实时推理的挑战：延迟约束、吞吐量要求、模型复杂度与硬件资源的矛盾
做边缘AI芯片这几年，我最大的感受就是——实时推理从来不是单纯的算力问题。你想想看，一个模型在服务器上跑得飞快，放到边缘设备上就卡成PPT。为什么？因为边缘侧有四个东西在打架：延迟、吞吐量、模型复杂度、硬件资源。它们之间的矛盾，说白了就是「既要马儿跑，又要马儿不吃草」。
延迟约束：你只有几毫秒的时间窗口
实时推理的第一道坎，就是延迟。我见过太多团队，模型精度刷到98%，结果推理延迟超标3倍，项目直接废掉。
延迟到底有多苛刻？ 拿自动驾驶举例，摄像头采集一帧图像到执行刹车指令，整个闭环必须在100ms内完成。其中神经网络推理只占20-30ms。你想想看，30ms能干什么？一个典型的ResNet-50在Jetson Nano上推理一次就要80ms。嗯，这里要注意——延迟不是平均时间，而是最坏情况下的时间。
- 硬实时（<1ms）：工业控制、医疗设备。错过截止时间等于系统失效。
- 软实时（1-10ms）：语音交互、AR/VR。偶尔超时可以接受，但不能频繁。
- 准实时（10-100ms）：视频监控、智能家居。用户能感知到卡顿。
我在项目中遇到过一件事：一个智能门锁的人脸识别方案，客户要求从按下指纹到开门不超过500ms。我们用了MobileNetV3，推理延迟只有120ms，但加上图像采集、预处理、通信开销，总延迟飙到了480ms。最后发现瓶颈不在模型，而在摄像头驱动——每次读取帧都要等50ms。你看，延迟优化是系统级工程，不能只看模型。
吞吐量要求：并发推理才是真正的考验
延迟是单次推理的时间，吞吐量是单位时间内能处理多少请求。这两个指标经常互相矛盾。
举个例子：一个智能摄像头要同时检测10个目标。如果每个目标单独推理，延迟不变，但吞吐量上不去。如果做batch推理，吞吐量上去了，但第一个结果要等最后一个算完——延迟反而增加了。
为什么会这样？ 因为硬件资源是有限的。NPU的MAC阵列、DSP的乘法器、内存带宽，这些都是共享资源。当并发请求增多时，资源竞争导致每个请求的实际延迟都会增加。
| 场景 | 延迟要求 | 吞吐量要求 | 典型矛盾 |
|---|---|---|---|
| 智能音箱 | <200ms | 1-5路并发 | 模型太大，唤醒词检测延迟超标 |
| 安防监控 | <500ms | 16-32路并发 | 多路视频解码占满CPU，NPU空闲 |
| 工业质检 | <50ms | 100+件/分钟 | 流水线速度超过推理速度 |
我个人习惯的做法是：先确定峰值吞吐量，再反推单次推理的延迟预算。比如一个场景要求100路并发，每路延迟不超过100ms。那你的系统必须在100ms内完成100次推理，也就是每次推理平均1ms。这个数字一出来，你就知道该用什么模型了——MobileNet都嫌大，得用SqueezeNet或者二值化网络。
模型复杂度：精度和速度的永恒博弈
模型复杂度直接决定了推理延迟和硬件资源消耗。但问题是，复杂度和精度不是线性关系。我见过有人把ResNet-50换成ResNet-101，精度只涨了0.5%，计算量翻了一倍。值不值？你自己掂量。
衡量模型复杂度的核心指标有三个：
- 参数量（Params）：决定模型大小和内存占用。1MB的模型和100MB的模型，加载时间差一个数量级。
- 计算量（FLOPs）：决定推理时间。1G FLOPs和10G FLOPs，在边缘设备上可能就是10ms和100ms的区别。
- 内存访问量（MACs）：这个容易被忽略。很多模型计算量不大，但频繁读写内存，导致实际延迟远高于理论值。
硬件资源的硬约束：你只有这么多东西可用
边缘AI芯片的硬件资源是固定的。你不可能像云端那样随时扩容。常见的资源瓶颈包括：
- 算力（TOPS）：NPU的峰值算力，决定了你能跑多复杂的模型。但注意，峰值算力不等于有效算力。实际利用率能有60%就算不错了。
- 内存（SRAM/DRAM）：模型参数、中间特征图、输入输出数据都要占内存。SRAM快但贵，DRAM便宜但慢。怎么分配是个学问。
- 带宽（GB/s）：数据从内存搬到计算单元的速度。很多芯片算力够，但带宽不够，导致计算单元一直在等数据。
- 功耗（W）：边缘设备通常有严格的功耗限制。手机芯片不超过5W，IoT设备不超过1W。功耗一超，就得降频，性能直接打折。
我画了一张图，帮你理清这四个要素之间的关系：
矛盾的本质：系统级权衡
这四个要素不是独立的，它们互相影响。我总结了一个经验公式：
系统性能 = min(算力利用率, 内存带宽利用率) × 模型效率 × 硬件效率说白了，木桶效应在这里特别明显。你算力再强，内存带宽跟不上，一样白搭。模型再轻量，硬件利用率低，也是浪费。
我处理过的一个实际案例：一个智能相机的目标检测项目，用了YOLOv5s，在RK3588上推理延迟35ms。客户要求降到20ms以内。我们试了模型剪枝、量化、算子融合，最后降到22ms，死活下不去。后来发现瓶颈在DMA传输——每次推理前都要把输入图像从DRAM搬到NPU的SRAM，这一步就占了8ms。最后我们改了数据流水线，让DMA和NPU并行工作，延迟直接降到18ms。
所以，面对实时推理的挑战，我的建议是：先量化，再优化。把延迟、吞吐量、模型复杂度、硬件资源这四个维度都量化出来，找到矛盾最尖锐的地方，然后针对性地解决。不要试图一次性搞定所有问题——那是不可能的。
嗯，这一章的内容就到这里。记住，实时推理的本质是系统工程，不是单纯的算法问题。下一章我们会深入具体的优化技术，看看怎么在硬件资源有限的情况下，把推理性能榨干。