十年前的 Xeon 伺服器，也能跑得動 260 億參數的 Gemma 4
引言：一台「不該跑 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）——黑盒工具讓你看不見這些，但也讓你無法優化。 ...