Akshat Bubna 是云平台 Modal 的 CTO。这期节目录于 Modal 宣布 C 轮融资之后，话题从 Kubernetes 的痛点一路聊到智能体沙箱、投机解码和「所有云之上的超级云」。以下为访谈全文整理。

我是通过一位投资人第一次认识 CEO Eric 的。那时候 Eric 就已经在思考构建一种新型的运行时，他是顺着这样的思路想通的：

这背后还有他在 Spotify 的那些经历。而 serverless 函数本身就是一个非常有用的原语：可以做 ETL、任务队列、各种突发性批处理——事实证明每家公司都有这方面的需求。同时我们也把它看作一个可以在上面构建一整套产品的原语，而且这些产品会非常垂直化。那时候的推理还比较「经典」，像计算机视觉、跑 XGBoost 之类的活儿。我们在 ChatGPT 出来的一年前就把 GPU 加进了产品，只是没想到它会变得这么了不起——就像顺手加了一百张 GPU 似的。

首先，当时市面上没有一款工具是真正为绝佳的开发者体验而打造的。另外还有一个普遍趋势：我们看到的大量负载都非常计算密集，需要多得多的资源、频繁地上下伸缩；而 Kubernetes 是为缓慢扩缩容设计的，更多面向 Web 服务器这类场景。还有一点，这些 worker 运行的环境越来越多样——有时需要加速器，有时需要不同类型的镜像。这是我们在很多公司身上看到的一致现象。

「自我供给（self-provisioning）的基础设施」这个说法也占了很大分量——那其实是主持人早年在 Temporal 工作时写过的一篇文章里的概念，我们真的很喜欢，就「借用」到了官网页面上。因为那个洞见在于：所有东西都可以直接放进装饰器里，和代码放在一起。

其实我们从来没有因为这一点真正被反驳过。因为 Modal 有个好处：你可以带上任何已有的代码，而 DSL 只是负责那部分配置的载体——你用什么硬件、怎么扩容，代码始终是你的。这样一来，你还能把正在做的事情的表面积压缩得很小、收进代码里，像操作其他代码一样去操作它，构建出更有表现力、更动态的东西。这一直都是我们故事里非常重要的一部分。

Modal 已经把 SDK 团队的工作方向，调整成去思考「智能体体验」了。在他们看来，开发者的痛和智能体的痛，是同一种痛。

我们其实已经把 SDK 团队调整成去思考 agent 体验，而不只是开发者体验。适用于 DX 的那些好处，同样适用于 AX。说白了——何必让一个 agent 去通读几百份 Kubernetes 文件、去写那种连类型都没有的 YAML？它明明只需要在装饰器上做几处改动，就能获得这种自我供给的运行时，实时看到自己的改动生效。

而且从我们接触过的客户来看，他们确实觉得对 agent 来说，用 Modal 比在另一种底座上操作要快得多。因为你可以把基础设施需求「定位」到运行它的那部分代码上。

还是有人在看代码的。有一件事我们至今仍觉得非常重要，那就是可观测性——你的 dashboard 到底好不好用。当然，我们把这些能力大量推到了 CLI 上，让 agent 可以自己去排查问题，但你仍然需要人去解读到底发生了什么、去做判断、拿主意。

你可以试着把代码当成一个黑盒，通过观察从它里面出来的可观测行为来理解它，然后直接提示 agent 去修改。从这个意义上说，可观测性也许比看代码本身更重要。

Modal 是一个云平台，它是从零开始为 AI 应用服务的，目前基本上覆盖推理、训练、批处理和 sandbox 负载，但它是为了构建更多的东西而生的。

我注意到你刚才没提 Web 服务器——那种常驻的、大规模 Kubernetes 的场景依然有它的位置。对，绝对有。我们并不想跟 Render 这类公司竞争，因为我们的差异化在于那些需要专用计算、需要大幅上下伸缩的工作流。

Modal 有很多东西都是跟创业公司们并肩做出来的——Cognition、头部科技公司、Ramp 等等，都是在跟我们一起创新，而这种事 AWS 是不会直接去做的。我们是小团队，可以跑得非常快，工程师会直接跟客户一起工作、一起摸索。甚至有位工程师就驻扎在 Cognition 里——因为沟通的延迟太高了，分布式嘛，你总得在那边安插一个节点。

