AI基础设施为何必须为Agent体验进化——Modal CTO Akshat Bubna

是啊。

我们搞了不少艺术装置，看到我们的产品跟罗丹的作品一起摆在展台上，还挺好玩的。

我其实是通过一位投资人第一次见到 CEO Eric 的。当时 Eric 已经在思考构建一种新的 runtime，他之所以有这个想法，是因为他在想：为什么工作流编排产品这么难用？因为必须在 Kubernetes 上运行。Kubernetes 很难管理，它不是为突发性负载和自定义镜像设计的，开发者体验也很糟糕。

是啊，我们最初的想法是，如果我们构建一个更好的 runtime，它本身就是一个非常有用的基础组件。Serverless 函数能解决很多问题，比如做 ETL、任务队列、各种突发性处理，事实证明每家公司都有这类需求。但我们也把它看作一个基础组件，可以在上面构建一整套垂直化的产品。所以数据工程可能是第一个方向，但我们也在考虑推理。当时更多是传统的推理，比如计算机视觉、运行 XGBoost 之类的。不过我们在 ChatGPT 发布前一年就把 GPU 加进了产品。

我们当时没觉得这会是什么大事。

主要就是，当时现有的工具没有一个是为出色的开发者体验而设计的。而且我们看到的很多工作负载都有一个趋势——我希望有个更好的词——就是计算密集。它们需要更多资源，所以你得频繁地上下伸缩，而 Kubernetes 是为慢速伸缩和 Web 服务器场景设计的。另外，这些工作负载运行的环境也越来越专业化，有时需要加速器，有时需要不同类型的镜像。这是我们在很多公司都看到的一致现象，这应该就是下一步的方向。

对，就是那个自供给工作负载。

是啊，我们真的很喜欢那个术语，所以就借用了。

那非常重要，因为我们真的不想让人花那么多时间写 YAML。你可以把要做的事情浓缩到代码里，这样就能像操作其他代码一样操作它，构建更富表达力和动态性的东西。所以那一直是很重要的一部分。

我们其实没怎么收到过这种反对意见，因为 Modal 的好处是你可以带上任何已有的代码。当然，DSL 是用来配置你用的是什么硬件、怎么伸缩的，但代码还是你的。这在我们故事里一直很重要。即使现在我们做推理也是如此。

我们实际上已经调整了 SDK 团队，让他们思考 agent 体验（agent experience），而不是开发者体验。我们认为适用于开发者体验的那些好处，同样也适用于 agent 体验。为什么让 agent 去读几百个 Kubernetes 文件，写连类型都没有的 YAML？它只需要在装饰器里改几处，就能获得这种自供给 runtime，实时看到改动生效。从我们接触的客户来看，他们发现 Modal 对 agent 来说比在别的底层上操作快得多。

是啊，人们确实不看代码了。但我们发现有一件事仍然非常重要，就是可观测性。你的仪表盘好不好用？当然，我们把很多信息推到了 CLI 上，让 agent 自己去调查，但你还是需要人类去解读发生了什么，做判断之类的。我觉得这现在可能比看代码本身更重要。

Modal 是一个云平台，我们从零开始为 AI 应用构建了基础组件。目前它主要覆盖推理、训练、批处理和沙箱工作负载。但我们还在构建更多东西。

对，绝对有。我们没想跟 Render 这类公司竞争，因为我们的差异化在于那些需要专用计算、需要频繁上下伸缩的工作负载。它们的形态不一样。

对，没错。我觉得这又是经典案例。我们团队小，行动快。工程师直接跟客户合作，边做边摸索。

对，那是Peyton。我们派他过去，因为沟通延迟太高了。

对，你在Hacker News上火了，我们流量暴增。我觉得你用Small Developer的方式就是通过Modal函数来跑东西，那确实是个好用例。

对，他差一点就成功了。

但有趣的是，同一时间我们在跟一群需要沙盒功能的客户聊。那是2023年。

所以我们建了——

对。

我们在2023年5月就建了沙盒，那时候还没人知道这东西会火。我们发布的第一个例子就是把Small Developer放进一个循环里，让agent能自我迭代。循环现在很难搞，循环很难。

