What I would test with a third 128 GB DGX Spark
Published
DGX Spark · proposed research
A third Spark needs a test plan
A proposed experiment comparing supported deployments against useful agent work. The lab owns two Sparks; the third system is proposed and hardware support is unconfirmed. No three-node result is represented here.
- PIN Workload and software Record the model artifact, runtime, context, output limits and test settings.
- CONFIGURE Pair, three nodes, or pair + worker Use a layout supported by the model and runtime; report capacity separately.
- MEASURE Useful work and responsiveness Keep completed tasks, latency, generation rate, errors and memory in the record.
- PUBLISH Recipe, results and limits Share reproducible measurements and unsuccessful configurations after the tests run.
I already own two NVIDIA DGX Spark systems. The next expansion I am exploring is one additional 128 GB Spark for a dedicated experimental node and scheduled three-node tests.
Hardware status, October 29: two systems owned; third system proposed; hardware support unconfirmed. This article is the test plan. It contains no new three-node measurements.
The useful question is how another machine changes the work I can finish: testing a model without taking the reference setup apart, running more useful agent tasks, or fitting a workload that does not fit the pair.
Start with the existing pair plus a test node
The simplest role for a third Spark is an isolated place to try a candidate model, quantization format or inference runtime while the existing pair stays available.
That separation makes a comparison easier to interpret. The reference configuration can remain fixed while the candidate changes. Deployment, rollback and memory limits can be exercised on the experimental node before a wider change is considered.
A single experimental Spark still has a single system’s memory limit. A candidate that needs multiple nodes would require a scheduled cluster experiment instead.
Three-node networking is now documented
NVIDIA’s Cluster Assistant guide documents a direct three-Spark ring: three supported QSFP cables, with each system connected to the other two. That layout does not require an external switch.
Networking is one part of the setup. The model, runtime and parallel execution configuration must also support the chosen layout. NVIDIA’s multi-Spark vLLM guide lists guided support for two to four matching-memory devices, while its current worked command-line examples cover two. A tested, versioned three-node recipe would be a useful contribution.
That recipe is an intended deliverable, not a claim that I have already run it. Actual model fit must leave room for the operating system, runtime and attention cache.
Compare layouts against the same useful work
| Layout | Question to answer |
|---|---|
| One Spark, for workloads that fit | What does the smallest supported deployment accomplish? |
| Two-Spark deployment | What does the existing reference configuration accomplish? |
| Two-Spark deployment plus an independent worker | Does separating work improve completed-task throughput or responsiveness? |
| Supported three-Spark deployment | Does a larger shared workload justify the communication and configuration overhead? |
Speed comparisons would use the same supported model artifact, task set and generation settings. A larger model that only fits a larger layout belongs in a capacity comparison, with its quality and latency reported separately.
The test record would pin model and runtime versions, quantization, context length, output limits, concurrency and the network layout. Repeated trials would preserve failures and report the distribution rather than only the fastest run.
Measure task completion as well as tokens
The proposed measurements include:
- Useful work: task success, tool-use correctness and successfully completed tasks per hour.
- Responsiveness: time to first token, generation rate, and end-to-end response latency under concurrent sessions.
- Capacity: usable memory, context limits and configurations that fail to fit.
- Reliability: extended runs, error rates and recovery from controlled failures.
Power or energy results would be included only where an appropriate meter provides those readings. A software utilization percentage is not an energy measurement.
What I intend to publish
The proposed project would produce benchmark scripts, a public task set with sanitized results, a reproducible setup/serving recipe, and a report explaining which workloads benefit from each layout. The target is a 90-day project after receiving the additional hardware.
Private business data, production prompts and internal operating playbooks would remain private. Any supplied hardware would be disclosed, and the report would include unsuccessful configurations and limitations.
Until those experiments run, the site’s model test history and existing two-Spark build log remain the places to read the dated results we actually have.