一、延迟要拆到每一环

「系统延迟 200 毫秒」这句话没有用， 因为它不告诉你该优化哪里。有用的做法是把端到端延迟拆成串行的环节，逐环量。 Demo 拆了七环： 曝光、图像传输、预处理、骨干推理、后处理、总线到执行器、液压／电机响应。 前六环里有两环是实测的（预处理和后处理），推理那一环用 60 毫秒的假设值。 为什么要实测预处理和后处理？因为这两环最容易被当成「忽略不计」。 结果后处理实测 49.4 毫秒，比预处理的三倍还多。

二、硬件那一块是物理的

三、换算成米，才有判断力

毫秒对人没有直觉。 换成「多走多少米」就有了。表二是 30 到 120 公里时速下，249.3 毫秒对应多走多远， 再加上按摩擦系数 0.8 算的刹停距离：

四、雨天会把这张表翻一倍

上面所有刹停距离都是按摩擦系数 0.8（干沥青）算的。 雨天掉到 0.4，刹停距离直接翻倍——120 公里时速要 141 米。 而延迟那 8.3 米不变。所以雨天里，延迟占总制动距离的比例从 10% 掉到 5.6%， 但绝对距离一点没少。 这就是为什么「雨雪天限速」不是保守，是物理要求。同样一套系统，干地能在 79 米内停住， 湿地要 149 米——感知距离不够，就是刹不住。

五、落地：预算倒推四步

① 定需求。 不是「延迟小于 200 毫秒」，而是「在 X 公里时速下，能在 Y 米内停住」。 这两个数决定了后面的全部。 ② 先扣硬件。 刹车／电机的响应时间是已知的，先扣掉。剩下的才是算法预算。 ③ 逐环实测。 特别是预处理和后处理——这两环经常比推理还久（Demo 里后处理 49.4 毫秒）。 ④ 留余量。 算出来占 50% 是安全线，占到 80% 就该考虑降配。 因为上车之后还有温度、负载、GC、日志这些开销，实验室里跑不出来的东西，路上全都会出来。 最后提醒：「把推理从 60 砍到 30」只降 12% 的总延迟，这一条应该记住。 优化之前先看饼图，别一头扎进最熟悉的那一环。

六、动手 Demo：实时性：总延迟 249 毫秒，120 公里时速下先盲走 8.3 米

在 640×640×3 的输入上实测预处理（归一化 + 1×1 卷积）和后处理（激活 + 降采样）的耗时， 各取五次平均； 把七环延迟加起来算占比，再把总延迟按车速换算成位移，和按摩擦系数 0.8 算出的刹停距离相加。

t0 = time.perf_counter()
for _ in range(5):
    z = (img - 0.45) / 0.225          # 归一化
    y1 = z @ Wm                       # 1×1 卷积
t_pre = (time.perf_counter() - t0) / 5.0 * 1000.0

parts = [(u"曝光", 16.7), (u"传输", 5.0), (u"预处理", t_pre),
         (u"推理", 60.0), (u"后处理", t_post), (u"总线", 2.0),
         (u"液压／电机", 100.0)]
tot = sum(v for _, v in parts)

d_react = v * tot / 1000.0              # 延迟内位移
d_brake = v * v / (2.0 * 0.8 * 9.81)    # 刹停距离

实跑输出：

--------------------------------------------------------------------
实时性：总延迟 249 毫秒，120 公里时速下先盲走 8.3 米
--------------------------------------------------------------------
  分辨率                   640 × 640 × 3
  预处理实测               16.2 毫秒（归一化 + 1×1 卷积）
  后处理实测               49.4 毫秒（激活 + 降采样）

  环节                       耗时(毫秒)   占比
  -------------------------------------------
  曝光（60 帧／秒）                16.7     7%
  图像传输（GMSL）                  5.0     2%
  预处理（实测）                   16.2     6%
  骨干推理（假设 60 毫秒）         60.0    24%
  后处理（实测）                   49.4    20%
  总线到执行器                      2.0     1%
  液压／电机响应                  100.0    40%
  合计                            249.3   100%

  车速(公里／时)   速度(米／秒)   延迟内位移   刹停距离   合计
  -----------------------------------------------------------
              30            8.3          2.1        4.4    6.5
              60           16.7          4.2       17.7   21.9
              90           25.0          6.2       39.8   46.1
             120           33.3          8.3       70.8   79.1

  **液压／电机那 100 毫秒占了 40%，是最大的一块。**
  **这一块是物理的**——刹车卡钳夹紧、刹车片贴合、压力建立，
  **再怎么优化算法也压不下去。所以实时性预算要从这一头开始倒推。**
  算法这一侧能压的是「预处理 16.2 + 推理 60 + 后处理 49.4」，共 126 毫秒。
  把推理从 60 砍到 30，**总延迟只从 249 降到 219 毫秒，降 12%。**
  **这就是硬件占大头时，优化算法能拿到的真实收益。**
  表二把毫秒换成米。**120 公里时速下总延迟 249 毫秒 = 先盲走 8.3 米。**
  再加刹停距离 70.8 米，**一共 79.1 米**——十七个车身。
  **所以「系统延迟 200 毫秒」这种话必须换成米来说，否则没人能判断严重程度。**
  **注意刹停距离是按摩擦系数 0.8 算的（干沥青）。**
  雨天掉到 0.4，这一项直接翻倍——**120 公里时速要 141 米。**
  所以延迟不能单独看：**路面越滑，同样 250 毫秒越致命。**
  一句话总结：**实时性要按「米」验收，不是按「毫秒」验收。**

液压／电机 100 毫秒占 40%，后处理 49.4 毫秒占 20%。这两项加起来 60%， 都不是「模型」那一环。 后处理比预处理还久，这一点很多人想不到。因为降采样和激活要大范围遍历内存， 在 Python 里还有解释器开销（这一项在 C++ 里会小很多）。 推理 60 毫秒是我假设的，不是实测——因为沙箱里没有真实的骨干网络。但它在总延迟里只占 24%， 所以这个假设对结论影响不大。 把推理砍一半（60→30），总延迟 249→219，只降 12%。这就是「硬件占大头」时优化算法的真实收益。 要说明：预处理和后处理是真跑在 numpy 上的， 所以数字反映的是这套环境；换到车规芯片上绝对值会变，但「哪一环占大头」这个结构通常不变。

30 秒实验

1. 把曝光时间从 16.7 毫秒（60 帧）改成 33.3 毫秒（30 帧），看总延迟。 涨到 266 毫秒——降帧率省算力，但会加延迟，这笔账要算清。
2. 把车速改成 150 公里／时，看重算后的合计距离。 刹停距离会到 110 米以上，延迟那 10 米显得更小，但一样跑不掉。
3. 把摩擦系数改成 0.4（雨天），看重算的刹停距离。120 公里时速从 70.8 米变成 141 米，翻一倍。

常见误区

1. 「延迟 200 毫秒听起来还行」。120 公里时速就是 8.3 米盲走，要换算成米才能判断。
2. 「优化推理就能解决实时性」。推理只占 24%，砍一半也只降 12% 的总延迟。
3. 「预处理和后处理可以忽略」。后处理实测 49.4 毫秒，比预处理多三倍，占 20%。

训练要点三件事讲完了：数据合规、模型鲁棒、系统实时。 下一节进入交通场景——第一个问题是路口那几个灯该怎么配。

• ☐ （本节完，下一节 10.2.1 智能交通管理）

相关笔记

• 模型鲁棒性强化
• 智能交通管理
• 什么是模型量化与模型蒸馏
• 🧠 AI训练师手册2 · 索引