NVIDIA DGX spark 不是這邊的主力部署, 不過這裡有一些數據分享給想知道或是有類似需求的朋友.
我的LLM的用途主要是工作上(驅動/韌體 開發/debug), 基本上需要模型跑在全精度或至少Q8量化以上. 我試過FP8相較BF16已經略差, Q4實際使用上是無法達到我的需求.
在這個前提下, 我需要的是更多的vram, 能夠跑Q8以上的模型, 並且至少需要256K context, 才能比較舒適的使用. DGX spark雖然不快, 但是如果我想跑minimax, deepseek, mimo之類的模型, 選擇似乎也不多. 如果有超大模型, 超長上下文, 多併發的需求, 同時又不能使用雲端模型的情況下, DGX spark是可以考慮的選擇之一.
現在我手上有4台DGX spark, 因為QSFP switch還沒到手, 所以只能先倆倆對接, 四台還沒辦法接在一起. DGX spark自帶兩個connectX-7 QSFP介面, 把多台接在一起的時候,透過RDMA 和張量並行，集群可實現部分加速, 越多台速度越快,這應該比mac的exo快, 我沒有多台mac, 所以不知道實際狀況如何. 目前我是跑Qwen/Qwen3.6-27B-FP8(模型權重30.9G)跟deepseek-ai/DeepSeek-V4-Flash全精度模型(模型權重160G), 下面速度供大家參考:

Qwen/Qwen3.6-27B-FP8單spark:

Qwen/Qwen3.6-27B-FP8雙spark:

deepseek-ai/DeepSeek-V4-Flash, 雙spark:

速度不是非常快, 不過因為平常我也不跟它們聊天, 都是用opencode或pi把工作丟給它們就去做別的事了, 所以也還好. 基本上有個20我就覺得可以用了, 畢竟這是8 bit的模型, 也不能強求什麼了.
這兩個模型依我的使用比較起來, 感覺智力上相當接近, qwen 3.6 27B在tool call上出錯比較少, 是真的能打. 雖然跟claude opus 4.7或GPT 5.5相較之下還是有差異, 不過也堪用了.

至於ComfyUI嘛.. 它就是一個沒有什麼跑不動, 卻也沒有什麼跑的快的狀態.

6/2更新, deepseek v4 flash spark論壇上有新的優化, 請gemini cli照做後性能有所提升.
論壇網頁:
https://forums.developer.nvidia.com/t/deepseek-v4-flash-official-fp8-running-across-2x-dgx-spark-tp-2-mtp-200k-ctx-recipe-numbers/370309/135

測試:

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

---

最近我的DGX SPARK GB10增加到了10台, 其中八台拿來跑GLM5.2, ctx 320K x 10. 正在測試中, 感覺是比deepseek v4 flash強, 強多少要多跑幾天才知道
不過很慢, prefill 大概600-800, tok/s大概2x
ps. 四台就可以跑了, 參考 https://forums.developer.nvidia.com/t/glm-5-2-on-a-4x-gb10-cluster-22-tok-s-decode-256k-ctx-recipe/374125

我跑的是這個 https://github.com/ciprianveg/gb10-glm-5.2
不過是用八台, 為了榨出更多的併發數, 我用了DCP4 , prefill跟tok/s都慢不少, 不過得到300K x 10 的ctx

如果是DCP1的話會快上不少, 這是作者的數據:

我已經用了好一陣子了, 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年的線上費用, 隱私又沒問題的話, 可以考慮線上使用就好. 本地用起來是舒適, 線上的是飛快, 爽度還是有差.

@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可以參考:

論壇大神發布了一個單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)。

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

@566656661
CRS804是4 port 400G QSFP56-DD, 每個port由八條獨立的資料通道組成, 所以可以分出2x200G, 4x100G等等. 買對線就可以接8台或16台DGX spark. 我看TP 8的時候網路流量好像也沒有到100G, 所以接16台應該對速度也沒有影響. 我是買這條線, 接了8台

@566656661
2部鏈接在一起的話應該只能接到3台, 兩兩對接. 我是用MikroTik CRS804 switch 接到八台GB10的200G的port.

@包磊 不錯喔，不過如果你之前沒試過，或許可以試試hermes直接接deepseek 看看，可能之前就是模型的問題而已
這兩天DGX論壇上也把單台dgx spark裝deepseek flash 0731搞到看起來還不錯，可以試試. 若一台覺得精度不夠，可能要看用量決定是再買一台來張量並行，還是直接用線上的.
兩台速度快很多，prefill 2000初 t/s, decode 40-60 tok/s, 精度也夠，看怎麼取捨了.

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

@怪物 提供你兩台DGX SPARK GB10跑官方FP4 + FP8 混合的DeepSeek-V4-Flash-DSpark數據參考:

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
deepseek-v4-flash	pp2048	1959.48 ± 8.50		1048.24 ± 17.23	930.12 ± 17.23	1048.24 ± 17.23
deepseek-v4-flash	tg128	52.03 ± 2.81	62.33 ± 4.03
deepseek-v4-flash	pp2048 @ d4096	1991.19 ± 11.48		2952.43 ± 30.38	2834.32 ± 30.38	2952.43 ± 30.38
deepseek-v4-flash	tg128 @ d4096	44.09 ± 11.80	54.00 ± 14.45
deepseek-v4-flash	pp2048 @ d8192	1951.66 ± 3.01		4816.60 ± 82.26	4698.49 ± 82.26	4816.60 ± 82.26
deepseek-v4-flash	tg128 @ d8192	30.62 ± 7.49	38.93 ± 7.88
deepseek-v4-flash	pp2048 @ d16384	1959.18 ± 35.62		8516.84 ± 208.01	8398.73 ± 208.01	8516.84 ± 208.01
deepseek-v4-flash	tg128 @ d16384	45.72 ± 4.31	38.67 ± 26.89
deepseek-v4-flash	pp2048 @ d32768	1948.22 ± 1.68		16207.60 ± 39.41	16089.49 ± 39.41	16207.60 ± 39.41
deepseek-v4-flash	tg128 @ d32768	36.85 ± 3.01	47.00 ± 1.41

