前回「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。