上周，NVIDIA亲手将Modal的首台Vera CPU服务器送到了我们的旧金山办公室。如今它正在服务器机架中平稳运行，我们对它可能为Modal Sandboxes乃至Modal用户带来的意义感到非常兴奋。
Vera是NVIDIA新推出的Arm兼容CPU，专为Vera Rubin GPU平台打造，但也可作为独立的CPU服务器使用。
支持Arm对Modal来说将是一个巨大的变化，因为我们长期以来一直只运行x86机器。我们需要在整个基础设施和镜像构建系统中做出改动，以支持一种完全不同的CPU架构，但基准测试结果令人印象深刻：吞吐量提升了2倍。由此，NVIDIA Vera CPU成为为Modal Sandboxes提供算力的一个极具吸引力的选择。
为什么Vera对Modal可能意义重大
首先，多租户集群存在噪声干扰。
为Sandbox产品做编排，意味着要在每台云主机上运行数百个并发容器和虚拟机。与普通的Kubernetes服务器部署将Pod共置于同一主机不同，每个sandbox工作负载的形态都是独特的，这会在多租户集群内引发一些有趣的动态：
- 资源使用可能极其尖峰化。一个sandbox在其大部分运行时间内可能相对不活跃，等待LLM，却会因一条
npm install或昂贵的grep命令而突然出现不可预测的CPU激增，达到基线的10倍。 - 工作负载形态并非静态已知。LLM可能往sandbox里扔进任何东西，而其形态只有在运行时才能知晓。资源规格往往只能靠猜。
- 所有这些异构工作负载挤进同一个同构的计算池中，可能导致吵闹邻居问题。一个租户的性能可能受到另一个租户行为的影响。
因此，用户极难知道如何为自己的工作负载设定规格，Modal也很难在没有争用的情况下对它们进行调度。
与其他强制用户为最大用量选择固定预留的提供商不同， Modal Sandboxes支持突发, 这允许用户为其P50用量预留有保障的容量，而不是为最坏情况下的P100 npm install 时刻预留，并相信当瞬时尖峰到来时，它会被主机节点内的余量所吸收。
这是一个很好的策略，我们通过教会用户信任突发能力，为他们节省了数百万美元，但这也增加了暴露于吵闹邻居问题的风险，而严格限制本可避免这些问题。
其次，每一秒CPU时间的成本都不止于那颗CPU。
Sandbox通常是为了 增强 某个外部进程而运行的，而该进程在CPU上出现瓶颈会带来实实在在的金钱成本。
在Modal，我们看到两个普遍的使用场景：后台agent和强化学习rollout。
- 对于后台agent，例如Ramp Inspect或运行在Niteshift上的那些，更快的agent意味着更快的回答，也就意味着更高的收入和用户留存。它还意味着更低的CPU时间，从而降低COGS。
- 对于强化学习，在sandboxed进程运行时，GPU却处于空闲状态。大多数训练设置仍然是同步的，整个rollout扇出必须全部完成，GPU系统才能推进到下一步。在CPU上节省的任何时间，都是在GPU上节省的时间。
对Vera CPU进行基准测试
为了测试Vera，我们为agentic Sandboxes构建了一组具有代表性的工作负载和基准测试。
创建一个“agentic”基准测试是一项具有挑战性的任务，因为服务器上完成的大部分工作并非CPU密集型，而且我们也没有想要专门优化的特定维度。数据库工作负载可以针对磁盘I/O进行优化，图像处理工作负载可以针对SIMD进行优化，而对于sandbox，我们需要设计一个既并发又异构的模拟器：一个我们可以扔给CPU的大杂烩。
由此我们开发了 Agentless Agent Bench, 它包含50个Terminal-Bench oracle解决方案和验证器，剥离了所有网络调用，并在并发Docker容器中预热，仅隔离出agent和RL实际在CPU上执行的任务——编译、文件grep、git操作、设备模拟等等。
运行该基准测试可以让我们同时获得线性任务完成时间和并发吞吐量指标。
以下结果展示了部分Terminal-Bench任务的单任务延迟，这些是你在sandbox中运行agent时合理会看到的任务。该实验在无负载的机器上串行运行，因此结果展示的是纯粹的直线延迟。
最初看到这些结果时，我承认自己持怀疑态度。在我们基准测试的50个任务中，Vera经常表现优于其他CPU，但并非总是如此，而且优势幅度也不算特别大。
但安静主机上的直线延迟并不是Sandbox用户所体验到的。在实践中，数百个工作负载同时竞争资源。继续在负载下进行测试，我们看到了Vera完全不同的表现。
虚假的取舍
在大多数系统中，吞吐量和延迟是一种取舍关系。
- 延迟可以定义为任务从开始到结束所经过的时间。
- 吞吐量是单位时间内完成的任务数量。这测试的是主机系统并发交错进程并同时推进所有进程的能力。
任务打包得越密集，吞吐量就越高。但一旦CPU被完全利用，单个任务的延迟就会因争用而受损。
就Modal调度器而言，我们总是很想以更高的打包密度运行，从现有主机机器中榨取更多算力，并提供用户可达到的更高绝对规模。但正如容器内的工作负载是尖峰化的，我们集群中容器的绝对规模也是尖峰化的，这使我们面临主机机器过度打包的风险。
通常，过度打包会表现为用户感受到的延迟增加。
但我们发现Vera并非如此。
Vera在重负载下表现更好
Agentless Agent Bench 中有一项吞吐量测试，它会增加机器上并发运行的容器数量，在固定时间内尽可能多地循环完成任务。
与直觉相反，Vera 在重负载下表现更好。
我们在 NVIDIA 总部进行的一次现场访问中，我清楚地记得第一次看到这些结果时，简直不敢相信它们会是真的。
我们早期的基准测试运行显示，与同等配置的 x86 GNR 机器相比，Vera 的任务吞吐量最高可达其两倍，尽管单个任务的延迟与 x86 机器相当，有时甚至更低。这是因为 Vera 不会随着任务堆积而变慢，而是以原本的速度快速完成每一个任务。
当我们询问时，Vera 团队确认这些结果并不令人意外。正是在这一刻，我成了 Vera 的信徒。
杀手级特性是抗争用
Vera 的杀手级特性是能够在争用下保持稳定。其高内存带宽允许每个核心打包显著更多的容器工作负载，而不会出现 CPU 节流——这解释了为什么 Vera 在我们的基准测试中远远领先于其他方案。
在增加 CPU 数量时，其他方案很早就触及吞吐量平台期，而 Vera 则持续提升，这表明我们可以将其推到比我们用于基准测试的节点更高的水平。
对 Modal 而言，这带来了更高的打包密度和更宽容的突发保护。
对 Sandbox 用户而言，我们可以在不牺牲延迟的情况下提供更高的绝对规模和吞吐量。
我们非常兴奋地推出对 Vera CPU 的支持，为 Modal Sandboxes 提供动力，并与 NVIDIA 和云提供商紧密合作，扩大我们的机群规模。
]