对，小雏形。大概是2023年中。

对，我不记得这个例子里有没有用工具调用，但模型在10次迭代后就会发散，产不出有意义的东西。

对，印钞机。

要有那种内在的信念，相信这些东西会变得这么好，确实很难。

说得对。

没错。

对，今天仍然需要。显然，工作负载形态变化很大。我们为大规模生产环境的客户跑东西，重点不是从0扩展到1，而是如何在一个区域内从1000个GPU快速弹性扩展到1500个。问题本质是一样的。

嗯，实际上我想退一步，聊聊人们现在怎么用Modal。我们最大的用例其实是弹性推理。我们最早找到产品市场契合点的是自定义模型的推理。所以我们当时避开了LLM领域，服务的是像Suno（音频）、Runway（视频）、机器人、计算生物学这类公司，它们在其他地方训练模型，但Modal是最好的黑盒，用于部署和根据流量模式弹性扩展到任意数量的GPU。我们发现它们都有非常不可预测的流量模式，比如昼夜波动，有些日子公司发布新产品，需求会暴增。而且它们部署的不只是一个模型，而是很多不同模型在不同区域。所以自动扩展问题变得更难，因为你得在特定区域内扩展，而这些周期是错开的。不同时间需要在不同区域扩展。

对，我们真正专精的是自动扩展这方面，因为我们发现并非所有提供商都能做到自动扩展。我们在技术层面做得更深，把GPU快照功能集成到了产品里。这样我们可以捕获GPU状态，比如你的Torch编译器模型，做快照，下次冷启动会快得多。所以回到你的问题，这就是为什么推理需要大量突发能力，但人们也会做很多按需训练。比如RL任务，你的rollout是突发性的，就像你说的。人们还会做很多批处理任务。很多公司在正式训练之前，需要数千个GPU来跑编码之类的工作。我觉得这些任务比agent更突发。agent没那么突发，沙盒也是，除非你在做RL。RL主要是突发性的。

对。做rollout时，有时需要10万个沙盒。

但这听起来像是你们会做的事情。正如你所说，我们很幸运能与许多前沿客户合作。Ngram 是我们的客户之一，他们正在利用我们提供的基础组件，尝试以非常有趣的方式使用它们，比如持续学习。随着技术不断进步，如果更多人需要这些功能，其中一部分也可能成为我们产品的一部分。但我们还在观望事态如何发展。

我想我们在 LLM 推理方面深入了很多，因为我们意识到我们在自动扩缩（auto scaling）方面的一些优势，尤其是在不同区域等场景下，是其他地方不具备的。而我们之前的短板在于，我们没有直接处理模型本身，它就像一个黑箱。后来我们意识到，通过拥有优秀的人才来研究这一切，我们实际上可以达到前沿水平的模型性能。而且我们最近开源了很多工作，比如我们分享了 DFlash 的工作，这是一种基于块的推测器（block-based speculator），我们已经全部开源了。所以通过使用开源的 DFlash，你可以获得与使用专有提供商相同的性能。接下来我们在考虑的是——

当然。简单总结一下，首先得解释清楚什么是推测解码。

再解释一遍也无妨，对吧？推测解码就是，你有一个较小的模型，称为草稿模型（draft model），它比大模型提前预测 token，然后大模型来验证所有这些预测的 token。它之所以更快，是因为如果你一次只预测一个 token，你会受到内存带宽的限制。但如果你能批量验证草稿模型的输出，那么计算效率会高得多，速度也更快。只要你的草稿模型能产生大量可被接受的 token（这被称为接受长度），你就能获得原始模型速度的数倍提升。这就是我们在这里强调的。很多人都在说我们让 kernel 更快了之类的，但优化 kernel 通常只能带来几个百分点的提升。而增加步长（step length）则能带来 2 到 4 倍的乘法级加速。没错，就是这样。

质量性能不会有下降，因为你永远不会接受一个过长的 token。

