私のAIエージェントが、AIエージェントのためのベンチマークツールを開発した

私のAIコーディングエージェントHermesが、ベンチマークツールを書きました。テストするのは、私のローカルモデル — つまりほかのAIエージェントが実際に動かしているのと同じモデル — の速度・知性・エージェント適性で、出力はJSONとターミナルの表です。ツールは1,660行のPythonで、名前はbench-llm。ポイントは「AIエージェントが、AIエージェントのためのベンチマークツールを開発した」という点です。

手に入るもの

1つのモデルに対してコマンド1つで、ターミナルにこう表示されます:

$ bench-llm gemma-4-31b-it

============================================================
  bench-llm — Benchmarking: gemma-4-31b-it
  GGUF Status:   READY
  GGUF Path:     /home/puppy/.lmstudio/models/google/gemma-4-31b-it-Q4_K_M.gguf
  GGUF Size:     16.5 GB
  Arch:          gemma4
  Quant:         Q4_K_M
============================================================

  🔥 Warming up model... OK (0.23s TTFT)

  ⚡ SPEED BENCHMARKS
  ----------------------------------------
    short_50 (131 chars, 3 runs)...
      TPS:  mean=84.2 median=83.8
      TTFT: mean=0.231s median=0.228s
    medium_200 (323 chars, 3 runs)...
      TPS:  mean=85.7 median=85.2
      TTFT: mean=0.312s median=0.308s
    long_800 (769 chars, 3 runs)...
      TPS:  mean=82.1 median=81.5
      TTFT: mean=0.541s median=0.537s

  🔍 Validating speed plausibility...
    Confidence: HIGH

  🧠 ABILITY TESTS
  ----------------------------------------
    Running: Code Generation (median_of_list)... PASS
    Running: Logic Puzzle (Pet Ownership)... PASS
    Running: JSON Compliance... PASS
    Running: Instruction Following... PASS
    Running: Summarization (Key Facts)... FAIL

    Ability Score: 4/5

  🤖 AGENT FITNESS TESTS
  ----------------------------------------
    Running: Task Acknowledgment... PASS
    Running: Format Adherence... PASS
    Running: Conciseness (Output/Input Ratio)... PASS

    Agent Fitness Score: 3/3

  📄 Results saved: ~/benchmarks/gemma-4-31b-it-2026-08-11.json

================================================================================
  BENCHMARK RESULTS: gemma-4-31b-it
================================================================================

  📊 SUMMARY TABLE
  ──────────────────────────────────────────────────────────────────────
  Model ID                         gemma-4-31b-it
  GGUF Size                        16.5 GB
  Architecture                     gemma4
  Quantization                     Q4_K_M
  T/s (short, mean)                84.2
  TTFT (short, mean)               0.231s
  Ability Score                    4/5 (80.0%)
  Agent Fitness Score              3/3 (100.0%)
  Confidence                       🟢 HIGH
  ──────────────────────────────────────────────────────────────────────

さらに、すべての生の計測値・各テストの応答・構造化されたサマリを含む完全なJSONペイロードを ~/benchmarks/ に書き出します。結果をエージェントに読み込ませて、「36モデルのうち、大量のJSON処理を任せるべきなのはどれ？」といった質問ができます。

何をテストするのか

常時稼働のエージェントスタックにとって重要だから選んだ、3つの軸です。

⚡ 速度

3つのプロンプト長 — 短い（約50文字、「変数とは何かを説明して」）、中（約200文字、「再帰を説明して」）、長い（約800文字、「3つのプログラミングパラダイムを比較して」）— で、3回のウォームアップのあとに本番の計測を行います。

計測するのは:

• TTFT（Time To First Token・最初のトークンまでの時間）— モデルが打ち始めるまでの時間。チャットUXの要で、500msを超えるともたつきを感じます。
• スループット（トークン/秒）— 生成を始めてからの速さ。長いコードブロックやレポートで重要です。
• プリフィルT/s — 生成前に入力プロンプトを処理する速さ。見えにくいけれど確実にかかるコストです。

既知のハードウェア上限に対する妥当性チェックも実行します。30GBのモデルが7900 XTXで200 T/sを主張していたら、bench-llm はフラグを立てます — その数字はおそらく投機的デコードか、事前に温められたキャッシュによる汚染です。

🧠 能力

有能なモデルには朝飯前で、苦戦しているモデルには見破りの決め手になる5つのテストです:

• コード生成 — median_of_list(numbers) をエッジケース付き（空リスト、偶数長、奇数長、入力を変更しないこと）で書かせます。関数は bench-llm の内部で6つのテストケースに対して実行されます — 応答テキストとのパターンマッチではなく、実際にコードを走らせます。
• 論理パズル — ペット4匹の所有パズル（Alice/魚、Bob/鳥、Carol/猫、Dan/犬）。正規表現で応答から解答の割り当てを抽出し、4つすべてをチェックします。
• JSON準拠 — 「指定したキーでJSONオブジェクトを返してください」。要求に応じて有効かつスキーマ準拠のJSONを生成できるかをテストします。ツール呼び出しの最低条件です。
• 指示追従 — 1〜10の数字を書き、偶数に*を付け、合計を求める。厳密な形式順守をテストします。答えは自明で、形式こそが本題です。
• 要約 — ヘリウムベースの量子コンピューティングに関する密度の高い段落。6つの重要事実が圧縮を生き延びたかをチェックします。ほとんどのモデルは少なくとも1つ落とします。

🤖 エージェント適性

ここが、ほかのベンチマークツールでは見たことのない bench-llm の独自機能です。モデルに本物のエージェントタスク — syslog から ERROR 行を検索し、サービスごとにグループ化してJSONレポートを生成する — を送り、エージェントの監督者のように応答を評価します:

• タスク認識 — モデルは依頼された仕事を理解しているか？ アプローチを概説し、障害を特定できるか？（いきなり syslog エントリの捏造を始めるモデルはここで落ちます。）
• 形式順守 — 出力は要求されたJSONスキーマに一致するか？ services 配列、total_errors 整数、scan_period 文字列をチェックします。
• 簡潔さ — 出力と入力の比率は？ 1,300文字のプロンプトに20,000文字の長文で答えるモデルは VERBOSE としてフラグが立ちます。簡潔にできないエージェントは、毎ターンコンテキストウィンドウを燃やし続けます。

3つのエージェント適性テストは同じプロンプトを共有しています — 同じ応答の異なる側面を評価しているのです。これにより、ベンチマークを高速に保ちながら、モデルが無人で動くときに本当に重要な性質を測定できます。

どうやって作られたか

Hermes — 私のマシン上のコーディングエージェント — が全体を書きました。私が渡したのは大まかな仕様だけです:「LM Studio のローカルモデルをベンチマークして、速度と賢さをテストし、JSONと表を出力するツールが欲しい」。Hermes は作業に取りかかり、動くスクリプトを持って戻ってきて、そこからやり取りを重ねました。

工程はこうでした:

1. 最初のパス: 速度テストのみ — LM Studio のOpenAI互換APIに接続し、トークンをストリーミングしてTTFTとT/sを計測。
2. 2回目のパス: 能力テスト — コーディング（実際の実行付き）、論理パズル、JSONスキーマ準拠、指示追従、要約。
3. 3回目のパス: エージェント適性 — syslog タスクと、あたかも自分のスタック内のエージェントであるかのような応答評価。
4. 仕上げのパス: GGUFファイルの解決（ディスク上の実際のモデルファイルを見つけ、サイズと量子化を報告）、速度の妥当性検証、サマリ表、--quick モード、モデル発見用の --list、事前チェックの --check コマンド。

4回の反復はすべて、ひとつの午後で完了しました。最終的なスクリプトは1,660行。すべての行をHermesが書き、私がレビューし、実モデルでテストし、問題を指摘し（「このスループット値は123Bモデルではあり得ない」）、Hermesが修正しました。妥当性バリデータは、まさにそうしたフィードバックループから生まれました。

採用した設計判断

• ポーリングではなくストリーミング。 bench-llm はOpenAI互換のストリーミングを使ってトークン単位のタイミングを取得します。ポーリング方式だとTTFTの計測がぼやけ、トークンレベルの粒度が失われます。
• コーディングテストは実際にコードを実行。 「median関数っぽいか」を尋ねるのではなく、サンドボックス化した名前空間で exec() し、6つのテストケースを実行します。どんなに自信満々に見える出力でも、それをすり抜けることはできません。
• 論理・JSONテストは正規表現ベースの解答抽出。 厳密な形式を要求するベンチマークは、実際の出力の前に「もちろんです！こちらが答えです:」と付け足すモデルを容赦なく落とします。bench-llm のチェッカーは、モデルがどんなラッパーで包んでも中身のペイロードを抽出します — テストしているのはモデルの内容であって、冗長さではありません。
• ベンチマーク間のVRAMクリーンアップ。 毎回 pkill llama-server を実行し、LM Studio の読み込みモデルがゼロになるのを待ってから次へ進みます。これをしないと、前のモデルのKVキャッシュが次のベンチマークのTTFT計測を汚染します。
• GGUFファイルの解決。 LM Studio のモデルIDを、パブリッシャー名とアーキテクチャのファジーマッチングでディスク上の実際のGGUFファイルに対応付けます。これでモデルのサイズ・量子化・ファイルの存在が分かり、「このモデルは本当にベンチマークできる状態か」を無駄な実行を始める前に判断できます。

セットアップ

3ステップです:

# 1. Install the one dependency
pip install openai

# 2. Make sure LM Studio is running with at least one model loaded
# (it should be listening on localhost:1234 — that's the default)

# 3. Run it
./bench-llm --list                         # see what's available
./bench-llm gemma-4-31b-it --quick         # smoke test
./bench-llm gemma-4-31b-it                 # full benchmark

