核心问题：按编译器 IR 层级划分 Agent，为什么可能帮助优化，又会遗漏什么跨层关系？
论文卡片
- 原题： EdgeKernelBench: Unified LLM-Driven Kernel Generation for Edge Backends
- 作者： Yuhua Zheng、Xueyi Chen、Xinze Zou、Xin Li、Haoji Hu、Huan Wang；西湖大学、浙江大学。
- 日期与版本： 2026-10-17 提交，arXiv v1，25 页；cs.LG；基准与系统研究预印本。
- 定位： 异构边缘设备的 LLM kernel 生成，以及沿多层 IR 组织优化的方法。
- 阅读入口： arXiv · HTML 全文（v1） · PDF（v1） · alphaXiv
简短导读：把一个大优化问题拆到不同表示里
EdgeKernelBench 用 TVM 实例化统一生成接口，覆盖 CPU/LLVM、GPU/CUDA、GPU/OpenCL。LEKA 进一步把图与算法、循环调度、目标源码分别交给不同 Agent；候选树保存版本关系，硬件反馈帮助选择下一次修改的位置。
这套分工的理由是：每层只需处理部分细节。但布局、融合和并行映射互相制约，所以局部 Agent 不能完全独立。上层改变后，受影响的下层实现需要重建，最终仍以完整程序验收。
证据与限制
论文从 331 个规范任务构造 650 个后端任务实例，覆盖单算子到紧凑模型图。性能基线是经过 MetaSchedule 调优的 TVM，而非未经优化的直接执行。Fast@1.0 指全部被评任务中，通过正确性检查、具有有效计时且快于该基线的比例，不是平均加速倍数。
Agent 实验只用分层抽样的 69 个实例，每后端 23 个。LEKA 和通用 Claude Code 均使用 GLM-5.3-Flash，共享任务契约、评测器与时间上限：Level 1 为 90 分钟，Level 2/3 为 155 分钟。Fast@1.0 从 Claude Code 的 26.1% 增至 LEKA 的 43.5%；单次生成是 13.0%。不能把这一子集的结果当作全部 650 个实例的成绩。
附录 B 规定使用三个随机种子输入及任务容差检查正确性；计时排除编译与部署时准备，并采用配对测量。因此“全部通过”仍是有限测试结论。论文没有逐项消融分层、候选树和反馈路由；结果支持整套系统的收益，尚不能单独证明 IR 分工是原因，更不能证明这种划分最优。附录 G 也未覆盖 NPU 或单任务 CPU/GPU 协同执行。
以上为原文 §5、附录 B/C/G 的结果与范围；对因果归因的限制是导读者的判断。本导读未独立复现实验。
重点阅读章节
- §4.1–4.2： 看层内编辑范围、渐进降低与候选谱系如何约束分工。
- §5.3、附录 B.4： 把比较结果与模型、任务子集、时间预算一起读。
- 附录 E.2.2、F.2、G： 对照实际跨层依赖、角色边界与尚未验证的设计空间。
思想启发：分工边界不是因果边界
以下是导读者的理解。
一个编译器层级说明“哪些决定适合在此表示”，却未必说明“性能问题由这一层单独造成”。低层出现访存瓶颈，可能需要改变高层布局；局部调度再精细，也可能无法弥补错误的融合边界。
这使分层具有两面性：减少上下文可以让局部推理更集中，同时也可能隐藏决定局部问题的全局事实。LEKA 保留相邻层信息和跨层请求，恰好说明有效分工依赖信息重新连接，而不只是切割任务。
还有一个反事实：假设某个图改写暂时变慢，只有后续专门调度才能获得收益，那么只接受眼前改进的流程可能过早放弃它。这不是论文报告的失败案例，而是由“局部验收”与“跨层互补”之间的张力引出的疑问。完整程序计时能判断当前结果，却不能直接判断尚未实现的组合潜力。
三个开放性思考问题
1. 编译器为合法降低设计的层级，为什么应当同时适合模型推理的分工？
参考思路
两者可能共享语义结构：图层显露依赖，调度层显露复用。但编译器设计也受历史接口和实现约束影响，未必对应模型最容易处理的知识单元。论文展示了一种有效划分；它尚未说明按瓶颈、算子区域或其他边界划分会更差。
2. 同模型、同时间预算下更快，足以把收益归因于分层吗？
参考思路
它排除了更换基础模型和延长允许时间这两种简单解释，却没有分离候选记忆、反馈解释、上下文组织及搜索策略。相同墙钟预算也不意味着相同调用数或评测数。因此可以认可系统级比较，同时保留机制层面的不确定性。
3. 如果一个上层改写只有配合未来的下层优化才有价值，当前计时应该拥有多大的否决权？
参考思路
立即拒绝可以节省搜索预算，却可能错过互补变换；保留所有暂时退步又会使分支膨胀。问题在于区分“尚未兑现的潜力”和“没有根据的乐观”。候选树提供保留可能性的结构，但哪些分支值得继续，仍需要超出当前延迟的判断。