先看证据
“矩形”描述的是采购合同
Modal CEO Erik Bernhardsson把AI算力供需的错位概括为“矩形”：客户通常按固定数量、固定期限购买GPU，合同画出来像一块矩形；真实工作负载却会随时间起伏。Modal面向的，是不想预先配置集群、预测峰值并为闲置资源付费的开发者和AI应用团队。这里的“矩形”应当理解为采购方式的比喻，而不是一种已确认的技术术语。
这个比喻值得读，不是因为它给GPU取了新名字，而是因为它把基础设施生意里的风险摆到了台面上。按峰值签约，低谷时硬件可能闲置；按平均需求购买，流量冲高时又可能不够用。Modal试图把多个客户的波动需求汇进一个容量池，先在底层取得供给，再把较小、较灵活的算力份额交给用户。能否奏效，取决于池里的需求是不是足够互补，而不是客户数量本身。
弹性取决于池化和启动速度
共享容量能摊平需求，但GPU不会因为被放进一个池子就自动变得可用。Modal的材料提到，它通过GPU缓冲、自定义文件系统、进程检查点和GPU内存快照，减少启动或恢复模型副本所需的工作。对使用者来说，这些底层机制最终体现为一件很实际的事：算力能不能在需求出现时及时到位，而不是等到扩容完成后，业务高峰已经过去。
这也解释了为什么“无服务器”不能只看开发者是否需要管理集群。弹性若响应太慢，就可能把资源成本转化成等待时间；若为了保证响应而预留过多容量，又会重新引入闲置成本。材料没有披露启动时间、GPU利用率或不同负载之间的实际错峰程度，因此不能据此判断Modal的池化效率究竟有多高。可以确定的是，快速启动与恢复不是表面上的开发体验优化，而是共享容量能否兑现的条件。
沙箱从配套工具变成运行入口
Modal的沙箱故事说明，需求变化不只发生在GPU数量上，也发生在计算的使用方式上。公司最初推出沙箱，是因为语言模型开始生成代码，而这些代码需要隔离环境运行；早期采用并不理想，团队一度讨论是否关掉产品。后来，编码代理、后台代理和强化学习带来新的使用场景。Bernhardsson称，沙箱如今约占公司营收的三分之一，这一增长并非团队发布时就预料到的。
代理会创建环境、运行代码、检查结果，再决定是否重试。于是，沙箱不再只是开发者偶尔打开的工具，其启动和恢复延迟会进入代理每一轮工作的体验与成本。Modal披露已启动近30亿个沙箱，但这个累计数量本身不能说明单个任务的效率，也不能说明安全隔离的强弱。它更清楚地表明，代理工作流正在把“在哪里运行生成的代码”变成基础设施产品的一部分。
池化者也要承担价格风险
把需求汇总起来，并不会消除供给侧的风险，只是把风险转交给更靠近容量采购的一方。Modal称自己不拥有算力，而是通过租赁和多云采购取得供给，并与近25家云服务商合作；材料还称其通常签订三年以上的容量协议。长期承诺可以帮助稳定可用容量，但如果GPU价格后来下跌，按旧价格锁定的供给就可能变得昂贵。依赖更灵活的现货容量则有另一面：供应可能被抢占，未必能在需要时兑现。
增长数字证明不了单位经济
在Series D相关材料中，Modal报告年度化营收运行率超过10亿美元、完成7.5亿美元融资并达到160亿美元估值，还称已启动近30亿个沙箱。这些数字展示了业务扩张的速度，却不能单独回答更重要的问题：GPU利用率有多高，容量池赚不赚钱，长期合同遇到价格变化时由谁承担损失。把融资、估值或沙箱数量直接当成基础设施效率的证据，会把增长与经济性混为一谈。
对技术负责人而言，判断是否采用这类平台，应该从自己的负载形状出发：峰值和低谷是否明显，任务是否能容忍启动等待，沙箱的创建与恢复是否成为代理循环的瓶颈。若需求高度波动、又不希望为峰值长期预留GPU，共享弹性算力值得纳入评估；若工作负载持续稳定，或对延迟和容量确定性要求极高，就需要比较预留资源与弹性服务的真实代价。最终要问的不是“算力是不是矩形”，而是谁为闲置、短缺和价格变化买单。