没错。所以我们一直在研究 DFlash，这是一种基于块的推测器。它不是一次预测一个 token，而是一次预测一个块。我们也在开源这方面的工作。接下来我们要做的，是帮助人们训练推测器和定制模型。传统上，这非常依赖 FDE（现场部署工程师），需要与客户合作并帮助他们完成。我们的愿景是——这也是我们推出 Auto Endpoints 的原因——我们希望让每个人都能获得前沿水平的性能。我们在公告中稍微透露了一下。接下来我们要推出的功能是：当你运行一个 AutoEndpoint 时，我们会进行流量镜像……你想解释一下什么是 AutoEndpoints 吗？好的。简单来说，这又回到了 Modal 的理念：你可以直接接触代码，但有时人们其实不想碰代码，他们只想用一个开箱即用、具备 Modal 所有优秀性能和可扩展性的端点。所以我们让这件事变得更简单了：通过 UI 或 CLI 创建一个端点，它已经内置了我们之前提到的所有优化，比如 DFlash 之类的东西。而且完全透明，我们会把代码给你，你可以自己运行。如果你愿意，还可以完全融入 Modal 的完整体验中——我们看到，随着用户越来越专业，他们确实想调整模型、进行微调。这些你仍然可以做到。它不是黑箱。另外，正如我们在文章后面透露的，下一步是：我们如何在此基础上为你提供更多价值，比如让你的草稿模型随着数据分布的变化而自动演进，而无需与任何人沟通？

这挺有意思的，因为我们采取的方式是开源我们的贡献并向上游提交。我们与 SG Lang 团队密切合作。我们实际上希望我们团队提出的改进能够出现在开源版本中，供其他人使用，即使不在 Modal 上。对我们的好处是，我们有一个拥有深厚专业知识的团队，如果你遇到某些问题，我们的团队可以优先帮你获得那样的性能。另外，使用这些端点，我们的弹性比任何人都强，就像你说的，你可以真正缩到零，真正应对突发流量。在实践中，这对人们来说比单纯找 GPU 并在上面跑模型代码重要得多。

这些权衡在表面上并不明显。对，不仅仅是这个。我认为运行生产级推理本身就是一个很难的基础设施问题。即使不考虑自动扩缩，还要控制尾延迟（tail latency），确保每个请求至少被投递一次等等。

我们想跟随用户的脚步，确保他们能获得一个所有组件都协同工作的平台。所以目前我们专注于模型生命周期和 agent 生命周期，也就是从数据准备到训练再到推理。此外，如果我想部署一个后台 agent，比如沙盒、持久化存储，以及其他很多东西。

是的，RampInspect 就是一个很好的后台 agent 例子，它之所以成功，是因为能够利用快照和快速扩缩容这类基础能力，让整个系统响应迅速、运行流畅。

是的。这其实也是我们看到的 Modal 的一个吸引人之处——我们构建了一个覆盖 17 家云服务商的计算资源池。所以我们非常擅长在全球各种云资源上运行。

我们没有自己的数据中心。我们只是运行在很多 NeoCloud 和裸金属服务商之上。

嗯，这是个好问题。部分原因是，我们把自己的差异化优势放在软件层，轻资产运营并专注于软件能让我们快速前进。到目前为止效果不错，因为有很多人在建数据中心，我们可以和他们有效合作，再次专注于让我们与众不同的东西。

实际上 Neo Cloud 比你想象的要多得多，它们的可靠性水平各不相同。所以我们投入了大量时间在之上构建自己的可靠性层。如果 GPU 掉线或发生什么情况，用户工作负载不会受到影响。这实际上让我们能利用比用户自己多得多的资源。

所以我想当你提到共置时，另一个有趣的事情是，我们看到有人来找我们，当他们想要非常特定位置的 CPU 或 GPU 时，比如他们想要——

没错，或者欧盟、美国、澳大利亚。

要么是数据本地化，要么是延迟。比如他们想在 Modal 中运行沙箱，希望它们彼此紧邻。

是的，完全正确。我们基本上就是把计算、存储和网络拿过来，在那层上构建人们需要的东西。我们看到一些有趣的网络需求正在出现。一个是人们实际上想要联网的沙箱。所以我们有——

