4 DGX Sparks Test DeepSeek V4.1 Flash: How Good Is Local Inference Productivity?

Why Run a "Large Model" Locally

The most direct reason to deploy DeepSeek^Ad V4.1 Flash (commonly known in the community as the 1017 version) next to your desk rather than calling a cloud API is control over data flow. A Bilibili creator linked 4 DGX Sparks / GX10s into a ring connected via 200G DAC cables—without using a high-speed switch. This is a community route outside NVIDIA's official 4-card guide. The official recommendation is a switch-based layout, but switches are not cheap; once the community got the ring topology working, it became the more pragmatic choice.

This setup runs SGLang. The creator notes that the community is also following new engines such as TensorRT-LLM, so the same hardware still has room for further optimization. This article breaks down the real-world performance of local inference based on his measured data: generation speed, first-token latency, multi-channel concurrency, and how well four "wish-style" tasks were completed.

DGX Spark is a compact AI computing device NVIDIA launched for desktop and edge scenarios (the community also often refers to similar products by codenames like GX10). Positioned between a workstation and a dev kit, it emphasizes delivering substantial VRAM and compute in a low-power, small form factor for local inference and fine-tuning. Ring topology means multiple devices are connected end-to-end to form a logical ring, with each device only directly connected to its two neighbors. Compared with a star-shaped switch layout, this saves switch ports and cost at the expense of multi-hop forwarding for cross-node communication; in scenarios like tensor parallelism that require frequent all-node communication, the bandwidth and latency of the ring interconnect directly affect inference throughput.

Generation Speed: Code Beats Prose, but Don't Compare Peaks with the Cloud

The measured data comes in two framings. With thinking mode off and 16 channels combined, code tasks hit 369.9 tokens/s and prose 317.8 tokens/s; from a single-channel perspective, code reaches 119.8 tokens/s and prose 71.2 tokens/s.

The reason code is faster is not hard to understand: code is structurally regular and subsequent content is more predictable, giving speculative decoding a chance to confirm multiple tokens at once. Prose has more freedom, so the hit rate drops and speed naturally falls off.

Where does this number sit in cross-comparison? OpenRouter charts show DeepSeek's official endpoint at about 63 tokens/s, with relayed access even slower; the creator cites online data claiming direct connection to the official API is about 200 tokens/s (not personally tested). Four small local machines running at 119.8 tokens/s already exceed the public readings from the official endpoint, though they still lag behind some providers' 294 tokens/s. Among commonly used foreign tools, Claude is about 107.1 tokens/s and Codex about 37.2 tokens/s—note these figures come from different environments and can only serve as order-of-magnitude references.

Speculative Decoding is a technique that accelerates generation without changing the output distribution: a lightweight "draft" model or heuristic first quickly guesses several subsequent tokens, then the main model verifies them all in parallel at once, directly accepting the correct guesses and rolling back from the first divergence when wrong. Its speedup depends heavily on text predictability—code and templated text have high hit rates, free prose low—which exactly explains why code is faster than prose in the measurements. TP4 means tensor parallelism of 4, i.e., splitting the weights of a single layer across 4 devices for joint computation, a common parallel strategy for running large models on a four-card cluster.

First-Token Latency: Long Context Is the Real Barrier

The weakness of local deployment isn't generation—it's the "reading the material" phase. Measured TTFT (from sending to first token output): about 5400 tokens/s at 60k+ tokens, waiting 12 seconds; about 4800 tokens/s at 260k tokens, waiting 54 seconds; about 3400 tokens/s at 1M tokens, waiting 4 minutes 54 seconds.

Looking at these wait times alone is indeed discouraging. But the creator's daily workflow uses DeepSeek Harness, where the cache hit rate for continuous tasks is basically above 90%—previously computed content is reused directly and only the new part is recomputed. For the same 60k+ token document, the second question waits only 0.4 seconds. Caching dramatically blunts the pain of "long context," and this is also the key to making local agent workflows viable.

The TP4 configuration supports a 1M token context. A complete edition of The Count of Monte Cristo is about 590k Chinese characters and over two megabytes of plain text—roughly 675k tokens after tokenization—so putting the whole book in still leaves over 370k tokens of headroom for continued questions or letting the model continue writing.

TTFT (Time To First Token) refers to the time from when a request is sent to when the first output token is received, mainly determined by the prefill stage: the model needs to compute the KV cache for the entire input context, and the compute is roughly proportional to context length, so longer contexts mean longer waits. KV cache hit relies on the prefix caching mechanism—if the beginning of a new request is exactly the same as a historical request, the engine can reuse the already-computed KV state and only prefill the new portion. This is exactly why a second question on the same 60k-token document takes only 0.4 seconds, and it is also the precondition for long-context agent workflows to be feasible locally.

Concurrency and Multi-User Use: 16 Channels Is the Recipe Limit, Not the Experience Limit

