“每秒多少Token”为什么经常没有意义
吞吐必须附带输入长度、输出长度、并发、请求到达方式、GPU、模型、精度和框架。离线批量把请求一次性塞满GPU，可以得到很高吞吐，却不能代表在线用户的首字体验；只测单请求速度，又不能说明高峰容量。
四个核心指标
TTFT是请求进入到首个输出Token的时间，包含排队、预填充和调度；TPOT是首Token后平均每个输出Token间隔；端到端延迟覆盖完整生成；goodput则是在延迟SLO内完成的有效请求或Token。平均值会隐藏长尾，至少同时报告P50、P95和P99。
固定环境基线
压测前记录：GPU型号、数量、互联、功率上限、驱动、框架镜像摘要、模型提交、量化方式、启动参数和Tokenizer。预热模型直到权重加载、CUDA Graph和常用内核稳定。测试客户端不要与服务端争用同一CPU或网络。
nvidia-smi --query-gpu=name,memory.total,power.limit --format=csv
curl -sS http://127.0.0.1:8000/v1/models | python -m json.tool请求数据不能只有一种长度
至少建立四类：短输入短输出用于聊天；长输入短输出用于文档问答；短输入长输出用于内容生成；长输入长输出用于复杂分析。再增加一组来自脱敏生产日志的真实长度分布。每类都用目标Tokenizer计算Token，不用字符数估算。
相同提示词重复请求会放大前缀缓存收益，应同时提供共享前缀与随机前缀两组，并单独报告缓存命中。
并发和固定请求率是两种测试
闭环并发测试中，每个虚拟用户收到响应后才发下一个请求，适合观察固定并发下性能；开放式固定请求率按时间到达，更接近真实流量，能够暴露排队增长。以低负载开始，逐级提高并发或RPS，每级保持5到15分钟。
当到达率超过处理能力，队列会持续增长。此时短暂测试可能仍显示高成功率，但TTFT会不断恶化。容量边界应取延迟稳定且错误率满足SLO的最大持续负载。
每一级必须保存的数据
- 请求总数、成功、超时、取消和HTTP错误。
- 输入/输出Token总量及分布。
- TTFT、TPOT、端到端P50/P95/P99。
- GPU利用率、显存、功耗、温度与降频。
- 服务端队列、活跃序列、KV Cache和缓存命中。
- 输出质量抽样与截断比例。
不要为了提高吞吐悄悄缩短输出或降低质量。量化、推测解码和聊天模板变化后必须重新跑固定质量集。
寻找拐点而不是峰值截图
把请求率作为横轴，分别画TTFT P95、TPOT P95、goodput和错误率。低负载区延迟稳定；接近饱和时TTFT与队列开始陡增；超过容量后超时和拒绝上升。生产目标应位于拐点左侧并保留故障与流量波动余量。
长时间稳定性测试
选定配置后持续运行至少数小时，混入长请求、取消请求和流式中断。观察显存是否持续增长、缓存是否能回收、容器是否重启以及温度稳定后是否降频。再滚动重启一个实例，确认负载切换和容量冗余。
最终报告不能只写“吞吐提升30%”，而应写成：“在某GPU、某模型精度、某输入输出分布和TTFT P95上限下，稳定goodput是多少”。这才是能指导采购和扩容的容量数据。
