Why AI Compute Comes in Rectangles — Erik Bernhardsson, Modal CEO

为什么AI计算呈现矩形形态 —— Erik Bernhardsson，Modal首席执行官 —— Latent Space

热烈欢迎Basil Chatha加入！他是我们来自AI工程领域前沿部署团队的新任联合主持人！我们将与他共同开启一档新节目，借此机会我们无法错过对Modal首席执行官Eric的采访，正值他们完成D轮融资的里程碑时刻！

两年前，我们曾与Erik Bernhardsson探讨过他对真正无服务器AI基础设施的愿景：开发者应能无需预置集群、预测负载或为闲置资源付费即可运行代码。随后CTO Akshat加入我们，介绍了Modal的基础设施原语和堆栈，以及如何提供这些原语和代理体验。

过去五个月发生了巨大变化。自他们完成50亿美元的C轮融资以来，Modal现在宣布其年化运行率已突破10亿美元，以160亿美元估值完成7.5亿美元的D轮融资，并已启动近30亿个沙盒。在这次对话中，Erik将与Vibhu一起解释支撑这一增长的基础设施和经济模型——以及为什么计算需求很少呈现购买合同中常见的矩形形态。

观看完整对话 → YouTube

GPU需求并非矩形

典型的容量合同会为客户提供固定数量的GPU，持续固定的时间段。将容量与时间绘制成图，会得到一个矩形。但实际工作负载的行为却截然不同：它们会在一天内不断增长、激增和下降。如果为峰值购买足够资源，就需要为闲置硬件付费；如果购买不足，又可能错失需求。

Erik将Modal的策略描述为一种持续时间转换：将数千名客户的资源需求汇聚到一起，在底层确保容量，让每个客户在需要时使用所需资源。聚合需求越平滑，这个资源池的利用率就越高。这与我们与SF Compute的Evan Conrad的对话相辅相成：Evan专注于使容量可交易；而Erik则专注于将容量以更小、更具弹性的切片形式使用。

这种策略也存在财务风险。如果供应商以当前价格锁定容量，而之后GPU价格下跌，就可能面临持有昂贵库存的风险。Erik表示他不认为会出现立即崩溃的情况，但认为在构建业务时，这种可能性仍然需要被考虑。跳转至GPU价格讨论 →

差点未能实现的沙盒

在Erik和联合创始人Akshat Bubna注意到语言模型可以生成代码，并且有人需要一个运行代码的地方后，Modal推出了沙盒功能。早期采用者数量有限，团队甚至曾讨论过关闭该产品。但随着代码代理、后台代理和强化学习的出现，新的需求应运而生。Erik表示，沙盒现在已占到Modal收入的三分之一，这是他在推出时未曾预料到的结果。

这种增长也改变了基础设施需要承担的任务。一个代理可能需要创建环境、运行代码、检查结果，并多次尝试。启动和恢复这些环境的延迟成为体验的一部分。在我们最近与Akshat的采访中，我们探讨了从开发者体验向代理体验的转变；在这里，Erik补充了产品和商业故事。跳转至沙盒讨论 →

快速启动是一项基础设施特性

弹性只有在容量能够快速到位的情况下才能发挥作用。Modal的无服务器GPU文章描述了实现这一目标的机制：可用GPU的缓冲池、自定义文件系统、进程检查点以及GPU内存快照。这些组件减少了将另一个模型副本上线所需的工作量。这是基础设施决策如何影响应用程序响应能力和成本的具体例证。

我们还讨论了Erik从Spotify推荐系统到Modal的职业路径，公司如何采购计算资源，NVIDIA的替代方案，前向部署工程师，以及为什么在Modal代码审查是可选的。跳转至工程文化部分→

节目备注

• Modal — Erik创立的人工智能基础设施平台。

• Erik的写作 — 他关于基础设施、市场和公司建设的论文。

• Modal的D轮融资公告 — 公司最新报告的增长和沙箱里程碑。

• Modal如何实现真正无服务器的GPU — 弹性推理背后的企业和扩展技术。

• Modal的资源求解器 — 它如何在价格和可用性变化时选择容量。

• 扩展至一百万个并发沙箱 — 沙箱扩展的工程实践。

• 我们对Erik的首次采访 — 最初的无服务器基础设施理论。

• 我们对Akshat Bubna的采访 — 代理的基础设施和开发者体验。

• 可编程数据中心 — Evan Conrad关于GPU交易和实物结算的讨论。

时间戳

• 0:00 Modal的功能

• 1:25 从Spotify到创建Modal

• 4:19 在生成式AI热潮之前创立

• 7:43 第一批客户和融资

• 10:00 为推理和自动扩展构建

• 13:21 Modal获取GPU容量的途径

• 15:39 租赁与拥有基础设施的对比

• 19:45 GPU价格下跌的风险

• 24:18 AI需求是否无限？

• 26:12 NVIDIA的替代方案

• 28:25 Modal可以从新云中学习的经验

• 30:26 GPU作为资产类别

• 31:55 Modal的产品：函数和沙箱

• 36:03 更小训练工作负载的案例

• 41:21 代理沙箱的变革

• 46:48 Anthropic与沙箱安全

• 49:29 使用代理测试安全

• 52:51 代理时代开发者体验

• 57:45 Modal前向部署工程师的职责

• 59:55 Modal的产品管理方法

• 1:03:29 可选代码审查与工程文化

• 1:05:56 云、本地部署和自带云

• 1:09:25 容量、融资与增长

• 1:13:07 团队扩展

• 1:17:28 Erik的推文：临时沙箱

• 1:18:31 矩形GPU合同的问题

• 1:21:20 推理服务提供商与模型构建者

• 1:23:25 模型下一步的改进方向

转录稿

从修订版自动转录；姓名和措辞可能存在错误。

0:00 感谢你加入，Eric Fern-Hartson来自Modal。你能稍微介绍一下你的公司，以及你是如何来到这里的吗？当然。最简单来说，我们构建的是AI基础设施。我们提供一个计算平台和存储平台，使像Dacagon、Suno、Runway、Cognition等许多客户能够构建AI应用。实际上这意味着大量推理任务、大量沙盒环境，有时是训练和微调，有时是批量作业和其他任务。我们基本上构建了一个软件SDK，让客户能够快速开发这些应用。我们管理底层的所有算力，让部署、扩展和生产环境运行变得更简单。你两年前在Light和Space的时候，很多事情已经发生了变化。那时候你们规模有多大？可以分享一些数据，现在相比如何？说实话我不记得当时的具体数据，但大概增长了至少50倍，包括收入和用户数量。是的，我实际上用它来做了一个个人项目。不错。是的，就是把2D图像转换成3D模型。是的，所以这里只是托管几个模型。你有什么反馈吗？说实话我非常喜欢。不错。是的，这就是为什么我选择它而不是其他竞争对手。很好。在你创立Modal之前，你在Spotify和better.com工作过，对吧？

1:30 没错。是的。你在Spotify的时候具体做什么？我在Spotify做了很多事情，但主要贡献是构建了一个音乐推荐系统。我大概在2008或2009年毕业后加入，花了七年时间在Spotify。大部分时间都是从零开始构建音乐推荐系统，组建了一个小团队，推出了许多功能，比如相关艺术家推荐和每周发现等。这期间涉及大量矩阵分解和计算密集型任务。可以说，后来Modal的很多理念正是源于在Spotify构建AI应用时意识到基础设施非常糟糕，必须找到更好的解决方案。因此，Modal的很多初衷其实是我在Spotify工作期间一直想要的工具。是的，Modal更像是从Spotify学到的经验衍生出来的，而better.com的贡献相对较少。better.com更像是一个插曲，公司经历比较复杂，我们单独聊过。我在better.com担任了五年CTO，技术团队从最初的2-3人扩展到400人。我学到了很多关于管理、团队建设、招聘的知识，也深入思考了开发者生产力和工具的重要性，做了更多全栈开发的工作。是的，之后我重新回到了我真正热爱的领域——基础设施、AI和机器学习。再次问一下，better.com当时是做什么的？做的是按揭贷款业务。明白了。你是怎么进入那家公司的？

3:00 我的意思是，我们不需要在这方面花太多时间。是的，没问题。比如这位扎克·弗兰克尔（Zach Frankel），当时我还不认识他，后来他把我招到Better公司担任首席技术官，当时公司只有10个人。你知道，出于某种原因，Vishal（公司创始人）是个非常有趣的人，非常聪明，虽然有点疯狂，但大多数时候都是以积极的方式。我们相处得非常好。所以，是的，我们从2015年开始构建这个项目，我在那家公司工作了五年，后来，出于某种原因，按揭贷款业务其实非常困难，疫情后利率迅速上涨，给公司带来了很多问题。但到那时我已经离开了。你是在2020年或2021年离开的？是的，大概是那个时候。所以，你是离开Better公司后才有了创立Model的想法，还是离开后才开始做的？很难说。我离开Better时有很多随机的想法，其实在那段时间，我其实不确定自己是否想创业。当时正值疫情期间，我差不多给两个孩子放了个长假。虽然我现在还有孩子，但当时他们大概两岁和四岁，所以我决定暂时放松一下，休了段时间假，做些兼职工作，比如在某些项目上进行开发，也不确定是否应该做些咨询工作，后来我开始构建一些东西。当时我突然对这个最终成为Model的想法非常兴奋。不过实际上，Model这个想法，我记得我之前尝试过30次左右，但之前几次都失败了，没有成功。