对，实际上如果你想要 Docker Compose，我们的沙箱现在支持一种叫 sidecar 的东西。所以一个沙箱实际上是一个容器 pod，你可以在一个沙箱里运行多个容器。这也很有用，因为回到网络问题，人们想要对沙箱的出站网络有更多控制。比如他们可能想运行一个中间人代理来记录 RL 的日志，或者控制出站到某个域的方式，注入凭证。所以我们不得不自己构建了很多这类东西。但有时人们还希望跨多个节点的沙箱能互相通信，这是我们看到的一个新兴需求。我们出于不同的原因已经支持了这一点。嗯，我们看看它会不会稳定下来。

我们确实支持，你可以在沙箱内暴露一个隧道。然后你可以把它暴露给公共互联网，或者在上面加一个 HTTP 认证层。但我们还有一个叫 I6PN 的东西，我们还没聊过，这是一个使用 IPv6 地址的覆盖网络。所以如果 Modal 容器在同一个工作空间内，启用这个功能后，它们可以用这个私有 IPv6 地址互相寻址，其他人不行。这有点像容器的私有网络。我们构建它是因为我们的分布式训练产品需要这个基础能力。所以我们还有另一个功能，你可以给函数加一个装饰器，就能得到一个 GPU 集群，它们有 RDMA 网络。这样你就可以运行一个真正无服务器的分布式训练任务。我们为此做了覆盖网络。但后来我们看到人们出于其他原因在使用它，我很好奇人们会用它做什么。

这甚至不在我们的文档页面上。人们不知怎么找到了它，然后就在用。哈。

是的。不过严格来说，覆盖网络实际上是 TCP 覆盖网络。我们之所以需要它，是因为在之上建立 RDMA 网络之前，需要用 TCP 来做 RDMA 的密钥交换。但后来人们发现了 TCP 部分。

我觉得这很合理，因为——这就是云，对吧？是的。就像你移动 KV 缓存的方式，以及你能多高效地完成它，在强化学习中把权重从训练 GPU 转移到推理 GPU 的效率，这里面有很多自由度，本质上就是一个关于移动内存和调度的系统问题。

不太一样。算是相关领域？那就解释一下吧。当然，当然。

是的，有点像 VPN。对，WireGuard 是，嗯，你说得对。它确实是，嗯，你已经转到同一领域的类似话题了。WireGuard 是加密的，而这个不需要加密。

嗯，这是主要区别。这是 TCP，我们有 eBPF 程序，会根据你是否被允许连接来拒绝或允许 TCP 连接。

嗯，我猜你说的是完全分布式训练，比如 Dailoco 那种跨数据中心的。

当你在 Modal 上运行多节点训练时，RDMA，嗯，我觉得 Mellanox 或者 InfiniBand，也是一种 RDMA，但基本上它是一种绕过 TCP 网络栈、在节点之间更快传输数据的方式。我们内部网络大概是每秒 3 太比特，这是所需的标准。好的。

对。我们显然不是冲着大规模预训练去的。我们构建多节点训练的目标是，我们看到很多小规模的后训练场景，比如人们在对中等规模的 Qwen 模型做后训练，以提高推理质量。这非常适合那种场景。

是的，我们看到的另一个多节点训练用例是，即使你有一个大集群，你的研究人员仍然在做小规模运行，而弹性在那里更重要。

我们有一篇关于自动研究的博客文章，Modal 实际上很适合做这个。

实际上，我不知道有多少人真的在做这个。我也这么想。你会知道的。内部，训练和推理团队都经常用到这种通用模式。比如我们有一个内部仓库叫 AutoInference，基本上我们用这个框架自动化了 FDE 工作，代理会启动一系列不同的扫描。它甚至会运行 NVIDIA 的 Inside Profiler，调整配置，然后找到最优方案。它会更换你的 GPU，从 H200 换到 B200，效果确实很好。不错。

我们的 FDE 团队本质上就是应用推理研究员或应用训练研究员。

