企业官网建设流程全解析

最近半年，好几拨朋友来找我聊大模型 API 选型，开场白基本都是：“我看 XX 模型最近很火，是不是直接换掉现在的就行了？”每次听到这种话，我都要劝一句：先别急着换，“很火”和“适合你”之间，还隔着一整套大模型 API 服务评测的流程。今天就把我这几年做模型服务评测的指标、方法和工具完整梳理一遍，目标很直接：帮你在面对一堆模型 API 时，不再靠感觉拍板，而是用数据说话。

这篇指南不是什么学院派教科书，也不是厂商宣传稿，而是我从实际项目里踩坑踩出来的经验。适合正在做技术选型的后端开发、算法工程师、技术负责人，也适合那些想把自己业务接进大模型 API、但不知道怎么评估效果的团队。文章会拆开讲四件事：先立一套能落地的评测指标，再讲评测方法怎么设计才不会测了个寂寞，然后给出能直接抄的代码和工具链，最后复盘一次真实选型中踩过的坑。

1. 为什么“凭感觉选模型”在 API 时代行不通

早几年用大模型，基本是本地部署开源模型，选型相对简单：哪个测评分数高、哪个显存放得下，就用哪个。但到了 API 时代，情况完全变了。厂商把模型包成了服务，你面对的是一堆参数、价格表、并发限制和不断迭代的版本号。同样是“7B 级别模型”，不同厂商的 API 在延迟、限流策略、返回格式、成本结构上可能差出好几倍。只看模型名字和新闻稿上的榜单，根本撑不起一个生产环境的选型决策。

更重要的是，API 服务的评测已经不再是“跑跑 benchmark 看分数”这么简单。你需要同时回答几类问题：用户体验层面，这个接口到底快不快、稳不稳；模型能力层面，它在我的业务场景里是不是真的聪明；成本层面，同样的预算能支撑多大并发；工程层面，限流、超时、错误提示是否可容忍。这些问题相互纠缠，单看任何一面都会误判。比如某个模型单项延迟很低，但一问复杂问题就频繁触发内容过滤，导致重试率飙升，最终真实延迟反而比竞品高一倍。

还有一个很现实的原因：模型 API 的更新频率在肉眼可见地加快。厂商经常发布新版本，同一系列内部的不同型号（比如轻量版、标准版、增强版）能力差异极大。你上个月测出来的结论，下个月可能就失效了。所以评测不只是一次性的选型动作，而应该变成一套可以随时复跑的流程。我见过不少团队，项目上线前简单测了下响应时间就定了模型，结果三个月后业务高峰期频繁 429 限流，一问才发现当初根本没做并发压测。这类问题，靠感觉永远发现不了。

所以我把这篇文章定义成“指南”而不是“报告”，就是想强调一件事：评测的价值不在于生成一份不可复现的结论，而在于建立一套可持续运行的方法。你完全可以用下面的指标和工具，构建属于自己的评测流水线，把每次版本升级、每个候选新模型，都放入同一套测试框架里横向比较。

2. 评测指标体系：先分清“体验指标”和“质量指标”

做评测最容易犯的错误，就是糊里糊涂地把所有指标混在一起算。我建议一上来就做个分类：一类是“服务体验指标”，回答“这个 API 用起来多快、多稳”；另一类是“模型能力指标”，回答“这个模型生成的答案到底行不行”；第三类是“成本指标”，回答“达到同样的服务水平要花多少钱”。三者分开测量、分开展示，最终再放到一起做综合判断。

2.1 服务体验指标：延迟、吞吐、稳定性

服务体验指标里，最重要的几个分别是：

• TTFT（Time To First Token），首 token 延迟。从请求发出到收到第一个 token 的时间。这个指标直接决定用户感知，尤其在流式输出场景下，TTFT 超过 3 秒，用户基本就会觉得“卡住了”。
• TPOT（Time Per Output Token），平均每个输出 token 的间隔时间。它反映的是生成速度，决定着长文本回答的总耗时。
• 端到端延迟（Total Latency），从发出完整请求到收到完整响应的总时长。在非流式调用场景下，这几乎是唯一指标。
• 吞吐量（Throughput），单位时间内能完成的请求数，常见单位是 RPS（requests 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 或版本号，否则后面复测时数据对不上，还以为是模型退化了。我见过某项目上线后某一晚突然准确率断崖下跌，查了很久才发现厂商悄悄切换了默认模型版本，旧参数在新版本上被忽略，输出格式变了。

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 或 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", json=payload, headers={"Authorization": f"Bearer {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(timeout=30) 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(f"TTFT 中位数 {statistics.median(ttft_list):.0f}ms，P95 {sorted(ttft_list)[int(len(ttft_list) * 0.95) - 1]:.0f}ms") print(f"总延迟 中位数 {statistics.median(total_list):.0f}ms，P95 {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, rounds=30))

这段脚本做了几件事：用 stream=True 精确计算 TTFT，统计总延迟和 token 数，输出成功率、中位数和 P95。注意脚本里我刻意没有复用同一个连接池的推导，而是直接用 AsyncClient 的默认连接池。实际评测时，建议把连接数上限和 keep-alive 参数调大，否则并发一高，本地连接池先成为瓶颈，测出来的数据就不是服务端真实水平了。

4.3 质量评测脚本：用 LLM-as-judge 解放人力

自建业务评测集到 500 条以上后，纯人工打分就变成负担。此时可以用“LLM-as-judge”方案，让一个强模型当裁判，给候选模型的输出打分。当然，Judge 模型本身也有偏差，所以不能盲信；建议先用一个几十条的小样本，把 Judge 模型的打分和人工打分做一致性比对，相关系数高了再用。

import openai judge_client = openai.OpenAI(api_key="your-key", base_url="https://api.example.com/v1") scoring_prompt = """ 你是客服质量评测员。根据以下任务、标准答案和模型回答，输出 1-5 分。 要求：只输出数字，不要解释。 任务：用户咨询退款到账时间 标准答案：退款通常在 3-5 个工作日内到账，具体取决于原支付渠道。 模型回答：{response} """ def score_response(response): prompt = scoring_prompt.format(response=response) res = judge_client.chat.completions.create( model="judge-model", messages=[{"role": "user", "content": prompt}], temperature=0, max_tokens=5, ) 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 在“退款政策”类任务上显著优于模型 B，91% 对 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 个是 300ms，1 个是 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”这个市场的判断力会明显不一样。不再追着新闻热点跑，而是手里握着自己业务的数据，知道哪家模型在哪类任务上强、哪家服务在高峰时扛不住、哪家看起来便宜但实际消耗大。评测本身也变成一个团队能力，沉淀成工具和样本集，以后任何新模型出来，都能在一天之内给出靠谱的答案。