从一次旗舰模型更新看选型逻辑：价格表、能力表与可用性表

过去一年，大模型版本迭代的节奏明显加快。每有新模型发布，技术社区的第一反应往往是翻跑分榜：谁在某个基准上多了两个百分点，谁又”逼近”了第一梯队。但如果把视角从榜单移到工程现场，会发现真正决定一个模型能否进入生产环境的，从来不是单点分数，而是三张表：价格表、能力表、可用性表。本文以近期一次国产旗舰模型的版本更新为引子，讨论这三张表各自该看什么、怎么算、如何在架构层落地。

一、能力表：长上下文与原生视觉的真实价值

先看能力维度。这一代旗舰模型的典型特征是三个关键词：超大规模参数、百万级 token 上下文、原生视觉理解。

参数规模的意义需要冷静看待。参数量决定了模型容量上限，但后训练（post-training）阶段的指令微调、偏好对齐与推理能力强化，往往才是同一基座下不同版本差异的主要来源。也就是说，”由上一代大规模后训练而来”这类表述，指向的是训练流程的延续性，而非简单堆叠参数。

百万级上下文是更值得工程团队关注的能力。它带来的变化不是”能塞更多字”，而是任务形态的改变：

• 过去需要先做检索、切块、摘要再喂给模型的长文档任务，现在可以整篇输入，减少信息在预处理阶段的损失；
• 跨文档交叉核对（例如比对多份合同条款、核对多轮实验记录）从”多轮问答”变成”单次推理”，链路更短、状态更少；
• 但上下文越长，单次调用的 token 消耗越大，成本与延迟的压力会同步上升——这就把话题直接引向第二张表。

原生视觉理解同样如此。它的价值不在于”能看图”，而在于把图文混排的输入（扫描件、图表、界面截图、带标注的工程图纸）纳入同一个推理上下文，避免在外部做 OCR + 结构化 + 再拼接的脆弱管线。对开发者而言，这意味着更少的胶水代码和更少的字段对齐错误。

在公开基准上，这类模型通常会在终端操作类、代码类、综合推理类评测中给出接近头部闭源模型的成绩，差距往往在个位数百分点以内。这个差距在选型中的权重，远低于很多团队的直觉——原因见下文。

二、价格表：把”每百万 token 单价”换算成”每任务成本”

价格表要看两层：刊例价，以及由刊例价推导出的单位任务成本。

以典型的三段式计费结构为例（输入缓存命中 / 输入缓存未命中 / 输出），不同模型的绝对价格可能相差数倍。但直接比较单价是不够的，因为不同模型的输出长度、推理轮次、重试率都不一样。真正有决策意义的指标是：

单位任务成本 ≈
    (输入 token 数 × 输入单价
   + 输出 token 数 × 输出单价
   + 重试轮次 × 单轮成本)
   ÷ 任务成功数

举一个具体场景：让模型通读一份三百页的标书并做一轮数据交叉核对。假设全文约 40 万 token，输出约 8000 token，单轮完成。在输入缓存命中价与未命中价差距较大的计费体系下，是否复用前缀缓存会显著影响账单——这也是为什么工程上应当尽量把稳定的长文档放在请求前部、把变化的问题放在后部，以提升缓存命中率。

再考虑重试因子。若某模型单轮成功率为 85%，另一模型为 92%，看似只差 7 个百分点，但在需要多步推理的任务上，端到端成功率会按轮次指数衰减：

端到端成功率 = 单轮成功率 ^ 轮次
85% ^ 5 ≈ 44%
92% ^ 5 ≈ 66%

这意味着低价 + 高重试的组合，最终成本可能反超高价 + 低重试。所以价格表的正确用法是：先用能力表估算轮次与成功率，再回填到成本公式里。

当国产旗舰把价格压到国际第一梯队的两成左右时，评测坐标系就应当切换：不再问”追到哪一步了”，而改问”完成一个真实任务，花多少钱、错几次、返工几轮”。这是从”模型评测”走向”工程评估”的关键一步。

三、可用性表：最容易被忽略、也最贵的一张表

第三张表往往不在发布材料里，而是在发布后几天由用户”用出来”。

典型问题包括三类：

1. 限流与并发上限。高峰期请求被排队或拒绝，长任务跑到一半中断；
2. 滚动窗口额度。按五小时等滚动窗口计量额度，长任务容易在窗口边界撞上限额；
3. 多智能体任务的异常消耗。多个子代理并行时，token 消耗呈乘数放大，若缺少预算约束，账单会失控。

这些问题不是”模型不好”，而是服务容量与配额设计的问题。对工程团队来说，它们必须在架构层提前兜底，而不是等出事再补。可落地的做法包括：

• 任务分片与断点续跑：把长任务拆成可持久化的阶段，每阶段落盘检查点，中断后从最近检查点恢复，而不是从头重跑；
• 预算熔断：为每个任务、每个租户设置 token 与调用次数上限，超限即降级或转人工，避免多智能体场景下的消耗雪崩；
• 退避与多路由：对限流错误实现指数退避，并在网关层准备备用模型路由，保证关键链路可用；
• 可观测性：对每次调用记录输入/输出 token、缓存命中、耗时、错误码，形成成本与稳定性的双维度监控。

# 示意：带预算熔断与检查点的任务封装（伪代码）
def run_task(task, budget):
    checkpoint = load_checkpoint(task.id)
    while not checkpoint.done:
        if budget.exceeded():
            return degrade(task, reason="budget")
        try:
            step = call_model(checkpoint.state)
        except RateLimited:
            backoff_and_retry()
            continue
        checkpoint = checkpoint.advance(step)
        save_checkpoint(checkpoint)
    return checkpoint.result

值得注意的是，成熟的服务方在出现配额问题后，通常会通过额度重置与按比例补偿来修复用户信任。这类响应速度本身也是可用性评估的一部分——出问题的概率和出问题后的恢复能力，应当分开打分。

四、把三张表合成一个选型框架

综合来看，一套可复用的评估框架大致如下：

维度	关注项	评估方法
能力	上下文长度、视觉输入、工具调用稳定性	用自有任务集做小样本评测，而非只看公开榜
成本	三段式单价、缓存命中率、重试率	代入单位任务成本公式，做月度账单测算
可用性	并发上限、额度窗口、异常消耗	压测 + 长任务演练 + 预算熔断验证

需要强调的是，这三张表的权重因场景而异。离线批处理任务对限流不敏感，成本权重最高；面向终端用户的交互式应用则相反，延迟与可用性优先。没有”最好”的模型，只有”匹配当前约束”的模型。

结语

一次旗舰模型更新，表面上是一组跑分和一张价目表，实质上是把”模型能力”翻译成”工程成本”的过程。对开发者而言，最有价值的动作不是追榜，而是建立自己的三张表：用能力表界定可行任务边界，用价格表算出单位任务成本，用可用性表设计兜底架构。当国产旗舰把价格打到国际第一梯队的两成，真正的竞争已经从”分数追平”转向”谁能把单位任务成本做得更低、把失败恢复做得更稳”。这个转向，对所有做落地的人都是好事。