llama.cpp 纯 CPU 跑 PLaMo 0.8B：五步命令 + 线程扫到饱和点

一台没有显卡的机器也能跑 0.8B 翻译模型：546.6 MiB 的 GGUF，4 核老机器全核 7.59 tok/s 已经能用，单线程只有 2.01。但 decode 在 8 线程就到顶 —— 因为瓶颈是内存带宽不是算力，同一台机器 prefill 却能一路涨到 20 线程。五步命令从零到出译文，附「什么机器在哪一档」的对号入座表。

这条适用于

• 一台能装 llama.cpp 的机器（x86_64 或 ARM 均可），内存 ≥ 2GB 可用
• 一个 0.5B–2B 的 GGUF 模型文件
• 不需要显卡。双路机器建议先确认 NUMA 拓扑

版本指纹

llama.cpp（llama-bench / llama-cli / llama-server）+ PLaMo 3 Translate 0.8B Q4_K_M

具体做法

【实测条件】2026-11-06 00:20–00:43。模型 plamo-3-translate-0.8b-Q4_K_M.gguf，实测 573,116,288 B（546.6 MiB），GGUF 魔数通过，llama.cpp 报 890.34 M 参数。两台机器均无显卡。

【机器 A：Xeon E5-2673 v4 @ 2.30GHz】2×20C/80T，双 NUMA，AVX2，后端 libggml-cpu-haswell.so，
绑单 NUMA node0，p128/n64/r3。
线程 → decode(64) / prefill(128)：
1 → 14.68 / 49.43
2 → 24.42 / 98.37
4 → 36.56 / 180.61
8 → 40.64 / 343.24（decode 在此饱和）
16 → 42.04 / 616.58
20 → 41.72 / 701.39
⇒ decode 8→20 线程只多 2.7%；prefill 同期翻一倍（343→701）。同一个进程里两件事走向相反，就是「decode 吃带宽、prefill 吃算力」的直接证据。

【机器 B：Celeron J3455 @ 1.50GHz】4C/4T，仅 SSE4.2 无 AVX，后端降级 libggml-cpu-sse42.so，p64/n32/r2。
1 → 2.01 / 3.16｜2 → 3.86 / 6.06｜4 → 7.59 / 12.09

【跨机对照】单线程 14.68 vs 2.01 = 7.3 倍；4 线程 36.56 vs 7.59 = 4.8 倍；4 线程相对单线程的扩展比 Xeon 2.49× vs J3455 3.78× ——老机器加核效率反而更高，因为它没有跨 NUMA 远程访问、也没有超线程抢执行单元。

【带宽解释】同机体积对照 qwen2.5-1.5b-instruct-q4_k_m（实测 1,117,320,736 B）：体积比 1.95，速度比 1.70，两者只差 14.5%；每 token 有效带宽 23.29 vs 26.67 GB/s。⇒ decode 速度 ≈ 可用内存带宽 ÷ 模型体积，只能当趋势用。拿 0.8B 反推 2B 得 12.89 tok/s，实测 17.27，误差 25.4%（层数/专家结构不同，读取量不等于文件体积）。

【内存带宽实测】每线程独立 256MB buffer 并行 copy，读写双计：T1 14.71 / T2 22.99 / T4 54.83 / T8 74.90 GB/s。⚠️ T16 185.94、T20 219.60 超过 E5-2673 v4 理论带宽 76.8 GB/s（4ch DDR4-2400）→ cache 命中污染，判为无效，可信区间只有 T1–T8。

【真实任务】llama-cli 英译中整轮 4.18 秒（生成 48.0 tok/s、prompt 231.3 tok/s），中译日 4.42 秒。⚠️ EN→ZH 指令输出了日文（内容准确、语种未听）——这是 0.8B 的真实局限，
已排除随机性。

【对号入座】2 tok/s 以下 = 看不了；2–7 = 能看但难受；7–15 = 能用（接近阅读速度）；15+ = 顺手。

【官方 GGUF 四档字节（hf-mirror API 逐文件取）】0.8B：Q2_K 391.1 / Q3_K_M 463.8 / Q4_0 522.2 / Q4_K_M 546.6 MiB。2B Q4_K_M 1723.5 MiB；8B Q4_K_M 5035.8 MiB。

【四档真实字节与体积换算】Q4_K_M 573,116,288 B = 0.573 GB（546.6 MiB）。另三档：Q2_K 410,177,946 B、Q3_K_M 486,286,394 B、Q4_0 547,565,978 B（391.1 / 463.8 / 522.2 MiB）。同机对照的 qwen2.5-1.5b-instruct-q4_k_m 是 1,117,320,736 B = 1.117 GB，同参数 decode 23.87 tok/s —— 这就是上面「体积比 1.95、速度比 1.70」那两行的原始读数。

【起 server 与端口】llama-server 默认 8080 端口，
是上下文长度。

【机器年龄与功耗口径】J3455 是 2016 年 Apollo Lake（4 核 4 线程，仅 SSE4.2）；TDP 10W。E5-2673 v4 TDP 135W。两者均为官方标称，整机实际功耗未测。

【跨 NUMA 的旧测量（同机型）】10-30 那篇在同样两台机器上量过：跨 NUMA 同 8 线程慢 19%，80 线程全开比 8 线程慢 2.66 倍。那次是 Qwen3-0.6B，这次是 PLaMo 0.8B，结论一致。

【等待时间的直观刻度】7 tok/s 这一档，1000 字译文要等 2 分钟以上 —— 所以「能用」这条线不是体感，是算出来的。

【成本账：为省钱别装】每月按 200 万 token 的翻译量算：走云端 API，按每百万输入 0.83 美元、输出 2.50 美元估，输入输出对半，一个月约 3.3 美元（23 块左右）；自己跑，J3455 整机 10W 级、一天跑 4 小时，一个月电费不到 2 块。差价 20 块左右 → 为省钱买机器算不过来。纯 CPU 跑本地的价值在「离线」和「数据不出门」：飞行模式、断网环境、不能上传的文档，这些场景云端 API 给不了。

← 返回全部排错方案