大模型项目从试点进入生产后，基础设施团队很快会遇到一个看似简单的问题：到底需要多少张GPU？
如果只用“每秒能生成多少Token”回答，结果通常不可靠。生产流量有高峰、有长尾，有短问答也有超长文档，有普通生成也有多轮Agent。用户在意首个Token多久出现，业务系统在意请求多久完成，财务部门则在意每个合格任务消耗多少资源。单机、固定并发、固定输入长度的Benchmark很难同时回答这些问题。
NVIDIA在2026年9月介绍AIPerf时，把重点放在生产流量模式、分布式压测、延迟分位数与GPU遥测上。它所代表的变化比工具本身更重要：推理性能测试正在从“跑出一个最大数字”转向“建立可用于容量决策的系统模型”。
一、为什么实验室吞吐量不能直接换算生产容量
1. 请求不是匀速到达的
很多测试以固定并发持续发请求，便于复现，也容易得到稳定曲线。但真实业务通常不是这样。办公助手会在上班后和会议前集中使用，客服系统会受营销活动和突发事件影响，Agent平台则可能由上游任务批量触发。
当请求以突发方式进入，排队时间会迅速增加。即使GPU计算速度没有变化，用户感受到的总延迟也会恶化。系统平均每秒能处理100个请求，并不意味着每一秒都能无等待地接住100个请求。容量规划必须考虑到达过程和峰值持续时间。
AIPerf支持常量、Poisson、Gamma等请求到达模式以及真实Trace Replay，意义就在这里。不同分布不是统计学装饰，而是用来逼近“流量如何撞上系统”。如果企业已有线上日志，优先回放脱敏后的真实轨迹，通常比凭经验设置并发更有价值。
2. 输入输出长度决定资源曲线
大模型推理至少包含预填充和解码两个主要阶段。长输入会增加预填充计算并占用更多KV Cache，长输出则持续占用解码资源。两个请求即使总Token数相同，也可能呈现不同的延迟与显存特征。
企业常见错误是用一组固定的短输入测试所有场景，然后按峰值吞吐采购。上线后，一批长文档或多轮对话进入，显存压力、批处理效率和排队时间立即改变。正确做法是从业务日志提取输入长度、输出长度、上下文轮数和工具调用次数的分布，至少按短、中、长以及极端长尾分桶测试。
3. 平均延迟掩盖了用户真正遇到的问题
平均值对长尾不敏感。多数请求很快、少数请求等待很久时，平均延迟仍可能看起来不错。但关键客户和关键流程恰恰可能落在长尾里。
推理服务至少需要观察TTFT（首Token时间）、ITL（Token间延迟）、端到端请求延迟和队列等待时间，并分别记录P50、P95、P99。流式问答对TTFT与ITL敏感；批量摘要可能更关心总完成时间；机器调用的结构化接口则可能要求严格超时。指标必须与交互方式对应。
4. 模型服务不是孤立进程
生产链路还包括网关、鉴权、内容安全、检索、重排序、工具调用、缓存、日志和存储。只压模型服务器，测到的是推理内核能力，不是业务服务能力。
容量规划应分两层进行：底层基准测试用于比较模型、精度、并行策略和硬件；端到端测试用于验证真实系统SLO。两层都要保留，因为只做端到端测试难以定位瓶颈，只做底层测试又会高估上线表现。
二、压测前先定义SLO，而不是先选并发数
没有服务目标，压测结果只是一串曲线。企业应先按任务类型定义SLO。
例如，内部知识问答可以要求P95 TTFT低于2秒、P95总延迟低于15秒、错误率低于1%；实时客服可能要求更快的首Token和稳定ITL；夜间批处理则允许更长延迟，但必须在窗口期内完成，并控制单位任务成本。
SLO还应包含质量条件。若为了提高吞吐而缩短输出、降低上下文或切换低精度模型，任务准确率可能下降。容量规划不能把“返回了响应”视为成功，最好以通过业务质量检查的请求作为有效吞吐量。
随后定义负载目标：日请求量、峰值每秒请求数、峰均比、峰值持续时间、并发会话数、输入输出分布和业务增长率。对于尚未上线的系统，可以使用试点日志、相邻业务流量和业务部门预测建立低、中、高三组情景，避免只给出一个看似精确的数字。
三、生产级推理压测的七个步骤
第一步：冻结测试对象
记录模型版本、量化方式、推理引擎、GPU型号与数量、驱动、CUDA、容器镜像、并行策略、最大上下文、批处理参数和缓存设置。缺少这些信息，结果无法复现，也无法解释后续性能变化。
模型升级或引擎参数变化后，应视为新的测试对象。尤其是连续批处理、推测解码、张量并行和前缀缓存，都会显著改变性能曲线。
第二步：构造代表性数据集
测试数据应保留真实Token长度和请求类型，但去除敏感信息。不要只随机生成字符，因为自然语言、代码、表格和结构化输出对分词长度与生成行为的影响不同。
数据集可以按业务占比混合，也可以单独测试极端场景。混合测试告诉团队日常容量，极端测试用来确定保护阈值。例如超长上下文是否应进入独立队列，批量任务是否必须限流，Agent任务是否需要单独资源池。
第三步：从低负载逐级加压
先测单请求与低并发，得到无排队条件下的基线；再逐级提高到达速率，观察吞吐何时不再线性增长、P95延迟何时陡升。这个拐点比理论峰值更重要，因为它代表系统开始进入拥塞区。
不要把压测目标设为“把GPU打到100%”。接近满载时，微小流量波动就可能造成队列堆积。生产容量应留出安全余量，并根据扩容速度决定余量大小。若新增实例需要十几分钟，预留空间就应高于秒级扩容系统。
第四步：同步采集GPU与系统遥测
AIPerf可结合DCGM和pynvml观察GPU利用率、显存、功耗等指标。企业还应同步采集CPU、内存、网络、磁盘、容器节流、队列长度和网关错误。
高延迟不一定意味着GPU不足。可能是CPU分词成为瓶颈，可能是跨节点通信受限，也可能是KV Cache占满导致请求等待。只有把请求指标与资源指标放到同一时间轴上，才能知道扩容应该加GPU、加前处理实例，还是调整调度策略。
第五步：测试稳定态与长时间运行
短时测试容易忽略内存碎片、缓存变化、日志堆积和温度降频。生产验证应包含足够长的稳定态运行，观察吞吐是否衰减、错误率是否上升、显存是否持续增长。
Agent系统尤其需要长测。一个任务可能包含多轮模型调用和工具等待，上游重试还会放大流量。若只测单轮问答，就会低估会话占用和级联重试带来的压力。
第六步：注入故障
容量规划不仅要回答正常状态需要多少资源，还要回答损失一台机器、一个节点或一个可用区后是否仍能服务。压测期间可以模拟实例退出、网络抖动、依赖超时和模型加载失败，观察流量迁移、重试风暴和恢复时间。
如果系统在满载时失去一台节点，其余节点可能同时进入拥塞。此时自动重试会进一步扩大压力。合理的设计包括退避、熔断、优先级队列、降级模型和批处理延后，而不是无限重试。
第七步：形成容量曲线，而不是单点结论
最终报告不应只写“8张GPU支持多少并发”，而应给出多组负载下的有效吞吐、P95/P99延迟、错误率、GPU利用率和单位成本。基于曲线，团队可以找到满足SLO的最高安全负载。
四、如何把压测结果转成采购数量
一个实用方法是先计算单个服务单元在SLO内的安全处理能力。服务单元可以是一张GPU、一个多卡节点或一个固定副本组，取决于模型的并行方式。
假设某四卡服务单元在目标业务混合负载下，每秒可以稳定完成12个合格请求；当超过14个请求时，P95延迟明显越线。容量规划应使用12而不是理论峰值14。若预计峰值为每秒90个请求，基础需求约为8个服务单元。
随后加入三类余量：增长余量、故障余量和部署余量。增长余量覆盖预测误差与近期业务增长；故障余量保证节点退出后仍可维持核心SLO；部署余量用于滚动升级和模型切换。如果系统要求N+1冗余，就不能把所有设备按正常峰值吃满。
对于多业务共享集群，还要考虑同时高峰与资源隔离。简单相加所有业务峰值往往过度采购，假设峰值完全错开又可能冒险。更好的做法是从历史数据计算相关性，并为高优先级业务保留最低保障容量。
五、容量规划必须带上成本与能耗
同样满足SLO的方案，可能采用更多低成本GPU，也可能采用更少高性能GPU；可能依靠量化，也可能依靠更激进的批处理。比较时应使用每千个合格任务成本或每个业务结果成本，而不是只看卡价和Token单价。
成本模型至少包括硬件折旧或云实例费用、空闲冗余、CPU与网络、存储、软件许可、运维人力和能源。功耗遥测可以帮助识别低利用率却高耗电的配置，也能评估不同批处理和频率设置的效率。
云上部署还要测试弹性成本。按需实例便于应对突发流量，但模型加载时间、镜像大小和GPU库存都会限制实际弹性。自动扩容策略应根据队列长度、到达速率和预测负载触发，不能只盯GPU利用率，因为利用率升高时用户排队可能已经发生。
六、常见的五个误区
第一，只用厂商给出的峰值吞吐做预算。厂商数字适合比较潜力，不代表企业负载。
第二，只测平均输入长度。平均值无法覆盖长上下文对显存与队列的冲击。
第三，只看GPU利用率。高利用率可能是高效，也可能是系统已经拥塞；低利用率也可能由CPU、网络或调度瓶颈造成。
第四，在压测时关闭安全、检索和日志，上线时再全部打开。这样得到的不是生产容量。
第五，把一次结果长期使用。模型、引擎、驱动、业务分布和提示模板都会变化，容量曲线需要持续回归。
结语
AIPerf把流量模式、分布式执行、延迟分位数和GPU遥测放进同一套压测思路，提醒企业：大模型推理已经不是单个算子的速度竞赛，而是完整服务系统的容量工程。
可靠的容量规划需要从业务SLO出发，用真实请求分布逐级加压，找到拥塞拐点，再结合故障冗余、增长预测和成本模型决定资源规模。最后得到的也不应是一个永远不变的GPU数字，而应是一套可重复运行的测试基线。只有这样，企业才能在模型更新和流量增长时知道何时扩容、扩什么，以及这次扩容是否真的值得。
参考资料
- NVIDIA Technical Blog：《Benchmarking LLM Inference at Scale with AIPerf》，2026-09-18。
- 本站《AI技术每日分析：模型评测与推理栈分层加速演进》，2026-09-20。