# Preflight a DGX Spark deployment.

Revision 3 | 2026-10-18 | source_reported | pending_reproduction

SOURCE-BASED GUIDE. No installation or independent model benchmark performed.

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

## 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.

```sh
uname -m
uname -r
nvidia-smi --query-gpu=name,driver_version,memory.total --format=csv
```

## Check 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.

## Self-check (not site evidence)

- [ ] Named machine and workload owner confirmed
- [ ] OS, driver and architecture captured
- [ ] Container manifest supports the host architecture
- [ ] Artifacts, disk and memory budget checked
- [ ] Recovery and disclosure review recorded
- [ ] Under-load clock and power observations retained per node
- [ ] Prefix-cache policy and actual cache state recorded
- [ ] Full-shape warmup and per-rank compilation state retained
- [ ] Serving-container transport and device visibility captured

## Sources

- [NVIDIA DGX Spark initial setup](https://docs.nvidia.com/dgx/dgx-spark/first-boot.html) | checked 2026-10-17
- [NVIDIA DGX Spark hardware overview](https://docs.nvidia.com/dgx/dgx-spark/hardware.html) | checked 2026-10-17

## Community incidents and original sources

### 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.

Record before testing: Retain under-load observations from each node, power and any throttle indications. Investigate asymmetry before interpreting a timing result.

Original report: https://github.com/WeZZard/dgx-spark-bench/blob/25e8dbf1b6113dd0b3f12d27a670fb284944d260/README.md#L113

### 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.

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.

Original report: https://github.com/WeZZard/dgx-spark-bench/blob/25e8dbf1b6113dd0b3f12d27a670fb284944d260/README.md#L127

### 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.

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.

Original report: https://github.com/WeZZard/dgx-spark-bench/blob/25e8dbf1b6113dd0b3f12d27a670fb284944d260/README.md#L138

### 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.

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.

Original report: https://github.com/WeZZard/dgx-spark-bench/blob/25e8dbf1b6113dd0b3f12d27a670fb284944d260/README.md#L182
Transport source: https://github.com/vroomfondel/dgxarley/tree/5f1f3762797eac0ea1ad43e403fa979e3e2c3934#L25


## Source identity

- WeZZard: https://github.com/WeZZard/dgx-spark-bench/blob/25e8dbf1b6113dd0b3f12d27a670fb284944d260/README.md
  - Revision: 25e8dbf1b6113dd0b3f12d27a670fb284944d260
  - SHA-256: b815d32807147f9638b1abbeadc02af257c55bd1f7651a123e5a8090bebe7469
- vroomfondel: https://github.com/vroomfondel/dgxarley/tree/5f1f3762797eac0ea1ad43e403fa979e3e2c3934
  - Revision: 5f1f3762797eac0ea1ad43e403fa979e3e2c3934
  - SHA-256: 293d119b6374d8073f040fe6dd277fe42f50f5f9baaadfdfa0d2120e65f12568