vLLM 休眠模式的显存税怎么省：PhOSv1 共享 GPU 上下文，休眠 23 个模型显存降 98.1%

原文信息：本文译自 arXiv 论文《PhOSv1: Efficient Scaling of Model Sleeping on a Single Server for Autoscaling with GPU-Context Deduplication》，作者 Tianle Sun、Xingda Wei、Rong Chen（上海交通大学），2026 年 10 月 29 日提交（arXiv:2610.39999，cs.DC）。原文链接：https://arxiv.org/abs/2610.39999 。原文采用 CC BY 4.0 许可。本文为翻译，省略了参考文献；文中图表请见原文，译者在文末补充了译者注。

译者导语：做多模型推理服务（MaaS）的团队都绕不开冷启动：扩容时新拉起的推理引擎要几秒到几十秒才能接请求。vLLM、SGLang 的休眠模式（sleep mode）把引擎提前启动再暂停，唤醒几乎零成本，但每个休眠模型都要在显卡上常驻一份 GPU 上下文，休眠 24 个模型就吃掉 80 GB 显卡约 27 GB 显存。这篇论文发现这些上下文大量重复，用一个常驻守护进程统一管理并去重，休眠 23 个模型的显存占用从 25.67 GiB 降到 0.49 GiB。对做 GPU 云服务器、推理平台和弹性伸缩的读者很有参考价值。

摘要

自动扩缩容（autoscaling）是"模型即服务"（model-as-a-service）系统的关键机制。快速扩容至关重要：扩容耗时直接决定模型服务过载持续多久，进而决定服务质量。目前最先进的做法是模型休眠（model sleeping），vLLM、SGLang 等主流推理引擎都已采用：预先在 GPU 上拉起引擎并暂停，扩容时几乎零成本。

但休眠并不是免费的午餐：每个休眠模型都必须让自己的 GPU 上下文常驻显存，这部分开销随模型数量线性增长，拖累服务性能。服务商需要支持大量模型，于是陷入两难：要么所有模型都能快速扩容，要么保证服务性能。

本文表明，单台服务器可以让大量模型休眠，而不必缴纳这笔"GPU 上下文税"。关键观察是：休眠模型的上下文高度重复——驱动（CUDA）上下文可以在模型间共享，而由于常用算子和库相同，各模型的 GPU 内核二进制也大量重叠。PhOSv1 通过 API 远程调用（API remoting），把每个引擎的 GPU 上下文分配透明地委托给一个中心守护进程，从而对上下文去重；这样，单台服务器能让休眠的模型数量远超现有引擎的上限。评估表明，PhOSv1 的扩容耗时与原生 vLLM 休眠模式持平，同时大幅降低显存占用，提升了端到端的多模型服务性能。

关键词：GPU 上下文、LLM 推理服务、冷启动、检查点与恢复、模型池化

一、引言

模型即服务——在一个或多个共享集群上部署多个模型，为应用提供 LLM 请求服务——已成为现代计算基础设施的重要组成部分。对模型即服务系统来说，自动扩缩容（在空闲 GPU 上动态增减服务某个模型的引擎）必不可少，原因有二。第一，服务商通常部署多家厂商的模型（如 DeepSeek、Qwen、GLM、MiniMax），每家又提供不同尺寸的模型。第二，单个模型的请求到达率随时间波动，因为应用会根据预算和能力需求动态选择调用哪个模型。如果静态部署每个模型、给它分配固定数量的 GPU，那么请求量超出容量时服务会因资源不足而过载；请求量下降时，GPU 又会因过度分配而闲置。自动扩缩容则根据请求率的变化动态调整每个模型的 GPU 分配。

高效扩容是自动扩缩容的关键系统需求。扩容在请求率上升时触发，但在扩容期间，新分到的 GPU 还无法服务请求，模型服务仍处于过载状态。因此扩容耗时直接决定过载持续多久，服务商都希望把它压到最低。

遗憾的是，现有的模型自动扩缩容扩容很慢，因为要启动一个能服务模型的引擎，需要一套复杂的控制面来创建所需的 GPU 上下文（见第二节）。为缩短这段延迟，vLLM、SGLang 等主流引擎采用的最先进方法是模型休眠：系统离线拉起多个引擎，每个都能在线服务一个模型；所有引擎完成初始化后，在宿主服务器上暂停。在线服务时一旦需要扩容，直接唤醒引擎即可，几乎零成本。

