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.
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.
python3 --version
python3 nvidia-capacity-lab.py test
python3 nvidia-capacity-lab.py memory --concurrency 4
python3 nvidia-capacity-lab.py memory --concurrency 10The 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
python3 nvidia-capacity-lab.py compare --hours 160
python3 nvidia-capacity-lab.py compare --hours 600These 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.