--- title: 基准测试 description: 两项基准测试回答两个不同的问题——真实 API 节省，以及大规模机制正确性。 sidebar: order: 7 --- 仓库中的 `benchmarks/` 目录包含两项基准测试，它们刻意不是同一种东西——不要把其中一项当作另一项的替代品。 ## `openrouter-savings` ——真实 API 调用，真实 token 计数 对 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 个决策相比，token 消耗减少了 83%——该数据来自 OpenRouter 自身的 `usage.total_tokens`，并非估算值。 :::tip 绝不要将真实 API 密钥提交到仓库。仅将 `OPENROUTER_API_KEY` 作为环境变量保存——它仅在 `benchmarks/openrouter-savings/index.ts` 中通过 `process.env` 读取，其他地方不会读取。 ::: ## `reuse-sweep` ——合成数据，在大规模下证明机制 完全不发起网络调用。它旨在回答一个更狭窄但诚实的问题：*给定 N 个决策和 R% 的重复率，缓存是否恰好复用了应当复用的条目，账本的记录是否恰好正确？* 它为每个决策使用固定且明确标注的合成成本（320 tokens），而非真实 API 响应——这是正确性证明，不是现实世界节省的估算。 ```bash pnpm run benchmark # table pnpm run benchmark -- --json # machine-readable ``` 无需编辑文件即可覆盖扫描的形状： ```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%` 列一一对应才是真正的重点——这确认缓存完全如其所称地工作，而不是在营销一个数字。 ## 我应该相信哪一项适用于我的用例？ 两项都不能直接照搬——你的实际节省取决于*你的*代理多久会再次询问同一个决策；`reuse-sweep` 的 reuse% 列对此进行建模，却无法替你预测。如果你想要一个针对自己工作负载的数字，请使用你自己的真实决策集运行 `openrouter-savings`。 ## 下一步 - [工作原理](/how-it-works) ——两项基准测试都会验证的签名和账本机制 - [快速开始](/quickstart) ——将其接入你自己的代理，以获得你自己的真实数据