大模型选型实战：三张表看懂新模型真实价值

每逢大模型发布，信息到达的顺序几乎是固定的：先刷屏的是跑分截图，随后是官网刊例价，最后——如果运气不好——才是用户社区里零星冒出的“被限流”“配额异常消耗”的抱怨。不少团队照这个顺序做判断：先为跑分激动，再为价格心动，最后在生产环境里为可用性买单。

更理性的阅读顺序应该反过来：先看价格表，再看能力表，最后重点盯可用性。前两张表回答“值不值得试”，第三张表回答“敢不敢用”。下面把三张表逐一拆开，给出可以直接抄走的评估方法与代码。

一、第一张表：价格经济学——先算钱，再看分数

1.1 定价是三个数字，不是一个数字

当前主流大模型 API 的计费普遍拆为三档：缓存命中的输入价、未命中的输入价、输出价。只盯着“输入 X 元/百万 token”一个数字，会严重误判真实成本，原因有三：

• Prompt Cache 已是业界通行做法。系统提示词、长文档、few-shot 示例这类“重复前缀”，命中缓存后的单价通常只有未命中价格的几分之一（常见 2~10 倍差距）。生产系统里重复前缀的占比往往超过一半，实际账单与刊例价可能相差数倍。
• 输出价显著高于输入价。自回归生成的每个 token 都要完整前向计算一次，没有缓存红利可吃，头部模型的输出单价通常是未命中输入价的 3~6 倍。
• 输出长度是模型自己的选择。同一个任务，措辞“啰嗦”的模型账单可能是精炼模型的两倍以上。看价格表必须结合“每任务平均输出 token 数”。

一个粗估公式：

单次调用成本 ≈ [命中输入量 × P_hit + 未命中输入量 × P_miss + 输出量 × P_out] / 1e6

1.2 长上下文是能力，更是成本放大器

百万级 token 上下文听起来是能力参数，用起来是计费参数。以一份约 30 万 token 的长文档（数百页的标书、合同集、代码库切片）做两轮问答为例，代入示例单价（命中 1.5 元、未命中 15 元、输出 60 元，每百万 token，仅作示意）：

• 第一轮未命中：300000 × 15 / 1e6 ≈ 4.5 元；
• 第二轮命中（缓存有效期内）：300000 × 1.5 / 1e6 ≈ 0.45 元；
• 两轮合计输出 1 万 token：10000 × 60 / 1e6 ≈ 0.6 元。

单任务约 5.5 元。这类“读全量文档再交叉核对”的任务，在不同旗舰之间价差可达数倍——当能力收敛、价格发散时，价格表就是第一张要看的表。

1.3 代际降价的解读

近年旗舰迭代有一个共同特征：参数规模上探（万亿级）、上下文拉长（百万级），单价反而下调三成上下。这通常来自推理侧批调度与 KV Cache 复用的成熟、更大参数量摊薄单位服务成本，以及市场竞争压力。对架构师而言，代际价差不只是省钱信号，它会改变架构选型：

• 当“全量上下文直读”从昂贵变得可接受，传统的“切片—检索—拼接”流程可以简化为“长上下文直读 + 引用定位”，少一半管线，就少一半出错点；
• 当输出价下降，“让模型多写一步推理、多产出一份结构化中间结果”变得可以负担，思维链外化与自检轮次的性价比随之上升。

1.4 可直接抄的成本估算器

def estimate_call_cost(input_tokens: int, output_tokens: int, hit_rate: float,
                       p_hit: float = 1.5, p_miss: float = 15.0,
                       p_out: float = 60.0) -> float:
    """粗估单次调用成本（元）。价格单位：元/百万 token。"""
    hit = input_tokens * hit_rate
    miss = input_tokens * (1 - hit_rate)
    return (hit * p_hit + miss * p_miss + output_tokens * p_out) / 1e6

选型评审时，建议用真实任务的 token 分布（输入长度、重复前缀比例、期望输出长度）跑一遍，得到每任务期望成本，而不是比较刊例价。

二、第二张表：能力基准——排名是粗筛，不是结论

2.1 基准的三层结构

• 通用综合榜（权威第三方评测机构的聚合榜、竞技场式盲测）：适合 30 秒内判断“这个模型在不在第一梯队”，仅此而已。
• 垂直任务榜：编码修复、数学推理、工具调用/终端任务（多步骤 Agent 场景）、长上下文检索。你的业务往往只落在其中一两个格子里。
• 自建评测集：20~50 条来自真实业务分布的任务样本。这是唯一的金标准，也是三张表里唯一没人能替你填的。

2.2 分差小于 1 个百分点，等于没有差距

近几轮发布的一个明显现象：头部旗舰在终端任务类基准上的分差已收敛到 1 个百分点以内。这个量级意味着：题库有限的选择题/短任务基准，采样温度、随机种子、题库污染（训练数据泄漏）都能造成 ±1 分级别的摆动。换言之，当分差小于基准噪声带，这张表对两个模型的排序基本失效，任何“谁压过谁”的叙述都是营销而非结论。此时应接受“能力收敛”的前提，把评估下沉到自建评测集：统计首答正确率、格式合规率、需要人工修正的比例。

2.3 代际提升幅度比绝对排名更有信息量

同一综合榜单上，某厂商新旗舰比自家上代高出 10 分以上——这比“排第几”有价值得多。头部模型早已越过“堆参数就涨分”的阶段，代际跃升通常来自后训练管线升级：可验证奖励的强化学习、大规模合成数据、工具使用课程、多模态对齐。看模型时，把“万亿级参数”当载体，把后训练质量当实质。

2.4 原生多模态的实用价值

