从三年 GPU 合同到八秒沙箱：Erik Bernhardsson 谈 Modal 的算力生意

一、嘉宾背景

Erik Bernhardsson 是 Modal 创始人。在这期由 Alessio Fanelli 与 Shawn swyx Wang 主持的 Latent Space 访谈中，他讨论了 Modal 如何连接底层算力与应用开发。Modal 提供计算、存储和软件 SDK，支持推理、沙箱、训练、微调及批处理任务，并管理背后的容量。交付计算资源本身，因而始终是这套软件平台的核心责任。

Erik 将 Modal 的起源与自己在 Spotify 的经历联系起来。据他回忆，他在那里工作了约七年，参与从零建设音乐推荐基础设施，并开发了 Related Artists、Discover Weekly 等功能。计算密集型推荐工作让他长期面对基础设施带来的阻碍；他把 Modal 描述为自己当时就希望拥有的工具。这段经历也解释了他为何反复把开发者获得反馈的速度，与底层执行能力放在一起讨论。它构成了产品的经验来源，但不能证明 Modal 适用于所有计算场景。

此后，他担任 Better.com CTO 约五年，积累了招聘、团队建设和开发者生产力方面的经验。他也曾发布开源工作流编排框架 Luigi。代码如何组织与执行、团队如何持续交付产品，是这些经历中彼此交织的两条线索，也贯穿了这次访谈：从工作流工具走向计算平台之后，Erik 对 GPU 合同的讨论，仍与工程控制、客户服务和公司文化紧密相连。

二、本期主要内容

Modal 的起点，是 Erik 对工作流工具的一次重新判断。2021 年，他探索云端工作流编排时逐渐发现，更大的障碍在于执行计算：即使任务依赖已经安排妥当，代码仍可能难以方便地在云端运行。团队因此转向解决底层执行问题。后来，Modal 还只有四五个人时，Stable Diffusion 成为关键应用。按 Erik 的回忆，帮助团队确认生成式 AI 推理需求的主要入口是图像生成，不能将这段增长笼统归于 ChatGPT。

早期收入增长很快，客户也高度集中。据 Erik 回忆，Modal 的月收入从 2022 年十一月约一百美元，升至次月两千美元，再到 2023 年一月三万美元。他将早期获客归因于自己持续发推和写博客。2023 年初，纽约的 Mage 一度贡献约八成至九成收入；同年晚些时候，Suno 也成为大客户，收入来源随后才逐步分散。这些经营回忆呈现了增长速度，也显示出早期业务对少数客户的依赖，尚不足以说明需求基础已经稳定而广泛。

Erik 将 Modal 的两项主要产品概括为 Functions 和 Sandboxes，称访谈时两者分别贡献约三分之二和三分之一的收入。Functions 主要用于推理，以便于部署和扩展的形式提供执行能力。Sandboxes 则回应了一个相邻需求：模型生成的代码需要隔离环境来运行。团队复用已有的容器隔离和 gVisor 基础设施，随后接触到 vibe-coding 公司、Ramp 后台智能体以及强化学习负载带来的需求。转录中有关沙箱增长年份的表述相互冲突，需求来源可以确认，快速增长发生的具体年份则无法据此确定。

需求扩大也改变了采购方式。Erik 说，Modal 最初主要使用大型云服务商的现货容量和短期预留，后来转向接近二十五家供应商，许多交易要求三年以上的承诺和大额预付款。约四人的采购团队与约十人的裸金属工程团队，承担采购交易、设备验收和全球设备故障处理等工作。访谈时，Modal 的容量仍以租用方式取得；Erik 也在考虑购买硬件及其他未来供给安排。拥有设备会增加电力、供应商协调和运维责任，股权融资涉及稀释，债务融资则要求收入能够支撑偿息。

在训练业务上，Erik 的重点是中小规模负载，包括研究者迭代、语音、计算生物技术和推荐系统。他以约六十四张 GPU 的任务为例，明确表示十万张 GPU 的大型交易不在当前重点之内。他还讲述了一个批处理案例：一位客户将数百万个文件、累计约五千年的音频，利用 Modal 的可用容量在几天内完成转录。这说明了他看重的批处理能力，但访谈没有提供成本、质量或资源配置数据，其他音频项目仍无法据此估算交付表现。

三、核心观点：推理、例子与边界

