边缘计算为何丢帧？先查调度失衡

端侧一丢帧，很多人先怀疑算力不够。边缘计算里，真正把帧打丢的，常常不是绝对算力，而是调度顺序错了。

调度失衡会把本来能跑完的任务挤出时间窗。摄像头预处理、推理、记录和网络上报若都在同一个核心上执行，某个后台任务突然占住 CPU，前台控制帧就可能错过截止点。算力峰值在这里比平均值更重要，因为很多端侧设备平时空闲不少，只有在多任务重叠时才真正触顶。端侧丢帧，往往发生在峰值瞬间而不是稳态阶段。

任务切片能缓解这个问题。把大任务拆成小片段后，调度器可以在片段之间插入高优先级控制任务，避免一个长耗时线程独占资源太久。可切片也有代价：切得太碎会增加上下文切换和缓存失效率，反而把总时延抬高。对多模型共存的端侧系统，实时模型应占有固定预算，非实时模型在空隙中推进，不能让后台盘点和日志压住前台。

预处理队列也是丢帧高发点。图像缩放、颜色转换、畸变校正和格式重排往往在模型前完成，如果这些步骤没有硬件加速，CPU 会先被耗尽，后面的推理单元反而空等。此时增加 NPU 算力没有意义，因为瓶颈不在模型。边缘计算系统应把采集到推理前的每一级队列都暴露出来，确认到底是哪一级开始堆积。

多模型共存时，峰值占用还会相互叠加。一个检测模型、一个分类模型和一个异常上报线程单独测试都没问题，合并运行时却可能在同一秒同时抢内存带宽。若调度器只按任务优先级，不按资源类型做限制，高优先级任务也可能被低优先级任务占满缓存或 DMA 通道。更稳妥的策略，是给关键模型保留固定资源窗口，后台模型只能使用剩余预算。

丢帧容忍度也必须显式定义。某些监控任务可以接受偶发丢帧，只要关键事件不丢；而控制任务则不能容忍连续丢帧。若本地监控指标只记录平均帧率，就会把真实故障藏起来。更有用的做法，是同时看最差帧间隔、最长阻塞时间和峰值占用，确认调度失衡是否来自某个固定线程。

算力不足和调度失衡的排查方法也不同。若每级队列都不深，但单次推理稳定超时，说明确实需要换模型或加速器；若单次推理不慢，只是某些时段帧间隔拉长，就应优先看任务抢占和资源峰值。端侧调度最好记录线程运行轨迹、队列水位和硬件加速器占用，这些数据能把“缺算力”和“排队错”分开。

丢帧策略还应与业务目标绑定。安防监控可以丢中间帧但要保留事件首尾，质量检测可以跳过低风险工件但不能漏掉异常批次，控制系统则宁愿降级模型也不能连续空窗。没有业务边界的丢帧，只是把技术故障变成业务风险。

排查时还应把冷启动和热运行分开。冷启动阶段模型加载、缓存预热和网络重连会同时发生，丢帧原因与稳定运行时不同；若只测热运行，首批帧丢失会被忽略。对需要随上电立即工作的设备，启动前几秒也应纳入调度预算。

所以，边缘计算不是算力不够才掉帧，而是资源分配没给关键路径留空档。先把调度修正，再谈扩算力，结果更接近真实需求。