<![CDATA[Deepseek v4.1 flash , 4台DGX spark GB10, TP=4]]>V4.1 flash釋出沒多久, DGX論壇上已經有幾個看起來不錯的配方了, 今天選了一個裝起來, 速度很讓人驚豔, 實際品質未知, 等跑了幾天實際任務再update. 實際工作單條工作流約40-60 tok/s, 三條約50-100 tok/s. prefill速度在2500 ~ 3000 tok/s左右, 快取命中約99%.

使用方案: https://github.com/MiaAI-Lab/DeepSeek-v4.1-Flash-DGX-Sparks , 模型為官方原始模型. 用Antigravity cli + gemini flash 3.8 安裝, 過程遇到幾個坑它自行解決, 安裝資訊與測試數據如下:

DeepSeek-V4.1-Flash TP4 部署與測試總結報告 (Summary)

一、 模型與服務基本資訊

  • 模型名稱 (Model Name)：deepseek-ai/DeepSeek-V4.1-Flash
  • 權重版本 (Pinned Revision)：fb2764a5cf321eaa5070ca8f9e892818f477c16d
  • 上游原生路線：MiaAI-Lab TP4 原生路由 (https://github.com/MiaAI-Lab/DeepSeek-v4.1-Flash-DGX-Sparks)
  • 硬體環境：4× NVIDIA DGX Spark (GB10, aarch64, 單節點 121.7 GiB 統一記憶體)
  • 高速網路互連：200G RoCEv2 (rocep1s0f0 / enp1s0f0np0), MTU 9000 (Jumbo Frames), GID Index 3

權重存儲與掛載：完整模型權重（476 GB，48 個 safetensors 分片）存放於 HEAD 本地 NVMe，透過 RoCE 容器化 NFSv4 (dsv41-weights) 共享給 WORKERS 唯讀掛載，各節點無重複複製。

二、 核心規格與配置參數 (Core Specs & Configurations)

核心參數 數值 / 設定 說明
Context Length (ctx size) 1,048,576 (1M tokens) 模型原生完整支援長度；生產實測認證邊界依上游 Proxy 設定為 500K tokens
Max Running Requests (max seq num) 8 支援最大並行請求數，CUDA Graph 完整捕獲 Batch Size 1 ~ 8
KV Cache Pool Size (kv cache size) 4,000,000 (4M tokens) 每 Rank 分配 1,000,000 tokens，100% 完整採納（零 downscaling 降級），FP8
精度
靜態記憶體比例 (Mem Fraction Static) 0.78 (Head: 0.78) 預留 ~94.9 GB 靜態預算，保證 4M KV pool 成功分配，並為各節點留出 18~20 GiB 實體
記憶體空間
分塊預填充尺寸 (Chunked Prefill Size) 2048 tokens 抑制 FP4 indexer attention logits 峰值張量至 2.0 GB，徹底消除超長上下文 OOM
快取釋放頻率 2048 tokens DSV41_PREFILL_EMPTY_CACHE_TOKENS=2048，每分塊預填充後立即主動釋放記憶體片段
推測解碼 (Speculative Decoding) DSpark (Block Size = 5) 草稿模型 DeepseekV4ForCausalLMDSpark 圖融合加速，動態接受率 ~0.44
Engram Offload 本地 NVMe 卸載 Layer 1 與 Layer 14 各 ~24 GiB，96 I/O threads 直讀，完全不佔用主機 RAM 與網路頻寬
多模態視覺 (Vision) 原生支援 (Triton Backend) 支援 3024×588 高解析度影像，標準消耗 1024 視覺 tokens
健康檢查機制 SGLANG_ENABLE_HEALTH_ENDPOINT_GENERATION=0 /health 即時回應 HTTP 200，杜絕長文本 Prefill 期間 dummy generation 造成的假死誤判

三、 驗證與測試數據 (Verification & Benchmark Data)

1. 基礎功能與能力驗證 (Correctness & Advanced Capabilities)

測試項目 輸入條件 輸出結果 / 指標 狀態
算術邏輯 (Arithmetic) 19 + 23 輸出 42，延遲 0.32s 通過 (PASSED)
代碼生成 (Code Generation) 快速逆平方根 (Fast Inverse Square Root) 輸出完整包含 0x5f3759df 與牛頓迭代之代碼，解碼速率 39.2 tok/s 通過 (PASSED)
結構化輸出 (JSON Schema) 巴黎景點資料 Strict JSON Schema 100% 吻合 Schema 定義，延遲 1.19s 通過 (PASSED)
思考切換 (Thinking OFF) 質數判定直接回答 直接回覆 Yes，無思考內容，延遲 0.29s 通過 (PASSED)
深度思考 (Thinking ON) 質數判定逐步推演 產出 1,536 字元之完整數學證明思維鏈，延遲 12.05s 通過 (PASSED)
工具呼叫 (Tool Calling) get_stock_price(NVDA) 正確發起 Tool Call 參數並於次輪整合回傳股價，總延遲 2.21s 通過 (PASSED)
原生視覺 (Multimodal Vision) 3024×588 幾何彩色圖形 精準識別紅圓與藍方之相對位置，消耗 1024 vision tokens，延遲 2.07s 通過 (PASSED)

2. 長上下文階梯壓測 (Long-Context Benchmark)

依據生產反向代理（Proxy）預設上限 500K，測試數據如下：

測試長度 (Tokens) 首字延遲 (TTFT) Prefill 吞吐速率 輸出 Tokens 解碼延遲 解碼速率 總耗時 (Wall Time) 輸出品質 狀態
32K (32,768) 10.02s 3,271.0 tok/s 64 0.95s 67.5 tok/s 14.44s 技術摘要精準連貫 PASSED
128K (131,072) 48.46s 2,704.8 tok/s 64 0.95s 67.5 tok/s 48.94s 技術摘要精準連貫 PASSED
256K (262,144) 87.46s 2,997.3 tok/s 64 1.08s 59.4 tok/s 88.00s 技術摘要精準連貫 PASSED
500K (500,000) 268.94s 1,859.1 tok/s 64 1.10s 58.2 tok/s 269.49s 技術摘要精準連貫 PASSED

記憶體監控結果：在 500K 超長上下文推演期間，各節點 GB10 實體可用記憶體均保持在 18 ~ 20 GiB，Swap 使用量全程維持 0 bytes，無任何 OOM 或快取逐出情況。

3. 高並發壓測 (Concurrency Benchmark C1 → C8)

測試梯級涵蓋 C1 至滿載 C8 並行請求，每請求生成 128 output tokens：

並發等級 成功率 總耗時 (Wall Time) 總生成 Tokens 聚合吞吐速率 平均請求延遲 P50 延遲 P95 延遲 狀態
C1 (1 並行) 1/1 (100%) 3.47s 128 36.9 tok/s 3.47s 3.47s 3.47s PASSED
C2 (2 並行) 2/2 (100%) 5.13s 256 49.9 tok/s 5.05s 5.05s 5.12s PASSED
C4 (4 並行) 4/4 (100%) 6.72s 512 76.2 tok/s 6.45s 6.47s 6.72s PASSED
C6 (6 並行) 6/6 (100%) 8.27s 768 92.8 tok/s 7.59s 7.86s 8.27s PASSED
C8 (8 並行) 8/8 (100%) 10.67s 1024 96.0 tok/s 8.51s 8.50s 10.66s PASSED
  • 全數成功：21/21 個請求全部成功回傳（成功率 100%）。
  • 極速解碼：滿載 8 並發下，聚合輸出速率達到 96.0 tok/s，P50 延遲僅 8.50s。
  • 動態排程：SGLang 與 CUDA Graph 完美覆蓋動態批次，無重新分配與記憶體震盪。
]]>https://lcz.me/topic/1658RSS for NodeSun, 13 Sep 2026 17:39:35 GMTSat, 12 Sep 2026 15:19:03 GMT60<![CDATA[Reply to Deepseek v4.1 flash , 4台DGX spark GB10, TP=4 on Sat, 12 Sep 2026 22:12:05 GMT]]>

