AI 推理性能测试应该测什么，延迟、吞吐、显存和 GPU 利用率如何综合判断

AI 推理性能测试最容易犯的错误，就是拿一个数字决定整台服务器或者整套推理框架的性能。有人只看 Tokens Per Second，有人只看 GPU 利用率，也有人把显存占用越低直接等同于优化效果。对于实际部署的大模型服务来说，这些指标都重要，但它们回答的是完全不同的问题。延迟反映用户需要等多久，吞吐量反映单位时间能够处理多少工作，显存决定模型和 KV Cache 能否稳定驻留，GPU 利用率则帮助工程人员判断计算资源究竟有没有被有效使用。真正有意义的性能测试，不是把其中某一项做到最大，而是建立一套能够对应业务 SLA、模型规模、并发量和硬件成本的完整测试体系。

首先要把延迟拆开来看。AI 推理中的“延迟”并不是一个单一数字，对于大语言模型尤其如此。常见指标至少包括 TTFT，也就是 Time To First Token，表示请求提交后用户看到第一个 Token 需要等待多长时间；还包括后续 Token 的生成间隔，以及整个请求完成所需要的端到端延迟。对于流式聊天服务，TTFT直接影响用户是否感觉系统“马上有反应”，而 Decode 阶段的 Token 间隔则决定文字输出是否流畅。因此，一台服务器即使最终平均响应时间不错，如果 TTFT 很高，或者生成过程中出现明显卡顿，实际体验仍然可能很差。

延迟测试还必须观察 P50、P95 和 P99，而不能只看平均值。P50基本可以理解为典型请求的中位数表现，P95和P99则用于观察尾部延迟。当并发量提高、KV Cache快速增长、显存压力上升或者多卡通信出现拥塞时，平均延迟可能变化不大，但P99可能突然恶化。对于在线 API、客服系统、代码助手和实时交互应用，尾部延迟尤其重要，因为用户并不会因为服务器平均响应速度很快，就忽略偶尔一次几十秒的等待。

吞吐量则需要采用更加严格的测试定义。对于大模型服务，常见指标包括 Requests Per Second、Input Tokens Per Second、Output Tokens Per Second以及总 Tokens Per Second。RPS表示单位时间完成了多少请求，而 Token Throughput表示单位时间处理或生成了多少 Token。两者不能混为一谈。一台服务器可能只能同时完成少量长文本请求，但每秒处理的 Token 数量非常高；另一台服务器可能能够快速完成大量短请求，RPS很漂亮，却未必适合长上下文的大模型任务。

因此，测试吞吐量时必须记录输入 Token 长度、输出 Token 长度、并发请求数、请求到达方式以及测试持续时间。不能简单地拿“总 Token 数除以某个平均响应时间”就宣布服务器的 TPS。更可靠的方式是在明确的测试时间窗口内统计实际完成请求和实际处理、生成的 Token 数量，同时记录不同并发等级下的性能变化。测试时间也不能只有几十秒，因为模型加载、KV Cache建立、CUDA Graph、内存分配以及缓存预热都可能影响初始结果。实际压力测试通常应该设置 warm-up 阶段，然后进入稳定测量阶段。

Batch Size同样不能简单理解成越大越好。大模型推理通常需要在 Prefill 和 Decode 两个阶段之间寻找平衡。Prefill阶段主要处理输入上下文，计算密集度通常较高；Decode阶段则不断生成新的 Token，同时频繁读取模型权重和 KV Cache，往往更加受到显存带宽、缓存访问和访存效率的影响。Continuous Batching能够把多个请求动态组织到同一个推理批次中，在提高 GPU 工作效率的同时减少传统静态 Batch 带来的等待问题。但随着并发增加，KV Cache占用、调度开销、显存容量以及带宽压力也会同步增加，所以不存在一个适用于所有模型和硬件的“最佳 Batch Size”。

原文中把 Batch Size 超过512后吞吐量必然出现非线性下降的说法过于绝对。是否在512、256、128甚至更小的批量出现瓶颈，取决于模型结构、上下文长度、输出长度、量化方式、GPU型号、显存容量、推理框架和调度策略。工程测试真正应该做的是建立 Batch Size 或并发数与吞吐量、P99延迟、显存占用之间的曲线，然后寻找业务可以接受的工作区间，而不是提前规定某一个固定数字。

显存测试也不能只记录“用了多少GB”。对于大模型推理，显存通常同时被模型权重、KV Cache、中间激活、CUDA运行时以及框架自身的内存管理机制占用。尤其在长上下文和高并发环境中，KV Cache可能成为决定系统容量的关键因素。假设一个模型在低并发测试中只占用一部分显存，并不能说明它可以在实际生产环境中稳定承受大量并发。测试时应该记录空载显存、模型加载后的显存、Prefill阶段峰值、持续Decode阶段峰值以及并发增加后的显存增长趋势。

这也是为什么量化测试不能只看模型文件缩小了多少。FP16、BF16、FP8以及INT8、INT4等不同精度会改变权重存储、计算路径、显存带宽需求和硬件利用方式，但性能变化并不是固定比例。某一种量化方案可能明显降低权重占用，同时提高单位显存能够容纳的并发请求数量；另一种情况下，量化后的算子没有得到目标 GPU 的充分硬件加速，结果可能是显存省下来了，实际 Token Throughput 却没有同步提高。因此，“显存下降30%，GPU利用率下降15%”这样的固定结论不能作为普遍规律，必须通过具体模型、具体 GPU 和具体推理后端实测。