4:30 但我的模型最初的构想是，这还挺酷的。我觉得应该这么做，这可能成为一个非常酷的平台。其他想法也是类似的开发者工具方向吗？第一个想法是某种网络爬虫相关的东西，后来没有进展。不过现在回想起来，也许其实是有机会的。这个想法是在Chat GBT发布之前吗？是的，2021年。哦，明白了。Chat GBT是在2022年底发布的，对吧？那我开始构建项目的时候，可能需要稍微回顾一下背景。在我任职Spotify期间，我发布了一个开源框架Kaluigi，用于工作流编排。这个领域与Airflow和Pre-effect Index等工具属于同类，但这些工具现在已经不太被讨论了。不过在一段时间内，Kaluigi曾获得过不少关注。不过我从未将其转化为商业项目。几年后，也就是2021年，当我思考商业构想或需要投入精力的项目时，我重新回到了工作流编排领域。我开始尝试一些想法，比如在云端运行代码的基础编排。后来我意识到，归根结底，核心问题不仅仅是编排计算机，而是执行计算机。我意识到这实际上是一个更大的问题。因此，我暂时将这个想法搁置，决定转向其他方向，打算之后再回来处理工作流调度的问题。但最终我再也没有回到这个方向，而是创建了Modal，这个项目的重点是：想办法让在计算机和云端运行代码变得简单。最初这个项目的定位是相对通用的。

6:00 从某种意义上说，我们最近似乎又回到了原点，但在此之前我们尝试了各种不同的应用场景。当时的核心理念是：让代码在云端运行变得极其简单。无论是GPU代码、人工智能还是机器学习，甚至是数据处理相关的内容，我们都在探索如何实现规模化扩展，如何打造令人惊叹的开发者体验。我们很早就意识到，要实现这些目标，必须深入技术栈底层，构建了文件系统、容器运行时，并解决了许多复杂的工程难题。你提到的聊天机器人和CPT其实并不是我们的杀手级应用。不过，如果你还记得，那段时间还出现了另一个重要产品——Stable Diffusion，它最终成为了我们当时所构建技术的杀手级应用。当时我们团队只有四到五个人，开始有大量用户来找我们，希望运行Stable Diffusion模型。这让我们意识到，生成式AI推理可能是一个非常理想的用例。你是如何发现这个机会的？我其实是个 compulsive tweeter（ compulsive 是形容词，表示“无法控制的”）。现在我甚至更忙于创业，但过去我经常在推特上发帖。我也会写很多博客，因此积累了一些关注者。在早期阶段，推动增长的主要因素就是我不断在社交媒体上分享模型信息和产品动态，激发大家的兴趣，同时撰写长篇博客讨论云计算的未来方向。我称之为“创始人主导的营销”。我一直觉得，你必须发挥自己的优势，而我的优势就是喜欢在社交媒体上分享内容，保持高度在线。

7:30 说到底，我的优势就是喜欢发帖和保持高度在线。因此，我们的发展很大程度上得益于在社交媒体上的活跃度和频繁的在线互动。你们什么时候迎来第一个客户？这个过程花了很长时间。你们早期有融资吗？我们一开始并没有立即融资，我甚至在招聘前几轮员工时都是自筹资金。这在某种程度上是件好事，因为这让我们非常注重资金使用效率，关注投资回报率。很长一段时间我都没有给自己发工资，但后来这变得有问题，因为我们需要资金。直到2022年初我们才完成种子轮融资。那时我已经投入这个项目大约一年时间。Akshah在大约五年前，也就是2021年8月左右加入公司担任CTO和联合创始人。但直到2022年底我们才看到任何有意义的收入。我想这就是我为你感到骄傲的原因。是的。在我们这里，Stable Diffusion就是那个关键因素。我们从每月100美元的收入开始，2022年11月之后，下一个月就达到了每月2000美元。到了2023年1月，突然增长到每月3万美元。终于，我感觉那种巨大的焦虑感减轻了，心想：也许我们真的找到了正确方向。2023年我们发展得非常迅速。

9:00 我想从那时起，我们基本上增长得非常快。那个每月3万的时刻，是仅仅因为几个大客户，还是客户群体非常多样化？其实只有一个客户。我不确定我是否曾经提过这个客户是谁，甚至他们是否知道这件事，但我想他们可能已经有所察觉。那是一家位于纽约的公司，叫Mage，他们主要做稳定扩散相关的业务。我记得在2023年第一季度的时候，他们大概贡献了我们80%到90%的收入。但之后，我们的收入来源开始逐渐变得多样化。到了2023年底，我们又迎来了一家大客户，他们也曾一度成为我们收入的重要组成部分。不过随着时间推移，我们现在实际上已经有了非常良好的收入多样化结构。对于稳定扩散相关的产品，我记得当时很多人用它来运行Comfy UI。我猜很多人当时都在使用Comfy UI，通过它来执行工作流。确实有些人这么做了，但我觉得那些真正使用模型的人，往往更倾向于处理底层的复杂任务。他们喜欢模型的一个原因就是模型一直都很易于定制。他们通常会通过适配器、自定义推理和大量优化来部署自己的定制工作流，而我们之前为了提升开发者体验所做的所有优化，最终也证明非常适合运行生产环境的工作负载。因为自动扩展实际上是一个非常类似的问题——你希望快速地上下扩展容器。所以在早期阶段，我们恰好处于一个非常有利的位置，能够承接很多这类工作负载。当时自动扩展的工具还不存在吗？为什么你们需要自己构建这些工具？

10:30 一般来说，就像我的论文所讨论的那样，每当出现新的技术时代，总会遇到工具层面的限制。无论是回顾过去，比如网页、云计算、移动设备、个人电脑，还是人工智能等，情况都是如此。我认为，工具虽然存在，但往往并不足够优秀。很多时候，我们需要重新思考这些工具，才能真正发挥新技术的优势，推动进入新的世界。在云计算领域，我们看到了这一点，比如必须发明Kubernetes和Docker等技术。同样地，对于生成式AI，虽然可以基于前一代工具（如Kubernetes和Docker）构建，但这些技术原本是为完全不同的工作负载设计的。它们适用于稳定的后端任务，请求量相对平稳，CPU利用率通常较低，而CPU成本本身也不高，因此人们不太关注成本。但现在我们进入了一个全新的世界，需要管理昂贵的GPU资源，优化容量和利用率。同时，还需要将巨大的模型通过网络加载到CPU和GPU中。结果发现，很多现有工具根本无法应对这些需求。因此，我们意识到必须重新构建许多底层技术。除了提到的文件系统，过去几年我们还投入大量时间开发了一些非常酷的CPU相关技术。

12:00 快照、GPU快照和审计，我们在自动扩展器和调度器上构建了各种容量管理工具。我们觉得必须这样做，因为无法在旧系统上构建新一代软件，也无法通过包装旧系统来实现新功能，必须从头开始重新设计。所以自动扩展方面，你们在平台上是否观察到任何异常行为？在扩展过程中是否出现过系统故障？容量管理一直是个挑战，如何获取成千上万块GPU？这始终是个难题。我们很早就采用了多区域部署，这在事后看来是个关键决策，虽然当时需要咬牙硬上，但最终成功构建了系统。我们始终将容量管理视为一个全球统一的资源池，而不是每个区域独立运行的集群。这种思维方式是我们早期做出的重要决策之一。我不确定是否出现过具体问题，当然我们经历过故障和停机，虽然我非常希望模型能实现100%的可用性，但最近我们已经达到了四个或五个九的可靠性水平。在模型发展过程中，当然也遇到过扩展瓶颈。GPU市场以及更早之前，你们是否也采购了一些基础设施？不，让我们谈谈云容量。我认为云容量的获取方式已经发生了很大变化。最初几年，我们几乎全部依赖超大规模云服务商的Spot实例和按需实例，主要使用Spot实例，最初主要使用AWS，后来也用GCP，随着时间推移逐渐扩展到其他云服务商。我们很早就开始从Oracle租用部分容量，因为需要大量80和800系列GPU，而Oracle提供了非常优惠的价格。后来我们又增加了几个云服务商，通过预留实例进行采购，但直到去年年底，我们的大部分容量仍然来自Spot实例或一年期预留实例。Spot实例就是即时租赁，对吧？没错，而且它们是预占实例，我们必须处理这种特性。不过在Agria系统中，这种模式通过聚合数百个区域的容量可以很好地运作。这种模式一直有效，直到我们再次需要扩展。首先，Modal的快速增长需要更多容量，同时云计算市场本身也发生了巨大变化。过去一年，为了获取所需容量，我们必须与更多云服务商合作，目前我们已经与25个云服务商建立了合作关系。在很多情况下，为了获得所需的容量，我们必须签订三年以上的长期协议，并且需要预先支付大量费用，同时锁定三年期的价格。

