Two DGX Sparks: Read the Deployment Conditions

A two-node model deployment is a combination of weights, runtime, attention cache, speculation and transport. A model name and a cable speed leave too much unspecified to reproduce it.

This note reads WeZZard’s pinned two-Spark campaign, remeasured on 5 September 2026, alongside its detailed configuration ledger. It explains what to record before trying a similar deployment. These are community observations; Run AI Here has not run the models.

AI-generated conceptual illustration. It is not a measured topology, a combined-memory claim or a photograph of the author’s cluster.

Start with the campaign boundary

The source reports two GB10 DGX Sparks, 121 GiB per node and a back-to-back 200 GbE link. Its corrected campaign has prefix caching off, 512 output tokens per request with --ignore-eos, full-length warmup for each workload and user shape, and median summaries from three campaigns. Served rate includes first-token waiting time in the request wall clock. Original conditions.

Each node retains its own memory and runtime state. Do not translate the two memory specifications into a promise of one freely allocatable memory pool. A launch-time context cap, an allocated KV pool and measured simultaneous users describe different constraints.

Preserve the actual artifact and launch profile

The artifact names and checkpoint revisions below come from the detailed REPORT ledger. Short revision prefixes are displayed here; the full revisions and separate source-document hashes are retained in JSON.

The local image tags identify the reported environments, but a tag is not an immutable image digest. They are not a general installation command or an endorsement of an unverified image with the same name.

Keep context, KV pool and concurrency separate

Sources: corrected pools and launch profiles DeepSeek, Qwen, GLM. GLM’s static memory fraction is 0.90.

The configured maximum is not a successful measurement at that load. Nor does a pool value establish a usable per-request context by division: engine accounting, shared state and scheduling need inspection. Preserve the input-token count for each measured cell; a workload label is insufficient.

Verify the transport inside the container

The source’s interconnect investigation found that host networking worked while container verbs devices were absent and NCCL used sockets. A visible HCA listing alone did not prove active RDMA.

For a comparable setup, inspect the devices exposed to the running containers and the transport actually used during a request. Retain observations from both nodes. A successful host bandwidth test and a server-ready message answer different questions from a completed distributed inference request.

Separate historical tuning incidents from the final campaign

The earlier 4 September speculation investigation recorded a Qwen pool change from 600,000 to 145,024 tokens after enabling MTP. That earlier value is not the corrected campaign’s 161,728-token pool. It illustrates why the allocated pool must be re-read after a configuration change, rather than supplying a universal MTP memory formula.

That investigation also corrected an FP8-KV failure explanation: a single long prompt could trigger the chunked-prefill path. “Short prompt succeeded” therefore did not establish that the tested image supported long-context FP8 KV. The successful profile in the table uses bfloat16 KV. Keep failure records attached to their own build and settings.

What to capture before calling a reproduction successful

Record the exact artifact revision, conversion, image digest and executed runtime version. Read the allocated KV dtype and pool from startup evidence. Preserve speculation settings, context cap, prefix-cache state, actual input/output lengths, measured users and request failures. Warm the shapes you will measure on both nodes and retain clock and power observations under load.

The engine inventory separately records a Qwen-image version observation on 4 September. It does not supply an immutable image digest binding all three corrected campaign launches, so those execution fields remain unknown here. GLM’s exact draft-model revision also remains unknown in this extraction.

These profiles do not establish a cross-model ranking, current best settings or DeepSeek 1017 compatibility. Use the separate 1017 evidence note for checkpoint identity and the Spark preflight checklist to prepare a run record.