これだけです。設定ファイルも、設定すべきAPIキーも（LM Studio はどんな文字列でも受け付けます）、構築するデータベースもありません。結果は自動的に ~/benchmarks/ に保存されます。

任意ですが便利: bench-llm をPATHにコピーすれば、どこからでも実行できます。

cp bench-llm ~/bin/
chmod +x ~/bin/bench-llm

自宅マシンでの実測結果

LM Studio に読み込んでいる36モデルのうちのいくつかで bench-llm を実行しました。編集なしの結果がこれです:

* DeepSeek R1 8B モデルの0.42秒というTTFTは、推論のオーバーヘッドを反映しています — 打ち始める前に考えるためで、アスタリスクはそのためです。バグではなく、アーキテクチャによるものです。

結論: 定型タスクの純粋な速度なら27BのQwenが勝者 — 91.5 T/s、TTFT 0.19秒、全項目満点。120BのNemotronは重量級 — 速度は半分ですが、すべてを完璧にこなします。DeepSeek R1 8Bはダークホース: トークンは速いものの、推論の前置きがTTFTを押し上げ、サイズが小さい分が能力テストに表れます。Dark Scarlett は「良いけれど飛び抜けてはいない」モデル — チャットには十分ですが、エージェント適性の形式順守テストを落としました。

この数字は私のハードウェア（Threadripper、RTX 3090 2枚、48GB VRAM）でのものです。あなたの環境では変わります。それこそが、このツールを持つ意味です。

何が違うのか

LLMベンチマークはたくさんあります。そのほとんどは奇妙な学術パズル（MMLU）か、リーダーボード最適化のトリビア大会です。bench-llm は、実際にローカルモデルを運用している人にとって意味のある3つのことをします:

1. チャット品質ではなく、エージェント品質をテストします。 形式順守・タスク認識・簡潔さこそ、無人で回るエージェントループでモデルの成否を分ける要素です。会話は得意でもJSONスキーマに従えないモデルは、ツール呼び出しのワークフローでは役に立ちません。
2. 自分の計測値を自分で検証します。 妥当性チェッカーが、あり得ない数字 — 投機的デコードの混入、事前に温められたキャッシュ、計測バグ — を検出します。ベンチマークツールが自分の出力のゴミを教えてくれなければ、そのどれも信頼できません。
3. スクリプト1本です。 Dockerも、データベースも、GPUドライバの依存も、50GBのデータセットのダウンロードもありません。Pythonファイル1つと pip install 1回で、いま LM Studio に読み込んでいるどんなモデルに対しても動きます。

注意点（ハマりどころ）

• LM Studio を先に起動しておくこと。 bench-llm は LM Studio を起動しません — localhost:1234 に接続するだけです。何も待ち受けていなければ、明確なエラーで失敗します。
• VRAMクリーンアップは強引です。 ベンチマークの合間に pkill llama-server を実行してKVキャッシュを消します。生かしておきたい llama-server プロセスが他にあるなら、bench-llm を実行しないか、クリーンアップの手順を変更してください。
• 要約がいちばん難しいテストです。 テストしたほぼすべてのモデルが、少なくとも1つの重要事実を落とします。要約だけを落として4/5なら、それは優秀な結果です — 欠陥と読まないでください。
• 推論モデルはTTFTが遅くなります。 DeepSeek R1 などの思考型モデルは、出力を出す前に推論フェーズに時間を使います。bench-llm はあらゆる種類の最初のトークン — 推論トークンも含む — からTTFTを計測します。そのため推論モデルは、実感よりも遅く見えます。思考トークンは、従来なら無音だった時間にストリーミングされるからです。JSON出力はTTFTを ttft_reasoning_s と ttft_content_s に分けているので、内訳を確認できます。
• コーディングテストはモデルの出力を exec() します。 新しい名前空間にサンドボックスされ、テスト関数は純粋なので爆発半径はゼロです — ただし、LLMが生成したコードを実行するという発想に抵抗があるなら、--speed-only で能力テストをスキップできます。
• 36モデルは時間がかかります。 1モデルの本番ベンチマークは速度にもよりますが2〜5分。36モデル全部だと数時間かかります。比較には --quick を使い、本番の一式は上位候補だけに回してください。

ダウンロード

bench-llm はPythonスクリプト1本とREADMEで構成されています。ビルドステップもインストールウィザードもありません — 解凍して実行するだけです。

zipの内容:

• bench-llm — 1,660行のベンチマークスクリプト
• README.md — 凝縮されたセットアップと使い方の説明

どちらのファイルも、私のコーディングエージェントHermesが書きました。スクリプトはMITライセンスです — 使うもよし、改造するもよし、自分のツールチェーンに組み込むもよし。

ダウンロード

• bench-llm をダウンロード（zip） 18 KB

個人利用は無料です。役に立ったら、コーヒーをおごってもらえると嬉しいです。