AI基础设施必须进化为“代理体验”——Modal CTO Akshat Bubna 访谈
摘要：Modal 是一家 AI 基础设施公司，近日完成 3.55 亿美元 C 轮融资。其 CTO Akshat Bubna 认为，传统云基础设施（如 Kubernetes）是为人类开发者设计的，而 AI 代理无法像人类一样阅读文档、调试 YAML，因此基础设施必须从“开发者体验”（DevEx）转向“代理体验”（AgentEx）。核心变化包括：用沙箱替代复杂编排、用装饰器替代 YAML 配置、强化可观测性，并支持弹性 GPU 资源分配，以满足突发计算密集型工作负载。
为什么 Kubernetes 不适合 AI 代理？
Kubernetes（简称 K8s）是当前主流的容器编排平台，但它最初是为 Web 服务器这种缓慢伸缩的场景设计的。AI 工作负载——尤其是强化学习训练、大规模推理和批量处理——需要快速创建和销毁大量计算环境，且环境高度专业化。Kubernetes 的复杂配置（数百个 YAML 文件）和慢速迭代周期，对人类开发者来说尚且耗时，对 AI 代理而言几乎是不可逾越的障碍。代理无法“阅读文档”或“理解仪表板”，它需要紧凑的反馈循环和程序化控制：创建沙箱 → 运行代码 → 检查输出 → 调试并重试。传统基础设施无法满足这种需求。
Modal 的方向：从 DevEx 到 AgentEx
Modal 最初以“函数即服务”模式为 GPU 工作负载提供底层基础设施，其核心创新是装饰器（decorator）式自配置。开发者在 Python 代码中通过 @app.function(gpu="A100") 这样的装饰器即可指定硬件需求，硬件配置与代码共置，无需单独编写 YAML 文件。这种模式天然对代理友好：代理只需修改几行装饰器就能实时调整配置，不必理解复杂的 YAML 语法。Modal 的 SDK 团队已将目标从“开发者体验”（DevEx）转向“代理体验”（AgentEx），因为像 Claude Code、Codex 这样的 AI 代理同样需要简洁、可读的配置接口。
随着代理编写代码成为常态，Modal 正从“函数即服务”向更丰富的 AI 原语扩展：弹性推理、GPU 快照、后台代理、多节点训练等。目前 Modal 已在 17 个云提供商之间构建了容量池，支持突发性弹性 GPU 分配和 serverless 模式，以匹配代理的快速迭代需求。例如，强化学习的 rollout 阶段可能需要一次性启动 10 万个沙箱，每个沙箱都是隔离环境，快速创建、运行、检查并销毁。
代理时代的可观测性：比阅读代码更重要
当代码由代理生成或变为黑箱时，可观测性（observability）成为人类理解系统行为的唯一窗口。用户不再直接阅读代码，而是依赖仪表盘（dashboard）和命令行（CLI）输出进行调试和决策。Modal 将大量观测数据推向 CLI，让代理也能自主排查问题。这意味着基础设施平台需要提供结构化的 API 返回、完善的日志和监控能力，而非仅仅面向人类的 UI。
影响与启示
- 基础设施架构需要重新设计：平台必须提供代理可编程调用的 API、沙箱和可观测性工具，而非仅面向人类。装饰器、代码内嵌配置等低认知成本接口将取代复杂 YAML 编排。
- 弹性 GPU 资源成为刚需：AI 工作负载的突发性和计算密集性要求云厂商支持 serverless 模式与弹性扩缩容，传统 Web 应用模型不适用。
- 可观测性是关键投资方向：当代码不可见或由代理生成时，完善的监控、日志和 CLI 能力成为基础设施平台竞争的核心价值。
- 对于从事 AI 应用落地的团队：Modal 的“代理云”模式（从 DevEx 到 AgentEx）可能成为行业趋势，推动云平台向 AI 原生工作负载迁移。
关键要点
- Kubernetes 的复杂性和慢速迭代不适合 AI 代理，代理需要沙箱、快速反馈和程序化控制。
- Modal 通过装饰器模式将硬件配置与代码共置，降低代理的认知成本，并正从 DevEx 转向 AgentEx。
- 强化学习训练催生了对 10 万级沙箱的需求，弹性 GPU 和 serverless 是基础设施的必备能力。
- 在代理编写代码的时代，可观测性比阅读代码本身更重要，CLI 和 API 输出是调试的主要手段。
- 基础设施平台须为代理设计低门槛、可编程的交互界面，而非仅面向人类开发者。
早期模型经过约十次迭代就会发散失效，收集失败案例并构建强化学习环境能大幅改进。Modal 在 2023 年 5 月就推出了 sandboxes API 用于 Agent 自我迭代，但直到近一年后才迎来爆发——基础设施需求往往领先于模型能力成熟度。当前弹性推理（elastic inference）是 Modal 最大的用例，服务对象以音频、视频、机器人及计算生物等自定义模型公司为主，而非通用大语言模型。
关键判断
模型早期迭代的瓶颈与突破
早期模型缺乏针对循环、自校正和后训练优化的能力。经过大约十次迭代就会发散失效，但通过收集失败案例并构建强化学习环境，可以大幅改进模型性能。这表明，模型的自迭代能力并非天生，而是需要精心设计的反馈环路和训练策略。
基础设施需求超前于模型能力
Modal 在 2023 年 5 月便推出了 sandboxes API，用于支持 Agent 的自我迭代。然而，直到近一年后才迎来大规模使用。这说明，基础设施层面的能力往往要先于模型本身的成熟度构建起来，开发者需要提前布局，才能在新能力落地时快速响应。
弹性推理成为主要用例
Modal 当前最大的用例是弹性推理（elastic inference），主要服务于自定义模型公司，例如：
- 音频生成（如 Suno）
- 视频生成（如 Runway）
- 机器人
- 计算生物学
这些公司并非使用通用大语言模型，而是运行自己的定制模型。它们的流量模式具有明显的日间波动和发布促销等突发峰值，并且需要跨区域部署多个模型。这使得自动扩缩容问题变得更加复杂——需要在特定区域内从千级 GPU 弹性扩缩至一千五百级。
影响
对开发者的影响
对于构建 Agent 或自定义模型的开发者来说，基础设施需要支持：
- 突发性计算：应对 RL 训练、批处理作业等瞬间高并发
- 跨区域弹性调度：在全球多个云区域间灵活分配 GPU 资源
- 沙箱化执行环境：安全隔离的代码运行空间，用于 Agent 的自迭代和测试
仅关注通用 LLM 推理已无法满足实际需求。
对云服务商和基础设施创业公司的市场机会
弹性推理与自迭代 Agent 的结合，将推动 GPU 资源管理平台向更细粒度的自动扩缩容和区域感知调度演进。这对云服务商和基础设施创业公司构成了明确的市场机会。
背景
Modal CTO Akshat Bubna 在对话中探讨了 AI 基础设施为 Agent 体验进行的演进，重点涉及自动扩缩容、GPU 快照技术以及 LLM 推理优化。对话涵盖了从传统批处理到强化学习 rollout 等多种突发性工作负载，并介绍了 Modal 在投机解码（DeFlash）和 Auto Endpoints 上的最新进展。
关键判断（续）
推理工作负载的突发性因场景而异
Agent 推理本身并不高度突发，但以下场景具有极强的突发性：
- 强化学习 rollout
- 训练前的编码任务
- 批处理作业（例如同时启动数十万个沙箱）
这些场景对基础设施的弹性扩缩提出了刚性需求。
GPU 快照与自动扩缩是差异化能力
Modal 通过 GPU 快照技术保存模型状态（如 torch.compile 后的模型），显著缩短冷启动时间。其自动扩缩能力在多家推理提供商中并不普遍，尤其在多区域场景下优势明显。
投机解码带来乘法级加速
DeFlash 是一种基于块的投机解码器。与传统的单令牌预测不同，它可以预测令牌块，从而获得 2-4 倍的推理速度提升，且不影响模型质量。
- 单纯的优化内核仅能获得百分点级改进
- 提高接受长度（accept length）是更具杠杆效应的手段
前沿性能的普惠化方向
Modal 推出 Auto Endpoints，通过影子流量自动优化，用户无需编写代码即可获得与专有提供商相当的前沿模型性能。同时，计划帮助用户训练定制投机器或自定义模型。
影响（续）
对推理服务提供者
需要针对强化学习、批处理等突发性工作负载设计弹性架构。单纯的快速推理引擎不足以应对瞬时段的高并发需求；投机解码等加速技术应作为标配而非可选项。
对模型开发者与使用者
可借助开源 DeFlash 等方案，在低成本下获得接近专有服务的推理性能，降低对专用推理系统的依赖。开发者应关注 Auto Endpoints 等抽象层，减少底层基础设施的运维负担。
对 Agent 应用生态
Agent 体验的优化不仅依赖模型本身，更需要基础设施在突发负载下具备自动扩缩与快速冷启动能力。这将成为 Agent 规模化落地的关键瓶颈之一。