實際跑coding任務速度大概在45-65之間, 視上下文長度及內容而定, KV快取命中一直處在高檔, 所以速度一般在50~6x t/s之間. 兩台GB10跑起來大約可以有6個500K的任務同時進行, 已經很夠用了.

不過你已經有一張RTX PRO 6000, 預算也差不多可以買另外一張, 兩張應該也是可以跑才是. 只是考慮還要跑comfyui, 可以原本RTX PRO 6000跑comfyui, 兩台GB10叢集跑deepseek v4 flash.

話說回來, 如果是自用的話.. 這些錢用線上的deepseek應該可以用超過十年了...

@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也是可以的.

@kos-or Deepseek 就很強了, 就我實際使用體感上deepseek v4 flash應該介於minimax M3與Kimi K3之間, 等這兩天deepseek v4正式版出來, 應該會更接近Kimi K3. 如果有chatgpt codex去解決難的問題, 應該就夠用了.
我之所以會有minimax是因為我是按年訂閱的, 退不了... minimax現在新用戶又增加了周限制, 不太划算

@terry 目前我兩台GB10跑deepseek V4 flash, 八台跑glm 5.2. 這是我自己兩台GB10跑出來的結果. prefill 速度上面也有, 接近2000 t/s. 每次會話的首字延遲視上下文而定, 約幾秒到分鐘不等. 首字過後緩存命中約9x%, 一般就沒甚麼prefill的花費, 這時候就是看吐字速度了.

@李明 之前貼過兩張V100 32G跑Qwen3.6 27B Q8的測速給你參考:

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
qwen-3.6-27b	pp2048	834.28 ± 19.56		2508.84 ± 171.52	2197.12 ± 171.52	2508.84 ± 171.52
qwen-3.6-27b	tg128	30.56 ± 0.79	38.67 ± 1.70
qwen-3.6-27b	pp2048 @ d4096	937.27 ± 20.09		6170.01 ± 97.33	5858.29 ± 97.33	6170.01 ± 97.33
qwen-3.6-27b	tg128 @ d4096	30.53 ± 0.49	38.00 ± 0.82
qwen-3.6-27b	pp2048 @ d8192	952.76 ± 8.60		10102.94 ± 101.45	9791.23 ± 101.45	10102.94 ± 101.45
qwen-3.6-27b	tg128 @ d8192	30.05 ± 0.74	36.67 ± 1.70
qwen-3.6-27b	pp2048 @ d16384	925.11 ± 11.23		18209.55 ± 38.89	17897.84 ± 38.89	18209.55 ± 38.89
qwen-3.6-27b	tg128 @ d16384	27.19 ± 1.32	34.33 ± 0.47
qwen-3.6-27b	pp2048 @ d32768	854.63 ± 5.92		37259.34 ± 281.61	36947.63 ± 281.61	37259.34 ± 281.61
qwen-3.6-27b	tg128 @ d32768	27.10 ± 0.80	35.33 ± 0.94

也有跑orinth-1.0-35b Q8的測試, 他是基於qwen 3.6 35BA3B去微調的, 大概可以100 t/s:

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
ornith-35b	pp2048	785.61 ± 15.97		2483.07 ± 66.69	2362.38 ± 66.69	2483.07 ± 66.69
ornith-35b	tg128	106.71 ± 4.49	109.00 ± 5.72
ornith-35b	pp2048 @ d4096	803.66 ± 14.44		7060.92 ± 293.27	6940.24 ± 293.27	7060.92 ± 293.27
ornith-35b	tg128 @ d4096	102.15 ± 1.64	104.00 ± 1.41
ornith-35b	pp2048 @ d8192	792.75 ± 2.92		12035.29 ± 105.50	11914.60 ± 105.50	12035.29 ± 105.50
ornith-35b	tg128 @ d8192	103.90 ± 0.75	105.33 ± 0.47
ornith-35b	pp2048 @ d16384	791.20 ± 7.30		21444.59 ± 125.59	21323.90 ± 125.59	21444.59 ± 125.59
ornith-35b	tg128 @ d16384	104.99 ± 4.85	107.33 ± 5.31
ornith-35b	pp2048 @ d32768	763.53 ± 9.87		41675.67 ± 664.23	41554.98 ± 664.23	41675.67 ± 664.23
ornith-35b	tg128 @ d32768	98.68 ± 0.85	101.00 ± 0.82

GGUF模型都可以跑, 其他的幾乎不用玩了. 現在這個容量之下 , 除了Qwen 3.6 27B / 35BA3B好像也沒其他甚麼模型可以用了.

我算了一下這兩天在這台跑的幾個任務的實際資料, 統計範圍為本次模型啟動 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其實不是那麼頻繁.

@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

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