差不多 2023 年，我们正在和一些需要 sandbox 之类能力的客户聊，紧接着就建了一个新的 API。我们 2023 年 5 月就做出了 sandbox，那时根本没人知道这会成为一件大事。我们发布的第一个示例，就是把 smol developer 放进一个循环里，让 agent 能自我迭代。

给听众们说明一下当时的问题：模型根本不是为这些事而设计的。它们没有经过后训练去理解循环、纠错这类东西；tool calling 当时已经有了，但也没那么好用。那些模型大概迭代十几次之后就开始发散，产不出任何有意义的东西。现在回头对三年前的自己说，答案就是：把所有的失败收集起来建一个 benchmark，再把案例收集起来构建一个 RL 环境。可在当时，你很难有那么一种发自内心的信念，相信这些东西会变得这么好。回过头来看，一切都太明显了。

一点没错，我们是那种价值被严重低估的产品。主持人自己也有一段亲身经历：三年前做 smol developer 的时候，需要一点突发性的算力，就试了 Modal——在一场黑客松上，有人特别坚持地说，我们想跑一个小模型，就是那种没有托管在别处的模型。有家特别酷的公司叫 Modal，它们能很快拉起一个 GPU sandbox，直接把模型扔上去，只要给一个 Hugging Face 的链接就行。即时的托管——把它拉起来、用完关掉、保持冷启动状态，几天后跑 demo 的时候它又自己活过来。所有这些，回过头来看，到今天依然就是我们需要的全部。

我们最大的用例其实是弹性推理。我们最初找到 product-market fit 的，是面向自研模型的推理服务——某种程度上，我们刻意避开了 LM 这个领域。我们服务的公司包括：做音频的 Suno、做视频的 Runway，还有机器人、计算生物领域的公司——它们都在别处训练自己的模型，但 Modal 是最好的「黑盒」，能在流量模式变化时，弹性扩缩容到你需要的任意数量的 GPU。

我们观察到，它们的流量模式非常难以预测，像昼夜节律一样有周期性。有些天，比如公司要发新品了，需要的算力会一下子大很多；而且它们部署的远不止一个模型——会在不同的区域部署很多不同的模型，这些周期又彼此错开，所以自动扩缩容的问题就更难了。我们真正专精的正是自动扩缩容这一块，而且技术上又往深走了一层：我们把 GPU 快照 做进了产品——比如你用 torch.compile 把模型编译好之后给它做个快照，下一次调用启动就会快得多。

负载形态也已经变了很多，因为我们服务的客户已经拥有了非常大规模的生产环境。在那种场景下，问题不再是能不能从 0 扩到 1，而是怎么真正做到弹性伸缩——一千张 GPU 在一个区域内非常快地扩到一万五千张。像 Cursor、Composer 这类产品，每隔几个小时就要对一个模型做一轮 RL；做 rollout 的时候，某些周期里可能就需要十万个 sandbox。agent 本身没那么突发，sandbox 才是突发性的——除非你在做 RL，做 RL 的时候就是特别突发。

至于持续学习的早期苗头——我们有幸跟许多前沿的客户和实验室合作，他们会拿我们提供的原语，尝试用出非常有创意的花样，比如持续学习。随着这些东西不断变好，如果更多人需要，其中一部分也可能会成为我们产品的一部分。我们只是在观望，看它会怎么发展。

投机解码是这样的：你有一个更小的模型，叫草稿模型（draft model），让它抢在大模型前面预测 token；然后让大模型去验证所有这些被预测出来的 token。它之所以更快，是因为：如果你一个一个地预测 token，你就会受限于内存带宽；但如果你能把草稿模型的验证过程批量化，那么你使用算力的效率就会高得多。

只要你的草稿模型能持续产出大量可以被接受的 token——这个量被称为「接受长度」（accept length）——你就能获得数倍于原始模型的速度提升。人们经常说「我们把 kernel 改得更快了」，但优化 kernel 只能带来几个百分点的提升，而提高接受长度带来的提升是好几倍的，而且几乎不影响性能——因为你永远不会接受一个本应更好或持平的 token，质量不会下降。