节目标题中的“矩形”，指的是算力供给合同的形状。Erik 举出的常见条件是提前三至六个月确定起租时间，随后连续约三年使用固定容量；客户需求却会随昼夜、业务增长和突发任务不断变化。Modal 的思路是汇聚数千家客户，把各自不规则的需求组合成更平滑的总负载，再通过快速调度分配容量。按需服务由此有了经济上的解释，其价值也延伸到了操作便利之外。不过，访谈没有披露利用率、毛利或闲置成本，需求聚合究竟带来多大收益，仍缺乏量化依据。

在 Erik 看来，开发体验与执行系统紧密相连。传统后端工具通常围绕较稳定的负载设计，昂贵 GPU 和大模型加载则提出了不同要求：模型需要从网络经 CPU 载入 GPU，准备过程本身就可能成为瓶颈。Modal 因而自建文件系统、容器运行时、快照、自动扩缩容系统和调度器。容器快速启停既能缩短开发等待，也能让生产服务随负载调整资源。如果执行和模型准备仍然缓慢，上层编排再精细，也无法消除这部分等待。这一瓶颈分析解释了 Modal 的选择，但不足以推出所有团队都应重写整套云基础设施。

全球容量池也让 Modal 能够整合供应端的分散资源。Erik 举出亚美尼亚三十二个节点、印度尼西亚一百二十八个节点，说明小规模资源如何成为采购机会。但节点数量只是评估的起点：供应商还须满足 IOPS、CPU 性能和南北向带宽要求，尽量先接受单节点验收，合作后还要持续考察故障响应与修复速度。“全球统一池”的背后，是平台对资源差异和设备失效的持续处理。供应商数量增加，并不自动等于有效容量增加；采购单价较低，也不等于交付成本较低。

长期采购承诺同时带来财务风险。锁价在市场上涨时可能有利，但 Erik 更警惕 GPU 租价、利用率和转售需求同时下滑。届时，闲置容量可能难以转售，采购义务却仍须履行。因此，他主张积极采购以跟上需求增长，而非以“智能需求无限”为由持续囤积。新兴 GPU 云的融资方式进一步显示了商业模式的差别：先取得客户的长期承诺，再以合同或 GPU 为担保融资，可以加快资产扩张；Modal 依靠产品吸引客户、承接弹性需求，较难复制这条融资路径。

算力交易也无法消除物理条件的差异。Erik 支持对冲、保险和风险分担，但不确定算力能否成为高度标准化的交易商品。地点、网络、磁盘、CPU 和可靠性，都会影响一份容量的实际价值。合同中的一小时 GPU 能否转化为应用的一小时有效执行，不能只看芯片名称。他对非 Nvidia 加速器的期待同样谨慎：以 Nvidia 承担 prefill、Cerebras 承担 decode 为例，异构推理有机会按阶段匹配计算或内存瓶颈，但部署更复杂，上游制造与供给也可能继续受限。他承认过去类似预测多次落空，因此将其视为一个可能的方向。

沙箱把按需分配的时间粒度进一步缩小。据 Erik 报告，Modal 沙箱的生命周期中位数约为八秒。他设想，长期存在的智能体工作流可以按需唤醒短时环境，执行后保存状态并关闭。约一百毫秒的唤醒时间是他举出的目标，尚非实测结果；长期运行的沙箱也仍有用途。Modal 将沙箱从 gVisor 扩展到完整虚拟机，是为了满足部分场景的 Linux 兼容性要求。交互式数据传输、文件系统、快照、分叉与恢复，也都是他关注的能力或发展方向。环境存续多久，最终仍取决于任务的运行要求。

CI 提供了一个具体的快照用例。测试分片若各自安装依赖、初始化环境，可能重复花费数分钟做准备；如果只初始化一次，再克隆快照，就有机会把执行粒度缩小到每个测试一个沙箱。Erik 提到约一千个沙箱并行，是为了说明这种可能性。收益来自减少重复准备和启停开销，不能仅凭并行数量判断；串行环节与并行化本身的开销，仍会限制最终加速幅度。

跨客户聚合与跨模型调配，处理的则是两类不同波动：前者缓冲时段差异和突发需求，后者应对模型热度的变化。Erik 以一个假设说明独立推理服务商的调配空间：将服务某个模型的数千张 GPU 中的 50% 转给另一个模型。他同时承认，模型和 prompt 都有使用黏性，需求能够迁移并不足以证明 LLM 已经商品化。对于未来应用，他也保留了相似的判断边界：代码、数学和网络安全等结果较易验证的任务，模型进展更明确；生物与材料领域的吸引力，在于可能接入模拟或实验反馈。至于目标模糊、反馈周期漫长的任务，他仍不确定模型能取得怎样的进展。

