大模型API选型：参数表相同，账单未必相同

一、为什么参数表相同，账单却可能不同

选择大模型API时，开发者通常先看三个数字：上下文窗口、最大输出长度和单价。这三项在不同服务之间经常非常接近，很容易让人认为成本也接近。实际情况并非如此。账单由Token用量、计费档位、缓存规则和请求结构共同决定，参数表只给出了其中一部分信息。

在推理类模型普及之后，这个差距变得更明显。模型在给出答案前会生成内部推理过程，这部分内容通常按输出Token计费，但不一定出现在最终返回的文本中。如果只根据可见回复估算费用，结果会偏低。

因此，选型前应先把计费规则拆开，逐项理解它们对具体业务的影响，再用真实请求量做估算。

二、影响成本的五类计费机制

1. 输入与输出单价的不对称

多数服务对输出Token的单价高于输入Token，有时差距达到数倍。这意味着同样是一万个Token，生成内容比阅读内容贵得多。对于摘要、分类、抽取类任务，输入占比高，成本主要来自输入。对于代码生成、长文写作类任务，输出占比高，成本主要来自输出。

2. 长上下文分段计价

部分服务按单次请求的输入长度划分价格档位。一旦输入超过某个阈值，整次请求可能按更高档位计费，而不是只对超出部分加价。这种规则会在阈值附近形成明显的成本断层。

下面的代码演示了这种计算方式。其中价格为演示用假设值，不代表任何真实服务的价格。

# 以下数值均为演示用假设，单位：元/百万Token，不代表任何真实服务的价格
PRICE_SCHEMA = [
    {"max_input": 200_000, "input": 20.0, "cache_hit": 2.0, "output": 80.0},
    {"max_input": None,    "input": 40.0, "cache_hit": 4.0, "output": 120.0},
]
def pick_tier(input_tokens: int) -> dict:
    """根据单次请求的输入长度选择整单适用的价格档位。"""
    for tier in PRICE_SCHEMA:
        if tier["max_input"] is None or input_tokens <= tier["max_input"]:
            return tier
    raise ValueError("no matching tier")
def request_cost(input_tokens: int, cache_hit_tokens: int, output_tokens: int) -> float:
    """计算单次请求费用，返回单位为元。"""
    if cache_hit_tokens > input_tokens:
        raise ValueError("cache_hit_tokens 不能超过 input_tokens")
    tier = pick_tier(input_tokens)
    uncached = input_tokens - cache_hit_tokens
    total = (
        uncached * tier["input"]
        + cache_hit_tokens * tier["cache_hit"]
        + output_tokens * tier["output"]
    )
    return total / 1_000_000
# 输入仅相差2000个Token，费用却明显跳变
print(round(request_cost(199_000, 0, 2_000), 2))  # 约 4.14
print(round(request_cost(201_000, 0, 2_000), 2))  # 约 8.28

这段代码说明，输入只增加约1%，费用可能翻倍。工程上应在请求构造阶段就检查输入长度，避免无意中跨越阈值。

3. 缓存计费

当多次请求共享相同前缀，例如系统提示词、固定文档或工具定义时，服务端可能对这部分内容提供缓存。缓存命中的Token通常单价较低，但缓存写入、缓存存储时长等规则也可能产生额外费用。

设计时应做到以下几点：

• 把不变内容放在提示词前部，保证前缀稳定，提高命中率。
• 把会频繁变化的用户输入放在后部。
• 记录每次请求的缓存命中Token数，用于验证实际效果。

4. 推理Token

使用推理能力较强的模型时，内部思考过程会消耗Token。部分服务允许设置思考预算，部分服务则默认开启且无法关闭。无论哪种情况，都需要通过用量统计接口查看推理Token数，而不是只看返回文本的长度。

对于同一任务，开启推理可能显著提高质量，也可能显著提高成本。应以任务质量指标为依据决定是否开启，而不是默认开启或默认关闭。

5. 工具调用与异步任务

工具定义本身会计入输入Token。每次工具返回的结果也会回填到上下文中，继续计入输入。在多轮Agent流程中，这部分累积开销容易被低估。

异步调用可以提高并发和吞吐，但需要额外处理任务状态查询、超时重试和结果落库。这些工程成本虽然不直接出现在API账单中，但会影响整体投入。

三、构建可复用的成本模型

成本估算应以业务请求类型为单位，而不是只用一个平均值。常见的请求类型包括：

• 短问答：输入短，输出短，关注延迟与单价。
• 长文档分析：输入长，可能触发高档位，关注阈值与缓存。
• 多轮Agent任务：请求次数多，上下文逐轮增长，关注累计Token。
• 批量离线处理：对延迟不敏感，关注吞吐与单位成本。

