Gemma 4 在 vLLM 與 Ollama 的 Blackwell GPU 效能測試

原始來源與檔名：Gemma4在Blackwell上的效能評測.md

來源：Allen Kuo (kwyshell) on Medium — 2026-04-08

NAPKIN | 餐巾纸

餐巾紙公式

Agent 基礎設施 = TTFT 敏感場景用 vLLM + 個人桌機單兵作戰用 Ollama + 26B MoE 模型性價比最高

一句話

作者在配備 96GB VRAM 的 RTX PRO 6000 Blackwell 工作站上，測試了 Gemma 4 家族 (8B, 26B MoE, 31B Dense) 在 vLLM (BF16精度) 與 Ollama (Q4_K_M 量化) 上的效能表現。結論是：vLLM 在並發吞吐與首字延遲 (TTFT) 佔優，適合 Agent 部署；而 Ollama 在單一用戶推理速度與 VRAM 佔用上碾壓，適合桌面端。最令人驚豔的是 26B MoE 模型，它提供了 26B 的智力，卻跑出了接近 4B 模型的速度。

餐巾紙草图

[ Gemma 4 Benchmarks on 96GB Blackwell ]

  * Metric 1: TTFT (Time To First Token) -> Winner: vLLM (~60ms vs Ollama ~190ms)
  * Metric 2: Concurrency (4 users) -> Winner: vLLM (up to 3.6x higher throughput)
  * Metric 3: Single-User Decode Speed -> Winner: Ollama (Q4 quantization wins memory bandwidth)
  * Metric 4: VRAM Footprint -> Winner: Ollama (Dynamic usage vs vLLM's 90% pre-allocation)

  [ The MVP: 26B MoE ]
  - 26B total parameters, but only ~4B active.
  - Speed on vLLM: 131 tok/s (Actually FASTER than the 8B dense model at 124 tok/s!)

ROUND 1: SKELETON | 骨架掃描

• 核心問題: 當企業或個人擁有一張頂級推理卡 (如 96GB Blackwell) 時，該如何選擇底層推理引擎 (vLLM vs Ollama) 與 Gemma 4 模型版本，才能達到效能與成本的最佳平衡？
• 核心答案: 引擎的選擇取決於場景 (並發 API 服務選 vLLM，單機桌面選 Ollama)。模型方面，強烈建議選擇 26B MoE (混合專家) 模型，它是本地推理的「甜蜜點」，避開了大型 Dense 模型帶來的記憶體頻寬瓶頸。

ROUND 2: DISSECTION | 血肉解剖

• vLLM 的系統瓶頸 (桌機環境):
  • 必須預先分配 80%-90% 的 VRAM 作為 KV Cache 池。在多用途桌機 (同時跑遊戲或 ComfyUI) 上，這會導致資源被獨佔。
  • 大模型 (如 31B) 在 BF16 全精度下，權重高達 59GB。由於記憶體頻寬限制，推理速度掉到慘不忍睹的 22 tok/s。
• Ollama 的量化紅利:
  • Q4_K_M 將 31B 的權重壓縮到 18GB，大幅緩解了 Memory-bound 問題，速度反而達到 58 tok/s，是 vLLM 的 2.6 倍。
• MoE 架構的降維打擊:
  • 26B MoE 在 vLLM 上跑出 131 tok/s，比更小的 8B Dense (124 tok/s) 還快。因為 26B MoE 每次只需啟動 ~4B 的參數，大幅降低了 Compute 與 Memory Bandwidth 的需求。

ROUND 3: SOUL | 靈魂提取

• 深層洞見: 「推理速度的真相：我們被記憶體頻寬 (Memory Bandwidth) 綁架了。」 這篇評測殘酷地揭示了 LLM 硬體架構的底層邏輯：推理不是 Compute-bound (算力瓶頸)，而是 Memory-bound。對於超過 20B 的模型，除非你是用 8 張卡並聯，否則單卡環境下「量化 (Quantization) 不是可選項，而是必選項」。同時，這也宣告了 MoE 架構在邊緣計算與本地部署上的全面勝利。

Hardware-Software Co-Design (Architectural Deep Dive)

TTFT 與 Agent 工作流的架構關聯

vLLM 在 Time To First Token (TTFT) 上取得了 3 倍的領先 (~60ms vs ~190ms)。 對於普通聊天機器人，190ms 是可以接受的。但為什麼這在 Agent 系統中致命？

• Agent Loop 放大效應：一個複雜的 Agent (例如前面提到的 Cerul 影片搜尋) 內部可能會觸發 10 到 20 次連鎖推理 (Chain of Thought -> Tool Call -> Evaluate)。
• 190ms 的延遲在一個 20 步的迴圈中，會被放大成接近 4 秒的純網路/啟動等待時間。
• vLLM 之所以能做到 60ms，是因為它的 PagedAttention 與 Continuous Batching 讓系統不需要在每次 Request 時重新啟動上下文分配，這就像是作業系統中的 Thread Pooling (執行緒池) 取代了昂貴的 Process Creation (建立行程)。

量化精度與引擎架構的不對稱比較

這篇評測帶出了一個在部署架構時常犯的盲點：「引擎速度」與「資料精度」的混淆。 Ollama 的單人 Decode 速度贏過 vLLM，並不是因為 Ollama 的 C++ 寫得比 vLLM 更好，而是因為 Ollama 預設跑 4-bit 量化，而 vLLM 預設跑 BF16 (16-bit)。 架構師在設計 Inference Server 時，必須清楚這是一個 I/O 問題： Token/s = Memory Bandwidth / Weights Size Blackwell 的頻寬是固定的 (1.8 TB/s)，權重小 4 倍 (Q4 vs BF16)，速度自然快 3-4 倍。未來的推理架構將全面轉向 NVFP4 (原生 4 浮點硬體加速) 或 AWQ/GPTQ 部署，純粹的 BF16 Dense 部署在成本上已不具備合理性。