GPU and Accelerator Configuration
What this domain tests
Making a healthy GPU behave predictably: persistence mode, ECC policy, MIG partitioning, NVLink state, and clock and power limits. The exam expects command-level familiarity with nvidia-smi and its MIG and NVLink subcommands.
Core rules
- Persistence mode.
nvidia-smi -pm 1keeps the driver loaded so CUDA context creation is milliseconds instead of seconds;nvidia-persistencedmakes the setting survive reboots. - ECC. Toggling ECC requires an idle GPU and a reset, and it cannot be changed with live processes. Uncorrectable errors surface as Xid 48 and can drive dynamic page retirement.
- MIG.
nvidia-smi -mig 1enables partitioning into GPU instances and compute instances; profile names encode compute slices and memory, e.g.1g.5gbon A100 40GB. Memory and SMs are dedicated, not shared, which is what makes MIG a multi-tenant isolation boundary. - NVLink.
nvidia-smi nvlink -sreports link status,-ereports CRC and replay errors, andnvidia-smi topo -mprints the GPU-to-GPU matrix whereNV#means NVLink andSYSmeans a cross-socket PCIe hop.
Worked example
A team wants seven isolated 5 GB inference tenants on one A100 40GB. Drain all processes first, run nvidia-smi -mig 1, then nvidia-smi mig -cgi 1g.5gb -C to create seven GPU instances with their default compute instances. Seven fits exactly because the 1g profile on the 40GB card is 5 GB; on an 80GB A100 the smallest profile is 1g.10gb, so the same request would need re-planning. The reasoning: MIG capacity is bounded by both the slice count limit (seven) and the memory granularity of that specific SKU.
Traps that cost marks
Creating instances without enabling MIG mode first; expecting a MIG slice to use NVLink bandwidth to another slice; assuming clock and power controls stay fully available while MIG is enabled; forgetting that a reboot clears persistence mode unless persistenced is running.