MLIR的Heterogeneous Computing（异构计算）调度从一个凌晨三点的崩溃说起去年做一款边缘AI推理引擎，目标是在一块RK3588上同时跑四个模型：一个YOLOv8做检测，一个ResNet做分类，外加两个轻量级语音模型。硬件资源是四核Cortex-A76、四核Cortex-A55、一个Mali-G610 GPU、一个NPU。听起来很美好对吧？结果凌晨三点，系统在切换模型时直接挂掉——GPU显存泄漏、NPU驱动死锁、CPU负载飙到400%。我盯着串口日志，看到一行“MLIR pass manager: failed to schedule heterogeneous pipeline”，才意识到问题出在调度层。那晚之后，我花了三个月重构了MLIR的异构调度模块。今天这篇笔记，就是那三个月踩坑的浓缩。异构计算的本质：不是“分配”，是“协商”很多人把异构调度理解成“把算子分给不同设备执行”，这是典型的教科书思维。真实情况是：每个设备都有自己的“脾气”——GPU喜欢大块连续数据，NPU对特定形状有硬件加速，DSP要求数据对齐到128字节，CPU虽然慢但什么都能干。MLIR的异构调度，本质是在这些设备之间做“协商”：谁更适合这个算子？数据搬运成本多少？设备当前负载如何？MLIR里有一个叫DeviceMappingAttr的属性，它标记了每个操作应该映射到哪个设备。但别天真地以为加上属性就完事了——我见过最蠢的写法是给所有卷积都打上#gpu，结果小卷积