模型休眠并不是免费的午餐。要让一个模型保持休眠，引擎必须在 GPU 上保留相当多的上下文，包括驱动上下文（CUDA context）和模型的 GPU 内核二进制。显存有限且宝贵，这给 GPU 带来沉重负担：在我们的实验中，让 24 个模型休眠会占用一块 80 GB 显卡多达 27 GB（34%）的显存，而且占用随休眠模型数线性增长。由于现代模型会预留显存存放中间结果（KV cache）以加速计算，这部分占用还会让单个模型的服务吞吐最多下降 54%。休眠模式之所以必须把这部分上下文留在 GPU 上，是因为它不像模型参数那样能快速恢复。这让服务商陷入两难：要让所有模型都能快速扩容，就得承担在线服务的性能损失；要保证服务性能，每台服务器只能让少数模型休眠，其余模型仍要付出扩容代价。

本文表明，可以在不缴纳线性"GPU 上下文显存税"的前提下，增加单台服务器上休眠模型的数量。关键观察是：每个休眠模型的上下文含有大量重复成分（如图 5 所示，两个热门模型之间的相似度最高达 99%）。驱动上下文天然可以跨模型共享——后创建的引擎可以复用先前引擎的驱动上下文；而当前的模型共用算子和库，不同模型的 GPU 内核二进制也大量重叠（见第三节）。对这些上下文去重，就能大幅降低单台服务器上支持更多休眠模型所需的显存。

为实现 GPU 上下文去重，我们采用分离式设计：把每个引擎的 GPU 上下文分配委托给一个中心系统守护进程，在那里识别并避免创建不必要的上下文。为兼容现有引擎，我们借助 API 远程调用透明地实现这种委托。去重的一个难点是，初始化期间分配的许多内部 GPU 缓冲区无法有效去重。所幸这类缓冲区的创建比其他上下文成分快得多，于是我们区别对待：模型休眠时不分配它们，唤醒时再重建。

我们从零实现了去重机制，并与 vLLM 的休眠模式集成。评估显示，PhOSv1 的扩容耗时与原生 vLLM 休眠模式相近，而在 23 个模型休眠时显存占用降低 98.1%。这一节省也改善了端到端服务性能：在多模型轨迹回放中，PhOSv1 相比原生 vLLM 将平均首 token 时延（TTFT）降低 87.0%——原生 vLLM 在显存预算内只能让有限几个实例休眠，而 PhOSv1 能让所有需要的模型都休眠，又不承担原生休眠模式的显存负担。

本文贡献：

• 首次刻画了模型休眠的"GPU 上下文显存税"，以及跨模型去重的机会（第二、三节）。
• 提出 PhOSv1：一个透明的 GPU 上下文去重系统，由服务守护进程代管上下文，共享重复的驱动上下文和内核二进制，并只在唤醒时重建无法去重的缓冲区（第三节）。
• 与 vLLM 休眠模式集成的实现及评估，表明 PhOSv1 保留了近乎零成本的扩容，同时降低 GPU 上下文显存占用、提升端到端多模型服务性能（第四节）。

PhOSv1 已在 GitHub 开源（仓库 blitz-serving/PhoenixOSv1）。

二、系统模型与问题定义

多模型服务与自动扩缩容。 AI 服务商通常在共享 GPU 集群中同时托管来自不同厂商、不同尺寸的众多模型，因为没有哪个模型能独占用户需求：模型在能力和成本上各有差异。受体量所限，每个模型占用一块或多块专用 GPU。

服务商面临的一个关键挑战，是给每个模型分配 GPU 资源。静态分配（部署时给每个模型分固定数量的 GPU）并不理想，因为各模型的请求率随时间波动：分多了 GPU 浪费，分少了请求排队、时延飙升。

因此，现代服务商用自动扩缩容按流量调整每个模型的 GPU 分配（原文图 1(a)）。具体来说，模型负载上升时，调度器挑选一块或多块空闲 GPU，在宿主服务器上启动一个或多个推理引擎并加载模型权重，扩大该模型的服务能力（扩容）；负载下降时，调度器回收该模型的部分 GPU，放回资源池供其他模型使用，节省 GPU 时长（缩容）。

自动扩缩容的关键系统需求是扩容时快速启动：新拉起的推理引擎就绪之前，发往该模型的请求只能排队；启动慢会直接导致扩容窗口内请求停滞、违反 SLO（原文图 1(b)）。扩容越快，性能损失越小。

