抡锤者

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

測試:

最近我的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

@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.

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

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

前幾天看著平常編程在用的洋垃圾, 突然想搞個顯卡來跑跑qwen 3.6 27B. 看了半天, 台灣這邊魔改卡不好買, 也都是天價. 7900XTX基本沒人在賣, R9700兩張又太貴, 就入了兩張Nvidia TESLA v100 32G來試試.
電腦本來只有BMC顯示, 所以驅動啥的都沒裝, 只有裝ubuntu 26.04.
各論壇看了看, 鎖定llama.cpp + Qwen3.6-27B-UD-Q8_K_XL.gguf , 然後把相關資料交給gemini cli去安裝, 大概一個小時它就把NVIDIA 驅動,CUDA其他相依軟件及設定搞好, llama.cpp編譯完成, 該避的坑避掉, 模型下載完然後就跑起來了, 全程無干預.
再來就是跟它花了大概兩個小時測試調整, 主要是一開始的prefill慘不忍睹, 花很多時間在長文本測試優化. 調到一個滿意的設定, 就差不多了, 整個過程還挺順利的.
底下是我電腦的基本資訊:

系統與硬體狀態

• 作業系統: Ubuntu 26.04 LTS
• CPU: AMD EPYC 7K62
• RAM: 128GB DDR4
• GPU 硬體: 2x NVIDIA Tesla V100-SXM2-32GB
• PCIe 連線: Gen3 x16 (狀態良好)
• 平均溫度: Idle 35°C / 滿載 ~45°C
• 功耗限制: 300W

目前的狀態大概是這樣:

服務運行狀態

• 服務名稱: qwen36-llama.service
• 執行引擎: llama.cpp (CUDA 70架構優化編譯版)
• 載入模型: Qwen3.6-27B-UD-Q8_K_XL.gguf

當前模型參數配置 (終極優化版)

• 總 Context 空間: 524,288 tokens
• 併發能力 (Parallel): 2 路 (每路 262,144 tokens)
• KV Cache 精度: q8_0
• MTP 加速: 啟用 (draft-mtp, 最大預測數: 2)
• Batching 設定: Batch 1024, UBatch 256

效能與資源佔用指標

VRAM 記憶體佔用

系統已確保 100% 的權重與 KV Cache 駐留於 VRAM 中，完全不依賴系統 RAM 進行 offload，徹底解除 PCIe 頻寬瓶頸。

• GPU 0 佔用: ~24.3 GB
• GPU 1 佔用: ~30.3 GB
• 總計佔用: 54.6 GB
• 安全餘裕: 剩餘約 9.4 GB，足以應付 Batch 1024 運算時產生的動態 Scratch Buffer 需求。

推理速度 (實測)

• Prompt Processing (Prefill): 最高可達 ~611 tokens/second (長文測試)。
• Generation (Decode): 穩定於 ~40 tokens/second。
• MTP 接受率: 約 79% ~ 100% (極高效率)。

以上是Gemini寫的報告, 中間有多次參數設定調整, 比較如下:

效能測試結果總表

測試組合	3路 256K (無MTP)	2路 256K (MTP 2)	1路 256K (B256, mtp2)	1路 256K (B512,mtp2)	1路 256K (B1024,mtp2)	2路 256K (B1024,mtp2)
1. 成功啟動	是	是	是	是	是	是
2. VRAM Used (GPU0/1)	27.8/31.2 GB	23.7/29.1 GB	19.3/23.8 GB	19.6/24.5 GB	19.9/25.1 GB	24.3/30.3 GB
3. Prefill (t/s)	90.31	42.02 (短文)	263.93	395.94	611.04	23.01 (短文)
4. Generation (t/s)	20.87	37.24	46.64	43.09	40.65	40.06
5. MTP 接受率	N/A	79%	100%	100%	100%	87.5%
6. 是否 OOM	否	否	否	否	否	否
7. 數據位置	部分 RAM	部分 RAM	純 VRAM	純 VRAM	純 VRAM	純 VRAM
8. GPU Power (0/1)	51W/49W	51W/49W	~50W/50W	52W/52W	53W/53W	51W/49W
9. GPU Temp (0/1)	35°C/35°C	34°C/33°C	35°C/35°C	39°C/40°C	39°C/41°C	34°C/34°C

定案之後看了一下vram占用狀態跟跑一下benchmark:

心得:

1. 一樣是qwen3.6 27B Q8模型, 實際使用速度約比雙spark高出5~10 token/s, prefill速度也還行. 不過雙spark可以容納約15路並行, 這台電腦礙於vram容量, 只能兩路.
2. 渦輪風扇實在太吵, 必須關到小房間... 早知道不要嫌麻煩買個水冷...

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

@怪物 提供你兩台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應該可以用超過十年了...

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

@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好像也沒其他甚麼模型可以用了.

@Tony-Wang
ltx2.3大概是這樣:
（DGX Spark, 1280×720）

steps	seconds	frames	冷啟動耗時
12	4	97	~290 秒
24	4	97	~480 秒

使用這些模型:

• models/checkpoints/ltx-2.3-22b-distilled-1.1.safetensors
• models/text_encoders/gemma_3_12B_it_fp4_mixed.safetensors
• models/latent_upscale_models/ltx-2.3-spatial-upscaler-x2-1.1.safetensors

Flux.2 1280x720、20 steps：

• bf16 20 steps 約 530 秒，fp8mixed 20 steps 約 155 秒。
• fp8mixed 4 steps smoke test 約 1 分鐘內完成；20 steps 約 2 到 3 分鐘級別