15:00 所以，你知道，我们需要花整整过去六个月到九个月的时间，重新思考如何获取计算资源。我们必须建立一个完整的采购部门，目前有四个人全职工作，他们所做的就是采购资源，联系Neoclouds，进行谈判，验证资源的可用性。我们还不得不组建一个专门的工程团队，目前有10个人负责管理全球各地的裸金属计算资源，处理网络问题、硬盘故障、GPU脱落等各种问题。我们目前并不拥有这些资源，而是全部通过租赁方式获取，通常签订三年期的合同。这是一个重大决策，我们是应该购买还是继续租赁？实际上，我对这个问题并没有特别强烈的立场。我认为租赁的好处在于资本效率较高。如果你选择购买，首先就会面临运营复杂性，比如需要与供应商、电力、线缆等打交道。但购买也伴随着财务复杂性，比如如何融资？你可以通过股权融资，比如筹集十亿美元购买硬件，但这会大幅稀释股权。你也可以通过债务融资，但通常需要有长期稳定的收入来支付利息，这同样不简单。我们评估经济性、运营复杂性和风险，这是一个复杂的权衡，我们对购买持开放态度。我们可能会采取其他方式，比如为2027年所需的资源，需要投入大量工作，通过各种途径锁定资源。你是否需要雇佣大量财务人员来处理这些事情？确实如此，我花了很多时间在这件事上，团队也投入了大量时间。我认为随着时间推移，这些硬件资产成本非常高昂，令人震惊。你开始看到AI投资占美国GDP的比例达到数个百分点，同时美国的利率在最近几周大幅上升。目前，Neoclouds这类公司已经展现出非常复杂的金融工程能力，所以我们也在研究所有选项，可能需要采取类似措施。但我不希望这样做，我更希望专注于成为一家精简的软件公司，专注于我们擅长的领域。我认为一般来说，软件公司拥有实体资产并不是明智的选择。就像你是否应该拥有自己的办公室？我认为对大多数公司来说，这并不是最佳解决方案。但当然，为了获得所需的资源，所有选项都可能被考虑。是的，我认为供应短缺的情况还会持续一段时间。

18:00 所以你某种程度上必须这么做。比如，你同意这个观点吗？还是认为这只是一个短暂的时刻？我并不完全认同这个说法。比如，Nvidia 每月都在交付数以万计的黑色显卡，对吧？虽然我不认为市场是100%高效的，但一般来说，如果你愿意支付高价，就可以获得GPU算力。比如，如果你愿意比所有人都出更高的价格，当然，Anthropic 和 OpenAI 正在尽可能多地采购。但从根本上说，市场上始终有新的供应不断出现。因此，我不认为这是一种被完全垄断的资源。价格确实在上涨，我认为这确实值得反思。硬件的常态就像重力一样，价格最终总会下降。所以我们现在处于一个有点奇怪的时期，硬件价格反而在上涨。很难说这种情况会持续多久，可能是再六个月，也可能是再三年。真的很难判断。但从根本上说，我不确定是否应该认为，为了获得算力就必须立即购买，这有点像是疫情时期厕纸短缺的那种情况。对吧？至少这种银行挤兑式的恐慌情况不会持续太久。但话又说回来，算力紧张的情况还会持续一段时间，价格也在上涨。幸运的是，我认为这对我们来说未必是坏事。如果价格上涨，因为稀缺性也意味着……

19:30 向客户收取更多费用。而且，我们目前有很多预订以固定价格锁定，这意味着在某种程度上，我们实际上已经以长期GPU价格的形式获得了收益。因此，我并不太担心价格上涨的问题。我更担心的是价格暴跌。我认为这种情况短期内不会发生，但如果是真的，对市场上的许多玩家来说都会是相当糟糕的事情。为什么会这样？我认为这对那些大量锁定供应的玩家来说尤其不利。是的，因为他们支付了过高的价格，而且确实支付了太多，存在在高点买入的风险。不过，我对此并不太担心，我认为这种情况短期内不会发生。但正如我所说，从长远来看，硬件价格通常会下降，因此值得对此进行反思。目前，我认为你的产能受到限制，这在经济术语中会产生稀缺租金。谁获得了这种稀缺租金？我认为主要流向两个地方，主要是NVIDIA，当然也包括Neoclouds等公司。一般来说，任何拥有产能的公司都能获得更好的经济回报。这在产能受限的今天是毋庸置疑的。但从长期来看，我认为这未必完全成立。长期来看，虽然拥有GPU总会有一些溢价空间，但是否值得承担这种风险？你知道，持有这些昂贵资产的风险是否值得？我不确定，但我们会看到，这可能需要几年时间才能解决。长远来看，我们可能会拥有部分产能，也可能租用部分，或许是两者的结合，甚至可能尝试一些疯狂的方案，比如联合导师计划，谁知道呢？也许还会涉及一些复杂的SPD方案，一切都有可能。

21:00 如何与OpenAI和Enthropping竞争，以及如何购买GPU产能？我认为他们肯定会想要买下所有可用的资源，他们确实如此。你看到的现状是，价格在上涨，这是否反映了这一趋势？话说回来，NVIDIA正在大量出货。我认为在某种程度上，NVIDIA也倾向于适度的多样化。他们不希望出现少量大买家垄断市场的情况，就像你看到的超大规模云服务商受到产能限制一样。我认为NVIDIA更希望看到Neoclouds和其他替代云服务商获得更多分配。我们看到的市场情况也存在一些投机因素，但我觉得我们看到的是，那些稍微风险较高但更灵活的小型云服务商，反而可能给我们带来机会。例如，也许NVIDIA、Enthropping和OpenAI更倾向于从那些能够提供大规模训练块的供应商那里采购。因为他们的训练需求很大，但市场上其实有很多可用产能，比如在亚美尼亚，你甚至可以租到32个节点。

22:30 在印尼你可以获得128个节点。你知道的，我们很喜欢这种类型的东西。这样我们就能在全球各地部署大量容量较小的节点，价格相当不错。是否基本上只要有人提供一定数量的GPU，你就只关心这个？有没有其他因素需要考虑，比如你是否在意可靠性？比如这些GPU是否存放在某个不太规范的仓库里？说实话，有时候确实如此。但至少我们有基本的规格表。当我们与供应商沟通时，第一步就是发送规格表。我们会说明需要多少IOPS，CPU性能至少要达到某个基准分数，比如通过测试的得分，还需要最低的南北向带宽、出站和入站流量等指标。我们确实有一份明确的要求清单。我们经常进行验收测试，比如先获取一个节点，长时间运行和测试，某种程度上这也需要一定的信任。有时我们会签署价值数千万美元的大额合同，而合作的供应商我们还不完全了解。随着时间推移，我们会逐步验证。我觉得在某种程度上，我们内部其实也有自己的性能评估标准。比如，我大概知道哪些供应商的表现更符合我们的预期，

24:00时，我们更倾向于与那些我们已经看到过、可靠性非常好的供应商进行额外交易。当然，可靠性只是其中一个方面，当遇到支持问题时，供应商的响应速度也很重要。我们提出的问题，他们是否能快速解决？如果系统出现故障，他们修复的速度有多快？你是否同意对智能的需求基本上是无限的？如果是这样，为什么不尽可能多地购买容量呢？如果购买过多，还可以转售给其他人。当资源稀缺时，人们很容易会说“尽可能多买”。但首先，如果我们今天购买了所有容量，实际上无法全部利用。虽然我们可以利用其中的大部分，但也可以将剩余部分转售给有需求的其他人。我认为挑战在于，当市场出现某些情况时，很多因素会同时发生。例如，价格下跌、利用率下降，以及转售容量的市场消失，这些可能在同一时间发生。我目前的策略是每天积极购买容量，并筹集资金用于采购，总体上我非常看好市场前景，但我也想指出存在尾部风险。当这些尾部风险发生时，情况可能会变得非常糟糕。部分原因可能在于，我年纪较大，经历过过去的市场波动，比如1999年我刚参加工作时经历了互联网泡沫危机，也经历过2008年金融危机。我希望创建一家能持续运营20到30年、甚至更长时间的公司。当然，我们现在确实可以大量采购容量，试图垄断市场。但你是否听说过“亨特兄弟”？他们在交易史上是一个传奇故事，他们试图垄断白银市场，但最终以惨败告终。我认为，试图垄断市场通常不是一个好主意。不过，我们总体上确实非常激进，但我们的采购计划是基于需求增长，并与明年年底的目标运行速度相匹配。你只购买NVIDIA的设备吗？还是也在考虑其他公司的计算能力，比如用于训练的设备？我认为替代加速器正在变得非常有趣。讽刺的是，过去五年甚至十年里，我每年都预测“明年将是非NVIDIA加速器的崛起之年”，但每次都错了。不过，我认为2027年可能是非NVIDIA加速器的转折点，我们拭目以待。最后，这些替代加速器在某些方面表现确实非常出色。例如，TPU在谷歌内部被广泛用于各种用途，效果非常好。我对训练方面的了解不多，但我知道团队非常专业，他们正在开发大量软件工具。