@soop-ladios said:

三條約50-100 tok/s. prefill速度在2500 ~ 3000 tok/s左右

要推動這麼大的參數巨獸 真是不容易, 家用 Deepseek v4.1 flash

]]>https://lcz.me/post/17672https://lcz.me/post/17672Sat, 12 Sep 2026 22:12:05 GMT<![CDATA[Reply to Deepseek v4.1 flash , 4台DGX spark GB10, TP=4 on Sat, 12 Sep 2026 16:31:35 GMT]]>@benton-yi
我是沒試過, 不過實際上是可行的 , 可以參考 https://github.com/FujitsuPolycom/sparkring/blob/main/docs/DEEPSEEK_V41_FLASH_QUICKSTART.md
作者已經跑通很多模型, 數據跟接switch相比也不見得慢.
根據作者自述, 多跳一個節點損耗並不大, 每台DGX spark GB10有兩個port, 組四台ring最多也就跳一次, 應該在可接受範圍內.
底下原作者說的:
64 KiB
直接 RDMA DAC 電纜 8.65 µs 節點 ↔ 節點 1
VirtualDiagonalMesh 10.51 µs 節點 ↔ 節點 1 ↔ 節點 2

同樣的數據，從 64 KiB 到 2 MiB，平均每次傳輸延遲增加 1.78 µs。頻寬保持不變，損耗極小。

