大模型选型指南：用同一套数据比能力与成本

教程目标

本教程帮助你搭建一套可复现的大模型评测与成本核算流程。新模型或新套餐上线后，按同样的步骤运行，就能得到可直接用于选型汇报的数据。

完成后，你可以：

1. 设计覆盖长文信息定位、指令遵循、长链推理三类能力的测试集；
2. 记录每个任务的输入Token、输出Token、推理Token、耗时、重试次数和失败原因；
3. 计算单位成功任务的真实成本，并比较按量计费与套餐折扣两种情景；
4. 结合能力、成本和稳定性，形成选型结论。

榜单分数只反映模型在特定题目上的表现，不反映花费。两个分数相同的模型，单位成功任务成本可能相差很大。因此，选型时要把能力、成本和稳定性放在同一张表里比较。

适用读者与场景

适用读者

• 开发者：需要在代码助手、自动化脚本或智能体应用中接入模型；
• 运维与平台工程师：负责预算、配额、调用稳定性和故障切换；
• 技术负责人与采购方：需要基于数据决定采购、续约或迁移。

适用场景

• 新版本模型发布后，判断是否替换现有模型；
• 续订或更换Token套餐，或在订阅制与按量计费之间切换；
• 长上下文业务选型，例如文档问答、代码库分析、多轮工单处理。

前置准备

1. 环境与权限

• 具备调用目标模型的API密钥。密钥存放在环境变量或密钥管理服务中，不写入代码仓库，也不输出到日志。建议使用最小权限的子密钥，并定期轮换。
• 具备查看账单和用量明细的权限，便于事后核对统计口径。
• 为每个请求设置超时时间和最大重试次数。下文的示例参数是超时120秒、重试不超过2次，仅作演示，实际上限由业务的延迟要求决定。调整参数后，记录它对成功率和成本的影响。

2. 测试数据

• 每类能力准备不少于30条样本。样本可来自脱敏后的真实业务数据，也可使用公开基准集。使用公开基准时，先检查其许可条款，确认允许用于内部评测，并在报告中注明来源。
• 每条样本需附带标准答案或明确的判定规则。没有判定规则的样本无法自动评分，应剔除或转为人工复核。
• 评测样本和结果日志不得包含可识别个人信息、密钥或未授权的业务数据。入库前完成脱敏，日志保留期限参照公司的数据管理制度执行。

3. 基础概念

• Token：模型处理文本的计量单位。输入和输出分别计量，多数服务按两者分别计价。
• 推理模式与非推理模式：推理模式在给出最终答案前会进行较长的内部推导，通常消耗更多Token，速度也更慢。两种模式需要分别测试，不能混在同一组数据里。
• 上下文窗口：单次请求可容纳的输入与输出总长度。输入接近窗口上限时，准确率和成本都可能变化，需要单独统计。

步骤一：定义评测指标

做什么：把”模型好不好用”拆成可量化的指标。

为什么：没有指标，模型之间的比较只能依靠主观印象，结论无法复核。

怎么做：对每个模型、每类任务，记录以下五项指标。

指标	含义	计算方式
任务成功率	通过判定规则的任务占比	成功任务数 / 总任务数
单位成功任务成本	完成一个成功任务的平均花费	总成本 / 成功任务数
平均Token消耗	每个任务的平均输入与输出Token	总Token / 总任务数
P95耗时	95%的请求在该时间内完成	按耗时排序后取第95百分位
重试率	需要重试的请求占比	重试请求数 / 总请求数

测量P95耗时时，需要明确起止点。本文以”从请求发出到完整响应返回”为准。流式输出时，首包延迟单独记录为一项指标，不与完整耗时混用。若要比较排队时间，应在客户端分别打点。重试产生的额外等待计入请求的总耗时，因为用户实际等待了这段时间。

成功率反映能力，单位成功任务成本反映花费，P95耗时反映响应体验，重试率反映稳定性。四项放在一起比较，才能判断模型是否适合业务。

步骤二：构造测试集

做什么：为三类能力各准备一份样本集，每类不少于30条。

统一字段模板：每条样本使用同样的字段结构，便于批量运行和对比。

字段	说明	示例
sample_id	样本唯一编号	LC-001
ability_type	能力类别：long_context、instruction、long_reasoning	long_context
input	发送给模型的完整输入	一段合同文本加问题
expected	标准答案或参考结果	2026-01-01
judge_rule	判定规则：exact、contains、json_schema、rubric 等	exact
max_tokens	本条样本允许的最大输出Token	256
metadata	输入长度分桶、来源、版本、标注人等	{“len_bucket”: “32k-64k”}