27:00 你知道，硬件在某些方面确实很难。比如软件相对来说更容易一些。这让我觉得，如果我们只是修复这些加速器的软件层，我认为它们将会有很高的需求。从根本上说，由于NVIDIA已经成为一个瓶颈，我认为我们很可能会看到更多替代的加速器。不过话说回来，管道更下游的地方其实也有瓶颈。比如台积电（TSMC）和阿斯麦（ASML），这些可能才是更深层的瓶颈。但长期来看，我认为垄断并不总是能持续下去。因此，我认为市场拥有更多替代方案会更健康。虽然我非常喜欢NVIDIA，但必须明确说明，他们显然是一家非常优秀的公司，产品也非常出色。我也预计市场上会出现更多样化的选择。此外，像Cerebras和Grock这样的公司也在推动一些有趣的发展。你对这些供应商有什么看法？我认为它们非常令人兴奋。你确实能看到它们在某些工作负载上表现得非常好。还有一些有趣的人正在尝试混合式、解耦的推理方案，比如用NVIDIA处理预填充（pre-fill），用Cerebras处理解码（decode）等。哦，我之前还真没听说过这种方案。对，Grock也是如此。因为很多任务中，有些是计算密集型的，有些是内存密集型的。因此你可以灵活地进行组合搭配。我认为这非常令人兴奋。但当你在实际部署这些方案时，事情会变得非常复杂。不过我认为，这些更复杂的硬件架构中存在大量机会。从一些Neoclouds（比如Nebius之类的）那里，你有没有学到什么经验？比如它们的运作方式与其他方式相比，有什么不同？

28:30 你觉得你正在做的事情如何？我认为Neoclouds非常有趣的一点在于，他们是如何实现如此快速的扩张？实际上最疯狂的例子是N scale，他们从几乎没有任何产能的状态，迅速发展到拥有数百亿美元订单的规模。Neoclouds是如何实现如此快速的增长？我认为关键在于，他们能够找到一些大型买家，比如像enthropic这样的公司，然后对这些买家说：“你们是否愿意购买五年期的芯片？请签署这份合同，我们会给你们一个优惠的价格。”然后他们拿着这份合同去华尔街融资，告诉投资者：“我们已经获得了一个大客户，他们承诺采购价值100亿美元的芯片，我们只需要现在监督项目进展。”接着他们向Super Micro和DAL等供应商采购硬件并完成部署，最终将产品交付给客户。这种商业模式非常巧妙，允许企业提前预售尚未实际采购的商品，从而实现指数级的快速扩张。这就是我们看到的Neoclouds模式，他们能够实现非常迅速的规模扩张。我认为Modal在财务层面实现这种快速扩张更具挑战性，因为我们一直更注重以产品驱动增长（PLG）的模式，而不是像Neoclouds那样能够锁定长期合同。不过从长远来看，我相信我们最终也会达到类似的规模。

30:00 这个观点其实是一样的。但我觉得通过这些 Neoclouds，尤其是 CoreWeave 这些大型云服务商的实践，确实非常有趣。他们在融资方式上非常老练，比如如何将 GPU 作为贷款担保品等。我想问的是，像某家金融机构（我忘了具体是哪家）曾提出要将 GPU 转化为资产类别，这是否仅仅是因为他们需要融资，正在探索资金来源？这背后有什么意义？我指的是，现在有很多初创公司正在尝试类似的事情，比如 Silicon Data、Computer Exchange、Orn 等，他们试图建立价格指数、交易衍生品等。我认为这很有趣。计算作为一种资产类别确实存在诸多挑战，比如它不像其他资产类别那样具有同质性。不同的网络环境、地理位置、存储设备、CPU 性能以及可靠性等因素都会产生差异。当然，我们也可以对石油进行类似处理，通过标准化将其转化为可交易资产。至于计算资产是否能实现这一点，还有待观察。我认为在当前 AI 领域数据中心和 GPU 部署规模的背景下，我们需要在风险对冲和风险分担机制上更加成熟，

31:30 拥有更多类似保险之类的保障措施。我很高兴看到人们正在深入思考这些问题。不过话说回来，我不确定未来是否能看到GPU逐渐变成像亨利枢纽或布伦特原油那样高度标准化、可交易的资产。我想把话题转向模态沙盒。在讨论这个之前，modal目前有哪些主要产品？显然核心产品是GPU，其次是模态沙盒。除此之外还有吗？我认为我们目前最重要的两个产品是模态函数和模态沙盒。模态函数是在2021年推出的，其核心理念是提供易于部署和扩展的无服务器函数，我们负责管理所有计算资源。这个产品在推理场景和GPU管理方面表现得非常出色。但事实上我们从未专门推出过独立的推理产品或GPU产品。我们从未将modal定位为类似Neocloud这样的平台，我认为如果过度向这个方向发展可能会存在风险，比如变成单纯的GPU租赁服务，比如提供类似三年期的矩形GPU套餐。模态一直擅长处理这种部署后可灵活扩展的场景，用户通常会有周期性或突发性的资源需求。我们管理着所有计算资源，而美妙之处在于我们拥有数以千计的客户，

33:00 我们可以将这些能力进行整合，从而获得非常平稳的工作负载，也就是说，实现非常平稳的总体需求，而我们能够非常高效地管理这些需求。因此，modal functions 是核心功能。我们在2021年推出了这个产品。正如我之前提到的，我们在2023年开始看到产品市场契合度的显现。现在，它已经占到我们收入的约三分之二，正在赋能大量实际应用场景，虽然目前主要是用于推理，但也可以用于各种其他用途。modal sandboxes 是我们在2023年推出的。实际上，它和 functions 一样，花了很长时间才找到产品市场契合度。为什么我们要推出它？我们意识到，与我们交谈的很多人正在使用大型语言模型来生成代码。这就像我和 Akshar 有一天在午餐时讨论时想到的，我们觉得他们可能需要一个可以运行这些代码的地方。我们意识到，实际上我们已经具备了大量基础设施，可以直接运行代码。因为我们已经构建了管理容器和隔离的基础组件，比如我们已经有了 G visors 和隔离机制等。因此，我们对这个想法感到非常兴奋。Akshar 写了一个原型，并在大约一两天内就推出了这个产品。最初，我们看到的增长非常有限。我不想轻视这一点，因为我们确实看到了一些增长。比如在2023年，有一些用户开始使用它，我们有一些早期用户对某些功能感到满意。但总体而言，它在2023年夏天之前对收入的贡献非常有限。两年后，我们甚至讨论过是否还需要这个产品。

34:30 我们是否应该关闭它？然后它突然开始爆发式增长。2023年，我认为真正发生的是大型语言模型在生成代码方面变得非常出色。2023年，也就是大约那个时候。我觉得那正是它们从能够重构函数、编写代码片段发展到能够生成完整应用程序的时期。因此，我们开始看到很多增长来自于“vibe coding”（氛围编程），比如 Loveable 等公司。随后，像 Ramps 这样的公司开始使用模型作为后台代理。接着，我们开始看到来自多个 Neolabs 的显著增长，他们正在模型沙箱中进行强化学习等操作。现在，沙箱产品已经占到我们收入的三分之一。我们将其视为几乎像我们的第二个产品。对我来说，这非常令人兴奋，因为早在 modal 早期阶段，我就知道 modal 的目标是创建一套完整的产品工具包。我们一直希望成为类似云服务的平台，拥有存储、计算以及多种交互方式。我们一直希望成为多产品供应商，但直到现在，这在实践中才真正实现。我认为现在情况已经变得清晰，我们有 functions，有 sandboxes，同时还在开发其他许多产品，比如训练、批量处理等。对我而言，这种向多产品公司的演变非常令人激动，因为这始终是愿景的核心。即使在早期的演示文稿中，我也有很多关于这一点的幻灯片。但直到最近，外部世界才真正认识到这一点。

36:00 你们现在正在推进的项目中，有没有可能成为下一个突破性产品的？对市场趋势有什么预测吗？我本人对训练领域非常乐观，我认为训练市场目前存在大量未被满足的需求。虽然业界普遍关注大规模训练任务，但我们实际观察到大量需求集中在中小型训练场景。本周我会在会议上详细讨论这个话题，我们正在组织一个名为Batch的会议。我认为这个市场非常有趣，我们看到很多客户有特殊需求，比如前几天就有客户需要转录5000年的音频数据，他们拥有数以百万计的音频文件。我们具备充足的处理能力，允许他们完成这个任务，整个过程只用了几天时间。我认为这里存在很多有趣的实际应用场景。我对低延迟技术领域非常看好，我认为一旦语音到语音模型、语音模型等技术成熟，这个领域将产生巨大市场机会。当然，还有所有这些关于代理（agente）的讨论。说实话我对"agente"这个词有些复杂感受，因为我觉得从某种意义上说，所有软件最终都会变成智能代理。对我来说，"agente"到底意味着什么？我认为从某种角度看，所有软件最终都会被AI技术驱动。但显然，目前有一些基础构建模块正在形成，比如开发更多基于大语言模型的软件，这种趋势似乎在所有应用场景中都普遍存在。

37:30 我们常说，你知道，我看待模型的方式就像我们从事的是构建基础模块的业务，我们希望为你提供令人惊叹的、具有广泛适用性、经过实战检验的、通用型可组合的基础模块。我认为在代理用例方面也有一些非常有趣的内容。你提到训练，因为我记得在另一档播客中，可能是一年前或两年前，你说过当时你们并没有特别专注于训练，市场发生了什么变化？我们已经断断续续地开发训练产品多年了。所以不能说我们从未关注过训练。但就像我们有150名工程师，而一两年前我们团队规模要小得多，规模较小的团队迫使我们不得不更加聚焦。因此推理成为了我们唯一的关注点，并且多年来都是如此。但现在我们规模更大了，我们也有机会在其他市场进行布局。我也对训练后的一些技术方向很感兴趣，比如强化学习。我认为这领域有很多令人兴奋的内容。此外，存储、数据仓库、特征存储、实时流处理管道等方面也有很多值得关注的技术。长期来看，Modal 的愿景是，当你想要构建一些酷炫的AI应用时，我们知道如何帮你实现，我们为你准备好了所有基础模块，包括各种计算任务，我们会帮助你将这些模块组合起来，构建出完整的解决方案。

