OpenRouter 详解智能体模型成本与质量权衡选型框架
Cost vs. Quality Tradeoff Framework for Agent Models
- 1OpenRouter 发布智能体模型选型三步框架,主张选达标的最便宜模型而非榜单最高分者
- 2框架要求先按任务定质量门槛,再在自有 20-50 条样本上按成本除以得分比较三档模型
- 3官方演示测算中 85% 门槛下 GPT-5.6 Luna 得 82 分出局,Gemini 3.7 Flash 每千次 $1.09 达标
- 4智能体每次工具调用与重试均计费,三步循环至少付三次 token 价;模型或价格变动后应重跑对比
智能体选型的实质正从追榜单最高分转向按任务门槛采购够用的能力,真实成本差要靠自有样本测出来,而不是按牌价估算。
- 影响:大批量常规任务可换便宜模型压成本;合规、医疗等高门槛任务仍要为前沿模型付费;智能体循环里每次工具调用与重试都计费,单个任务成本会数倍于单次对话。
- 参考:可考虑按任务清单各取 20-50 条自有样本,跑便宜、中档、前沿三档模型并算出每质量点成本;值得按门槛给任务分档配置模型,并在候选模型更新或调价后重跑脚本。
- 依据:方法与数字均出自 OpenRouter 官方博客,价格为其 2026-09-18 目录牌价,文中质量分为演示值,企业需以自有样本重测;无独立第三方验证。
根据排行榜排名为智能体挑选模型,会让那些更便宜的模型本可以以相同准确率完成的任务支付前沿模型的价格。要回答的问题不是哪个模型得分最高,而是哪个模型是足以胜任眼前任务的最便宜模型。
本指南是一个用于做出该决策的三步框架。你设定任务所需的质量门槛,在自己的样例上衡量每个质量点的成本,然后挑选以足够余量越过门槛的最便宜模型。
太长不看版
- 在比较模型之前,先为每个任务设定质量门槛。低于门槛的模型无论多便宜都会被淘汰。
- 在你自己的 20 到 50 个样例上分别运行一个便宜模型、一个中档模型和一个前沿模型,用同一套评分标准打分,然后将成本除以分数得到每个质量点的成本。
- 挑选以超过你在多次运行之间观察到的分数波动幅度越过门槛的最便宜模型。
- 从每个响应的
usage.cost字段读取成本,而不是用公布的费率乘以估算的 token 数量。 - 当候选模型或其价格发生变化时,重新运行该比较。
排行榜排名不会告诉你的事
排行榜将模型在与你的任务毫无关系的各种任务上的结果取平均值。在编程上排名第一的模型未必在你的结构化数据提取任务上排名第一,而在推理基准测试中表现平平的中档模型,也许能以足够的准确率回答你的 FAQ 流量,满足你的门槛。
智能体任务通常很窄,例如对工单进行分类、提取一个字段,或在模型不确定时进行升级。更便宜的模型在窄任务上能否达到与前沿模型相同的准确率是一个需要测量的问题,排行榜不会替你完成它。
智能体的成本也不止一次提示和一次响应。单次聊天补全只计费一次,而智能体要为每一次工具调用、每一个中间步骤和每一次重试付费。一个三步循环在返回答案之前至少要支付三次按 token 计的价格。如果你按排行榜排名挑选模型,可能会为某个更便宜的模型本可以以相同准确率完成的任务支付三倍的前沿模型价格。
第 1 步:定义任务所需的质量门槛
在比较任何东西之前,先确定对这项任务来说什么算“足够好”。每个任务的门槛都不同,它是后续每个步骤都要经过的过滤器。
如果错误回答会带来责任,例如在合规、医疗或法律审查中,就把门槛设高,并接受每请求更高的成本。如果任务是高流量的支持或聊天,整体结果比任何单次响应更重要。一个能正确处理 90% 的常规请求并将剩余 10% 干净地升级的更便宜模型,对该任务来说可能是可以接受的。由你决定门槛设在哪里,框架则据此进行衡量。
对延迟敏感的工作,例如欺诈检测和实时聊天,会增加第三个约束。一个便宜且准确但对任务来说太慢的模型,在谈论成本或准确率之前就已经被淘汰。
速度、成本和准确率无法同时最大化。确定你的任务有哪些约束,候选名单就会随之缩小。
如果你不知道某个任务处于什么位置,一个起点是先用中档模型处理所有任务,然后根据测量显示出问题的地方来拆分任务。中档模型超出所需的任务转向更便宜的模型,未达到门槛的任务转向更高级的模型。由测量决定每个任务需要哪个层级,而不是事先凭猜测决定。