长文信息定位：给模型一段长文本，要求找出特定信息，例如某条款的生效日期或某个参数的取值。

• 判定方式：规范化后精确匹配，例如日期统一为YYYY-MM-DD；数值统一去掉单位和千分位。
• 边界条件：目标信息放在文档开头、中部和结尾各占三分之一，避免结果只反映位置偏好。
• 示例：在一份多章节的服务协议中，询问”违约金计算的起始日期”。标准答案写入expected，判定规则为exact。

指令遵循：要求模型按照格式、字数、字段或禁用词等约束输出内容。

• 判定方式：能用程序判断的约束用代码校验，例如JSON可解析、字段齐全、字数在范围内；语义类约束使用rubric打分，由两名评审独立判定。
• 边界条件：同一任务包含一条约束和多条约束两种难度，分别统计通过率。
• 示例：要求输出一个包含name、price、stock三个字段的JSON，且price保留两位小数。判定规则为json_schema加正则校验。

长链推理：给出需要多步计算或多步逻辑推导的问题，例如数据表对账、多条件排期或多步代码修复。

• 判定方式：只比对最终答案，不比对推导过程。答案唯一的题目使用exact；开放题使用rubric。
• 边界条件：步骤数分为3步、6步、10步三档，观察成功率随步数的变化。推理模式和非推理模式分别跑一遍。
• 示例：给出三张表格和一组对账规则，要求输出差异金额。判定规则为exact，允许金额误差为0。

自动评分与人工复核的边界：

• 能用精确匹配或程序校验判定的样本，全部自动评分。
• 判定规则依赖语义理解的样本，先由自动评分给出初步结果，再抽取不少于20%的样本人工复核。若自动评分与人工判定的一致率低于90%，需要先修正判定规则，再继续评测。
• 模型输出无法解析、超出max_tokens或API报错的情况，直接计为失败，并记录失败原因，不交由人工补判。

输入长度分桶：长上下文样本按输入Token数分桶统计，例如8k以下、8k到32k、32k以上。接近窗口上限的样本容易出现截断和遗忘，单独看每个桶的成功率，比只看总体平均值更能反映真实风险。

步骤三：Token记录口径

做什么：每次请求都写入一条结构化日志，包含完整的计量与状态信息。

需要记录的字段：

字段	含义
request_id	请求唯一编号，用于对账和重试追踪
sample_id	对应的测试样本
model_version	模型名称与版本号
timestamp	请求发出时间，使用UTC
input_tokens	输入Token数
output_tokens	输出Token数
reasoning_tokens	推理Token数，服务商未单独返回时记为空并注明
cached_input_tokens	命中缓存的输入Token数，未返回时记为空
latency_ms	完整响应耗时
retry_count	本次任务的重试次数
status	success、failed
failure_reason	失败原因，见下文分类
unit_price	本次请求适用的输入、输出单价
discount	折扣或套餐抵扣说明

失败原因分类：超时、超出上下文窗口、输出格式错误、答案错误、拒答、接口报错、其他。分类要在评测开始前确定，中途不随意增减，否则不同模型之间的分布无法比较。

重试和失败请求的计费处理：

• 每一次重试都是一次独立的计费请求，只要服务商对它计费，就必须计入总成本，即使最终成功。
• 失败的任务同样计入总成本。它们消耗的Token已经产生了费用，不能因为失败而剔除。
• 只有成功任务数作为分母，失败任务不计入成功任务数，但它们的成本计入分子。这样得到的单位成功任务成本才反映真实的代价。
• 服务商因接口报错而不计费的请求，应在账单中核对后排除，并在报告中注明。

步骤四：成本核算

核心公式：

单次请求费用 = input_tokens ÷ 1,000,000 × 输入单价 + output_tokens ÷ 1,000,000 × 输出单价

总成本 = 所有请求费用之和（包含成功、失败与重试的请求）

单位成功任务成本 = 总成本 ÷ 成功任务数

推理Token的计价方式依服务商规则而定。多数服务把推理Token按输出单价计费。若账单中单列了推理Token，应按账单单价计入，并在报告中写明。

缓存命中的输入Token通常按较低单价计费。若服务商提供缓存命中单价，应拆分计算：未命中部分按常规输入单价计费，命中部分按缓存单价计费。

两种计费情景：