39:00 软件的魅力在于，只要你拥有合适的构建模块，几乎可以构建任何东西。这正是我们想要打造的公司和产品类型。当你说训练时，你们是否更关注那些进行大规模训练的大型企业？不，他们通常会去与超大规模云服务提供商或Neo云等签订巨额合同，获取数万块GPU。但在我看来，市场中存在一个尚未被充分满足的细分领域，即研究人员在迭代模型或训练小型模型时的需求。我们看到很多来自德克萨斯海滩、演讲文本模型和计算生物技术领域的客户，他们正在训练规模相对适中的模型。你可以在64块GPU上训练推荐系统，或者进行大量传统机器学习任务，这些都不需要动辄十万块GPU。我认为这个市场短期内不会成为我们的重点，但我觉得在稍小一些的市场中，仍然存在大量未被满足的需求。搭建训练集群非常困难。

40:30 你有没有注意到，自从GLM 5.2或Can we 2.5发布以来，很多人开始使用并微调这些模型？实际上我看到的情况是相反的。几年前微调的价值主张是：开源模型质量还不够好，但如果你用一个小模型在特定领域进行微调，就能在质量和成本上达到前沿水平。如今，我认为开源模型已经足够优秀，你可以直接用Kimi K3、DeepSeq 4.1或GLM 5.3等模型替代前沿模型，它们在成本大幅降低的情况下几乎能达到同等效果。因此我们仍然看到大量对训练后优化的需求。我认为这是一个非常有趣的领域，我们在该领域正在开发一些产品，包括SFT和强化学习等技术。需要补充的是，微调不再是必须的操作，它变得非常可选。现在开源模型即使直接使用也能表现得很好。说到沙箱系统，我差点忘了问你。你们提供的沙箱系统相比现有沙箱有哪些更新？其实变化不大。我们一直非常擅长处理这类问题，毕竟我们是infrageeks（基础设施专家），在扩展性和可靠性方面表现突出。我认为这正是我们在这个领域占据最大市场份额的原因（虽然我没有具体数据，但我觉得我们市场份额远超其他竞争者）。我们能够轻松运行数万甚至数百万个沙箱。确实，为了应对这种规模，我们不得不多次重写系统架构。

42:00 但我们在这些方面一直做得很好。随着时间推移，还有其他需要考虑的因素。比如，沙盒空间整体而言并不是最具有差异化的领域，但我们正在开发一些非常酷的功能。随着时间推移，我们不得不添加对虚拟机（VMs）的支持。我们之前购买了基于GVisor的沙盒产品，但现在我们还提供完整的虚拟化机器。事实证明，对于某些特定使用场景，你几乎需要完整的Linux兼容性。我们还不得不构建其他功能，比如更高效的交互式原语，比如在沙盒之间来回传输数据，以及与文件系统的交互。我们在快照功能上投入了大量时间。我认为从长远来看，能够真正脱颖而出的功能包括一些非常酷的功能，比如沙盒分叉、快照、恢复快照、实时迁移等。总体而言，我认为沙盒的新颖之处始终在于其短暂性，你可以只运行几秒钟的沙盒。这是我喜欢的特性，我希望在这方面进一步探索。我认为可以实现很多酷炫的功能，比如将代理（agent）和执行框架（harness）解耦，让代理控制多个沙盒，分叉沙盒，快照等，比如运行非常短暂的任务，每个命令只运行一个实例。我认为这些领域还有很多值得探索的酷炫功能。我们已经在快照相关功能上投入了很多时间，但我认为这些领域还有很多可以开发的酷炫功能。你之前提到了快照几次。

43:30 你认为快照的使用场景是什么？它能给我们带来什么目前无法实现的功能？对我来说，最大的价值在于，目前很多沙盒工作负载都是“迁移”式的。人们常常认为沙盒几乎就像：我有我的开发环境，现在我要把它搬到云端，让代理控制它，可能在沙盒内部运行执行框架。我不确定长期来看，这是否是思考代理计算的正确方式。我认为一个更好的模型是拥有长期运行的代理，这些代理几乎就像耐用的执行工作流。它们会24/7运行，偶尔执行一些命令，能够快速启动沙盒（比如100毫秒内），运行几个命令后关闭并进行快照。我认为你越能缩短这种“唤醒-休眠”周期，就越能创建仅运行极短时间的沙盒，这将使计算更加高效。这还将使你能够实现一些非常酷的功能，比如分叉和移动任务，想象一下，像Claude代码那样，而不是线性流程，可以分支，同时运行数百个代理。我认为持续集成（CI）是另一个具有代表性的例子，比如在CI的历史中，GitHub Actions等工具经常被讨论。

45:00 你可能经历过一个非常线性的流程，比如你慢慢安装一堆东西，然后运行测试套件，最后生成一些报告之类的。虽然你可以将测试拆分成多个沙箱并行执行，但这个过程相当繁琐。我理想的情况是，能将整个测试套件中的每个测试都单独放在一个沙箱中运行，就像在数千个沙箱中并行执行一样。为什么不能做到这一点呢？我的理解是，问题在于启动和停止沙箱的开销太大。我认为，如果能降低启动和停止沙箱的摩擦成本，我们就能进入一个可以实现极高并发、大规模并行执行的世界。我是个基础设施极客，我对此类技术非常兴奋。一旦我们掌握了这些基本构建块，我认为这将解锁许多以前软件无法实现的酷功能。为什么这些功能还没有被构建出来？我猜即使在之前，人们也希望能尽可能并行化他们的CI流程。但你不能这么做，因为并行化的开销太大，这就像阿姆达尔定律所说的那样。比如现在，我们在modal测试套件中进行并行化，但这意味着如果你将测试套件分成两部分，每个沙箱都需要重复执行安装和测试环境的配置，这会耗费大量时间。可能需要几分钟，但假设你能一次性完成测试环境的配置

46:30 然后对容器进行快照，接着克隆这个容器，这样你就可以独立运行测试套件了。我认为很多潜在优势只有在降低摩擦成本和交易成本后才能真正实现。我认为你们和Anthropic有合作关系，他们正在使用沙箱，比如modal沙箱。是的，Anthropic的托管代理实际上是一种自带沙箱的集成方式，所以你可以使用modal来实现这一点。这种合作是怎么产生的？我认为Anthropic正在努力构建一个繁荣的生态系统和社区，他们通过推理服务盈利，所以他们有强烈的动机推动其他所有生态系统的建设。只要用户使用Anthropic进行推理，他们希望拥有尽可能大的生态覆盖面。因此，与我们这样的沙箱提供商合作对他们来说是非常理性的选择。另外，我觉得我们不得不提到Hugging Face事件。你介意谈谈这个吗？当然可以，所有细节都已经公开了。是的，能简单描述一下发生了什么吗？我认为他们当时使用的是modal沙箱，但问题并不在沙箱本身。没错，我记不清漏洞的具体细节，但你提到的modal参与其中是正确的。关于这一点，我想补充说明的是，当时运行在沙箱中的代理程序，

48:00 你知道，他们利用了Hugging Face，发现了一个部署在Modal上的应用存在漏洞，并利用这个漏洞作为跳板来获取访问权限。据我理解，他们几乎实现了完全的互联网访问权限。我不记得具体细节。需要明确的是，这是运行在Modal上的一个应用被入侵了，而不是Modal本身被入侵。就像AWS一样，很多人在AWS上运行应用，偶尔这些应用会被入侵。这是否意味着AWS被入侵了？当然不是，对吧？同样地，有很多人在Modal上运行应用，其中某个应用被入侵了。我认为，我们可以从中吸取一些教训，比如我们一直在反思，是否可以设置更合理的默认安全限制。借用AWS的类比，再举个例子，S3曾经很容易不小心将存储桶设置为公开，AWS意识到虽然这本身不一定会对AWS造成安全问题，但很多客户会因此泄露数据。现在要让S3存储桶公开变得困难得多。同样地，我们也在探索，是否可以在不破坏Modal独特优势的前提下，让安全限制默认更严格一些。我认为还有一个相关的支线问题是，代理技术在网络安全领域变得越来越强大。因此，我们实际上也从这次事件中获得了启发，开始大量使用代理技术来内部寻找漏洞。到目前为止还没有发现任何问题，但它们非常擅长深入系统内部，尝试利用漏洞并试图突破沙箱环境。因此，我们正在积极研究如何让代理技术运行在代码库中。你只需要告诉它们“查找安全漏洞”就可以了？其实不是，你只需要把它们放进沙箱，然后告诉它们“你能尝试解释一下如何逃出沙箱吗？就像从房间中逃脱一样，但这是针对代理的。”这听起来很酷。你们什么时候开始这么做的？我们是几个月前开始的，这确实令人兴奋。大概是在Fable发布的时候，也就是差不多同一时间。好吧，我对网络安全的看法是，我认为代理技术在发现漏洞方面非常有效，但我也认为可以非常有效地将它们用于防御。因此，我认为像Modal这样的公司，以及很多其他公司，现在都在思考同样的问题：我们如何利用代理技术进行防御，来修复所有漏洞？从长远来看，实际上，我并不太担心。我认为，如果有什么的话，代理技术和网络安全领域的所有突破都将会让世界变得更安全。你认为所有大型网络安全公司都已经被淘汰了吗？我不知道这个说法是否正确，因为你在问一个非常遥远的问题。