四、学习与应用

评估 GPU 采购时，起租时间、承诺期限、实际负载形状和退出条件，需要与容量一同考察。尤其应分析价格下跌、利用率下降和转售困难同时发生时，长期合同会留下多大敞口。比较供应商，还须纳入 IOPS、CPU、网络、验收和修复表现。长期承诺能够换取供给确定性，也意味着承担需求预测失误的代价；访谈没有给出可以直接采用的最佳采购比例。

对智能体和 CI 团队而言，准备、启动、实际执行与状态恢复的耗时，应分别测量。如果安装依赖和初始化占比很高，就可以验证预先准备环境、再克隆快照是否能带来收益；如果任务需要长期连续运行，频繁关闭环境可能并无优势。评估细粒度并行，也应比较完整任务的完成时间和资源消耗。Erik 报告的八秒生命周期中位数，描述的是 Modal 的沙箱使用情况；约一百毫秒唤醒和一千沙箱并行，仍是设想与示例，无法替代具体项目的测量。

接口维护同样需要考虑智能体。Erik 强调，清晰的文档、描述性错误和快速反馈，对人和智能体都有帮助；他倾向于用命令式 SDK 创建、操作和销毁沙箱。这些操作可以组成端到端任务，用来观察智能体在哪里误解接口、遇到错误后能否恢复。Modal 也测试智能体完成应用开发、部署和供应商推荐任务的表现。由于模型常沿用旧语法，团队对 API 弃用更加谨慎，并更新示例、改进定价说明。接口变更时同步检查在线示例，在错误信息中指明正确路径，有助于减少这类使用障碍。定价能否被正确理解，也需要通过任务验证。模型的供应商推荐可以反映它掌握的信息，却不能充当可靠性或价格优劣的客观排名。

客户工程介入的过程，则能为产品开发提供依据。Erik 描述，FDE 会协助客户调优、迁移和排障，也会帮助 CPU 或内存申请过量的客户降低成本。这项工作的长期目的，是把产品缺口转化为自助能力。团队可以记录每次介入解决的障碍，再跨客户寻找重复模式，判断哪些适合形成诊断工具、自助配置或通用能力，哪些仍需要人工判断。Erik 主张从十至二十个客户的需求中提炼共同的基础设施原语，避免堆积大量近似功能；这个数量表达的是寻找共性的思路，并非立项门槛。抽象需要时间，未来需求也无法被准确预测，每项定制服务都立即变成标准功能并不现实。

可选代码审查依赖一整套工程条件。Erik 的主张建立在可靠的 CI/CD、充分测试、限流、解耦和消除单点故障之上。希望减少审查等待的团队，需要先判断这些控制能否承接相关改动的风险，再决定哪些工作可以自主交付。脱离这些前提，普遍免审就失去了他论点的依据。公司快速招聘时也有相似要求：Erik 将容量与财务决策、未来产品原语和公司文化列为重点，并警惕文化漂移、工作方式割裂和注意力分散。更明确地传递上下文、建立信任与责任，是保持协作的必要工作；提交权限本身并不能确保大家理解当前重点。

Hugging Face 相关事件显示了安全归因对证据的要求。Erik 明确承认自己的记忆不完整，并将事件解释为部署在 Modal 上的客户应用被利用来访问互联网，而非 Modal 平台被攻破。核实时仍需分别考察应用漏洞、网络出口和平台边界，这段回忆不足以替代独立调查。他说 Modal 正在探索更严格的默认设置，以及由智能体进行的逃逸测试；截至访谈时，这些智能体尚未发现漏洞。这样的结果仍受测试范围限制，不能证明不存在漏洞。检查默认权限、将智能体逃逸测试纳入补充检查，是这段讨论能够支持的具体做法。

选择下一项 AI 应用时，结果如何验证、反馈多久到达、下一次尝试能够从中学到什么，是更有用的判断依据。模拟与实验可能为生物、材料任务提供迭代反馈，但访谈没有给出效果数据，研发回报仍无法据此保证。Erik 也承认，未来需求无法准确预测。从已经观察到的共性出发构建可组合能力，并保留调整空间，更符合这一判断；愿景中的数字和应用，还不足以成为路线图承诺。

来源

• 原始节目：Why AI Compute Comes in Rectangles — Erik Bernhardsson, Modal