Modal 重建沙箱基础设施：绕开 Kubernetes，60 秒内创建 100 万个并发沙箱

当 AI 工作负载要求同时运行上百万个隔离沙箱、每秒创建数万个时，Kubernetes 这类传统容器编排系统开始力不从心。Modal 工程师 Colin Weld 和 Connor Adams 最近公开了他们「从头重建沙箱基础设施」的做法——结论相当激进：干脆绕过 Kubernetes 这个系统。

一分钟速览

• Modal 自研沙箱基础设施，以支撑数百万并发沙箱与每秒数万次创建吞吐；
• 核心做法是放弃 Kubernetes 等强一致性编排系统，规避 O(N) 状态协调瓶颈；
• 每个工作节点成为自己的「单一数据源」，调度层由一组并行服务器水平扩展；
• 基准测试中不到 1 分钟创建 100 万个沙箱，启动到运行代码中位时间不到 0.5 秒。

Kubernetes 的扩展极限在哪

运行 100 万个沙箱，对任何容器平台都是极限考验，既因为容器数量庞大，也因为需要数万个计算节点。许多操作的复杂度要么是 O(容器数)、要么是 O(节点数)，这会让传统容器平台撞上扩展极限。以 Kubernetes 为例，调度算法和中央持久化存储（etcd）的负载都随节点和 Pod 数量增长；Pod 和节点会多次向 etcd 写入数据，在 Pod 创建率或更替率很高时容易引发严重问题，而且 etcd 没有为同一键空间分片提供原生支持。要克服这一限制，需要重写或替换 etcd、并行化调度算法，工作量巨大。

绕开系统的关键设计

Modal 工程师做的根本性改动，是停止全局协调，让调度更接近负载均衡：每个工作节点不再依赖中央数据存储作为「单一数据源」，而是各自成为自己的「单一数据源」；不再使用单个串行调度器，而是部署一组并行运行的调度服务器。一旦调度服务器决定在哪个工作节点创建沙箱，就直接通过 RPC 联系该节点——有空闲资源就接受，否则拒绝。最终架构仅剩一个瓶颈：所有工作进程把状态发布到一个 Redis 流中，但负载测试表明这在工作进程数量远超 10 万时仍可行。

他们把设计优先级定得很清楚：所有产生 O(沙箱) 或 O(节点) 级负载的组件都必须默认支持水平扩展，沙箱创建流程应尽可能简单，其余事项视为次要。

趋势洞察

亚马逊云科技首席 AI 工程师 Alex Jones 评价，Modal 的关键在于没有试图扩展 Kubernetes，而是在理解其局限性后「绕过了整个系统」，认为这是「首个可信的信号，表明 Kubernetes 未能足够快速地适应生成式 AI 基础设施的实际需求」。在他看来，行业正朝「协调与执行脱钩」的方向发展：执行层需要 Modal 这样能在几毫秒内建立隔离边界的实现，而多代理工作流的协调层仍需要 Kubernetes 擅长的能力。对 AI 基础设施而言，这是一条越来越清晰的分层路线。

并非孤例

Modal 并非唯一试图围绕「高可扩展基础设施 + 10 毫秒级冷启动」重构云计算的平台，Unikraft、Google Substrate 和 Overdrive 也在朝类似目标努力。这背后的共同逻辑是：生成式 AI 的工作负载形态——海量短生命周期、高度并行、对启动速度极度敏感——与传统 Web 服务截然不同，逼着基础设施层做一次从「强一致编排」到「水平可扩展执行」的范式迁移。