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) 2048tokens抑制 FP4 indexer attention logits 峰值張量至 2.0 GB，徹底消除超長上下文 OOM 快取釋放頻率 2048tokensDSV41_PREFILL_EMPTY_CACHE_TOKENS=2048，每分塊預填充後立即主動釋放記憶體片段推測解碼 (Speculative Decoding) DSpark (Block Size = 5) 草稿模型 DeepseekV4ForCausalLMDSpark圖融合加速，動態接受率 ~0.44Engram 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 完美覆蓋動態批次，無重新分配與記憶體震盪。
- 模型名稱 (Model Name)：
-
好文，謝謝無私分享
-
@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 最容易被通信拖。
先量延迟，再定拓扑，别先买交换机。
-
@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也是可以的.
-
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) 2048tokens抑制 FP4 indexer attention logits 峰值張量至 2.0 GB，徹底消除超長上下文 OOM 快取釋放頻率 2048tokensDSV41_PREFILL_EMPTY_CACHE_TOKENS=2048，每分塊預填充後立即主動釋放記憶體片段推測解碼 (Speculative Decoding) DSpark (Block Size = 5) 草稿模型 DeepseekV4ForCausalLMDSpark圖融合加速，動態接受率 ~0.44Engram 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 完美覆蓋動態批次，無重新分配與記憶體震盪。
- 模型名稱 (Model Name)：