设计目标与设计空间。 我们的目标是降低推理实例扩容时的冷启动开销。为此，先把冷启动拆成两个阶段，再分析每个阶段的具体步骤，判断能优化多少。如原文图 1(c) 所示，两个阶段分别是：在 CPU 和 GPU 上构建推理引擎运行时上下文的控制面，以及把模型权重加载进显存的数据面。

控制面构建两类上下文。构建 CPU 上下文，就是启动运行推理引擎的 Python 解释器：解释器导入整个推理软件栈（如 PyTorch 和 vLLM），加载数以万计的 Python 模块，并实例化请求调度器等引擎组件。构建 GPU 上下文，则要初始化 GPU 驱动（例如在目标设备上创建 CUDA 主上下文），把模型的 GPU 内核加载进显存，并创建引擎下发 GPU 任务所需的运行时句柄——CUDA 流（stream）、cuBLAS、cuDNN 等。

数据面把模型权重从主机内存或外部存储拷贝到显存，其耗时下限是权重大小除以链路带宽（如 PCIe 或 RDMA）。借助近期基于网络多播的权重加载等工作，数据面已经逼近硬件极限。

如果服务器从完全干净的状态启动（不做任何优化），这两个阶段可能要几秒甚至几分钟（见第四节）。已有不少工作尝试缓解启动慢的问题。本文聚焦于降低控制面开销，因为数据面已经接近硬件极限。

现有方案：检查点/恢复与模型休眠。 加速冷启动的一个直观办法是检查点/恢复（checkpoint/restore）：把已完成控制面初始化的引擎做成检查点镜像，下次重启时从镜像恢复，从而跳过全部控制面开销。但把检查点/恢复用于现代推理引擎有两个问题。

其一是性能。目前最先进的系统 PhoenixOS 在扩容时恢复一个引擎仍要 0.57 秒，因为解析检查点镜像、恢复进程内存页和内核态都需要时间（原文图 1(c)）。最坏情况下，由于基于 CRIU 的 CPU 侧上下文恢复出现原因不明的延迟，启动一个应用要 10–20 秒。其二是兼容性。现代推理引擎采用了 io_uring 等复杂优化，我们基于 CRIU 的 CPU 侧检查点/恢复工具目前无法支持。要支持它们，要么大改现有推理引擎，要么在 CRIU 上投入巨大的实现工作量；而推理引擎一直在快速演进，这两条路都不现实。

现有系统采用的另一种方法是模型休眠，包括 Aegaeon 以及 vLLM、SGLang 的休眠模式。它类似 Serverless 计算中用于加速冷启动的预热（warm start）技术，只是用在了模型即服务场景中。具体来说，休眠模式在服务器上预先拉起若干引擎，每个都能服务一个模型，然后在它们接收请求之前用操作系统工具把它们暂停。之后需要扩容时，恢复对应引擎运行即可跳过全部控制面开销；模型缩容后，引擎再次暂停。在本文考虑的单 GPU 服务模型中，每块 GPU 可以缓存多个休眠引擎，但同一时刻最多只有一个引擎在该 GPU 上被唤醒并执行。

模型休眠的关键问题：显存随休眠模型数线性增长，并拖慢服务。 既然检查点/恢复有上述问题，自然要问：模型休眠是否解决了冷启动？它的一个关键问题是用显存换启动速度。由于显存开销随休眠模型数线性增长，每台机器能预热的模型数量有限。具体来说，为了让后续扩容的控制面成本接近零，暂停的引擎要把 GPU 上下文常驻显存、CPU 上下文常驻主机内存。CPU 上下文只占主机内存的一小部分（如 vLLM 在 CPU 侧占 2.9 GB），还能借助主机共享内存在进程间共享；但 GPU 上下文体量可观，且目前无法共享。于是同一块 GPU 上休眠的模型越多，浪费的显存就越多。原文图 3（左）用 vLLM v0.19.1 测量了这种增长：缓存 24 个模型约占 27 GB 显存。注意，这一测量已排除模型参数，因为借助近期的自动扩缩容技术，参数可以快速恢复。即使一块 GPU 同一时刻只服务一个模型，这笔开销也存在：只要其他模型在休眠，它们的 GPU 上下文就一直常驻。PhOSv1 关注的是降低这部分常驻 GPU 上下文的显存开销；同一 GPU 上多个活跃引擎的并发共享与调度不在本文范围内。

