THE PRACTICAL ANSWER
Check the exact machine, architecture, software identity, artifact support, available capacity and workload ownership before installing or testing. A hardware specification and an old successful deployment do not establish today's available test environment.
- Reference
- Checklist v3 · community case review, no site deployment
- Site-tested environments
- None · no installation or inference performed
- Source review / reproduction
- 18 Oct 2026 / Not run
- Release state
- Source-based guide · independent reproduction not run
Identify the system and the owner
Use an explicitly authorized machine and time window. Note the device model, architecture, OS and kernel. Ask the workload owner about existing services and jobs before starting a process. This page contains no network addresses, credentials or controls. It has not inspected any machine, scheduled a job or measured occupancy.
Collect a narrow environment receipt
On a test host you are permitted to inspect, collect the architecture, kernel and GPU software identity. Keep identifiers and private paths out of a public receipt. These read-only commands are examples for the host operator; the website cannot execute them. A successful nvidia-smi response is inventory evidence, not an inference benchmark.
uname -m
uname -r
nvidia-smi --query-gpu=name,driver_version,memory.total --format=csvCheck the complete software chain
Confirm that your selected runtime release supports the host architecture, the model architecture and its exact quantization. For a container, inspect its architecture manifest and pin an image digest. For a source build, record the commit and build options. A container tag, a community post or a device marketing claim is insufficient to establish this combination. Missing evidence means pending reproduction.
Budget capacity without reserving it
Account for weights, temporary download space, container layers, KV cache, runtime overhead and retained results. Use available memory after existing workloads. Do not infer model capacity from total unified memory alone. A multi-node topology needs explicit network and parallelism configuration; it is not a larger single memory pool by default. There is no multi-node scaling result on this page.
Prepare a minimum experiment manifest
Write down model revision, artifact hashes, tokenizer, chat template, runtime identity, device count/topology, context, input/output policy, concurrency, cache, KV type, seed and corpus hash. Leave unmeasured power and temperature null. Validate that record with a synthetic fixture first. The fixture validator does not authorize or launch the real experiment.
Define stop and recovery conditions
Before execution, agree on memory pressure, timeout and failure limits with the host owner. Retain the previous runtime and settings. Stop on unexpected workload contention or unsupported artifacts, and release only resources you allocated. A successful canary permits a technical next step only within the operator's separate authorization; it does not permit publication.
Separate a deployment receipt from a publishable result
An inventory, a load check, a short canary and a repeated benchmark establish different facts. Retain the source and artifact identities, test method, failure counts and permission to share the material you use. Remove private prompts, addresses and credentials from a public report. A successful server response does not establish quality, and a community result on a similar machine does not become your own measurement.
Check clocks, cache and the actual transport
The two-Spark audit remeasured its campaign after a low-clock node and unequal prefix caching changed earlier conclusions. DGXArley separately explains why a large-message NCCL bandwidth number can hide a poor small-message path. These reports support a preflight checklist that captures under-load clock behavior, full-shape warmup, cache policy and the serving container’s transport; they do not justify changing a shared cluster without an operating window.
Community incidents → preflight questions
Two distinct reports, read at their pinned revisions. These cases explain checks; none was reproduced by this website.
Check clocks with load and power
The two-Spark author corrected a campaign after finding a node that did not clock up normally. Their guard considers clock and power together; an idle clock reading alone is insufficient. Original report
Record before testing: Retain under-load observations from each node, power and any throttle indications. Investigate asymmetry before interpreting a timing result.
Make prefix-cache state comparable
The same campaign had denied prefix caching only to Qwen. Its corrected comparison explicitly disabled the prefix cache for all three models. Original report
Record before testing: Record the policy, actual cache state and repeated-prompt method for every result. A warm repeated prefix and a fresh prompt answer different questions.
Warm the workload that will be timed
Short-output warmup had missed serving-time compilation. The revised campaign warms each workload/user shape at full generation length and keeps JIT caches per node. Original report
Record before testing: Retain warmup shapes and completion status for every rank. Check compilation messages before calling a result steady state; do not assume a shared cross-node cache.
Verify the serving process transport
The two-node container could not see RDMA devices and used TCP despite a 200 GbE physical link. Separately, DGXArley warns that large-message bandwidth hides small-message behavior relevant to decode. Original report · Transport source
Record before testing: Record the actual serving-container transport and interfaces, device visibility and topology. Read a small-message profile with the tested process configuration; link speed alone is insufficient.
YOUR LOCAL CHECKLIST
Keep the open questions visible.
Checking a box records your own review. It does not create site-verified evidence.
0 / 9 marked · this browser session only
Sources & change log
18 Oct 2026 · Revision 3. Added pinned community cases and matching preflight fields.
- NVIDIA DGX Spark initial setup Checked 2026-10-17 · Setup reference; does not establish that any local machine is available.
- NVIDIA DGX Spark hardware overview Checked 2026-10-17 · Hardware reference; total memory is not usable model capacity.
17 Oct 2026 · Revision 2. Source-based task guide and downloadable resource. Source documentation inspected; environment reproduction not run. Moving documentation may change after review.