Modal 实测 NVIDIA Vera CPU：高负载下沙箱吞吐翻倍

Modal 官方工程博客· Erik Dunteman·2026-10-19 22:01· 1 小时前AI 评分51

NVIDIA Vera CPU 让 Modal Sandboxes 吞吐量翻倍

AI 导读

Modal 工程团队分享了 NVIDIA Vera CPU（兼容 Arm）在 Modal Sandboxes 上的基准测试。作者自建了 Agentless Agent Bench（包含 50 个 Terminal-Bench oracle 解法与验证器、剥离网络调用、以并发 Docker 容器运行），用于对比多款 CPU。

正文 · 原文

上周，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。
• 对于强化学习而言，当沙箱进程运行时，GPU 却处于空闲状态。大多数训练设置仍然是同步的，必须等整个 rollout 扇出全部完成，GPU 系统才能推进到下一步。在 CPU 上节省的任何时间，都是在 GPU 上节省的时间。

对 Vera CPU 进行基准测试

为了测试 Vera，我们针对智能体沙箱构建了一组具有代表性的工作负载和基准测试。

创建一个“智能体”基准测试是一项具有挑战性的任务，因为服务器上完成的大部分工作并非受 CPU 限制，而且我们也没有想要针对某个特定维度进行优化。数据库工作负载可以针对磁盘 I/O 进行优化，图像处理工作负载可以针对 SIMD 进行优化，而对于沙箱，我们需要设计一个既并发又异构的模拟器：一个我们可以扔给 CPU 的大杂烩。

由此我们开发了 Agentless Agent Bench，它包含 50 个 Terminal-Bench oracle 解决方案和验证器，去除了所有网络调用，并在并发 Docker 容器中预热，仅隔离出智能体和 RL 在 CPU 上实际执行的任务——编译、文件 grep、git 操作、设备模拟等等。

运行该基准测试可以让我们同时获得线性任务完成时间和并发吞吐量指标。

以下结果展示了部分 Terminal-Bench 任务的单任务延迟，这些是你在沙箱中合理预期智能体会运行的任务。该实验在无负载的机器上串行运行，因此结果展示的是纯粹的直线延迟。

初次看到这些结果时，我承认自己持怀疑态度。在我们基准测试的 50 个任务中，Vera 经常优于其他 CPU，但并非总是如此，而且优势也不是特别大。

但安静主机上的直线延迟并不是沙箱用户体验到的实际情况。在实践中，数百个工作负载同时竞争资源。接下来在负载下进行测试，我们得到了关于 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 和云提供商紧密合作，扩大我们的集群规模。

来源：Modal 官方工程博客 · modal.com