One channel means one person using it; eight channels means several things running together. Pushing the unified test to the recipe's 16 channels means each person gets a bit slower a share, but the overall group throughput is higher.

This characteristic determines the use case: it's not for one person chasing extreme response speed, but for a small team sharing an intranet inference pool. The creator's judgment is that running this model on four Sparks is "already very practical" for personal and small-company internal use—model inference stays on the intranet, and the flow of personal data, client contracts, and work documents is under your own control, with one less layer of dependence on cloud services.

Four Stress Tests: From Riding a Bike to Building a City

The creator used four tasks to test real productivity, all with extremely short prompts, relying on the model to fill in the details itself:

Make Tihu ride a bike: in about 7-plus minutes it produced the first HTML—legs pedaling, wheels turning, body bobbing—from a one-sentence prompt.

3D rescue game: the canyon, cable car, storm, and objectives were all built by the model. The first version had bugs; after one round of feedback they were fixed, and after the fix, it could move to pick people up and transport them. Interestingly, DeepSeek wrote wind force into the physics calculations—the heading drifts due to wind, so the player must constantly correct, and ultimately three passengers are rescued.

Fukushima from desolation to prosperity: grassland spreads out, paths appear, trees and buildings grow layer by layer, wind turbines turn, and the camera can orbit around this little world.

Fictional handheld console website: a product website for a transparent handheld console called "Lingjie," where the body splits into six layers as you scroll, color schemes can be switched, and the reservation popup works on mobile too. But a closer look gives it away—there's no fine internal structure, and the circuitry looks more like several layers of flat glass stacked together. One HTML file achieved both appearance and interaction, with limited depth.

Deployment Experience: From Tuning Parameters to Handing It to an Agent

Many people still associate local deployment with tuning parameters against documentation. The creator's current process is: plug in power, connect the DAC cables, set up SSH, hand the recipe link to an agent, let it deploy the model, then connect to DeepSeek Harness. Once robots learn to plug in cables, even the two steps of connecting power and network cables can be eliminated.

The day after 1017 was released, this community recipe was up and running. From the timeline, community adaptation speed is already keeping pace closely.

One background worth noting: the creator mentions that DeepSeek officially recorded a nearly five-hour partial outage of its website and API. The specific date and details are vaguely stated in the original, but they point to a simple argument—put inference at home, and you have one less layer of dependence on cloud service availability. This is also the core motivation why local deployment is still repeatedly discussed in 2026: not the pursuit of benchmark scores, but the pursuit of not being interrupted.

SGLang is an open-source framework for large model inference and serving. Its core features include RadixAttention (managing KV cache prefix reuse with a radix tree), efficient multi-channel batching scheduling, and support for deployment forms such as tensor parallelism and quantization—particularly suited to multi-turn dialogue and agent scenarios that require high cache hit rates. The TensorRT-LLM mentioned in the article is NVIDIA's own inference optimization library, focusing on operator fusion, quantization, and kernel-level tuning to squeeze GPU performance. Swapping inference engines on the same hardware often yields different trade-offs in throughput and first-token latency, which is exactly where community recipes have room for continued iteration.

Conclusion: Good Enough, with Clear Boundaries

A ring cluster of four DGX Sparks running DeepSeek V4.1 Flash reaches nearly 120 tokens/s on code generation, makes long context nearly imperceptible once the cache hits, and supports 16-channel concurrency to serve a small team sharing it. Its value lies not in peak performance but in data sovereignty and availability autonomy. The costs are hardware expense, first-token latency, and the fact that complex 3D tasks still require human feedback and iteration.

For individual developers and teams of fewer than ten people, this setup has crossed the "usable" threshold; for production environments chasing extreme throughput, switch-based layouts and stronger engines remain the next step.

One-line Summary

A hands-on test of running DeepSeek V4.1 Flash locally on a four-DGX-Spark ring network, and its boundaries

Paragraph Summary

Based on a Bilibili creator's hands-on test, this article breaks down the local inference performance of running DeepSeek V4.1 Flash (1017 version) on 4 DGX Sparks/GX10s linked into a ring topology via 200G DAC cables. With thinking mode off, single-channel code hits 119.8 tokens/s and prose 71.2 tokens/s, while 16 channels combined reach 369.9 and 317.8 tokens/s respectively—already exceeding public readings from the official endpoint. The real weakness is first-token latency: a 1M-token context takes 4 minutes 54 seconds, but with a cache hit rate above 90%, a second question takes only 0.4 seconds. 16-channel concurrency suits a small team sharing an intranet inference pool. Four agent tasks with extremely short prompts (bike animation, 3D rescue game, Fukushima growth, handheld console website) were all completed, though complex 3D tasks still need human feedback and iteration. The conclusion: the setup has crossed the usable threshold, and its value lies in data sovereignty and availability autonomy rather than peak performance.