能够与客户有效沟通和互动很重要。他们都想要同样的东西。对，但这不完全是销售性质的事。我们会给他们搭配解决方案架构师，后者更偏向售前。

嗯。好吧，我看到人们用它做的事情完全不在架构层面。基本上就是调整参数，但这是由某种模型直觉引导的超参数扫描。所以它比其他任何扫描方式都高效得多。

对，它们实际上出奇地好。我觉得在 Cloud 4 之前，它们不行。但现在它们能直接一次性生成。我们正在考虑发布一个 Modal 基准测试，针对 LLM 还做不到的更难的任务。比如什么例子？我认为有时候代理在没有正确指导和技能的情况下，会难以使用我们其他的可观测性工具。比如，某个东西失败了，你怎么查看日志然后更新正确的内容？这需要一些推理。但它们能一次性完成，比如——

对，所以我们现在有一个模型技能，实际上这也是我们构建这个模型基准测试的原因之一。就是为了发现这类问题，然后在我们——对，你调整技能。

对。我们增长很快，这意味着我们必须更主动地做好容量规划。对。所以我们有——

嗯，我们有一个非常能干的团队，职位叫计算策略。所以如果有人正在听，或者想从事这方面的工作。

嗯，其实不止，这不只是财务规划与分析。这里面有很多有趣的财务问题，比如一年期和三年期预留的混合比例怎么定？我们如何预测自己的容量？尤其是我们的容量在不同GPU型号和不同区域之间具有很强的可替代性，基本上你得做大量建模，还得对供应链的演变有自己的判断，然后基于此下注。

是的，对我们来说，整个算力业务很大程度上也关乎出色的容量管理。这是实现良好单位经济性的关键，而且长期来看，也是为客户创造更多价值的方式。比如，我们正在开发的一个功能是，如果客户不关心延迟，他们可以获得更便宜的价格，结果在24小时内返回，本质上就是一个批处理层级。这些是我们能掌控的杠杆，因为我们控制着整个堆栈和调度等，可以给用户提供足够的——

我们看到这类需求其实并非来自大语言模型，尽管有时人们想在那里跑评估或做合成数据准备，这说得通。但更多来自非大语言模型公司，比如做计算生物学的，他们跑的是大型批处理任务，不关心什么时候拿到结果。

可以设定边界。你可以给用户提供预估时间。是的。

我们在构建能让用户生活更轻松的基元。比如，LM推理方面，成千上万的公司会进行后训练并部署开源模型做推理。所以我们正在思考最佳的产品形态。这涉及从我们的训练平台到能提供前沿性能的端点。同样，无需与人沟通，其他垂直领域的情况会有所不同。比如，我们也看到很多实时音视频需求，这就是为什么我们在开发带故障转移的区域路由。这样GPU可以尽可能靠近用户，实现视频流等低延迟。在agent方面，我们仍在与客户紧密合作，因为他们的需求变化太快。除了沙盒和持久化文件系统，人们在构建生产级agent时还需要很多其他东西。所以我们正在考虑这些其他组件。

嗯，我现在可能应该分享一下。

我对于在沙盒层面使用LLM中介的权限持怀疑态度，因为你确实需要硬边界。否则，显然有人可以窃取数据。

是的，我认为你总是需要硬护栏，同时可以搭配软护栏。那将是完全无中介的。

是的，我们很高兴与Anthropic以及其他一些基础实验室合作，不会透露我们还在和谁合作。我们认为，托管agent是开始构建agent的好起点。但当你构建更生产级的东西时，比如像Ramp这样的公司，他们也在我们这里运行自己的会计agent。对于面向外部的agent，你需要对计算基元有更多控制，比如如何处理agent能访问的不同文件，如何快照和恢复，如何控制网络。也许你需要GPU。到了那个阶段，你会想要一个专门的沙盒提供商来提供这些。这就是我们试图扮演的角色。我们对于框架本身没有偏好，不管它是在云托管agent中运行并连接到Modal沙盒，还是直接在Modal沙盒中运行框架。我们会看人们最终会如何选择。

你是指OpenPy和——

我个人没怎么玩过它们。用它们构建过agent。

