OpenRouter 发布 Agent 模型成本与质量权衡选型框架
Cost vs. Quality Tradeoff Framework for Agent Models
OpenRouter 发布一个三步框架,用于为 Agent 任务选出以最低成本达到质量门槛的模型,而不是按排行榜排名选最高分模型。方法是先按任务设定质量门槛,再用 20 到 50 条自己的示例运行廉价、中档和前沿模型并用统一评分标准计算每质量点成本,最后选出以超过运行间分数波动的余量过线的最便宜模型。
原文给出可复用的三步选型方法,读者可以据此按任务质量门槛测量并选出成本最低的够用模型。
按排行榜排名为智能体挑选模型,会让前沿模型的高价花在更便宜的模型也能以同等准确率处理的任务上。要回答的问题不是哪个模型得分最高,而是哪个模型是足够便宜、又足以胜任你面前这个任务的那一个。
本指南是一个三步框架,帮你做出这个判断。你为任务设定所需的质量门槛,在你自己的样本上衡量每个质量点的成本,然后选出以一定余量越过门槛的最便宜模型。
太长不看
- 在比较模型之前,先为每个任务设定质量门槛。低于门槛的模型无论多便宜都直接淘汰。
- 在你自己的 20 到 50 个样本上运行一个便宜模型、一个中端模型和一个前沿模型,用同一套评分标准打分,再用成本除以得分,得到每个质量点的成本。
- 选出以超过你观察到的多次运行间得分波动的余量越过门槛的最便宜模型。
- 从每次响应的
usage.cost字段读取成本,而不是用标价费率乘以估算的 token 数。 - 当候选模型或其价格发生变化时,重新运行比较。
排行榜排名不会告诉你的事
排行榜是在与你的任务毫无关系的各种任务上对模型结果取平均。在编程上排名第一的模型,未必在你的结构化数据提取任务上排第一;而一个在推理基准上看起来平平无奇的中端模型,可能对你的 FAQ 流量回答得足够准确,达到你的门槛。
智能体任务往往很窄,比如给工单分类、提取一个字段,或在模型不确定时升级处理。更便宜的模型在窄任务上能否达到与前沿模型相同的准确率,这是一个需要测量的问题,排行榜不会替你测。
智能体的成本也不只是一次提示和一次响应。一次聊天补全只计费一次。而智能体要为每一次工具调用、每一个中间步骤和每一次重试付费。一个三步循环在返回答案之前,至少要按每 token 价格付费三次。如果你按排行榜排名来选,就可能为一个更便宜的模型本可以以同等准确率处理的任务,付出三倍的前沿模型价格。
第 1 步:定义任务所需的质量门槛
在比较任何东西之前,先确定对这个任务来说什么算足够好。每个任务的门槛都不同,而它是后续每一步都要经过的筛选器。
如果错误答案会带来责任风险,比如在合规、医疗或法律审查中,就把门槛设高,并接受更高的单次请求成本。如果任务是高并发的支持或聊天,整体结果比任何单条响应都更重要。一个更便宜的模型如果能正确解决 90% 的常规请求,并干净地升级处理剩下的 10%,对这个任务来说可能就是可接受的。门槛设在哪里由你决定,而框架会对照它来衡量。
对延迟敏感的工作,比如欺诈检查和实时聊天,会增加第三个约束。一个便宜且准确、但对任务来说太慢的模型,在成本和准确率被考虑之前就已经被淘汰了。
速度、成本和准确率无法同时最大化。确定你的任务有哪些约束,候选名单就会缩小。
如果你不知道某个任务处于什么位置,一个起点是先用中端模型处理所有任务,然后根据测量结果显示问题所在来拆分任务。中端模型超出所需的任务,转向更便宜的模型。中端模型达不到门槛的任务,向上提升。由测量而非事先猜测来决定每个任务需要哪个层级。

