by Chris DePuy, 650 Group / November 2, 2026
On October 29, an operator published a one-card Windows build for the full DeepSeek V4.1 Flash 1017 checkpoint. It ran on a single RT3090 with 192 GB memory and, in DGX Spark terms, served 41 tokens per second.
The measurement that carries the story is the second figure in the same operator’s post: the build was compared token by token against DeepSeek’s own hosted API, and he reports 90.2 percent agreement on the first-choice token overall, rising to 92.4 percent on code and mathematics. Two quantization lanes this quarter have now paired an aggressive weight compression with an explicit agreement test, and that pairing, more than the token rate, is what an enterprise buyer should read.
The build and its measured ladder
In this setup, the machine behind the number is a desktop, not a workstation.
Additionally, the post specifies an Intel Core i5-13600K.
It notes four 48 GB DDR5-5600 modules for 192 GB of system memory and NVMe solid-state storage.
The post states that every one of the model’s 552 billion parameters is present in the served checkpoint.
With the routed expert weights held at two bits rather than a pruned or distilled variant.
DGX Spark reveals how sensitive the build is to its parts list.
Additionally, cut system memory from 192 GB to 128 GB, and generation falls from 41 to 33 tokens per second.
On long prompts in the 25,000-to-64,000-token band, prefill runs at 610 tokens per second.
With 128 GB, the rate falls to 410 tokens per second.
Restricting the card’s visible frame buffer reduces throughput.
At 16 GB it drops to 31 tokens per second, and at 12 GB to 17.
The stated floor is 128 GB of memory and about 385 GB of free disk.
Expert weights read from the SSD after memory exhaustion, and requests are handled one at a time.
The post’s own closing line marks all of these figures as the builder’s own measurements.
Read together, those rows say something a vendor spec sheet does not: on this configuration the card is the least consequential part. The ladder moves on memory capacity and on disk, and the concurrency behavior is what a memory-bound decode looks like when the weights have to be fetched.
The fidelity test, and what it still leaves open
A contributor’s release on October 19 put the same 1017 checkpoint on a single 128 GB DGX Spark. It ran at 1.62 bits per weight on the routed experts. The report shows 99.61 percent answer-only agreement on code against DeepSeek’s checkpoint. Decode speed reached 35.5 tokens per second, with a prefill peak of 1,189 tokens per second. The release notes these are teacher-forced comparisons rather than task-side pass rates. At publication time, a broader evaluation across coding, math, tool-calling and multilingual tasks was still running. The one-Spark serving recipe lists the host as a stock Ubuntu 24.04 install. Thus, the two builds are complementary rather than duplicative: same checkpoint, two quantization methods, two operating systems, two memory systems.
The practical reading is that a 2-bit expert quant is being published with the agreement number attached, while the quality question that decides enterprise use, whether the model still completes real tickets, remains open on both lanes until someone republishes the two checkpoints under identical task suites on hardware neither author controls.
Scaling is the part one card does not buy
Single-stream speed and serving capacity are different problems.
The same community has measured the gap.
On September 19, four DGX Spark devices ran at tensor parallelism four.
The setup used 3.5-bit-per-weight EXL3 weights and a 500,000-token context limit.
Results included about 91 tokens per second single-stream on code.
There were 324 tokens per second aggregate across six concurrent sessions.
There were 376 at eight and 475 at twelve on coding prompts.
Cold prefill reached 1,939 tokens per second at a 3,000-token prompt.
It rose to 2,048 at 93,000.
The companion recipe is the published build for that configuration.
This site covered the checkpoint’s first multi-Spark community recipes in a day-one report.
The contrast with the consumer build is an occupancy comparison rather than a speed one. One big-memory box is a single-stream machine with requests waiting their turn; the four-node cluster is a capacity machine whose value is the streams it holds at once. The same reasoning applies to the accelerator itself: the community measurements of the tensor unlock for the RT30-series reported gains on matrix throughput while decode stayed flat, and a build whose bottleneck is fetching expert weights is not the workload those gains were for.
The bill of materials is the decision
For a buyer sizing this against a desk-side box, the useful line is the floor rather than the peak. The consumer build needs 128 GB of system memory at minimum and about 385 GB of clean disk before the card earns any attention, and the 192 GB ceiling is reachable on four slots only because the operator could source 48 GB DDR5 modules. The post itself attaches a condition to that route, noting the used-card-plus-big-memory path is interesting again provided DDR5 pricing stays tolerable, which is the honest caveat: the economics here track memory pricing more than GPU pricing.
Two things still have to land before a full-model consumer build is a serving option rather than a demonstration: replication of the 41-token figure on a second machine the builder does not own, and the task-level quality results both quantization lanes have flagged as pending. As firms such as 650 Group have been tracking in their AI infrastructure research, the checkpoint that holds agreement against a vendor’s own API while running on hardware a shop already owns is the one that changes the buying conversation, and the October receipts put that test, not the token rate, on the table.