Our four-node DGX Spark ring serves DeepSeek-V4.1-Flash-1017 with ds41f (setup in DGX Spark ×4 in a Ring). Its author released spark-ds41f-1030 on 2026-10-29, and we moved to it the next day. This post puts the two releases side by side on the same hardware.
What changed in 1030
From the release notes (vLLM patches 0491–0567):
- TileLang is the only kernel family; the checkpoint loads directly.
- Prefill yield: a short request that arrives during a long prefill gets its first token sooner.
- PDL along the decode chain.
- GLP steering per request, served under a second model name.
- An Engram hash fix (#677) and a corrected KV-capacity line at startup.
The author’s own comparison against 1025: prefill 8.4–12.2% faster from 32K to 1M, decode 1.9–3.6% faster at every concurrency.
How we measured
Same as the earlier post: four nodes in a switchless ring, TP4, the stock 4 KiB-page kernel, GPU clock capped
at 2,000 MHz, and one harness, the benchmark script from Mia’s AI Lab’s 2x recipe
(tools/bench.py): streaming, temperature 0, thinking off, a random salt per
run so nothing reads the prefix cache, two repetitions per point. 1025 was measured on 2026-10-28, 1030 on
2026-10-30, each with other traffic kept off the engine.
Prefill
From 8K up, 1030 is 7–9% faster: a 128K-token prompt starts answering in about 18 seconds instead of 20. Short prompts (2K) are unchanged.
Decode and concurrency
A single decode stream rose from 67.0 to 72.0 tokens/s (+7.5%). Under load the two releases are level: at 16 concurrent requests both deliver about 326–328 tokens/s in aggregate.
| 1025 | 1030 | Change | 1030 (author)(*1) | |
|---|---|---|---|---|
| Prefill 2K (tok/s) | 4,433 | 4,380 | −1% | – |
| Prefill 8K (tok/s) | 5,783 | 6,284 | +8.7% | – |
| Prefill 32K (tok/s) | 6,377 | 6,886 | +8.0% | 7,313 |
| Prefill 128K (tok/s) | 6,239 | 6,675 | +7.0% | 7,396 |
| Decode, 1 stream (tok/s) | 67.0 | 72.0 | +7.5% | 78.3 |
| 4 concurrent (aggregate tok/s) | 162 | 165 | +1.4% | – |
| 16 concurrent (aggregate tok/s) | 328 | 326 | −0.7% | – |
(*1) From the author’s release record (four-node ring, 2026-10-30, the author’s own suite; 131K for the long prefill row, “one conversation at a time” for 1 stream). The author’s ring runs the 64 KiB-page kernel without a clock cap. Our cap alone costs 7–10% of prefill (earlier post), which accounts for most of the gap.
Single runs move around: across four runs of 1030 that day, the 128K prefill median ranged from about 6,200 to 6,700 tokens/s. Read differences of a few percent with that in mind.
Takeaways
- At the same clock, 1030’s prefill gain matches the author’s claim (+7–9% here, +8–12% there).
- Single-stream decode improved; aggregate throughput at 8–16 requests did not move.
- The upgrade took about 19 minutes of downtime (an image build of 8 minutes plus copying it to three nodes).