純 CPU 推論
純 CPU 推論是可行的，數字也不像傳說中那麼令人沮喪——只要你明白它跟 GPU 解碼玩的是同一場頻寬遊戲，只是管道只有十分之一。現代雙通道 DDR5 桌機有約 80–100 GB/s 的記憶體頻寬。那就是你全部的預算；CPU 核心本身改變不了多少。
公式與試算
decode tok/s ≈ effective bandwidth (GB/s) ÷ model size (GB)
雙通道 DDR5-5600 紙上約 90 GB/s；核心與預取器分走份額後，算它有效 60–80 GB/s。8B Q4 模型約 5 GB，所以：
90 GB/s ÷ 5 GB ≈ 18 tok/s 理論上限 → 實際 8–14 tok/s。
那不是 bug——它跟大型獨立 GPU 用的是同一套算術，只是頻寬剩十分之一。
各硬體的預期表現
| 平台 | 大約頻寬 | 8B Q4 解碼 | 感覺 |
|---|---|---|---|
| 筆電，DDR4 雙通道 | 40–50 GB/s | 5–8 tok/s | 讀得動，起步慢 |
| 筆電，DDR5 雙通道 | 60–80 GB/s | 8–12 tok/s | 可用的對話 |
| 桌機，DDR5 雙通道 | 80–100 GB/s | 10–16 tok/s | ≤8B 蠻舒服 |
| Threadripper/EPYC，四通道以上 | 200–460 GB/s | 30–80 tok/s | 真的不錯 |
| 雙插槽伺服器 | 400+ GB/s | 60–100 tok/s | 幾乎是記憶體 GPU |
雙通道桌機上的舒適等級：
- 舒適：7–8B Q4 對話與程式協助，10+ tok/s。
- 可用：13–14B Q4，約 5–8 tok/s。要等，但不至於天荒地老。
- 要有耐心：24–32B Q4，約 2–4 tok/s。適合隔夜批次，不適合對話。
- 別：雙通道上 70B Q4 低於 1 tok/s。只有四通道工作站勉強，而且即使如此也要三思。
逃生口：部分卸載
如果有一張小 GPU，llama.cpp 會把層拆給 CPU 與 GPU——例如 32 層中的 20 層放到 8 GB 卡上。駐留在 GPU 的部分以 VRAM 頻寬跑，其餘以 RAM 頻寬跑，速度落在兩個極端之間。當權重在哪都放不下完整的時，它勝過任一純模式；也勝過看著「完整 GPU 卸載」狂打進共享記憶體。
預填才是真正的痛
解碼搶走所有目光，但 CPU 真正痛的地方是預填：它是運算受限的，而桌機 CPU 的 FLOPs 只有 GPU 的零頭。8B 模型上一個 4,000 token 的提示詞，可能在第一個 token 出現前就要花數十秒。注入大量上下文的 RAG 式管線，每個請求都要付這個代價。緩解方式：提示詞保持簡短、批次預填給比解碼多的執行緒、並把索引當一次性成本（見 RAG）。
實用旗標
# 解碼執行緒 = 實體核心；批次預填也可用邏輯核心
llama-server -m qwen2.5-7b-instruct-q4_k_m.gguf -c 8192 -t 8 --threads-batch 16
# 多插槽主機：讓記憶體在 NUMA 節點間交錯
numactl --interleave=all ./llama-server -m model.gguf -t 32
# 這顆 CPU 有哪些 SIMD？AVX2 是底線；AVX-512 對預填有幫助
lscpu | grep -o 'avx[0-9a-z_]*' | sort -u
-t設為實體核心數在解碼上通常勝過邏輯／SMT 數；在你的機器上兩者都測，交叉點因工作負載而異。- AVX2 是各地的底線；AVX-512（Zen 4/5、近期的 Xeon）對預填有實質助益。llama.cpp 在建置時偵測支援。
- 在多插槽機器上，NUMA 綁定可以值 20% 以上——遠端插槽上的記憶體就是慢記憶體。
- 筆電 DDR4 的頻寬大約是桌機 DDR5 的一半。同一條公式、更差的常數：桌機給 12 的地方，預期 5–8 tok/s。
純 CPU 何時真的是正解
- 嵌入與 RAG 索引——重要的是吞吐量而非延遲；隔夜花幾小時做區塊嵌入是免費的。
- 腳本裡的極小模型——0.5–3B 的分類器、抽取器與重排序器，即使在 CPU 上也是數十毫秒就回應。
- 背景批次工作——趁你睡覺時用 3 tok/s 消化積壓的摘要；沒有人在看串流。
- 買前試用——在砸錢買 GPU 之前，先驗證某個模型家族到底做不做得到。
如果目標是互動對話而且手上有任何 GPU，就把模型放上去。用 第一次執行 今天就開始，用 速度 弄懂你看到的數字是什麼意思。