# DeepSeek on DGX Spark: What DGX sPLIce's 322 Tokens per Second Means

A new community build combines two DGX Sparks with an RTX 3090 host, and its published measurements show why the workload matters.

By Paras Madan | 2026-11-01


PLI Labs published new October 31 measurements for DGX sPLIce, a community build running DeepSeek-V4.1-Flash-1017 across two DGX Sparks and an additional x86 machine with two RTX 3090 GPUs. It reports 322 output tokens per second on a four-stream counting test. Coding and prose results are substantially lower.

For developers evaluating local inference, the useful part is the published configuration and raw results. **This is a mixed three-machine setup**, not a result produced by two Sparks alone, and 322 tokens per second is aggregate throughput across four requests.

## What hardware DGX sPLIce needs

The [installation guide](https://github.com/ProprietaryLegal/DGX-sPLIce-DeepSeek-V4.1-Flash-2xDGX-Spark-2xRTX3090-drafter-x86-offload/blob/main/docs/install.md) lists two DGX Sparks connected at 200 Gb/s. The x86 host connects separately to each Spark at 40 Gb/s and needs about 220 GiB of spare RAM for the model's Engram tables. The tested host has an AMD EPYC 7302P and 503 GiB of memory.

Two 24 GB RTX 3090 cards on that host run the speculative drafter. A smaller drafting computation proposes tokens that the main model checks, potentially producing several accepted tokens in one round. Moving both the drafter and Engram storage off the Sparks leaves more memory there for the attention cache.

The build uses a legal-weighted allocation of HeNryous's 2.75-bit-per-weight EXL3 quantization, served through vLLM with additional software overlays. It is a deployment recipe from PLI Labs, not a new DeepSeek model release or an NVIDIA-supported turnkey appliance.

## The benchmark changes with the prompt

The [October 31 raw results](https://github.com/ProprietaryLegal/DGX-sPLIce-DeepSeek-V4.1-Flash-2xDGX-Spark-2xRTX3090-drafter-x86-offload/blob/main/runs/2026-10-31-sparkdash-protocol-ebc29ed8.json) contain three repeats per output-speed test. Their median aggregate rates are:

| Workload | One stream | Four streams, combined |
| --- | --- | --- |
| Counting numbers, structured test | 138.3 tokens/s | 322.1 tokens/s |
| Code prompts | 110.5 tokens/s | 192.0 tokens/s |
| Prose prompts | 66.0 tokens/s | 130.1 tokens/s |

These tests use temperature zero, thinking disabled and 400 generated tokens per request. The structured prompt asks the model to count from 1 to 200. It should not be read as a general result for complicated JSON generation or agent tool calls.

The [measurement notes](https://github.com/ProprietaryLegal/DGX-sPLIce-DeepSeek-V4.1-Flash-2xDGX-Spark-2xRTX3090-drafter-x86-offload/blob/main/docs/measurements.md) explain the gap: almost all five proposed draft tokens are accepted per round on counting, compared with roughly 2.2 on prose at four streams. Drafting helps most when its predictions match the main model reliably.

That gives a buyer a more useful question than the fastest headline number: does the intended workload resemble the test where the extra GPUs help?

## Context capacity is not a single-request limit

The project reports an attention-cache pool of about 1.93 million tokens, but the configured maximum context for one request is 327,680 tokens. **The shared cache pool is not a 1.93-million-token context window.**

In the published prefill run, a roughly 262,000-token prompt took about 100.4 seconds to reach its first token. The headline prefill rates subtract a small measured overhead; the raw file also includes unadjusted rates. Long-document ingestion and interactive response speed therefore need separate measurements.

## What the release still leaves unproven

These are the builder's measurements, not an independent reproduction. The repository discloses differences in clocks, prompts and hardware when comparing other two-Spark builds, and reports losses on several workloads. It also says the persistent prefix-cache code and some comparison run files have not yet been published.

The current setup supports at most four concurrent streams. A short request arriving behind a long cold prompt can also wait tens of seconds for its first token. Those limits matter for a shared developer service, even if its total output rate looks attractive.

DGX sPLIce gives local-inference teams a concrete configuration to inspect and reproduce. Before adding a drafting machine, measure the acceptance rate on your own tasks and the waiting time under mixed traffic. The extra hardware needs to improve the requests people actually make.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders explain infrastructure work and benchmarks clearly, so developers understand what changed and where the limits are.

[Book a 30-minute call](https://cal.com/paras-madan/30min)