利用 LP、FUSE、C/R 和 CUDA 检查点将推理冷启动减少 40 倍

所有帖子 返回 工程 2026 年 5 月 12 日 • 阅读 20 分钟 使用 LP、FUSE、C/R 和 cuda-checkpoint 将推理冷启动减少 40 倍 Charles Frye @charles_irl 技术人员成员 Jonathan Belotti @jonobelotti_IO 技术人员成员 Erik Bernhardsson @bernhardsson 首席执行官兼创始人 Akshat Bubna @akshat_b CTO 和创始人 我们在推理的年龄。数十亿到万亿参数的神经网络在专用加速器上以每秒千万亿次的运算速度运行，以大规模生成媒体、编写软件和折叠蛋白质。与以前占主导地位的训练工作负载相比，推理工作负载更加可变且更难以预测。这使它们自然适合无服务器计算，其中应用程序是在（虚拟）机之上的级别定义的，以便它们可以更容易地扩展和缩小以处理可变负载。但无服务器计算只有在新副本能够快速启动的情况下才能发挥作用——与需求变化一样快，可以达到秒级。天真地启动一个新实例，例如在 B200 上为十亿参数 LLM 提供服务的 SGLang 实例，可能会花费数十分钟，或者因 GPU 可用性而停滞数小时。在 Modal，我们在过去五年中进行了深入的工程工作来解决这个问题。在这篇博文中，我们将介绍我们所做的事情。有四个关键要素： 云缓冲区：维护健康、空闲 GPU 的小缓冲区以承担新负载 自定义文件系统：从内容寻址的多层云原生缓存中延迟提供容器映像 检查点/恢复：通过直接将进程恢复到内存中，通过 CPU 端初始化快进 CUDA 检查点/恢复：通过直接将 CUDA 上下文恢复到内存中，通过 GPU 端初始化快进 它们共同将 AI 推理服务器副本扩展为多个几千秒到几十秒。我们一直在分享这项工作的点点滴滴，因为我们认为保密是一条糟糕的护城河。如果更多的人学习如何有效地使用 GPU，那么市场上就会有更多可用的 GPU！但这篇博文是我们第一次将整个故事放在一个地方。我们希望它能让您相信我们的系统值得购买——或者加入我们来构建它。为什么关心无服务器 GPU？最大限度地提高推理工作负载的 GPU 分配利用率。首先，让我们明确问题的框架。 GPU 昂贵且稀缺，因此我们希望最大化其利用率，其中“利用率”是以下无单位量： 利用率 := 实现的输出 ÷ 支付的容量 有多种方法可以衡量利用率 - 定义输出和容量。这里最复杂和最严格的可能是“模型 FLOP/s 利用率”，它将原始算法操作要求除以聚合算术带宽。这对于工程师来说是很有趣的事情。对于“英雄跑”大规模训练也尤为重要，因此吸引了大量的投入和关注。最近，每个人都在 xAI 的 ~10% MFU 上扣篮。但在堆栈的另一端，有一种更基本的利用率形式，它破坏了所实现的输出与推理工作负载分配的容量之间的关系，GPU 分配利用率：GPU 分配利用率 := 运行应用程序代码的 GPU 秒数 ÷ 支付的 GPU 秒数 除了“GPU 利用率”术语之外，nvidia-smi 和类似工具报告的“GPU 利用率”介于这两个极端之间。它报告内核代码在 GPU 上运行的时间比例——字面意思是 CUDA 流在 GPU 上运行的时间比例。在这里阅读更多内容。推理应用程序的规模变化很大。与培训不同，对能力的需求不在工程组织的直接控制和管理范围内。相反，它是由外部用户行为驱动的——由市场或社交媒体算法或产品团队驱动。以下是我们用于模拟推理应用程序的时变泊松过程中每分钟请求的示例跟踪。不仅要注意季节变化（每日周期），还要注意随着平均需求的增加，需求变化不断增加的长期趋势。激增的需求引发了严重的工程问题。借用 AWS 的 Marc Brooker 的话：“系统的成本随着（短期）峰值流量而变化，但对于大多数应用程序来说，系统产生的价值随着（长期）平均流量而变化。”尖峰的需求意味着高的峰均比，这对系统经济性提出了挑战。具体来说，想象一下此类应用程序的容量规划。您的需求（以在延迟目标内服务请求所需的 GPU 来衡量）可能如下所示： 使用固定的、超额配置的 GPU 分配，利用率较低 已配置的应用程序需求 为了正确服务您的预期负载，您分配（机架堆栈式、在超大规模器上租用）140 个 GPU。但大多数 GPU 大部分时间都处于闲置状态 — GPU 分配利用率很低。哟