GPU需求不是矩形：Modal的弹性算力与智能体沙箱
为什么说GPU合同是“矩形”？
典型的GPU容量合同，会规定客户在一段固定时间内使用固定数量的GPU。把容量画在纵轴、时间画在横轴上，就得到一个矩形。
但真实的AI工作负载并不遵循这种形状：需求会增长，也会在一天之内出现高峰与低谷。按峰值采购，就要为闲置硬件付费；采购不足，又可能无法满足需求。
Modal CEO Erik Bernhardsson提出的思路，是在底层 확보算力容量，再将数千家客户的需求汇集起来，让每家客户按实际需要使用算力。不同客户的需求汇总后越平稳，共享容量池就越能发挥作用。
这相当于把固定期限的大块算力，转换为更细粒度、可弹性使用的服务。 Modal希望开发者运行代码时，不必自行配置集群、预测负载或承担全部闲置成本。
弹性服务背后，仍有价格风险
客户不再直接承担所有容量规划工作，并不意味着风险消失了，而是部分转移到了平台一侧。
如果平台按当前价格锁定算力，之后GPU价格下跌，就可能持有成本偏高的供给。Erik表示，他并不预期GPU价格即将崩跌，但认为建设这类业务时，必须把这种可能性纳入考虑。
因此，弹性算力不仅是调度问题，也涉及采购期限、容量利用率和价格变化之间的平衡。
一度考虑关闭的沙箱，成为重要业务
Modal推出沙箱，是因为Erik和联合创始人Akshat Bubna注意到：语言模型能够生成代码，而这些代码需要一个执行环境。
产品早期的采用情况并不理想，团队甚至讨论过是否将其关闭。随后，编程智能体、后台智能体以及强化学习带来了新的需求。
据Erik介绍，沙箱业务已贡献Modal约三分之一的收入。这并不是他在产品推出时预料到的结果。
智能体的工作方式也改变了基础设施的要求。一次任务可能反复经历以下过程：
- 创建执行环境；
- 运行代码；
- 检查结果；
- 修改并再次尝试。
在这种循环中，环境的创建与恢复延迟，会直接影响任务执行体验。基础设施需要服务的不再只有开发者，也包括不断调用环境的智能体。
快速启动，是弹性的前提
只有新增容量能足够快地投入使用，弹性扩容才有实际意义。
Modal介绍的技术机制包括：
- 可用GPU缓冲池：保留可供调用的GPU容量；
- 自定义文件系统：减少启动所需的数据准备工作；
- 进程检查点：保存进程状态，便于恢复；
- GPU显存快照：减少模型副本上线时需要重复完成的工作。
这些机制共同减少新模型副本上线所需的工作量，也使底层基础设施设计直接影响应用响应速度与运行成本。
用业务规模理解这场变化
Modal披露，其年化营收运行率已超过10亿美元，并以160亿美元估值完成7.5亿美元D轮融资，累计创建的沙箱接近30亿个。这里的年化营收运行率是按当前业务水平折算的年度指标，不等同于已经实现的全年营收。
比规模数字更值得关注的是两组关系：一方面，用户需要随负载变化的算力，而底层供给往往需要提前锁定；另一方面，智能体频繁创建和恢复执行环境，让启动延迟成为产品体验的一部分。
Modal的实践展示了如何通过需求聚合、容量管理和快速启动机制，尝试弥合这两类差距。但平台仍需承担利用率与GPU价格变化带来的经营风险。