大模型选型：如何平衡速度、成本与质量

一、速度与成本为什么比榜单分数更值得算

模型榜单给出的综合分数，反映的是模型在一组固定测试上的平均表现。业务系统关心的是另一组问题：每次调用多久返回，每千次请求要花多少钱，结果能否直接进入下一个环节。当两个模型在质量上差距不大，而其中一个响应更快、成本更低时，选型问题就从“哪个更强”变成“强到什么程度就够用”。

因此，评价一个新模型时，可以先回答三个问题：它在我的任务上是否达到可接受的质量；它的响应时间是否满足交互要求；它的单位任务成本能否支撑规模化使用。三个问题都有答案，才能形成决策依据。

二、把评估拆成三个可量化的维度

2.1 质量：用任务正确率代替通用分数

质量评估应围绕具体任务定义。以文档结构化抽取为例，可以用字段级准确率衡量；以代码修改为例，可以用单元测试通过率衡量；以客服回复为例，可以用人工评分或规则检查衡量。每个指标都需要明确的判定标准，避免“看起来不错”这类主观结论。

2.2 延迟：区分首字延迟与完整耗时

延迟至少要拆成两个指标。首字延迟（Time to First Token）决定用户多久看到第一个字，直接影响流式交互的体感。完整耗时决定批处理任务的吞吐量，也决定异步流程的排队压力。同一个模型在两类场景下的表现可能差异很大，需要分别记录。

2.3 成本：按 token 计算单任务成本

多数模型按输入 token 和输出 token 分别计价，因此只看单价无法反映真实开销。应当计算每个任务的实际花费，并把它归一到业务单位，例如每份合同、每张工单或每次检索。部分模型会在可见输出之外产生内部推理 token，这部分通常也计入费用，统计时应以账单为准。

三、建立自己的评测集

通用评测无法说明特定业务的问题。团队需要从真实流量中抽取样本，构建一份可以重复运行的评测集。

实施时需要注意以下几点：

• 样本来源：取自近期真实请求，覆盖高频场景、长尾场景和边界情况，并完成脱敏处理。
• 样本数量：每类任务至少几十条，关键任务应达到数百条，以降低偶然波动的影响。
• 标注标准：提前写好判定规则。多人标注时计算一致性指标，一致性过低说明规则需要修订。
• 固定条件：温度参数、系统提示词和上下文长度在所有候选模型间保持一致，否则比较结果不可信。

下面是一个示意性的评测脚本，用于同时统计质量、延迟和成本。其中 call_model 和 judge 需要替换为团队实际使用的客户端封装和判定函数。

import time
from statistics import mean
def evaluate(model_name, cases, call_model, judge, price_in, price_out):
    """price_in 和 price_out 为每个 token 的单价。"""
    correct = 0
    latencies, costs = [], []
    for case in cases:
        start = time.perf_counter()
        resp = call_model(model_name, case["prompt"])
        latencies.append(time.perf_counter() - start)
        costs.append(
            resp["input_tokens"] * price_in + resp["output_tokens"] * price_out
        )
        if judge(case["expected"], resp["text"]):
            correct += 1
    return {
        "accuracy": correct / len(cases),
        "avg_latency_s": mean(latencies),
        "avg_cost": mean(costs),
    }

脚本输出的三个指标应放在同一张表中比较，且每次比较都使用相同的样本集。

四、按任务难度分层选用模型

多数团队没有必要让所有请求都经过最强模型。更合理的做法是按难度对任务分层，简单请求走低成本通道，只有复杂请求才调用高能力模型。

常见的分层方式如下：

1. 轻量层：分类、关键词抽取、格式转换、简单问答。
2. 中间层：文案撰写、界面或图像理解、规范化的文档处理、常规数据整理。
3. 高能力层：多步推理、复杂代码生成与重构、需要长链条判断的分析任务。

分层依据应当是评测结果，而不是模型的名称或官方定位。某个档位的模型如果在团队的评测集上达到质量要求，就可以承接对应的任务类型。

路由逻辑可以写成简单的规则表：

ROUTE_RULES = {
    "classify": "tier_light",
    "summarize": "tier_mid",
    "refactor_code": "tier_heavy",
}
def route(task_type: str, prompt_tokens: int) -> str:
    # 超长输入直接进入高能力层，避免中间层上下文不足
    if prompt_tokens > 100_000:
        return "tier_heavy"
    return ROUTE_RULES.get(task_type, "tier_mid")

仅有静态规则还不够，路由还需要两个动态机制：升级与回退。当低档模型的输出格式不合规或校验失败时，系统应自动升级到更高档位重试。当高档位出现超时或限流时，系统应回退到可接受的替代档位，并记录降级事件，便于后续分析。

五、计算真实的单位成本

单次请求成本的计算公式如下：

单次成本 = 输入 token 数 × 输入单价 + 输出 token 数 × 输出单价

看一个假设的例子。某业务每天处理 1000 次请求，每次平均输入 2000 token，输出 500 token。假设输入单价为每百万 token 1 元，输出单价为每百万 token 4 元，那么每天的成本为：

• 输入：1000 × 2000 = 200 万 token，约 2 元
• 输出：1000 × 500 = 50 万 token，约 2 元
• 合计：约 4 元每天

这些数字只用于演示计算方法，并非任何实际价格。

单价比例不等于性价比。若低价模型的错误率更高，导致需要两次重试或增加人工复核，那么单位任务的真实成本可能反而更高。因此，成本核算应当把重试次数、复核工时和失败请求的费用一并计入。

六、常见误区

误区一：用单一指标决定选型。 响应快、单价低的模型，如果错误率偏高，成本会转移到人工复核和用户投诉上。选型必须同时看质量、延迟和成本。

误区二：用一次测试定结论。 模型服务可能随版本更新或负载变化而改变表现。评测集应定期重跑，尤其在供应方发布新版本之后。

误区三：忽略上下文长度。 长文档场景下，首字延迟和费用都会随输入长度明显增加。应当针对不同长度区间单独测试，而不是只用短样本代表全部场景。

误区四：把榜单结论直接套用到业务。 榜单任务与业务任务的差异可能很大。榜单适合用来筛选候选模型，最终结论仍要以自己的评测集为准。

七、落地步骤与持续监控

1. 梳理业务任务，列出每类任务的类型、调用频率和质量要求。
2. 从真实流量中抽取样本，建立评测集。
3. 对候选模型统一运行评测，记录质量、延迟和单任务成本。
4. 按任务划分档位，设定路由规则与升级、回退机制。
5. 先小流量灰度上线，对比线上质量指标与成本变化，确认无明显退化后再全量切换。
6. 持续监控每日成本、各档位请求占比、错误率、升级比例和 P95 延迟。

监控告警可以接入团队已有的日志服务与监控告警系统。阈值应按业务的容忍度设定，例如成本环比上涨超过约定比