Owen's recipe, standard release 1107: DeepSeek-V4.1-Flash on 4 GB10 boxes (TP4 ring)

How fast it runs

Long prompts: context steps (filler log first, task prompt last, 512 reply tokens)

Context step and prefill series. "Prefill at 32K" in the table above is the prefill series (a cold prompt of 32,768 token ids, 8 reply tokens, three runs). The 32K row here is a different measurement of a prompt of about the same size: a chat request with a filler log first and the task prompt last, 512 reply tokens, two runs each with the code and the prose prompt. Both divide the prompt tokens by the time to first token; the two numbers are not the same measurement.

Method: code+prose; 2 run(s) each; 512 tokens; 1 warm-up(s); median; context steps: prompts of exactly 16K, 32K, 64K and 128K tokens (a filler log first, the code or prose task prompt last), 2 runs per step, 512 output tokens; decode = tokens after the first / time after the first token; prefill = prompt tokens / time to first token of the same request, median over its requests; requests at once: C1,C2,C4,C8 at once; 2 rounds each; 512 tokens per request; prose prompt; total = all tokens / wall time, per request = tokens / end-to-end time; median over the rounds. Measured 2026-11-13. Raw files: speed result · speed contract · log · long answer.

Requests at once: the server has 16 slots (from the author's recipe).

What ran. Christopher Owen's standard release spark-ds41f-1107 (release commit cc20ed18be1f7cbf5c6c53cdee945f7cc77d5fc5 of Nov 7, 2026; the GitHub release was published on Nov 8, 2026 and is marked Latest). The setup is the recipe's shape tp4-ring: DeepSeek-V4.1-Flash-1017 (revision 1bae0e10, FP8 with FP4 routed experts, as published) with its DSpark drafts (5 per step), served by vLLM (the local-inference-lab fork that the recipe pins: base 19f2c20e plus 641 patches, tree ed1bdb7a) with TileLang kernels, tensor parallel 4 over 4 GB10 boxes in a cable ring, the one-shot ring all-reduce (transport oneshot-ring4), a context of 1,048,576 tokens, 16 slots (--max-num-seqs 16) and a batch of 16,384 tokens (shape values from releases/spark-ds41f-1107/cluster.json lines 224 and 227 to 230). The image is not Owen's: we built it ourselves from Owen's recipe on Nov 8, 2026 (image tag spark-ds41f:1107, our image ID sha256:141450645e06695f04a96e0279065865834f3ee01b0298dfa8e09ce820537bd1; no published image was used), and started it with Owen's own tool, bin/spark, and a cluster config of ours that extends the recipe (the start command is in the Setup section below). Owen's own published numbers are in the section "Owen's published numbers" below, labelled with release, date and method.

Where this run differs from Owen's setup (paths in this paragraph are relative to the repository root at the release commit cc20ed18). (1) Kernel and page size: the stock kernel 7.0.0-1019-nvidia with 4 KiB pages and no memory saver, where the recipe asks for 7.0.0-1019-nvidia-64k with 64 KiB pages and the memory saver (releases/spark-ds41f-1107/cluster.json lines 74 to 78 for the kernel and the page size, docs/memory-profiles.md line 99 for the memory saver 0.4.1; the start tool printed its warning about this on all four boxes). (2) GPU clock: our boxes run with a standing cap of 2200 MHz; Owen writes that a healthy GB10 stays near 2,400 MHz in operation (docs/recovery.md line 176), and Owen's measurement files do not record the clock. In our load log the clock stayed at 2,171 to 2,190 MHz on the four boxes while the GPUs were busy. (3) Weights: the workers read the weights over a read-only network share from the head box when the model loaded (the share was mounted during the whole run and has been removed since); the two Engram shards (47 and 48) are local on every box. (4) The recipe's GLP file is left out (glp unset in our cluster config); only the stock model name is served. (5) The image is our own build (point above), made on Nov 8, 2026 with the vLLM patch_head 2756478b, as issue 952 in Owen's repository describes; the vLLM tree label ed1bdb7a equals the tree that the recipe expects. On Nov 9, 2026 Owen moved the tag spark-ds41f-1107 from the release commit cc20ed18 to commit 8e5ea208f3d22bc69df91ace94d6975932c858a8; the tag text says that the release records now carry the patch_head 2756478b that the build tool reproduces, with the tree ed1bdb7a unchanged (issues 952 and 1020). The two commits differ by one or two changed lines in each of 17 files, all about the recorded patch head (our comparison list of the two commits), so the code, the patches and the recipe values on this page are the same under both; our start config and the image come from the release commit and the Nov 8 correction. (6) NCCL_IB_GID_INDEX stays pinned to 3, as in the recipe (cluster.json line 245). (7) Host: fan control is off in our config (host.fan_control false); the memory available while the speed test was running stayed at or above 17.2 GiB on the head box and 18.3 to 19.0 GiB on the other three (our load log), well above the 3 GiB that the recipe's memory guard is set to (cluster.json lines 69 and 70). (8) Sampling and thinking: temperature 1.0 and top_p 1.0, the recipe's generation defaults (releases/spark-ds41f-1107/cluster.json lines 19 and 20, equal to the model card as recorded on our card), no top_k, no min_p and no penalties, because the recipe names none; seed 42; thinking is off in every request of Speed v2 and of the six fixed quality lists (enable_thinking false per request), on only for the last quality test; Owen's server default is thinking on (docs/current-state.md line 292), and Owen's own test runs use thinking off. (9) The prompt cache is off for the tests (cache_prompt false, a different cache salt in every request). (10) The context, the slot count, the batch size and the KV cache of 10.5 GiB per rank (11,274,289,152 bytes) are the recipe's own values, unchanged.

Two runs, and which one each value comes from. Run 1 (Nov 13, 2026; server up at 00:23 after 641 s, all of it on one server start): Speed v2 (00:23 to 00:35), then the five quality tests of the instruct profile (00:35 to 00:52) and the Thinking test (00:52 to 01:01); every part finished. The repetition (a second server start, up at 01:17 after 656 s): Speed v2 only (01:17 to 01:30); the load guard stopped it at the 128K step (see "The repetition" below), so it is not a complete run. Every value in the tables of this page comes from run 1; the repetition's values are told in the text and are not in the tables (one valid value per measurement). The raw folders are: speed-r0 (Speed v2 of run 1), inst-r1 (the five instruct quality tests), think-r2 (the Thinking test) and wdh1-speed-r0 (the repetition).

The headline 76.3 tok/s is the mean of the code prompt (76.4) and the prose prompt (76.3), medians of two runs each (the code runs gave 70.6 and 82.1, the prose runs 70.9 and 81.7 tok/s; spread (CV) 10.6 % and 10.1 %). The code prompt has 1,210 and 1,213 tokens and the prose prompt 1,279 and 1,285 tokens; every reply is 512 tokens long and ends at the limit. Drafts were accepted at a rate of 23.1 % (1,133 of 4,898 drafted tokens, mean accepted length 2.24 tokens; counted from the engine's counters over the four decode runs). The four decode runs of run 1 spread widely (70.6 to 82.1 tok/s for the code prompt, 70.9 to 81.7 for the prose prompt); the spread (CV) is above 10 % for both prompts and below the method's limit of 15 %, above which a new measurement is required. Words per second (53.8) is the mean of the two prompts' medians (code prompt 42.6, prose prompt 65.0 words/s), so the figure of 500 words on this page (about 9.3 s) mixes both prompts; at the prose prompt's rate alone, 500 words take about 7.7 s.

Several requests at once. The server has 16 slots, so the levels 1, 2, 4 and 8 at once are all below the slot count and run in parallel. All requests carry the same prompt (the prose prompt), 512 tokens each, two rounds per level. The total is 71.7, 104.9, 149.3 and 201.4 tok/s with 1, 2, 4 and 8 requests, and the speed of each request is 71.7, 55.0, 38.0 and 26.1 tok/s. The level of 16 at once, the server's slot count, was not measured.

Prefill and long prompts. The prefill series uses prompts of exactly 2,048, 8,192 and 32,768 tokens, three runs each (prefill 4,461, 7,238 and 8,355 tok/s); the long-prompt steps use prompts of exactly 16K, 32K, 64K and 128K tokens (a filler log first, the task prompt last), 2 runs each with the code and the prose prompt, 512 reply tokens. Prefill is the prompt tokens divided by the time to first token of the same request; the 128K step needs 16.5 s to the first token. "Prefill at 32K" and the 32K step of the long-prompt table are two different measurements of a prompt of about the same size: the prefill series sends raw token ids with no chat template and 8 reply tokens, three runs (a cold prompt, 8,355 tok/s); the context step is a chat request, a filler log first and the code or the prose task prompt last, with 512 reply tokens, two runs each, median of the four requests (8,085 tok/s). The two numbers are not the same measurement and are not mixed on this page; the context steps are shown only in the long-prompt table. Long answer test: one reply that ended by itself (finish reason stop) after 7,199 tokens in 60.9 s.

Foreign load in run 1. The load guard of the speed test (any other process above 25 % of a core for two samples in a row) threw away and repeated 10 of 38 steps of run 1, each once: the prefill at 32K (run 1), requests at once with 4 (round 1) and 8 (round 2), the long answer, and six long-prompt steps (the 16K code run 1, the 32K prose run 1, the 64K prose run 1, and at 128K the code run 1, the prose run 1 and the code run 2). Every time the kernel thread kcompactd0 (memory compaction) went above the limit (peaks of 48 to 68 % of a core in nine steps and 100 % in the long-answer step); all repeats ran clean and are the values used. We did not isolate the cause; our boxes run 4 KiB pages (point 1 above). A second kind of load was seen in the first seconds of the decode test: the guard's samples show short processes of the boxes' vendor update service on the head box (a firmware query and an update-availability check, up to 54 % of a core in one sample) during code run 1, code run 2 and prose run 1, but not during prose run 2. Code run 1 also had one sample of the container runtime on the head box (containerd 518 % and dockerd 378 % of a core, one sample only). The guard did not act on them, because it needs one process in two samples in a row. The two slow decode runs of run 1 (code run 2 with 70.6 and prose run 1 with 70.9 tok/s) fall into that time, and so does the fast code run 1 (82.1 tok/s), so the load is probably part of the explanation for the low values, not a proven cause. The repetition's decode runs have no such samples. The cache check of the tool found no cached tokens in any of the 61 requests that it checked. Not published: the guard's sample file, the quiet-check tables, the load logs and the single requests of the speed runs.

The repetition. We ran Speed v2 a second time on a new server start (run 1 is the one with the five quality tests and the Thinking test; the repetition has Speed v2 only). It gave: decode 81.5 tok/s (code prompt 86.3, prose prompt 76.8; the code runs 81.1 and 91.4, the prose runs 75.1 and 78.4 tok/s; spread (CV) 8.5 % and 3.1 %), prefill 4,415, 7,253 and 8,358 tok/s at 2K, 8K and 32K, 204.6 tok/s for 8 requests at once, and 7,732 tok/s at 16K, 8,084 at 32K and 8,298 at 64K for the long-prompt steps. The repetition has no value at 128K: its 128K step was stopped by the load guard. The guard threw away the prose run 1 of that step four times (the first try and three repeats; kcompactd0 above 25 % of a core, up to 100 %) and stopped the test there; the code run 1 of that step had been thrown away and repeated 3 times as well, and its last try ran clean. The tool counts a step with fewer valid requests than planned as failed ("decode code 1 of 2 runs valid; decode prose 0 of 2 runs valid; prefill/TTFT 1 of 4 requests valid"), so no decode, prefill or first-token value of the repetition at 128K exists, and the later steps were not run. The guard threw away and repeated 12 of 36 steps of the repetition (18 repeats in all); 17 of the repeats were caused by kcompactd0 and one by the package manager's update check on the head box. All values of the repetition that are shown here are from clean tries. The repetition's raw files are linked at the end of this paragraph; they are not part of the tables (the register rows of the repetition are not shown on this page, so that each measurement has one value here). Raw files of the repetition: speed result · speed contract · log · long answer.

Server start. The server answered after 641 s (run 1) and 656 s (repetition). The weights are read over a network share here (point 3 above). This is not a speed test, and we did not isolate what the start time depends on.

Owen's published numbers

These are the figures Owen published in the spark-ds41f repository for the standard release 1107 on the same shape (four GB10 boxes in a ring, tensor parallel 4). The release was published on 8 Nov 2026, 12:54 UTC and is marked Latest (read on 13 Nov 2026). They are shown as published, with label, date and source, and were not measured by us. Owen's method differs from our speed test (last paragraph), so they are shown for reference and not as a comparison, unless a line says so. Source paths are relative to the repository root at the release commit cc20ed18, except the paths starting with experiments/2026-10-26-spark-ds41f-candidate/candidate-50/, which are relative to the repository root at tag candidate-54.

Release run of 1107, 7 Nov 2026 (servebench 0.1.0, suites release v3 and single-stream v1, closed loops of 300 s after a 60 s warm-up, 256 fixed prompts, 256 output tokens each, temperature 0, thinking off): 82.6 tok/s with 1 stream, 207.4 with 8 streams and 272.9 with 16 streams (total output). Cold prefill on real source text (1 output token, 3 repeats): 8,508 tok/s at 32K, 8,657 at 131K, 8,261 at 262K. With temperature 1.0 and top_p 1.0 (Owen's sampled suite, seed 0): 268.3 tok/s with 16 streams, 203.8 with 8 and 80.0 with 1. Sources: manifests/suites/2026-11-07-spark-ds41f-1107-tp4/c16.json:46, c8.json:46, prefill.json:27, :42, :57; manifests/suites/2026-11-07-spark-ds41f-1107-tp4-single-stream/c1.json:46; manifests/suites/2026-11-07-spark-ds41f-1107-tp4-sampled/{c16,c8,c1}.json:49; README.md lines 354 to 362. Where two of Owen's texts give different figures for the same run (sampled c8 and c1), this page uses the value in the run file.

Reference screen of 1107, 9 Nov 2026, two boots (servebench 0.1.0, suite screen v1; Owen recorded it as the base for later builds): 265.2 and 265.3 tok/s with 16 streams (60 s warm-up, 300 s window, 256 fixed prompts of 15 to 29 tokens, 256 output tokens each, temperature 0, thinking off); cold prefill on real source text (1 output token, 3 repeats) 8,500 and 8,544 tok/s at 32K, 8,228 and 8,268 tok/s at 256K. Sources: experiments/2026-10-26-spark-ds41f-candidate/candidate-50/receipts/references/spark-ds41f-1107-tp4-ring-screen{,-again}/c16.json:46 (output), experiments/2026-10-26-spark-ds41f-candidate/candidate-50/receipts/references/spark-ds41f-1107-tp4-ring-screen{,-again}/prefill.json:27 (32K), :42 (256K).

Owen's own quality figures in the same release text (other test lists and other generators than our Quality v2, so not comparable with it; shown as published): LongBench v2 8/12 (66.67 %), RULER 4K to 256K 26/26 (100.0 %), EvalPlus HumanEval+ 164/164 base (100.0 %) and 156/164 plus (95.1 %), Vision Eval 83.25 % (1900.5/2283), tool-eval-bench 90 to 91/100, on the shapes listed there, tp4-ring among them (source: release-notes.md:50-53). Owen's release text names no MMLU-Pro, GPQA, IFEval or LiveCodeBench figure.

Image: Owen's release text names the image ID sha256:3f32a962ce04b7c8d85337cd427a8946b8b6bcaadd97cc8d8a8cd14e8d68a6ce (source: release-notes.md:12), with the vLLM patch_head 320021e3 recorded at the release commit (the moved tag records 2756478b, see the setup notes above) and the expected tree ed1bdb7a (release-notes.md:9). Owen publishes no registry image; the image of this page was built by us from Owen's recipe (its ID is below in the setup; image IDs differ between Docker stores), and its vLLM tree label equals the expected tree ed1bdb7a.

How these relate to our numbers: our speed test uses two fixed prompts of about 1,200 tokens (code and prose), 512 output tokens, temperature 1.0 and top_p 1.0 (the recipe's generation defaults), thinking off, median of two runs; concurrency starts 1, 2, 4 and 8 identical requests together; prefill and context steps use a synthetic filler text at exact lengths. Owen's servebench uses closed loops over 256 different one-sentence prompts, 256 output tokens, temperature 0, and real source text for prefill. Single stream: our value 76.3 tok/s (run 1) and 81.5 tok/s (repetition), Owen's value 82.6 tok/s, different method, not comparable. Eight streams: our value 201.4 tok/s (run 1) and 204.6 tok/s (repetition), Owen's value 207.4 tok/s, different method, not comparable. Prefill 32K: our value 8,355 tok/s (run 1) and 8,358 tok/s (repetition), Owen's value 8,508 tok/s, different method, not comparable. Prefill 128K: our value 7,964 tok/s (run 1; none in the repetition), Owen's value 8,657 tok/s at 131K, different method, not comparable. Sixteen streams and 262K prefill: not measured by us. Owen's recipe asks for the 64 KiB kernel with the memory saver (releases/spark-ds41f-1107/cluster.json lines 74 to 78) and Owen's documentation says that a healthy GB10 stays near 2,400 MHz in operation (docs/recovery.md line 176); Owen's measurement files do not record kernel or clock. We run the stock kernel and a 2,200 MHz cap (see the deviations above); we did not isolate what part of any difference comes from that.

Compared with candidate-54. Owen's pre-release candidate-54 of the same recipe was run by us on Nov 12, 2026 with the same speed test on the same four boxes and the same card except for the recipe (page of candidate-54). Decode: 76.3 tok/s here in run 1 (81.5 in the repetition) against 84.5 there; prefill at 32K 8,355 against 8,643 tok/s; 8 requests at once 201.4 against 210.0 tok/s; prefill at 128K 7,964 against 8,545 tok/s (the 128K value of candidate-54 comes from a separate server start with one forced deviation, which its page explains). Change from candidate-54 to 1107, in percent from the raw values: decode -9.6 % in run 1 (-3.5 % in the repetition), prefill at 32K -3.3 %, 8 requests at once -4.1 %, prefill at 128K -6.8 %. Decode is not conclusive: our two runs of 1107 gave 76.3 and 81.5 tok/s. Both pages show every number with its raw files.

python3 speed2.py --base-url http://127.0.0.1:40661/v1 --label quality-v2-261113-box-3-ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site-speed-r0 --prompts $BENCH/repos/<speed-test-tool>/prompts-v2.json --output $RUN/quality-v2-261113-box-3-ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site-speed-r0/quality-v2-261113-box-3-ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site-speed-r0/speed2 --contract $RUN/quality-v2-261113-box-3-ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site-speed-r0/quality-v2-261113-box-3-ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site-speed-r0/speed2/speed-contract.json --parts decode,prefill,conc,l1,ctx --prefill-depths 2048,8192,32768 --prompt-ids code,prose --runs 2 --max-tokens 512 --warmups 1 --prefill-runs 3 --conc-levels 1,2,4,8 --conc-rounds 2 --conc-max-tokens 512 --conc-prompt prose --ctx-depths 16384,32768,65536,131072 --ctx-runs 2 --ctx-max-tokens 512 --tokenizer-json $HOME/ds41f-hub/hub/models--deepseek-ai--DeepSeek-V4.1-Flash-1017/snapshots/1bae0e1088993b9b82de08f59de5be5a34e42170/tokenizer.json --tokenizer-python $HOME/not published --sampling {"temperature": 1.0, "top_p": 1.0} --sampling-source releases/spark-ds41f-1107/cluster.json:18-21 generation_defaults (temperature 1.0, top_p 1.0), put on the server by --generation-config vllm --override-generation-config (cluster.json:161-162); equal to the model card; a request's own values win. Speed v2 runs thinking off. --model deepseek-v4.1-flash --no-cache-prompt --server-log $RUN/server-A.log --engine-version-file $RUN/engine-version.txt --server-slots 16 --server-slots-source christopherowen/spark-ds41f@cc20ed18 releases/spark-ds41f-1107/cluster.json shapes.tp4-ring.sizing.max_num_seqs (16) --server-ctx 1048576 --server-ctx-source card GB10 box 3-ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site field ctx

How well it answers

Owen's standard release 1107, run with forced deviations. Six fixed lists with thinking off and one test with thinking on (the last row), raw numbers with their 95 % margins, no overall score. All seven tests ran on one server start, together with the Speed v2 run of run 1 (see the notes below and the Speed section).

Thinking off, except the last test. Seed 42. Sampling from the model card. A cut-off answer counts as wrong. Measured 2026-11-13.

Note from the run: What the numbers are. Only raw numbers with their margins; there is no overall score. Six fixed lists ran with thinking off (MMLU-Pro with 400 questions, GPQA Diamond with 198, IFEval with 200, LiveCodeBench with 40, long-text tests (RULER-lite) at 8K and 32K with 40 each), 16 requests at a time (the recipe's 16 slots), temperature 1.0, top_p 1.0, seed 42. The last test, GPQA with 30 questions, ran with thinking on and is a test of its own: a cap of 16,384 tokens, 16 requests at a time.

Where they ran. All seven tests ran on the same server start as the Speed v2 run of run 1, one after the other (the five instruct tests from 00:35 to 00:52, the Thinking test from 00:52 to 01:01). Every summary file of the five instruct tests reports 0 errors except the long-text one, which has no error counter; the tool finished every part with status ok.

Cut-off answers count as wrong. The two knowledge tests give each answer 48 tokens: 59 of the 400 MMLU-Pro answers and 60 of the 198 GPQA answers (30.3 %) were cut off at that limit and count as wrong, so the GPQA result is strongly shaped by this limit (120 of the 918 requests of the instruct tests were cut off in all, 13.1 %: 59 MMLU-Pro, 60 GPQA and 1 long-text answer, which ended at its limit of 128 tokens; IFEval and LiveCodeBench had none). In the Thinking test, 4 of 30 answers were cut off at the cap of 16,384 tokens and count as wrong; the median answer took 2,182.5 tokens and 100.3 s with 16 requests at a time.

Long-text tests (RULER-lite). Of the 80 prompts, 5 had one token less than the length of the test (8,191 instead of 8,192 tokens in 3 prompts, 32,767 instead of 32,768 in 2 prompts, counted by the local tokenizer on the text; the server adds the chat template on top); the tool marks them in the answer file and counts them as they are. The variable-tracking task (vt) scores 0 of 10 at 8K and 1 of 10 at 32K because the method counts an answer as right only when it is complete, and 18 of the 20 vt answers name only some of the four variables. Owen's own RULER figure is on another list and is not comparable.

Not published: the answer files of MMLU-Pro (mmlupro.jsonl), of IFEval (ifeval.jsonl) and of LiveCodeBench (lcb.jsonl and lcb.gen.jsonl). The publication check of this site holds back a file when an answer text in it matches one of its patterns (a unit in a physics question in MMLU-Pro, a word in an IFEval answer that matches a name pattern, a variable name in the code of a LiveCodeBench solution); the files themselves are unchanged, and the summary files of the three tests are linked in the table. The answer files of GPQA, the long-text tests and the Thinking test are published.

bash tools/quality2/measure_all.sh tools/quality2/cards/ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site.json --parts mmlupro --job quality-v2-261113-box-3-ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site

bash tools/quality2/measure_all.sh tools/quality2/cards/ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site.json --parts gpqa --job quality-v2-261113-box-3-ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site

bash tools/quality2/measure_all.sh tools/quality2/cards/ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site.json --parts ifeval --job quality-v2-261113-box-3-ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site

bash tools/quality2/measure_all.sh tools/quality2/cards/ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site.json --parts lcb --job quality-v2-261113-box-3-ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site

bash tools/quality2/measure_all.sh tools/quality2/cards/ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site.json --parts ruler --job quality-v2-261113-box-3-ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site

bash tools/quality2/measure_all.sh tools/quality2/cards/ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site.json --parts ruler --job quality-v2-261113-box-3-ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site

bash tools/quality2/measure_all.sh tools/quality2/cards/ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site.json --parts think --job quality-v2-261113-box-3-ds1017-owen-1107-native-fp8fp4-tp4-ring-4x-site

Also made this possible

• Model (DeepSeek-V4.1-Flash-1017, revision 1bae0e10)DeepSeek@deepseek_ai Hugging Face GitHub Website
• Engine base pinned by the recipe (vLLM, local-inference-lab fork, base 19f2c20e plus 641 patches, tree ed1bdb7a)Llocal-inference-labGitHub

Exact command

What you need and how to start it, step by step. The results below come from this setup, which differs from Owen's recipe in the ways named in the notes of the Speed section.

What you need

Hardware

4x NVIDIA DGX Spark class boxes (GB10), tensor parallel 4 over a switchless CX7 cable ring (two paths per neighbour, 109.25 to 109.33 Gb/s per path, measured before each of the two server starts): two ASUS Ascent GX10, one Gigabyte AI TOP ATOM (head box, rank 0) and one Lenovo ThinkStation PGX. All four boxes run driver 580.178.04 and the stock kernel 7.0.0-1019-nvidia with 4 KiB pages and no memory saver; GPU clock capped at 2200 MHz

Model

deepseek-ai DeepSeek-V4.1-Flash-1017 (rev 1bae0e10, FP8 block-32 ue8m0 + FP4 routed experts as published) + checkpoint DSpark drafts

Model (DeepSeek-V4.1-Flash-1017, revision 1bae0e10)

huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017

Engine

Owen's standard release spark-ds41f-1107 of the recipe, run on forced deviations from it (see the notes of the Speed section); DeepSeek-V4.1-Flash-1017 with DSpark drafts, vLLM with TileLang kernels, tensor parallel on 4 GB10 boxes in a cable ring; image built by us from Owen's recipe for 1107 — the program that loads the model and answers requests · github.com/local-inference-lab/vllm

Recipe: spark-ds41f, standard release 1107 (tag spark-ds41f-1107, release commit cc20ed18, Nov 7, 2026; release published Nov 8, 2026)

github.com/christopherowen/spark-ds41f by Christopher Owen

Steps

1. Get the recipe, the engine and the model files from the list above. The cluster config named in the next step is ours and is not published.

2. Start the server with this command. It loads the model into memory.

   Copy

   cd <spark-ds41f checkout at the release commit cc20ed18 of tag spark-ds41f-1107 plus our cluster config> && bin/spark \
     --cluster-config <our cluster config> cluster start \
     --replace \
     --apply
   (our cluster config extends releases/spark-ds41f-1107/cluster.json shape tp4-ring; it sets our model path (DeepSeek-V4.1-Flash-1017, revision 1bae0e10), our host home folder, host.fan_control false, the head address, the vLLM patch head 2756478b and our deployment repository, and unsets glp. The tool starts one vLLM process per box: head box = rank 0, then ranks 1 to 3 around the ring; vllm serve <model snapshot> \
     --tensor-parallel-size 4 \
     --nnodes 4 \
     --max-model-len 1048576 \
     --max-num-seqs 16 \
     --max-num-batched-tokens 16384 \
     --speculative-config dspark 5 ... as set by the recipe; image tag spark-ds41f:1107, built by us from Owen's recipe)

vLLM (local-inference-lab fork, base 19f2c20e + 641 patches, tree ed1bdb7a; image built by us from Owen's recipe) + TileLang kernels, TP=4 over 4 nodes (mp backend), DSpark 5 drafts (CopyDrafter), one-shot ring all-reduce (sparknet, NCCL 2.30.7), Engram tables on local NVMe; cd <spark-ds41f checkout at the release commit cc20ed18 of tag spark-ds41f-1107 plus our cluster config> && bin/spark --cluster-config <our cluster config> cluster start --replace --apply
(our cluster config extends releases/spark-ds41f-1107/cluster.json shape tp4-ring; it sets our model path (DeepSeek-V4.1-Flash-1017, revision 1bae0e10), our host home folder, host.fan_control false, the head address, the vLLM patch head 2756478b and our deployment repository, and unsets glp. The tool starts one vLLM process per box: head box = rank 0, then ranks 1 to 3 around the ring; vllm serve <model snapshot> --tensor-parallel-size 4 --nnodes 4 --max-model-len 1048576 --max-num-seqs 16 --max-num-batched-tokens 16384 --speculative-config dspark 5 ... as set by the recipe; image tag spark-ds41f:1107, built by us from Owen's recipe)