39,000 个 Token 的账单，才决定模型值不值

01 / 先把“便宜”改写成一张可核对的收据

挑模型时，单看每百万 token 单价很容易得出错误结论。真正该比较的是：完成同一批任务花了多少 token，答对了多少题，返工了几次，最后每个合格结果要付多少钱。你自己的提示词、上下文长度和输出格式，才是最接近生产环境的基准。

下面这张收据只演示记账方法，数字是固定的测试输入，不代表任何模型的实际测评结果，也不代表平台当前单价。测试使用 30 条你自己的提示词：10 条代码任务、10 条结构化提取、10 条长上下文问答。每个模型使用相同的系统提示、输入、工具权限和输出上限。

02 / 一张 39,000 token 的可复算收据

• ■ 新输入：18,000 token
• ■ 缓存读取：12,000 token
• ■ 缓存写入：6,000 token
• ■ 输出：3,000 token
• ■ 计费 token 合计：39,000 token

不要把 39,000 直接乘一个统一单价，因为输入、输出、缓存读取和缓存写入可能分别计价。把控制台显示的每百万 token 价格记作 P输入、P输出、P读缓存和 P写缓存，收据就是：18,000 ÷ 1,000,000 × P输入，加上 3,000 ÷ 1,000,000 × P输出，再加上 12,000 ÷ 1,000,000 × P读缓存，以及 6,000 ÷ 1,000,000 × P写缓存。

这一步的价值在于可审计。CheapRelay 按真实 token 计费，缓存读取和写入也会进入账单；没有月费，也没有订阅费。你可以把每次运行的输入、输出、缓存数量和金额保存成 CSV，再按任务类型比较，而不是凭记忆判断哪个模型“感觉更值”。

03 / 用通过率计算每个合格答案的价格

模型质量要先定义成可检查的标准。代码题可以要求测试全部通过，提取题可以逐字段比对，长文本题可以用人工评分表检查事实、格式和遗漏。30 条任务中，只有达到标准的结果才算通过；部分正确可以单独记录，但不要偷偷算成成功。

例如，一轮运行得到 24 个合格结果，账单金额记为 C，那么每个合格结果的成本就是 C ÷ 24。第二轮得到 27 个合格结果，即使总账单更高，也可能拥有更低的单个合格结果成本。还应记录返工次数：若 3 个失败任务各重试一次，重试产生的 token 必须加入同一张收据。

04 / 把模型选择变成同一把尺子

你可以先用 Claude Sonnet 5.5 跑完整测试，再用 Gemini 3.1 Pro 跑完全相同的输入。每个模型至少运行两轮，固定随机参数，并分开记录短任务和长上下文任务。若缓存命中情况不同，也要单独标记；否则一轮大量读取缓存、另一轮全部重新输入，成本比较会失真。

最终表格只需要五列：合格数、失败数、总 token、总金额、每个合格结果成本。再加一列人工备注，记录错误类型。这个结果可能显示低价模型在提取任务上最划算，也可能显示高价模型因为少返工而更便宜。结论只对这批提示词成立，换了上下文、语言或输出要求，就应重新测量。

05 / 同一把钥匙减少了比较噪声

CheapRelay 提供一个 API 入口，可通过 OpenAI 兼容的 /v1 路由接入常见 SDK，也支持 Gemini 原生的 /v1beta 路由。这样可以把客户端、日志格式和账单记录方式固定下来，再替换模型名称，减少接入差异对结果的干扰。你可以在 CheapRelay 注册，把自己的提示词跑成一份可复核的成本表，然后按每个合格结果的价格做决定。