1180 tok/s 的地表極速是什麼概念？在 256 tokens 的輸出下，運算只要 0.22 秒就瞬間結束，這表示 DiffusionGemma 26B 在 NVIDIA GH200 上跑 vLLM 的速度，整整比 M2 Max 快了 80 倍！
延續系列第一篇在 M2 Max 96GB (MLX) 篇 中探討地端 Agent「無限 Token 自由」的實驗，當時 Standard 4-bit 雖然擠出了 31.6 tok/s 的不錯峰值，但面對長 Context（上下文）與多用戶併發請求時，Mac 的排隊機制與記憶體頻寬依然顯得力不從心。
為了追求 Production等級部署，我們將戰場移到魔王級的硬體—— NVIDIA GH200 (Grace Hopper)，當強大的 Diffusion 架構遇上 vLLM 優化，不僅 32,653 tokens 的 Context 直接逼近極限打滿，併發吞吐量也是狂飆猛飆，雖然上面還是舊的HBM3，但是效果體感上還是滿讓人滿意的。
測試環境：vLLM + GH200 480GB
| 項目 | 內容 |
|---|---|
| GPU | NVIDIA GH200 480GB（單顆 Hopper + Grace CPU NVLink-C2C） |
| HBM3 | 95.6 GB 可用 |
| CPU | 72 核 ARM Neoverse（Grace） |
| 系統 | Rocky Linux 9.7 (aarch64) |
| 框架 | vLLM 0.22.1rc1（容器：vllm/vllm-openai:gemma） |
| 模型 | nvidia/diffusiongemma-26B-A4B-it-NVFP4 |
| 部署參數 | --dtype auto --max-model-len 32768 --gpu-memory-utilization 0.60 --max-num-seqs 4 --attention-backend TRITON_ATTN |
為了簡化部署的架構，我是讓 vLLM 跑在 Podman 容器裡，GPU memory utilization 嘗試幾次後，後來設 0.60 不是為了省記憶體，是因為更高會在 warmup 階段因為 CUDA graphs 配置沒留空間而 OOM，KV cache 能用的都是剩下的。
Generation Throughput：1180 tok/s 是什麼概念
生成速度的測試我先維持了跟 Mac 一樣的 prompt 和參數：
| Output 長度 | 速度 | 延遲 |
|---|---|---|
| 64 tokens | 260 tok/s | 0.25s |
| 128 tokens | 519 tok/s | 0.25s |
| 256 tokens | 887~1180 tok/s | 0.22~0.29s |
| 512 tokens | 936~1053 tok/s | 0.49~0.55s |
| 1024 tokens | 1011 tok/s | 1.01s |
256 tokens 最快（1180 tok/s），因為剛好 fit 一個 canvas，不過更有趣的是 1024 tokens 只花了 1.01 秒，代表多個 canvas 的 parallel processing 在 Hopper 的架構上卻 scale 的更好。
跟 M2 Max 對比（同為 256 tokens）：
| 平台 | 速度 | 差距 |
|---|---|---|
| M2 Max (MLX) | 14.7 tok/s | 1x |
| GH200 (vLLM) | 1180 tok/s | 80x |
這部分應該是 vLLM 的 Hopper GPU 針對 diffusion 架構做了 TRITON_ATTN backend 和專屬 denoising kernel 優化。
Context Scaling：32K 全滿可用
GH200 真正有優勢的地方在這，M2 Max 到 16K 就喘呼呼了，而GH200 直接推到 32K 上限：
| Context 長度 | 速度 | 延遲 |
|---|---|---|
| 5K tokens | 104 tok/s | 0.61s |
| 10K tokens | 66 tok/s | 0.97s |
| 20K tokens | 39 tok/s | 1.63s |
| 32K tokens | 4.0 tok/s | 15.9s |
前 20K 的延遲都在 2 秒以內，對實際開發應用來說完全可接受，但是到 32K 的時候掉到 4 tok/s，原因是 KV cache 接近用盡 + diffusion intermediate states 競爭記憶體頻寬，不過我實際上接到 opencode CLI 上使用，體感還是滿好的。
併發吞吐量：vLLM 的優勢
跟 M2 Max MLX server 不同，vLLM 有真正的 batching 和 concurrent kernel execution：
| 情境 | GH200 | M2 Max |
|---|---|---|
| Sequential 平均延遲 | 0.06~0.12s | 1.5s |
| Concurrent 4 總吞吐量 | 256 tok/s | 1.4 tok/s |
在併發測試時 GH200 跑出 256 tok/s（wall 0.39s），而M2 Max 只有 1.4 tok/s，不止數據上差距 180 倍，實際上接到 opencode使用時心情也是差了好幾十倍。
GH200 的定位
DiffusionGemma 26B 在 GH200 上運作好棒棒，但還是有一件事要留意，目前 91 GB 模型佔用對 GH200 的 96 GB HBM3 來說太滿了，剩下 5 GB 的 headroom 在短 context 時沒問題，但如果需要同時處理大量長 context 請求，記憶體會是瓶頸或是造成其他的問題。
好在GH200 還有 480 GB 的 coherent memory 可以透過 NVLink-C2C 存取，但 vLLM 預設不會拿來放 model weights，這邊的 bandwidth 跟 HBM3 比起來還是差了不少，但是還是有一些社群上大神提供的參數還可以再測試讓記憶體再有餘裕一點。
接下來
DiffusionGemma 26B 在 GH200 搭配 vLLM 下的表現堪稱恐怖，在短 Context 靠著極致頻寬與 TRITON_ATTN 後端優化可以無壓力秒殺，但是遇到多用戶、長 Context 的極端高併發場景，剩餘 5 GB 的 KV Cache 空間就會迅速面臨撞牆瓶頸。
目前是先架在公司內多人連線測試中，也陸續還在調整一些參數來讓大家的 Agent token更有餘裕，後續如果還有更優化版本，再分享上來。
下一篇我們會拿 NVIDIA Blackwell GB10 的 128GB 統一記憶體來看看DiffusionGemma 26B 在長序列滿載時是否能展現更完美的完全體型態。
- 模型：
nvidia/diffusiongemma-26B-A4B-it-NVFP4 - 框架：vLLM 0.22.1rc1（容器：
vllm/vllm-openai:gemma） - GPU：GH200 480GB（Grace Hopper）