GPU利用率是另一个非常容易被误读的指标。通过 nvidia-smi 看到GPU长期保持95%甚至100%，并不意味着推理系统已经达到最佳状态。GPU可能是在高负载执行有效计算，也可能是在受到内存带宽限制的情况下持续工作；另一方面，如果 GPU 利用率只有50%，也不能马上判断服务器性能很差，因为系统可能正在等待 CPU 调度、数据传输、网络通信、KV Cache 管理或者其他请求。

专业测试因此需要把 GPU Compute Utilization 与显存带宽利用率、SM利用率、Tensor Core利用率、显存占用、PCIe传输以及功耗等指标结合起来分析。如果 GPU计算利用率很低，同时 CPU利用率很高，可能存在数据准备或调度瓶颈；如果 GPU计算单元已经非常繁忙而显存带宽也接近瓶颈，那么继续提高并发可能只能换来更高的排队延迟；如果 GPU利用率不高，但 PCIe 或多卡互联链路已经出现明显压力，则问题可能根本不在 GPU 算力本身。

多 GPU 和多节点推理又增加了一层复杂度。单机多卡部署中，需要观察 GPU之间的互联拓扑以及通信带宽。NVLink、PCIe以及不同代际的互联方式，会直接影响 Tensor Parallel、Pipeline Parallel 等并行策略的效率。多节点环境还要进一步考虑网络延迟、RDMA、InfiniBand或高速以太网、通信库以及节点之间的数据交换。随着模型并行规模扩大，计算时间和通信时间之间的比例可能发生变化。如果一部分 GPU 大量时间都在等待通信，那么增加 GPU 数量并不会线性提高吞吐量，甚至可能出现 GPU数量增加、单位请求成本反而上升的情况。

这里也不能把“超过4个节点后 GPU 利用率下降20%以上”当成普遍规律。通信瓶颈究竟从多少张卡、多少个节点开始出现，与模型规模、Tensor Parallel度、网络结构、通信模式、消息大小以及具体硬件密切相关。工程人员应该直接测量 All-Reduce 等关键通信操作的耗时，并结合 Nsight Systems、Nsight Compute 等工具观察计算和通信时间线。如果 GPU 在等待 NCCL 通信，而不是等待模型计算，那么优化方向就应该转向并行策略、拓扑、通信库和网络，而不是简单增加 GPU 数量。

另外需要区分“训练”和“推理”的性能分析方法。原文提到通过梯度聚合策略解决多节点推理中的通信问题，这一表述并不准确，因为梯度聚合属于训练阶段的典型通信问题。推理部署更应该关注 Tensor Parallel、Pipeline Parallel、Expert Parallel、KV Cache 管理以及节点间激活数据和专家路由数据的通信。如果是 MoE 模型，还需要进一步观察 Expert Parallel 和 Token Routing 带来的网络压力。

实际建立 AI 推理基准测试时，建议至少形成一套二维甚至三维测试矩阵。第一维是模型和精度，包括模型参数规模、BF16、FP16、FP8或其他量化方式；第二维是输入输出长度，例如短上下文、中等上下文和长上下文；第三维则是并发量，从单请求逐步增加到生产环境预计的峰值并发。在每个测试点记录 TTFT、TPOT、P50、P95、P99、RPS、Input Tokens Per Second、Output Tokens Per Second、显存峰值、GPU利用率、显存带宽利用率、功耗以及错误率。

对于在线实时服务，通常应该首先保证 TTFT和P99延迟处于SLA允许范围，然后在这个约束条件下提高吞吐量。对于离线批处理、批量文档分析、数据清洗或者大规模代码生成，则可以牺牲部分单请求延迟，把目标放在最大稳定 Token Throughput 和单位任务成本上。如果是混合业务，则需要观察不同负载之间是否互相争夺 KV Cache、GPU计算资源和显存，而不能用一个单独的平均值代表整个系统。

最终还应该加入“单位成本性能”这一指标。两台服务器如果一台每小时成本更高，但只能带来10%的吞吐提升，就不能仅仅因为它的 TPS 更高而判定它更优秀。更合理的比较方式包括每美元每小时能够生成多少 Token、每瓦能够生成多少 Token，以及在满足指定 P99 SLA 的情况下能够承载多少稳定并发。对于企业级部署，这些指标往往比实验室里的峰值 TPS 更接近实际采购和扩容决策。

AI 推理性能测试的核心并不是寻找一个漂亮的数字，而是找出系统的瓶颈究竟在哪里。延迟告诉我们请求等了多久，吞吐量告诉我们系统完成了多少工作，显存告诉我们模型和缓存能装下多少并发，GPU与显存带宽指标则帮助定位计算还是访存成为瓶颈，多卡通信指标进一步揭示扩展到更大规模后性能为什么开始下降。只有把这些指标放到同一套测试矩阵中，再结合具体业务的 SLA、并发模型和服务器成本，才能判断一个推理方案到底是“跑得快”，还是仅仅在某一个测试数字上看起来很快。