24 小时、1,000 次工具调用：kernel 案例研究证明了什么

实验设置

Meta 测试了 Muse Spark 1.2 在长达 24 小时、超过 1,000 次工具调用的运行中迭代优化 GPU kernel 的能力。在 Muse Code 的 agentic 环境里，模型编写一个 kernel、编译它、以给定的 baseline 为基准做 profiling，再利用 profiling 数据继续尝试——一个“编写-编译-剖析-改进”的紧凑循环，持续整整一天。基准目标是 NVIDIA Hopper GPU 上的 KDA 和 MLA attention kernel。

有一条规则让这次测试足够诚实：禁止模型导入 FLA 之类的第三方 kernel 库。不能把现成的快速实现包一层就邀功——agent 必须运用真正的 kernel 优化知识，亲自用 Triton 实现这些算法。

Agent 实际构建了什么

这些解法并不是泛泛之作。针对 KDA——以 FLA 的 Triton 实现为基准——Muse Spark 1.2 把一个分块并行（chunk-parallel）的准备 kernel 与一个顺序的块间扫描（inter-chunk scan）配合起来，在标准的算子融合和 tiling 之外，还用上了 KDA 特有的技巧，比如把带门控的累积衰减重新居中到块的中点。针对 MLA——以 PyTorch 参考实现为基准，batch size 1、64 个 head、序列长度 8192、latent 维度 512——它设计了一条两 kernel 的 Triton 流水线，将共享的 KV latent 同时复用为 K 和 V。

这些是专家在理解算法结构之后才写得出的优化，而不是表层的循环微调。而且随着运行推进，agent 持续找到相对 baseline 的显著改进——进展在数百次迭代中不断累积，而不是在第一波爆发后就陷入停滞。

为什么 24 小时才是真正的头条

能把一个 kernel 优化二十分钟的模型有很多。要把有方向的进展维持一整天，需要的是大多数 agent 不具备的基础设施。有三个部件承担了重量。目标条件化（goal conditioning）让第 700 次迭代仍然瞄准与第 1 次相同的目标——模型正是为此而训练的。上下文压缩（context compaction）保留真正重要的知识（哪些策略失败了、profiler 说了什么），而不会淹没在一整天的历史里。而事件日志让运行时可以安全重启——24 小时里，一定会有什么东西出岔子，如果一次崩溃抹掉了第 23 小时的成果，整场演练就毫无意义了。

它对日常工作意味着什么

很少有团队需要优化 Hopper kernel。但这个任务的形态——对着一个可度量的目标迭代、从每次尝试中学习、不丢失主线——和大量并不光鲜的工程工作是吻合的：追查不稳定的测试套件、一点点磨小 bundle 体积、把一个 API 迁移分一百个调用点逐步完成。这份案例研究是 Meta 给出的证据：如今“启动它，明天再来看”已经是一种真实可用的工作流。评测方法论已发布在 Meta 的研究站点上；长时程工作的产品侧则从文档开始。