十年前的 Xeon 伺服器，也能跑得動 260 億參數的 Gemma 4

Wed, 03 Jun 2026 00:00:00 +0000

引言：一台「不該跑 AI」的機器

這篇文章是 point.free 上一篇 Gemma 4 系列的最後一篇——前面兩篇講了怎麼把 Gemma 4 的 MTP drafter 量化、怎麼跟 verifier 配對，而這一篇要回答一個更刁鑽的問題：

「把這些成果丟到一台根本沒有資格跑 AI 的機器上，會怎樣？」

作者的硬體規格聽起來像是一台從墳墓裡挖出來的古董：

CPU：Intel Xeon E5-2620 v4（2016 年產，約為當前筆電 CPU 的五分之一慢）
記憶體：128 GB DDR3（頻寬只有最新筆電 RAM 的五分之一到六分之一）
GPU：無（連內顯都沒有）

換作一般工具，比如 ollama，直接放棄。但這篇文章的作者說：「等等，聽我說完……」

核心問題：記憶体牆（Memory Wall）

要理解這篇文章的精髓，先搞懂一個概念——LLM 推理的瓶頸不在運算能力，而在記憶體頻寬。

當你使用 ChatGPT 看著文字逐字流出時，你看到的是「decoder pass」。在這個階段，處理器要不斷把龐大的模型權重從記憶體拉進 CPU cache 才能計算下一個 token。處理器的運算速度其實很快，但它大部分時間都在等記憶體傳輸——這就叫「記憶體受限」（memory-bound），而非「運算受限」（compute-bound）。

這就是著名的「記憶体牆」問題。不管你用的是 2016 年的 Xeon 還是最新的 H100，這堵牆都在那裡。

所以，直接拿預設參數跑 llama-cli 在 DDR3 機器上會慢到令人發指。解法是什麼？把 ik_llama.cpp 能用的優化選項全部拉滿。

那串「魔法咒語」

作者甩出了一長串 llama-cli 參數，看起來像中世紀巫師的咒語：

llama-cli \
 --model gemma-4-26B-A4B-it-Q8_0.gguf \
 --model-draft wikitext-2-raw_ik-llama-mtp_drafter-conservative/gemma-4-26B-A4B-it-assistant-Q8_0.gguf \
 --spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune \
 -cnv --color --jinja --special \
 -sm graph -smgs -sas -mea 256 --split-mode-f32 \
 --temp 0.7 -t 8 --parallel 8 \
 --cpu-moe --merge-up-gate-experts \
 --flash-attn on --mla-use 3 \
 --mlock --run-time-repack --no-kv-offload

25 個參數，一半沒有文件說明，四分之一會靜默失敗。這就是作者所說的「可用性的護城河」（usability moat）——黑盒工具讓你看不見這些，但也讓你無法優化。

CPU Inference on 凱凱的技術筆記

十年前的 Xeon 伺服器，也能跑得動 260 億參數的 Gemma 4

引言：一台「不該跑 AI」的機器

核心問題：記憶体牆（Memory Wall）

那串「魔法咒語」