我们一直在 dFlash 上做大量工作，它是一个基于块的投机解码器——不是一次预测一个 token，而是预测一整块。我们也把所有代码都开源了：只要使用开源的 dFlash，你就能获得和那些闭源供应商一样的性能。

这又回到 Modal 的理念——你会去触碰代码，但有时候人们其实并不想碰代码，只想快速上手一个能直接工作的端点，并且拥有 Modal 所提供的全部性能与可扩展性。所以我们把这件事变得更容易了：可以通过 UI、通过 CLI 来创建一个端点，里面已经内置了我们聊到的所有优化，比如 dFlash 那一套，而且完全透明——我们会把代码给你，你可以自己去运行。如果你愿意，还能「跳出」到完整的 Modal 体验，因为我们看到随着用户越来越成熟，他们确实会想调优模型、想做微调。它不是黑盒。再往后，我们想的是如何在此基础上继续创造价值，比如让你拥有自己的草稿模型，让它随着你的数据分布一起演化——同样无需去跟人沟通。

至于增量：我们采取的做法是把贡献开源、回馈上游，我们和 SGLang 团队合作很紧密，希望自己团队做出的改进能沉淀到开源里。对我们的好处在于，我们有一支经验非常丰富的团队——如果你确实遇到了某些开源里还没有的东西，我们的团队能帮你先把那份性能拿到手。另一件事是，用这些端点时我们比任何人都更有弹性：你有真正的缩容到零，有真正的突发弹性。而且在实践中，这件事对人们的意义比「找到 GPU、把模型代码跑起来」更大。运行生产级推理本身就是一个很困难的底层问题——哪怕你把自动扩缩容这一层拿掉：要管控尾部延迟、要确保每个请求至少被投递一次，诸如此类。

我们显然不是冲着大规模预训练去的。我们之所以构建 Modal Training，是因为看到大量较小规模的后训练需求：人们在微调中等规模的开源模型，以获得更高的质量和推理性能。这对我们来说是一个绝佳的契合点。另外一个用例是：即使你已经有了一个大集群，你的研究员们仍然要做很多小规模的运行——而在弹性这方面，重要程度要大得多。这其实也是当前自动研究（auto-research）真正的限制因素：你基本上得给你的模型一些 GPU。

我们的训练团队和推理团队，其实都大量采用了这种方案的大致形态。比如我们内部有一套叫 Auto Inference 的东西——本质上是用这个 harness 把我们自己的 FDE（驻场交付工程师）工作自动化了：智能体会自己拉起一批不同配置的扫描，它甚至会在内部运行 profiler 做剖析，然后调整配置，最终收敛到正确的结果；它还会帮你换 GPU，从 H200 换到 B200，而且效果真的很好。

我看到人们实际用它做的事情，根本还没到架构那一层，基本就是在调整参数。但它本质上是一种由某种「模型直觉」引导的超参数扫描，所以比你手头任何其他的扫参器都高效得多。至于 FDE——我们的 FDE 和其他公司的不太一样，他们本质上就像应用推理研究员或应用训练研究员，既要能动手构建，也要能和客户交谈、有效地互动，这一点非常重要。

部分原因在于，我们把差异化放在软件层；保持轻资产、专注于软件，能让我们跑得飞快。到目前为止效果很好，因为建数据中心的人太多了，我们能够与他们高效合作，同时也专注于我们真正独特的地方。

现实中的新型云比你想象的多得多，而且它们的可靠性参差不齐。正因为如此，我们投入了大量时间在其之上构建自己的可靠性层：比如某块 GPU 从总线上掉下来，或发生诸如此类的事，用户的工作负载不会受到影响。这其实也让我们能用到的容量，比你作为单个用户自己能用到的要多得多。现在大家都清楚我们处在哪一层——做所有云之上的超级云。