这笔显存开销让服务商不得不取舍。现代 LLM 服务商提供大量模型，而休眠只能消除已休眠模型的控制面成本，要在众多模型上都避免这笔成本，就得让很多模型同时休眠。那么让很多模型休眠的显存开销能否承受？我们发现不能，因为常驻显存会损害服务：休眠的模型越多，服务性能下降越多。原因在于，服务一个模型需要在显存中存放 KV cache（计算的中间结果）；留给 KV cache 的显存越少，请求就会排队并显著变慢，模型可支持的上下文长度也受限制。原文图 3（右）用 Qwen3.6-27B 在 A800 GPU 上做了量化：休眠模型占用的显存从 0 增加到 16 GB 时，服务吞吐从 747 token/s 降到 341 token/s，下降 54%。因此，服务商目前只让少数模型休眠，其余模型仍要付出完整的控制面成本。

三、PhOSv1 的设计

PhOSv1 有两个目标：（1）即使一块 GPU 很可能同时让许多模型休眠，也要消除控制面成本；（2）避免让许多模型休眠带来的显存开销。

关键设计机会：休眠模型之间的 GPU 上下文高度冗余。 PhOSv1 在模型休眠的基础上消除控制面成本，以实现快速扩容。为解决其显存膨胀问题，我们有一个关键观察：各模型的 GPU 上下文包含大量重复内容。如果能对这些内容去重，就能大幅降低让多个模型同时休眠所需的显存。

我们在原文图 4 中详细拆解了每个休眠模型占用的显存，以评估能去重多少。显存常驻部分由四类成分构成：

• CUDA 上下文：GPU 运行时环境，包含虚拟内存管理和同步事件的控制状态；
• GPU 内核：执行模型推理的已编译 GPU 代码；
• GPU 缓冲区：为模型内部使用而分配的显存；
• 句柄：用于访问 GPU 的资源与库的注册信息，如 CUDA 流和 cuBLAS。

除了与模型相关的 GPU 缓冲区和显存占用可以忽略的句柄，我们发现大部分内容都能去重。首先，CUDA 上下文可以跨模型共享，这一点很直接：驱动上下文本身与模型无关，一个模型用过的上下文可以直接给另一个模型用。其次，各模型使用的内核也高度重叠。原文图 5 给出了不含 GPU 缓冲区时，热门模型两两之间的 GPU 内核相似度。我们选的是 Hugging Face 上下载量高的模型，它们代表了模型即服务商通常提供的热门模型。大多数模型对的内核相似度在 59%–99% 之间。尽管架构和尺寸不同，现有模型的内核仍然相似，原因是：（1）矩阵乘法等许多运算是各模型通用的；（2）在 GPU 上高效实现这些运算并不容易，所以提供它们的库集中在少数几个（如 FlashInfer）。因此，对 CUDA 上下文和内核去重，可以大幅降低让多个模型休眠所需的显存。

读者也许注意到，对某些模型（如原文图 4 上半部分的 Qwen3.6-27B），GPU 缓冲区仍占了很大一块显存。不过我们发现，这类缓冲区可以快速动态恢复：如图 4 下半部分所示，从零创建它们只需约 30 毫秒，而创建一个 CUDA 上下文约需 430 毫秒。这类缓冲区通常是运行时内部预留使用的，因此可以放心地不在 GPU 上保存，按需创建即可。

系统架构。 要实现去重，必须确保不同休眠模型的所有 GPU 上下文都由一个中心服务统一管理，它才能发现重复成分、避免创建重复资源。因此，PhOSv1 在每台机器上部署一个系统守护进程，统一管理来自不同模型的 GPU 上下文（原文图 6）。与现有休眠模式中每个模型的引擎进程各自管理 GPU 上下文（原文图 2 上半部分）不同，PhOSv1 的上下文服务把 GPU 内核二进制放在一个由分配到该 GPU 的所有模型共享的 CUDA 上下文中管理，同时管理每个模型自有的资源，如定制内核。在多 GPU 服务器上，守护进程为每块 GPU 管理一个这样的上下文，不同 GPU 上的唤醒互不影响。内核会被正确去重：模型加载某个内核二进制之前，先检查这次加载是否必要，即同样的二进制是否已经加载过；如果是，就跳过加载，减少显存占用。

下面详细介绍 PhOSv1：如何在离线阶段构建上下文服务，以及在线服务系统在引擎唤醒后如何借助它处理推理请求。