每类请求都可以套用以下公式：

单次成本 = (未命中缓存的输入Token × 输入单价 + 命中缓存的Token × 缓存单价 + 输出Token（含推理） × 输出单价) ÷ 100万 + 工具调用及其他附加费用

上线前，应先用真实日志抽样计算，再按日均请求量外推月度成本。外推时还要考虑增长曲线和峰值流量。

四、评测方法：从综合榜单到自建评测

1. 公开榜单的局限

公开榜单能提供参考，但存在几个问题。第一，测试集与你的业务场景可能差异很大。第二，模型版本、运行参数和系统提示词的设置会影响结果。第三，分数之间的差距可能落在统计误差范围内。第四，新模型发布初期，官方资料与第三方复现结果之间可能存在差异，应等待更多独立验证。

因此，榜单适合用来缩小候选范围，不适合直接决定采购。

2. 用统计方法比较分数

如果两个模型的平均分很接近，应重复运行评测，并计算置信区间。下面的代码给出了一个近似的95%置信区间计算方法。

import math
def evaluate(model_call, dataset, judge):
    """
    model_call: 接收问题文本，返回模型回答
    dataset: 列表，每项包含 question 与 reference
    judge: 接收回答与参考答案，返回0到1之间的得分
    """
    scores = []
    for item in dataset:
        answer = model_call(item["question"])
        scores.append(judge(answer, item["reference"]))
    n = len(scores)
    mean = sum(scores) / n
    variance = sum((x - mean) ** 2 for x in scores) / (n - 1)
    std_error = math.sqrt(variance / n)
    return {"mean": mean, "ci95": 1.96 * std_error, "n": n}

如果两个模型的置信区间大幅重叠，就不能据此认定其中一个更强。

3. 评估幻觉率

幻觉率需要按任务定义，不能只给一个笼统数字。建议同时统计以下指标：

• 事实错误率：回答中出现与参考事实不符的内容比例。
• 无依据断言率：回答包含事实陈述，但无法在给定材料中找到依据的比例。
• 拒答率：模型表示不知道或无法确定的比例。拒答率过高会影响可用性，拒答率过低则可能掩盖错误。
• 引用可验证率：要求模型给出出处时，出处能被核实的比例。

这些指标应一起看。只降低幻觉率却大幅提高拒答率，未必是好结果。

4. 自建评测集的基本流程

1. 从真实业务中抽取一百条以上的代表性样本，覆盖主要请求类型。
2. 由领域专家标注参考答案或评分标准，并记录标注一致性。
3. 固定系统提示词、温度参数和输出格式，保证不同模型之间的条件一致。
4. 每个样本运行多次，记录平均分与波动。
5. 同步记录Token用量、延迟和失败率，与质量指标放在同一张表中比较。

五、安全、合规与供应商依赖

闭源服务无法在本地部署，也无法自行量化或修改权重。这带来几类需要提前考虑的问题。

• 数据合规：输入中可能包含个人信息或商业机密，需要确认数据处理位置、保留期限和是否用于训练。
• 供应商锁定：提示词、工具定义和输出格式若深度绑定某一接口，迁移成本会很高。
• 服务可用性：单一供应商故障或限流时，业务需要降级方案。

对应的工程做法包括：

• 在发送请求前做敏感信息识别与脱敏，只传递完成任务所需的最小内容。
• 在业务层封装统一的模型调用接口，把供应商差异隔离在适配层。
• 对模型输出做格式校验与关键事实复核，不直接把输出当作可信结果写入系统。
• 日志中避免保存完整敏感输入，只保留必要的元数据。

六、选型流程与落地建议

建议按以下顺序推进选型：

1. 明确任务类型、质量底线、延迟上限和合规要求。
2. 用真实日志构建小规模评测集，覆盖高频与高风险场景。
3. 在候选模型上运行评测，记录质量、Token用量、延迟和失败率。
4. 按第三节的公式估算月度成本，并分别计算长上下文与普通请求的占比。
5. 对比质量与成本，确定可接受的组合，例如不同任务使用不同模型。
6. 小流量灰度上线，持续监控用量与质量漂移。

上线后，应重点监控以下指标：

• 每类请求的平均输入、输出和推理Token数。
• 长上下文请求占比，及其是否集中在阈值附近。
• 缓存命中率，以及命中率下降的时间点。
• 质量抽检得分与人工复核的不一致率。

设置告警阈值后，成本异常可以在数小时内被发现，而不必等到月末账单。

总之，大模型API的成本取决于计费规则、请求结构和质量要求的共同作用。只看参数表和综合榜单，很难做出可靠判断。把计费拆开建模，用自建评测验证质量，才能让选型结论经得起业务检验。