核心要点
把AI推理和运动控制放进同一颗工业SoC，最常见的翻车方式不是算力不够，而是推理一启动、控制周期立刻抖动。原本稳定在一毫秒的控制任务，出现零点几毫秒量级的偶发延迟，表现为轴抖、跟随误差变大或通信超时。根因是共享资源被争抢：NPU推理在DDR上产生密集突发访问，把实时核的访存延迟拉长；同时推理线程污染共享缓存，使实时任务的指令与数据频繁回到主存取。这两项都不会被算力指标反映出来。判断抖动来源要看分布而不是平均值。用GPIO翻转配示波器或硬件定时器记录控制周期，统计第九十九百分位与最大值；平均值正常但尾部拉长，基本可以确认是资源争抢而非算法耗时。可用手段按性价比排序：把实时任务的代码与数据放进片上紧耦合内存、给实时主控在总线上配置更高服务质量优先级、限制推理的批量与单次访存规模、划分缓存分区、最后才考虑换双芯片方案物理隔离。选型时该问的三个问题：是否提供总线服务质量调节寄存器、是否有可锁定的片上紧耦合内存或可分区缓存、是否支持非对称多核让实时核独立于Linux运行。三项都没有，就不要在这颗芯片上做硬实时。什么是资源争抢与总线服务质量
资源争抢（Resource Contention） 指多个主设备同时访问共享的内存控制器、总线与缓存，导致单次访问延迟被拉长的现象，后果是任务执行时间的上界不可预测。总线服务质量（QoS，Quality of Service） 是SoC内部互联提供的仲裁机制，可为不同主设备设置带宽配额与优先级，让实时主控的访存请求优先被内存控制器响应。紧耦合内存（TCM，Tightly Coupled Memory） 是与实时核紧邻的片上SRAM，访问延迟固定且不经过共享总线，是获得确定性执行时间最直接的手段。
抖动从哪里来
| 干扰源 | 表现 | 量级参考 | 缓解手段 |
|---|
| DDR带宽争抢 | 周期尾部拉长 | 数微秒到数十微秒 | 总线QoS配额 |
| 共享缓存污染 | 命中率骤降 | 数微秒 | 缓存分区或锁定 |
| DMA长突发 | 周期性尖峰 | 数微秒 | 限制突发长度 |
| 中断风暴 | 随机尖峰 | 微秒级 | 中断核绑定 |
| 温度降频 | 整体变慢 | 百分比级 | 散热与功耗封顶 |
| 电源域切换 | 偶发长延迟 | 数十微秒 | 禁用深度低功耗态 |
DDR是第一嫌疑：推理读权重与特征图的访问模式是长突发，对内存控制器最不友好，实时核的短读请求会被排在后面。缓存污染容易被忽略：推理数据量远大于末级缓存容量，会把实时任务的工作集整体冲掉，下一周期只能重新从主存取。温度降频属于慢变量：持续推理让芯片温度升高触发降频，控制周期整体变慢，现象是运行半小时后才出问题，排查时最容易误判为软件泄漏。怎么定位与量化
先测再改：用空闲GPIO在控制中断入口与出口翻转电平，示波器抓一小时的周期分布，记录最大值与第九十九百分位，这是后续所有优化的基线。开关对照：让推理任务在跑与不跑两种状态下各测十分钟，两组分布的差值就是争抢造成的净影响。看内存带宽占用：多数SoC提供内存控制器性能计数器，若推理期间带宽利用率长期高于八成，说明已经进入饱和区，任何软件优化都只能小幅改善。看缓存命中率：用性能计数器读取实时任务的末级缓存命中率变化，下降明显就应优先做缓存分区或把关键数据搬进紧耦合内存。分离温度变量：用风冷强制散热复测一次，若抖动明显改善，说明问题主要在温度与降频，不在总线。分工怎么设计
实时任务上核不上Linux：把周期性控制放到独立的实时核，用非对称多核架构运行，与跑Linux的应用核在启动与调度上解耦，Linux崩溃不影响控制回路。关键代码常驻片上：中断向量、控制算法、位置环数据放紧耦合内存或锁定缓存，禁止在中断上下文里访问经过共享总线的大数组。推理侧主动让路：把大模型拆成多次小批量推理，在两次控制周期之间的空隙执行，宁可牺牲帧率也不牺牲控制周期的确定性。数据交换用固定缓冲：实时核与应用核之间用双缓冲共享内存加内存屏障传数据，禁止在实时侧等待应用侧的信号量。给功耗设上限：把推理的功耗与温度封顶设在触发降频之前，用略低的帧率换全程一致的控制周期。常见问题（FAQ）
问：加一颗核或换更高算力的芯片能解决抖动吗？
答：通常不能。抖动来自共享的内存与缓存通路，增加核数往往让争抢更严重；换更高算力芯片如果内存带宽同比例增加还有帮助，若只是加了算力单元，反而会把带宽压得更紧。有效顺序永远是先隔离共享资源，再谈算力。
问：只把实时任务的线程优先级调到最高，够不够？
答：不够。操作系统优先级只能决定谁先拿到CPU，无法决定谁先拿到内存。一个低优先级的推理线程发出的DMA请求，在总线仲裁层面依然可能压在高优先级实时任务前面。必须同时配置总线侧的服务质量参数。
问：Linux加实时补丁与双核非对称架构该选哪个？
答：控制周期在毫秒级、抖动允许几十微秒的场合，打了实时补丁的Linux通常可用；周期进入百微秒级或抖动要求十微秒以内，应当选非对称多核，把控制放到裸机或实时操作系统的独立核上。判断依据是允许抖动，不是平均延迟。
问：怎么向芯片供应商确认这颗SoC能不能做硬实时？
答：问三份材料。一是互联的服务质量寄存器说明与可调粒度，二是紧耦合内存或缓存分区的容量与使用限制，三是官方提供的实时性测试报告，包含推理满载条件下的中断响应时间分布。只给算力对标数据的，视为未回答。
问：容器化部署会不会加剧抖动？
答：会。容器本身开销不大，但容器编排带来的日志采集、监控代理与镜像层文件系统访问都会占用内存带宽与中断资源。做法是把实时部分留在容器之外的独立核上，容器只承载推理与上传业务，两者之间用共享内存通信。
选型与落地清单
立项阶段先写下控制周期与允许抖动两个数字，用它筛芯片，不要先看算力再补实时性。确认芯片提供总线服务质量配置、紧耦合内存或缓存分区、非对称多核三项能力中的至少两项。控制算法与中断向量常驻片上紧耦合内存，中断上下文禁止访问大数组与外部Flash。给实时主控配置最高总线优先级与带宽保障，同时给推理主设备设置带宽上限。把大模型推理拆成小批量，安排在控制周期空隙执行，帧率让位于周期确定性。用GPIO加示波器建立周期抖动基线，记录第九十九百分位与最大值并纳入出厂检验项。做满载推理加高温环境的联合压力测试，至少连续两小时，确认降频不会破坏控制周期。实时核与应用核之间只用双缓冲共享内存通信，实时侧不允许阻塞等待应用侧响应。
