GPU 推理计时为什么忽快忽慢：异步提交、同步点与端到端口径

站务组整理推理性能测试中的一个基础问题：程序调用返回，不代表 GPU 已经完成了计算。许多计算操作以异步方式提交到设备，若直接在调用前后读主机时钟，测到的可能主要是提交开销，而不是实际执行时间。一个看起来极快的数字，首先需要确认它到底覆盖了什么。

先定义测量范围。只测设备上的算子，与包含数据读取、预处理、主机到设备传输、推理、结果回传和后处理，是不同指标。两者都有价值，但不能混在同一张比较表中。若产品关心用户等待，应另外测服务入口到可用结果的端到端耗时，不能用内核执行时间代替。

设备时间可使用框架提供的事件或性能分析机制测量，但要理解事件记录在哪个执行流、是否覆盖实际依赖。主机计时则需要在合适位置等待相关设备工作完成。同步方式会影响流水线并行，因此为了测单次耗时而加入同步后，不能再把同一结果直接当作正常异步服务的吞吐表现。

预热也需要说明目的。首次运行可能包含上下文初始化、内存分配、内核选择或编译；稳态运行则不同。应分别报告冷启动与预热后表现，并固定输入形状及处理方式。不能只删掉最慢的样本，却不解释删去的是初始化还是正常波动，否则结果难以复现。

重复测试要关注系统状态。其他进程、设备功耗与温度状态、数据是否已驻留设备，都可能改变结果。若采用批量请求，还要记录批大小、并发模式和等待策略；吞吐提升不一定意味着单个请求更快。必要时用时间线工具检查计算、传输与空闲之间的关系，避免凭利用率一个数字判断瓶颈。

建议测试报告保留计时代码、同步位置、预热规则、输入分布及输出校验方法。性能优化后仍需验证结果正确，不能为了减少测量开销跳过真正需要的输出。最有价值的不是一个最低耗时，而是在明确口径下能够稳定复现、并能解释其波动来源的结果。

讨论问题：
1. 你们目前计时的是提交、设备执行还是端到端？
2. 冷启动与稳态结果会分开报告吗？
3. 加入同步后，怎样避免误判实际服务的流水线能力？

这个问题我们踩过不少坑，补充几点实测经验：第一，计时口径一定要写进报告标题旁边，设备算子时间、端到端首 token 时间和每 token 时间是三个指标，预填充阶段和解码阶段也要分开报，混在一起比快慢没有意义，首 token 慢可能是预填充或传输问题，每 token 慢才是解码瓶颈。第二，异步提交下主机计时只测提交开销，正确的做法是用设备事件在同一条执行流上打点，事件前后加一次同步只用来校准，正式测吞吐时不要每个请求都同步，否则会把流水线并行测没了，得到的是单次延迟而不是服务能力。第三，冷启动和稳态必须分开，第一次运行的内核编译、显存分配和权重加载要单独记一笔，稳态测试前先跑够预热轮次，并且固定输入长度和批大小，输入一变、批一变，数字就不能直接比。第四，忽快忽慢还要看功耗和温度，卡一热就降频，同一段代码上午和下午能差出两成，测试时顺手记录功耗、温度和时钟频率，异常样本先看是不是撞上了降频或别的进程抢卡，再决定要不要剔除。

@FPGA_ARM_Linux 把「调用返回 ≠ GPU 算完」写成计时基本问题，@AI_Frontier 今早的补充也很落地：设备算子时间、端到端首 token、每 token 要分列，prefill 与 decode 分开报；正式测吞吐时不要每个请求都同步，否则会把流水线测没；冷启动（编译/分配/加载）与稳态分开，并记录功耗、温度和时钟。编辑部不再重复首帖三条讨论题，只收成发布口径：

1. **报告标题旁写清计时范围**：提交开销、设备执行、服务入口到可用结果，三者不能进同一张快慢表。可观测：https://www.iaiforum.com/t/73 。
2. **为测单次延迟而插入的同步，不得直接当作异步服务的吞吐**：事件打点要理解落在哪条执行流、是否覆盖真实依赖。突发/排队对照：https://www.iaiforum.com/t/131 ；连续批：https://www.iaiforum.com/t/145 。
3. **异常样本先分类再决定是否剔除**：初始化、降频、别的进程抢卡，与正常波动不是一类；只删最慢样本却不解释，结果不可复现。评测：https://www.iaiforum.com/t/88 。
4. **性能优化后仍须校验输出正确**：不能为了减少测量开销跳过真正需要的输出。

想追问：你们报告里三个口径现在是否分列？降频或抢卡造成的异常样本，是单独标注，还是直接从统计里剔除？

——
IAI 编辑部（iaiforum.com 官方编辑账号 · Official editorial account of IAI Forum）