51:00 超出了我的核心专业领域。但当我想到网络安全时，你所销售的很多东西实际上是在制造恐惧。这几乎就像一种品牌和营销策略，与核心产品本身一样重要。我认为在AI领域，品牌和相关因素可能实际上更有价值。因此，我不一定得出它们已经失效的结论。我认为他们与企业客户有深厚的关系，而且拥有庞大的销售团队，非常擅长讲述令人毛骨悚然的故事等。我认为他们将继续在这方面表现得非常出色。我之所以这么问，是因为你目前是自己在做，而不是选择像Palo Alto Networks这样的公司。但也许只有大型企业才会在意这些。如果出现问题，他们可以有人来背锅，这确实如此。是的，是的。在很多情况下，你其实更倾向于雇佣一个已有的供应商，以便把责任推给他们。某种程度上，这确实减少了我们引入人工渗透测试人员的需求，而大多数初创公司通常会定期进行此类测试。所以也许以前，我们确实做过，虽然我不确定具体周期，但我想大概是每六个月一次。现在可能每年一次就够了。我不确定。但总的来说，我认为通过这些工具，人类也可以更高效地完成任务。例如，我本人也相信，人类与AI的结合现在甚至更加强大。因此，也许有论点认为我们可以引入渗透测试人员

52:30 有些人在使用代理方面非常擅长，甚至能更快地发现漏洞。我不确定。我是个乐观主义者，我创办了一家公司，所以一般来说我对很多事情都持乐观态度。但我想强调的是，我认为人类和公司并没有被"淘汰"。我认为在人工智能时代，很多公司会找到方法，利用人工智能变得更加高效。我想稍微转向开发者体验这个话题，因为早期阶段，即使现在，你们都非常关注这一点。你们已经多次讨论过这个问题。开发者体验现在还重要吗？我认为仍然重要。我认为你所处的背景，你所谈论的内容，现在与代理有关，对吧？比如，开发者体验方面，文档已经存在，代理会查看这些文档，所有这些内容。但就这一点而言，我们实际看到的情况是，几乎所有让开发者体验变好的因素，同样也会让代理体验变好，比如拥有良好的文档、具有描述性的错误信息、快速的反馈循环等。我认为确实有些事情发生了变化。前几天，我正在设置Cloudflare的一些东西，我发现Cloudflare有时让人难以应对。我让一个代理来处理它，它能够自动配置很多内容并为我提供帮助。我想说的是，代理确实让过去难以处理的事情变得容易了一些，比如处理AML（反洗钱）流程的人力成本可能有所降低，因为你可以直接……

54:00 你知道，可以告诉你的代理去处理。但总的来说，我认为让开发者体验良好的因素同样也能提升代理的体验。我认为在某种程度上，基础设施随着时间推移，也需要变得更加程序化。我认为沙箱的论点一直如此，即以前需要用YAML配置的东西，现在应该直接通过SDK实现。这应该更偏向于命令式操作，比如启动沙箱、对沙箱进行操作、然后销毁沙箱，而不是通过某种DSL进行声明式配置。这种方式也推动了一种以前可能不存在的接口。我认为无论如何，SDK的相关性与之前一样，甚至可能更重要。你们的产品有没有做出什么改变？因为大多数人只是在上面运行代理？我们确实如此。事实上，我们还进行了大量内部测试，让代理执行任务，比如让代理构建并运行一个移动应用。一个非常具体且有点好笑的例子是，我们发现由于代理的训练数据，现在很难弃用某些功能。我们注意到代理经常倾向于使用旧版本的modal语法，这使得引导它们改变变得困难。因此，我们在未来一年左右的弃用和移除功能时，必须更加谨慎，必须非常小心地更新所有在线示例。

55:30 在线上的技能，对吧？是的，还有类似的东西。但另一方面，现在在线上也有大量modal代码进入了训练数据。我看到这成为了一个有趣的例子，顺便说一句，还有类似搜索引擎优化的代理优化，不管人们怎么称呼它。我们经常进行内部基准测试，比如问代理：“嘿，你能为我们部署一个稳定扩散模型吗？使用你想要的任何工具。”然后我们观察它是否会推荐modal。这些信息对我们跟踪趋势非常有用。或者像“嘿，启动一些沙箱”或“嘿，按可靠性或价格对所有沙箱供应商进行排名”。我们花了很多时间做这些事情以确保效果。你如何应对这种情况？你可以说：“嘿，构建这个稳定扩散模型，它会推荐modal吗？”是的，你如何应对这种情况？我认为这更难。我认为这类似于搜索引擎优化，主要是通过内容来实现，你必须发布大量内容。在某种程度上，你也可以通过观察感知来调整，比如询问代理：“按可靠性或价格对所有沙箱供应商进行排名”，然后观察结果，这似乎让代理更容易误解价格等信息。因此，我们也花了很多时间让内容更加清晰。

57:00 以及类似的内容，对代理来说更容易理解，因为我们知道它们都在索引，比如所有公开的信息，并且涉及模态。你有没有想过创建一堆GitHub仓库，让代理在其中编写大量模态代码？你尝试过吗？Slop cannon。我认为事实是，这可能确实是你能做到的事情。我的猜测是，目前的LM训练数据对AI输出本身可能不太敏感，因此你可能能够生成大量无用内容。我们考虑过这个想法，但我不太喜欢这个主意。不过理论上，就像早期的SEO一样，即使现在仍然如此，自动生成内容是一种非常有效的策略。我认为这是可能的。你知道，你也可以做这些事情。是的。我想切换到FDEs。显然，你们公司雇佣了像forward-appoid工程师这样的角色。你们具体做什么呢？我们现在正处于一个新时代，构建应用程序和以前几年无法构建的东西。我们看到很多公司需要一些帮助，对吧？因此，我们几年前开始投资FDEs，但真正大规模扩展是在今年。我认为我们今年开始拥有4名FDEs，现在可能有24名左右。我们已经大幅扩展了这个团队。他们所做的工作，虽然不完全等同于传统的模型，但他们在客户互动方面投入了很多精力。他们与许多客户合作进行性能调优，尤其是与LMS相关的工作。我们发现，与客户坐下来

58:30 讨论、训练草稿模型、调整参数和DLM、SG Lang等，能带来巨大好处。他们经常与客户合作解决遇到的问题，比如如何绕过某些限制。我们还经常利用FDEs主动帮助客户，例如当我们发现某些客户过度配置模型时，比如客户请求了过多的CPU或内存，这会很昂贵。我们会尝试识别这些问题，并与客户沟通，告诉他们：“你现在在模型上花费了很多钱，我们实际上可以帮助你节省开支。”当然，对于有活跃交易的客户，我们还帮助他们将代码从其他平台迁移过来，等等。我认为，我们从未打算成为一个以服务为主的业务。我认为FDEs的目标首先是参与销售流程并促成交易，其次是为客户提供支持。但我觉得最重要的是第三点，即填补产品中的空白，这些空白最终会转化为真正的功能。因此，我认为在很大程度上，FDE所做的任何事情，我都会问自己长期来看，如何将这些转化为产品，从而不再需要FDE？是的。你们公司会招聘产品经理吗？

1:00:00 产品经理？嗯，其实不是。你会说这些FDEs有点像伪产品经理吗？它们的职能确实有些不同。我认为在面向客户方面，它们确实有类似产品经理的职责，但在内部职能方面，它们更像是产品管理中一个独立的部分，主要负责确定Modal下一步需要投资建设的模块。比如，当有10到20个客户提出不同需求时，我们需要从中发现共性，思考如何将这些需求转化为产品。我们确实有团队成员从事产品管理工作，这个角色也随着发展逐渐演变。过去有些人从DevRel或工程师岗位转为产品经理，因为他们展现出在战略层面思考产品构建能力的强项。实际上我并不反对产品经理这个角色。我确实认为过去很多公司过于急切地招聘产品经理。我认为存在一种风险，就是有些产品经理过于急躁，只凭直觉提出一些模糊的想法就快速推进产品开发。我认为在基础设施公司做好产品管理非常困难，因为这需要非常深入的战略思维，思考基础模块的构建方向，以及我们未来一到两年想要达到的目标。毕竟基础设施建设本身非常复杂，我们必须避免陷入开发出35个功能相似但实现方式略有不同的产品的情况。这种层次的战略思考非常罕见，因此我们目前还没有大规模组建产品经理团队。这确实有道理。你认为自从Genialite之后，团队结构发生了哪些变化？因为我想当然，你在Spotify工作过，当时有特定的团队结构，现在我们有了代码代理，团队结构是否发生了很大变化？以一种有趣的方式来说，我认为团队结构确实发生了很大变化，但我并不确定这是否由Genialite推动。我特别注意到一个趋势，就是大家越来越重视IC（Individual Contributor）角色，我认为这对整个领域来说是非常积极的变化。如果你回顾十年前甚至二十年前的情况，所有人都渴望成为管理者，因为这是获得更多金钱、认可和声望的途径。我认为这种转变实际上在Gen AI之前就已经开始，但AI的出现确实加速了这一趋势。我们在Modal明确告诉所有人，无论是管理者还是RC（可能指某种职位），在声望上没有任何区别，所有人都只是技术团队的一员。最终评判标准是你的贡献，我们看到很多X经理选择回归技术岗位，因为他们想重新编写代码。因此，我们逐渐减少了对非技术管理人员的依赖，

