--- title: ベンチマーク description: 異なる2つの問いに答える2種類のベンチマーク — 実際のAPI節約量と、大規模環境における仕組みの正しさ。 sidebar: order: 7 --- リポジトリ内の `benchmarks/` には2つのベンチマークがあります。意図的に異なる種類のものなので、片方をもう片方の代替として解釈しないでください。 ## `openrouter-savings` — 実際のAPI呼び出し、実際のトークン数 OpenRouter に実際に呼び出しを行い、OpenRouter が返す実際の `total_tokens` を記録します。実際の呼び出しには費用がかかり、レート制限にもかかるため、繰り返しを含む少数の決定だけを扱うよう意図的に小さくしています。出力されるすべての数値は、実際のAPIレスポンスに基づいています。 ```bash OPENROUTER_API_KEY=sk-... pnpm --filter @runic-labs/benchmarks run start OPENROUTER_API_KEY=sk-... pnpm --filter @runic-labs/benchmarks run start -- --json ``` ファイルを編集せずに繰り返し回数を増やしてサンプルを広げるには、次のようにします。 ```bash OPENROUTER_API_KEY=sk-... REPEATS_PER_DECISION=6 pnpm --filter @runic-labs/benchmarks run start -- --json ``` 変更を加えていない実際の実行結果: ```json { "model": "openai/gpt-oss-20b:free", "decisions": 48, "uniqueDecisions": 8, "apiCalls": 8, "cacheHits": 40, "tokensSpent": 2582, "tokensSaved": 12910, "tokensWithoutRunic": 15492, "savingsPercent": 83 } ``` 48件の決定を解決し、実際の呼び出しは8回のみで、通常の方法で48件すべてを解決する場合と比べてトークン消費量は83%少なくなっています。これは推定値ではなく、OpenRouter 自身の `usage.total_tokens` から測定した結果です。 :::tip 実際のAPIキーをリポジトリにコミットしないでください。`OPENROUTER_API_KEY` は環境変数としてのみ保持してください。これは `benchmarks/openrouter-savings/index.ts` の `process.env` から読み取られ、それ以外の場所では使用されません。 ::: ## `reuse-sweep` — 合成データで、仕組みを大規模に検証 ネットワーク呼び出しは一切行いません。これは、より限定的で率直な問いに答えるためのものです。*N 件の決定と R% の再利用率が与えられた場合、キャッシュは再利用すべきエントリを正確に再利用し、台帳の記録処理は完全に正しい結果になるか？* 実際のAPIレスポンスの代わりに、決定ごとに固定かつ明示された合成コスト（320トークン）を使用します。これは正しさの証明であり、実世界での節約額の見積もりではありません。 ```bash pnpm run benchmark # 表 pnpm run benchmark -- --json # 機械可読形式 ``` ファイルを編集せずにスイープの形状を上書きするには、次のようにします。 ```bash SWEEP_DECISIONS=10,50 SWEEP_REUSE_PCTS=0,50,90 pnpm run benchmark ``` 実際の実行結果: ```txt Runic reuse-sweep (synthetic — proves the mechanism, not real-world savings) Synthetic cost per unique decision: 320 tokens decisions reuse% unique hits spent saved savings% ---------- ------- -------- -------- ---------- ---------- --------- 10 0 10 0 3200 0 0 10 25 7 3 2240 960 30 10 50 5 5 1600 1600 50 10 75 2 8 640 2560 80 10 90 1 9 320 2880 90 100 0 100 0 32000 0 0 100 25 75 25 24000 8000 25 100 50 50 50 16000 16000 50 100 75 25 75 8000 24000 75 100 90 10 90 3200 28800 90 1000 0 1000 0 320000 0 0 1000 25 750 250 240000 80000 25 1000 50 500 500 160000 160000 50 1000 75 250 750 80000 240000 75 1000 90 100 900 32000 288000 90 10000 0 10000 0 3200000 0 0 10000 25 7500 2500 2400000 800000 25 10000 50 5000 5000 1600000 1600000 50 10000 75 2500 7500 800000 2400000 75 10000 90 1000 9000 320000 2880000 90 ``` すべての規模で `savings%` 列が `reuse%` 列を1対1で追跡していることこそが重要です。これは数値を売り込むためではなく、キャッシュが主張どおりに正確に動作することを確認しています。 ## 自分のユースケースでは、どちらを信頼すべきですか？ 直接的には、どちらも信頼すべきではありません。実際の節約量は、*あなたの* エージェントが同じ決定をどれほど頻繁に再度問い合わせるかに依存します。これは `reuse-sweep` の reuse% 列でモデル化されていますが、あなた向けに予測することはできません。ワークロード固有の数値が必要な場合は、自身の実際の決定セットに対して `openrouter-savings` を実行してください。 ## 次へ - [仕組み](/how-it-works) — 両方のベンチマークが検証する署名と台帳の仕組み - [クイックスタート](/quickstart) — これを自身のエージェントに組み込み、実際の数値を取得する