测准NPU时延：从请求排队到设备计时

设备内核只花几毫秒，用户请求却可能等待更久。评估NPU时延，必须先说明请求以什么节奏到达，再说明计时区间覆盖哪些阶段，否则同一系统会得到互相矛盾的性能结论。

排队从到达速率与服务能力不匹配时开始，但平均能力足够也不保证每个请求立即执行。真实请求可能成簇到达，任务服务时间也可能变化；当利用率接近饱和，短暂突发就会积累队列，使较高分位的时延快速增加。一个简化的单服务台随机队列模型可以说明这种趋势，但其具体公式依赖到达和服务分布，不能直接用于多队列、多执行单元或复杂批处理系统的容量承诺。

负载生成方式决定了测试能否暴露积压。如果发出一个请求后必须等待它完成，再发下一个，设备变慢会自动降低发压速度，测试中的到达过程随系统响应改变。这种闭环方式适合测单请求往返，却可能漏掉固定外部到达率下的等待。对持续服务，应采用独立于完成速度的到达计划，记录计划发送、实际发送和完成时刻；发压端本身赶不上计划时，也要报告，避免把生成器瓶颈误认成设备稳定。

统计时应区分服务时间、排队时间和最终完成时间，保留完整请求样本或足以重建分位的直方图。只给平均值会隐藏少量严重超时，直接平均多轮分位数也不等于所有请求合并后的分位数。丢弃、超时和主动限流的请求必须进入报告，不能只统计成功者。若系统通过批处理提高吞吐，还应包含等待凑批的时间，并分别扫描到达率与批处理策略，找到满足时限的可持续工作区间。测试持续时间也要足够覆盖目标分位的样本数量，并保留原始计数。样本过少时，极端分位可能由一两个请求决定，不宜据此宣称稳定满足服务期限。

测时的另一项常见错误，是把异步提交接口返回的时间当成推理完成时间。主机可能只把命令写入队列，设备尚未开始工作，调用就已经返回。若只在调用前后读取主机时钟，得到的通常是提交成本，不能代表设备计算。完整请求测量应以单调时钟记录开始，并等待对应结果达到接口规定的可用状态再结束；若应用还需后处理，应明确其是否包含在用户可感知的时延内。

分析NPU内部执行时，可以使用后端支持的设备事件或时间戳，但必须核对事件的记录位置。事件放在队列前后，可能包含队列中的等待；放在具体内核边界，则可能排除搬运与转换。同一设备时间戳差通常可用于局部区间分析，但不能未经校准就与主机时间戳直接相减，因为二者可能来自不同频率、不同起点的时钟域。跨域关联需要运行时提供的同步机制，并考虑时钟漂移和采样误差。

测量工具本身也会影响执行。逐层强制同步会破坏原有重叠，详细跟踪可能增加主机和设备开销，因此应先测正常模式的整体验证值，再开跟踪定位阶段占比，并比较两种模式的差异。首次编译与稳定运行要按业务分别报告，而不是把最慢一次随意删除。多阶段流水中，各阶段耗时可以重叠，不能把阶段数值直接相加后当作端到端时延；应以同一请求的实际开始与结束作为最终依据。

可信的时延结论必须带着到达模型和计时边界。用独立到达过程检查积压，用明确的完成事件界定测量，再把内部阶段与请求结果对应起来，才能为容量选择提供可靠依据。