第 2 步:在你自己的示例上衡量每个质量点的成本
拿出你的 agent 真正会看到的文档、工单和提示词。使用你自己的流量,而不是公开数据集,也不是基准示例。重点是要衡量你的任务。
在这些示例上分别运行一个廉价选项、一个中端选项和一个前沿选项。用一套一致的评分标准给它们打分。对于分类这类确定性任务,使用与固定答案的精确匹配,这适用于只有一个值正确的情况。对于开放式任务,使用 LLM 作为评判者来给质量打分。我们的 LLM-as-a-judge 指南 介绍了如何设置。当每个候选模型返回相同形状的输出时,评分会更容易,这正是 结构化输出和 response_format 的用途。
用模型每 1,000 次请求的成本除以其质量得分,你就得到了一个可以直接在候选模型之间以及不同规模的测试集之间比较的每个质量点成本。把它写成一个简短的脚本,只需替换一个模型字符串,并从每个响应的 usage 对象中读取每次请求的成本。我们在每个非流式响应以及每个流式响应的最后一条消息中都会返回 usage 对象,无需任何额外的请求参数,如 用量核算文档 中所述。usage.cost 是我们就该请求向你账户收取的金额,单位为美元。OpenAI Python SDK 会保留它未定义的响应字段,因此 r.usage.cost 可作为属性使用。
import json
import os
from openai import OpenAI
client = OpenAI(
base_url="https://openrouter.ai/api/v1",
api_key=os.environ["OPENROUTER_API_KEY"],
)
ROUTING_PROMPT = open("routing_prompt.txt").read()
test_set = json.load(open("test_set.json")) # 20-50 of your own {"ticket": ..., "label": ...} examples
candidates = [
"openai/gpt-5.6-luna",
"google/gemini-3.7-flash",
"anthropic/claude-opus-5",
]
for model in candidates:
total_cost, correct = 0.0, 0
for ex in test_set:
r = client.chat.completions.create(
model=model,
messages=[
{"role": "system", "content": ROUTING_PROMPT},
{"role": "user", "content": ex["ticket"]},
],
)
total_cost += r.usage.cost
answer = (r.choices[0].message.content or "").strip()
correct += int(answer == ex["label"])
score = correct / len(test_set)
points = score * 100
cost_per_1k = total_cost / len(test_set) * 1000
cost_per_point = cost_per_1k / points if points else float("inf")
print(f"{model}: score={score:.0%} cost/1K=${cost_per_1k:.2f} cost/point=${cost_per_point:.4f}")响应可能不包含任何文本内容,例如当模型拒绝时,因此脚本将缺失的内容视为空答案,将其计为不正确,并将其成本计入总数。得分为零的模型没有每个质量点的成本,因此脚本会为其打印 inf,而不是除以零。
下面是一个支持路由任务的完整示例。假设每个请求发送约 700 个输入 token(工单加上一段简短的系统提示词),并返回约 150 个输出 token。每 1,000 次请求的成本为 (700 / 1M × input price) + (150 / 1M × output price),乘以 1,000。每个质量点的成本就是该成本除以质量得分。
这些价格是我们 模型目录 中 2026-09-18 列出的 GPT-5.6 Luna、Gemini 3.7 Flash 和 Claude Opus 5 的价格。它们是目录列出的模型级价格。各个提供商端点以及 flex 和 priority 服务层级 按各自的费率计费,而 GPT-5.6 Luna 对提示词 token 达到 272,000 或以上的请求按更高的费率计费。token 数量和质量得分仅作示例。你自己的运行会替换它们。
| 模型 | 输入/输出价格(每百万 token) | 成本 / 1K 请求 | 质量得分 | 成本 / 质量点 | 是否达到 85% 门槛? |
|---|---|---|---|---|---|
openai/gpt-5.6-luna | $0.20 / $1.20 | $0.32 | 82 | $0.0039 | 否(−3) |
google/gemini-3.7-flash | $0.75 / $3.75 | $1.09 | 89 | $0.0122 | 是(+4) |
anthropic/claude-opus-5 | $5.00 / $25.00 | $7.25 | 97 | $0.0747 | 是(+12) |
按框架运行的顺序阅读表格。首先以门槛为关卡。在 85% 的门槛下,GPT-5.6 Luna 以 82 分被淘汰,因此其较低的每个质量点成本无关紧要。低于门槛的模型无论每个质量点多么便宜都会被取消资格。这样就剩下 Gemini 3.7 Flash 和 Claude Opus 5。
在通过门槛的两者之间,选择更便宜的那个。Gemini 3.7 Flash 每 1,000 次请求花费 $1.09。Claude Opus 5 花费 $7.25,换来的却是任务并不需要的得分。Gemini 3.7 Flash 是首选,它以 4 分的余量通过门槛。
改变情况,答案就会改变。如果一次错误路由意味着错过 SLA,而你把门槛设为 95%,那么只有 Claude Opus 5 能通过,你就得支付 $7.25。目标不是选择得分最高的模型。而是要知道哪个模型能以最少的钱通过你的门槛,并看清当你伸手去够更高标准时要付出的差距。
第 3 步:选择能以余量越过门槛的最便宜模型
选择能以余量越过门槛的最便宜模型,而不是直接胜出的模型。余量很重要,因为数字会变动。
模型得分会随着提供商更新权重而漂移,你自己的流量也会随时间变化,新版本还会改变局面。余量应来自观察,而不是选定一个固定百分比。多次运行候选模型,或在一批新流量上运行,记录得分在多次运行之间的波动幅度,并要求胜出者越过门槛的幅度大于这一观察到的波动。
一个只在单个小样本上刚好达到门槛的模型,在你确定采用它之前,应当先越过更高的内部目标,这样普通的波动才不会在生产中把它推到门槛以下。
应用到几个任务上,这个框架大致如下。成本数字使用与上表相同的标价,输入和输出 token 大小按每行标注。质量门槛仅为示例,你记录的成本来自 usage.cost。
| 任务 | 质量门槛 | 能越过门槛的最便宜层级 | 成本 / 1K 请求 |
|---|---|---|---|
| 支持工单分流(700 输入 / 150 输出 token) | 80% | 便宜,openai/gpt-5.6-luna | $0.32 |
| 代码审查(4,000 输入 / 1,000 输出 token) | 88% | 中端,google/gemini-3.7-flash | $6.75 |
| 合规审查(3,000 输入 / 600 输出 token) | 95% | 前沿,anthropic/claude-opus-5 | $30.00 |
每一行的方法相同,答案不同是因为门槛不同。测得的权衡在你测量的那一天是成立的。当有更新的模型发布时要重新检查,因为昨天越过你门槛的模型,现在可能和刚好低于门槛的模型价格相同。
当模型或价格变化时重新检查对比
新模型发布频繁,现有模型的价格也会变化。2026 年 5 月到 9 月间,我们的目录新增了四个 Gemini Flash 版本:2026-05-19 的 Gemini 3.5 Flash、2026-07-21 的 Gemini 3.6 Flash、2026-08-13 的 Gemini 3.7 Flash,以及 2026-09-02 的 Gemini 3.8 Flash。几个月前做的对比可能已经过时,所以每当候选模型更新或其定价变化时都要重新运行。
在我们这边重新运行很便宜。我们提供一个 OpenAI 兼容 API,因此更换模型只是改配置。基础 URL、密钥和 SDK 保持不变。你把模型字符串从 openai/gpt-5.6-luna 改成 anthropic/claude-opus-5,上面的脚本就会针对新模型运行。
你不需要为每个想测试的提供商编写新的集成,这正是让在新版本发布当周就能针对它重新运行你的示例变得可行的原因。同样的单行替换,也是多智能体设置中 模型路由 所依赖的。
有两件事让这个框架立足于真实数字。在你确定之前,我们会在 模型目录 中展示每个模型的定价,因此你对比中的成本一侧从实时数据开始。而且由于每个响应都会报告 usage.cost,你测得的支出就是我们实际计费的金额,而不是根据费率卡估算出来的。
常见问题
AI 模型的成本与质量权衡是什么?
它是请求成本与模型在你的任务上表现好坏之间的权衡。速度是第三个约束。一个便宜且准确但对任务来说太慢的模型仍然出局。选择模型意味着决定任务需要多少质量并为此付费,而不是为可获得的最高分付费。
什么是最适合 AI 智能体的模型?
没有单一的最佳模型。适合某个 agent 的模型取决于其任务必须达到的质量标准、必须满足的延迟要求以及必须处理的请求量。一个能达到合规审查标准的模型,其成本高于支持工单分诊这类任务所需;而一个便宜到足以用于分诊的模型,可能达不到合规审查的标准。
AI 模型针对 agent 工作负载是如何定价的?
我们目录中的文本模型会列出每 token 的提示词费率和补全费率。部分端点还会列出缓存输入、推理 token、按请求收费以及弹性或优先服务层级的费率。Agent 工作负载会在首次请求之上增加工具调用和重试,因此单次补全的 token 价格低估了一个任务的成本。要衡量完整 agent 运行的成本,并从每次响应中的 usage.cost 读取它。
多 agent 设计比单 agent 更贵还是更便宜?
这取决于工作如何拆分。多 agent 设计可以将路由和分类交给便宜的模型,只对需要处理的请求调用更贵的模型,这比把每个请求都发给贵模型成本更低。但它也会增加请求数量,所以要衡量完整运行,而不是想当然地认为拆分就能省钱。
结论
定义标准,在你自己的示例上衡量完整运行,并选择成本最低且超出标准幅度大于你在多次运行之间观察到的波动的模型。保留脚本和示例集,以便在模型、价格或你的流量发生变化时重新运行比较。
参考资料
- 用量计费,用于每次响应中返回的
usage.cost字段。 - 结构化输出,用于
response_format和 JSON schema 响应。 - 服务层级,用于弹性和优先定价。
- 模型目录,用于当前的各模型价格。
- LLM-as-a-Judge:自动为 AI Agent 输出评分,用于为开放式任务评分。
- OpenRouter 模型路由的工作原理,用于在模型之间进行路由。
来源:OpenRouter:Announcements(RSS) · openrouter.ai