边缘计算亲和性优先于盲目迁移

节点一旦同时跑采集、推理和控制，不少系统会依赖调度器自动把任务分到空闲核心。边缘计算里如果忽略亲和性，线程看上去在“动态平衡”，实际常把缓存局部性和加速器邻近性一起打散。

亲和性绑定的价值，不只是把线程钉在某个核上，而是让数据流和执行单元形成稳定路径。摄像头中断若总落在同一簇核心，预处理线程再紧邻这簇运行，缓存中的热页就能被复用；反之，中断、预处理和推理线程每次都被迁来迁去，L2 和共享缓存不断失效，平均算力没变，尾延迟却会抬高。对弱核强核并存的 SoC，这种抖动尤其明显。

异构核迁移还有隐藏的能耗和同步代价。某些系统为了追求瞬时低延迟，把热点线程从小核搬到大核，看起来反应更快，但迁移时要重新加载缓存、切换频点，甚至调整内存控制器策略。若任务本身执行时间并不长，搬家成本可能和真正计算时间相当。结果是核心占用图很好看，业务时延却没有下降。

加速器邻近内存也会影响迁移收益。NPU、DSP 或 ISP 往往更适合与特定内存区域或 DMA 通道协同，线程若被迁到远离这些中断和缓冲区的位置，数据仍要跨总线折返。很多项目只把 CPU 使用率当作调优指标，却忽略了“线程在哪里消费数据”这个更核心的问题。对端侧推理链，位置不对往往比核心不够更伤。

固定策略并不等于所有线程都永远绑死。实时闭环、采集中断和关键预处理适合保持稳定落点，后台压缩、日志和批量上报则可以在剩余核心上弹性运行。关键在于先划出抢占域，让高优先级任务的局部性不被非关键任务破坏。若所有线程都共享同一调度池，后台任务即使优先级低，也会通过缓存污染和内存争用干扰关键路径。

迁移问题还会伪装成随机丢帧或偶发超时。因为线程并非每次都迁移到同样的核，现场表现会像“偶尔有几次特别慢”，压力测试里却不一定稳定复现。把线程迁移次数、缓存未命中、加速器等待和中断落点一起记录，才能把这种随机现象拉回到可解释的系统层。

亲和性设计要跟业务阶段一起变化。启动阶段模型加载和校验占主导，可允许更大的迁移空间；进入稳定运行后，应收紧关键线程的核绑定和频点策略。若设备还要按温度或供电状态切换模式，也要同步调整亲和性，不然节能模式下原本合理的布局可能突然失效。

如果系统支持 cpuset 或隔离核，最好把实时线程和后台线程在启动时就分仓，避免故障排查时还要从一堆随机迁移里猜关键路径到底被谁打断。

不要把调度器的自动迁移当成免费优化。自动迁移适合吞吐型后台任务，不适合要求尾延迟稳定的控制链。先让数据和执行单元形成固定搭配，再讨论哪一部分值得动态均衡，收益通常更直接。

端侧性能是否稳定，常常取决于线程是否待在该待的位置。只要亲和性先于盲目迁移被设计好，边缘计算就更容易把局部算力变成可预测输出。