如何对LLM大型语言模型进行评估与基准测试：从性能指标到推理能力的落地实践-北京尧图网络

1. 为什么你的 LLM 选型总在“跑分好看、上线翻车”之间反复横跳很多团队在给大型语言模型做评估时第一反应是去翻某个榜单看谁家分数高就选谁。结果模型接进业务后用户抱怨“回答半天蹦不出第一个字”或者高峰期请求排队到超时再或者同一段提示词今天答得挺好、明天就开始胡言乱语。问题不在于模型本身不行而在于评估口径和真实场景脱节了。LLM 评估与基准测试本质上是回答三个问题这个模型在我的输入输出长度分布下首 Token 要等多久、每秒能吐多少 Token、连续跑几千个请求会不会崩。它适合需要为模型选型与上线把关的工程团队也适合正在做推理成本优化的后端同学。你不需要一上来就搭一套庞大的压测集群但必须有一套可复现的配置固定的数据集、固定的评测脚本、固定的指标口径否则不同工具跑出来的数字根本没法横向比。我见过最常见的坑是拿负载测试的结论去做性能基准测试的判断。负载测试模拟的是一群用户同时访问关心的是“顶得住多少人”性能基准测试专注模型本身的吞吐和延迟关心的是“跑得有多快”。两者混着做就会出现“并发调高后 TPS 涨了但单用户 TPS 掉了一半”这种看似矛盾、实则正常的现象。所以这篇内容会从指标定义讲起一路落到可复制的配置文件和验证脚本并且用统一的 API 通道接入被测模型保证你换模型时只改一个 Model ID不用重写整套评测代码。2. 用 TaoToken 统一 Key 与 API 通道把被测模型接进评测脚本做基准测试最烦的事情之一是每换一个模型就要改一遍 SDK、换一套鉴权、对一遍 Base URL。为了让评测脚本保持稳定我习惯把所有被测模型收敛到同一个 OpenAI 兼容通道上这样评测代码里只变model字段其余逻辑完全不动。TaoToken 在这里扮演的就是这个统一入口官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 可以了解整体能力API 地址是 https://taotoken.net/api兼容 OpenAI 的/v1/chat/completions形态流式和非流式都支持。前置准备其实就三步。第一步在控制台创建一个 API Key建议按评测项目单独建 Key方便后面看调用量和排障。第二步确认你要测的模型 ID不同模型的上下文长度和最大输出 Token 数不一样这个参数会直接影响你的 ISL/OSL 设定。第三步把 Base URL 和 Key 写进环境变量别硬编码在脚本里后面跑多轮对比时你会感谢自己。export TAOTOKEN_BASE_URLhttps://taotoken.net/api/v1 export TAOTOKEN_API_KEYsk-你的评测专用Key这里有个细节值得展开评测脚本里一定要显式设置stream: true和stream_options: {include_usage: true}。前者让你能测到 TTFT首 Token 时间后者让你在流式结束后拿到准确的 prompt_tokens 和 completion_tokens避免自己数 Token 数出偏差。很多工具在统计 TPS 时口径不一致就是因为有的把请求准备时间算进去了有的没算自己拿 usage 字段算最稳。另外提醒一句评测用的 Key 和线上业务 Key 分开别拿生产 Key 去跑几千次压测既不好归因也容易触发限流策略。控制台里可以给 Key 加备注写上“LLM-bench-2025Q1”这类标识后面回看调用记录时一目了然。如果你要测的是长期编码或 Agent 类场景可以顺带看一下 Coding Plan 的额度形态避免评测跑到一半额度不够中断导致样本量不完整。3. 可复制的基准测试配置数据集、评测脚本与指标口径这一节是整篇的核心我会给出一份可以直接落地的配置。先说数据集。你不需要去找什么公开榜单最贴近业务的做法是从真实日志里采样 200 到 500 条请求按输入长度分桶短输入约 100 Token比如分类、意图识别、中等输入约 500 到 2000 Token比如翻译、摘要、长输入1000 Token 以上比如 RAG 检索增强后的问答。输出长度也要标注预期生成类任务 OSL 可能到 1000 以上摘要类任务 OSL 通常只有 100 左右。把数据集存成 JSONL每行一条字段包括id、prompt、expected_output_tokens、bucket。这样评测脚本可以按桶统计而不是只给一个全局平均数——全局平均最容易被长尾请求带偏。{id: case-001, bucket: short, prompt: 把下面这句话翻译成英文今天天气很好。, expected_output_tokens: 20} {id: case-002, bucket: medium, prompt: 请总结以下会议纪要的三个关键决策点……, expected_output_tokens: 150} {id: case-003, bucket: long, prompt: 基于以下检索文档回答用户问题……, expected_output_tokens: 300}接下来是评测脚本。用 Python 写一个最小可用的 runner核心逻辑是对每条样本发起流式请求记录请求发出时间、首个非空 chunk 到达时间、最后一个 chunk 到达时间以及 usage 里的 completion_tokens。TTFT 就是首个 chunk 时间减去请求发出时间ITL 用最后 chunk 时间减首个 chunk 时间除以completion_tokens 减 1端到端延迟就是最后 chunk 时间减请求发出时间。注意要过滤掉空字符串的初始响应否则 TTFT 会被污染成接近 0 的假值。import os, time, json, statistics from openai import OpenAI client OpenAI( base_urlos.environ[TAOTOKEN_BASE_URL], api_keyos.environ[TAOTOKEN_API_KEY], ) def run_one(prompt, model你的模型ID, max_tokens512): t0 time.perf_counter() first_token_at None last_chunk_at None usage None stream client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], max_tokensmax_tokens, temperature0, streamTrue, stream_options{include_usage: True}, ) for chunk in stream: now time.perf_counter() if chunk.choices and chunk.choices[0].delta.content: if first_token_at is None: first_token_at now last_chunk_at now if chunk.usage: usage chunk.usage completion_tokens usage.completion_tokens if usage else 0 ttft (first_token_at - t0) if first_token_at else None e2e (last_chunk_at - t0) if last_chunk_at else None itl None if first_token_at and last_chunk_at and completion_tokens 1: itl (last_chunk_at - first_token_at) / (completion_tokens - 1) return {ttft: ttft, e2e: e2e, itl: itl, completion_tokens: completion_tokens}指标口径要提前定死写进 README避免不同人跑出不同结论。我建议的口径是TTFT 取 P50 和 P95ITL 取均值TPS 用总 completion_tokens 除以从第一个请求发出到最后一个响应完成的墙钟时间RPS 用成功请求数除以同一段时间。采样参数统一用temperature0Greedy并且设置ignore_eos等价行为——也就是把max_tokens设成你期望的固定长度让每次输出长度一致否则短回答会把 ITL 拉低、长回答会把 ITL 拉高横向对比就失真了。并发控制建议从 1 开始逐步加到略高于推理引擎的最大批处理大小。你可以用concurrency参数控制同时活跃的请求数每完成一个就补一个保证系统里始终有 N 个在途请求。这个方式比固定请求速率更稳因为速率控制下如果系统处理不过来未完成请求会无限堆积最后测出来的延迟全是排队时间。4. 验证请求与成功结果跑分对比、延迟复测与稳定性观察配置写好后先做一次单并发冒烟验证确认通道和脚本都通。跑一条样本打印 TTFT、ITL、completion_tokens看数值是否在合理范围。如果 TTFT 是几百毫秒到一两秒、ITL 在几十毫秒量级说明链路正常。这一步别省我踩过的坑就是流式开关没生效结果 TTFT 等于端到端延迟白跑了一轮。冒烟通过后按桶跑全量数据集每个桶至少 100 条样本记录 P50/P95 的 TTFT 和端到端延迟。然后做并发阶梯测试并发 1、4、8、16每个档位跑 3 分钟或跑完固定样本量观察 TPS 是否随并发上升后趋于饱和、单用户 TPS 是否随并发上升而下降。这个交叉点就是你系统的“甜点并发”超过它再加并发只会让延迟变差、吞吐不涨。稳定性复测建议至少跑 30 分钟连续请求观察 ITL 是否随时间漂移。如果 ITL 在前 10 分钟稳定、后面逐渐变大通常是 KV Cache 增长或显存碎片导致的这时候要回头看你的最大上下文长度设置是否合理。另一个观察点是错误率401、429、超时分别计数429 说明触发了限流需要降低请求速率或申请更高额度超时则要区分是网络问题还是模型生成卡住。成功结果的判定标准我一般设三条目标桶的 P95 TTFT 低于业务可接受阈值比如对话场景 2 秒内、ITL 均值稳定且无随时间上升趋势、连续 30 分钟错误率低于 1%。三条都过才进入下一轮模型对比。对比时保持数据集、采样参数、并发档位完全一致只换 Model ID这样跑出来的差异才能归因到模型本身。5. 本篇常见错排查401、local proxy failed、reading choices 与 OAuth 报错评测跑不起来八成是下面这几类报错。逐个说清楚现象和修法。401 Unauthorized最常见。先确认TAOTOKEN_API_KEY环境变量真的被读到了别出现 shell 里 export 了但 Python 进程没继承的情况。其次检查 Key 有没有多余空格或换行复制粘贴时很容易带上。如果 Key 确认无误还是 401去控制台看这个 Key 是否被禁用或额度耗尽。注意 Base URL 要带/v1写成https://taotoken.net/api/v1少写/v1有些客户端会拼出错误路径返回的也可能是 401 或 404。local proxy failed / connection refused这类报错通常出现在客户端配置了本地代理但代理没启动或者环境变量里残留了HTTP_PROXY、HTTPS_PROXY指向一个不存在的端口。排查方法是先unset掉这些变量再跑一次确认是不是代理配置问题。评测脚本里建议显式不传代理参数保持直连避免中间层干扰延迟测量。reading choices 相关报错典型信息是KeyError: choices或list index out of range发生在解析响应时。原因一般是请求失败但脚本没检查状态码就直接取choices[0]或者流式模式下某个 chunk 的choices是空数组比如最后一个只带 usage 的 chunk。修法是解析前先判断if chunk.choices and len(chunk.choices) 0并且对非流式响应先看response.choices是否存在。另外确认max_tokens没有设成 0 或负数否则可能返回空 choices。OAuth / token 过期类报错如果你用的是某些需要 OAuth 流程的客户端比如 Claude Code 这类工具报错信息里会出现 token 刷新失败或授权失效。这类问题的根因通常是客户端缓存了旧的凭证。处理方式是清理客户端配置目录下的凭证缓存重新走一次授权。如果你是通过 API Key 方式接入就不涉及 OAuth直接检查 Key 即可。这里要强调三件套必须写全Base URL、API Key、Model ID缺一个都会在鉴权或路由阶段报错而且报错信息往往不直接指向缺失项容易绕弯路。还有一个隐蔽的坑并发调高后出现大量超时但单条请求手动跑又正常。这通常是客户端连接池太小或者没复用 HTTP 连接导致每次请求都重新握手。把客户端超时时间调大、连接池调大再复测一轮往往就恢复了。6. 把评测固化成流程从一次性跑分到持续回归一次性跑分只能回答“今天这个模型行不行”回答不了“下周换了个版本还行不行”。所以最后一步是把上面这套东西固化成可重复执行的流程。我的做法是把数据集、runner 脚本、指标计算和阈值判断打包成一个目录用一条命令跑完输出一份 JSON 报告里面按桶列出 TTFT P50/P95、ITL 均值、TPS、RPS 和错误率。每次模型切换或配置变更都跑一遍和历史报告做 diff超过阈值波动就告警。具体落地时报告里加一个config_hash字段把 Base URL、Model ID、max_tokens、temperature、并发档位拼起来做哈希。这样你回看历史报告时能一眼看出两次跑分是不是同一套配置避免拿不同口径的数字互相比较。数据集也要版本化新增样本就升一个版本号老报告保留保证可追溯。如果你要测的是编码或 Agent 这类长会话场景建议单独建一个桶输入是短指令、输出是长代码或长推理链OSL 设到 1000 以上专门观察 ITL 在长输出下是否稳定。这类场景对首 Token 时间不敏感但对持续生成速度和上下文增长后的性能衰减很敏感。跑完对比后把结论沉淀成选型文档哪个模型在哪个桶里达标、成本大概什么量级、什么并发下开始劣化。下次有人问“为什么选这个模型”你直接把报告甩过去就行。评测这件事工具和指标都是次要的关键是口径统一、配置可复现、结论能归因。把这三件事做到你就不用在“跑分好看”和“上线翻车”之间反复横跳了。

如何对LLM大型语言模型进行评估与基准测试：从性能指标到推理能力的落地实践

相关推荐

DeepSeek-R1模型选型与提示语工程实践指南

AI赋能知识产权运营：四类智能体破解科技成果转化供需匹配难题

UG/NX二次开发实战弹药库：从环境搭建到UF函数调试

更多资讯

MCP协议：大模型标准化连接与实战应用解析

2025电商AI趋势：重构人货场关系与跨境新机遇

H.265视频编码技术解析与动漫处理实践

医疗OCR技术选型与优化实战指南

PyTorch运动鞋细粒度图像分类实战：从数据到ONNX部署

商务大数据建模实战：从数据清洗到决策优化

今日更新

基于YOLOv11的石油泄漏智能检测系统开发实践

AI行业变局：合规、Mod化与上下文管理的实战启示

计算机视觉与AI原生应用融合的技术实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？