作為三平台評測的最終章（前兩篇為 M2 Max 96GB MLX 與 GH200 vLLM），本篇將完整測試一下 GB10 的吞吐量表現、32K 長 Context 的速度代價、以及在 Podman 部署時讓人抓狂的 OOM 踩坑紀錄。
在數據的結果來看，155 tok/s，比 M2 Max 快了整整 10 倍！ 更重要的是，Context 長度一路從 2K 解鎖到 32K都成功Pass，直接與老大哥 GH200 站在同一條起跑線上，直到 32,600 tokens 才開始撞牆。
整體來說， NVIDIA GB10（Grace Blackwell 128GB）在執行 DiffusionGemma 26B 時，交出了一份令人驚艷的成績單，雖然 Context 拉長後，速度衰減得比 GH200 明顯，但實際串接在CLI 的使用體感與超高性價比，絕對是本地推理 Server 的首選。
測試環境：GB10 + vLLM，32K Context 達標
| 項目 | 內容 |
|---|---|
| 平台 | NVIDIA GB10（Grace Blackwell），128 GB 統一記憶體 |
| 框架 | vLLM 0.22.1rc1 |
| 模型 | nvidia/diffusiongemma-26B-A4B-it-NVFP4 |
| 部署參數 | --gpu-memory-utilization 0.7 --max-model-len 32768 --max-num-seqs 4 --enable-auto-tool-choice --tool-call-parser gemma4 --reasoning-parser gemma4 |
| 容器 | vllm-diffusiongemma |
| 部署方式 | Podman，需用 --device nvidia.com/gpu=all 而非 --gpus all
|
部署的設定我跟 GH200 那台使用相同的 vLLM 版本（0.22.1rc1），部署參數也差不多，另外設定--gpu-memory-utilization 0.7 只分配約 90 GB GPU 記憶體給 vLLM，但靠 --max-num-seqs 4 限制併發數避免 OOM，也成功把 --max-model-len 推到 32768 跟 GH200 達到差不多的輸出體驗。
Generation Throughput
| Output 長度 | 速度 | 延遲 |
|---|---|---|
| 64 tokens | 35 tok/s | 1.82s |
| 128 tokens | 78 tok/s | 1.64s |
| 256 tokens | 140 tok/s | 1.83s |
| 512 tokens | 155 tok/s | 3.30s |
| 1024 tokens | 151 tok/s | 6.76s |
Throughput 的峰值在 512 tokens（155 tok/s），不過有趣的是 64 tokens 反而最慢（35 tok/s），應該是因為在較短輸出時 denoising step 的 warmup overhead 佔比大，剛開始的 decoding overhead 被攤分到的 token 數太少，而跟 GH200 的 1180 tok/s 相比，GB10 約 1/8，但對比 M2 Max 的 14.7 tok/s 已經是 10 倍。
輸出的速度曲線很平穩，大概從 256 到 1024 tokens 都維持在 140-155 tok/s，這也代表 Blackwell GPU 在 multi-canvas 處理上 scale 得不錯。
Context 限制：32K 達標，20K 內都還算順
前面有提到，透過設定--max-model-len 從 8192 再拉到 32768 之後，context 極限跟 GH200 打平了。
實測上的最大輸入有到 32,600 tokens（配 1 個 output token，距 32,768 差 168），超過就會一直跳出類似的提示
This model's maximum context length is 32768 tokens.
當然，context 越長速度越慢，跟 GH200 比起來還是有一段距離
| Context 長度 | 輸入 tokens | GB10 速度 | GH200 速度（對照） |
|---|---|---|---|
| ~1.5K | 1,484 tok | 35.4 tok/s | — |
| ~5K | 7,500 tok | 15.7 tok/s | 104 tok/s |
| ~10K | 15,070 tok | 9.3 tok/s | 66 tok/s |
| ~20K | 30,273 tok | 3.3~15.6 tok/s | 39 tok/s |
| ~30K | 32,216 tok | 9.9 tok/s | — |
| ~32K（極限） | 32,600 tok | 0.09 tok/s | 4.0 tok/s |
前 10K 都還有 9 tok/s 以上，對多輪對話和中等長度文件分析完全夠用，到快 20K 的時候生成速度看 workload 差異很大（簡單 prompt 有 15.6 tok/s，複雜摘要掉到 3.3 tok/s），而 30K 還有 10 tok/s，但到極限 32K 就只剩 0.09 tok/s。
跟 GH200 比起來，GB10 在同 context 長度下大約慢 4-7 倍。但考慮到 GB10 的價格和功耗，這個 trade-off 很合理，實際上在CLI 的串接體感上，較長context的等待時間我覺得還可以接受，偶爾需要等一下。
部署踩到的坑
這顆模型在 Podman 上部署不算順利，記錄幾個有筆記起來的部分。
一開始在 CUDA graphs warmup OOM：gpu-memory-utilization 設太高（~0.8+）時，模型權重載入後剩餘空間不足以讓 CUDA graphs 完成 warmup，直接噴 OOM，後來陸續調降到 0.7 後才變得比較穩定，再配合參數 --max-num-seqs 4 限制併發，可以把 max-model-len 推到 32768。
Podman GPU 參數：--gpus all 在 Podman 上不支援，要用 --device nvidia.com/gpu=all。
CNI DNAT 殘留：刪除舊容器重建後，nftables 還留著舊容器的 DNAT 規則，連 localhost:8090 會 No route to host，後來是利用 sudo nft flush chain ip nat CNI-HOSTPORT-DNAT && sudo systemctl restart podman來成功排除。
DGX Spark CNI 插件路徑：這台機器的 CNI plugins 放在 /usr/lib/cni/ 不是預期的 /opt/cni/bin/，Podman 會找不到網路插件，需要手動 symlink。
併發
| 併發數 | 總吞吐量 | Wall time |
|---|---|---|
| 1 | 70 tok/s | 1.14s |
| 2 | 126 tok/s | 1.27s |
| 4 | 123 tok/s | 2.59s |
在併發數2的時候還是接近線性 scaling（70→126），但到 4後就 plateau 了（123 tok/s），跟GH200 的 4個併發結果可以到 256 tok/s，GB10 大約是它的一半，再跟 M2 Max 的 1.4 tok/s 比，已經是阿彌陀佛了🤣
三平台定位
到目前為止三台的關鍵數字：
| 項目 | M2 Max 96GB | GH200 480GB | GB10 128GB |
|---|---|---|---|
| 框架 | MLX | vLLM | vLLM |
| 峰值生成 | 14.7 tok/s | 1180 tok/s | 155 tok/s |
| 4 路併發 | 1.4 tok/s | 256 tok/s | 123 tok/s |
| 可用 context | ~8K-16K | ~32K | ~32K |
| 優勢 | 開發方便、RAM 大 | 極致效能 | 價格效能比最佳 |
GB10 把 context 推到 32K 之後，跟 GH200 站在同一條起跑線了，雖然 155 tok/s 的生成速度雖然只有 GH200 的 1/8，但 32K context 全滿可用、不貴、不吵、插電就能當 local 推理 server。
以 GB10 的價位來說，這個表現已經遠超出預期，如果你的應用需要長時間執行推理任務（batch processing、定期分析），GB10 搭配 GH200 可以形成一個很有效率的 tiered 架構，一般日常開發和短任務給 GB10，長 context 或高併發丟給 GH200。
- 模型：
nvidia/diffusiongemma-26B-A4B-it-NVFP4 - 框架：vLLM 0.22.1rc1
- 平台：GB10 Grace Blackwell（128 GB 統一記憶體）
