如何评估新一代大模型：能力、成本与可用性

一、发布潮之下，老坐标系为什么失灵了

大模型的发布节奏已经明显加快。每当有新旗舰登场，社区讨论几乎总被同一套叙事占据：参数规模多大、上下文窗口多长、在某榜单排第几、距离最强闭源模型还差几个点。这套叙事在早期确有价值——当时模型之间的能力差距是数量级的，名次基本决定了可用性。

但如今头部模型的公开基准差距普遍收缩到个位数百分点，甚至落入评测误差范围内；与此同时，价格竞争把不同梯队模型的单价差距拉大到数倍。这意味着两件事：

1. 能力名次的信息含量在下降。 当差距小于评测误差范围时，“第四名”和“第二名”在统计上已无法区分。
2. 成本与供给稳定性的权重在上升。 当一个模型完成同一任务的综合成本只有另一家的几分之一，“追到哪一步了”就不再是工程团队最关心的问题。

因此，围观一次新模型发布，建议把阅读顺序调整为：先看价格表，再看能力表，最后看发布几天之后的服务状态公告。前两张表决定“值不值得试”，第三张表决定“敢不敢用”。下文按这个顺序展开。

二、第一张表：能力基准——用来初筛，不是终审

2.1 公开基准的正确打开方式

第三方评测机构发布的综合榜单与专项基准（如终端任务、代码生成、长文本理解类）仍有价值，但应当作初筛工具而非终审结论。使用时注意三点：

• 看差距，不看名次。 两个模型相差 0.7 个百分点与相差 7 个百分点，是完全不同的结论。前者应视为“同档”，后者才构成代差。
• 看子项，不看总分。 综合榜会平滑掉结构性差异。如果业务以代码任务为主，就只看代码类子项；以长文档处理为主，就只看长文本子项。总分高的模型完全可能在你的核心场景上落后。
• 警惕数据污染。 主流基准的题目可能已进入训练语料，高分存在“背题”的可能。判断方法之一是观察该模型在较新、较小众基准上的表现是否与老基准一致。

2.2 自建评测集：把“我的任务”变成基准

公开基准与真实业务之间总有一条鸿沟：基准测的是“模型一般擅长什么”，业务要的是“我的任务能不能完成”。补齐这条鸿沟只有自建评测集一条路，要点包括：

1. 任务画像对齐：样本的输入长度、输出格式约束、领域术语分布应与生产流量一致；
2. 分层抽样：按难度和任务类型分层，避免评测集被简单样本稀释；
3. 可复现判分：能写成单元测试的写成断言，不能的采用结构化评分标准或多评委投票，并固定随机种子；
4. 定期换血：评测集本身也要防污染，核心样本应与公开数据做相似度检查。

三、第二张表：价格结构——把单价换算成任务账单

3.1 先拆解 token 计价的四个维度

模型服务的刊例价通常不是一个数字，而是一组参数，选型前至少要拆出四项：

• 输入/输出分离计价：输出单价通常是输入的数倍，因为生成是自回归过程，逐 token 串行计算；
• 缓存命中折扣：重复出现的提示词前缀（系统提示、少样本示例、长文档）可按命中价计费，命中价与未命中价常常相差一个数量级；
• 上下文长度阶梯：部分服务对超长上下文请求收取更高单价；
• 批量与闲时折扣：离线批处理任务通常能拿到明显更低的单价。

3.2 长上下文任务对输入单价高度敏感

考虑一个典型任务：读完一份几十万 token 的长文档，再交叉核对一轮数据，输出约两万 token 的结论。这类任务的输入 token 量往往是输出量的十倍以上，账单结构由输入主导。此时输入单价的折扣会被“放大”到整个任务层面，而缓存命中率的工程优化（固定提示词前缀、文档内容前置）能带来远超预期的节省。

用一组纯属示意的数字算一笔账（非任何真实产品报价）：设输入未命中 10 元/百万 token、命中 2 元/百万 token、输出 60 元/百万 token。任务输入 30 万 token、输出 2 万 token：

• 全部未命中：0.3 × 10 + 0.02 × 60 = 4.2 元/轮
• 前缀 80% 命中：0.06 × 10 + 0.24 × 2 + 0.02 × 60 = 2.4 元/轮，降幅约 43%

再看一个常被忽略的乘数：返工轮次。真实任务很少一轮通过，若平均返工 2 轮，实际账单就是单轮的 3 倍。所以评估模型时，真正的成本公式是：

