KernelOPT：面向 GPU 内核优化的调度感知智能体搜索

KernelOPT 是一个多智能体系统，把编译后的模型视为结构化产物，保留 cuBLAS、cuDNN 等厂商库调用，只用五个受性能剖析引导的 LLM agent 优化生成的 Triton 子核，并通过静态校验、多种子正确性、模型级 float64 回退验证和性能门控四道关卡筛选候选。在 250 个 KernelBench 问题上，相对 torch.compile 的几何平均加速为 Level 1 1.40 倍、Level 2 1.15 倍、Level 3 1.07 倍。

此前 LLM 辅助内核优化器多把编译模型当黑盒，只优化孤立内核，不尊重编译器的结构性决策，也不做端到端验证。KernelOPT 改为在编译产物结构内定点替换生成的 Triton 子核，并加入四道验证级联和整模型端到端复核，在无候选达标时保留编译器基线。

机制上，它不重写厂商库调用，只对编译器自动生成的 Triton 子核做搜索，降低与 cuBLAS、cuDNN 等已优化实现冲突的风险；多智能体结合 profiling 信息定位候选，四道关卡依次过滤不合法、不稳定、数值错误和性能不足的候选，从而在保证正确性的前提下接受加速结果。

对依赖 PyTorch Inductor 生成内核的推理与训练流程，这提供了一条在编译基线之上再取增量的路径，且失败时回退到原基线，降低采用风险；团队可在不改模型代码的前提下接入 nn.Module 或独立 Triton、Helion 内核，但需承担额外的编译与验证时间成本。

• 在推理服务上线前，对 torch.compile 生成的热点子核做离线优化并用四道验证门控，达标才替换上线。
• 把端到端 float64 回退验证包装成内核替换的默认合规检查，降低数值错误进入生产的概率。
• 针对 Level 1 类简单子核优先落地，因其报告的几何平均加速最高，验证 ROI 更明确。

• 1.40 倍、1.15 倍、1.07 倍这些加速数字在真实生产模型上是否可复现，而非仅限 KernelBench 合成题目？
• 四道验证级联带来的端到端优化与验证耗时是多少，是否适合频繁迭代的研发流程？
• 多智能体搜索的 token 与算力开销相对于所获加速是否经济？
• 该方法对不同 GPU 架构和 CUDA、Triton 版本的鲁棒性尚未被证据说明。