第 2 步:在自己的示例上测量每个质量点的成本
提取你的智能体真正会接触到的文档、工单和提示词。使用你自己的流量,而不是公开数据集,也不是基准测试示例。重点在于测量你自己的任务。
在这些示例上运行一个廉价选项、一个中档选项和一个前沿选项。用一套统一的评分标准为它们打分。对于分类等确定性任务,使用与固定测试用例的精确匹配,这适用于恰好只有一个正确值的情况。对于开放式任务,使用 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,因此更换模型只是一项配置更改。base URL、密钥和 SDK 保持不变。你只需把模型字符串从 openai/gpt-5.6-luna 改成 anthropic/claude-opus-5,上面的脚本就会针对新模型运行。
你无需为想要测试的每家提供商编写新的集成,这正是你能在新版本发布的当周就对你的示例重新运行的原因。多智能体设置中的 模型路由 所依赖的也正是这种一行代码的切换。
有两点让该框架建立在真实数字之上。在你做出决定之前,我们会在 模型目录 中展示每个模型的定价,因此对比中的成本一侧从实时数据开始。而且由于每个响应都会报告 usage.cost,你测量到的支出就是我们实际计费的金额,而不是根据价目表估算的数字。
常见问题
AI 模型的成本与质量权衡是什么?
它是指一次请求的成本与模型在你的任务上表现好坏之间的权衡。速度是第三个约束条件。一个便宜又准确但对任务来说太慢的模型仍然会被排除。选择模型意味着判断任务需要多少质量并为此付费,而不是为可获得的最高分数付费。
最适合 AI 智能体的模型是什么?
没有唯一最佳的模型。适合 Agent 的模型取决于其任务需要达到的质量门槛、必须在多短的延迟内响应,以及需要处理的流量规模。一个能达到合规审查门槛的模型,其成本高于支持分诊这类任务所需,而一个便宜到足以用于分诊的模型可能达不到合规审查的门槛。
AI 模型针对 Agent 工作负载是如何定价的?
我们目录中的文本模型列出了每 token 的提示(prompt)费率和补全(completion)费率。一些端点还列出了缓存输入、推理 token、每请求收费以及 flex 或优先(priority)服务层级的费率。Agent 工作负载在首次请求之外还会增加工具调用和重试,因此单次补全的 token 价格低估了单个任务的成本。请衡量一次完整 Agent 运行的成本,并从每次响应中的 usage.cost 读取。
多 Agent 设计比单 Agent 更贵还是更便宜?
这取决于工作如何拆分。多 Agent 设计可以把路由和分类交给便宜的模型,只为需要的请求调用更昂贵的模型,这比把每个请求都发给昂贵模型的成本更低。但它也会增加请求数量,因此请衡量完整运行的成本,而不是想当然地认为拆分就能省钱。
结论
定义好门槛,在你自己的示例上衡量完整运行,并选择以超出你在多次运行之间观察到的波动幅度达到门槛的最低成本模型。保留脚本和示例集,以便在模型、价格或你的流量发生变化时重新运行对比。
参考资料
- 用量统计:了解每次响应中返回的
usage.cost字段。 - 结构化输出:了解
response_format和 JSON schema 响应。 - 服务层级:了解 flex 和优先(priority)定价。
- 模型目录:查看当前各模型的价格。
- LLM-as-a-Judge:自动为 AI Agent 输出打分:用于为开放式任务评分。
- OpenRouter 模型路由的工作原理:了解模型之间的路由。
来源:OpenRouter:Blog(Announcements) · openrouter.ai