任务成本 = 单轮 token 账单 × 平均轮次 × 并发任务数

3.3 一段示意代码：把刊例价变成估算器

M = 1_000_000
def task_cost(input_tokens, output_tokens, rounds=1,
              p_in=10, p_out=60, p_cache=2, cache_ratio=0.0):
    """估算一个多轮任务的 token 账单（单位：元，价格为示意值）"""
    hit = input_tokens * cache_ratio
    miss = input_tokens - hit
    per_round = (miss / M * p_in            # 未命中输入
                 + hit / M * p_cache        # 命中输入
                 + output_tokens / M * p_out)  # 输出
    return per_round * rounds
# 示意：30万输入（80%命中）+ 2万输出，平均返工2轮
print(task_cost(300_000, 20_000, rounds=2, cache_ratio=0.8))

把候选模型各自的刊例价代入这个函数，用同一批真实任务样本跑出对比，比任何榜单排名都更接近决策需要。

四、第三张表：可用性——发布日之后才暴露的问题

4.1 典型故障形态

新模型发布初期，能力表和价格表都已定型，但第三张表才刚刚开始书写。常见故障形态有三类：

1. 限流与配额窗口：部分订阅或套餐会对请求频率、token 用量设置滚动窗口上限。长任务跑了几小时，恰好撞上窗口重置点，前面的计算全部作废；
2. 异常消耗：多智能体或循环调用场景下，子任务各自携带完整上下文，token 消耗出现乘数效应。一个拆成 8 个子智能体并发的任务，实际消耗可达单任务的 5～10 倍（示意量级），账单和配额都会被同步放大；
3. 容量挤兑：发布初期流量洪峰导致延迟抖动、超时率上升，这与模型能力无关，却直接决定任务能否按时交付。

4.2 工程侧的对策清单

这些问题不能靠“换个模型”解决，要靠工程设计兜底：

• 用量可观测：主流模型服务平台（包括百度智能云等云厂商）普遍提供用量看板与配额管理能力，接入选型时应把“能否按项目、按任务维度统计消耗并设置告警”列为硬性检查项；
• 重试与指数退避：对限流错误做退避重试，并加入随机抖动，避免多客户端同步重试造成雪崩：

import time, random
def call_with_backoff(invoke, max_retries=5, base_delay=1.0):
    for attempt in range(max_retries):
        try:
            return invoke()
        except RateLimitError:
            delay = base_delay * (2 ** attempt) + random.uniform(0, 0.5)
            time.sleep(delay)
    raise RuntimeError("超过最大重试次数，任务转入降级队列")

• 断点续跑：长任务按阶段落盘中间结果，撞上配额窗口后可从断点恢复，而不是从头再来；
• 降级路由：主模型限流时自动切换到次选模型完成剩余步骤，牺牲部分质量保住交付时效；
• 错峰调度：批处理任务安排在流量低谷执行，避开高峰期的配额竞争。

4.3 把“发布日”和“运行30天”分开评估

一个务实的做法是：发布日只做小流量验证，观察至少一至两周的限流触发频率、错误率、延迟分位数，再决定是否放大流量。跑分是一天的成绩，供给稳定是一个季度的成绩。

五、把三张表合成一个坐标系

综合以上，推荐团队建立一套三步评测流程：

1. 定义任务画像：统计生产流量的输入/输出 token 分布、并发峰值、容错要求，明确“什么算完成一个任务”；
2. 建立成本基线：选一批有标准答案的金丝雀任务，用候选模型的刊例价分别跑通，记录单位任务成本、首次通过率、平均返工轮次；
3. 小流量灰度：接入 5%～10% 真实流量，观察一至两周的限流次数、超时率与人工修正量，再决定放量。

最终写进选型报告的，不应是“榜单第几名”，而应是四个数字：单位任务成本、首次通过率、平均返工轮次、限流触发次数。这四个数字分别回答了业务方最关心的四个问题：花多少钱、对多少、返工几轮、能不能稳定跑完。

六、结语

新一代模型发布的正确围观姿势，可以概括为一句话：先查价格，再看能力，最后等几天看服务状态。当模型之间的能力差距收缩到误差范围、而价格差距拉大到数倍时，评测的重心必然从“能力追赶”转向“单位任务成本与交付质量”。榜单告诉你模型的上限在哪里，账单和告警才告诉你它能不能进你的生产环境。对工程团队而言，后者才是决策的起点。