Auto Research 有了计算需求，但研究工作流本身是极度不可预测的：

  • 超参搜索阶段：需要数十甚至数百个 GPU 并行跑
  • 调试阶段：回到 1 个 GPU，频繁交互，快速迭代
  • 验证阶段：扩到 8-GPU 集群，确认质量
  • 全部完成：缩回零，释放资源

所有这些状态，可能在同一个 session 里交替发生。

传统云基础设施的问题：

常驻集群：有突发算力，但贵。Agent 在「Thinking...」的时候你也在付费，而且大多数集群难用。

单机/工作站：便宜、好用，但强制实验串行执行，迭代速度被拖死。

你要的是两个世界的最佳解：单机的心智负担和成本控制，加上大集群的突发算力。

Modal 的解法

Agent 写好训练脚本，加一个装饰器：

@app.function(gpu='H100:8')
def train_model():
    ...

然后 modal run。有 Bug 了，调用 modal.Sandbox.create(gpu='H100:8') 起一个交互式沙箱。GPU 几秒内就绪，从 1 GPU 扩到数十甚至数百个也是一行参数的事。工作完成，自动释放——不会醒来发现一个空闲集群跑了一整夜账单爆了。

Agent 和人类一样，需要多少算力取决于他们正在做什么。但也和人类一样，他们喜欢弹性。Modal 为此专门写了 Skills，指导 Agent 如何使用 Modal 的算力原语：启动交互式沙盒、用 modal run 写和跑训练任务、用 modal.Volume 管理持久存储、编排并行子 Agent。

真实案例：15小时跑完 113 次实验

Tony 给 Claude Code 接了 Modal + Bits per Byte benchmark，让它自己跑，然后去睡觉。

醒来后发现：

  • 113 次实验
  • 238 GPU-hours
  • 核心训练完成时间比单机快 5 倍
  • 只用了单机串行所需资源的一小部分

完整时间线拆解

Phase 1：冒烟测试（~1小时）

Agent 通过 modal.Sandbox.create(gpu='H100:8') 起了一个单 GPU 沙箱，跑了一个 tiny 8M 参数模型训练，量化后跑评估。4 次快速实验确认端到端流程可工作。Baseline BPB：1.42。

Phase 2a：探索阶段 — 并行搜索（~36分钟墙钟时间）

68 次单 GPU 实验，每次用 modal.Sandbox.create(gpu='H100') 起一个独立沙箱。搜索空间：模型大小、学习率、序列长度、训练时长。没有任务队列、没有资源分配配置，每个实验一行调用。BPB 从 1.42 → 1.40 → 1.37 → 1.34。

Phase 2b：精选阶段 — 聚焦最优配置

23 次单 GPU 实验，聚焦最有望的模型大小和学习率组合。

Phase 3：8×H100 并行验证

从单 GPU 切到 8×H100，只改了一个参数：gpu='H100' → gpu='H100:8'。不需要新的集群配置，不需要部署清单，Modal 用同一套方式处理多 GPU 调度。跑 top 5 配置，5 × 8×H100，40 个 GPU 同时跑。BPB 从 1.34 降到 1.14。4 小时完成，而不是 20 小时。

Phase 4：调试瓶颈（5.5小时，60 GPU-hours，全部超时）

模型训练没问题，但量化步骤——GPTQ 压缩到 16MB 预算——跑在 CPU 上，每次超过 45 分钟，10 分钟评估窗口根本无法完成。Agent 尝试增加超时：45 → 60 → 90 → 120 分钟，全部超时。

Phase 5：重写量化 — GPU 加速

换思路：把量化步骤重写为 GPU 执行。总时间降到 52 分钟（含训练和量化）。

Phase 6：优化阶段 — 弹性扩缩

确认修复后，Agent 进入优化循环：

  • 2 × 8×H100 验证（BPB: 1.1420，无回归）
  • 5 × 8×H100 并行优化（BPB: 1.1230 → 1.1217 → 1.1206）
  • 4 × 8×H100 最终确认（BPB: 1.1220，略差，Agent 判断边际收益递减）
  • 缩回零，停止

最终 BPB：1.1206

弹性伸缩的真实收益

阶段vs 工作站加速vs 常驻集群效率
冒烟测试~1x节省大量（1-2 GPU 足以）
探索（68次单GPU）~4x（40次/40分钟 vs 3小时）节省大量（按需用~40 GPU）
验证（5×8×H100）5x（4小时 vs 20小时）集群满载，几乎无闲置
调试（串行）~1x节省大量（只用1-2 GPU）
优化（弹性扩缩）高速 + 高效按需调配

Auto Research 的算力基础设施意义

Modal 展示的不是某个 benchmark 分数，而是 Auto Research loop 在工程侧最难落地的一环：算力弹性。

Karpathy 的 Autoresearch 概念解决的是「Agent 如何通过循环改进自己」；Modal 解决的是「循环的每次迭代所需的算力从哪来、如何低成本按需取用」。

Agent 可以自主决定：

  • 用多少算力
  • 用什么类型的算力（单 GPU 调试 vs 多 GPU 训练 vs 大规模并行搜索）
  • 何时释放

不需要提前预留，不需要人工干预，按需弹性，用完即走。

想自己试？把 Modal Skills 集成进你的 Agent，指向你的问题，看它能发现什么。