NPU共享DDR时，QoS比峰值更关键

很多节点单模型测试时吞吐正常，一到现场并发就忽快忽慢，问题常不在峰值带宽，而在共享仲裁。NPU只要和相机、编码器、CPU 后处理共用 DDR，QoS 规则写得不好，实时性会先出问题。

共享主存最怕短时间内出现多个高突发主设备。相机帧写入、编码器码流回写、日志落盘和推理张量读写若在同一窗口叠加，控制器会不断在不同主端口之间切换。总带宽表上看似仍有余量，关键任务却可能在最坏时刻拿不到连续服务。对实时推理来说，稳定的服务间隔比漂亮的峰值数字更有用，因为阵列一旦等数，前后级节拍都会被打乱。

QoS 不只是给某个主设备打高优先级这么简单。若一味抬高推理读请求优先级，写回队列可能被压住，缓冲迟迟腾不出来，最终仍会反向卡住前端；若只保证写回顺畅，读路径又会饿死。更稳妥的做法，是同时给读、写设独立水位和抢占窗口，让关键流量在高水位前被服务，而不是等队列爆满后再救火。

摄像头和推理并发是最常见的冲突源。采集端通常按固定周期吐出大块数据，而推理链的读写节奏则随层而变；若两者共享同一仲裁策略，相机的整帧突发容易把中间层张量访问挤成碎片。此时平均帧率不一定掉很多，但尾延迟会稳定变坏。现场表现常是“有时一切正常，有时隔几秒就卡一下”，本质上就是固定周期的外设流量在打断推理工作集。

后处理同样不能被忽略。很多系统把 NMS、解码、跟踪留给 CPU，以为不占加速器就不影响主链，实际上这些步骤同样要读回大量特征或候选框。若平台没有把 CPU 大页访问纳入带宽预算，推理刚算出来的数据会在写回和后读之间互相抢线。看似瓶颈在后处理，真实根子仍是主存仲裁没有按链路重要性分层。

隔离预算应该在系统设计阶段就写出来。关键模型、采集通路、码流输出和后台维护分别能占多少带宽、在什么水位开始降级、谁可以被限流，最好都形成显式策略。否则现场新增一个看似无害的统计任务，就可能把原本平衡好的总线重新搅乱。共享资源没有预算，就等于默认所有人都能随时冲进来。

某些控制器还支持端口老化或信用配额，这类机制若长期保持默认值，弱优先级主设备会在持续重压下被饿太久，最终把偶发拥塞拖成稳定抖动。

若平台允许动态改优先级，也要防止控制线程在高峰时频繁改表，否则仲裁器还没稳定，新的优先级波次又进来，抖动会从硬件竞争变成策略自身振荡。

定位这类问题时，单看总 DDR 利用率帮助不大，更需要读写队列深度、主设备服务间隔、仲裁等待时长和高水位触发次数。若慢帧总伴随某一主端口的突发峰值，说明 QoS 没把关键路径隔离开；若各端口都不高却仍抖，则要反查访问粒度和地址局部性是否已经碎掉。

共享内存系统稳不稳，不看峰值数字，而看最坏时刻谁还能持续得到服务。只要 QoS 和仲裁预算先被定清，NPU在多任务现场的吞吐才不会被别人零敲碎打地吃掉。