GPU推理：在延迟约束内核对吞吐
GPU推理的最高吞吐不一定就是可以出售的服务容量。如果一项服务要求用户很快看到首字，三秒后才开始回复的系统即使每秒生成更多词元，也可能不能满足合同。研究任务是先定义延迟和质量要求，再核对在这些要求内实际完成了多少有效输出，最后区分单副本实测与扩容假设。
交付物应是可复算的基准工作表，而不是只按每秒词元数给芯片排序。模型版本、精度、硬件、服务软件、输入输出长度、请求到达方式和延迟分布必须同时保留。某次测试支持的是该配置和测试窗口，不会自动成为所有客户提示词的容量，更不会直接变成收入。
先定位一手指标定义
NVIDIA的LLM推理基准基础文章在How LLM inference works说明排队、预填充和生成阶段；LLM inference metrics及图一分别呈现首词元时间、词元间延迟、用户吞吐与系统吞吐。应阅读正文定义，不能只用页面自动摘要作为测试规范。
首词元时间描述开始输出前的等待，词元间延迟描述生成过程的间隔。系统吞吐汇总多个请求同时完成的工作，单用户速率则对应那个请求的体验，两者分母不同。并发提高后，总吞吐可能上升，而每位用户等待反而变长。
本例虚构服务要求为首词元时间不超过一秒、完整响应不超过十二秒；每个请求输出目标均为二百词元，输入长度分布及质量测试保持相同。这些是演示门槛，不是NVIDIA建议。必须由同一个请求同时通过两项时间要求，不能把两张分别漂亮的统计图拼成“全部合格”。
三档并发如何筛选
假设单张GPU分别以一、八、三十二并发测试，系统输出速率为每秒八十、四百八十、九百词元，首词元时间的第九十五百分位分别为零点二、零点八、三秒。模型、输出目标、输入样本和计时规则均相同。
| 并发数 | 系统每秒输出词元 | 首词元时间p95，秒 | 通过本例运行级筛选 |
|---|---|---|---|
| 一 | 80 | 0.2 | 是 |
| 八 | 480 | 0.8 | 是 |
| 三十二 | 900 | 3.0 | 否 |
三十二并发的裸吞吐最高，却没有通过这项运行级延迟筛选。八并发是通过初筛的两档中较快的一档，但这仍然不代表所有请求合格。百分位只是分布摘要；首词元和完成时间分别通过百分位门槛，也不能证明同一批请求同时通过两项要求。
因此，下一份应取得的证据是逐请求记录，包括提交、首字、完成、错误及输出词元数。只有平均延迟的图无法重算第九十五百分位；即使提供百分位图，若没有对应请求记录，也无法计算同时满足服务条件的数量。
从请求账本重算有效输出
对八并发配置另做一次固定窗口观测，时长五百秒。明确纳入一千个请求，并追踪到全部请求的最终状态；每个完成请求输出二百词元。其中九百三十个同时通过两项时间要求及同一质量检查，七十个至少一项失败。假设没有未分配的预热请求，也没有跨窗口词元混入。
有效输出为九百三十乘二百，等于十八万六千词元；除以五百秒，得到每秒三百七十二有效词元。若一千个请求都生成完整目标，全部生成量是二十万，毛输出速率为每秒四百。这次窗口观测与前表每秒四百八十的示意基准是两次不同测试，必须分别保存分母，不能悄悄拼成一组结果。
因为本例输出长度相同，合格请求占比百分之九十三也等于合格输出占比。若每个请求输出长短不同，这个等式就不成立，应逐个汇总合格请求的实际输出。失败原因可分别标注延迟和质量，但总失败数取并集，同一请求两项失败不能计两次。
还要避免把系统吞吐再乘并发数。系统总量已经包含并发工作。预填充处理的输入词元与解码生成的输出词元也不是同一种产出；若供应商总速率把两者相加，应先取得分列数据，再与本工作表的输出指标比较。
扩容必须另列假设
假设计划部署八个独立副本，并以百分之七十作为规划折减。以实测每秒三百七十二为基础，情景容量为三百七十二乘八乘百分之七十，等于每秒二千零八十三点二有效输出词元。这是扩容情景，并非八卡实测。折减系数不能证明请求路由、共享存储或通信资源确实互不干扰。
情景还假设各副本接收相似输入、质量和服务条件不变。平均利用率不能修复高峰排队造成的超时。真正验证扩容，需要加入实际路由链路、相关突发到达及共享依赖重新测量。在取得证据前，工作表将单副本观测和多副本假设放在不同单元格，不能用同一种“容量”标签遮住证据差别。
机制不同的边界案例
把短提示词改成长输入，但保持每次输出二百词元，预填充工作会改变，首字等待也可能变化，即使硬件解码速率看起来稳定，旧测试的延迟结论仍不能沿用。输入长度不仅是备注，而是决定该基准服务什么工作负载的重要输入。
另一个边界是质量。较低精度配置可能运行更快，但在相同任务与相同质量门槛下完成核验之前，不能把全部输出都当成同等有效容量。模型家族名称相同也不等于响应等价，应记录准确检查点、精度、相关服务设置和质量验收方法，不凭性能提升编造准确率结论。
重试还会改变分母。一次客户任务可能因失败发起多次尝试，每次都消耗GPU工作，却只能产生一次成功任务。分别列尝试数、唯一任务数、成功任务数和生成词元数。若取消或超时请求被排除在延迟样本外，漂亮的分布可能只描述幸存者，而非全部进入系统的服务体验。
可执行核验表
| 输入 | 应取得证据 | 核对动作 |
|---|---|---|
| 工作负载 | 输入、输出长度和分词器 | 分布一致而非只均值一致 |
| 配置 | 模型和服务配置清单 | 检查点、精度、卡数一致 |
| 计时 | 逐请求时间戳及窗口规则 | 排队、预热、终态可追踪 |
| 质量 | 固定测试及验收记录 | 任务和门槛不随配置改变 |
| 输出 | 词元数与唯一任务标识 | 不混输入输出、不重算重试 |
| 扩容 | 多副本测试或明确假设 | 实测与规划分别标识 |
销售材料与日志冲突时，先查输入样本、百分位口径、失败请求是否入样和测试时长，而不是平均两组不兼容速率。缺少时间戳或失败记录，就只报告现有证据能支持的窄指标，把联合服务合格率留作未知。
复算还应保留从原始日志到汇总表的请求数量桥。窗口内进入多少、成功多少、失败多少、仍未完成多少，每一项都应有状态定义。完成时间超过观测窗口的请求不能因记录截止而消失；应延长追踪或明确使用进入队列与输出窗口不同的统计设计，并解释为何两者可比较。这样才能识别看似提高的吞吐是否只是把慢请求移到报表外。
当模型、输入组合、质量门槛、调度器、副本拓扑或服务目标变化时，重开一行测试版本，保留此前配置以归因变化。最终结论应说清实测容量对应什么工作负载和延迟预算，以及哪一段仍依赖未经验证的扩容假设。
检查延迟改善背后的样本变化
较快结果还需核对进入、完成、失败、取消和仍运行请求。若最慢请求被删除，完成百分位会变好，实际服务的唯一客户任务却可能减少。每个进入请求保留终态，跨窗口请求说明后续追踪方法，不能因日志截止而从分母消失。
输出长度变化时，同时记录目标上限和实际生成量。提前结束可能缩短完成时间，也减少输出；这或许是有用产品变化，却不能全部归为硬件提速。用相同任务完成与质量要求比较，或明确将较短输出视为不同服务配置。
能耗与费用同样需要一致边界。芯片额定功率除整个服务的实测有效吞吐，会混合部件估计与系统观察。若要说单位能耗，应取得定义明确的服务系统电量；只有实例租金时，可以说该次测试下每单位合格输出的租金，不能称全部经营成本或毛利。
最后保留运行标识、日志版本和重算方法，让另一位读者能从请求账本复现汇总。配置名称相同但软件版本或负载生成方式改变时，另开测试行。商业敏感性引用哪一行，应能直接回到那次运行，不能从不同测试各挑一个最好数字拼成不存在的系统。
常见问题
首词元时间p95合格，代表每个请求都合格吗？
不代表，也不能代替同一请求同时通过完成时间条件的核验。
八张卡能直接按单卡八倍估值吗？
在完整服务链路实测之前，只能作为已说明条件的扩容情景。