GPU 合同是矩形，AI 算力需求却不是
为什么说 GPU 合同是“矩形”？
购买 GPU 容量时，常见的合同是：在固定时间内，获得固定数量的 GPU。把时间放在横轴、算力容量放在纵轴，这份合同就是一个矩形。
但真实的 AI 工作负载并不如此规整。需求会增长、突然冲高，也会在一天内回落。按峰值购买，就要承担闲置成本；买得少，又可能无法满足需求。
Modal CEO Erik Bernhardsson 所描述的弹性算力模式，正是要处理这种错配：开发者不必提前配置集群、预测全部负载，也不必始终为闲置容量付费。
弹性算力：把长期容量拆成按需使用的小块
Erik 将 Modal 的做法形容为一种“期限转换”：平台在底层 확보算力容量，再汇集数千家客户的需求，让每个客户在需要时使用相应资源。
如果不同客户的需求能够形成更平滑的总负载，这个共享容量池就更有价值。它解决的不只是算力采购问题，也是如何把算力切分成更小、更灵活的使用单元。
不过，弹性并不意味着风险消失，而是平台需要承担部分供需和价格风险。
例如，平台按当前价格锁定容量后，如果 GPU 价格下跌，就可能持有成本偏高的供给。Erik 表示，他并不预期价格即将崩塌，但认为经营这类业务时，必须考虑这种可能性。
沙箱：从险些被放弃，到约三分之一营收
Modal 推出沙箱产品，始于 Erik 与联合创始人 Akshat Bubna 的一个判断：语言模型既然能够生成代码，就需要有地方执行这些代码。
产品早期的采用情况并不理想，团队甚至讨论过将其关闭。随后，编程智能体、后台智能体和强化学习带来了新的需求。
据 Erik 介绍，沙箱业务已增长至 Modal 营收的约三分之一，这是他在推出产品时没有预料到的结果。Modal 同时披露，累计启动的沙箱已接近 30 亿个。
这种增长也改变了基础设施的要求。智能体可能反复执行以下循环：
- 创建运行环境；
- 执行代码；
- 检查结果；
- 调整后再次尝试。
在这种工作流中，环境启动和恢复的延迟，会直接影响智能体完成任务的体验。基础设施服务的对象，不再只有操作工具的人类开发者，也包括持续调用工具的智能体。
快速启动，是弹性成立的前提
如果新增容量来得太慢，即使平台支持自动扩缩容，也未必能及时应对需求变化。
Modal 介绍的无服务器 GPU 实现涉及几类机制：
- 可用 GPU 缓冲池：保留能够用于承接新增负载的容量；
- 自定义文件系统：配合实例启动和运行；
- 进程检查点：保存进程状态，减少恢复时需要重复完成的工作；
- GPU 显存快照：减少启动额外模型副本时的准备工作。
这些机制共同服务于一个目标：降低新增模型副本上线所需的工作量，让弹性扩容能够实际改善应用响应速度和成本。
增长数字应如何理解？
Modal 披露，其年化收入运行率已超过 10 亿美元，并以 160 亿美元估值完成了 7.5 亿美元 D 轮融资。
这里需要区分：年化收入运行率并不等于已经实现的全年收入；累计沙箱启动量也不等于同时在线的沙箱数量。这些指标反映的是不同维度的业务规模。
这场讨论的核心问题是：当 AI 负载越来越波动、越来越多任务由智能体反复执行时，固定容量合同与实际使用需求之间的差距，要由谁承担，又该通过什么技术和商业机制来缩小？