見出し画像

llama.cppの「42倍速」はドラフト作成だけの話でした。M4のMacでprompt lookupを測ったら、コード書き換えは2.2倍速、作文は1割遅くなりました

Hack-Log

r/LocalLLaMA で「llama.cpp の prompt lookup を42倍速にした」という投稿が話題になっています。

見出しだけ見ると、ローカルLLMの生成が42倍速くなるように読めます。でも元の記事を読むと、速くなったのは「ドラフト作成」という一部分だけでした。

そこで、手元のMacで prompt lookup を実際に動かして、生成全体がどれだけ変わるのかを測りました。

この記事でわかること:

  • 「42倍速」が何の数字なのか

  • M4・16GBのMacで prompt lookup を使ったときの実測値（得意なタスクと苦手なタスク）

  • そのまま試せるコマンドと、Qwen3.5系でハマった点

prompt lookup とは

投機的デコード（speculative decoding）の一種です。普通の投機的デコードは小さい別モデルに「次の数トークン」を予想させますが、prompt lookup は別モデルを使いません。プロンプトの中から、直前と同じ並びの続きを探して、それを予想として使います。

たとえば「このファイルの一部だけ直して、全体を出力して」と頼むと、出力の大半は入力のコピーです。そういうタスクでは予想がよく当たり、まとめて確定できるので速くなります。

「42倍速」の中身

元記事（https://jadidbourbaki.github.io/blog/prompt-lookup-llama-cpp/ ）で速くなったのは、この「プロンプトの中から続きを探す」処理です。

  • 541MBのコーパスを使った場合、1トークンあたりのドラフト作成が 165.48µs から 3.98µs に（約42倍）

  • メモリ使用量は最大2.6倍削減

  • 予想の当たる率（受理率）は変わらない

  • 計測環境は M4 Pro・48GB

  • 変更は作者のリポジトリ上のPRとして出されていて、本家への取り込みは記事からは確認できません

生成全体の tok/s がどう変わるかは、元記事では扱っていません。そこを測ります。

検証環境

  • Mac mini（M4・16GB・macOS 26.4）

  • llama.cpp b10964（Homebrew）

  • モデル: Gemma 4 E4B（Q4_0）

  • 温度0（毎回同じ出力になる設定）

試したコマンド

llama.cpp を Homebrew で入れていれば `llama-lookup` が一緒に入っています。

brew install llama.cpp

# 普通の生成
llama-completion -m gemma-4-E4B-it-Q4_0.gguf -f prompt.txt \
  -n 1200 --temp 0 -c 8192 -no-cnv --no-display-prompt

# prompt lookup を使った生成
llama-lookup -m gemma-4-E4B-it-Q4_0.gguf -f prompt.txt \
  -n 1200 --temp 0 -c 8192 --spec-draft-n-max 8

`llama-lookup` は終了時に `decoded ... speed: xx t/s`（生成速度）、`t_draft`（ドラフト作成にかかった合計時間）、`accept`（受理率）を表示します。

プロンプトは、Gemma 4 のチャット形式（`<|turn>user` ～ `<|turn>model`）で直接書いています。

結果1: コードの書き換え（得意なタスク）

85行のPythonファイルを渡して「print を logging.info に置き換えて、ファイル全体を出力して」と頼みました。

  • 普通の生成: 27.53 tok/s / 27.56 tok/s（2回）

  • prompt lookup: 59.16 tok/s / 59.83 tok/s（2回）

  • 受理率: 82.4%

  • ドラフト作成の合計時間: 1.65ms（生成全体は20.4秒）

約2.2倍速くなりました。 出力も、途中で打ち切った末尾以外は普通の生成と一致していて、精度が落ちるわけではありません。

一方、ドラフト作成にかかったのは20.4秒のうち1.65ms、全体の0.008%でした。ここが42倍速くなっても、縮むのは約1.6msです。今回の条件では、42倍速パッチの効果は体感できる大きさになりません。 元記事のように数百MBの静的キャッシュを使う場合はドラフト作成が重くなるので、効くのはそちらの使い方だと思います。

結果2: 自由作文（苦手なタスク）

「MacでローカルLLMを始めるときの注意点を800字ほどで」と、入力にない文章を書かせました。

  • 普通の生成: 28.05 tok/s

  • prompt lookup: 25.38 tok/s

  • 受理率: 9.4%

約1割遅くなりました。 予想がほとんど外れるので、確認のぶんだけ損をします。常時オンにする設定ではなく、「入力をほぼ写すタスク」専用と考えたほうがよさそうです。

ハマった点: Qwen3.5-4B では壊れた

最初は Qwen3.5-4B（Q4_K_M）で試しましたが、`llama-lookup` 実行中に `failed to decode` が40回出て、出力も普通の生成とずれました。ログには M-RoPE（Qwen3.5系が使う位置情報の方式）の位置が合わないというエラーが出ています。Qwen3.5系で試す場合は、出力が普通の生成と一致するかを必ず見てください。

まとめ

  • 「42倍速」は prompt lookup のドラフト作成部分の数字で、生成全体の数字ではない

  • M4・16GB・Gemma 4 E4B では、コードの書き換えが 27.5 → 59.5 tok/s（約2.2倍）、自由作文は 28.1 → 25.4 tok/s（約1割減）

  • ドラフト作成は全体の0.008%で、ここを速くしても今回の条件では差が出ない

  • Qwen3.5-4B では decode エラーが出て出力がずれた

prompt lookup 自体は本家の llama.cpp にもう入っています。ファイルの修正やリファクタのように「ほぼ写す」作業をローカルLLMに投げているなら、`llama-lookup` に差し替えて速度を見てみてください。

関連（有料）：ローカルLLMで大きいモデルを動かそうとしたときに、本当に必要なメモリがいくつになるかを実測でまとめています。


いいなと思ったら応援しよう！