还有一个背景值得说：老黄今年 GTC 主题演讲里有个「推理拐点」——AI 工作负载里，过去大概可以说是 8:1（GPU 对 CPU），而现在更接近 1:1。智能体会大量阻塞在偏 CPU 的事情上，所以真正的瓶颈因素在 GPU 与 CPU 之间来回摇摆的频率比过去高得多——以前是全是 GPU、偶尔 CPU，现在几乎是持续地在两者间切换。那你必须把所有东西共置（co-locate），而这正是 Modal 吸引人的地方之一。我们也见过有人来找我们，就是因为他们想要位置非常明确的 CPU 或 GPU——固定在某个地方，比如就放在欧盟，要么是出于数据驻留，要么是出于延迟考虑。

我们基本上就是把计算、存储、网络拿过来，然后在那一层上，为用户需要的东西做构建。网络方面有几个方向正在冒出来。一个是，人们确实想要可以互相连通的沙箱——类似 Docker Compose 那种多容器的东西。实际上我们的沙箱现在支持一个叫 sidecar 的机制：一个沙箱本质上是一个容器组，你可以在沙箱里跑多个容器。这个功能有用的另一个原因是，人们希望对沙箱的出站网络有很强的控制：比如跑一个中间人代理来记录 RL 的日志，或者控制对某个域名的出站流量、注入凭据。这类东西我们很多都得自己构建。

再比如直接开一个 socket、类似 mTLS 的东西我们也支持：你可以在沙箱里暴露一条隧道，要么把隧道暴露到公网，要么让它保持私有，还可以在它上面再加一层入口/代理。还有一个东西叫 IPv6 overlay 网络——启用之后，同一工作区内的 Modal 容器之间，就可以用这种私有 IPv6 地址互相寻址，其他任何人都访问不到。我们做它，其实是因为分布式训练产品需要这个原语：给一个函数加上装饰器，就能得到一组已经组好网的 GPU 集群，跑一个真正 serverless 的分布式训练任务。那个 overlay 网络跑在 TCP 上，是搭 RDMA 之前用来做密钥交换的，但后来人们发现了 TCP 那一部分，出于其他原因在用它。

权限控制这块，我们写了 eBPF 程序，根据调用方是否有权限来决定拒绝还是放行 TCP 连接——过去这需要一整个 sidecar，但现在内核里就有 eBPF 了。而在 Modal 上跑多节点训练时，用的是 RDMA——可以把它理解为一种绕过 TCP 网络栈、在节点之间更快传输数据的方式。我们拥有大约 3Tbps 的内部网络，这正是所需的标准。在 RL 里面自由度非常多，它本质上就是一个系统问题：把内存搬来搬去，还有调度。

有，我们增长非常快，这意味着我们必须在容量规划上做得更好。我们有一支非常能干的团队，这个角色我们叫「算力策略」（Compute Strategy）。它涉及大量很有意思的财务问题：一年期预留和三年期预留怎么配比？怎么预测自己的容量需求？尤其是，我们的容量在不同 GPU 型号、不同区域之间具有很强的可替换性——你基本上得把这一大堆东西都建模出来，还必须对供应链会如何演变有自己的判断，然后你得去下注。

打个类比：航空公司与燃油——他们必须对燃油进行套期保值。很长一段时间里，西南航空因为做过一次堪称英雄式的燃油豪赌，相比其他所有公司都保持着超低的成本。整个算力生意在很大程度上，也取决于能否把容量管理做到极致：这正是我们拥有出色单位经济的原因；而长远来看，这也是给客户解锁更多价值的方式。

比如我们现在正在做的一件事，是给客户一种途径：如果他们不关心延迟，就能拿到便宜得多的价格，大约在 24 小时内拿回结果——本质上就是一个批处理档位。这些都是我们手里的杠杆，因为我们掌控着整个技术栈、调度等等。有趣的是，对这类方案需求更多的其实不是 LLM 公司，而是大量非 LLM 公司，比如做计算生物学的——他们往往不在乎什么时候拿回结果，时间预期比较宽松。

我们非常兴奋能与 Anthropic 以及另外一些基础实验室合作。在我们看来，托管式的 agent，如果你是从零开始构建一个 agent，是一个很好的起点。但当你进入构建更生产级的东西时——比如像 Ramp 这样的公司，一边在自建自己的产品，一边把它的会计 agent 跑在我们上面——你就需要对计算原语有更多的掌控：agent 能访问的不同文件该怎么持久化？快照和恢复怎么做？网络怎么控制？到那个阶段你可能还想要 GPU。总之到了那一步，你会想要一个能把这些都给你的专门的沙箱供应商——这正是我们努力扮演的角色。