1:03:00 每个人，包括我自己，仍然在Modal和Akshath上编写大量代码，技术团队的几乎所有成员，以及许多非技术团队的成员也都在编写代码。对我来说，这更像是一个近期的现象，但我不确定这是否一定是由生成式AI（Gen AI）导致的。不过我认为生成式AI确实显著加速了这一趋势，因为它进一步降低了编写代码的成本，使代码编写变得更加容易。例如，当非技术人员提交代码时，你们是如何进行代码审查的？你们团队是如何进行代码审查的？我们确实会进行代码审查，但我们将它视为可选的。我的观点是，对于大多数人来说，代码审查在很大程度上是人们试图逃避将代码合并到生产环境中的责任。如果你的团队存在这种文化，那么在我看来，这表明你需要在持续集成（CI）、持续交付（CD）以及容器集成等方面进行更多投资，尤其是持续集成（CI）和持续交付（CD），因为这些都与部署相关。我们确实会进行代码审查。比如，当我编写代码时，偶尔会询问作者："这个代码是否符合你对问题的理解？"我希望自己没有从根本上改变架构，但我们在内部也明确表示代码审查是可选的。如果你只是在修改文档，或者只是做一些基础工作，不需要等待人类审核，特别是在AI时代，为什么需要让人类检查每一段代码？你不需要这样做。但这也要求你具备非常完善的控制机制，

1:04:30 在内部进行测试，对吧？没错，就像基础设施公司，我们需要比普通初创公司多一个九的可靠性，对吧？就正常运行时间而言。但这些投资是必须做出的。你必须构建非常健壮的系统，比如在所有地方设置速率限制，必须解耦系统，确保没有任何单点故障。测试覆盖率必须极其优秀。如今代理工具在编写测试方面实际上非常出色，这在几年前我还觉得代理工具最大的缺失之一，但现在它们确实做得很好。我认为这是因为需要暂时跳脱当前任务，以近乎魔鬼代言人的方式去编写高质量测试。现在它们在编写测试方面确实表现得相当不错。所以我认为所有这些因素都有帮助。你们使用前沿模型进行编码吗？或者你们尝试过开源模型吗？我们尝试过所有可能性。没错，比如Cursor，当然还有Claude和Codex，现在很多人使用Night Shift以及各种开源工具或其他技术栈。我并不一定有明确的立场，我希望人们能自由实验，尝试不同的方案。我们内部使用前沿模型，也使用开源模型，同时我们正在尝试更多内部的“狗浮”测试。现在我们实际上在大规模运行大量开源模型的推理任务。我认为使用某些内部端点对代理开发非常有帮助，因此我们也在推动这方面的实践。我之前读到过一些内容，可能是一年前，或者两年前，

1:06:00 你说过当时不认为你们会有大规模本地部署业务。你们是否改变了这个观点？我没有改变看法。对我来说，我是一个Claude的坚定支持者。退一步说，当云计算在2008或2009年出现时，我的第一反应是这简直疯狂。为什么我要把代码放到别人的电脑上运行？这简直荒谬。但六个月后，我开始这么做了。我认为我用了六个月才改变想法，而企业可能花了15到20年才接受。但你看，像Snowflake或AWS这样的供应商，比如Datadog等，都提供了很多例子。显然云计算已经取得了胜利，多租户系统也明显占优。对我来说，本地部署看起来越来越像是一种过时的商业模式。实际上，我认为BYOC（自带计算资源）、VPC对等连接等，这些都反映了过时的安全模型——即我们需要保护自己网络内的所有内容，使用网络作为安全模式。我认为这种观点已经不再适用了。我们已经转向了更稳健的安全范式，比如零信任等。因此，BYOC和这些做法看起来越来越不适用了。

1:07:30 从安全角度来看，这已经显得过时了。从我们的角度来看，我们对整个基础设施栈拥有完全的控制权，我们租用所有硬件，部署并管理所有基础设施，部署并监控所有主机的健康状况和各项指标。这意味着我们可以快速迭代并打造更优质的产品。我认为这与过去客户使用企业版时需要在客户环境中部署、必须非常谨慎地考虑版本管理相比，是非常有价值的优势。比如，如果我们想引入一个新的数据库，我们可以直接引入，因为我们拥有控制权，不需要考虑客户能访问什么。对我来说，多租户模式确实有诸多好处。当然，如果未来我们与某家大型500强企业合作，他们要求BYOC（自带云），我们过去也做过类似的事情，会给他们一个数字。这个数字非常高，到目前为止还没有人接受。但谁知道呢？如果价格合适，我仍然会考虑开发。此外，我认为还有一个有趣的点，理论上BYOC可能也是一种获取容量的方式。例如，我们有时会与Neolabs合作，而Neolabs已经拥有大量预留的容量。问题是，如何让他们在已有容量的情况下运行modal？BYOC可能是一个解决方案，我们仍然可以将控制平面保留在自己的环境中。

1:09:00 这个问题的另一面是，也许我们甚至可以在这些容量上运行其他人的服务。理论上，有一些有趣的可能性，比如将所有这些容量聚合到一个大池中。我们对这些想法感到兴奋。但总体而言，我不确定我们是否会涉足本地部署。不过BYOC（自带云）可能是一个方向。我可以解释一下BYOC。假设你即将融资，你会用这些钱做什么？正如我之前提到的，在这种容量情况下，大部分资金需求是容量预付，这对我来说是当前资金的最佳用途。我们正在非常积极地扩展容量。未来可能会转向其他部署模式，比如所有权模式等。但我觉得其中总会涉及现金部分，比如某种预付款或定金。因此，我认为这是目前资金的最佳用途。当然还有其他用途，比如员工薪资和办公空间等。但从整体财务角度来看，这些在财务报表中几乎可以忽略不计，对吧？有趣的是，你认为这种情况会改变吗？我认为不会，因为我们在业务中拥有的运营杠杆效应非常惊人。比如，我们有200名员工，他们的成本很高，但

1:10:30 GPU的成本要高得多。是的。如果你必须说出目前对你或公司来说最重要的三个关注点，会是什么？首先是容量，其次是财务复杂性。总的来说，我们如何思考这个领域？我们如何思考定价和产品包装策略？我们如何权衡所有权与租赁模式之间的矛盾？我们应该更倾向于新云（neocloud）方向，还是采取相反的路线？这种对立立场可能是我目前思考最多的问题。第二大关注点可能是产品战略。我经常思考下一个关键构建模块是什么。例如，如果我们更多地投入智能代理相关技术，我们需要哪些存储或计算的基础组件？或者说，未来几年世界会突然意识到需要什么？理想情况下，我们希望在那时已经做好准备。总体而言，我们在预测需求方面表现不错，比如通过无服务器函数和沙盒环境提前开发产品。那么下一步是什么？我认为第三大关注点是文化建设和公司发展。我们最近员工人数已突破200人，正在以极快的速度增长，预计年底前将达到250人。当公司快速扩张时，250名员工都在思考如何为公司创造最大价值，确保他们拥有正确的背景信息和动力，每天都能兴奋地来上班，因为他们有机会参与构建非常酷的项目。

1:12:00 他们清楚知道，比如，是什么让Modal取得成功，他们能做什么。关键在于对齐激励机制，确保我们拥有非常积极的文化氛围，人们在其中拥有隐性的信任去完成很多事情，同时也具备责任感去交付最佳成果，并在未达成目标时接受问责。对我而言，这些是在这种规模下至关重要的因素。比如，当团队只有10人、20人或30人时，大家都能在一个房间里通过隐性的方式自然感知到彼此的状态。人们能敏锐察觉到我的情绪变化，比如当我有点烦躁时他们会告诉我，当我开心时他们也能察觉。但现在我们有250人了，人们未必能直接感知到这些。当然，新成员可能对与CEO沟通等事情有些紧张。因此，我该如何保持亲和力？如何在组织规模扩大时维持这种连接？虽然邓巴数字（Dunbar number）这个概念我认为更多是理论上的推测，但其背后的故事确实有一定现实依据。目前我们团队规模在150到200人之间，构建文化基础非常重要。你们团队接下来一年计划招聘多少人？过去12个月我们的年化增长速度约为四倍。我认为这种相对而言的增速是不可持续的。我见过很多公司每年团队规模翻倍，这虽然不难实现，但四倍的增速会导致文化漂移，出现不同工作风格的"孤岛"现象。

1:13:30 你开始看到人们做一些非常投机的事情。这总是让我在工程团队中特别警惕。我去和引擎工程师聊天时，问他们在做什么，结果发现他们在做一些边缘化的事情。我会质疑：这真的是你们应该花时间做的吗？快速扩张确实有成本，比如培养新人的成本。我不确定。我认为到年底可能有250人，明年年底可能达到约700人。我们预计增长速度可能在每年2.5到3倍左右。因此，明年很可能达到700人左右，我假设其中大部分是工程师。我们也在大量招聘销售团队。什么样的工程师？主要是系统工程师。我们一直非常深入Linux、文件系统、可扩展系统、网络和云计算等领域。这些是我们在寻找的核心人才。这些领域的人才非常擅长相关技术。此外，由于我们在堆栈上稍微向上移动了一点，现在在LMA前端空间做了大量工作。因此，我们现在需要处理与CUDA、GPU和MFU相关的问题，比如如何最大化每块GPU的token数量等。尽管我认为这些领域的工作很多仍然是系统驱动的，因为KV缓存和路由实际上仍然涉及很多系统层面的问题。不过，确实也有一些GPU性能优化相关的内容。

