边缘计算抖动：推理队列要收口

系统一旦把感知、推理和控制都压在端侧，最先暴露的往往不是平均算力，而是抖动。边缘计算若不先把队列和峰值并发收住，控制链路就会从“偶尔慢一点”变成“时快时慢”。

抖动通常不是单个模型慢，而是多个任务在同一时间窗里同时抢资源。摄像头帧、音频块和传感器包进入本地网关后，若推理线程、预处理线程和上报线程都按同一优先级排队，短时峰值会把缓存、CPU 和 NPU 一起推到拥塞区。此时平均 FPS 可能看着正常，真实现场却会出现某几帧延迟突然拉长，控制输出错过窗口。边缘计算里最危险的不是长期满载，而是峰值到来时系统没有缓冲余量。

峰值并发整形的关键，是让数据流在进入核心模型前先被分层。实时闭环相关的输入应拥有最高调度权，非关键上报和统计任务应在本地空闲时再消费资源；如果模型支持，短时积压可以通过小批量合并处理，但批处理窗口不能无限增大，否则会把延迟从随机抖动变成稳定偏移。对视频类任务，丢帧并不一定是坏事，前提是丢的是过期帧而不是控制关键帧。边缘计算的本地调度，本质上是在吞吐和时延之间设一个硬边界。

队列收口不能只靠把缓存做大。缓存越大，系统越容易把过期输入保存下来，后续推理虽然没有丢数据，却是在处理已经失去控制意义的历史。更合理的做法，是给每类输入设置最大等待时间和最大队列深度，超过上限时按时间戳丢弃旧帧，而不是让先进先出规则机械地拖住新帧。对报警类任务，还要保留触发前后的短窗口，避免只留下事件之后的片段。

峰值整形也要放在资源入口，而不是等模型已经排队后再补救。摄像头帧率、音频块大小、传感器采样周期和网络上报频率都应接受统一预算；当本地负载升高时，先降低非关键输入速率，再限制后台任务，而不是让实时任务和日志任务一起争抢处理器。若设备支持硬件加速，还要记录加速器等待时间，区分是真正算力不足，还是入口没有背压。

更稳妥的做法，是把端侧时延预算拆成采集、预处理、推理、后处理和上报五段，并给每段留出最坏值。只盯平均值，结果常是某段短时拥塞沿着流水线一路放大。若网关还要承担多个模型，主模型和辅助模型最好分开队列，避免某个低优先级任务拖住高优先级控制链。缓存也应按生命周期拆分，短命帧不要和长命日志共用同一池。

队列指标也要直接暴露给运维系统。只记录 CPU 使用率和平均推理耗时，不足以解释现场抖动；更有用的是每级队列的最大深度、最长等待、丢弃原因和过期帧比例。若这些指标能和业务事件对齐，就能判断抖动来自采集端突发、模型端排队，还是上报端阻塞。没有这些观测点，工程团队只能靠复现压力猜瓶颈。

端侧还要预留降级路径。峰值持续超过预算时，可以降低非关键模型帧率、暂停历史回放或只输出粗粒度结果，但不能让实时链路无限等待。降级动作应由本地状态触发，而不是等云端下发指令；否则网络不稳时，最需要降级的时刻反而收不到控制命令。

验证抖动时，要在最坏网络、最坏负载和最冷启动状态下观察端到端时延曲线。只要峰值并发被压平，控制环就不会因为偶发拥塞而乱跳。系统能不能稳，不看平均值，看峰值管理。