如果你最近在选型、做模型量化对比或准备把开源大模型部署成线上服务大概率已经遇到过下面这类问题同一个 7B 模型换一个推理框架后速度差了一倍到底谁的数据可信模型量化成 int8、int4 之后推理快了多少显存省了多少API 返回速度快不快在浏览器里流式输出到底卡不卡自己本机跑得挺快的模型一旦多人并发调用为什么 latency 直线飙升这些问题无法靠“运行一下看感觉”回答你需要一套能够量化、可复现、能横向对比的方法这就是 LLM Inference Benchmarking 要做的事。这篇文章会从工程视角讲清楚“大模型推理基准测试”到底测什么、怎么测、有哪些关键指标、有哪些工具能做到以及最容易踩的坑在哪里。核心结论先放在前面推理基准测试不是跑一个 tokens/s 数字那么简单而是一套从硬件选型、推理后端选型到量化方案选型和容量规划的系统性测量方法。如果只盯着单个数字很容易在真实业务场景里翻车。全文围绕实际可落地的方案展开。1. LLM 推理基准测试要解决的真实问题在正式介绍指标与工具之前先回答一个更基础的问题为什么需要专门给“推理”做基准测试这是因为大模型推理和传统 Web 服务的性能模型差别很大。传统接口的耗时一般围绕单次请求的 P99、吞吐量等指标评估而 LLM 推理有一个核心特点模型每一次生成都是逐 token 自回归的。前一个 token 是后一个 token 的输入这种串行依赖导致单次请求内部包含“首 token 生成”和“后续 token 生成”两个阶段两个阶段的耗时特征完全不同。同时token 数量和输入上下文长度还会动态影响显存占用和计算量你的服务很难提前预估资源。如果把这些问题映射到实际开发中推理基准测试主要是为了解决以下几类决策问题。第一类是模型选型。开源界有个残酷现实Qwen、Llama、Mistral 等不同系列的同量级模型单个 token 输出的理论计算效率差异没有想象中大但因为架构细节、激活函数、注意力实现方式不同真实推理性能会有差别。这个差别有时只能通过实际测量才能发现。第二类是部署方案选型。同样是跑一个 7B 模型你用 llama.cpp 还是 vLLM用 Ollama 还是 TensorRT-LLM在并发场景下的表现完全是两回事。没有基准测试你就只能看官方 GitHub 的 README 宣传很难判断哪种后端适合你的业务形态。第三类是量化与显存规划。int8 和 int4 到底掉多少点、快多少不是一个拍脑袋能解决的权衡。更关键的是你需要根据并发数、输入输出长度估算显存消耗避免服务进程在运行到一半时出现 OOM。第四类是容量规划。线上接入的用户数量增加单实例能否扛住要不要加副本如果只看平均 latency你很难判断系统的真实瓶颈。把这些真实问题串起来可以发现LLM 推理基准测试的本质不是“跑分”本身而是用可复现的指标和标准测试方法帮你把“感觉很快”或“感觉不稳定”变成可记录的工程数据基于数据做决策。2. 推理性能评测与模型能力评测先分清这两个概念聊 LLM 评测很多人会混淆两类方向。一类叫模型能力评测Evaluation关心的是“模型聪明不聪明”常见的粒度是 MMLU、GSM8K、HumanEval、C-Eval 等数据集用来衡量知识水平、推理能力、代码能力或指令遵循能力是判断模型质量的核心方式。另一类叫推理性能基准测试Inference Benchmarking关心的是“模型部署后跑多快、多稳、占多少资源”衡量的不是答案正确性而是服务性能。区别可以总结为这样一张表对比维度模型能力评测推理性能基准测试核心问题模型回答得对不对模型跑得快不快、稳不稳常用数据/工具MMLU、GSM8K、lm-evaluation-harnessllama-bench、vLLM benchmark、自定义压测脚本主要指标accuracy、passkTTFT、tokens/s、显存占用、并发吞吐应用阶段模型选型与微调质量评估部署架构、量化方案、容量规划关注对象模型权重本身硬件、推理框架、量化、服务化配置不少团队吃亏就吃亏在把两者混在一起。做技术方案评审时模型能力评测好但服务性能跟不上会造成上线事故反过来推理吞吐高但模型质量差产品体验也会受到很大影响。在部署侧做性能分析和优化时要用的是你测出来的真实推理延迟与吞吐数据而不是模型在某个榜单上的排名。3. LLM 推理基准测试的核心指标拆解评估一个 LLM 推理系统通常是围绕几个关键指标展开的。每个指标的含义和实际影响都需要理解透彻。3.1 TTFT首 Token 延迟Time to First TokenTTFT 指客户端发送完请求到接收第一个生成 token 所花的时间。它决定了一个 LLM 应用“看起来”响应快不快尤其是在聊天场景中用户发出问题后到看到第一个字出现所经历的时间直接决定了使用者的耐心。TTFT 包含网络传输、请求排队、prefill预填充阶段计算以及调度和显存分配等开销。prefill 阶段会把用户输入的 prompt 一次性或分批处理掉这段计算量对长 prompt 影响很大。因此测试时不要只用短 prompt还要覆盖真实业务中的最长输入场景。对交互式应用来说TTFT 通常需要控制在 1 到 2 秒之内否则用户会有明显的“卡住”感但对离线批处理任务TTFT 优先级可以降低。3.2 TPOT每输出 Token 时间Time Per Output TokenTPOT 指生成第一个 token 之后平均每生成一个 token 需要的时间。如果 TTFT 决定“首响体验”TPOT 就决定“整体等待感”。举例来说假设生成 200 个 token 的回复如果 TPOT 是 100ms总生成时间约为 20 秒如果 TPOT 降到 50ms总生成时间约为 10 秒。对于需要阅读完整回复的场景这个指标的影响非常直接。业界也常用它的倒数来近似表达每个用户感受到的生成速度。3.3 tokens/s生成速度tokens/s 通常指每秒生成的 token 数它的数学关系经常和 TPOT 互为倒数关系但要注意不同工具计算口径可能不同。有的工具只算“生成阶段”的每秒 token 数有的把 prefill 和 decode 一起做了加权计算还有的在并发测试中把总生成 token 数除以总时间得到吞吐。单并发场景下一个模型的生成速度主要和硬件算力、模型参数量、量化方式、KV Cache 命中等因素相关。别把它和并发场景下的系统吞吐混为一谈。3.4 Throughput吞吐量吞吐量是指系统在单位时间内能够处理的 token 数或请求数常见单位包括 tokens/s 和 requests/s。连续批处理continuous batching技术让并发场景的吞吐远高于单请求的生成速度乘以请求数因为多个请求可以共享 GPU 计算批次。线上服务关注点往往是给定延迟上限在限定并发下系统能扛住多大吞吐。这个指标需要和延迟指标一起看常见的压测曲线是随着并发升高QPS 先升后降而延迟单调上升系统的“甜点区”就在这条曲线的中间位置。3.5 显存占用与显存峰值LLM 推理是一个显存密集型任务。模型权重、KV Cache、激活值、CUDA context 和推理框架本身都会占用显存。不同量化方式对权重显存的影响比较直观KV Cache 则和并发数、上下文长度和层数、注意力头数相关。测试显存时不要只看空闲时的占用要看跑实际负载时的峰值“空闲显存”和“最高负载显存”之间往往差出好几 GB。这部分数据直接决定你要买多少 GB 的显卡能支持多大并发。3.6 并发与扩展性指标并发场景下还需要关注 P50/P95/P99 延迟、请求排队时间、error rate 等指标。P99 是最难优化的往往体现了调度抖动和显存竞争的问题。扩展性指标则可以衡量增加 GPU 后系统吞吐的变化情况用于规划集群规模。之所以要拆这么细核心原因是不同业务对指标优先级的要求不一样。在线聊天更在意 TTFT 和 TPOT离线批量推理更在意 cost per token 和吞吐多租户服务更在意隔离资源和并发稳定性。没有一套指标可以通吃所有场景。4. 基准测试工具盘点从轻量到服务化覆盖现在主流开源推理方案之间差异并不小选择合适的 Benchmark 工具也很难一步到位。先按工具类别梳理一下。4.1 llama.cpp / llama-bench轻量、单机、快速验证llama.cpp 是当前社区兼容性极广的推理方案内置了 llama-bench。它最大的优势是开箱即用、不依赖 Python 服务环境适合快速验证不同 GGUF 量化等级在本机上的生成性能也适合嵌入式或普通开发机场景。如果要测试的是一个只跑单用户的本地工具、或者对比不同 GGUF 量化文件对本机的速度差异llama-bench 往往是最直接的选择。4.2 vLLM 系列 Benchmark服务化与吞吐压测vLLM 是目前开源社区最常用的高吞吐推理服务之一。它的仓库里提供了 benchmark_throughput.py 和 benchmark_serving.py 这类脚本。前者适合测试离线批量处理的吞吐后者适合模拟真实在线服务请求输出 TTFT、TPOT 等端到端指标。vLLM 自带脚本一般需要下载源码或安装 vllm 包比较适合已选型 vLLM 的场景。4.3 Ollama / 其他部署工具偏向用户实测Ollama 这类工具的定位偏向本地一键部署本身没有特别完整的性能压测工具但你可以通过它暴露出的 OpenAI 兼容 API 做一些自定义压测比如用 Python 循环发送请求统计 TTFT 和总耗时。此类测试更多是端到端体感验证生产级压测建议还是回到推理框架自带工具或者用标准化负载工具做。4.4 通用压测工具与自定义脚本除了推理框架自带工具还可以用 Locust、wrk、JMeter 或自写 Python 并发脚本对 OpenAI 兼容 API 做压测。大模型推理请求是长连接、流式返回通用压测工具未必能很好地模拟流式响应所以更多时候是使用 Python 配合httpx或openaiSDK 来写自定义压测脚本同时记录 token 数、TTFT、总延迟等维度的数据。选择工具时不必全装可以先按自己的使用阶段判断如果只是选型阶段在电脑上验证模型先跑 llama-bench如果已经确定线上用 vLLM直接用 vLLM benchmark 系列如果只是要接 OpenAI 兼容接口做出业务验证则用自写脚本更贴近自己的场景。5. 环境准备与基准测试前置条件无论选择哪个工具Benchmark 都应在控制变量的前提下进行。如果环境不统一测出来的数据参考价值会大打折扣。5.1 硬件与驱动基准测试对硬件要求比较直接。GPU 型号、显存大小、是否支持 bf16、驱动和 CUDA 版本都会影响结果同一块卡在不同的 CUDA 版本下推理速度也可能不同。因此在记录结果时至少要把 GPU 型号、驱动版本、CUDA 版本、推理框架版本、模型权重来源和量化等级完整记录下来。操作系统建议使用 Linux大部分推理框架对 Linux 的支持最完善macOS 上做测试则主要面向 Apple Silicon 的 Metal 加速数值和 NVIDIA GPU 不具备可比性。5.2 Python 环境与依赖vLLM 等框架对 Python 版本和 PyTorch 版本有严谨的依赖约束。推荐使用虚拟环境避免把服务器基础环境弄乱。# 创建独立虚拟环境 python3 -m venv llm-bench-env source llm-bench-env/bin/activate # 根据项目文档安装 vllm具体版本以官方要求为准 # 如果只是测试 OpenAI SDK则安装轻量依赖 pip install openai需要注意生产服务器上如果已经有 CUDA、PyTorch 等基础组件不要在未确认兼容性的情况下随意覆盖用venv或conda隔离是成本最低的保护手段。5.3 模型权重与量化文件进行 Benchmark 之前首先确认模型权重的来源。GGUF 文件可以从 Hugging Face 的模型仓库下载来源要尽量选择可信仓库并核对 SHA256 等哈希信息。仓库中的config.json与 tokenizer 文件如果缺失推理可能不会报错但行为会对不上。如果你打算测试不同量化方案建议准备同一模型的多个量化文件比如原始 bf16 版本、int8 版本、int4 版本这是量化选型测试的输入源头。需要提醒的是模型下载与网络环境有关部分镜像站点访问不稳定时需要做好超时与重试机制但这部分属于网络运维范畴这里不展开。5.4 输入数据选择Benchmark 的性能会受到 prompt 长度、生成 token 数量的直接影响。输入的选择需要考虑三类短 prompt、短输出模拟轻量聊天。长 prompt、中等输出模拟文档分析、RAG 场景。批量多样化的 prompt模拟真实流量分布。更正式的测试还应统计线上请求的 prompt 长度分布而不是只测一个点。测试时建议记录“输入 token 数 - 输出 token 数”组合否则结果没有可对比性。6. 使用 llama-bench 做快速推理基准测试6.1 获取 llama.cpp 与 llama-benchllama.cpp 的新版本通常会在编译后提供 llama-bench 可执行文件。如果你使用官方预编译包在对应 release 中能找到如果想自己编译在 llama.cpp 源码目录下执行 build 即可。下面是 Linux 下常见的编译方式git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build cmake --build build --config Release -j编译完成后llama-bench会出现在build/bin下。如果找不到可以执行find build -name llama-bench确认路径。6.2 基本测试命令llama-bench 最基础的使用方式是./llama-bench -m /path/to/your-model.gguf -p 128 -n 64 -t 8参数含义如下-m指定 GGUF 模型路径。-p本次测试的 prompt token 数量有些版本也支持自然语言字符串。-n本次测试生成的 token 数量。-t线程数在 CPU 推理场景影响较大GPU 场景也可以留默认。-r重复测试次数建议设为 3 次以上取平均。执行完输出会包含 prefill 耗时、decode 耗时、ttft 等相关数据。由于不同版本输出字段会有差异建议直接查看帮助文档./llama-bench --help。6.3 对比不同量化文件快速对比同一模型的不同量化文件的相对速度./llama-bench -m /models/MyModel-Q8_0.gguf -m /models/MyModel-Q4_K_M.gguf -p 256 -n 64llama-bench 支持在一个命令中传入多个模型文件结果会以表格形式输出可直接看到在不同量化等级下的 tok/s 差异。这里真正的实践重点是先保证输出 token 数和 prompt 长度一致再谈不同量化之间的比较。6.4 结果解读示例假设执行后看到类似下面的输出| model | size | giB | t/s | | ------------------------------ | --- | --- | --- | | MyModel-Q8_0.gguf | 7.2G | 6.71 | 42.35 | | MyModel-Q4_K_M.gguf | 4.1G | 3.85 | 58.92 |这个表中体现的是单解码线程下的生成速度。你无法仅仅从这里判断“用户是否流畅”因为真实交互还要把 TTFT 考虑进去还要看你是否能支撑并发。如果你看到 Q4 量化比 Q8 量化快很多可能是合理的因为更低的精度意味着更少的显存带宽需求但你需要结合模型能力评测的结果确认量化带来的质量损失是否能接受。7. 使用 vLLM 做并发吞吐性能测试vLLM 是生产环境常用的推理服务框架它的自带 Benchmark 脚本是很多团队做容量规划的起点。实际操作时先确认已正确安装 vllm 包通过命令python -c import vllm; print(vllm.__version__)可以验证版本。7.1 离线吞吐测试vLLM 仓库中的benchmarks/benchmark_throughput.py适用于离线吞吐测量。这类脚本通常支持--model、--tokenizer、--input-len、--output-len、--num-prompts等参数配合--trust-remote-code可以运行部分需要远程代码的模型。一个常见的命令示例是python benchmark_throughput.py \ --model Qwen/Qwen2.5-7B-Instruct \ --tokenizer Qwen/Qwen2.5-7B-Instruct \ --input-len 512 \ --output-len 128 \ --num-prompts 100 \ --max-model-len 4096这里注意参数可能随 vLLM 版本变化一定要先通过python benchmark_throughput.py --help查看当前版本支持哪些参数。离线吞吐测试只输出一个整体的吞吐值不对服务本身做端到端验证。7.2 在线服务压测如果已经启动了 vLLM 服务可以使用benchmarks/benchmark_serving.py模拟并发请求。先启动服务python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.90 \ --max-model-len 8192然后运行压测脚本python benchmark_serving.py \ --backend vllm \ --model Qwen/Qwen2.5-7B-Instruct \ --tokenizer Qwen/Qwen2.5-7B-Instruct \ --num-prompts 50 \ --request-rate 10 \ --input-len 256 \ --output-len 128脚本会输出类似 End-to-End Latency、TTFT、TPOT、Throughput 的指标。--request-rate可以控制请求到达速率是模拟固定 QPS 的关键参数如果设置成一个很大的值相当于一次性打满请求测试服务最大吞吐。7.3 修改并发数的核心方式在 benchmark_serving.py 中并发数通常不是直接设置的而是通过控制每秒请求数和总请求数间接得到的。想要提高并发压力可以增大--request-rate或选用更大的--num-prompts。这里如果不理解透压测结果很容易被误读。单看“tokens/s 很高”不一定代表用户体验好因为在压测中总吞吐高可能是牺牲了延迟换来的。这种在线服务压测结果更适合与业务指标挂钩如果业务要求 TTFT 小于 2 秒、TPOT 小于 100ms那么寻找能够满足这两个约束的最大吞吐就是容量规划的目标。8. 用自定义脚本测试 OpenAI 兼容接口的 TTFT 与生成速度很多线上应用不是直接操作推理框架而是通过兼容 OpenAI 协议的服务调用。这时用 Python 写一个简单脚本统计 TTFT 和整体速度是最贴近真实业务的方式。下面的示例代码不依赖某个特定推理后端只要服务能通过 OpenAI 兼容接口访问即可运行。代码的关键点是发送流式请求记录“首 token 到达时间”和“全部 token 到达时间”然后根据 token 数计算速度。# 文件路径bench_client.py import time import os from openai import OpenAI client OpenAI( api_keyEMPTY, base_urlos.environ.get(LLM_BASE_URL, http://localhost:8000/v1), ) model os.environ.get(LLM_MODEL, my-model) prompt 请写一段关于城市交通管理的分析字数控制在300字左右。 messages [ {role: system, content: 你是一个数据分析助手。}, {role: user, content: prompt}, ] start time.perf_counter() response client.chat.completions.create( modelmodel, messagesmessages, streamTrue, temperature0.7, max_tokens512, ) first_token_time None collected_text [] for chunk in response: if first_token_time is None and chunk.choices: first_token_time time.perf_counter() if chunk.choices and chunk.choices[0].delta.content: collected_text.append(chunk.choices[0].delta.content) end time.perf_counter() full_text .join(collected_text) token_count_estimate len(full_text) ttft_ms (first_token_time - start) * 1000 if first_token_time else None total_ms (end - start) * 1000 tokens_per_sec token_count_estimate / (total_ms / 1000) if total_ms 0 else 0 print(f首 Token 延迟(TTFT): {ttft_ms:.2f} ms) print(f总耗时: {total_ms:.2f} ms) print(f估算 token 数: {token_count_estimate}) print(f生成速度(估算): {tokens_per_sec:.2f} tokens/s)这里的 token 数是通过字符数估算的并不精确只是一个相对参考。如果想精确获得 token 数可以在测试前用本地分词器对full_text做 tokenize或者让服务端在非流式返回中给出 usage 信息。实际对比时要保证 prompt、温度和生成长度一致。测试时建议多次运行并记录均值和 P95单次结果容易受到随机调度波动的影响。9. Benchmark 结果解读与常见误区结果解读是整个流程中最容易出现偏差的环节这里总结几个高频误区。9.1 误区一tokens/s 高就一定快很多文章在宣传一张显卡跑某个模型时习惯性报一个“tokens/s”。但是否流畅还要看 TTFT 和并发。高吞吐不等于低延迟特别是服务端配置了连续批处理的情况下单个用户请求可能和其他请求拼在同一个 batch 里计算牺牲的是单用户的延迟。衡量时不能只报一个数要把“并发数、输入 token 数、输出 token 数、TTFT、TPOT、吞吐”这组数据一起记录。9.2 误区二不同工具的测试结果直接对比llama-bench 的 tokens/s 和 vLLM benchmark 的 tokens/s 并不是同一个概念。前者偏向单请求本地推理后者可能包含 prefetch、调度、网络传输等开销。如果拿 llama.cpp 的 60 tokens/s 去对比 vLLM 服务压测得到的 40 tokens/s并得出“llama.cpp 更快”这种结论很可能是不成立的因为两者的批处理策略和负载模型不同。跨工具比较时最好统一为“OpenAI 兼容 API 脚本测量 TTFT/TPOT”这类端到端口径同时核对服务端负载参数。9.3 误区三只看短 prompt 的结果短 prompt 的 prefill 开销很低TTFT 会很好看。但真实 RAG 场景中prompt 可能被塞进几千甚至上万 token 的上下文prefill 耗时可能从几十毫秒涨到几秒。因此 Benchmark 必须覆盖长 prompt 场景并使用与业务分布相近的输入数据。9.4 误区四忽略“量化后模型质量”而只看速度int4 量化即使推理速度非常亮眼也不能只根据跑分决定上线。你需要用模型能力评测集验证量化后的质量并且做业务样例回归。推理基准测试解决的是部署性能问题模型能力评测解决的是质量问题两者是合作互补的不要把量化优化变成单纯为了拉高 tokens/s 而牺牲用户可感知的回复质量。9.5 误区五没有固定基线直接开测不同 CUDA 版本、PyTorch 版本、推理框架版本、驱动版本都可能对 Benchmark 结果造成重大影响。评测前先固定本轮基线的软件版本和硬件环境可以自动避免很多“为什么同样跑在 A100 上结果差这么多”的疑问。最好把每次环境信息记录到一个benchmark_env.txt文件中方便追溯。10. 常见问题与排查思路下面整理了一些 Benchmark 实践中可能遇到的问题。问题现象可能原因排查方式解决方案llama-bench 运行报 “failed to load model”GGUF 文件路径错误或模型文件损坏检查路径比对模型文件哈希重新下载或换用官方仓库模型显存不足导致启动失败--max-model-len设置过大或并发数过高查看 GPU 显存记录缩小并发降低 context 长度、换更小量化、减并发在线服务压测请求全部超时推理后端排队过长或 API 服务未就绪检查服务日志和 health 接口降低 request-rate先小并发验证两次 Benchmark 结果不稳定后台有其他进程占用 GPU/CPU用nvidia-smi、htop检查占用清理进程重复多轮取平均值TTFT 远高于预期prompt 过长且 prefill 未优化检查是否启用了相关 prefill 优化或 chunked prefill根据框架特性调整配置Python SDK 调用时报连接错误base_url 与 API 端口配置错误检查服务地址和端口使用curl先验证/v1/models能否访问遇到性能异常时可以先从环境变量、服务日志和 GPU 监控三个方向入手尽量避免直接“盲调”参数。在大模型推理场景中显存不足和请求排队是最常见的性能瓶颈来源优先排查总是没错的。11. 最佳实践把 Benchmark 做成可持续的工程指标Benchmark 不只为了完成一次测试更有价值的是把它沉淀成持续进行的工程指标。下面是我从工程实践中提炼出的几个建议。11.1 每次测试前记录环境基线写一个标准记录模板建议包含以下字段测试日期 GPU 型号 显存大小 驱动版本 CUDA 版本 推理框架及版本 Python 版本 模型名称及来源 量化等级 prompt token 长度 输出 token 长度 并发数可以把这些信息写入benchmark_env.txt跟结果文件放在同一目录。这样哪怕一个月之后再回来看数据也能搞清楚当时的测试条件。11.2 统一测试请求负载线上的 prompt 长度往往不是固定的因此建议构造一套“短、中、长”混合负载。在测试组内部确定好标准输入和输出长度后每次对比都使用同一套负载。这样不同模型、不同量化、不同框架之间的对比才有意义。可参考这个思路短任务256 token 输入128 token 输出。中任务1024 token 输入512 token 输出。长任务4096 token 输入1024 token 输出。实际业务侧重不同可以调整比例。建议按线上采样分布来设置权重。11.3 结合模型能力评测一起做决策推理性能的 Benchmark 和模型能力评测结论必须放在一起看。量化提升性能但损失质量是否值得新框架性能更好但功能不完整是否值得这些决策不能单靠性能测试得出来。可以把两个结果放进同一张对比表中比如同时记录“Q8 量化质量分 - 速度分”与“Q4 量化质量分 - 速度分”决策时一目了然。11.4 生产环境压测要设置安全阈值压测请求会对生产环境产生真实流量影响。强烈建议在非生产环境或专用于压测的实例上进行。如果需要压测试生产预发环境必须得到授权、拉低流量峰值并准备回滚预案。测试脚本要注意并发上限避免因无限制的并发请求打挂推理服务尤其是共享 GPU 环境。11.5 使用日志与监控体系辅助定位Benchmark 脚本给出的字段只能代表系统整体表现真正定位瓶颈需要监控细粒度数据。建议关注GPU 利用率与显存使用率曲线。KV Cache 剩余空间。请求排队长度。单次请求的 prefill 耗时与 decode 耗时。服务端 error log 和 timeout log。一个典型的优化顺序是先确认显存没有打满再确认 batch 策略是否生效最后检查是否因长 prompt 导致 prefill 成为瓶颈。这样做可以相对迅速地定位问题。11.6 把基准测试纳入 CICD 与发布流程对于长期维护推理服务的团队建议把 Benchmark 脚本纳入 CICD 流程中作为版本发布或配置变更的回归测试。当默认量化等级、推理框架版本或 GPU 驱动发生变更时自动执行一套预定义的性能跑分并与基线对比。现在很多开源工具都支持输出 JSON 格式的结果方便程序自动读取和比对。这种做法能尽早发现“某个小版本升级导致性能下降 10%”之类的问题而不是等到线上用户反馈时才发现。12. 总结与后续学习方向这篇文章重点讲了 LLM Inference Benchmarking 的实际价值与落地方案核心内容可以归纳为以下几个方面搞清楚评测对象推理性能基准测试关心的是 TTFT、TPOT、tokens/s、吞吐、显存等部署指标和模型能力评测不是一回事但两者要结合起来做选型决策。掌握核心指标体系不要只看单一 tokens/s要理解 TTFT 决定首响体验、TPOT 决定完整回复等待感、吞吐决定系统容量、显存决定部署边界。学会使用工具轻量场景用 llama-bench服务化场景用 vLLM 的 benchmark 脚本贴近业务场景时可以用 OpenAI 兼容 API 配合自定义脚本测试。形成工程方法固定环境基线、统一输入负载、多次测试取均值、记录日志和监控数据把 Benchmark 变成可持续的回归测试手段。如果你接下来要深入探索可以从这些方向继续展开学习开源推理框架的连续批处理和 PagedAttention 实现原理、KV Cache 对并发和显存的实际影响、不同量化算法的计算原理与质量损失评估、生产环境中基于监控指标的动态扩缩容策略等。这些都是与大模型推理性能直接相关的关键方向。对开发者来说Benchmark 的真正价值不在于跑出一个好看的分数而在于为选型、容量规划和性能优化提供可信数据。实际项目中建议把推理性能测试固化为团队例行事项模型换版跑一次、量化变更跑一次、推理框架升级跑一次、GPU 扩容后跑一次用数据降低每一次变更的风险。这套方法初期会花一些时间但从长期看能帮你从“拍脑袋部署”走向真正的工程化交付。