Claude + Local DeepSeek V4 (now 4.1) Flash is all I needed: it coded its own server rack trays, then ported 167k lines of Node to Rust
Claude plus a local DeepSeek V4 Flash is all I needed. It runs on a dual DGX Spark, 60-70 tps, and these are the four things it has built for me so far:
1. DeepSeek coded its own server rack trays. It generated the geometry for the 3D printed trays that hold the two Sparks, power bricks included, from my requirements, inside a React 3D workspace that Claude Code and Antigravity built. My 2 DGX spark has run almost 24x7 in that rack for three days with no thermal issues. STLs on MakerWorld: makerworld.com
2. A Node.js to Rust port, 167k lines. The concurrency model changed completely, from single threaded Node to Tokio, so it was not a mechanical refactor.
3. A Rust port of the claude-agent-acp codebase, 100k+ lines. This is still WIP
4. A KMP mobile app for my open source agent orchestrator, which ran for almost 48 hours continuously.
For anyone with two Sparks, these are the community recipes I run it with (not mine, credit to their authors):
- DeepSeek V4 Flash 0731: native checkpoint weights with an NVFP4 KV cache, 1M context, tensor parallel 2 across both Sparks, DSpark speculative decoding, vLLM. tonyd2wild/DeepSeek-v4-Flash-0731-DSpark-1M-NVFP4-KV-2x-DGX-Spark
- DeepSeek V4.1 Flash 1017 (what I run now): an EXL3 2.9 bpw quant, 1M context, tensor parallel 2 over the dual-rail RDMA link, TensorFold engine with DSpark drafting. MiaAI-Lab/DeepSeek-v4.1-Flash-1017-2x-DGX-Sparks
All of it goes through one SDLC skill: Sonnet writes the plan, Opus reviews it, and Sonnet then fires a DeepSeek subagent for every phase of every plan, turn by turn. I wrote the skill and the orchestrator that coordinates it in the web-ui, and both are open source: skill fastestdevalive/vibekit and orchestrator fastestdevalive/vibe-station -> mobile app coming soon.
I'd like to know if anyone else runs it as a worker under a stronger planner and compare some notes on the SDLC skill.
38 points · 8 comments
One DGX Spark, four ways to serve Qwen3.8-Flash-Next: quality is close, speed, memory and structured output are not
I served Qwen3.8-Flash-Next four different ways on one DGX Spark (GB10, 121 GB unified memory), one server at a time, and ran every recipe through the same benchmarks. Each ran on its own defaults with a 262,144-token window, thinking off and temperature 0.
The four recipes
- My recipe, fast (default): vLLM with b12x kernels, NVIDIA's NVFP4 FP4-Local checkpoint, FP8 KV cache, MTP 3
- My recipe, quality (opt-in): same, plus a second FP4 term for the prefill rounding residual and BF16 activations in the dense layers
- hibrid48 by myllmbox: vLLM, Marlin W4A16 MoE kernels, its own NVFP4 weights, BF16 KV cache, MTP up to 7
- TensorFold by MiaAI-Lab: native Zig engine, same NVIDIA FP4-Local checkpoint as mine, FP8 KV cache, MTP drafts
Benchmarks: tool-eval-bench 2.8.1 (97 scenarios, two full runs per recipe), sixcat-eval 0.8.3 (884 items), perplexity on fresh 2026 texts, and llm_context_benchmarks from 0.5k to 128k tokens.
Quality: close
- My recipe scored highest on tool-eval, sixcat and perplexity, but the margins are within run-to-run noise. Top scores: 90 on tool-eval, 92.1 on sixcat.
- The three vLLM recipes land within 2 points on tool-eval, and a single recipe's two runs differed by up to 4 (hibrid48: 86, then 90).
- sixcat Tools category: hibrid48 70, the others 85-90, which pulls its overall down to 87.8.
- Perplexity on fresh 2026 texts: fast 2.205, quality 2.227, hibrid48 2.247. TensorFold's server refuses logprobs, so no number for it.
Speed (single stream, geometric means)
- Decode: hibrid48 54.3 t/s, TensorFold 51.6, fast 45.8, quality 44.4
- Prefill: hibrid48 1,936 t/s, TensorFold 1,858, fast 1,717, quality 1,362
- TTFT on a 128k prose prompt: hibrid48 60.2 s, TensorFold 63.9 s, fast 65.5 s, quality 86.0 s
- Every recipe stays above 38 t/s even at 128k
Memory and concurrency (as shipped)
- Mine: 1,365,333 tokens of FP8 KV, cap of 5, so five full 262k windows. Five prompts of 246k-253k each generating 3,000 tokens decoded together with no preemption.
- hibrid48: 877k tokens (BF16 KV), cap of 16, so about 16 requests at ~54k or 3 at 262k.
- TensorFold: about 1.57M tokens of FP8 KV, cap of 5.
- Mine with PROFILE=kv-max: 1.72M tokens, cap of 6, the largest pool of the four.
- Concurrent load test: hibrid48 delivers the most total output at every load (82 t/s with 16 requests of 8k vs 51 for mine), then TensorFold, then mine.
The precision setting that doesn't pay: quality halves token-level error against full precision (mean |Δ logprob| 0.020 vs 0.039, top-1 agreement 99.23% vs 98.59%), but scores tool-eval 90 vs 89 and sixcat 91.7 vs 92.1, and a 128k prompt waits 86 s instead of 66 s. So fast is the default.
The surprise: TensorFold and structured output. Its engine returns HTTP 400 on any request with response_format. Same weights as mine, but 6/12 on Structured Output vs 10/12 for every vLLM recipe, so the gap is the engine, not the weights. I opened a PR that adds structured output to TensorFold's engine: Qwen3.8-Flash-Next-Single-DGX-Spark-TensorFold#69
Which one to run
- Several long requests at once, with structured output: my recipe, fast
- Fastest single stream or many short requests: hibrid48
- A light native engine without vLLM: TensorFold, unless you depend on response_format
- Maximum fidelity to full precision: my recipe with PRECISION=quality
Full write-up with all charts: alfonsofortunato.com
My recipe: devopsfortunato/Qwen3.8-Flash-Next-FP4-Local-DGX-Spark
Credits: myllmbox (hibrid48) and MiaAI-Lab (TensorFold) for their recipes, eugr for the b12x container, Tim Messerschmidt for tool-eval-bench, vcruz305 for sixcat-eval and Ivan Fioravanti for llm_context_benchmarks.
Happy to rerun anything if you think a setting is unfair to one of the recipes.
8 points · 14 comments
Mentions
これやっていきたいけど、ストレージが足りない... github.com/MiaAI-Lab/DeepSeek-v4.1-Flash-1017-2x-…
If you've had issues with your DGX Sparks overheating/crashing I highly recommend this repo. It limits clockspeeds which barely effects your throughput 1-2% but saves so many headaches. I have this applied to all 4 of my sparks, makes travel easier. MiaAI-Lab/sparkLimiter
【DGX Spark】1台でQwen3.8-Flash-Nextを実用速度で動かす — FP4 QAD + TensorFold + 17パッチ > 前シリーズ（構築編／不安定化の切り分け編／3モデル比較編／Flash-Next格闘編／27B改良編）の続編です。 > 1台の DGX Spark（GB10, 128GB ユニファイドメモリ）で Qwen3.8-Flash-Next（以下FN） を常用するまでを、 > メモリの壁・エンジンの選定・最終構成の実測までまとめます。 > 数値は手元1台の実測です。IP・ホスト名・認証情報はプレースホルダに置き換えています。 --- TL;DR - 以前は「FNは1台ではメモリがカツカツで、prefillも遅い」ため27Bに妥協していた。 - 2026年10月の TensorFold 1.1.4〜1.1.6 と Mia AI LabのFP4 QADレシピで状況が変わった。 - 最終構成は nvidia/Qwen3.8-Flash-Next-FP4-Local（QAD、96GiB）+ TensorFold 1.1.4 + 17パッチ。 - 実測: prefill 32k=12.5秒、decode 45〜49 tok/s、5並行で119.8 tok/s（prose）。 - 27B（1.1.6）比で prefillが2.0〜2.6倍速く、長文decodeも+20〜38%。品質も上（DeepSWE 58.7 vs 42.2）。 - メモリは85GB使用／35GB空き。ただし並行は5本まで（27Bは8本）。 --- 1. なぜFNに戻したのか 前回（Flash-Next格闘編）は、FNの品質（DeepSWE 58.7 / JobBench 55.7）に魅力を感じつつも、次の理由で27Bに妥協しました。 | 当時の課題 | 内容 | |---|---| | メモリ | 0.6.6で起動見積84.26GiB。--ple-on-ssd必須で、残りが24GBしかない | | prefill | 80kで54秒（27Bは43秒）。長文セッションで体感が悪い | | 速度 | 思考ONで46〜48 tok/s（27Bと同等） | その後、次の3つが変わりました。 1. TensorFold 1.1.4 で27Bのcold prefillが最大5倍改善（後述の別記事） 2. 1.1.6 で同時リクエストのprefillを共有（8チャット×28kで201秒→31秒） 3. Mia AI Lab が1台のSpark向けレシピ（FP4 QAD + 17パッチ）を公開 特に3つ目が大きく、FNが1台で実用速度になりました。 --- 2. メモリの壁：n-gramテーブルをどう逃がすか FNの重みは、言語モデル125B（4bitで約62GB）に加えて n-gram埋め込み51B（約26.8GiB） とMTP 4Bを持ちます。合計は約113GB（MLX 4bit）で、128GBのSparkにはぎりぎりです。 | 方式 | 重みの扱い | 実測使用量 | |---|---|---| | TensorFold 0.6.6（--ple-on-ssd） | n-gramをSSDへ退避 | 84GB（残り24GB） | | TensorFold 1.1.6（素） | n-gramをmmapで参照 | 81GB（残り40GB） | | Miaレシピ（FP4 QAD） | n-gramをpreadで読み出し | 85GB（残り35GB） | ポイントは n-gramテーブルをGPUメモリに載せないことです。どの方式も、n-gramはファイルから都度読みます（ページキャッシュ／pread）。 tensorfold plan の見積もりに注意 1.1.6には tensorfold plan があり、起動前にメモリ要件を表示できます。 memory 122 GiB, 30 GiB available, 4.0 GiB reserved weights 105.4 GiB the model and one prompt chunk need about 109.4 GiB does not fit 105.4GiBはディスク上のサイズで、実際にアップロードするのは76.4GiB（n-gramはmmap）です。planは保守的なので、そのまま信じると「載らない」と誤判定します。 --- 3. Mia AI Labのレシピ MiaAI-Lab/Qwen3.8-Flash-Next-Single-DGX-Spark-TensorFold は、TensorFold 1.1.4に17個のパッチを当て、NVIDIAの量子化意識蒸留（QAD）FP4チェックポイントを1台のSparkで動かすレシピです。 | 項目 | 内容 | |---|---| | エンジン | TensorFold 1.1.4（commit eab8582）+ 17パッチ | | チェックポイント | nvidia/Qwen3.8-Flash-Next-FP4-Local（約96GiB） | | 量子化 | routed experts = NVFP4（group 16）、attention/shared = MXFP8、n-gram = FP8 | | 実行 | Docker（NVIDIA PyTorch 26.07） | | 並行 | 5リクエスト | | KV | fp8（4.37GiB/262k/stream） | QADの品質 NVIDIAがbf16を教師としてNVFP4/MXFP8を学習したチェックポイントで、bf16に近い品質とされます（GPQA 91.5 vs 92.2、ToolEvalBench 88.7 vs 89.4。モデルカードの値）。 主なパッチ | パッチ | 内容 | |---|---| | 0003/0005 | --kv-cache fp8（5ウィンドウが収まる）、fp8 attention reader | | 0004/0006/0014/0015 | プロンプトのタイル最適化（128x128 MXFP8、3,072行チャンク） | | 0010/0013 | n-gramをpread＋先読みで読む（mmapのページフォルトを回避） | | 0012 | 部分的に棄却されたドラフト窓でDeltaNetを再実行しない | | 0016 | 共有エキスパートを別ストリームで、DeltaNetを3起動に | | 0017 | ドラフトチェーンの停止規則（確率の積） | --- 4. セットアップ git clone https://github.com/MiaAI-Lab/Qwen3.8-Flash-Next-Single-DGX-Spark-TensorFold.git cd Qwen3.8-Flash-Next-Single-DGX-Spark-TensorFold ./start.sh 初回は次を実行します（数十分〜1時間）。 1. Dockerイメージのビルド（TensorFold 1.1.4 + 17パッチ、Zig 0.17.0） 2. チェックポイントのダウンロード（約96GiB） 3. 起動＋スモークテスト > Dockerグループに属していない場合は sudo ./start.sh で実行します（sudoがパスワードを要求するので、非対話なら echo 'パスワード' | sudo -S ./start.sh）。 --- 5. 実測 prefill（cold、TTFT） | 長さ | FN（FP4 QAD） | 27B（TensorFold 1.1.6） | 改善 | |---|---|---|---| | 9k | 3.7秒 | 7.3秒 | 2.0倍 | | 32k | 12.5秒 | 28.1秒 | 2.2倍 | | 64k | 25.5秒 | 63.4秒 | 2.5倍 | | 80k | 32.3秒 | 83.4秒 | 2.6倍 | decode | 長さ | FN | 27B | 差 | |---|---|---|---| | 9k | 46.7 | 48.8 | 同等 | | 32k | 45.2 | 42.2 | +7% | | 64k | 48.5 | 40.3 | +20% | | 80k | 44.7 | 32.5 | +38% | 長文ほどFNが有利です。QSA（Qwen Sparse Attention）が2,048トークン単位のブロックで注意を絞るため、KVの読み出しが増えにくいのが効いています。 並行スループット（prose、temp 0.7、思考ON） | 並行 | 集計 | 1本あたり | |---|---|---| | 1 | 48.5 tok/s | 48.5 | | 2 | 73.2 | 38.0/36.6 | | 4 | 108.1 | 29.5/27.4/27.2/27.0 | | 5 | 119.8 | 26.2/25.3/25.0/24.3/24.0 | code（temp 0、思考OFF）は1本74.7、5本172.5 tok/sでした。 公開レシピの公称値との差 Miaの公称は prose 1本55.6／5本156.1、code 1本110.5でした。手元では prose 48.5／119.8、code 74.7と低めです。プロンプトの長さやfixtureが違うため、単純比較はできません。 --- 6. 27Bとどちらを選ぶか | 観点 | FN | 27B | |---|---|---| | prefill（長文） | 2.0〜2.6倍速い | — | | decode（長文） | +20〜38% | — | | 単発の快適さ | +78%（48.5 vs 27.3） | — | | 品質（DeepSWE） | 58.7 | 42.2 | | 同時利用 | 5本まで | 8本 | | 起動 | 155秒 | 62秒 | | 実質空き | 35GB | 30GB | 1〜5人ならFN、6人以上を同時に捌くなら27Bが結論です。 --- 7. 運用 | 操作 | コマンド | |---|---| | 再起動 | ./start.sh restart | | 停止 | ./stop.sh | | ログ | docker logs -f qwen38-flash-next-tf | | モデル一覧 | curl http://<DGX>:8888/v1/models | opencodeなどのクライアントは base_url = "http://<DGX>:8888/v1"、モデルID Qwen3.8-Flash-Next で接続できます。エイリアスを追加すれば既存のモデルIDを維持できます。 ./start.sh restart --alias qwen3.8-27b-fast --alias qwen3.8-27b-think 注意点 - DLと推論は並行させない: チェックポイントのダウンロード中はディスクI/Oが競合し、TTFTが40〜50秒まで悪化します（実測） - 起動に155秒かかる（calibrationを含む） - メモリの余裕は35GB。長文セッションを5本同時に走らせると逼迫する - visionを使わない場合は VISION=0 で2GiBをKVプールに戻せる --- まとめ 1. 1台のDGX SparkでFNが実用速度になった（prefill 32k=12.5秒、decode 45〜49 tok/s、5並行119.8 tok/s） 2. 鍵は n-gramをGPUに載せないことと、FP4 QAD + プロンプト最適化パッチ 3. 27B比でprefill 2.0〜2.6倍、長文decode +20〜38%、品質も上 4. ただし並行は5本まで。6人以上なら27Bか2台構成 5. DLと推論を並行させると性能が落ちるので、セットアップは計画的に > 数値は筆者環境（DGX Spark 1台、ドライバ580.178.04、CUDA 13.0）での実測です。チェックポイント・パッチ・負荷で変動します。
It's 100% worth capping the DGX Sparks. Almost no performance hit, but WAY cooler temps. All of my sparks are capped at 2200. You can use sparkLimiter or sparkDash to easily do it. MiaAI-Lab/sparkLimiter MiaAI-Lab/sparkDash
Claude + Local DeepSeek V4 (now 4.1) Flash is all I needed: it coded its own server rack trays, then ported 167k lines of Node to Rust Claude plus a local DeepSeek V4 Flash is all I needed. It runs on a dual DGX Spark, 60-70 tps, and these are the four things it has built for me so far: 1. DeepSeek coded its own server rack trays. It generated the geometry for the 3D printed trays that hold the two Sparks, power bricks included, from my requirements, inside a React 3D workspace that Claude Code and Antigravity built. My 2 DGX spark has run almost 24x7 in that rack for three days with no thermal issues. STLs on MakerWorld: makerworld.com 2. A Node.js to Rust port, 167k lines. The concurrency model changed completely, from single threaded Node to Tokio, so it was not a mechanical refactor. 3. A Rust port of the claude-agent-acp codebase, 100k+ lines. This is still WIP 4. A KMP mobile app for my open source agent orchestrator, which ran for almost 48 hours continuously. For anyone with two Sparks, these are the community recipes I run it with (not mine, credit to their authors): - DeepSeek V4 Flash 0731: native checkpoint weights with an NVFP4 KV cache, 1M context, tensor parallel 2 across both Sparks, DSpark speculative decoding, vLLM. tonyd2wild/DeepSeek-v4-Flash-0731-DSpark-1M-NVFP4-KV-2x-DGX-Spark - DeepSeek V4.1 Flash 1017 (what I run now): an EXL3 2.9 bpw quant, 1M context, tensor parallel 2 over the dual-rail RDMA link, TensorFold engine with DSpark drafting. MiaAI-Lab/DeepSeek-v4.1-Flash-1017-2x-DGX-Sparks All of it goes through one SDLC skill: Sonnet writes the plan, Opus reviews it, and Sonnet then fires a DeepSeek subagent for every phase of every plan, turn by turn. I wrote the skill and the orchestrator that coordinates it in the web-ui, and both are open source: skill fastestdevalive/vibekit and orchestrator fastestdevalive/vibe-station -> mobile app coming soon. I'd like to know if anyone else runs it as a worker under a stronger planner and compare some notes on the SDLC skill.
なんか諸々詰まりまくったけど何とか構築できた。使っていきます [MiaAI-Lab/DeepSeek-v4.1-Flash-1017-2x-DGX-Sparks: DeepSeek-V4.1-Flash-1017 EXL3 on 2x DGX Sparks with TensorFold](MiaAI-Lab/DeepSeek-v4.1-Flash-1017-2x-DGX-Sparks)
うーん、このレシピ、 Disk が 500 GB 近く必要なのか...。ディスク空けるの大変だぁ... [MiaAI-Lab/DeepSeek-v4.1-Flash-1017-2x-DGX-Sparks: DeepSeek-V4.1-Flash-1017 EXL3 on 2x DGX Sparks with TensorFold](MiaAI-Lab/DeepSeek-v4.1-Flash-1017-2x-DGX-Sparks)
DeepSeek V4.1 Flash 1017 on 2x DGX Sparks Frontier at home. No limits. 100% Private. MiaAI-Lab/DeepSeek-v4.1-Flash-1017-2x-DGX-Sparks
Well, that was fast! ⚡️ DeepSeek V4.1 Flash 1017 for 2x DGX Sparks has been Abliterated! Thanks @u1tra_instinct ! - Simple ABLIT=0/1 flag. - Same repo/quant. Get it here: MiaAI-Lab/DeepSeek-v4.1-Flash-1017-2x-DGX-Sparks
One DGX Spark, four ways to serve Qwen3.8-Flash-Next: quality is close, speed, memory and structured output are not I served Qwen3.8-Flash-Next four different ways on one DGX Spark (GB10, 121 GB unified memory), one server at a time, and ran every recipe through the same benchmarks. Each ran on its own defaults with a 262,144-token window, thinking off and temperature 0. The four recipes - My recipe, fast (default): vLLM with b12x kernels, NVIDIA's NVFP4 FP4-Local checkpoint, FP8 KV cache, MTP 3 - My recipe, quality (opt-in): same, plus a second FP4 term for the prefill rounding residual and BF16 activations in the dense layers - hibrid48 by myllmbox: vLLM, Marlin W4A16 MoE kernels, its own NVFP4 weights, BF16 KV cache, MTP up to 7 - TensorFold by MiaAI-Lab: native Zig engine, same NVIDIA FP4-Local checkpoint as mine, FP8 KV cache, MTP drafts Benchmarks: tool-eval-bench 2.8.1 (97 scenarios, two full runs per recipe), sixcat-eval 0.8.3 (884 items), perplexity on fresh 2026 texts, and llm_context_benchmarks from 0.5k to 128k tokens. Quality: close - My recipe scored highest on tool-eval, sixcat and perplexity, but the margins are within run-to-run noise. Top scores: 90 on tool-eval, 92.1 on sixcat. - The three vLLM recipes land within 2 points on tool-eval, and a single recipe's two runs differed by up to 4 (hibrid48: 86, then 90). - sixcat Tools category: hibrid48 70, the others 85-90, which pulls its overall down to 87.8. - Perplexity on fresh 2026 texts: fast 2.205, quality 2.227, hibrid48 2.247. TensorFold's server refuses logprobs, so no number for it. Speed (single stream, geometric means) - Decode: hibrid48 54.3 t/s, TensorFold 51.6, fast 45.8, quality 44.4 - Prefill: hibrid48 1,936 t/s, TensorFold 1,858, fast 1,717, quality 1,362 - TTFT on a 128k prose prompt: hibrid48 60.2 s, TensorFold 63.9 s, fast 65.5 s, quality 86.0 s - Every recipe stays above 38 t/s even at 128k Memory and concurrency (as shipped) - Mine: 1,365,333 tokens of FP8 KV, cap of 5, so five full 262k windows. Five prompts of 246k-253k each generating 3,000 tokens decoded together with no preemption. - hibrid48: 877k tokens (BF16 KV), cap of 16, so about 16 requests at ~54k or 3 at 262k. - TensorFold: about 1.57M tokens of FP8 KV, cap of 5. - Mine with PROFILE=kv-max: 1.72M tokens, cap of 6, the largest pool of the four. - Concurrent load test: hibrid48 delivers the most total output at every load (82 t/s with 16 requests of 8k vs 51 for mine), then TensorFold, then mine. The precision setting that doesn't pay: quality halves token-level error against full precision (mean |Δ logprob| 0.020 vs 0.039, top-1 agreement 99.23% vs 98.59%), but scores tool-eval 90 vs 89 and sixcat 91.7 vs 92.1, and a 128k prompt waits 86 s instead of 66 s. So fast is the default. The surprise: TensorFold and structured output. Its engine returns HTTP 400 on any request with response_format. Same weights as mine, but 6/12 on Structured Output vs 10/12 for every vLLM recipe, so the gap is the engine, not the weights. I opened a PR that adds structured output to TensorFold's engine: Qwen3.8-Flash-Next-Single-DGX-Spark-TensorFold#69 Which one to run - Several long requests at once, with structured output: my recipe, fast - Fastest single stream or many short requests: hibrid48 - A light native engine without vLLM: TensorFold, unless you depend on response_format - Maximum fidelity to full precision: my recipe with PRECISION=quality Full write-up with all charts: alfonsofortunato.com My recipe: devopsfortunato/Qwen3.8-Flash-Next-FP4-Local-DGX-Spark Credits: myllmbox (hibrid48) and MiaAI-Lab (TensorFold) for their recipes, eugr for the b12x container, Tim Messerschmidt for tool-eval-bench, vcruz305 for sixcat-eval and Ivan Fioravanti for llm_context_benchmarks. Happy to rerun anything if you think a setting is unfair to one of the recipes.