大模型API选型：成本、性能与评估方法

一、为什么大模型API选型需要系统的评估方法

大模型API的采购决策通常同时涉及三个变量：单位价格、完成任务所需的Token数量、以及输出结果的质量与响应速度。只看单价，容易忽略实际消耗；只看演示效果，又容易忽略稳定性和长期成本。

常见的问题包括：

• 同一个任务在不同模型上的输出长度差异很大，导致实际账单与预期不符。
• 厂商公布的延迟数据通常基于理想网络和短文本，与业务高峰期的表现存在差距。
• 质量评价依赖个人主观感受，无法在团队内部复现，也难以支持长期迭代。

因此，合理的选型流程应当把成本、性能和质量拆成可以测量的指标，再放到同一套业务数据上比较。

二、成本模型：拆解输入与输出Token

多数按量计费的大模型API采用“输入Token单价 + 输出Token单价”的结构。输出单价通常高于输入单价，原因在于输出需要逐个Token生成，计算开销更大。因此，同样的单价倍数，对输出较长的业务影响更明显。

单次请求成本可以表示为：

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

在估算月度账单时，还需要考虑请求频次、重试次数和系统提示词（system prompt）占用的固定Token。以下是一个通用的估算函数示例，单价参数由使用者根据服务商官方价目表填写：

def estimate_monthly_cost(
    requests_per_day: int,
    avg_input_tokens: int,
    avg_output_tokens: int,
    price_in_per_m: float,   # 每百万输入Token单价
    price_out_per_m: float,  # 每百万输出Token单价
    retry_rate: float = 0.0, # 重试比例，例如 0.05 表示 5%
    days: int = 30,
) -> float:
    total_requests = requests_per_day * days * (1 + retry_rate)
    total_in = total_requests * avg_input_tokens
    total_out = total_requests * avg_output_tokens
    return (total_in / 1_000_000) * price_in_per_m + (total_out / 1_000_000) * price_out_per_m
# 示例：假设单价为输入 10、输出 50（单位货币/百万Token），仅用于演示计算方法
cost = estimate_monthly_cost(
    requests_per_day=10_000,
    avg_input_tokens=800,
    avg_output_tokens=300,
    price_in_per_m=10,
    price_out_per_m=50,
)
print(f"月度估算成本：{cost:.2f}")

在上述假设下，输入部分为 240 百万 Token，输出部分为 90 百万 Token，合计约 6900 单位货币。输出部分的成本占比超过输入部分，说明优化输出长度（例如限制回答篇幅、使用结构化输出）往往比压缩提示词更有效。

成本优化的常见手段包括：

1. 精简系统提示词，删除与任务无关的规则描述。
2. 对高频、低难度的请求使用更小的模型，只把复杂请求交给大模型。
3. 为重复出现的问题建立缓存，避免重复调用。
4. 通过字段约束或JSON模式限制输出格式，减少冗余文字。

三、性能指标：延迟、吞吐与稳定性

性能评估应覆盖用户能感知的指标，而不只是平均值。建议至少记录以下四类数据：

• 首Token延迟（Time to First Token）：从发出请求到收到第一个输出Token的时间，直接影响流式对话的体感。
• 输出速度：每秒生成的Token数，决定长回答的完成时间。
• 尾部延迟：P95、P99分位的响应时间，反映高峰期和极端输入下的表现。
• 错误率与超时率：包括限流、超时和服务端错误，需要区分可重试与不可重试的情况。

测量时应注意控制变量：相同的输入样本、相同的并发数、相同的时间段，并尽量在接近生产环境的网络条件下进行。单次测试结果波动较大，建议每组至少采集数百次请求后再计算分位数。

下面是一个基于标准库的简单延迟采样示例，适用于对任意兼容的接口做基准测试：

import time
import statistics
def benchmark(call_fn, samples: list[str]) -> dict:
    latencies = []
    errors = 0
    for prompt in samples:
        start = time.perf_counter()
        try:
            call_fn(prompt)
            latencies.append(time.perf_counter() - start)
        except Exception:
            errors += 1
    latencies.sort()
    n = len(latencies)
    return {
        "count": n,
        "error_rate": errors / max(len(samples), 1),
        "p50": statistics.median(latencies) if n else None,
        "p95": latencies[int(n * 0.95) - 1] if n else None,
    }

四、质量评估：建立可复现的评测集

质量是选型中最难量化的部分。可行的做法是从真实业务中抽取一批代表性样本，构建评测集，并定义明确的评分标准。

评测集的构建步骤如下：

1. 从线上日志中按场景分层抽样，覆盖高频问题、边界情况和高风险问题。
2. 为每条样本编写参考答案或评分规则，例如事实正确性、格式合规性、是否遗漏关键信息。
3. 使用自动化检查处理可以规则化的部分，例如JSON是否合法、字段是否齐全、是否包含禁用内容。
4. 对无法自动判断的部分，采用人工盲评，多名评审独立打分并计算一致性系数。

评测结果应同时报告准确率、任务完成率和单位成本下的质量，即“每元能获得多少合格结果”。这一指标能把质量与成本放在同一个坐标系中比较，避免只选择最强或最便宜的方案。

五、选型对比的标准流程

一套可复用的选型流程通常包括以下环节：

1. 明确业务约束：延迟上限、预算上限、数据合规要求和上下文长度需求。
2. 确定候选方案：按规模、能力和接入方式筛选三到五个候选，避免无限扩大比较范围。
3. 统一测试条件：使用同一评测集、同一提示词模板和同一参数设置，例如温度值和最大输出长度。
4. 记录三类结果：成本估算、性能分位数和质量得分，并填入同一张表格。
5. 进行小流量灰度：在真实流量中按比例分流，观察线上指标与离线测试是否一致。
6. 设定复评周期：服务商的价格、限额和模型版本会变化，需要定期重新测试。

对比时可以使用加权评分表。权重应由业务方决定，例如对客服场景，延迟和稳定性可以占较高比例；对离线分析场景，质量和成本的权重可能更高。

六、常见误区

• 只看单价，不看Token消耗。输出更长、重试更多的方案，实际成本可能高于单价较高的方案。
• 用少量样本下结论。几十条样本难以反映长尾问题，结论容易偏向个别场景。
• 忽略上下文长度的成本影响。长上下文会同时增加输入Token数和响应延迟。
• 把演示效果当作生产效果。精心挑选的示例通常无法代表真实流量的分布。
• 没有降级方案。接口限流或中断时，系统应能切换到备用方案或返回可接受的兜底结果。

七、小结

大模型API的选型本质上是一个多目标权衡问题。成本由单价和Token消耗共同决定，性能需要用分位数和错误率衡量，质量则要依靠可复现的评测集和明确的评分规则。把这三部分拆解清楚，并在相同条件下进行对比，才能得出有依据的结论。建议团队将本文的估算函数、基准测试脚本和评测流程纳入内部工具链，每次更换模型或调整业务规则时重新运行，把选型从一次性决策变成持续优化的过程。