我们对 harness 本身并没有立场——不管它是跑在一个托管的 agent 服务里，然后你把它接到 Modal Sandbox 上，还是你直接把 harness 跑在 Modal Sandbox 里面，我们拭目以待大家会怎么收敛。Ramp 的 Inspect 就是一个非常成功的后台智能体例子，因为他们能用上快照、快速扩缩容这些原语，从而让产品感觉响应非常快。至于那些在这之上再多加一层的 meta-harness——OpenPipe 是其中之一，Databricks 最近也推出了 OmniGen——我个人还没上手玩过。但只要它们能用更多的基础设施，一切都利好 Modal。

对于沙箱层面的事，我很怀疑由 LM 来做中介授权是否靠谱，因为你确实需要硬边界——否则显然会有人把训练数据导出去。但也许这是老派的想法，也许我们才是恐龙——也许 AI OS 或 LM OS 才是趋势，到那时候内核会真的是一个 LM。

我不相信那套，但我想看看自己哪里想错了，因为那才是非共识所在。我觉得你始终需要硬护栏，而由 LM 中介的授权只能带你走这么远——你可以把那些更软的护栏跟硬护栏搭配着用。

用现成预训练 LLM 的好处在于，Modal 已经在它们的训练数据里了，它们其实已经出奇地好——现在能开箱即用地一次性把东西写对。我们正在琢磨发布一个类似 Modal Bench 的东西，针对的是 LLM 目前还搞不定的更难的任务。有时候让它们卡住的是：如果没有正确的引导，它们就不知道怎么用我们其余的可观测能力——某个东西是怎么失败的？该怎么看日志，然后去更新对的地方？这需要一点推理判断。但给足引导后它们能一次搞定——你只要给它加一个 skill 就行。我们做 Modal Bench 的原因，就是为了找出这类问题，好让我们能在 skill 里把它们解决掉。

我们实际上真的会给产品增加新的接口面：如果 agent 想去够某个东西——比如「这里也许该有个 CLI」——它们常常会自己幻觉出不存在的功能。而且有时这说得通：如果它们伸手去够某个东西，那就是产品反馈，就把这东西给它们。还有，我们以前只把日志和指标放在 UI 里，现在也在把所有这些搬到 CLI，让 agent 能以那种方式访问。

至于 Replicate——不做模型 API，正是我们一直有意避开的一件事。因为提供模型 API，其中有一部分最终服务的会是一个很偏爱好者的市场，这种市场粘性低得多。我们一直想服务的是那些在构建产品的公司，它们需要更多灵活性，而不是一层 API 就够了。你当然可以给 Modal 套一层 API——Replicate 显然就是那个形态——但你可以把它包成一个功能更完整的后端，一个由你自己持有、自己运行的后端。

所以实际上，我们所有的示例都不是「把这个模型拉起来，给你个 API token，拿去用吧」，它们全都是代码——这是一份示例起步代码，但你可以随便怎么改。这里面有一点选择效应：很多真的想在这个层面往深里做的公司，很可能正在构建更有区分度的东西。更好的例子是 Suno：Suno 不用 Modal 做训练，但它的所有推理都跑在 Modal 上，因为它们有完全自定义的模型架构，这意味着它们必须下沉到代码层面，去调整那些不是 API 能覆盖的东西。

我们把 Python 作为第一个 SDK 语言，是因为人们做数据和 ML 时用的就是这门语言。我们现在也有 Go 和 TypeScript 的 SDK，而且我们的运行时是彻底语言无关的——底层是 Rust，绝不被 Python 绑定。我们的观察是：在推理和训练这些场景里，大家仍然非常 Python；而 agent 那边有意思的是，大家用我们的 TypeScript SDK 要多得多，因为他们实际上并不需要做任何涉及 ML 的事。