另外, 這四台我接的是100G的線, 因為現在switch不好買. 如果用200G, CRS804只能接8台, 100G可以接16台. 實際量測各個模型的使用頻寬, 不管是TP=4還是TP=8, 流量很少超過50G. 所以其實買100G的CRS504也是可以的.

]]>https://lcz.me/post/17624https://lcz.me/post/17624Sat, 12 Sep 2026 16:31:35 GMT<![CDATA[Reply to Deepseek v4.1 flash , 4台DGX spark GB10, TP=4 on Sat, 12 Sep 2026 16:03:04 GMT]]>@benton-yi TP4 的核心约束不是"能不能连上"，是 all-reduce 的延迟。transformer 每层、每 token 都要 all-reduce，链路延迟直接乘进 decode。

不用交换机的环（daisy-chain）NCCL 能识别，但 4 节点环上 all-reduce 的通信步数是 2(N-1)=6 跳，延迟明显高于全互联；而且中间任一节点/线缆出问题，整环降速甚至挂掉。CX-7 是 200G 级，带宽不是瓶颈，问题在拓扑跳数和故障域。

建议：

  • 本地验证/学习：环可以跑，先上 nccl-tests 的 all_reduce_perf，量 busbw 和延迟，再决定要不要跑 vLLM。
  • 生产 TP4：上 200G 交换机做全互联，或确认板载双口能两两直连组全互联。
  • 顺便确认 vLLM 的 TP 通信切分和 overlap，长 prompt prefill 最容易被通信拖。

先量延迟，再定拓扑，别先买交换机。

]]>https://lcz.me/post/17617https://lcz.me/post/17617Sat, 12 Sep 2026 16:03:04 GMT<![CDATA[Reply to Deepseek v4.1 flash , 4台DGX spark GB10, TP=4 on Sat, 12 Sep 2026 15:47:35 GMT]]>想了解一下DSV4.1的TP4必须要通过交换机方式组网吗？如果4个节点不使用交换机，采用环形网络拓扑（对面节点无法直接访问）方式可以做到吗？

]]>https://lcz.me/post/17610https://lcz.me/post/17610Sat, 12 Sep 2026 15:47:35 GMT<![CDATA[Reply to Deepseek v4.1 flash , 4台DGX spark GB10, TP=4 on Sat, 12 Sep 2026 15:33:39 GMT]]>这么快就来了， 火钳流明

]]>https://lcz.me/post/17605https://lcz.me/post/17605Sat, 12 Sep 2026 15:33:39 GMT<![CDATA[Reply to Deepseek v4.1 flash , 4台DGX spark GB10, TP=4 on Sat, 12 Sep 2026 15:26:58 GMT]]>好文，謝謝無私分享

]]>https://lcz.me/post/17604https://lcz.me/post/17604Sat, 12 Sep 2026 15:26:58 GMT