前回「llama.cpp は GPU だと他エンジンの 1/3〜1/2 で遅い」と書いた。それは llama.cpp のバージョンが古かっただけ だった、という訂正と教訓の記事です。
ハイライト
-
同じ T4・同じモデル(LFM2.5-1.2B Q4_K_M)・同じ計測コードで、llama-cpp-python を
0.3.15→0.3.28に上げただけで decode 速度が41.9 → 175.4 tok/s＝4.2 倍になった。 - しかも新バージョンは GPUクロックがより低い (1590MHz→971MHz) のに速い。代わりに消費電力が上がった (54W→66W)＝「GPUがちゃんと働くようになった」。
- これに気づいたのは偶然。新アーキの MoE モデル(LFM2-8B-A1B)が古い wheel でロードできず、仕方なく llama.cpp を上げたら、ついでに測った 1.2B が爆速になっていた。
- 前回記事のランキング（ONNX 116 > vLLM 92 > … > llama.cpp 44）は、vLLM と ONNX は当時すでに最新版、llama.cpp だけ旧版という不公平な比較だった。揃えると llama.cpp が一気に最速になる可能性が高い。
きっかけ: 速くしようとしたのではなく、「動かなかった」
前回 LFM2.5-1.2B（dense）を 3 エンジンで測ったので、今回は本命の LFM2-8B-A1B（8.3B 総params / 1.5B active の MoE）を測ろうとしていました。
llama.cpp 用に、前回も使った prebuilt wheel（sergey21000 の v0.3.15-cu124）で GGUF をロードしようとしたら、5GB のファイルは正常にダウンロードできるのに、ロードで落ちる。
ValueError: Failed to load model from file:
.../LFM2-8B-A1B-Q4_K_M.gguf
調べると、原因は モデルのアーキテクチャ lfm2moe に llama.cpp が対応していないことでした。
- LFM2-8B-A1B は MoE で、
lfm2moeという新しいアーキテクチャ識別子を持つ - llama.cpp が
lfm2moeをサポートしたのは ビルドb6709以降（公式 GGUF リポジトリの bug report で確認） - 前回使った
llama-cpp-python 0.3.15（そしてsergey21000の wheel が出している最新0.3.16ですら 2025 年夏で止まっている）が同梱する llama.cpp は、それより古かった - 1.2B（dense の
lfm2アーキ）が 0.3.15 で動いていたのは、たまたま対応済みのアーキだったから
そこで wheel の供給元を、公式 abetlen のプリビルト index に切り替えました。ここには最新の 0.3.28 があります。
# lfm2moe(MoE) には新しい llama.cpp が必須。abetlen index から最新を入れる
# GPUランタイムは cu124、CPUランタイムは cpu
pip install --upgrade --force-reinstall "numpy<2.1" llama-cpp-python \
--extra-index-url https://abetlen.github.io/llama-cpp-python/whl/cu124
# ★インストール後はランタイム再起動が必要
これで 8B-A1B は無事ロードできた——のですが、走らせてみて速度に驚いた。前回 GPU で苦戦した llama.cpp とは別物の速さだったのです。
「まさかバージョンか？」と思って、前回 0.3.15 で測った 1.2B を、まったく同じ計測コードで 0.3.28 で測り直しました。
比較結果
計測条件は前回と完全に同一です。
| 項目 | 値 |
|---|---|
| GPU | Colab T4 (CUDA 13.0 driver / 70W cap) |
| エンジン | llama-cpp-python 0.3.15（旧）vs 0.3.28（新） |
| 量子化 | Q4_K_M（GGUF） |
| 指標 | DECODE_PROBE：greedy + EOS抑制で 固定256トークン生成の純デコード tok/s（n=5 中央値） |
旧 0.3.15 の値は、前回さんざんハマった「セッション間のブレ」を排除するため、GPUクロックを固定できていたセッション(sm>1400MHz)だけを抜き出した公平な値を使っています。
速度（T4 / Q4_K_M / 固定256tok decode）
| モデル | llama-cpp-python | decode tok/s | 消費電力 | SMクロック | VRAM | cv |
|---|---|---|---|---|---|---|
| LFM2.5-1.2B | 0.3.15（旧） | 41.9 | 54W | 1590MHz（固定） | 1.9GB | 大（セッション間） |
| LFM2.5-1.2B | 0.3.28（新） | 175.4 | 66W | 971MHz（未固定） | 2.0GB | 2.9% |
| LFM2-8B-A1B | 0.3.28（新） | 140.1 | 68W | 1172MHz | 6.1GB | 5.2% |
新バージョンの生値（1.2B, 5試行）: 176.9, 176.1, 175.4, 174.3, 164.5 — 変動係数 2.9% で安定。
倍率
- 新1.2B / 旧1.2B = 4.2 倍（41.9 → 175.4）
挙動側（系統A）の P5「1から200まで書いて」でも 37.3 → 146.5 tok/s と同じ傾向が再現したので、プローブだけの偶然ではありません。
なお 8B-A1B も新 0.3.28 で 140.1 tok/s 出ています。これはバージョン比ではなく別の発見で、8.3B 総params・Q4 で 5GB のモデルが 0.7GB の 1.2B（175.4）の 0.8 倍に収まる＝デコード速度が総params ではなく active params（1.5B） で決まる、という MoE の特性が出ています。
ここが一番不思議: 「クロックが低いのに速い」
普通、速くなったら「クロックが上がったから」と考えます。でも逆でした。
- 旧 0.3.15: クロック 1590MHzなのに 54W しか食わず 41.9 tok/s = GPUがスカスカで遊んでいる
- 新 0.3.28: クロック 971MHzで 66W 食って 175.4 tok/s = GPUが密に働いている
前回ランキングは「不公平な比較」だった
前回の結論はこうでした:
ONNX CUDA q4 = 116 > vLLM fp16 = 92 > ONNX fp16 = 59 > llama.cpp Q4 = 44 > …
ところが各エンジンのバージョンを確認すると（PyPI 最新, 2026-06 時点）
| エンジン | 前回ベンチ時 | 今の最新 | 状態 |
|---|---|---|---|
| llama-cpp-python | 0.3.15（旧） | 0.3.28 | ⬆️ これだけ古かった |
| vLLM | 0.22.1 | 0.22.1 | ✅ 当時すでに最新 |
| onnxruntime | 1.26.0 | 1.26.0 | ✅ 当時すでに最新 |
vLLM と ONNX は当時すでに最新版で測っていた。古かったのは llama.cpp だけ。つまり前回のランキングは「最新の vLLM/ONNX vs 旧 llama.cpp」という不公平な土俵でした。
新 llama.cpp を同じ土俵に乗せると:
🥇 llama.cpp 0.3.28 = 175 > ONNX 1.26.0 = 116 > vLLM 0.22.1 = 92
最下位だったエンジンが、バージョンを上げただけで最速に化ける可能性が高い。
※ ただし新 llama.cpp の 175 tok/s は現状 n=5・単一セッション1回のみ。前回さんざん書いた「Colab 単発は信用するな」を自分で破らないためにも、確定には複数セッションでの再確認が要ります（とはいえ cv 2.9% と 4.2 倍という倍率の大きさから、セッションノイズで説明できる差ではありません）。
まとめ
- 同じGPU・同じモデル・同じ量子化・同じ計測コードで、llama-cpp-python を 0.3.15 → 0.3.28 にしただけで decode 速度が 4.2 倍（41.9 → 175.4 tok/s）。
- 前回のエンジン比較は vLLM/ONNX が最新・llama.cpp だけ旧版という不公平な比較で、揃えると llama.cpp が最速に化ける。
- 教訓: 速度ベンチではエンジンのバージョンを必ず記録・固定せよ。「このエンジンは遅い」はバージョンの罠かもしれない。
計測条件: Colab T4 (CUDA 13.0 driver, 70W cap) / LFM2.5-1.2B-Instruct・LFM2-8B-A1B / Q4_K_M / DECODE_PROBE（固定256tok・greedy・EOS抑制）/ n=5 中央値。llama-cpp-python 0.3.15 と 0.3.28、vLLM 0.22.1、onnxruntime 1.26.0。