@terry 機器太吵, 已經被我關進lab小房間, 不太容易拍照. 補一張四卡nvidia-smi圖

最近又入手了一組雙卡V100 32G 擴展塢, 帶NVLINK, 用PEX8749 PCIe Switch接到PC. 這台PC原本有兩張V100 32G無NVLINK PCIE, 把它插在一起組成4卡128G, 兩張無nvlink, 兩張有nvlink的奇怪組合. 128G目前能裝的大概只有qwen 3.8 flash next, 於是就動手把它裝起來, 步驟如下:

1. 打開chatgpt web, 讓他去找目前網路上的最佳組合, 然後出個prompt給我
2. 用Antigravity cli + gemini 3.8 flash照prompt安裝, 約三小時裝好, 無須介入
3. 叫gemini寫報告, 給chatgpt看. chatgpt提出一些調整建議與測試驗證
4. Gemini又花了約兩小時做完, 結論是不用調, 測試全數通過, 一樣無須介入
   以下是最終報告:

一、目前模型與服務核心配置 (Production Baseline)

1. 核心模型參數

參數名稱	數值 / 設定	備註說明
Model API ID	qwen-3.8-flash-next	OpenAI 相容調用模型名稱
Base Checkpoint	RadixArk/Qwen3.8-Flash-Next-NVFP4	官方原版非 abliterated 量化權重（commit 7b71922）
模型權重總量	~125.9 GiB（206 safetensors shards）	存放於 /opt/llm-qwen3.8-flash-next/models/
Context Size (ctx size)	200,000 tokens (200K)	--max-model-len 200000（實測驗證穩定上限）
Max Sequence Num	4	--max-num-seqs 4
Max Batched Tokens	4,096	--max-num-batched-tokens 4096（嚴格 A/B 評測勝出者）
GPU 利用率上限	0.92 (92%)	--gpu-memory-utilization 0.92
Parallelism	TP=4, PP=1	跨 4 張 V100 進行張量平行，流水線平行設為 1
MTP / 投機解碼	關閉 (OFF)	實測證實 MTP k=1 吞吐倒退 14% 且破壞 200K 容量規範
通訊優化	--disable-custom-all-reduce	關閉 PCIe 自訂算子，依賴 PyNCCL 混合 NVLink/PCIe 環

2. KV Cache 與顯存資源配置

項目	數值 / 配置	詳細說明
KV Cache Dtype	FP16 (float16)	SM70 專屬原生浮點精度，無量化損耗
單卡可用 KV Cache	6.48 GiB / 卡	TP4 總計 25.92 GiB 專供 KV 快取
GPU KV Cache 總容量	513,207 tokens	充裕空間保障高並發與長上下文
200K 最大並行度	2.57×	滿載 200K 上下文下保障 2.57 條並發（滿足 $\ge 2.0\times$ 生產硬指標）
Block Size	784 tokens	--mamba-cache-mode align 自動對齊 Mamba 狀態頁
Prefix Caching	啟用 (ON)	提示詞命中後 TTFT 提升達 4.0× ~ 14.7×
PLE / N-gram Offload	45.7 GiB 釘選於主機 RAM	VLLM_PLE_CPU_OFFLOAD=1，釋放 ~46 GB GPU 顯存
靜態顯存佔用	~30,500 MiB / 32,768 MiB (93%)	每張卡預留約 2.26 GiB 安全餘裕，無 OOM 風險

---

二、執行的驗證項目與結果

1. API 功能與正確性測試（8/8 全數通過）

• 模型枚舉 (/v1/models)：正確枚舉 qwen-3.8-flash-next。
• 基本問答 (Non-streaming)：基礎問答正常，耗時 < 1s。
• 串流輸出 (Streaming)：SSE 逐 Token 平滑輸出。
• 程式碼生成 (Coding)：生成正確的 Python Fibonacci 迴圈實作。
• 多步驟推理 (Reasoning)：清晰輸出多步驟思考鏈（CoT）。
• 工具呼叫 (Tool / Function Calling)：精準解析 get_weather(location="Tokyo")。
• 結構化輸出 (Structured JSON)：輸出符合 Schema 的 3 筆 JSON 資料並成功解析。
• 長文本檢索 (Long Context 2K)：於 2,022 tokens 上下文中正確檢索目標並總結。

