在最近的一篇文章中，Modal 的工程师 Colin Weld 和 Connor Adams 描述了他们如何从头开始重建沙箱基础设施，以支持数百万个并发沙箱创建和每秒数万个沙箱创建。
根据 Weld 和 Adams 的说法，传统的容器编排系统（例如 Kubernetes）很难以这种规模运行，因为它们依赖于集中式同步和强大的持久状态。
运行 100 万个沙箱突破了任何容器平台的极限，这不仅是因为容器数量庞大，而且还因为运行这么多沙箱需要数万个计算节点。有许多实现要么是 O（容器），要么是 O（节点），或两者兼而有之，这导致传统容器平台达到可扩展性限制。
就 Kubernetes 而言，他们解释说工作负载定向到调度算法和中央持久存储（etcd）随着节点和球的数量而增加。此外，pod 和节点都会向它们写入内容 etcd 多次，“这可能会在本质上不可分离的密钥空间内，在高 Pod 创建率或高 Pod 衰减等情况下导致严重问题”。他们还指出，克服这些限制是可能的，但需要“大量工作”，包括重写或替换。 etcd 以及调度算法的并行化。
为了优化扩展，我们决定默认情况下任何需要 O(boxes) 或 O(nodes) 的东西都应该是水平扩展的，创建沙箱的方式应该尽可能简单，其他一切都应该是次要的。
Modal 工程师对其平台所做的一项重大更改是停止全局同步，并使调度更像负载平衡。每个工人不再依赖中央数据库作为事实来源，而是成为自己的事实来源。同样，他们没有使用单个序列化调度程序，而是部署了一组并行调度服务器，允许调度层水平扩展。
一旦调度服务器决定由哪个工作人员创建沙箱，它就会通过 RPC 直接联系该工作人员并请求创建沙箱。如果工作人员有空闲资源，则接受计划请求，否则拒绝该请求。
他们说，最终的架构只有一个缺点：所有工作人员将其状态发布为单个 Redis 流。然而，“负载测试表明这对于超过 100,000 名工人来说仍然可行”。在他们的基准测试中，他们每分钟构建 100 万个沙箱，平均开始编码时间不到 0.5 秒。
Hopsworks 首席执行官 Jim Dowling 在 LinkedIn 上评论这一消息时指出，“每个规模都会出现新的技术挑战”，这表明团队需要多次迭代其设计才能实现每秒 50,000 个可靠的沙箱创建。更重要的是，AWS首席工程师Alex Jones观察到，Modal取得的成就很大一部分并不是试图扩展Kubernetes，而是在意识到其局限性后“绕过一切”。 Jones 认为这是“第一个可靠的信号，表明 Kubernetes 没有足够快地适应 GenAI 基础设施的真正需求”，并认为：
我们将把协调与执行分开。高性能飞机想要莫代尔制造的东西；以毫秒为单位出现的分离边界。协调平面（多机构工作流程需要共享内存和重叠安全边界）仍然希望 Kubernetes 风格的系统良好。
Modal 是专为 AI 工作负载构建的无服务器计算平台，提供对 CPU、GPU、容器、推理、训练、工作区和隔离盒的可编程访问。它不仅仅是寻求围绕高度可扩展的基础设施和低于 10 毫秒的冷启动“重建云”。其他具有类似目标的项目包括 Unikraft、Google Substrate 和 Overdrive。
