跳到正文
OpenRouter Blog·· 4 天前精选AI 评分62

OpenRouter 发布智能体模型成本与质量权衡框架

Cost vs. Quality Tradeoff Framework for Agent Models

AI 导读

OpenRouter 发布一套三步框架,用于为智能体任务挑选够用且最便宜的模型:先按任务设定质量门槛,再用自己 20 到 50 条真实样本跑便宜、中端、前沿三档模型并统一打分,用成本除以得分得到单位质量成本,最后选以超过运行波动幅度越过门槛的最便宜模型。

推荐理由

OpenRouter 给出的三步选型框架把质量门槛、单位质量成本和运行波动串成可复用的测量流程,适合需要为智能体任务定模型的团队参考。

正文 · AI 翻译

按排行榜排名为智能体挑选模型,会让你以顶级模型的价格去处理那些更便宜的模型也能以相同准确率完成的任务。要回答的问题不是哪个模型得分最高,而是哪个模型是足够便宜、又能胜任你眼前任务的那一个。

本指南是一个三步框架,帮你做出这个判断。你为任务设定所需的质量门槛,在你自己的样本上测量每个质量点的成本,然后选出以一定余量越过门槛的最便宜模型。

简而言之

  • 在比较模型之前,先为每项任务设定质量门槛。低于门槛的模型无论多便宜都直接淘汰。
  • 在你自己的 20 到 50 个样本上运行一个便宜模型、一个中端模型和一个顶级模型,用同一套评分标准打分,再用成本除以得分,得到每个质量点的成本。
  • 选出以超过你观察到的多次运行间得分波动幅度的余量越过门槛的最便宜模型。
  • 从每次响应的 usage.cost 字段读取成本,而不是用标价费率乘以估算的 token 数量。
  • 当候选模型或其价格发生变化时,重新运行比较。

排行榜排名无法告诉你的事

排行榜是在与你的任务毫无关系的各种任务上对模型结果取平均。在编程上排名第一的模型,未必在你的结构化数据提取任务上排第一;而一个在推理基准上看起来平平无奇的中端模型,可能对你的 FAQ 流量回答得足够准确,达到你的门槛。

智能体任务往往很窄,比如对工单分类、提取某个字段,或在模型不确定时升级处理。更便宜的模型能否在窄任务上达到与顶级模型相同的准确率,这是一个需要测量的问题,排行榜不会替你测。

智能体的成本也不只是一次提示和一次响应。单次聊天补全只计费一次。而智能体要为每一次工具调用、每一个中间步骤和每一次重试付费。一个三步循环在返回答案之前,至少要按每 token 价格付费三次。如果你按排行榜排名来选,就可能为一个更便宜的模型本可以以相同准确率处理的任务,付出三倍的顶级模型价格。

第 1 步:定义任务所需的质量门槛

在比较任何东西之前,先确定对这项任务来说什么算足够好。门槛因任务而异,而它是后续每一步都要经过的筛选器。

如果错误答案会带来责任风险,比如在合规、医疗或法律审查中,就把门槛设高,并接受更高的单次请求成本。如果任务是高并发的支持或聊天,整体结果比任何单次响应都更重要。一个更便宜的模型如果能正确解决 90% 的常规请求,并干净利落地升级处理剩下的 10%,对那项任务来说可能就是可接受的。门槛设在哪里由你决定,框架则据此进行衡量。

对延迟敏感的工作,比如欺诈检查和实时聊天,会增加第三个约束。一个便宜且准确、但对任务来说太慢的模型,在成本和准确率被考虑之前就已经被淘汰。

速度、成本和准确率无法同时最大化。确定你的任务有哪些约束,候选名单就会缩小。

如果你不知道某项任务处于什么位置,一个起点是先用中端模型处理所有任务,然后根据测量结果显示问题所在来拆分任务。中端模型超出所需的任务,转向更便宜的模型。中端模型达不到门槛的任务,向上提升。由测量而非事先的猜测来决定每项任务需要哪个层级。

Diagram of a cost-per-request versus quality scatter. Three regions labeled cheap, mid-tier, and frontier rise from bottom-left to top-right. A dashed horizontal line marks the task's quality bar. One point in the cheap region sits just above the bar and is labeled as the pick, the cheapest model above the bar.

第 2 步:在你自己的示例上衡量每个质量点的成本

拿出你的智能体真正会看到的文档、工单和提示词。使用你自己的流量,而不是公开数据集,也不是基准示例。重点在于衡量你的任务。

在这些示例上分别运行一个便宜选项、一个中端选项和一个前沿选项。用一个一致的评分标准给它们打分。对于分类这类确定性任务,使用与固定答案的精确匹配,这适用于只有一个值正确的情况。对于开放式任务,使用 LLM 作为评判者来给质量打分。我们的LLM 作为评判者指南介绍了如何设置。当每个候选模型返回相同形状的输出时,评分会更容易,这正是结构化输出和 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.3282$0.0039否(−3)
google/gemini-3.7-flash$0.75 / $3.75$1.0989$0.0122是(+4)
anthropic/claude-opus-5$5.00 / $25.00$7.2597$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、按请求收费以及 flex 或 priority 服务层级的费率。Agent 工作负载会在首次请求之上增加工具调用和重试,因此单次补全的 token 价格低估了一项任务的成本。要衡量完整 agent 运行的成本,并从每次响应中的 usage.cost 读取它。

多 agent 设计比单 agent 更贵还是更便宜?

这取决于工作如何拆分。多 agent 设计可以把路由和分类交给便宜的模型,只对需要它的请求调用更贵的模型,这比把每个请求都发给贵模型成本更低。但它也会增加请求数量,所以要衡量完整运行,而不是想当然地认为拆分就能省钱。

结论

定义标准,在你自己的示例上衡量完整运行,并选择成本最低、且超出标准幅度大于你在多次运行之间观察到的波动的模型。保留脚本和示例集,这样当模型、价格或你的流量发生变化时,你可以重新运行对比。

参考资料

来源:OpenRouter Blog · openrouter.ai