2. Prefix Caching 驗證

• 重播一致性：Cold 與 Warm 輸出為 100% 精確相符 (Exact Match)。
• 1.8K 前綴：TTFT 從 1.210s 降低至 0.302s，達到 4.01× 加速。
• 7.5K 前綴：TTFT 從 6.828s 降低至 0.464s，達到 14.71× 加速。

---

三、各項基準測試數據摘要 (Phase 2 Benchmarks)

所有評測均使用模型專屬 Tokenizer 校準實際 tokens，每項測試重複 3 輪取中位數（Median）：

1. Prefill 效能 (PP 8K ~ 190K tokens)

Flash-Next 混合線性注意力架構展現線性擴展性，Prefill 速度恆定維持在 ~1,810–1,890 tok/s：

測試情境	實際 Prompt Tokens	首字延遲 (TTFT)	Prefill 速度	峰值顯存佔用
PP 8K	8,019	4.311 s	1,860.0 tok/s	31,248 MiB
PP 32K	32,019	16.953 s	1,888.7 tok/s	31,248 MiB
PP 64K	64,019	33.960 s	1,885.1 tok/s	31,248 MiB
PP 128K	128,019	69.259 s	1,848.4 tok/s	31,248 MiB
PP 190K	190,019	104.796 s	1,813.2 tok/s	31,248 MiB

2. Decode 效能 (短長上下文解碼)

單序列解碼速度極為平穩，190K 極長上下文下僅微幅下降 9.2%：

上下文長度	輸出長度	解碼速度	平均 ITL (單字延遲)	TTFT
2K (短文本)	128 tokens	57.46 tok/s	17.40 ms	1.100 s
2K (短文本)	512 tokens	57.33 tok/s	17.44 ms	1.103 s
32K (中長文本)	128 tokens	56.95 tok/s	17.56 ms	16.830 s
128K (長文本)	128 tokens	54.06 tok/s	18.82 ms	68.924 s
190K (極長文本)	128 tokens	52.17 tok/s	19.64 ms	104.411 s

3. Concurrency 平行並發壓測 (~2K Prompt, 512 Output)

導入 threading.Barrier 同步屏障與獨立 Session 修復假性排隊後，並發擴展恢復正常：

並發數 (C)	總體吞吐量 (Aggregate)	單請求平均速度	P50 TTFT	P50 ITL	說明
C = 1	50.46 tok/s	57.42 tok/s	1.120 s	17.38 ms	基準單序列
C = 2	63.86 tok/s (+26.6%)	37.31 tok/s	1.978 s	25.86 ms	正常超越 C1（C2 異常徹底修復）
C = 4	93.67 tok/s (+85.6%)	34.25 tok/s	4.014 s	28.53 ms	達到 TP4 伺服極限吞吐

4. 混合負載干擾 (Mixed Prefill/Decode Interference)

• Test A (32K decode + 64K prefill)：
  • 解碼中動態注入 64K 預填，Req B 預填耗時 55.59s (1,151.6 tok/s)。
  • Req A 解碼受到突發干擾時之最大單字停頓（Max Stall）：2,615.4 ms。
• Test B (128K decode + 64K prefill)：
  • Req B 預填耗時 77.24s (828.8 tok/s)。
  • 由於 128K 解碼在 64K 預填中途即提早完成，未出現額外卡頓。

---

跑llama-benchy測試:

實際測試心得: 速度很快, 比單DGX spark快很多, 剛雙DGX spark插不多. 品質方面RadixArk的NVFP4是優於兩組DGX spark( Local-Lab NVFP4/NVIDIA NVFP4) , chatgpt說的, 還沒長時間實測.
Qwen 3.8 flash next我在DGX spark上面用了一段時間了, 同時單台跟兩台都有在用, 同時也在使用glm 5.3 flash跟Deepseek v4.1 flash. 就我的心得而言, Qwen 3.8 flash next是超越Deepseek的.
以下同時提供兩個DGX spark的llama-benchy測試數據:
單DGX spark:

雙DGX spark:

雙DGX spark經過修復後實際工作使用可以跑約50~70, 單DGX spark約3X, 4xV100 32G跑了一陣約5x-6x.

橫向對比另外一組雙v100 32G x 2 nvlink的 雙卡擴展塢, 跑Qwen 3.8 27B Q8, 速度約4x-5x, 數據如下:

不過能力上27B相較之下還是稍弱了, prefill也略低.

30多也是我實際使用觀察的, 我是覺得如果品質沒感受到差異的話, 能快一點當然是快一點比較好. 用到"忍"這個字就表示並不滿意, 反正叫agent去裝也不過就耗些tokens, 如果不行再回退就好了.
再來我有空會去裝那個60~70 tok/s的版本, 如果能用, 就賺到了.

我裝的是這個配方https://github.com/blazux/qwen3.8-Flash-DGX
實際跑單流decode大概30多, prefill大概1000多, KV有800多K, 數據如下:

另外這個速度更快: https://github.com/azampatti/Qwen3.8-Flash-Next-Int4-FAST/tree/main
DGX社群評價品質好像也不差, 我是沒有裝來試過

@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)	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 完美覆蓋動態批次，無重新分配與記憶體震盪。

---

論壇大神發布了一個單spark的配方,速度很快, 跟大家分享一下.
出處: Up to 70tok/s Qwen3.8-Flash-Next-Int4-AutoRound

我在一台GB10上跑了一陣, 的確比我原本的雙GB10跑Qwen 3.8 flash next 快, 跑長鏈任務品質跟雙GB10沒有明顯區別. 不過prefill還是雙GB10快上一大截, KV poll兩台GB10也是多了超過一倍. 就看怎麼取捨了.

上述單台GB10配方測試數據如下, 實際跑會比這個快一些:

相關資訊如下:

Model

項目	值
HF repo	azampatti/Qwen3.8-Flash-Next-125B-A5B-INT4-AutoRound
Base	Intel/Qwen3.8-Flash-Next-W4A16-AutoRound(原始 Qwen3.8-Flash-Next,作者把 routed experts 由 10 砍到 5 並 healing)
量化	INT4(AutoRound, W4A16)
參數	125B 總 / 4.8B active / token(原版 6B);vocab 248,320、hidden 2,560、48 layers、512 experts、top-k 5
架構(vLLM)	Qwen4ExpForConditionalGeneration;layer pattern 每 4 層一個 full-attention、其餘 linear-attention(Δ-net)+ sparse-attention indexer + PLE n-gram table
license	qwen(原始 Qwen 授權)
硬體目標	1× DGX Spark(GB10, 128 GB unified)
設定	值	來源
max_model_len (CTX)	262,144(256K)	--max-model-len
KV cache pool	--kv-cache-memory-bytes 20g → vLLM reserved 18.63 GiB / 644,732 tokens;滿 ctx 單 request 可並行 2.46×(實測報告)	--kv-cache-memory-bytes
max-num-seqs	8(同時最多 8 條 request)	--max-num-seqs
gpu-memory-utilization	0.01(配合 kv-cache-memory-bytes 手動控 KV,不走 util 估算)
KV dtype	auto(預設;若改 KV_DTYPE=fp8_e4m3 可擴到約 1.9× tokens,但慢約 10%)	--kv-cache-dtype
投機解碼	MTP depth 3 + draft k=10(讀 ~/.models/...-draft-k10 那包 symlink;Same weights,只有 config 改 top-k)	--speculative-config
prefix caching / chunked prefill	on
chunked prefill size	8192	--max-num-batched-tokens
CUDA graph	PIECEWISE;explicit splitting_ops 排除 Δ-net / indexer / PLE mmap 這些需要 host→device copy 的 op
flashinfer autotune	off
Tool calling parser	qwen3_coder(--enable-auto-tool-choice)
Reasoning parser	qwen3(thinking 會被放到 reasoning 欄位,content 只放最終回答)

Vision

模型 包含 vision:model_type=qwen4_exp,language_model_only=false,image_token_id=248056;隨附 preprocessor_config.json (Qwen2VL image processor,longest_edge 16,777,216) 與 processor_config.json (Qwen3VLProcessor + video processor,longest_edge 25,165,824)。