我觉得我们短期内不用再往更多语言扩展，因为 Python 和 TypeScript 仍然占主导——这可以说是世界上最后的两种语言。真正的最后两种，是英语和提示词。连 Bret Taylor 都说过「我们需要一门为 LM 而生的新语言」，可到现在还没人做出来。Python 和 TypeScript 拥有海量生态数据加成，但作为语言本身，它们也远不完美。

他们处在不太一样的市场——大致属于 CI/CD 市场——但技术上真的非常出色。我的感觉是，也许他们没在对的时间做对的市场，而我们算是运气好，正赶上 agent 用例真正起飞。一个关键差别：GitPod 的沙箱更像是 CI/CD 式的构建期沙箱，而 Modal 的沙箱是运行时沙箱。事实证明运行时沙箱更好——两者的差别在于，运行时沙箱有不同的配置面，比如你怎么配置镜像、怎么挂持久化存储。后来他们加入了 OpenAI，也许我们会看到 Owner 团队变成 Codex Cloud 之类的东西——我觉得那会非常强。

其实我们对 CI 市场非常看好，因为编码 agent 会越来越多，它们会跑多得多的 CI，而现在的 CI 浪费太多了。对 agent 而言，改进 CI 的最高优先级那个抓手是：CI 里有大量时间浪费在准备 artifacts、把环境拉起来、准备依赖这些东西上。但如果你有内存快照与恢复这样的原语，是不是就能把 CI 跑得更高效？本质上，这又是另一种按需计算——它需要的还是同一个平台。

很明显一场巨大的转变正在发生。有一件事我觉得人们不那么容易看到——因为 LM 推理被谈论得太多了——那就是我们合作了很多做药物发现和计算生物学的公司，在这些地方，大事很可能就要发生。我们还合作了很多机器人公司，他们真的把机器人放进了实际部署，并且拿到了不错的效果。我们的目标不是只服务 LLM-first 的市场——语音、生物、图像，我们两边都做。另外我们也看到很多实时音视频的东西进来，这正是我们在做带故障转移的区域路由这类功能的原因——拿到尽量靠近用户的 GPU，在视频流这类场景获得低延迟。

agent 这一侧，我们仍在和客户非常紧密地协作，因为他们的需求变化太快了。除了沙箱和持久化文件系统，人们在构建生产级 agent 时，还会从这个技术栈里需要很多别的东西。还有一个有意思的方向：xAI Grok 团队的 Ethan 做过一个预测——视频生成的下一层，不是更好的视频模型，而是一个更好的、能编排各类视频模型的模型或 agent。你可以从 Grok 生成 6 秒或 10 秒的视频，但你真正想要的是 6 分钟的视频，而普通的视频生成到不了那一步。我们最近也看到一些公司在用 GPU 沙箱做视频处理的 agent——给 agent 一个 ffmpeg，让它跑。Luma Agent 就是视频制作方向上的一种形态，不过它是单点式的。

至于有没有本地部署、物理隔离之类的版本——没有，我们一般只提供云。

这是我们身份认同里很大的一部分。这不只是战术层面的「agent 要怎么用 CLI」，也包括把一个东西跑起来有多容易：当你想拉一个新的服务、想在生产里把一个东西搞上线时，你的迭代时间是多少。在实践中这对人们来说非常重要，而且我觉得它会一直重要下去——大家构建东西只会更快，如果你给了他们快速完成、又没有额外负担的方式。

对我来说，争论点一直在于：为开发者体验而做的东西，和为 agent 体验而做的东西，会不会做出某些本质上非常不同的？它们俩就像余弦相似度高达 0.9 的那种东西。最主要的转变，是我们搞了 Modal Bench 这个基准来看 agent 缺在哪，然后真的给产品增加新的接口面、把日志和指标搬到 CLI。就这么简单。

这场对话最一致的线索，是 Modal 对「原语」的克制：不追逐每一个热点市场，把计算、存储、网络做成可组合的积木，然后看智能体们拿它搭出什么。2023 年 5 月那个没人看好的 sandbox API，如今成了 RL rollout 每天要拉起十万次的基础设施。也许再过几年回头看，今天关于 AX 的这些判断，也会「太明显」得让人不好意思提起。