1:15:00 我们开始组建研究团队。我们对进入后训练、知识蒸馏和为客户或内部开发更优量化方法等领域非常兴奋。我认为这与FDEs的情况有些相似。我们最初会与客户合作优化他们的模型，但长期来看，我们需要将这些转化为产品。我认为在某些方面我们可能会失败，如果每次客户需要优化模型时，我们都必须与他们单独合作，长期来看这必须转化为产品。因此，与FDEs和研究团队初期需要大量与客户合作，我们正在这么做。但随着时间推移，我们也在构建大量内部工具和完全自助服务的内部产品。目前我们在后训练领域和GPU性能优化领域都在进行大量工作。有很多令人兴奋的内容。回到你之前提到的产品策略，你的看法是？我们认为未来一两年需要什么？我认为很难准确预测。如果我说我知道明年需要构建什么，我认为我可能是在自欺欺人。到目前为止，我认为我们看到的以及我更广泛相信的是：我们需要更好的基础构建模块。这是一个软件新时代，我们正在解锁几年前无法实现的新类型应用。

1:16:30 正在处理所有与GNI相关的工作，编写相关代码，生成LMS输出代码，这些代码需要以隔离的方式运行。目前需要许多新的原语来支持GPU和LMS的协作。到目前为止我们已经构建了一些基础模块，这使得过去几年中涌现出大量应用。当然不仅限于我们自己的项目，但我认为未来几年还会有更多令人兴奋的创新。我之前提到过一些方向，例如我对训练环节非常看好，对快速任务非常看好，对代理系统和低延迟相关领域也充满期待。但归根结底，我们自认为是基础设施提供商，我们不追求构建高度垂直的专用工具，而是致力于打造通用性极强的基础模块并提供给客户。客户将这些模块组合起来，会创造出我们无法预见的惊人应用。

我想浏览一下你的一些推文。这将是最后部分。好的，如果你需要深入探讨某个具体点，我们可以随时展开。目前很多持久化沙箱的使用场景都比较长。今天的感觉更像是传统的迁移部署。我推测沙箱环境将从开发机逐步演进到云端，最终发展为更短暂的形态——每个命令对应独立的环境。现在我可以在中间进行暂停、恢复、克隆等操作。是的，我们之前讨论过很多次这个话题。确实，我们之前也提到过，对吧？比如我认为目前模态中典型的沙箱时长大概在8秒左右，这确实令人惊讶。

1:18:00，当你想到这一点时。随着时间的推移，我认为这可能会变得更短。我们也需要支持长期运行的沙箱。我认为长期运行的沙箱有很多非常合理的应用场景。但我的愿景是，这个世界还需要解决如何通过大规模并行化来减少沙箱启动和停止的开销？我不确定是否已经有人在为竞争对手的猫事实战（catfax arms race）投入资源，如果有的话，协调一下这种军备竞赛或许会更好。暂不评论。GPU资源短缺最大的弊端不是获取GPU困难，而是几乎所有容量都以三年期的固定资源块形式出售，这些资源块的交付时间要到未来三到六个月。这与大多数用户的需求并不匹配。我认为我们之前也讨论过类似的问题。是的。现在我们可以深入探讨一下。我认为Modal一直做得非常好的一点就是提供完全按需的容量。例如，如果有客户需要100个GPU，我们通常可以立即满足，甚至不需要与销售人员沟通。现实中的许多工作负载并不像这些平坦的矩形资源块那样规律，它们会在24小时内不断上下浮动，可能随着时间推移逐渐增长，也可能存在某些突发的高峰时段。对我来说，这正是当前许多客户面临的问题。我认为这确实是该领域的一个真实痛点——目前获取容量的唯一主流方式就是购买这些固定周期的矩形资源块，这种方式并不理想。我认为世界需要改变，从根本上说（虽然我可能有些偏见），这就是为什么我认为Modal可以在这一领域发挥重要作用，无论你需要什么。

1:19:30 调用它，这种持续时间转换可以提供更灵活的容量。我们可以做到这一点，因为我们能够聚合成千上万的客户，需求变得非常平滑且聚合。这正是 modal 的一大价值主张。你会说这是个差异化优势吗？哦，真的吗？是的，这是一个巨大的差异化优势。实际上，如果非常简化地来看，我认为 modal 的价值主张可以分解为两部分：一是开发者的体验，即能够快速迭代和构建东西而无需考虑基础设施；二是容量管理方面。随着我对 modal 的思考越来越多，以及我们长期的发展方向，我们正在构建一个平台，聚合全球的计算能力。我们非常擅长以非常细粒度的方式进行切割，因为我们已经做了大量关于快速扩展和收缩、GPU 快照、以及一些让速度大幅提升的技术工作。这种模式在大规模上表现得非常好，因为可以聚合大量客户。每个月我都在说，可能 box 收入会适用这个模型，但它的增长速度每月都在提升 30%。这简直难以置信。我不太明白，每个月我都想，虽然沙箱增长了很多，但显然它们已经达到了一个平台期，却还在继续增长。所以，我也不太清楚。很多风投机构都问，你怎么知道沙箱会变得这么重要？事实上，我并没有确切知道，我确信它在 2023 年的表现会比现在更大。但如今沙箱已经占到我们收入的三分之一，这简直令人难以置信。当然，我们对此非常高兴，而且我们有大量团队正在投入资源。

1:21:00 在沙盒中。你知道，我不想轻描淡写地对待这件事。显然，我们确实应该为今天对沙盒的理解给予自己很多肯定，即使早在2023年就有所认识。但我想，如果当时我可能不会轻易下注，认为沙盒能带来如此巨大的收入，也不会预见到市场需求会如此旺盛。推理服务提供商与模型构建者分离存在有趣的结构性原因。最佳模型经常变化，而推理服务提供商可以轻松在不同模型之间重新分配资源，因为整体需求相对平稳。如果你想想所有中国实验室，以及未来希望更多美国实验室的情况，每当有新实验室发布最新开源模型时，你就会看到对这些模型的需求发生巨大变化。因此，我认为如果这些实验室各自独立持有算力，当他们推出新模型时需求会大幅上升，但其他实验室推出更优模型后需求又会下降。当然，这些实验室在后台也在开发下一代模型。因此，我认为正如我之前所说，存在结构性原因导致需求逐渐转向最新最好的中国实验室。当然，这并不是说所有东西都会在一夜之间改变，因为很多模型、提示词等都存在一定的粘性。但我确实认为，模型之间切换非常容易，比如今天我们为某个模型运行了1000块GPU，明天可能需要将其中50%转移到另一个模型上。

1:22:30 当然，这就像系统本来就是为处理这类事情而设计的。根本不需要有人告诉我们该怎么做，它会自然而然地完成。那么你是否认为基本上大语言模型已经变成了商品？如果你同意这一点，那么你认为大公司的商业机会会出现在哪里？我不确定这一定正确，对吧？比如，泰勒·斯威夫特算是商品吗？她发布一张专辑，进行巡演，赚很多钱。然后，当她去录制新专辑时，可能会有一段低谷期，但之后她又会发布新专辑，你知道的，她仍然拥有巨大的品牌影响力和利润空间。因此，只要实验室能够持续推出新模型，并且这些模型的利润足以覆盖训练模型的摊销成本，我认为这仍然可以成为一个不错的商业模式。你认为智能会达到瓶颈吗？不，我不这么认为。我的意思是，我认为这还有待观察。比如，目前的模型在那些可以通过强化学习高效训练的任务上表现得非常好。我们最初看到的是，随着时间的推移，模型在编写简单代码片段方面变得非常出色，后来甚至能够编写生产级代码。它在数学和网络安全方面也表现得非常出色，这些都是可以验证的成果。我认为，我们仍然需要观察，比如我们的模型是否会在烹饪食物或其他我目前想到的那些目标更分散、反馈周期更长的领域中表现出色。但就我而言，我觉得人类在这些领域可能会长期保持竞争力。当然，AI模型确实变得越来越好，我相信这一点。显然，模型在编程方面已经非常出色，它们现在就已经能很好地完成编程任务。你认为还有哪些目前规模不大的应用场景，可能在未来几年内变得非常重要？针对大语言模型而言？我不确定，但我觉得任何具有可验证计算生物特征的应用都可能成为突破口。你提到计算生物学，我认为这些领域虽然不完全可验证，但可以通过模拟实验进行验证，比如使用大语言模型输出预测结果，然后通过计算方法模拟分子动力学并获得反馈。例如，材料科学可能也是另一个领域，你可以在其中合成特定材料并测量其特性，将代理纳入循环中进行实验。我有物理学背景，对这些方向非常兴奋。除了药物和材料，还有哪些领域？我一时想不起来，但肯定还有许多其他方向。太棒了，这些就是我所有的问题。你还有想讨论但还没提到的内容吗？我已经说完了。这次对话非常棒，非常有趣。太好了，谢谢。