Agent参与实验循环后，Databricks训练任务涨了8倍，瓶颈也换了

Databricks AI研究团队把一部分实验循环交给agent。流程不复杂：agent提出模型或训练方法的改动，并行提交多个实验，读训练指标，判断哪个方向有效，再开下一轮。Databricks在博客里说，这种agent驱动的实验方式，让他们AI Functions研究负载的训练任务数量一年涨了8倍。

8倍听起来像效率故事。真正先暴露的是基础设施摩擦。Databricks团队训练从几十亿参数到近万亿参数的模型，方法包括SFT、离线RL和在线RL，用H100或B300，最大训练任务要几百张GPU跑数天到数周，还要高带宽网络。一个节点或RDMA网络出问题，几百张GPU就空转，训练只能退回旧checkpoint重来。长任务最怕这种中断。

这些模型支撑Databricks AI Functions，包括ai_parse_document和ai_extract。Databricks列了三个挑战：长训练任务的容错，快速实验和原型验证，GPU队列在多项目间的分配。对应到agent实验，问题更直接。研究员手动跑几个实验时，启动慢一点还能忍。agent一次提交几百个任务，启动延迟、配置报错、坏节点都会变成吞吐瓶颈。

AI Runtime是Databricks用来管这层GPU训练基础设施的产品。研究团队从产品早期就是客户零号。AIR会在训练前检查GPU节点健康和通信，训练中监控NCCL通信失败、热或功耗降频、GPU驱动问题。节点坏掉导致任务失败后，系统会隔离该节点，后续任务不再调度上去。对KARL这类超过1000亿参数、需要数千GPU小时的RL项目，这比反复排查硬件故障更实际。

快速迭代靠两件事。AIR CLI让任务可以程序化启动，指定GPU，由AIR负责供应和调度，包括跨云分布式训练的高带宽网络。自定义Docker容器则让本地开发环境和训练环境保持一致，代码上传后在同一个容器里跑，镜像可以通过Databricks Artifact Registry注册和共享。Databricks说AIR在启动延迟和容器优化上的投入，能把训练任务启动压到几秒，缩短实验反馈循环。

实验追踪用MLflow。AIR会自动创建和管理训练任务的MLflow实验，研究员能看状态、流式读日志、取指标。agent也要靠这些信息评估结果，决定下一步。研究数据放在Unity Catalog，通过FUSE挂载，训练代码可以像读本地文件一样访问，跨workspace也能用，数据权限和追踪不丢。

GPU容量管理是另一个摩擦点。调试实验可能只要几张GPU，大训练要几百张跑几天。AIR的优先级和抢占能力把资源分给不同项目，时间敏感的实验先跑，空闲容量可以接探索性实验。Databricks举的例子是周末用空闲容量跑额外实验，不打断高优先级工作。目标不是让研究员手动协调机器，是让该跑的实验有GPU可用。

Agent循环受Andrej Karpathy提出的autoresearch影响。Databricks把流程拆成四步：提议，提交并行试验，读指标学习，更新计划再开实验。AIR适合这个循环，因为agent能通过Databricks CLI和databricks-air-skills程序化提交并发任务、监控状态、取MLflow指标，再根据结果迭代。

这里有个容易被忽略的变化。人做研究时，基础设施问题是摩擦；agent做研究时，基础设施问题会变成实验吞吐的上限。启动慢、报错含糊、结果拿不到，都会让agent在原地打转。Databricks的结论很产品化：agent驱动研究需要快速任务启动、程序化接口、清晰可行动的报错、可靠执行和可访问的训练结果。听着像基础设施清单，实际决定agent一天能试多少想法。

如果自己训练或微调模型，可以看Databricks的AI Runtime文档。原文在这里，autoresearch项目在GitHub。