我目前手上兩個都有跑, qwen 3.8 flash next跑出數字如下:

用的是這份recipe:
https://github.com/tonyd2wild/Qwen3.8-Flash-Next-NVFP4-DGX-Spark
用他的SPEED mode, 不過把KV換成BF16, 修復prefill cache, 摘要如下:

模型與執行配置

項目	實際設定
Hugging Face model	nvidia/Qwen3.8-Flash-Next-NVFP4
Context length	262144 tokens
Max sequences	5
Tensor parallel	TP=2
Pipeline parallel	PP=1
KV cache dtype	BF16 / bfloat16
KV pool size	1,074,081 tokens（本次重啟實測）
262144-token concurrency	4.10x
KV memory	約 16.41 GiB（本次 rank 0 log）
GPU memory utilization	0.70
MTP	3 speculative tokens
Max batched tokens	4096
Prefix caching	Enabled；Mamba mode=align；實際 cache hit 已驗證
PLE	TonyD SPEED resident mode（PLE_MODE=none）
CUDA graphs	FULL_DECODE_ONLY，compile mode NONE
Container swap	禁止；兩端 memory.swap.current=0、OOM counters=0

驗收摘要

• Prefix cache：實際命中 1,600 tokens，TTFT 約 2.126s → 0.860s。
• Prefix correctness：cold/hit 的文字與完整 token sequence 相同；20-round growing conversation 為 20/20 文字與 tokens 相同，無 Mamba/CUDA error。
• 32K prefill：3,095.38 tok/s
• 128K prefill：3,002.73 tok/s
• 約 250K prefill：2,880.57 tok/s
• C1 coding：50.55 tok/s；C1 reasoning：48.81 tok/s
• C4 aggregate：coding 155.40 tok/s；reasoning 148.88 tok/s
• 目前允許最多 5 個 active sequences；既有 4×64K context + 每路 4096 forced decode 壓測已證明可維持 4 個 active sequences，尚未另跑 C5 長壓測。
• Coding、reasoning、OpenAI tool/function calling round-trip 與 1-image Vision smoke 均 PASS。

兩者相較之下, 經過不同任務長時間驗證, 我感覺qwen 3.8 flash next能力比較強一點. 不過我主要是做工程方面的, 或許其他方面不一樣也不一定.

@KAKAHermes 我趁沒人用的空檔跑了一下給你參考:

DeepSeek V4 Flash Concurrency Benchmark

• 測試時間：2026-09-02
• 工具：llama-benchy 0.3.8.dev2+gff162bcfc
• 模型：deepseek-v4-flash
• 參數：PP=2048、TG=128、每組 5 runs、--no-cache

測試結果

Concurrency	Prefill total	Prefill/request	TG total（持續）	TG/request	TG 1 秒峰值
4	1835.1 ± 24.0 tok/s	648.3 ± 327.4 tok/s	56.27 ± 3.52 tok/s	18.92 ± 2.84 tok/s	100.6 ± 5.2 tok/s
5	1820.6 ± 69.4 tok/s	598.5 ± 393.3 tok/s	56.97 ± 3.09 tok/s	16.30 ± 2.54 tok/s	108.6 ± 5.1 tok/s

Individual prefill 的 median：c4 為 487.2 tok/s/request，c5 為 485.5 tok/s/request。

這是vllm跑的TP2, 看起來是勉強到你的最低要求. 還是TP4比較有餘裕.
附註:

1. 為了增加更多可用ctx (目前是500K x 6), 我把max-num-batched-tokens設4096 , 再多會OOM. 如果把KV cache減少, 可以留多一點空間, 就可以把這個值調大, prefill會更快
2. 這是KV緩存完全沒命中的測試. 實際prefill數值要視使用情況而定, 可能更快也可能更慢. GB10是統一記憶體, KV緩存到ram不會是一個方案. 若常有長上下文冷啟動需求, 可能要考慮nvme緩存, 這需要折騰.

@KAKAHermes 可以用llama-benchy 測試多concurrency
https://github.com/eugr/llama-benchy

@KAKAHermes 说:

對內尖峰同時發問支持5人， 希望Token數要有15-25 每秒才可以接收。

這一台GB10應該是做不到的. 需要TP才行. 建議買四台GB10跟一台CRS504 100G switch, 跑TP4 deepseek v4 flash vision exp, 或是不要switch跑兩組TP2
兩者我都跑過, TP2 多concurrency tok/s 80+應該是沒有問題, TP4的數據沒有留, 應該是更快.
跑litellm應該是不用那麼多ram, 數據分流litellm內部就可以做到, 不管下面接的是一組, 兩組還是多組.
我現在litellm接了glm 5.3 (GB10 x 8), qwen 3.8 27B Q8 (v100 x 2), ornith-1.5 35B Q4(3060 12G + dram offload), deepseek v4 flash 0731 (GB10 x 2), qwen 3.8 flash next (GB10 x 1), 分別服務兩個網段. litellm也才用了一台i5-1135G7, 16G ram的小電腦而已.

@kop-wang
我是沒用兩台跑過qwen 3.8 flash next, 機器都拿去跑別的模型了. 照以往的經驗, 兩台大概可以提昇1.3~1.5倍左右的速度.
這邊有一台用SGLang跑出43 tok/s平均速度的可以參考 https://github.com/azampatti/GB10-3.8-Flash-Next

也有人兩台跑vllm的nvfp4可以參考:

@kop-wang
qwen 3.8 flash next NVFP4一台就可以跑了, 參考 https://github.com/blazux/qwen3.8-Flash-DGX
pp大概1500-2000 tok/s , decode 約 30 tok/s , KV cache大概有630K. 我跑了一周左右吧, 很穩定, 用codex cli長鍊loop工作數天沒什麼問題.
兩台其實也可以跑glm 5.3 flash的 https://github.com/Entrpi/glm-5.3-flash-exl3-2x-spark

我有八月初裝的時候的測試數據可以參考:

我算了一下這兩天在這台跑的幾個任務的實際資料, 統計範圍為本次模型啟動 2026-08-20 14:38:49 至 2026-08-22 23:11:37。

整體 Inference 流量

項目	數量
總 inference requests	555
正常完成	549
Client 取消	6
完整輸入 tokens（實算＋cache hit）	約 44,519,320
輸出 tokens	345,037
輸入＋輸出總 tokens	約 44,864,357

統計摘要

• Cache 命中的輸入：約 42,957,100 tokens
• 實際重新計算的輸入：約 1,562,220 tokens
• 實際模型運算量：1,562,220 + 345,037 = 約 1,907,257 tokens
• 549 個正常完成的 requests，輸入＋輸出共 44,759,153 tokens
• 其餘約 105,204 tokens 來自 6 個處理途中被 client 取消的 requests

在這其中,

長 Context Prefill(實際運算至少 10K prompt tokens) 統計

時間	Task/Slot	完整輸入	KV hit	RAM hit	實際 prefill	秒	t/s	輸出	實際運算
08-21 17:54:56	2200/0	49,038	38,095	0	10,943	15.33	713.66	258	11,201
08-21 17:55:19	2302/0	60,660	49,032	0	11,628	18.14	641.05	363	11,991
08-21 19:15:11	29262/0	43,354	28,082	0	15,272	20.81	734.04	268	15,540
08-22 07:36:55	48605/1	42,075	32,008	0	10,067	14.93	674.41	468	10,535
08-22 09:02:31	75758/0	59,242	28,055	0	31,187	41.32	754.68	2,397	33,584
08-22 09:04:48	76775/0	84,174	61,632	0	22,542	39.27	574.09	4,812	27,354
08-22 09:10:03	79712/0	107,364	93,401	0	13,963	30.63	455.91	4,667	18,630
08-22 09:25:31	87432/1	140,000	28,055	0	111,945	220.04	508.75	6,194	118,139
08-22 09:58:39	100491/0	56,804	28,056	0	28,748	38.47	747.37	183	28,931
08-22 10:01:06	101496/1	61,095	28,055	0	33,040	45.38	728.13	56	33,096
08-22 13:10:21	124047/2	40,054	0	28,056	11,998	22.91	523.63	1,217	13,215
08-22 22:23:27	129780/0	34,222	0	0	34,222	49.31	694.00	136	34,358
合計	12 次	900,170	414,471	28,056	457,642	675.64	677.35 加權	23,902	481,544

