Skip to content
← Free FDE training guides

Free learning / NVIDIA systems lab

NVIDIA systems: a workload-to-procurement lab

Connect GPUs, CUDA, Nemotron, NeMo and serving to a runnable capacity calculation and a complete rent-or-buy decision.

No account needed. Use your own copy for writing and keep the original as a reference.

Engineering lab library / Run locally

Make the capacity decision concrete.

Use the local systems lab to compare memory limits and hypothetical rent-or-buy scenarios. The walkthrough explains each input and what still needs real measurement.

Synthetic records. No provider key or model inference. Runs locally with the standard library.

  1. Start here / Python 3.11+ · Standard library

    GPU capacity and cost lab

    Find a memory admission boundary and compare hypothetical rent/own scenarios.

    Python 3.11+ standard library · No GPU or account

Original LockedIn FDE practice. Start with the visual NVIDIA learning path. Use Python 3.11 or later. No GPU, account, package installation or cloud purchase is required. The case, prices and memory allocations are synthetic. This is a planning and reasoning lab, not a GPU benchmark, vendor certification or authorization to buy hardware.

1. Map the system before choosing a product

The fictional Field Desk drafts maintenance responses using approved procedures. It serves one authenticated team, keeps data in an approved location, and asks a person to accept a draft. It must refuse cross-tenant data access and return a controlled response when capacity is exhausted.

Draw application → model service → GPU execution. Put the approved source store beside the application and a human decision after the draft. Place these labels at their responsibilities: GPU, CUDA, Nemotron, NeMo and NIM. NeMo development tools do not have to sit in every request path.

Keep a decision packet with: task, component, exact version, alternative, evidence needed and owner. Explain the diagram to someone before using an acronym. They should be able to point to the model and the hardware separately.

2. Run the capacity boundary

Download nvidia-capacity-lab.py into an empty working folder.

Code example
python3 --version
python3 nvidia-capacity-lab.py test
python3 nvidia-capacity-lab.py memory --concurrency 4
python3 nvidia-capacity-lab.py memory --concurrency 10

The default weight estimate is 16 decimal GB (about 14.901 GiB). At concurrency four, the total including fixed overhead and safety reserve is 37.6 GB against 48 GB. At concurrency ten, it is 49.6 GB and the estimate is refused. The per-request allocation is a supplied assumption; it is not derived from a real Nemotron architecture. A refused estimate is a successful boundary demonstration, so the CLI still exits normally and reports fits_estimate: false.

Change --bits 8, then --request-gb 4. Explain what changed and what did not. Lower stored precision changes arithmetic but does not establish acceptable quality. Actual memory depends on the selected model, precision, runtime, context and concurrency. The program models one device; adding several devices requires a placement and interconnect design, not simply adding capacities.

Produce two outputs and a paragraph naming which inputs need real measurements.

3. Inspect an environment without pretending to have a GPU

On a host you are authorized to inspect, nvidia-smi can show devices and driver information. Separately record the exact container digest, framework version and device execution check. If you do not have such a host, mark these observations as unverified. Do not install drivers, allocate resources or invent a transcript for this exercise.

The current CUDA guide and the chosen runtime's support matrix define compatibility. A host driver command does not prove that a framework inside a container is executing on the GPU.

4. Select a model and an improvement method

Use the Nemotron directory to choose a specific model card. Record the exact identifier/revision, modalities, context, license and runtime requirements. Leave performance unmeasured until it is actually measured.

Write five cases: an ordinary request, missing evidence, conflicting procedures, a foreign-tenant request and an adversarial instruction embedded in a document. Keep expected behavior and data boundaries fixed when comparing candidates.

Now diagnose three failures: stale knowledge, inconsistent formatting and unauthorized tool use. Propose the simplest relevant repair. Read the NeMo suite map and explain which specific component, if any, would help an improvement experiment. Keep held-out cases separate from the material used to improve the system. Guardrails do not replace server authorization.

5. Specify the private model service

Use the current NIM documentation to record a model/runtime candidate. Identify the authenticated caller, source boundary, memory admission rule, queue limit, timeout, retry budget and cancellation behavior. Do not put secrets into the packet.

Name readiness checks separately from task-quality checks. Include a permitted ordinary request as well as a denial. Write what happens under overload and who owns rollback. TensorRT LLM, Dynamo and NIM have distinct responsibilities; verify the exact release's supported combination.

6. Compare renting and owning

Code example
python3 nvidia-capacity-lab.py compare --hours 160
python3 nvidia-capacity-lab.py compare --hours 600

These hypothetical equivalent-capacity bundles use a rate of 8 currency units per hour, an 80,000-unit purchase over 36 months, and 800 units of monthly operation. Rental is 1,280 at 160 hours and 4,800 at 600 hours. The ownership estimate is 3,022.22 per month; the arithmetic crossover is approximately 377.78 hours. This is not a current NVIDIA price.

Replace assumptions only with comparable, dated evidence. Include storage, networking, software, support, electricity, cooling and staff in the operating-cost assumption. The simple formula excludes taxes, financing, residual value, migration and unmodeled downtime. Unknown costs stay unknown in the decision packet; they are not evidence of zero cost.

Add a managed endpoint and a smaller pilot as alternatives. State one change in usage or operating requirements that would reverse your recommendation.

7. Prepare a complete quote and acceptance request

Use the official where-to-buy directory and certified-system information as research starting points. Do not place an order as part of this lab.

Ask for exact SKU, GPU count and memory, CPU/RAM, interconnect, NICs, storage, rack/power/cooling, software entitlement, warranty, support, installation, delivery date and acceptance conditions. Distinguish a chip/card quote from a server or rack quote. Confirm provider region and capacity terms for rental. A product announcement is not a local availability guarantee.

Current-generation references checked 19 October 2026: Blackwell and Blackwell Ultra and Vera Rubin. Compare supported precision, memory, bandwidth, topology and the complete system. Recheck documentation and supplier availability before making a purchase decision.

End with a one-page recommendation: workload, chosen option, alternatives, estimated costs, observed evidence, unresolved assumptions, acceptance workload, receiving owner and next decision. The evidence should be understandable without the presenter supplying missing facts.

Before you move on

Keep the evidence of your work.

  • A labeled model, service and hardware architecture.
  • Two capacity boundaries and a hypothetical cost comparison.
  • A procurement brief with dated evidence and an acceptance workload.

Keep these in your own working copy. Reading this page does not save work or record completion.

Suggested next free session

Control AI traffic with a gateway

Put an explicit identity, routing and token budget boundary in front of the model service. This is a suggested sequence; choose the practice that addresses your current gap.

Open the next free guide
Have Academy access?

Continue with worked explanations, practice and review in the related lesson.

Open the related Academy lesson →
Back to top ↑