在舊款 Xeon 硬體上執行 Gemma 4 26B

在舊款 Xeon 硬體上執行 Gemma 4 26B

Google 的 Gemma 4 26B 混合專家 (MoE) 模型可以在沒有 GPU 的情況下，於 13 年前的 Ivy Bridge Xeon CPU 上以每秒約 5 個 token 的速度運行。這是透過在 ik_llama.cpp 推論引擎中為 AVX2 和 FMA3 指令集實作純量回退 (scalar fallbacks)，從而使現代 MoE 架構能夠在舊款企業級硬體上運行而實現的。

硬體與效能基準測試

在 2013 年的硬體上執行一個 260 億參數的模型，證明了記憶體頻寬而非原始運算指令，才是舊系統上本地 LLM 推論的主要瓶頸。

系統規格：

  • 硬體： 再利用的 HP StoreVirtual 儲存盒
  • CPU： 雙 Intel Xeon E5-2690 v2 (Ivy Bridge, 2013)
  • 指令集： 僅 AVX1 (無 AVX2, 無 FMA3)
  • RAM： DDR3
  • GPU： 無
  • 總硬體成本： 低於 300 美元

效能指標 (Gemma 4 26B-A4B, Q8_0)：

  • 解碼速度： ~5.2 tokens/sec
  • 提示詞評估 (Prompt Evaluation)： ~16 tokens/sec

技術挑戰：AVX2 指令集差距

現代高效能推論核心 (kernels)，包括 ik_llama.cpp 分支中的核心，通常假設硬體最低門檻為 AVX2 和 FMA3 (於 2014 年隨 Intel 的 Haswell/v3 世代推出)。Ivy Bridge (v2) CPU 缺乏這些指令，當軟體嘗試執行不存在的 CPU 指令時，會導致立即的編譯失敗或執行時崩潰。

雖然在編譯時停用 GGML_USE_IQK_MULMAT 會強制大部分程式碼庫回退到純量或 SSE 數學運算，但 Gemma 4 MoE 前饋網路 (FFN) 中的某些圖形運算 (graph operations) 仍然存在問題。具體而言，圖形建構器會發出 MOE_FUSED_UP_GATE 和 FUSED_UP_GATE 運算，但在非 AVX2 編譯版本中，調度器 (dispatcher) 缺乏對應的運算路徑。這導致了靜默失敗 (silent failure)，即每個專家 FFN 的目標張量 (destination tensors) 從未被計算，導致模型處理未初始化的記憶體。

解決方案：實作純量回退

為了修復此靜默損壞並實現與前 AVX2 硬體的相容性，在一個補丁 (作為 PR #2138 提交至 ik_llama.cpp) 中實作了三個主要的修改：

1. 修正純量編譯路徑

在 iqk_quantize.cpp 中的幾個純量 #else 分支錯誤地引用了 AVX2 輔助函式，例如 hsum_i32_8。這些被重寫為可移植的純量迴圈，並添加了 #if GGML_USE_IQK_MULMAT 保護，以防止 AVX2 特有的 IQK 呼叫洩漏到編譯中。

2. 修復執行時調度器錯誤

與其修改調度器，不如更新圖形建構器以發出在舊款硬體上具有現有運算路徑的運算。當 GGML_USE_IQK_MULMAT 被停用時：

  • 合併的 up_gate_exps 張量被拆分為兩個 ggml_view_3d 切片。
  • 執行兩個獨立的 ggml_mul_mat_id 呼叫。
  • 結果使用 ggml_fused_mul_unary(gate, up, SILU) 進行合併。

這種方法利用了標準的 GGML 實作 (mul_mat_id 和 fused_mul_unary)，確保 MoE 層可以正確運算而不需 AVX2 融合核心 (fused kernels)。

3. CI 與編譯系統存根 (Stubs)

為了確保測試套件可以在非 AVX2 硬體上執行，修正了 IQK 源碼中 #else 存根部分的缺失 <cstdint> 包含以及錯誤的函式簽名，以使其與 iqk_mul_mat.h 相符。

部署限制與注意事項

嘗試在非 AVX2 硬體上重現這些結果的使用者必須遵守以下限制：

  • 停用執行時重新打包 (Run-Time Repacking)： 必須省略 --run-time-repack 旗標。此功能會將量化權重重新排序為交錯佈局 (Q8_0_R8)，這僅限於 AVX2；在 AVX1 硬體上使用它會導致輸出錯誤。
  • 編譯配置： 專案必須使用 GGML_USE_IQK_MULMAT=off 進行編譯。

社群對本地舊款硬體推論的看法

技術使用者之間的討論突顯了本地推論的教育/隱私價值與雲端供應商的經濟現實之間的緊張關係。

"我估計伺服器在推論期間可能消耗大約 500W... 因此，在本地推論 18k tokens 的成本為 0.15 美元，這比使用推論供應商的成本高出 30 倍。"

雖然舊款硬體使用電力成本可能超過 API token 的成本，雖然支持者認為，此設定的主要驅動因素是數據隱私與在付費 API 不可用時維持本地備援的能力。

Sources