离线阶段：让模型休眠并初始化上下文服务。 离线阶段负责初始化休眠引擎，为在线高效扩容做准备。这一阶段可选但推荐：不做的话，系统会在模型首次启动时才在上下文服务中按需初始化，带来一次性的扩容延迟。实践中，这一过程也可以增量进行，比如复用扩容实例或在请求空闲期启动模型，从而摊薄成本、避免之后的扩容延迟。

离线阶段的流程如下。给定一台服务器上需要通过休眠模式快速启动的 N 个模型，先以后台守护进程的形式初始化一个管理 GPU 资源的上下文服务。守护进程就绪后，逐个启动引擎（如 vLLM/SGLang），每个引擎启动完成后即进入休眠。进入休眠后，引擎的进程状态被暂停，而它的 GPU 上下文由上下文服务持有，而不是引擎自己持有。为此，引擎不直接创建 GPU 资源，而是把资源创建委托给上下文服务。我们用一种成熟的 GPU 虚拟化技术——API 远程调用——让这种委托对引擎透明：通过 LD_PRELOAD 在 CUDA Driver API 边界拦截所有 GPU 资源创建调用，转到上下文服务中执行，推理引擎无需改动任何源码。

上下文服务收到资源创建请求后，先检查资源是否已经存在。如果资源（例如某个内核）尚未创建，上下文服务就创建它并记录创建信息，以便后续请求识别。我们用一张编码了 API 语义的查找表来实现这一点：例如 cuModuleLoadData 会把一个内核二进制加载到 GPU，之后用同一份二进制再次调用时会被识别为重复，服务直接跳过创建。这张表涵盖推理引擎用于 GPU 资源管理的全部 CUDA API，因此覆盖了所有 GPU 上下文分配。

GPU 缓冲区需要特殊处理。引擎请求分配缓冲区时，服务为它创建一个虚拟占位，把真正的分配推迟到在线阶段。这样做没问题，因为如前所述（原文图 4 下半部分），在线创建这些资源很快。GPU 缓冲区的内容会以检查点形式保存在主机内存中，以保证正确恢复。

在线阶段：支持模型唤醒与推理请求。 在线阶段，引擎被唤醒来服务请求后，我们只需让它使用上下文服务中保存的 GPU 上下文进行推理，用的仍是上面介绍的资源管理机制——API 远程调用。引擎调用 GPU 内核时，调用先被重定向到上下文服务，由它按需创建所需的 GPU 缓冲区，再执行内核。远程调用 GPU API 可能给推理带来性能开销。得益于批处理和同步等优化，这一开销在所评估的负载中可以忽略（见 4.1 节），因为推理的瓶颈主要在 GPU 执行，而不在 CPU 侧的内核下发。

如果某个模型的上下文尚未由上下文服务持有，就执行上文的休眠流程把它保存到服务里，让之后的唤醒免于冷启动。保存一个新模型的上下文通常要额外预留显存。放任不管的话，休眠的模型越多，显存占用就越大。为此，我们为休眠模型设定可预留显存的上限，必要时把较少使用的模型从上下文服务中驱逐出去，具体采用最不经常使用（LFU）策略。其他策略能否进一步提升系统性能，不在本文讨论范围内。

四、评估

PhOSv1 用 10,825 行 Rust 实现。评估回答三个问题：（1）在自动扩缩容下，PhOSv1 能否提升端到端的多模型服务性能？（2）它能否消除让许多模型休眠时线性增长的显存开销？（3）它能否保持原生休眠模式的低扩容时延？

测试环境：单台服务器，配 8 块 NVIDIA A800 GPU（每块 80 GB HBM），本节所有测量只用其中一块 GPU；两颗 Intel Xeon Platinum 8350C CPU，共 64 核；1 TB 内存；CUDA 12.9，vLLM v0.19.1。

对比基线：

• 冷启动（Cold start）：请求到来时从零启动一个原生 vLLM 推理引擎；
• 原生休眠（Vanilla sleep）：使用 vLLM 休眠模式，丢弃 KV cache、把模型参数放在主机内存，之后唤醒同一个 vLLM 引擎；
• PhoenixOS：用检查点与恢复启动引擎，休眠后对进程做检查点，扩容时恢复进程再唤醒。