555個request中只有12次有超過10K沒命中. 其中完全沒命中的只有1次, 其他都部分被KV cache或ram cache命中. 12次裡面prefill超過一分鐘的只有一次.

以這個使用場景來說, 長prefill其實不是那麼頻繁.

這個速度真的比較低, decode跟pp都是. 我的垃圾雙卡Tesla v100 32G, Q8 GGUF, 無nvlink, llama.cpp, mtp 2, 跑出來數字如下:

@applejuice
這個配方我也在用, 初始prefill大概29xx t/s上下.
目前一個複雜任務用codex cli跑超過兩天, 沒有出現衰退或崩潰的現象, 但是也還沒解出來.
跟3.6相比, 我覺得進步的是他更加嚴謹, 可控. 更會遵循賦予他的提示詞, 比較不會跑偏或遺漏.
不過問題是他想很多, 太多. 導致進度緩慢, 並且知識面相較deepseek, glm確實有點不足. 想得很多但是太困難的任務又無法全面掌握該有的技術. 可能還需要再優化下, 至少讓他完成任務的時間短一點.
補個測試數據;

我已經用了好一陣子了, coding中速度30~70不定, pp約2000.
我來回答你的問題:
1. 两台 DGX Spark 跑 V4，实际生成速度大概能到多少 token/s？
測速約40~50, 實際coding使用視狀況約落在30~70不等.
2. 两台之间用 200G 网络互联，实际通信效率怎么样？
這有點複雜, 他每一個port有兩個rail, 各100G, 你可以用100G或200G, 看怎麼設. 我是用100G, 看他實際也沒用到100G, 就沒去搞200G了. 實測iperf約97G
3. 跑 V4 的时候，两台机器是比较接近“线性叠加”，还是通信开销会吃掉很多性能？
因為一台跑不了正常V4 flash, 所以沒辦法比較. 不過照之前別的模型的經驗,兩台速度約為一台的1.5倍左右. 我之前也跑過4台,速度又比兩台快上不少
4. 如果主要用途是编程、Agent、长上下文和日常本地 AI，两台 DGX Spark 是否值得？
我只用來編程, 主要是驅動韌體的開發跟debug, 跑claude code或codex cli , 兩台實際上約可以並行6個ctx 500K的session. 使用上是夠順了, 就看智力跟能力符不符合你的需求, 我是覺得不到優秀,但是堪用.
5. 有没有已经实际部署过 V4 的朋友，能分享一下真实测试数据？

6. 如果现在买，华硕、技嘉、微星等不同品牌的 DGX Spark，散热、SSD、稳定性方面有没有明显区别？
1TB 版本是不是就够了？后面自己升级 SSD 是否更划算？
我有華碩跟技嘉的, 感覺差不多. 兩台的話還好,反正也跑不了多大模型, 選擇也不多. 1T應該可以,有需要日後再換就好. 如果只用來跑模型的話, 速度瓶頸在頻寬, 長時間不間斷運轉可以考慮GPU降頻跑不會影響pp跟t/s太多, 溫度跟功耗會下降不少

最後應該考慮的是, 是否真的有這個需求? 這需要從用量跟隱私方面評估了. 兩台GB10不便宜, 漲價後更是誇張. 若是用量沒那麼多, 兩台GB10可能可以抵過10年的線上費用, 隱私又沒問題的話, 可以考慮線上使用就好. 本地用起來是舒適, 線上的是飛快, 爽度還是有差.

@linkdesu 我已經用兩台跑很久了，0731出來也已經換上了，真心不錯，速度快，kv緩存也夠500K x 6.
不過coding上使用起來感覺還是差glm 5.2一點，純個人感覺，沒有甚麼根據.
單純論性價比,dsv4f用兩台，glm 5.2至少要四台，dsv4f還是比較高的

這個模型我有用一陣子, 蠻不錯的, 不過有一些過度思考跟loop輸出的問題, 而且他們好像還在tune, 可能再等一陣子吧.