前回の記事で選定した 5 モデルを、実際に数値で比較しました。使ったのは lm-evaluation-harness（EleutherAI）です。HuggingFace Leaderboard でも使われている業界標準の評価フレームワークで、Ollama の OpenAI 互換 API（localhost:11434/v1）経由で接続しました。

計測条件

項目 内容
環境 MacBook Air M3 / 24GB RAM
Ollama バージョン 0.30.6
評価フレームワーク lm-evaluation-harness（EleutherAI）
タスク GSM8K、ARC Challenge
ショット数 0-shot
問題数 各タスク limit=50

GSM8K は OpenAI が公開した小学校レベルの数学文章題（テストセット 1,319 問）、ARC Challenge は理科の多肢選択問題です。どちらも limit=50 で計測したため、5-shot・フルセットの公式スコアとは直接比較できません。あくまで相対評価として見てください。

結果

モデル GSM8K ARC Challenge 推論時間
phi4 88.0% 96.0% 約 29 分
qwen3:14b 60.0% 90.0% 約 55 分
mistral-nemo 58.0% 74.0% 約 13 分
deepseek-r1:14b 38.0% 42.0% 約 67 分
gemma4:12b 36.0% 32.0% 約 28 分

phi4 が両タスクで最高スコアを記録しました。Microsoft が合成データ学習で追求してきた「小型でも高性能」の特性がそのまま出た形です。mistral-nemo は 100 問を約 13 分で処理し、精度は中位ながらスループットのコスパが際立ちます。

詰まったポイント

計測中にいくつかの問題が出ました。後から同じことをやる人のために残しておきます。

gemma4 の空応答問題。 OpenAI 互換 API 経由だと、gemma4 の回答が content ではなく reasoning フィールドに格納されます。lm-eval はそれを空応答と判断してスコア 0% になります。カスタムパッチで reasoning フィールドを読むよう修正して解決しました。

HellaSwag は非対応。 HellaSwag は loglikelihood ベースの評価で、chat API では動きません。当初の予定から ARC Challenge に差し替えました。

出力形式の正規化。 モデルによって回答形式がまちまちです。#### 18 で終わるものもあれば、箇条書きの推論メモが続くものもあります。カスタムタスク定義で出力を正規化しないと採点がぶれます。

スリープ対策。 計測中に Mac がスリープしてジョブが止まりました。caffeinate -i で対処しています。

並列化の工夫。 当初は 5 モデル × 2 タスク = 10 ジョブを逐次実行していました。1 モデルにつき全タスクをまとめて 1 回の lm_eval 実行にまとめると、モデルロード回数が半減して合計時間が短くなります。

考察

deepseek-r1:14b は時間がかかるわりにスコアが低めという結果でした。thinking が有効になっているため推論トークンを大量に出力しますが、0-shot のスモーク設定では採点に合わせた出力形式が出にくく、phi4 や qwen3 に劣った可能性があります。推論特化モデルは評価方法との相性に注意が必要です。

gemma4:12b の ARC 32% も低い数字です。thinking モードの出力が多肢選択の形式と合わず、採点が取れなかった傾向があります。gemma4 の空応答問題をパッチで修正した後でもこのスコアなので、出力形式の問題が残っていると見ています。

qwen3:14b は GSM8K 60%・ARC 90% と、数学と理科でスコアが大きく開きました。多言語汎用モデルとしての性格が出たのか、数学文章題の形式との相性に差があるのかもしれません。

まとめ

観点 結論
精度重視 phi4
速度重視 mistral-nemo
バランス qwen3:14b

ローカル LLM のベンチマークは「動かしてみるまでわからない」部分が多く、出力形式の正規化や API の挙動差など、フレームワーク側の対処が結果に影響します。今回の数値はあくまで同一条件での相対比較として参考にしてください。