最近半年好几拨朋友来找我聊大模型 API 选型开场白基本都是“我看 XX 模型最近很火是不是直接换掉现在的就行了”每次听到这种话我都要劝一句先别急着换“很火”和“适合你”之间还隔着一整套大模型 API 服务评测的流程。今天就把我这几年做模型服务评测的指标、方法和工具完整梳理一遍目标很直接帮你在面对一堆模型 API 时不再靠感觉拍板而是用数据说话。这篇指南不是什么学院派教科书也不是厂商宣传稿而是我从实际项目里踩坑踩出来的经验。适合正在做技术选型的后端开发、算法工程师、技术负责人也适合那些想把自己业务接进大模型 API、但不知道怎么评估效果的团队。文章会拆开讲四件事先立一套能落地的评测指标再讲评测方法怎么设计才不会测了个寂寞然后给出能直接抄的代码和工具链最后复盘一次真实选型中踩过的坑。1. 为什么“凭感觉选模型”在 API 时代行不通早几年用大模型基本是本地部署开源模型选型相对简单哪个测评分数高、哪个显存放得下就用哪个。但到了 API 时代情况完全变了。厂商把模型包成了服务你面对的是一堆参数、价格表、并发限制和不断迭代的版本号。同样是“7B 级别模型”不同厂商的 API 在延迟、限流策略、返回格式、成本结构上可能差出好几倍。只看模型名字和新闻稿上的榜单根本撑不起一个生产环境的选型决策。更重要的是API 服务的评测已经不再是“跑跑 benchmark 看分数”这么简单。你需要同时回答几类问题用户体验层面这个接口到底快不快、稳不稳模型能力层面它在我的业务场景里是不是真的聪明成本层面同样的预算能支撑多大并发工程层面限流、超时、错误提示是否可容忍。这些问题相互纠缠单看任何一面都会误判。比如某个模型单项延迟很低但一问复杂问题就频繁触发内容过滤导致重试率飙升最终真实延迟反而比竞品高一倍。还有一个很现实的原因模型 API 的更新频率在肉眼可见地加快。厂商经常发布新版本同一系列内部的不同型号比如轻量版、标准版、增强版能力差异极大。你上个月测出来的结论下个月可能就失效了。所以评测不只是一次性的选型动作而应该变成一套可以随时复跑的流程。我见过不少团队项目上线前简单测了下响应时间就定了模型结果三个月后业务高峰期频繁 429 限流一问才发现当初根本没做并发压测。这类问题靠感觉永远发现不了。所以我把这篇文章定义成“指南”而不是“报告”就是想强调一件事评测的价值不在于生成一份不可复现的结论而在于建立一套可持续运行的方法。你完全可以用下面的指标和工具构建属于自己的评测流水线把每次版本升级、每个候选新模型都放入同一套测试框架里横向比较。2. 评测指标体系先分清“体验指标”和“质量指标”做评测最容易犯的错误就是糊里糊涂地把所有指标混在一起算。我建议一上来就做个分类一类是“服务体验指标”回答“这个 API 用起来多快、多稳”另一类是“模型能力指标”回答“这个模型生成的答案到底行不行”第三类是“成本指标”回答“达到同样的服务水平要花多少钱”。三者分开测量、分开展示最终再放到一起做综合判断。2.1 服务体验指标延迟、吞吐、稳定性服务体验指标里最重要的几个分别是TTFTTime To First Token首 token 延迟。从请求发出到收到第一个 token 的时间。这个指标直接决定用户感知尤其在流式输出场景下TTFT 超过 3 秒用户基本就会觉得“卡住了”。TPOTTime Per Output Token平均每个输出 token 的间隔时间。它反映的是生成速度决定着长文本回答的总耗时。端到端延迟Total Latency从发出完整请求到收到完整响应的总时长。在非流式调用场景下这几乎是唯一指标。吞吐量Throughput单位时间内能完成的请求数常见单位是 RPSrequests per second也可以换算成 tokens/s。错误率与稳定性包括 4xx/5xx 错误率、超时率、P95/P99 延迟分位数。P99 能暴露长尾问题比如大多数请求 200ms但 1% 的请求卡了 10 秒这个卡顿对用户体验的伤害不亚于整体变慢。测量这些指标时有几个特别容易踩的坑。第一TTFT 不能用 SDK 默认的“等待完整响应计时”来算必须在流式接口里对首 token 单独计时。第二连接池必须复用否则把 TCP 握手时间也算进模型延迟里数字会虚高。第三要区分冷启动和热请求很多服务首次请求比后续请求慢得多评测时最好先发几个预热请求或者至少把第一轮数据单独标注出来。2.2 模型能力质量指标公开基准不等于业务效果模型能力的评测指标按数据来源可以分成两类。一类是公开基准比如 MMLU、GSM8K、HumanEval、BBH 等。它们的优点是可以快速比较不同模型也能和社区公开数据对照。缺点是它们和你的真实业务往往有偏差而且网上已经有大量“刷分”情况很多模型专门在这些基准上做过优化分数未必反映实际泛化能力。另一类是你自建的业务评测集从真实用户问题里采样一批有代表性的任务人工标注标准答案或打分维度。这类评测最接近真实效果但建设成本高、维护也麻烦。我强烈建议任何想认真做 API 选型的团队至少在核心业务上建 100 到 200 条业务评测样本用它们做最终裁决。公开基准只能当入门筛选的初筛别用它直接定生死。业务评测集也不一定都要人工打分。实践中常用的做法是三类注入第一类简单抽取看模型能否从给定文档里找到准确答案第二类逻辑推理看能不能完成多步推断第三类格式遵循看能不能严格输出 JSON 或指定结构。每条样本只需人工判断“通过/不通过”跑完就能算出准确率成本低可解释性也强。2.3 成本指标别只看每百万 token 价格很多人评测 API 只盯着官网的单价这是大误区。单价只是“目录价”真实成本还得看实际消耗和额外开销。完整的成本指标应该包括输入与输出 token 的单价当前主流 API 都区分 input 和 output且 output 通常贵得多。实际消耗量同一个任务不同模型的 token 消耗差异可能很大。有的模型答非所问、废话连篇虽然单价便宜但实际花费反而更高。重试与补偿成本如果模型频繁触发限流或内容过滤你就需要重试重试次数直接翻倍成本。缓存成本如果你做了 prompt 缓存或语义缓存实际计费 token 会低于原始 token这个也要纳入测算。我建议统一用一个复合指标每千次有效业务的 token 消耗 × 实际单价。例如做客服问答一次完整会话可能会调用三到五次模型每轮都要有上下文最终算出来单次会话成本才具备真正的横向可比性。2.4 工程可用性指标限流、配额与版本稳定性最后这类指标经常被忽略但在生产环境里最要命。你需要确认厂商的限流策略是否匹配你的业务峰值每分钟最大请求数RPM、每分钟最大 token 数TPM分别是多少超出之后是排队还是直接拒绝配额是每天重置还是每小时重置万一连续几天流量上涨是否可以申请临时扩容此外还要看错误响应里有没有明确的 retry-after 头限流错误的 body 是否包含友好的提示。好的 API 设计能让你快速实现优雅降级差的 API 设计会让客户端在高峰期直接雪崩。版本稳定性也很关键。很多模型 API 会有多个版本号比如 v1、v2 或带日期后缀的版本不同版本的参数格式、返回字段可能不一致。评测时必须锁定版本记录 UUID 或版本号否则后面复测时数据对不上还以为是模型退化了。我见过某项目上线后某一晚突然准确率断崖下跌查了很久才发现厂商悄悄切换了默认模型版本旧参数在新版本上被忽略输出格式变了。指标维度核心指标测量方式参考经验体验TTFT / TPOT / 总延迟流式接口对首 token 计时TTFT 在线业务建议 P95 3s稳定性P95/P99 延迟、错误率、429 率压测脚本统计分位数P99/平均 大于 3 倍时警惕长尾能力公开基准 业务评测集离线跑批 人工/自动判分业务评测集优先成本单次业务成本、token 消耗、重试率日志统计 价格表以“每千次业务”为单位工程RPM/TPM 限制、版本锁定、SLA阅读文档 实测触发限流必须与峰值流量对比3. 评测方法设计从“刷榜”到“贴近业务”的实验流程指标定好之后下一步就是设计评测流程。很多人把评测想得太随意随便写几个 prompt发给几个 API看谁回得快、谁答得通顺就下结论。这种评测基本经不起推敲变量都没控制住得出的结论自然不可信。规范的评测方法关键在于三个环节评测集怎么建、实验怎么控变量、结果怎么解释。3.1 评测集建设公开基准筛选、业务集定胜负我推荐的流程是“分层漏斗”第一层用公开基准做粗筛把明显不靠谱的模型排除掉。比如你要做中文客服先跑一遍 C-Eval 或中文问答类评测低于某个阈值的模型直接出局。第二层用自建业务评测集做精测样本量不用特别大但要保证覆盖核心场景的各个子任务。自建业务评测集的样本设计有四个维度不能漏功能维度你的产品有哪些核心功能点客服机器人的退款、改地址、查订单是不同功能每个功能至少留 10 到 20 条样本。难度维度简单询问、复杂多轮、需要检索增强的都要照顾到。如果只测简单问题评测结果会明显偏向“话痨型”模型。格式维度需要输出 JSON、纯文本、还是 Markdown每个格式单独分组统计方便定位问题。边界与违规样本包括无关问题用户乱说话、敏感边缘问题、超长上下文问题。这些能测试模型的安全性和鲁棒性。每一条样本最好都写好“期望行为”说明并尽量给出参考答案。评测判分标准要提前定义是逐字匹配还是允许同义改写我建议对大多数业务场景采用“五点打分制”1 分完全错误5 分完全正确并且由一个固定的人或小型标注团队统一打分避免多人评分标准漂移。3.2 控制变量温度、上下文、版本、并发必须统一模型评测不控制变量结果就是垃圾进垃圾出。以下是必须锁定的变量温度temperature必须统一建议设 0.1 到 0.3 的低温度减少随机性。你评测的是模型的确定性能力不是它的创作能力尤其客服、信息抽取类任务更是如此。上下文内容同一批 prompt 必须完全一致。别因为某个模型支持更长上下文就额外给它加一堆背景知识这会直接破坏公平性。输出长度建议设置 max_tokens 上限防止某个模型因为生成长文而拉高延迟导致性能对比失真。评测能力时报告里要标注实际输出 token 数不能只看总时长。模型版本锁定 API 返回的具体版本号最好从响应头里读取。同一系列模型v1 和 v2 差别极大。并发度做性能评测时并发数必须作为显式变量。分别测并发 1、10、50、100 的情况画出延迟随并发变化的曲线。只看单并发没意义因为生产系统几乎不会只有一个人在调用。3.3 评测执行顺序与轮次交替执行、多次取中位数顺序上也有讲究。如果同一时刻只测 A 模型再测 B 模型可能会被服务端高峰、网络抖动等因素干扰。正确做法是分多轮交替执行先跑一轮 A 和 B 各 100 条记录结果休息一会儿再跑一轮 B 和 A 各 100 条。这样可以抵消时间段偏差。每轮样本建议至少 3 次重复取中位数或平均值。如果某条样本某次返回超时要保留记录不能直接丢弃因为超时也是服务质量的真实表现。不过要把“模型能力”和“服务稳定性”两个维度分开记录模型答得好不好只有成功返回的样本才参与计分超时、报错、限流则单独计入稳定性指标。3.4 评测结果记录结构化的日志才能复盘评测过程中必须把完整的请求上下文保存下来包括请求时间、模型版本、prompt、完整响应、延迟数据、token 用量、错误信息。我一般建议直接输出 JSONL 格式的文件一条请求一行。后面做任何分析无论是统计 token 成本还是追溯某个失败案例都能快速定位。数据记录里尤其要注意 token 用量。OpenAI 兼容接口通常会在 usage 字段里给出 prompt_tokens、completion_tokens、total_tokens这些是从计费角度最准确的数据。有些非标准 SDK 不暴露 usage你需要自己数 token 或者用官方 tokenizer 估算这会带来成本误差评测报告里必须注明估算方式。4. 评测工具与脚本几行代码拿到关键指标指标和方法有了接下来就是工具。我见过不少团队一上来就搭很重的评测平台结果平台还没搭完业务需求早变了。更务实的路径是从脚本到平台逐步演进先用一段 Python 脚本跑通流程再引入开源评测框架做质量管理最后才考虑是否需要自建 Web 平台。4.1 工具选型按阶段挑别一步到位工具类别适用阶段特点与注意事项Promptfoo评测框架小规模对比支持 YAML 配置测试用例、自动判分、输出 HTML 报告适合 100 条以内的快速对比DeepEval评测框架单元测试提供了 LLM-as-a-judge、G-Eval、答案相似度等多种指标适合集成进 CIRagas检索增强评测RAG 场景专注检索相关性和生成 faithfulness适合已经有 RAG 管线的团队LangSmith / Langfuse可观测平台线上追踪能记录真实请求链路、token 消耗、延迟做线上质量回归k6 / Locust压测工具并发与性能两者都支持 HTTP 压测Locust 用 Python 写压测脚本k6 用 JavaScript上手难度差不多自建 asyncio 脚本专项评测精细化指标灵活测量 TTFT、TPOT、分位数我建议每个团队都保留一个这样的脚本工具不是越多越好核心是“够用”。我的建议是刚开始做评测用 Promptfoo 或 DeepEval 跑质量指标用 Locust 跑并发压测再用自建脚本补齐 TTFT、TPOT 这类流式指标。等你已经有线上流量之后再引入 Langfuse 做持续监控。4.2 自建性能测试脚本一次拿到 TTFT、TPOT 与分位数下面这段 Python 脚本是我自己常用的性能测试骨架利用 asyncio 并发调用 OpenAI 兼容接口并记录关键延迟。代码刻意保持精简方便你改造。import asyncio import statistics import time import httpx API_BASE https://api.example.com/v1 API_KEY your-key MODEL qwen-plus PROMPT 用三句话介绍大模型 API 评测的核心指标。 async def stream_once(client, payload): start time.perf_counter() first_token_time None tokens 0 try: async with client.stream( POST, f{API_BASE}/chat/completions, jsonpayload, headers{Authorization: fBearer {API_KEY}}, ) as resp: resp.raise_for_status() async for line in resp.aiter_lines(): if line.startswith(data:) and line ! data: [DONE]: if first_token_time is None: first_token_time time.perf_counter() - start tokens 1 total_time time.perf_counter() - start return { success: True, ttft: first_token_time, total: total_time, tokens: tokens, } except Exception as exc: return {success: False, error: str(exc)} async def run_concurrent(concurrency, rounds): payload { model: MODEL, messages: [{role: user, content: PROMPT}], temperature: 0.2, max_tokens: 200, stream: True, } async with httpx.AsyncClient(timeout30) as client: tasks [] for _ in range(rounds): tasks.append(stream_once(client, payload)) results await asyncio.gather(*tasks) success_results [r for r in results if r.get(success)] ttft_list [r[ttft] * 1000 for r in success_results] total_list [r[total] * 1000 for r in success_results] print(f并发 {concurrency}成功率 {len(success_results)}/{len(results)}) if ttft_list: print(fTTFT 中位数 {statistics.median(ttft_list):.0f}msP95 {sorted(ttft_list)[int(len(ttft_list) * 0.95) - 1]:.0f}ms) print(f总延迟 中位数 {statistics.median(total_list):.0f}msP95 {sorted(total_list)[int(len(total_list) * 0.95) - 1]:.0f}ms) print(f平均吞吐 {len(success_results) / (sum(total_list) / 1000):.1f} req/s) for concurrency in [1, 10, 30]: asyncio.run(run_concurrent(concurrency, rounds30))这段脚本做了几件事用 streamTrue 精确计算 TTFT统计总延迟和 token 数输出成功率、中位数和 P95。注意脚本里我刻意没有复用同一个连接池的推导而是直接用 AsyncClient 的默认连接池。实际评测时建议把连接数上限和 keep-alive 参数调大否则并发一高本地连接池先成为瓶颈测出来的数据就不是服务端真实水平了。4.3 质量评测脚本用 LLM-as-judge 解放人力自建业务评测集到 500 条以上后纯人工打分就变成负担。此时可以用“LLM-as-judge”方案让一个强模型当裁判给候选模型的输出打分。当然Judge 模型本身也有偏差所以不能盲信建议先用一个几十条的小样本把 Judge 模型的打分和人工打分做一致性比对相关系数高了再用。import openai judge_client openai.OpenAI(api_keyyour-key, base_urlhttps://api.example.com/v1) scoring_prompt 你是客服质量评测员。根据以下任务、标准答案和模型回答输出 1-5 分。 要求只输出数字不要解释。 任务用户咨询退款到账时间 标准答案退款通常在 3-5 个工作日内到账具体取决于原支付渠道。 模型回答{response} def score_response(response): prompt scoring_prompt.format(responseresponse) res judge_client.chat.completions.create( modeljudge-model, messages[{role: user, content: prompt}], temperature0, max_tokens5, ) return int(res.choices[0].message.content.strip())类似这样的自动化判分脚本能大大提速评测过程。不过我还是要提醒一句LLM-as-judge 对于事实性错误比较敏感但对格式错误、逻辑一致性这类问题可能漏判。如果你业务里对输出时效、格式要求很严最好在 Judge 之外再加一层规则校验比如“是否包含 JSON 字段”“是否包含订单号”等硬校验。5. 实战复盘一次跨厂商大模型 API 评测的完整流程讲了这么多理论分享一次真实评测案例吧。这是一个电商客服 RAG 项目需要从三家模型 API 里选一个作为底座任务包括订单查询、退换货流程解答、物流信息追问等。评测周期一共 5 天过程并不复杂但碰到的坑挺有代表性。5.1 评测方案设计第一天我们做了两件事从线上客服日志里抽了 200 条真实问题按功能拆成 4 组每组 50 条再从中挑出 20 条覆盖 RAG 检索增强的难题标注好标准答案。随后用公开基准做初筛把三个候选模型中一个明显偏弱的先淘汰掉。接下来对剩下两个模型做了质量和性能两轮评测。质量评测用 200 条业务样本跑批性能评测用上面那段 asyncio 脚本测 10 路并发和 50 路并发。最后统计单次会话成本再看了一眼两个模型在连续重试场景下的表现。5.2 质量评测结果一个尴尬的“平局”前两轮质量评测结果非常尴尬两个模型在 200 条业务样本上的准确率几乎一样一个 87%一个 88%。如果只看总分根本没法决策。这时候业务集拆分的价值就体现出来了分功能看模型 A 在“退款政策”类任务上显著优于模型 B91% 对 82%但模型 B 在“多轮订单状态查询”上更强特别是对上下文信息的保持能力更好。于是我们改变决策思路让模型 A 负责退款政策相关意图让模型 B 负责订单查询相关意图用路由把不同请求分到不同模型。这一改业务整体准确率提升到了 92%比任何单一模型都高。这也说明了评测样本要分组统计的原因总分掩盖了太多信息。5.3 性能评测结果被限流真相惊到性能评测阶段模型 A 的单并发 TTFT 中位数只要 400ms看着很漂亮。但并发跑到 50 时P95 直接飙到 6.8 秒而且开始出现零星 429 错误。模型 B 单并发时 800ms似乎慢一些但 50 并发下 P95 稳定在 2.1 秒没有报错。这个对比让我彻底明白单并发数据只能证明接口“能用”不能证明“够用”。在真实业务里用户请求是同时涌进来的高峰时 50 并发根本不算高。如果只被模型 A 的单并发快吸引等上线后大概率会被限流和排队打脸。后来我们专门看了两家文档模型 A 的免费配额只有 30 RPM模型 B 默认就给了 200 RPM这直接拉了差距。5.4 成本测算单价低的那个反而更贵成本核算也很有意思。模型 A 的单价确实便宜每百万输出 token 比模型 B 低 30%。但实际跑业务样本时模型 A 的无效输出特别多经常在回答后面重复一遍“如果您还有其他问题请随时咨询”甚至把检索到的无关文档内容也复述进来。最终统计单次会话平均消耗模型 A 比模型 B 多了 40% 的 output token。两者抵消后每千次会话的综合成本几乎持平。这个案例提醒我做成本对比时一定要用等量的“业务完成量”来做分母而不是等量的 token 数。用同一批业务样本、让模型完成同一批任务、统计平均消耗这才是可以横向比较的数据。否则你省下的单价都会在意外的 token 膨胀里还回去。5.5 踩坑记录评测中最常见的五个低级错误复盘时我把这次评测以及过往项目里的坑整理了一下列成了一份“低级错误清单”你们可以对照着避雷没做预热请求。第一次请求往往会触发连接建立、鉴权、冷启动不预热的话会把模型实际速度测慢 20% 到 50%。超时时间设得太短。默认的 10 秒超时在长文本生成场景下一定会误伤建议根据任务预期耗时设置 30 到 60 秒。忽略输出 token 数。两个模型生成同样一个回答一个输出 200 token一个输出 350 token延迟曲线完全不同不记录 token 就对比延迟等于耍流氓。只统计成功请求。失败请求全部滤掉后P95 会特别好看但那不是真实体验。至少要把超时和 429 单独拉出来看。用同一个 API Key 在本地脚本和多平台监控里混跑导致触发限流。评测本身请求量大最好申请专用 Key并注明限流版本。6. 结果解读与选型决策不要被总分骗了评测数据全部跑完最后一个环节是从数据到决策。这一步看似简单其实最容易犯经验主义错误。我常跟团队说的一句话是评测结果不是用来给你“选一个最好的”的而是用来帮你“理解每个模型的强弱边界”再根据业务约束做加权选择。6.1 分位数比平均值更诚实先看延迟类指标。平均值很容易被极端值拉偏比如 100 个请求里有 99 个是 300ms1 个是 15 秒平均值就是 447ms看起来还行但那个 15 秒的请求已经让用户流失了。所以我建议核心延迟指标一律看 P95 和 P99并且把最大值单独标出来。如果某个模型的 P99 是中位数的 3 倍以上说明它的服务质量抖动很厉害要在你的架构里预留足够的降级和重试空间。再看成功率。99% 的成功率听起来不错但换算到一天百万次调用就是一万次失败。如果关键链路失败会导致业务直接中断那 99% 完全不够。你需要评估失败请求的分布特征是集中在高峰期还是随机分散如果集中在高峰期说明是容量问题如果随机分散可能是限流策略或网络波动。不同的失败模式对架构设计的要求完全不同。6.2 质量与成本的权衡曲线在不少团队里质量指标和成本指标是分开开会讨论的算法说 A 模型好财务说 B 模型便宜最后吵半天没结论。我建议把两个模型在不同质量阈值下的“最小成本”画出来做成一条权衡曲线。比如你可以问为了达到 90% 业务准确率模型 A 和模型 B 每千次会话各要花多少钱如果模型 A 在 90% 准确率下成本是 20 元模型 B 需要 25 元那选 A如果你的业务要求 95% 准确率A 可能需要更换更大模型或大量重试成本翻倍而 B 可能通过 prompt 优化稳定在 95% 成本只涨 30%那选 B。这种曲线需要你在评测时多跑几个点不同 prompt 策略、不同温度、不同重试机制下质量和成本都会变化。一开始不用太细先跑两个点后面上线了再逐步补全。6.3 持续评测把评测脚本放进 CI让回归自动化最后也是最重要的一点评测不是一次性的。模型 API 的迭代没有停过你的业务也会持续增加新场景。我强烈建议把核心评测集固化下来脚本化并接入到 CI/CD 流程中。每当你要升级模型版本、更换供应商、调整 prompt 模板的时候自动跑一次评测对比新旧结果。如果准确率掉了 3 个百分点或者 P95 延迟涨了 1 秒系统就该报红。我在实际维护中发现自动化评测最大的阻力不是技术而是样本集过期。业务变快了评测样本跟不上跑出来的分数看起来很高其实测的都是老场景。所以每季度要花半天时间从真实日志里补充一批新样本人工复核一遍替换掉那些已不重要的旧样本。样本数量保持稳定质量持续更新这套评测流水线才能真正长期服务团队。按这个思路走下来你会发现自己对“大模型 API”这个市场的判断力会明显不一样。不再追着新闻热点跑而是手里握着自己业务的数据知道哪家模型在哪类任务上强、哪家服务在高峰时扛不住、哪家看起来便宜但实际消耗大。评测本身也变成一个团队能力沉淀成工具和样本集以后任何新模型出来都能在一天之内给出靠谱的答案。 大模型API选型实战指南：评测指标、方法、工具与避坑策略
最近半年好几拨朋友来找我聊大模型 API 选型开场白基本都是“我看 XX 模型最近很火是不是直接换掉现在的就行了”每次听到这种话我都要劝一句先别急着换“很火”和“适合你”之间还隔着一整套大模型 API 服务评测的流程。今天就把我这几年做模型服务评测的指标、方法和工具完整梳理一遍目标很直接帮你在面对一堆模型 API 时不再靠感觉拍板而是用数据说话。这篇指南不是什么学院派教科书也不是厂商宣传稿而是我从实际项目里踩坑踩出来的经验。适合正在做技术选型的后端开发、算法工程师、技术负责人也适合那些想把自己业务接进大模型 API、但不知道怎么评估效果的团队。文章会拆开讲四件事先立一套能落地的评测指标再讲评测方法怎么设计才不会测了个寂寞然后给出能直接抄的代码和工具链最后复盘一次真实选型中踩过的坑。1. 为什么“凭感觉选模型”在 API 时代行不通早几年用大模型基本是本地部署开源模型选型相对简单哪个测评分数高、哪个显存放得下就用哪个。但到了 API 时代情况完全变了。厂商把模型包成了服务你面对的是一堆参数、价格表、并发限制和不断迭代的版本号。同样是“7B 级别模型”不同厂商的 API 在延迟、限流策略、返回格式、成本结构上可能差出好几倍。只看模型名字和新闻稿上的榜单根本撑不起一个生产环境的选型决策。更重要的是API 服务的评测已经不再是“跑跑 benchmark 看分数”这么简单。你需要同时回答几类问题用户体验层面这个接口到底快不快、稳不稳模型能力层面它在我的业务场景里是不是真的聪明成本层面同样的预算能支撑多大并发工程层面限流、超时、错误提示是否可容忍。这些问题相互纠缠单看任何一面都会误判。比如某个模型单项延迟很低但一问复杂问题就频繁触发内容过滤导致重试率飙升最终真实延迟反而比竞品高一倍。还有一个很现实的原因模型 API 的更新频率在肉眼可见地加快。厂商经常发布新版本同一系列内部的不同型号比如轻量版、标准版、增强版能力差异极大。你上个月测出来的结论下个月可能就失效了。所以评测不只是一次性的选型动作而应该变成一套可以随时复跑的流程。我见过不少团队项目上线前简单测了下响应时间就定了模型结果三个月后业务高峰期频繁 429 限流一问才发现当初根本没做并发压测。这类问题靠感觉永远发现不了。所以我把这篇文章定义成“指南”而不是“报告”就是想强调一件事评测的价值不在于生成一份不可复现的结论而在于建立一套可持续运行的方法。你完全可以用下面的指标和工具构建属于自己的评测流水线把每次版本升级、每个候选新模型都放入同一套测试框架里横向比较。2. 评测指标体系先分清“体验指标”和“质量指标”做评测最容易犯的错误就是糊里糊涂地把所有指标混在一起算。我建议一上来就做个分类一类是“服务体验指标”回答“这个 API 用起来多快、多稳”另一类是“模型能力指标”回答“这个模型生成的答案到底行不行”第三类是“成本指标”回答“达到同样的服务水平要花多少钱”。三者分开测量、分开展示最终再放到一起做综合判断。2.1 服务体验指标延迟、吞吐、稳定性服务体验指标里最重要的几个分别是TTFTTime To First Token首 token 延迟。从请求发出到收到第一个 token 的时间。这个指标直接决定用户感知尤其在流式输出场景下TTFT 超过 3 秒用户基本就会觉得“卡住了”。TPOTTime Per Output Token平均每个输出 token 的间隔时间。它反映的是生成速度决定着长文本回答的总耗时。端到端延迟Total Latency从发出完整请求到收到完整响应的总时长。在非流式调用场景下这几乎是唯一指标。吞吐量Throughput单位时间内能完成的请求数常见单位是 RPSrequests per second也可以换算成 tokens/s。错误率与稳定性包括 4xx/5xx 错误率、超时率、P95/P99 延迟分位数。P99 能暴露长尾问题比如大多数请求 200ms但 1% 的请求卡了 10 秒这个卡顿对用户体验的伤害不亚于整体变慢。测量这些指标时有几个特别容易踩的坑。第一TTFT 不能用 SDK 默认的“等待完整响应计时”来算必须在流式接口里对首 token 单独计时。第二连接池必须复用否则把 TCP 握手时间也算进模型延迟里数字会虚高。第三要区分冷启动和热请求很多服务首次请求比后续请求慢得多评测时最好先发几个预热请求或者至少把第一轮数据单独标注出来。2.2 模型能力质量指标公开基准不等于业务效果模型能力的评测指标按数据来源可以分成两类。一类是公开基准比如 MMLU、GSM8K、HumanEval、BBH 等。它们的优点是可以快速比较不同模型也能和社区公开数据对照。缺点是它们和你的真实业务往往有偏差而且网上已经有大量“刷分”情况很多模型专门在这些基准上做过优化分数未必反映实际泛化能力。另一类是你自建的业务评测集从真实用户问题里采样一批有代表性的任务人工标注标准答案或打分维度。这类评测最接近真实效果但建设成本高、维护也麻烦。我强烈建议任何想认真做 API 选型的团队至少在核心业务上建 100 到 200 条业务评测样本用它们做最终裁决。公开基准只能当入门筛选的初筛别用它直接定生死。业务评测集也不一定都要人工打分。实践中常用的做法是三类注入第一类简单抽取看模型能否从给定文档里找到准确答案第二类逻辑推理看能不能完成多步推断第三类格式遵循看能不能严格输出 JSON 或指定结构。每条样本只需人工判断“通过/不通过”跑完就能算出准确率成本低可解释性也强。2.3 成本指标别只看每百万 token 价格很多人评测 API 只盯着官网的单价这是大误区。单价只是“目录价”真实成本还得看实际消耗和额外开销。完整的成本指标应该包括输入与输出 token 的单价当前主流 API 都区分 input 和 output且 output 通常贵得多。实际消耗量同一个任务不同模型的 token 消耗差异可能很大。有的模型答非所问、废话连篇虽然单价便宜但实际花费反而更高。重试与补偿成本如果模型频繁触发限流或内容过滤你就需要重试重试次数直接翻倍成本。缓存成本如果你做了 prompt 缓存或语义缓存实际计费 token 会低于原始 token这个也要纳入测算。我建议统一用一个复合指标每千次有效业务的 token 消耗 × 实际单价。例如做客服问答一次完整会话可能会调用三到五次模型每轮都要有上下文最终算出来单次会话成本才具备真正的横向可比性。2.4 工程可用性指标限流、配额与版本稳定性最后这类指标经常被忽略但在生产环境里最要命。你需要确认厂商的限流策略是否匹配你的业务峰值每分钟最大请求数RPM、每分钟最大 token 数TPM分别是多少超出之后是排队还是直接拒绝配额是每天重置还是每小时重置万一连续几天流量上涨是否可以申请临时扩容此外还要看错误响应里有没有明确的 retry-after 头限流错误的 body 是否包含友好的提示。好的 API 设计能让你快速实现优雅降级差的 API 设计会让客户端在高峰期直接雪崩。版本稳定性也很关键。很多模型 API 会有多个版本号比如 v1、v2 或带日期后缀的版本不同版本的参数格式、返回字段可能不一致。评测时必须锁定版本记录 UUID 或版本号否则后面复测时数据对不上还以为是模型退化了。我见过某项目上线后某一晚突然准确率断崖下跌查了很久才发现厂商悄悄切换了默认模型版本旧参数在新版本上被忽略输出格式变了。指标维度核心指标测量方式参考经验体验TTFT / TPOT / 总延迟流式接口对首 token 计时TTFT 在线业务建议 P95 3s稳定性P95/P99 延迟、错误率、429 率压测脚本统计分位数P99/平均 大于 3 倍时警惕长尾能力公开基准 业务评测集离线跑批 人工/自动判分业务评测集优先成本单次业务成本、token 消耗、重试率日志统计 价格表以“每千次业务”为单位工程RPM/TPM 限制、版本锁定、SLA阅读文档 实测触发限流必须与峰值流量对比3. 评测方法设计从“刷榜”到“贴近业务”的实验流程指标定好之后下一步就是设计评测流程。很多人把评测想得太随意随便写几个 prompt发给几个 API看谁回得快、谁答得通顺就下结论。这种评测基本经不起推敲变量都没控制住得出的结论自然不可信。规范的评测方法关键在于三个环节评测集怎么建、实验怎么控变量、结果怎么解释。3.1 评测集建设公开基准筛选、业务集定胜负我推荐的流程是“分层漏斗”第一层用公开基准做粗筛把明显不靠谱的模型排除掉。比如你要做中文客服先跑一遍 C-Eval 或中文问答类评测低于某个阈值的模型直接出局。第二层用自建业务评测集做精测样本量不用特别大但要保证覆盖核心场景的各个子任务。自建业务评测集的样本设计有四个维度不能漏功能维度你的产品有哪些核心功能点客服机器人的退款、改地址、查订单是不同功能每个功能至少留 10 到 20 条样本。难度维度简单询问、复杂多轮、需要检索增强的都要照顾到。如果只测简单问题评测结果会明显偏向“话痨型”模型。格式维度需要输出 JSON、纯文本、还是 Markdown每个格式单独分组统计方便定位问题。边界与违规样本包括无关问题用户乱说话、敏感边缘问题、超长上下文问题。这些能测试模型的安全性和鲁棒性。每一条样本最好都写好“期望行为”说明并尽量给出参考答案。评测判分标准要提前定义是逐字匹配还是允许同义改写我建议对大多数业务场景采用“五点打分制”1 分完全错误5 分完全正确并且由一个固定的人或小型标注团队统一打分避免多人评分标准漂移。3.2 控制变量温度、上下文、版本、并发必须统一模型评测不控制变量结果就是垃圾进垃圾出。以下是必须锁定的变量温度temperature必须统一建议设 0.1 到 0.3 的低温度减少随机性。你评测的是模型的确定性能力不是它的创作能力尤其客服、信息抽取类任务更是如此。上下文内容同一批 prompt 必须完全一致。别因为某个模型支持更长上下文就额外给它加一堆背景知识这会直接破坏公平性。输出长度建议设置 max_tokens 上限防止某个模型因为生成长文而拉高延迟导致性能对比失真。评测能力时报告里要标注实际输出 token 数不能只看总时长。模型版本锁定 API 返回的具体版本号最好从响应头里读取。同一系列模型v1 和 v2 差别极大。并发度做性能评测时并发数必须作为显式变量。分别测并发 1、10、50、100 的情况画出延迟随并发变化的曲线。只看单并发没意义因为生产系统几乎不会只有一个人在调用。3.3 评测执行顺序与轮次交替执行、多次取中位数顺序上也有讲究。如果同一时刻只测 A 模型再测 B 模型可能会被服务端高峰、网络抖动等因素干扰。正确做法是分多轮交替执行先跑一轮 A 和 B 各 100 条记录结果休息一会儿再跑一轮 B 和 A 各 100 条。这样可以抵消时间段偏差。每轮样本建议至少 3 次重复取中位数或平均值。如果某条样本某次返回超时要保留记录不能直接丢弃因为超时也是服务质量的真实表现。不过要把“模型能力”和“服务稳定性”两个维度分开记录模型答得好不好只有成功返回的样本才参与计分超时、报错、限流则单独计入稳定性指标。3.4 评测结果记录结构化的日志才能复盘评测过程中必须把完整的请求上下文保存下来包括请求时间、模型版本、prompt、完整响应、延迟数据、token 用量、错误信息。我一般建议直接输出 JSONL 格式的文件一条请求一行。后面做任何分析无论是统计 token 成本还是追溯某个失败案例都能快速定位。数据记录里尤其要注意 token 用量。OpenAI 兼容接口通常会在 usage 字段里给出 prompt_tokens、completion_tokens、total_tokens这些是从计费角度最准确的数据。有些非标准 SDK 不暴露 usage你需要自己数 token 或者用官方 tokenizer 估算这会带来成本误差评测报告里必须注明估算方式。4. 评测工具与脚本几行代码拿到关键指标指标和方法有了接下来就是工具。我见过不少团队一上来就搭很重的评测平台结果平台还没搭完业务需求早变了。更务实的路径是从脚本到平台逐步演进先用一段 Python 脚本跑通流程再引入开源评测框架做质量管理最后才考虑是否需要自建 Web 平台。4.1 工具选型按阶段挑别一步到位工具类别适用阶段特点与注意事项Promptfoo评测框架小规模对比支持 YAML 配置测试用例、自动判分、输出 HTML 报告适合 100 条以内的快速对比DeepEval评测框架单元测试提供了 LLM-as-a-judge、G-Eval、答案相似度等多种指标适合集成进 CIRagas检索增强评测RAG 场景专注检索相关性和生成 faithfulness适合已经有 RAG 管线的团队LangSmith / Langfuse可观测平台线上追踪能记录真实请求链路、token 消耗、延迟做线上质量回归k6 / Locust压测工具并发与性能两者都支持 HTTP 压测Locust 用 Python 写压测脚本k6 用 JavaScript上手难度差不多自建 asyncio 脚本专项评测精细化指标灵活测量 TTFT、TPOT、分位数我建议每个团队都保留一个这样的脚本工具不是越多越好核心是“够用”。我的建议是刚开始做评测用 Promptfoo 或 DeepEval 跑质量指标用 Locust 跑并发压测再用自建脚本补齐 TTFT、TPOT 这类流式指标。等你已经有线上流量之后再引入 Langfuse 做持续监控。4.2 自建性能测试脚本一次拿到 TTFT、TPOT 与分位数下面这段 Python 脚本是我自己常用的性能测试骨架利用 asyncio 并发调用 OpenAI 兼容接口并记录关键延迟。代码刻意保持精简方便你改造。import asyncio import statistics import time import httpx API_BASE https://api.example.com/v1 API_KEY your-key MODEL qwen-plus PROMPT 用三句话介绍大模型 API 评测的核心指标。 async def stream_once(client, payload): start time.perf_counter() first_token_time None tokens 0 try: async with client.stream( POST, f{API_BASE}/chat/completions, jsonpayload, headers{Authorization: fBearer {API_KEY}}, ) as resp: resp.raise_for_status() async for line in resp.aiter_lines(): if line.startswith(data:) and line ! data: [DONE]: if first_token_time is None: first_token_time time.perf_counter() - start tokens 1 total_time time.perf_counter() - start return { success: True, ttft: first_token_time, total: total_time, tokens: tokens, } except Exception as exc: return {success: False, error: str(exc)} async def run_concurrent(concurrency, rounds): payload { model: MODEL, messages: [{role: user, content: PROMPT}], temperature: 0.2, max_tokens: 200, stream: True, } async with httpx.AsyncClient(timeout30) as client: tasks [] for _ in range(rounds): tasks.append(stream_once(client, payload)) results await asyncio.gather(*tasks) success_results [r for r in results if r.get(success)] ttft_list [r[ttft] * 1000 for r in success_results] total_list [r[total] * 1000 for r in success_results] print(f并发 {concurrency}成功率 {len(success_results)}/{len(results)}) if ttft_list: print(fTTFT 中位数 {statistics.median(ttft_list):.0f}msP95 {sorted(ttft_list)[int(len(ttft_list) * 0.95) - 1]:.0f}ms) print(f总延迟 中位数 {statistics.median(total_list):.0f}msP95 {sorted(total_list)[int(len(total_list) * 0.95) - 1]:.0f}ms) print(f平均吞吐 {len(success_results) / (sum(total_list) / 1000):.1f} req/s) for concurrency in [1, 10, 30]: asyncio.run(run_concurrent(concurrency, rounds30))这段脚本做了几件事用 streamTrue 精确计算 TTFT统计总延迟和 token 数输出成功率、中位数和 P95。注意脚本里我刻意没有复用同一个连接池的推导而是直接用 AsyncClient 的默认连接池。实际评测时建议把连接数上限和 keep-alive 参数调大否则并发一高本地连接池先成为瓶颈测出来的数据就不是服务端真实水平了。4.3 质量评测脚本用 LLM-as-judge 解放人力自建业务评测集到 500 条以上后纯人工打分就变成负担。此时可以用“LLM-as-judge”方案让一个强模型当裁判给候选模型的输出打分。当然Judge 模型本身也有偏差所以不能盲信建议先用一个几十条的小样本把 Judge 模型的打分和人工打分做一致性比对相关系数高了再用。import openai judge_client openai.OpenAI(api_keyyour-key, base_urlhttps://api.example.com/v1) scoring_prompt 你是客服质量评测员。根据以下任务、标准答案和模型回答输出 1-5 分。 要求只输出数字不要解释。 任务用户咨询退款到账时间 标准答案退款通常在 3-5 个工作日内到账具体取决于原支付渠道。 模型回答{response} def score_response(response): prompt scoring_prompt.format(responseresponse) res judge_client.chat.completions.create( modeljudge-model, messages[{role: user, content: prompt}], temperature0, max_tokens5, ) return int(res.choices[0].message.content.strip())类似这样的自动化判分脚本能大大提速评测过程。不过我还是要提醒一句LLM-as-judge 对于事实性错误比较敏感但对格式错误、逻辑一致性这类问题可能漏判。如果你业务里对输出时效、格式要求很严最好在 Judge 之外再加一层规则校验比如“是否包含 JSON 字段”“是否包含订单号”等硬校验。5. 实战复盘一次跨厂商大模型 API 评测的完整流程讲了这么多理论分享一次真实评测案例吧。这是一个电商客服 RAG 项目需要从三家模型 API 里选一个作为底座任务包括订单查询、退换货流程解答、物流信息追问等。评测周期一共 5 天过程并不复杂但碰到的坑挺有代表性。5.1 评测方案设计第一天我们做了两件事从线上客服日志里抽了 200 条真实问题按功能拆成 4 组每组 50 条再从中挑出 20 条覆盖 RAG 检索增强的难题标注好标准答案。随后用公开基准做初筛把三个候选模型中一个明显偏弱的先淘汰掉。接下来对剩下两个模型做了质量和性能两轮评测。质量评测用 200 条业务样本跑批性能评测用上面那段 asyncio 脚本测 10 路并发和 50 路并发。最后统计单次会话成本再看了一眼两个模型在连续重试场景下的表现。5.2 质量评测结果一个尴尬的“平局”前两轮质量评测结果非常尴尬两个模型在 200 条业务样本上的准确率几乎一样一个 87%一个 88%。如果只看总分根本没法决策。这时候业务集拆分的价值就体现出来了分功能看模型 A 在“退款政策”类任务上显著优于模型 B91% 对 82%但模型 B 在“多轮订单状态查询”上更强特别是对上下文信息的保持能力更好。于是我们改变决策思路让模型 A 负责退款政策相关意图让模型 B 负责订单查询相关意图用路由把不同请求分到不同模型。这一改业务整体准确率提升到了 92%比任何单一模型都高。这也说明了评测样本要分组统计的原因总分掩盖了太多信息。5.3 性能评测结果被限流真相惊到性能评测阶段模型 A 的单并发 TTFT 中位数只要 400ms看着很漂亮。但并发跑到 50 时P95 直接飙到 6.8 秒而且开始出现零星 429 错误。模型 B 单并发时 800ms似乎慢一些但 50 并发下 P95 稳定在 2.1 秒没有报错。这个对比让我彻底明白单并发数据只能证明接口“能用”不能证明“够用”。在真实业务里用户请求是同时涌进来的高峰时 50 并发根本不算高。如果只被模型 A 的单并发快吸引等上线后大概率会被限流和排队打脸。后来我们专门看了两家文档模型 A 的免费配额只有 30 RPM模型 B 默认就给了 200 RPM这直接拉了差距。5.4 成本测算单价低的那个反而更贵成本核算也很有意思。模型 A 的单价确实便宜每百万输出 token 比模型 B 低 30%。但实际跑业务样本时模型 A 的无效输出特别多经常在回答后面重复一遍“如果您还有其他问题请随时咨询”甚至把检索到的无关文档内容也复述进来。最终统计单次会话平均消耗模型 A 比模型 B 多了 40% 的 output token。两者抵消后每千次会话的综合成本几乎持平。这个案例提醒我做成本对比时一定要用等量的“业务完成量”来做分母而不是等量的 token 数。用同一批业务样本、让模型完成同一批任务、统计平均消耗这才是可以横向比较的数据。否则你省下的单价都会在意外的 token 膨胀里还回去。5.5 踩坑记录评测中最常见的五个低级错误复盘时我把这次评测以及过往项目里的坑整理了一下列成了一份“低级错误清单”你们可以对照着避雷没做预热请求。第一次请求往往会触发连接建立、鉴权、冷启动不预热的话会把模型实际速度测慢 20% 到 50%。超时时间设得太短。默认的 10 秒超时在长文本生成场景下一定会误伤建议根据任务预期耗时设置 30 到 60 秒。忽略输出 token 数。两个模型生成同样一个回答一个输出 200 token一个输出 350 token延迟曲线完全不同不记录 token 就对比延迟等于耍流氓。只统计成功请求。失败请求全部滤掉后P95 会特别好看但那不是真实体验。至少要把超时和 429 单独拉出来看。用同一个 API Key 在本地脚本和多平台监控里混跑导致触发限流。评测本身请求量大最好申请专用 Key并注明限流版本。6. 结果解读与选型决策不要被总分骗了评测数据全部跑完最后一个环节是从数据到决策。这一步看似简单其实最容易犯经验主义错误。我常跟团队说的一句话是评测结果不是用来给你“选一个最好的”的而是用来帮你“理解每个模型的强弱边界”再根据业务约束做加权选择。6.1 分位数比平均值更诚实先看延迟类指标。平均值很容易被极端值拉偏比如 100 个请求里有 99 个是 300ms1 个是 15 秒平均值就是 447ms看起来还行但那个 15 秒的请求已经让用户流失了。所以我建议核心延迟指标一律看 P95 和 P99并且把最大值单独标出来。如果某个模型的 P99 是中位数的 3 倍以上说明它的服务质量抖动很厉害要在你的架构里预留足够的降级和重试空间。再看成功率。99% 的成功率听起来不错但换算到一天百万次调用就是一万次失败。如果关键链路失败会导致业务直接中断那 99% 完全不够。你需要评估失败请求的分布特征是集中在高峰期还是随机分散如果集中在高峰期说明是容量问题如果随机分散可能是限流策略或网络波动。不同的失败模式对架构设计的要求完全不同。6.2 质量与成本的权衡曲线在不少团队里质量指标和成本指标是分开开会讨论的算法说 A 模型好财务说 B 模型便宜最后吵半天没结论。我建议把两个模型在不同质量阈值下的“最小成本”画出来做成一条权衡曲线。比如你可以问为了达到 90% 业务准确率模型 A 和模型 B 每千次会话各要花多少钱如果模型 A 在 90% 准确率下成本是 20 元模型 B 需要 25 元那选 A如果你的业务要求 95% 准确率A 可能需要更换更大模型或大量重试成本翻倍而 B 可能通过 prompt 优化稳定在 95% 成本只涨 30%那选 B。这种曲线需要你在评测时多跑几个点不同 prompt 策略、不同温度、不同重试机制下质量和成本都会变化。一开始不用太细先跑两个点后面上线了再逐步补全。6.3 持续评测把评测脚本放进 CI让回归自动化最后也是最重要的一点评测不是一次性的。模型 API 的迭代没有停过你的业务也会持续增加新场景。我强烈建议把核心评测集固化下来脚本化并接入到 CI/CD 流程中。每当你要升级模型版本、更换供应商、调整 prompt 模板的时候自动跑一次评测对比新旧结果。如果准确率掉了 3 个百分点或者 P95 延迟涨了 1 秒系统就该报红。我在实际维护中发现自动化评测最大的阻力不是技术而是样本集过期。业务变快了评测样本跟不上跑出来的分数看起来很高其实测的都是老场景。所以每季度要花半天时间从真实日志里补充一批新样本人工复核一遍替换掉那些已不重要的旧样本。样本数量保持稳定质量持续更新这套评测流水线才能真正长期服务团队。按这个思路走下来你会发现自己对“大模型 API”这个市场的判断力会明显不一样。不再追着新闻热点跑而是手里握着自己业务的数据知道哪家模型在哪类任务上强、哪家服务在高峰时扛不住、哪家看起来便宜但实际消耗大。评测本身也变成一个团队能力沉淀成工具和样本集以后任何新模型出来都能在一天之内给出靠谱的答案。