“原生支持视觉理解”值得单独加分：文档场景里大量关键信息躺在图表、扫描件与排版结构中，过去要串联“OCR → 版面分析 → 文本模型”三段管线，每一段都是信息损耗点和故障点。原生多模态把三段并成一段，准确率上限与工程复杂度同时改善。

三、第三张表：可用性——最容易被忽略，也最容易翻车

3.1 可用性不是 uptime，是一组工程参数

评估生产可用性时，要看清：RPM/TPM 限额、配额窗口类型（固定窗口还是滚动窗口）、并发上限、上下文长度上限、超时行为、429/5xx 错误码的结构化程度。这些参数决定长任务、高并发、多智能体场景下的生死。

3.2 滚动窗口与长任务是天然冤家

滚动窗口（如“过去 5 小时内消耗的 token 计入当前额度”）对短请求友好，对长任务极不友好：一个预计 40 分钟的任务跑到第 25 分钟撞上额度墙，前面 25 分钟的 token 白花，配额还被持续占用，重试又要等窗口滑出空间。社区里常见的“任务没跑完就中断、重试几次还是中断”，多源于此。

3.3 多智能体的配额放大效应

表面上的“一次任务”，若执行框架内部拆成 N 个子智能体——每个子智能体各自携带一份系统提示、各自读一遍共享上下文——实际 token 消耗会被放大几十倍；且子智能体常在毫秒级窗口内并发起跑，瞬间打满 TPM 限额，触发 429 连锁。工程防御清单：

• 预算前置检查：任务提交前估算 token 预算，乘 1.2~1.5 安全系数，超窗就排队，而不是让任务死在半路；
• 客户端令牌桶兜底：不要依赖服务端限流信号，客户端自己控速；
• 指数退避 + 抖动：避免所有 worker 同步重试形成的周期性尖峰；
• 断点续跑：长任务按阶段切 checkpoint，失败从断点恢复；
• 配额监控：把“窗口剩余额度”纳入告警，设 80% 阈值提前预警。

import time, threading
class TokenBucket:
    """客户端侧限速器：按预估消耗量放行请求。"""
    def __init__(self, capacity: float, refill_per_sec: float):
        self.capacity, self.refill = capacity, refill_per_sec
        self.tokens, self.ts = capacity, time.monotonic()
        self.lock = threading.Lock()
    def acquire(self, n: float):
        while True:
            with self.lock:
                now = time.monotonic()
                self.tokens = min(self.capacity,
                                  self.tokens + (now - self.ts) * self.refill)
                self.ts = now
                if self.tokens >= n:
                    self.tokens -= n
                    return
                wait = (n - self.tokens) / self.refill
            time.sleep(min(wait, 0.5))

3.4 从补偿方案看工程成熟度

出现限流事故后，规范的厂商会做两件事：受影响用户额度重置、按比例补偿。这体现事后处理的态度，但生产用户要清醒：补偿解决的是情绪问题，解决不了 SLA 问题。接入前真正该审查：限流文档是否公开明确、有无 burst 弹性空间、有无企业级配额通道、错误码是否结构化可编程。此外，无论走公有云 API 直连，还是在百度智能云等平台上做私有化/托管部署，GPU 容量规划、弹性伸缩与监控告警都属于同一张可用性表，应在压测阶段一并验证。

四、三张表合一：把坐标系换成“任务经济学”

四个可直接落地的指标：

1. 单任务期望成本 = 直接调用成本 ÷ 任务成功率（重试成本摊入）；
2. 首答正确率：不需要人工修正即可验收的比例；
3. 平均返工轮次：从首次输出到验收通过的平均交互次数；
4. 端到端时延分布：P50/P95，必须包含限流排队时间。

建议的评审流程：第 1 天定义 20~50 条真实任务样本；第 2 天冷、热（缓存命中）各跑一遍，记录成本、正确率、轮次；第 3 天注入故障——人为压低客户端速率模拟限流，观察断点恢复与重试行为；最后填决策表：

候选模型	单任务成本（元）	首答正确率	返工轮次	P95 时延	限流下失败率
A	5.5	82%	1.4	6 min	3%
B	21.0	84%	1.3	4 min	1%

这张表才是采购决策的最终形态：候选 B 更准更快但贵约 4 倍，候选 A 在“能力近似收敛”前提下以零头价格完成同量任务。不同团队加权不同，但至少，决策发生在同一坐标系里。

五、选型落地清单

价格表

• 三档单价（命中输入/未命中输入/输出）是否明确公示；
• 缓存有效期与命中判定规则（前缀匹配）是否写清；
• 已用真实任务分布算出“单任务期望成本”。

能力表

• 目标基准上的分差是否超过噪声带（建议 ≥3 个百分点才有排序意义）；
• 相对上代的提升幅度是否构成代际信号；
• 自建评测集上的首答正确率与返工轮次；
• 多模态是否原生（能否省掉外挂 OCR 管线）。

可用性表

• RPM/TPM、并发与上下文上限的公开文档；
• 配额窗口类型与容量、恢复节奏；
• 429/超时错误码是否结构化、可编程处理；
• 长任务断点续跑与幂等设计的压测结果；
• burst 弹性、企业级配额通道与 SLA 条款；
• 历史故障与补偿机制的公开记录。

结语

跑分回答“行不行”，价格回答“用得起吗”，可用性回答“敢不敢押上生产”。三张表的交集，才是选型结论。当旗舰间的能力差距收敛到基准噪声之内、价格却发散到数倍时，评测坐标系必须随之更换——从“追赶叙事”换到“任务经济学”。值得把这句话贴在选型评审材料的第一页：先看价格表，再看能力表，最后，盯死可用性那张表。