在 Modal 上，一个典型的 Sandbox 超过一半的生命周期里使用的 CPU 不到其峰值的 6%。以一个编程智能体为例：当模型在推理下一步该做什么时，Sandbox 几乎处于空闲状态，只有当智能体安装依赖、运行测试或构建项目时才会出现峰值。同样的模式也出现在其他常见的 Sandbox 工作负载中：RL rollout、评估和应用构建器。
如今，大多数 sandbox 采用固定资源预留模式定价。预留模式不适合这种尖峰型工作负载，原因有两个：
- 你必须猜测自己的峰值。智能体的资源使用量因任务而异，而且规格不足的 Sandbox 可能会崩溃，所以你最终预留的资源会远高于真实峰值。
- 你一直在为峰值付费。Sandbox 大部分时间都远低于其预留量运行，但你却要为全部预留付费。
我们认为你的账单应该与你的工作负载相匹配，繁忙时上升，空闲时下降。这就是我们的 Sandbox 支持突发的原因：当你的工作出现尖峰时，Sandbox 会获得所需的 CPU 和内存，完成后又会归还。你只需为实际使用的资源付费。
在 Modal 上的样子：活跃资源定价
每个 Sandbox 默认都支持突发。从基础的 0.125 核和 128 MiB 请求开始，让 Sandbox 按需增长。
采用活跃资源定价后，你按秒为实际使用的资源付费，以较小的请求量作为下限。你可以请求更多资源来保证供给，但即使 Sandbox 空闲，你也要为这些资源付费。你还可以设置上限来限制 Sandbox 的突发幅度；可以把它理解为设定 Sandbox 所在计算机的规格。大多数工作负载无需设置请求或上限：使用默认值并在此基础上突发即可。
估算 Modal 上的 Sandbox 成本
由于你按实际使用量付费，请根据平均使用量而非峰值使用量来估算成本：
CPU 成本≈ 运行时长 × CPU 费率 × 平均使用核数
内存成本≈ 运行时长 × 内存费率 × 平均使用 GiB 数
这种平均值适用于突发型 Sandbox，因为每一秒 Sandbox 都按其请求量和实际使用量中的较高者计费。由于平均值远低于峰值，具有突发型工作负载的客户最终可能只需支付其典型预留账单的一小部分。
下面的计算器可以帮助你估算账单会如何变化。
一个 20 分钟的编码智能体任务：安装，然后读取、编辑、测试和类型检查，其间模型在各步骤之间思考，最后进行一次构建。
CPU（1 CPU ≈ 2 vCPU） 安装和构建时出现峰值；测试使用约 1 CPU。
内存（GiB） 各步骤之间约 0.8 GiB；构建时为 2.3 GiB。
预留：提前确定规格（CPU 按最繁忙的一分钟，内存按峰值），并始终按整台机器计费 Modal：按工作负载实际使用量逐秒计费
Modal 费率 标价 · 按使用量计费
14.19¢/CPU·小时 2.40¢/GiB·小时
预留 CPU 费率¢ 每 vCPU·小时 · 可编辑
预留内存费率¢ 每 GiB·小时 · 可编辑
突发更便宜：节省58%相比固定规格预留。
Modal 仅预留其最小值，0.125 CPU 和 128 MiB。
- 平均计费使用量
- 0.44 CPU · 0.94 GiB
- 峰值使用量
- 6.00 CPU · 2.30 GiB
- 预留规格
- 1.5 CPU · 3 GiB CPU 按最繁忙的一分钟，内存按峰值
- 每 Sandbox-小时 Modal 成本
- 8.4¢ 14.19¢ × 0.44 CPU + 2.40¢ × 0.94 GiB
- 每 Sandbox-小时预留成本
- 20.0¢ 10.08¢ × 1.5 CPU + 1.62¢ × 3 GiB
- 突发节省
- 58%
1 CPU ≈ 2 vCPU。Modal 按物理核心为 CPU 定价；大多数 sandbox 提供商按 vCPU 定价。成本按每 Sandbox-小时计。预留覆盖工作负载最繁忙一分钟的 CPU 及其峰值内存，向上取整到整数 vCPU 和 GiB，采用常见的固定规格标价。工作负载为示意性示例，并非生产环境追踪数据。
突发为何有效
你的 Sandbox 保证获得其请求量，该请求量默认很小。当它突发超出该请求量时，会从机器空闲容量的共享池中获取资源，Modal 的调度器会在每台机器上保持该池空闲。
这之所以可行，是因为平均法则。共享同一台机器的沙箱大多为不同客户运行互不相关的工作，因此很少会在同一时刻出现峰值。如果每个 Sandbox 都为其峰值预留容量，机器就需要容纳所有峰值之和。而借助突发能力，它只需容纳它们同时使用的最大量。这跟电网的规模可以远小于所有家庭峰值需求之和是同一个道理。
我应该如何为我的 Modal Sandboxes 规划容量？
对大多数工作负载来说，不必规划。从默认值开始，让你的 Sandbox 突发使用，只为实际用量付费。默认情况下，CPU 可以在其请求量之上突发至多 16 核，内存则没有上限。
限制是可选的，但在以下情况下会很有帮助：
- 你需要一致的环境：对于评测、RL rollout 和其他基准测试，限制可以防止某次运行使用的 CPU 和内存明显多于其他运行。如果某个环境每次都需要完全相同的资源，就把请求量设为与限制相等。
- 你想控制成本：限制会约束一个 Sandbox 能获得多少内存和 CPU，从而限制不受限的进程或失控智能体带来的总账单。
设置内存限制时，要把它设在 Sandbox 真实峰值之上。超过内存限制的 Sandbox 会被停止。
默认请求量意味着你不必为空闲资源付费：Sandbox 空闲时按默认请求量计费，突发使用时按实际用量付费。
尽量减小驱逐的影响
峰值很少会同时出现。不过，如果它们真的同时出现，且某台机器的 CPU 耗尽，突发使用的 Sandbox 会变慢，直到 CPU 被释放出来。每个 Sandbox 都保证至少获得其请求的 CPU，但实际上大多数在需要时能获得更多。
内存的风险更大。如果某台机器的内存耗尽，当时使用量超过其请求量的 Sandbox 可能会因内存不足错误（OOM）而被驱逐（处于请求量之内的 Sandbox 永远不会被驱逐）。
驱逐很少发生，我们以 SLO 为此背书：对于小于 8 GiB 的突发使用 Sandbox，OOM 率低于每分钟 0.0001%（约每 694 个 Sandbox-天发生 1 次驱逐）。我们目前还没有针对更大 Sandbox 的 SLO，但实际上它们的驱逐率也很低。
我们还提供了工具来帮助减少 OOM 的影响。退出快照在 Sandbox 停止时自动保存其文件，并且文件系统快照在你选择的任意时刻保存它们。卷将数据保存在 Sandbox 之外，而终止原因 SDK 让你能够检测到驱逐并重试。
如果你的工作负载无法承受给定频率下的 OOM，请设置更高的内存请求（保证内存）。要找到合适的规格，请从默认请求开始，查看退出原因图表在你的仪表盘中了解运行情况，并按需调整你的请求。
总结
简而言之，大多数 Sandbox 工作负载都是突发性的，因此它们需要与之匹配的定价模式。借助 Modal 的活跃资源定价，你只需为实际使用的资源付费，同时为你的 Sandbox 提供所需的资源，因此请按平均使用量而非峰值来估算。保持默认设置，你的 Sandbox 会从小规模起步并按需突发。
每个 Sandbox 默认都会突发，因此你可以用你的下一个modal.Sandbox.create()来试试。如果你仍不确定自己的用例适合哪种方式，请联系你的销售代表，或通过以下邮箱联系我们：sales@modal.com。