负载与指标：端到端负载见 4.1 节。如无特别说明，使用 Hugging Face 上下载量高的 16 个 Qwen 和 Qwen-VL 模型。报告的指标包括显存占用、启动时延、端到端首 token 时延（TTFT）、不含排队的 TTFT，以及输入、输出 token 吞吐。端到端 TTFT 指从请求发出到生成第一个 token 的时间，可能包含排在前面请求之后的等待；不含排队的 TTFT 指从系统开始调度目标模型到生成第一个 token 的时间，如果模型未处于活跃状态，则包含其冷启动或唤醒时间。

测量方法：用 NVML 测量 vLLM 进程当前占用的显存。报告 GPU 上下文显存时，在 vLLM 引擎进入休眠后测量，因此不含模型权重。

4.1 端到端实验

实验设置：为评估 PhOSv1 能否在自动扩缩容下提升用户可感知的多模型服务性能，我们按 Aegaeon 的轨迹构造方法生成了一份多模型端到端轨迹：服务 10 个参数量从 0.6B 到 32B 的热门 Qwen 模型；10 分钟的 ShareGPT 轨迹按泊松到达生成，每个模型的请求率为每分钟 0.3 个。这个单模型到达率代表大量长尾模型、请求稀疏的场景——正是需要模型休眠来快速启动的场景。原生休眠基线的休眠缓存预算设为 6 GB，其余显存留给活跃模型的权重和 KV cache；它在预算内尽可能多地保留休眠的 vLLM 实例，推理完成后让模型重新休眠，超出预算时按 LFU 驱逐，模型未被缓存时则冷启动。6 GB 是能保持 vLLM 默认显存分配的最大预算，再大就会压缩 KV cache 容量，从而缩短支持的上下文长度。PhOSv1 与原生休眠使用相同的 vLLM 配置。

总体性能：如原文图 8 所示，与受休眠缓存预算限制的原生 vLLM 相比，PhOSv1 把平均端到端 TTFT 从 146.82 秒降到 19.09 秒，改善 87.0%；p50 TTFT 从 142.39 秒降到 14.65 秒；完成同样负载的活跃服务窗口也更短（578 秒对 728 秒）。改善来自：PhOSv1 能缓存并让所有需要的模型休眠，又不消耗原生休眠模式那样线性增长的 GPU 上下文显存；而基线在显存预算内只能让一小部分模型保持预热，请求未缓存的模型时要付出冷启动延迟，由此产生的排队主导了端到端 TTFT。

技术开销：为评估共享上下文给推理带来的开销，原文图 8 下半部分给出了 PhOSv1 和原生 vLLM 的吞吐（token/s）。PhOSv1 的吞吐至少达到原生 vLLM 的 97.3%，说明共享上下文引入的开销很小。

4.2 GPU 上下文显存缩减与启动性能

原文图 7（左）评估 PhOSv1 能否消除阻碍原生休眠模式扩展到大量缓存模型的显存增长。实验使用图 4 中的 23 个模型，不计模型权重。结果显示，缓存 23 个模型后，原生休眠占用 25.67 GiB 显存，而 PhOSv1 加休眠只占 0.49 GiB，显存占用降低 98.1%。节省来自在上下文服务中共享 CUDA 上下文、对常见内核二进制去重，而不是让每个休眠引擎各持一份私有 GPU 上下文。

原文图 7（右）进一步评估：在增加了上下文服务连接和 API 远程调用层之后，PhOSv1 能否保持休眠模式的低唤醒时延。实验使用 16 个模型，比较冷启动、唤醒休眠的 vLLM 模型、PhoenixOS 和 PhOSv1。结果显示，PhOSv1 的启动时延与原生休眠相当：16 个模型平均 4.12 秒，原生休眠为 4.89 秒，冷启动为 24.41 秒。启动依然很快，是因为昂贵的控制面上下文已在服务中就绪，而每个模型连接上下文服务的开销很小，平均 72 毫秒。（图中冷启动和 PhoenixOS 的权重加载时间已做归一化，剔除了存储 I/O 开销。）

五、讨论

本节讨论 PhOSv1 的若干假设与局限。

第一，PhOSv1 假设共享同一 CUDA 上下文的引擎彼此可信。这一假设适用于模型即服务部署，因为服务各模型的引擎都由服务商自己管理。在不可信引擎之间共享上下文不在本文范围内。