这就是我们专注于基础设施层的原因。这是我们的相对优势所在，也是——

这确实是个激动人心的时期。我认为很大程度上是因为这些东西需要的规模太大了。

总的来说，很明显正在发生巨大的转变。有一件事对人们来说不那么明显，因为LLM推理被讨论得太多，而且我们也和很多做药物发现和计算生物学的公司合作，比如China Discovery World。那里可能会发生大事。我们还和很多机器人公司合作，他们实际上在积极部署机器人，并且取得了不错的成果。

我们的目标不仅仅是服务LLM和FaaS市场。

我们一直避免的一件事就是提供模型API，因为我认为提供模型API——其中一部分最终服务于一个非常业余的市场，粘性很低。而我们一直想为那些构建产品的公司服务，它们需要比单纯API更灵活的方案。

是的，实际上我们所有的示例都不是"启动这个模型，给你一个API token，用吧"。它们实际上都是代码。所以重点是，这只是一个示例，一个入门代码。但你可以随意调整。如果你是一家构建产品的公司，比如计算生物学之类的。

我认为存在一定的选择效应，很多想深入这个层次的公司可能正在构建更具差异化的东西。举个例子，在LM推理方面，最初我们和那些构建自己后训练框架的公司合作，或者RAMP早期在训练自己的tokenizer，并替换Llama中的tokenizer等等。我不是说那一定成功。更好的例子是Suno，因为Suno不用Modal做训练。

但他们用Modal做所有推理，因为他们有完全自定义的模型架构，这意味着他们必须在代码层面调整那些不是API的东西。这也很有意思。

这很有意思。实际上，我们有GPU沙盒，最近看到一些公司在做视频操作的agent——

是的，我之前没把它和视频制作联系起来。在我脑子里，这些东西更偏向编辑方向。

是的，我们团队的人和Gitpod团队聊过，他们技术上非常强。实际上，Modal对CI市场也非常看好，因为随着更多agent、编码agent的出现，它们会运行更多的CI，而那里的原语可以做得更好。

嗯，CI中有很多时间浪费在准备工件、依赖项之类的事情上。构建系统当然有帮助。但如果你有像内存快照和恢复这样的原语，能不能更高效地运行CI？哦，好吧。

没错。它需要同样的平台。

我感觉他们可能没在正确的时间进入正确的市场，因为我们其实也有点运气成分——比如那些用例正好爆发了，需要更像沙盒形态的东西。我的直觉是，嗯，就是这样。

对，区别在于运行时沙盒有不同的配置面，比如如何配置镜像、如何附加持久化存储等。确实很有意思。

嗯，我们最初把 Python 作为第一个 SDK 语言，因为那是人们做数据和机器学习用的语言。现在他们也有了 Go 和 TypeScript 的 SDK。我们的运行时完全与语言无关，是用 Rust 写的，但绝不绑定 Python。在推理和训练方面，人们仍然非常依赖 Python。有趣的是，在 agent 相关的东西上，人们用我们的 TypeScript SDK 更多，因为他们实际上不需要做任何涉及机器学习的事情。我认为我们短期内不需要超越这个范围，因为 Python 和 TypeScript 仍然占主导地位。

没错。就这些了。嗯，还有英语和提示词（prompting）。

这是我们身份的重要部分。不仅仅是战术层面的问题，比如 agent 如何使用 CLI，还包括启动新东西有多容易？比如你想快速上线一个新服务并投入生产，迭代时间是多少？实际上，这对人们来说很重要，我认为它会继续重要下去。

我其实还写过一篇关于这个的博客文章。

对，基本上对我们来说，主要变化是，正如我所说，我们构建了 Modal Bench 这个基准测试，用来观察 agent 的不足之处，然后直接在产品中增加相应的功能面。如果它们需要某个东西，也许那东西就该是一个 CLI。

有时候这很有道理。如果它们需要某个东西，那就是产品反馈，直接给它们。然后，实际上，我们以前只在 UI 里有日志和指标，现在也把这些都移到了 CLI 里。这样就能以那种形式访问了。就这么简单。

好的。