不到一分钟创建100万个沙箱，从启动到运行代码的中位时间不到0.5秒。这是Modal工程师Colin Weld和Connor Adams在一篇文章里给出的基准测试结果，也是他们决定从头重建沙箱基础设施的直接原因。

他们要支撑的目标是数百万个并发沙箱，以及每秒数万次沙箱创建。这个量级下，传统容器编排系统先撑不住了。

打开网易新闻 查看精彩图片

Kubernetes卡在哪

Weld和Adams的判断是，Kubernetes这类系统高度依赖集中式协调和强一致性状态，规模一上来就会撞墙。

运行100万个沙箱，既考验容器数量，也考验背后数万个计算节点。其中不少操作的复杂度要么是O(容器数)，要么是O(节点数)，要么两者兼有，传统容器平台会因此触及扩展极限。

具体到Kubernetes，调度算法和中央持久化存储etcd的负载都会随节点和Pod数量增长。Pod和节点还会多次向etcd写入数据，在Pod创建率或更替率很高时可能引发严重问题。他们提到，etcd没有为在同一个键空间内分片提供原生支持。

绕开这个限制并非不可能，但需要做大量工作，包括重写或替换etcd，以及对调度算法做并行化处理。

把全局协调拿掉

Modal团队定下的原则很直接：所有产生O(沙箱)或O(节点)级负载的组件，都必须默认支持水平扩展；沙箱创建流程要尽可能简单；其余事项视为次要。

最根本的改动是停止全局协调，让调度更接近负载均衡。每个工作节点不再依赖中央数据存储作为单一数据源，而是各自成为自己的单一数据源。调度层也不再是单个串行调度器，而是一组并行运行的调度服务器，从而实现水平扩展。

调度服务器决定沙箱落在哪个工作节点后，会通过RPC直接联系该节点请求创建。工作节点有空闲资源就接受，没有就拒绝。

这套架构最终只剩一个瓶颈：所有工作进程都要把状态发布到一个Redis流中。不过他们表示，负载测试表明这种方案在工作进程数量远超10万时仍然可行。

外部的两种解读

Hopsworks首席执行官Jim Dowling在LinkedIn上评论说，规模每增加一个数量级，就会出现新的技术问题，这意味着团队必须对设计多次迭代，才能实现每秒可靠创建5万个沙箱的目标。

亚马逊云科技首席AI工程师Alex Jones的看法更具体：Modal的关键在于没有试图扩展Kubernetes，而是在理解其局限性后绕过了整个系统。他认为这是首个可信的信号，表明Kubernetes未能足够快速地适应生成式AI基础设施的实际需求。

Jones还给出了一个方向性判断：协调与执行正在脱钩。执行层需要的是Modal这种能在几毫秒内建立起隔离边界的实现；而协调层，比如多代理工作流需要共享内存、存在安全边界重叠的场景，仍然需要Kubernetes这类系统擅长的功能。

Modal本身是一个专为AI工作负载打造的无服务器计算平台，提供对CPU、GPU、容器、推理、训练、批处理任务以及隔离沙箱的可编程访问。它并非唯一想围绕高可扩展基础设施和10毫秒内完成冷启动来重构云的项目，Unikraft、Google Substrate和Overdrive也在追求类似目标。