第二，PhOSv1 用 API 远程调用实现上下文共享，可能带来推理开销。选择这种实现方式，是为了在不修改 NVIDIA 闭源 CUDA 驱动的前提下共享上下文。直接在驱动中实现上下文共享可以避免远程调用开销。

最后，PhOSv1 不支持 CUDA Graph。对 CUDA Graph 做检查点与恢复，需要保留或重建图节点中嵌入的设备指针和内核引用，已有工作对此有过讨论。我们把支持 CUDA Graph 留作未来工作。

六、相关工作

Serverless 与 LLM 推理的快速启动。 已有工作通过缓存、检查点/恢复和远程 fork 等方式复用已初始化的执行环境，加速 Serverless 容器启动；相关技术也用于加速虚拟机启动和 GPU 检查点/恢复。在 LLM 推理方面，ServerlessLLM 利用存储局部性快速加载参数；BlitzScale 结合网络传输与协作执行实现快速自动扩缩容；FaaSwap 在 SLO 约束下换入换出权重；Medusa 和 Foundry 通过离线物化加速 CUDA Graph 的构建。这些方法降低了参数加载成本或重建部分执行状态，与 PhOSv1 在休眠引擎间对常驻 GPU 上下文去重互为补充。vLLM/SGLang 的模型休眠和 Aegaeon 避免了启动开销，但每个模型仍保留一份独立的 GPU 上下文（见第二节）。

面向 GPU 的操作系统原语。 NVIDIA MPS 通过共享调度资源支持多个 CUDA 进程并发；PhOSv1 针对的则是休眠引擎之间的 GPU 上下文去重，目的是快速扩容。MIG 把一块 GPU 划分成相互隔离的计算和显存实例，而我们面向的是活跃模型独占整块 GPU 的推理负载。TGS 通过速率控制和统一内存超分在容器间共享 GPU；REEF 提供微秒级内核抢占，Paella 提供软件定义的 GPU 调度，XSched 把抢占式调度扩展到多种 XPU。GPU API 远程调用与虚拟化把应用与物理设备解耦，PhOSv1 正是在 API 远程调用之上实现了跨休眠模型的 GPU 上下文去重。

七、结论

本文提出 GPU 上下文去重，这是首个让单台服务器能让大量模型休眠以实现快速自动扩缩容、又不必缴纳线性显存税的技术。核心洞见是：休眠模型的 GPU 上下文大部分是重复成分，可以通过一个中心守护进程在模型间共享，且对现有推理引擎透明。评估表明，PhOSv1 保留了模型休眠的快速扩容能力，同时大幅降低显存占用，提升了端到端多模型服务性能。

译者注

1. 先分清"数据面"和"控制面"：很多团队优化冷启动时只盯着权重加载（数据面），但本文的数据提醒我们，控制面同样昂贵：创建一个 CUDA 上下文约 430 毫秒，从零冷启动一个 vLLM 引擎平均 24 秒。如果你的推理平台已经用上了本地 NVMe 缓存或 RDMA 加载权重，下一步值得看的就是引擎进程本身的初始化开销。
2. 落地时注意边界条件：PhOSv1 的结论建立在几个前提上——单个 GPU 同一时刻只有一个模型活跃、共享上下文的引擎彼此可信、不使用 CUDA Graph。vLLM 默认会捕获 CUDA Graph 来降低解码时延，若要尝试类似方案，需要评估关闭它（如 enforce-eager）带来的吞吐损失。多租户场景下，不同客户的模型共享同一 CUDA 上下文意味着隔离边界变弱，公有云上需要谨慎。另外，实验只在 A800 和 Qwen 系列模型上完成，换用其他架构或模型家族时，内核重叠率可能不同。
3. 与华为云产品的关系：在华为云弹性云服务器 ECS 的 GPU 加速型实例上自建 vLLM/SGLang 多模型推理服务时，可以先用 vLLM 的休眠模式压缩扩容时间，再按本文方法估算每个休眠模型的上下文显存占用，确定每卡休眠多少个模型、留多少显存给 KV cache。昇腾平台上也有类似的设备上下文（Context）与算子二进制加载开销，"共享上下文、对算子二进制去重、缓冲区按需重建"的思路同样值得参考，但具体可行性取决于对应运行时的接口，需要自行验证。

相关阅读

• 竞价实例跑 Serverless 工作流不怕被回收：FaaSpot 按 DAG 结构分级容错，成本降一半（https://bbs.huaweicloud.com/blogs/0eb752350f164b0c8478911194445196）