ローカルLLMを1問ずつ試すだけでは、失敗が見えない：64GBのMacで測ったこと

私たちは、コーディングエージェントの中でローカルモデルを使っています。モデルは読み取り専用のツールでファイルを読み、コードベースについての質問に答えます。こうしたモデルを確かめる普通のやり方は、1問だけ質問して答えが合っているかを見ることです。私たちは、それで本当に足りるのかを知りたいと思いました。

差が見つかったのは偶然でした。ループの中でエージェントのプロセスが標準入力を飲み込んでしまい、2問目から6問目が、5つの別々の質問ではなく、1つの大きなプロンプトとしてモデルに届いたのです。結果がはっきり違って見えたので、このまとめて渡す条件を正式なテストにしました。

この記事は、そのテストの報告です。モデルの順位づけではなく、テストの設計についてのささやかな観察です。

1問ずつのテストでは、この差は決して見えなかったでしょう。

すべて1台のマシンで、モデルは1つずつ動かしました。

MoEモデルは、トークンごとにパラメータの一部だけを使います（ここでは約3B）。denseモデルはすべてを使います。コードベースのファイル名、設定名、コードは公開しないため、タスクは一般的な言葉で説明しています。

6つの質問があり、それぞれに、人が確認した正確な答えがあります。

まず、6つの質問を1回に1問ずつ実行しました。どちらのモデルも、6問すべてに正解しました。

所要時間は、MoEが合計137.3秒、denseが合計417.4秒で、denseは3.0倍遅くなりました。ただし品質については、このテストでは違いがまったく見えませんでした。

ここで止めていたら、この作業については2つのモデルは同じくらい信頼できる、と結論づけていたはずです。

次に、同じ6問を1つの文脈にまとめ、モデルごとに3回ずつ実行しました。1モデルあたり18個の小問です。

1問ずつのテストが隠していた差が、ここではっきり現れます。

MoEは合計9/18（50%）で、全問正解の回はなく（0/3）、平均時間は170.7秒でした。denseは合計17/18（94%）で、全問正解の回は3回中2回、平均時間は362.2秒、MoEの2.12倍の遅さでした。

MoEの1回目は、標準出力にも標準エラーにも1バイトも出さないまま、187.7秒後に静かに終了しました。

正解数だけでは、実行がどう壊れたのかがわかりません。そこで、失敗の種類も記録しました。

判断を任せる役割では、無言の空実行のほうが、より有害な失敗だと私たちは考えています。

速度の話では、たいていデコード速度、つまりモデルが1秒に何トークン書けるかが使われます。しかし実際のエージェント作業にはprefillもあります。与えられたものすべて（ここではエージェントが開くファイル）をモデルが読み込む処理です。同じプロンプトで、ウォームな状態、thinkingオフにして、denseモデルについて両方を測りました。

MLXエンジンのデコードは、GGUFの約2.1倍でした。ところが6問をまとめた実行の所要時間は、ほぼ同じでした。平均はGGUFが481.7秒、MLXが492.2秒で、意味のある差はありません。実際のエージェント作業では、時間の大半はデコードではなくprefill（ファイルの読み込み）にかかります。

どちらの構成も、あとからのコード修正の影響を受けない質問には正しく答えました（下の制約を参照）。

MoEとdenseの速度比も、プロンプトによって変わります。今回のテストでは4.8倍（40.0対8.4 tok/s）、以前のテストでは7倍でした。「7倍」を一般的な数字として引用しないでください。

1. エージェントは、実際に直面する負荷の形、つまり長くまとまった文脈でテストする。1問ずつだけで終わらせない。
2. 点数だけでなく、失敗の種類を記録する：無言の空出力、項目の欠落、浅い推論、でっち上げ。
3. prefillが大半を占めるとき、デコードのtok/sは作業時間の当てにならない指標だと考える。
4. 人が確認した正解キーに対して、スクリプトで採点する。生ログは残す。
5. 環境と限界を明記する。n=3を順位表にしない。

• 小さなテストです。6問×3回×2モデル、マシン1台、コードベース1つ、各セルn=3。モデルの順位づけではなく、テスト設計についての観察です。
• ソフトウェアは先へ進んでいます。ここで使ったOllamaの構成は、その後、私たちの環境ではllama.cppに置き換わりました。モデルのファミリーはテストしたとおりに記載しており、現在は結果が違うかもしれません。現行バージョンについては何も主張しません。
• 速度の条件は、コード修正によって質問の1つ（5問目）の答えが変わったあとに実行しました。そのため、この条件は残りの5問だけで比較しています。
• ハードウェアはApple SiliconでNVIDIAではありません。他の人の環境の数字とは混ぜないでください。
• 採点は、人が確認したキーとの完全一致で行いました。最初の目視確認ではdenseの2回目のでっち上げを1つ見逃し、スクリプトで修正しました。採点は必ずスクリプトで行ってください。

私たちのコードがなくても、同じ考え方を当てはめられます。

1. 人が確認した正確な答えのあるタスクを用意し、スクリプトで採点できるようにする。
2. 各タスクを1つずつ実行し、次に、普段の実行と同じ形で1つの長い文脈にまとめて実行する。
3. 各条件を何度か繰り返し、回ごとの結果を残す。
4. 不正解の回ごとに、失敗の種類を記録する：空出力、項目の欠落、浅い推論、でっち上げ。
5. 実際の所要時間を測り、デコード速度は別に測る。
6. スクリプトで採点し、生ログを残す。
7. 環境と限界を、結果のそばに書き留める。

MoE（mixture of experts）

トークンごとに、パラメータの一部だけを使うモデル。

denseモデル

トークンごとに、すべてのパラメータを使うモデル。

prefill

モデルが、与えられたものすべて（エージェントが開いたファイルなど）を読み込む段階。

デコード

モデルが答えを1トークンずつ書き出す段階。

tok/s

1秒あたりのトークン数。デコードの速さ。

実時間（wall-clock）

実行の開始から終了までの実際の時間。prefillとデコードの合計。

完全一致

人が確認したキーと完全に同じ場合だけ、正解とする方式。