1. 按量计费：直接使用账单单价计算总成本。这种情景下，成本随Token数线性变化，适合用来判断单个任务的边际成本。
2. 套餐折扣：套餐的费用是固定的，需要先把套餐总价按一段周期内的预计用量摊到每个Token上，得到有效单价。有效单价 = 套餐月费 ÷ 套餐覆盖的月度Token总量。用这个有效单价代入公式，即可得到折扣情景下的单位成功任务成本。

示例（数字为演示用，非真实报价）：

假设某模型的输入单价为每百万Token 1元，输出单价为每百万Token 4元。一组测试中，共100个任务，其中80个成功，总输入为2,000,000 Token，总输出为500,000 Token，重试与失败请求合计已计入上述用量。

• 总成本 = 2 × 1 + 0.5 × 4 = 4元
• 单位成功任务成本 = 4 ÷ 80 = 0.05元

同一组用量若按某套餐的有效单价重新计算，得到的结果可能完全不同。比较时两者都要列出，供采购方判断哪种计费方式更划算。

步骤五：阈值与选型结论

阈值设定原则：下表中的数值是结构示例，用于说明如何设置阈值，不代表任何服务商的实际表现。每项阈值都应由业务的SLA、预算上限和风险承受能力决定，并在评测前写入文档。不得使用无来源的数字作为保证性结论。

指标	示例阈值	设定依据
任务成功率	不低于业务基线，例如90%	由人工抽检后确定的最低可用标准
单位成功任务成本	不高于预算上限	按月预算与预计任务量反推
P95耗时	不高于SLA的响应时限	由用户可接受的等待时间决定
重试率	不高于5%	超过该值说明接口稳定性不足
失败原因分布	超时类失败占比低于某一上限	用于判断失败的主要来源

选型判断顺序：

1. 先检查稳定性。重试率和接口报错率超过阈值的模型，直接排除，不进入成本比较。
2. 再检查能力。任务成功率低于基线的模型，即使便宜也不进入下一轮。
3. 最后比较成本。在能力达标的模型中，比较单位成功任务成本和P95耗时。
4. 如果两个模型的成功率差异在统计上不显著，优先选择单位成功任务成本更低、稳定性更好的一个。

输出结论时，同时给出以下内容：三类能力的成功率表、两种计费情景下的单位成功任务成本、P95耗时与重试率、失败原因分布、测试所用的模型版本与参数。结论要写明适用的业务场景和长度范围，不能推广到未测试的场景。

步骤六：保证结果可复现

模型服务经常更新，同一个模型名称下的表现也可能变化。为了让结果在几周后仍能被核对，每次评测都要记录以下条件：

• 模型名称与版本号，以及接口返回的具体版本标识；
• 温度、top_p等采样参数，以及是否固定随机种子；
• 最大输出Token（max_tokens）和超时、重试设置；
• 系统提示词的完整文本和版本号；
• 评测脚本的版本号或提交哈希；
• 运行日期和每个模型的运行次数。

建议对同一批样本至少重复运行三次，取平均值和波动范围。若同一模型三次结果的成功率相差超过设定的阈值，说明结果不稳定，需要先排查原因，再得出结论。

常见风险与处理

输入接近窗口上限：文档超过窗口后被截断，模型可能给出看似合理却不完整的答案。处理方式是提前计算输入Token数，超限样本单独标记，不混入普通样本的统计。

信息遗忘：长文本中间部分的信息更容易被忽略。通过步骤二中的位置设计，可以观察这一现象在不同模型上的差异。

成本随长度上升：输入越长，单次请求费用越高，而且长输入的成功率可能更低，两者叠加会明显抬高单位成功任务成本。按长度分桶统计，可以直接看到这一效应。

样本泄露：如果公开基准集的题目已经出现在模型的训练数据中，成功率会偏高。处理方式是同时使用一部分内部脱敏样本，并在报告中区分两类数据的结果。

检查清单

运行正式评测前，确认以下事项已完成：

• 密钥已放入环境变量或密钥管理服务，子密钥权限最小化；
• 每类能力的样本不少于30条，且都有判定规则；
• 公开基准的许可条款已核对，样本和日志已完成脱敏；
• 字段模板、失败原因分类和计费口径已确定；
• 阈值已由业务方确认，并写入文档；
• 模型版本、采样参数、系统提示词和脚本版本已记录。

按照这份清单执行，得到的结果可以被他人复核，也可以在模型更新后重新运行，比较前后的变化。