Towards Efficient and Practical GPU Multitasking in the Era of LLM

文章标题：迈向大语言模型时代高效实用的 GPU 多任务处理
作者/机构：Jiarong Xing†⋄, Yifan Qiao†, Simon Mo†, Xingqi Cui⋄, Gur-Eyal Sela†, Yang Zhou†‡, Joseph Gonzalez†, Ion Stoica†
†UC Berkeley ⋄Rice University ‡UC Davis

A1 主要贡献

本文探讨了在当前大语言模型（LLM）时代，GPU 单任务（singletasking）范式日益低效和不可持续的问题。随着硬件能力的大幅提升和工作负载的多样化，GPU 系统正处于一个必须像几十年前的 CPU 一样拥抱多任务（multitasking）的拐点。

核心问题与研究目标：
1. GPU 单任务范式的低效性：由于两大趋势，GPU 单任务模式变得越来越低效。首先，GPU 硬件能力在过去十年中实现了巨大飞跃，峰值吞吐量增长超过1000倍，内存容量和带宽也增长了20多倍。其次，AI 工作负载变得日益多样化和动态，小型模型难以充分利用大型 GPU 的算力，为峰值负载配置的 GPU 在非高峰时段处于空闲状态，导致数据中心 GPU 利用率极低（例如，推理场景低至10%）。这种低效率浪费了能源和资本。
2. GPU 多任务处理的需求：为了提高硬件利用率和降低计算成本，GPU 系统必须转向多任务范式。本文旨在明确高效实用的 GPU 多任务处理所需满足的关键要求，并提出一个实现这一目标的系统愿景。

核心创新与贡献：
本文的核心贡献并非提出一个已完全实现的系统，而是一个对未来 GPU 资源管理框架的构想和展望。
1. 明确了 GPU 多任务的四大关键要求：
* 高资源利用率：最大化 GPU 整体利用率，包括计算和内存资源。
* 性能保证：为性能关键型应用提供资源隔离，确保其满足性能目标。
* 故障隔离：在多租户环境中，一个应用的失败不应影响其他共存应用。
* 大规模部署：支持在数据中心与 Kubernetes 等现代集群管理器集成。

  1. 分析了现有技术的局限性：系统性地审视了工业界（如 MIG, FGPU, MPS）和学术界（如 Orion, REEF, Paella）的现有 GPU 多任务技术，并指出了它们的共同局限性：

    • 无法同时实现高利用率和性能保证。
    • 过度关注复杂的空间共享，而忽视了隔离性更好、实现更简洁的时间共享。
    • 主要关注计算共享，而忽视了在 LLM 时代日益关键的内存共享。
    • 缺乏与 Kubernetes 等主流编排框架的集成，难以大规模部署。

  2. 提出了一个统一的 GPU 资源管理层愿景：设想构建一个位于硬件和应用之间的 GPU 资源管理层，其功能类似于 CPU 的操作系统。该层将负责管理共享资源，以满足上述四大关键要求。具体而言，该层应具备以下能力：

    • 支持快速、动态的资源划分。
    • 实现高效的内存虚拟化。
    • 通过协同调度实现高利用率和性能保证。
    • 确保故障隔离。
    • 管理网络资源共享。
    • 为大规模部署提供清晰的接口。

作者希望通过本文激发更广泛的社区努力，共同构建基于多任务处理的下一代 GPU 计算范式，并已将初步努力开源至 openvgpu 项目。

A3 背景知识与关键观察

GPU 硬件与软件背景

硬件结构。GPU 硬件为大规模并行计算设计，拥有数百个流式多处理器（Streaming Multiprocessors, SMs），可同时执行数千个线程。每个 SM 包含一组核心、寄存器文件、共享内存（L1 缓存）和线程调度器。线程被组织成线程束（warps），再进一步组织成线程块（thread blocks），由硬件调度器动态分配给 SMs 执行。GPU 拥有一个多层内存结构，包括每个 SM 内的 L1 缓存、一个 L2 缓存以及所有 SM 共享的全局内存，内存容量逐级增大但访问延迟也相应增加。

单任务调度。NVIDIA 提供了 CUDA API 以简化 GPU 编程【18, CUDA C++ Programming Guide, 2025, NVIDIA】。开发者通过 CUDA API 将并行程序编写为内核（kernels），这是 GPU 程序的基本单元，类似于 CPU 上的函数。当一个内核被启动时，CUDA 运行时会将其划分为多个线程块以准备执行。随后，CUDA 驱动程序将内核及相关数据传输到 GPU。最后，GPU 硬件调度器动态地将线程块分配给 SMs 执行。CUDA 一次只调度一个内核，并期望所有 GPU 资源都专用于尽快执行该内核。CUDA 任务队列强制执行严格的顺序执行，即内核按照其被分派的顺序排队和执行。

GPU 单任务模式面临的挑战

单任务模式的适用性与当前困境。单任务模式非常适合单个应用能完全饱和 GPU 的场景，如图形渲染或批处理的高性能计算任务。然而，随着 GPU 硬件的进步和工作负载向 AI 主导的转变，单任务模式已变得日益低效且不可持续。

GPU 能力的巨大飞跃。如今的 GPU 与十年前的已大不相同——GPU 硬件发展迅速。如图 1a 所示，过去十年间，数据中心 GPU 的计算吞吐量在硬件并行度和混合精度计算支持的推动下增长了超过 1000 倍。同时，GPU 内存容量也扩大了 20 多倍，如今的 NVIDIA B300 GPU 已达到 288 GB。预计未来 GPU 将延续这一增长趋势【29, The Blue Lion Supercomputer Will Run on NVIDIA Vera Rubin, 2025, NVIDIA Blog】。


图 1: 在 LLM 时代，GPU 单任务模式是低效且不可持续的。

工作负载的转变。现代 GPU 的使用主要由 AI 训练和推理工作负载主导，这给传统的单任务范式带来了新的挑战。主要体现在以下三个方面：

  1. GPU 与模型尺寸比例的扩大。一方面，超大模型（>600B 参数）不断涌现【14, DeepSeek-V3 Technical Report, 2024, arXiv】，推动了对更大容量 GPU 的需求。另一方面，小型蒸馏模型（<10B 参数，如 Meta Llama-3.2 【15, Introducing quantized Llama models..., 2024, Meta】和 gpt-oss-20B 【31, Introducing gpt-oss, 2025, OpenAI】）在特定任务上的表现可与大模型媲美，并获得了更广泛的部署【10, Distilling Step-by-Step!..., 2023, arXiv】【43, Densing Law of LLMs, 2024, arXiv】【49, LoRA Land: 310 Fine-tuned LLMs that Rival GPT-4..., 2024, arXiv】。这使得 GPU 与模型尺寸的比例不断扩大，导致小型模型难以充分利用单个 GPU 的全部容量。
  2. 负载可变性的增加。AI 流量负载随时间变化剧烈。训练过程中的数据加载、检查点保存和网络通信等阶段会导致 GPU 利用率的剧烈波动。推理负载的动态性更强，研究表明【35, ConServe: Harvesting GPUs for Low-Latency and High-Throughput Large Language Model Serving, 2024, arXiv】【40, Towards Efficient and Reliable LLM Serving: A Real-World Workload Study, 2024, arXiv】，推理请求率可在数分钟内剧烈波动（例如增加3倍）。LLM 的自回归解码过程【13, Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023, SOSP】进一步加剧了这种不可预测性。为保证服务质量，系统必须按峰值流量进行资源配置，导致非高峰时段资源闲置。
  3. 工作负载异构性的拓宽。AI 工作负载正变得更加复杂和异构。例如，大模型训练越来越依赖小模型推理进行数据预处理【44, Reducing the Cost of Pre-training Stable Diffusion by 3.7x with Anyscale, 2025, Anyscale Blog】，而复合 AI 系统【46, The Shift from Models to Compound AI Systems, 2024, BAIR Blog】则混合使用多个模型完成一项任务。不同模型和组件具有不同的资源需求（计算密集型 vs. 内存密集型）和性能目标（交互式 vs. 批处理），一次只运行一个任务很容易在一种资源上造成瓶颈，而使其他资源未被充分利用【50, BlendServe..., 2024, arXiv】【52, NanoFlow..., 2024, arXiv】。

单任务模式导致低利用率的总结。因此，单任务模式很容易导致 GPU 利用率低下。为了说明这一点，我们通过重放一个流行模型提供商的生产流量，测量了在 A100 GPU 上运行单个 LLaMA-3-8B 模型的计算和内存利用率。如图 1b 所示，GPU 的计算和内存资源都远未得到充分利用，这凸显了在现代服务场景中将整个 GPU 专用于单个模型的低效性。

从单任务到多任务的转变

多任务处理的必要性和关键要求。上述讨论凸显了 GPU 多任务处理的迫切需求。这一转变为在 GPU 上更高效地处理 AI 工作负载提供了可能，从而降低资本和能源成本，并进一步加速 AI 驱动服务的发展。我们认为，高效且实用的 GPU 多任务处理应满足以下要求并应对相应挑战：
* 高利用率：多任务处理的主要目标是提高 GPU 资源利用率，包括计算和内存资源。这要求系统能够尽可能地回收和再利用闲置资源，减少资源空闲时间。
* 性能保证：高利用率不应以牺牲应用性能为代价，特别是对于性能关键型任务。因此，GPU 多任务处理必须提供资源隔离，确保此类任务在需要时能获得足够的资源以满足其性能目标。解决高利用率和性能保证之间矛盾的关键在于实现快速、细粒度的动态资源划分。
* 故障隔离：在一个应用中发生的故障或崩溃不应影响在同一 GPU 上运行的其他应用，这对于多租户环境至关重要。然而，当前 GPU 系统在空间共享模式下并未提供原生的故障隔离机制。
* 大规模部署：GPU 多任务处理应支持在云数据中心进行大规模部署，这需要与现代集群管理器（如 Kubernetes 【12, Production-Grade Container Orchestration, 2025, Kubernetes】）以及 LLM 专用的部署系统（如 LLM-D 【38, llm-d..., 2025, http://llm-d.ai】、Dynamo 【20, Dynamo..., 2025, NVIDIA】 和 OME 【39, OME..., 2025, GitHub】）集成。

现有技术的局限性

现有技术概述与共同缺陷。尽管已有一些工作在 GPU 多任务处理方面取得了初步进展（如表1所示），但它们普遍存在一些共同的局限性，使其无法满足高效和实用的 GPU 多任务处理的关键要求。
* 资源共享不灵活：工业界的实践，如 Multi-Instance GPU (MIG) 【27, NVIDIA Multi-Instance GPU, 2025, NVIDIA】、Fractional GPU (FGPU) 【1, Implementing Fractional GPUs in Kubernetes..., 2024, Hugging Face】【2, GPU Sharing Scheduler..., 2023, Aliyun】【36, Quickstart: Launch Workloads with GPU Fractions, 2023, Run:ai】和 Multi-Process Service (MPS) 【17, NVIDIA Multi-Process Service, 2024, NVIDIA】，均采用静态资源分配，无法适应动态的工作负载需求，因此难以实现高利用率。
* 缺乏性能保证：学术界的研究工作如 Orion 【37, Orion: Interference-aware, Fine-grained GPU Sharing..., 2024, EuroSys】、REEF 【8, Microsecond-scale Preemption for Concurrent GPU-accelerated DNN Inferences, 2022, OSDI】、Paella 【16, Paella: Low-latency model serving..., 2023, SOSP】和 TGS 【42, Transparent {GPU} sharing in container clouds..., 2023, NSDI】虽然通过自定义内核调度器提高了计算共享的灵活性，但由于不同内核可以任意使用资源，它们缺乏实现性能保证所需的资源隔离。
* 缺乏故障隔离：LithOS 【6, LithOS: An Operating System for Efficient Machine Learning on GPUs, 2025, arXiv】、BLESS 【47, Improving GPU Sharing Performance..., 2025, EuroSys】和 SGDRC 【48, SGDRC: Software-Defined Dynamic Resource Control..., 2025, PPoPP】虽然通过对每个内核强制执行资源限制来增强资源隔离，但它们的实现依赖于 MPS 进行空间共享，而 MPS 使用共享的 CUDA 执行上下文，损害了故障隔离。
* 忽视内存共享：大多数技术都集中在计算共享上，而忽视了内存共享。它们通常假设内存可以静态划分且总能容纳在 GPU 容量内。然而，这一假设在 LLM 工作负载下不再成立，因为 LLM 的内存消耗会随着输入和输出长度动态增长，使内存更容易成为瓶颈。
* 不支持大规模部署：尽管 FGPU 和 TGS 可以与 Kubernetes 集成，但它们缺乏对动态资源供应的支持，也未解决分布式环境下的网络共享问题。它们都假设容器启动后其资源分配保持不变，这限制了 GPU 共享的灵活性。


表 1: 最先进的 GPU 多任务技术总结。MIG、FGPU 和 MPS 是常见的工业实践，其余为研究工作。C: 计算；M: 内存；S: 空间共享；T: 时间共享。

A2 方法细节

本节我们讨论实现高效实用 GPU 多任务处理所面临的挑战和潜在技术。我们设想这些技术构成一个统一的 GPU 资源管理层，其功能类似于 CPU 操作系统，能够协调计算和内存共享，在提供性能保证的同时实现高资源利用率，确保故障隔离，并支持大规模部署。

3.1 计算资源复用

计算资源复用的两种方式。计算复用主要涉及共享 SM 核心，这是并行执行 GPU 内核的基本硬件单元。共享 SM 有两种方式：（1）时间共享（temporal sharing），每个任务在其时间片内获得所有 SM，任务间随时间进行上下文切换；（2）空间共享（spatial sharing），多个任务同时在不同的 SM 子集上运行。

关键挑战。这里的关键挑战在于实现灵活的计算复用，允许系统以细粒度共享 GPU 计算资源，根据工作负载需求动态调整分区方案，并强制执行资源限制以确保性能保证。

灵活的计算复用方案。对于时间共享，我们认为内核粒度调度——即拦截内核启动并选择执行哪个任务的内核——提供了一种实用且足够有效的解决方案。由于目前的 GPU 不支持手动抢占正在运行的内核，任务切换只能在内核完成后发生。然而，对于大型现代 AI 模型而言，单个内核的执行时间相对于整体请求延迟通常较短（例如，一个 Llama3-8B 模型在批大小为 8 时所有内核都能在 10ms 内完成，而端到端推理通常需要数秒），这使得该方法在许多情况下是有效的。

时间分片技术的应用。在需要毫秒级延迟的场景中，我们建议利用大多数现代 GPU 上可用的时间分片（time-slicing）功能【30, Time-Slicing GPUs in Kubernetes, 2025, NVIDIA】，该功能在内核用尽其分配的时间片时自动切换执行上下文。虽然当前的时间分片实现仅支持静态分片长度以实现公平共享，但 NVIDIA 【26, NVIDIA Linux open GPU kernel module source, 2025, NVIDIA】和 AMD 【3, AMD ROCm documentation, 2024, AMD】近期开源的 GPU 驱动为在驱动层面实现更灵活、动态的时间片调度带来了机会。

空间共享的实现方法。对于空间共享，先前的工作【6, LithOS: An Operating System for Efficient Machine Learning on GPUs, 2025, arXiv】【47, Improving GPU Sharing Performance..., 2025, EuroSys】【48, SGDRC: Software-Defined Dynamic Resource Control..., 2025, PPoPP】试图通过限制内核启动的线程块数量来约束其可访问的 SM 数量，以克服 MIG 【27, NVIDIA Multi-Instance GPU, 2025, NVIDIA】和 MPS 【17, NVIDIA Multi-Process Service, 2024, NVIDIA】的僵化性。然而，这种间接方法通常需要修改内核实现，因此不切实际。我们提出一种替代方案：在内核启动时直接控制其可用的 SM 数量。这可以通过使用最近开发的库 libsmctrl 【4, Hardware Compute Partitioning on NVIDIA GPUs, 2023, RTAS】来实现，该库能够屏蔽特定 SM 对内核的可见性。这种方法在驱动层面操作，对应用程序保持透明。

时间共享与空间共享的权衡。时间和空间共享代表了不同的权衡。时间共享相对简洁且易于实现。当通过时间分片实现时，它提供强大的资源隔离，但会产生上下文切换开销（例如，每次切换约 100µs）。另一方面，空间共享避免了上下文切换开销，但在调度和资源隔离方面引入了额外的复杂性。例如，像内存带宽这样的共享资源难以隔离，并且由于缺乏手动内核抢占支持，SM 在内核运行时无法重新分区。此外，我们将在 3.4 节讨论，空间共享会因共享单个 CUDA 上下文而损害故障隔离。相比之下，时间共享通过允许每个任务在自己的上下文中运行，自然地保持了隔离性。

共享策略的选择与组合。没有绝对的理由在所有情况下都偏好一种策略。我们认为，时间共享和空间共享之间的选择应取决于工作负载特性和优先考虑的具体目标。如果资源和故障隔离至关重要，通过时间分片实现的时间共享能提供更强的隔离保证。相反，如果最大化资源利用率是主要目标，空间共享则具有同时执行多个内核的优势，从而提高硬件效率，特别是当单个内核太小而无法完全占用整个 GPU 时。

时空混合共享。此外，某些场景允许将两种策略结合起来，实现时空混合共享（temporal–spatial sharing）。例如，可以使用 MIG 在需要强性能和故障隔离的租户之间对 GPU 进行空间分区。在给定的租户内部，工作负载可以时间共享分配到的 MIG 分片。动态 MIG 分片技术的最新进展【23, NVIDIA DRA Driver for GPUs, 2025, NVIDIA】【32, InstaSlice Operator..., 2025, OpenShift】进一步使租户能够根据需求在不同大小的分片之间迁移，从而在资源利用率和性能保证之间实现更好的平衡。

3.2 内存资源复用

内存复用的重要性日益凸显。内存复用在先前的工作中很大程度上被忽视了，但它正变得越来越关键，原因有二。首先，由于模型尺寸增大和中间状态（如 KV 缓存）增多，LLM 时代的内存消耗显著增长，使内存更有可能成为瓶颈。其次，由于 LLM 生成过程的非确定性（即自回归生成），内存使用现在更具动态性和不可预测性，即使是相同的输入也可能产生不同长度的输出，从而导致不同的内存使用量。

关键挑战。CPU 操作系统通过虚拟内存和页错误处理实现了灵活、细粒度的内存管理。然而，GPU 历来被用作单任务设备，因此缺乏用于虚拟内存和页错误处理的开放接口。因此，传统的 GPU 应用通常静态地预留一块物理内存并手动管理。实际上，大多数现代 AI 应用依赖于像 PyTorch 【33, Pytorch: An imperative style, high-performance deep learning library, 2019, NeurIPS】这样的框架，这些框架抽象了这一过程并在后台处理 GPU 内存管理。

利用 CUDA 虚拟内存 API。一个新兴的机会是最近发布的 CUDA 虚拟内存 API 【19, CUDA Toolkit Documentation—Virtual Memory Management, 2025, NVIDIA】，它解耦了虚拟内存和物理内存的分配，为在 GPU 上实现虚拟内存机制奠定了基础。借助这些 API，应用程序可以预先保留虚拟内存，系统可以按需以细粒度的页面（例如 2MB）映射物理内存。

集成虚拟内存的挑战。然而，将这种虚拟内存机制与现有的 AI 应用集成带来了新的挑战。如前所述，这些应用通常实现自己的内存管理。例如，当内存被释放时，PyTorch 可能会将其保留在自己的缓存中，而不是返回给系统，这使得跟踪实际使用情况和及时回收未使用的内存变得困难。

支持 GPU 虚拟内存的方案。为了在不改变应用程序代码的情况下解决虚拟内存的挑战，我们建议在 GPU 驱动中拦截与内存相关的 API 调用，例如分配和释放。例如，当应用程序调用 cudaMalloc 时，我们拦截它并用我们的虚拟内存 API 替换它。之后，我们可以监控系统内存使用情况，按需分配和映射物理内存，或者反过来回收它。

语义感知的内存共享。使用上述方法应用 GPU 虚拟内存的一个注意事项是，如果应用程序没有显式调用内存释放 API（如前述 PyTorch 的例子），系统就缺乏回收该内存所需的上下文。为了弥合这一语义鸿沟，我们建议利用这些框架提供的可定制内存分配器【34, torch.cuda.memory.change_current_allocator..., 2025, PyTorch】，并对其进行扩展以与 GPU 驱动程序合作。这使系统能够准确跟踪内存使用情况，及时回收未使用的内存，并根据需要将其重新分配给其他应用程序以提高性能。

内存交换机制。当 GPU 内存被超额订阅时，可能会发生内存不足错误，导致正在运行的应用程序崩溃。为了缓解这种情况，我们提出了一种透明的内存交换技术。当系统检测到内存压力时，它会通过高速 GPU-CPU 互连（如 NVLink 或 PCIe，这是现代 GPU 服务器的标准配置【24, NVIDIA GH200 Grace Hopper Superchip, 2025, NVIDIA】）自动将页面驱逐到 CPU DRAM。为避免频繁驱逐活动页面，我们还可以利用语义感知的内存共享框架进行引导式交换。例如，PyTorch 分配器可以与驱动程序共享有关非活动内存的信息，使其能够做出更明智的驱逐决策。这种方法可以有效缓解由内存交换引起的性能下降。

KV 缓存的内存共享。KV 缓存内存是一个例外，因为其常规的使用模式实际上简化了问题。KV 缓存通常由当今的开源 LLM 推理引擎管理，例如 vLLM 【13, Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023, SOSP】和 SGLang 【51, SGLang: Efficient Execution of Structured Language Model Programs, 2024, NeurIPS】。虽然目前的实现是静态预留 GPU 物理内存而不考虑内存共享，但它们为 KV 缓存管理提供了定义良好的接口（例如 alloc/free 函数）。这为实现内存共享提供了一条更简单的路径——正如我们之前的工作【45, Prism: Unleashing GPU Sharing for Cost-Efficient Multi-LLM Serving, 2025, arXiv】所提议的，用我们的虚拟内存实现替换它们的 KV 缓存管理函数，可以在不修改 GPU 驱动程序的情况下实现灵活的内存共享。

3.3 资源协调

弹性资源划分。我们建议将资源配置为两种类型：保证资源（guaranteed）和可抢占资源（preemptible）。任务始终有权不间断地使用其保证资源。当存在空闲 GPU 容量时，任务可以将其用作可抢占资源以提升性能。


图 2: 两个内核的计算效用。

可抢占资源的回收。然而，这些可抢占资源可以被系统回收，以满足其他进程的保证资源需求。同时，如果一个任务没有完全利用其保证分配，我们可以暂时将未使用的部分作为可抢占资源分配给其他任务，直到原始任务需要它为止。

协作式抢占。当一个任务需要当前被可抢占任务使用的保证资源时，系统必须迅速回收这些资源以确保性能。回收计算资源相对直接：系统可以等待当前时间片或内核完成，然后重新调整分配。相比之下，内存抢占更具挑战性，因为系统必须保留应用程序数据——简单地通过删除数据来回收内存会导致应用程序崩溃。为了解决这个问题，我们可以重用 3.2 节中讨论的透明内存交换机制。系统可以临时将数据交换到 CPU 内存，而不是删除数据。此外，通过引入扩展的 PyTorch 内存分配器，我们可以获得应用程序级别的语义来帮助指导交换决策。这使系统能够优先驱逐未使用或不活跃的内存，并避免频繁交换活动数据，否则会降低性能。

效用引导的协调。可用的可抢占资源可以使用可定制的策略（如最大最小公平调度【41, Max-Min Fairness, 2023, Wikipedia】）在任务间共享。我们提出一种效用引导（utility-guided）策略，该策略根据任务效率动态分配资源，以提高整体硬件计算利用率。其核心思想是，不同的内核在分配更多资源时会产生不同的性能增益。为了量化这一点，我们定义了一个名为效用（utility）的指标，它量化了内核相对于使用整个 GPU 所达到的性能比例。如图 2 所示，Kernel1 表现出近线性的效用增长，而 Kernel2 则迅速饱和。这意味着分配相同的额外资源可能导致不同内核的效用提升差异巨大。例如，超过 60% 的 SM 分配后，为 Kernel2 增加 SM 分配只会带来边际效益。系统可以利用这些效用曲线来指导资源分配，并优化可抢占资源的整体效用。

3.4 故障隔离

故障隔离的重要性。故障隔离在多租户环境下的 GPU 多任务处理中至关重要。它确保一个任务中的故障（无论是由计算单元、内存控制器还是其他组件触发）不会损害共享同一 GPU 的其他任务的正确性或执行。

不同共享方式下的故障隔离。在 GPU 上，每个进程维护一个封装其执行状态的 CUDA 上下文。这个上下文对于正确执行至关重要；如果上下文中发生错误，相关进程将崩溃。GPU 时间共享天然提供了故障隔离，因为每个任务都在自己的进程中运行，拥有独立的上下文。因此，一个任务中的故障不会传播到其他任务。

空间共享的故障隔离挑战。然而，对于空间共享，只有通过 MIG 【27, NVIDIA Multi-Instance GPU, 2025, NVIDIA】才支持故障隔离，MIG 将 GPU 硬件物理划分为静态的、固定大小的分片。在没有 MIG 的情况下，空间共享 GPU 的唯一方法是通过 MPS 【27, NVIDIA Multi-Process Service, 2024, NVIDIA】，它将多个进程合并到一个共享的 CUDA 上下文中。因此，基于 MPS 的解决方案会损害故障隔离，因为一个任务中的错误可以传播到整个共享上下文并导致所有任务崩溃。

提出解决方案。我们认为，这一限制更多地源于 GPU 软件栈，而非根本的硬件约束。根据 NVIDIA 的报告【27, NVIDIA Multi-Instance GPU, 2025, NVIDIA】，现代 GPU 已经包含多个可以独立分配给不同进程的计算引擎、内存控制器和复制引擎。MIG 正是利用了这种能力通过静态分区来提供隔离。因此，我们建议重构 GPU 运行时和驱动程序，以支持空间共享下的故障隔离作为一等公民特性。我们的关键思想是在 GPU 内核驱动【26, NVIDIA Linux open GPU kernel module source, 2025, NVIDIA】中，在内核启动时跟踪分配给每个内核的特定硬件组件（例如，哪个 SM 组）。当发生硬件故障时，驱动程序可以根据硬件组件的分配情况识别出故障的内核和进程，优雅地终止它，并允许其他任务继续运行而不受干扰。

3.5 在云端进行大规模部署

大规模部署面临的新挑战。AI 工作负载主要托管在大型云数据中心。然而，将 GPU 多任务处理扩展到多 GPU 服务器和多节点集群，在实例管理和网络共享方面引入了新的挑战。

与管理工具的集成。Kubernetes 【12, Production-Grade Container Orchestration, 2025, Kubernetes】已成为云数据中心事实上的容器编排框架，近年来也出现了基于其上的 LLM 部署框架，如 LLM-D 【38, llm-d..., 2025, http://llm-d.ai】、Dynamo 【20, Dynamo..., 2025, NVIDIA】和 OME 【39, OME..., 2025, GitHub】。为了支持大规模部署，GPU 多任务处理必须无缝集成到它们的生态系统中。然而，当前 Kubernetes 的设备插件模型假设设备是静态的：GPU（或 MIG 分片）在 kubelet 启动时被枚举，然后调度器将它们视为不可变的、整数计数的资源。因此，动态 GPU 共享将违反这些假设，使其与 Kubernetes 不兼容。幸运的是，Kubernetes 中关于动态资源分配（Dynamic Resource Allocation, DRA）的最新提案【11, Dynamic Resource Allocation, 2025, Kubernetes】提供了一条有希望的前进道路。通过扩展 DRA，我们可能能够在数据中心规模上实现灵活、细粒度的 GPU 共享，并获得原生的容器编排支持。

与上层框架的协调。此外，这些框架已经包含了它们自己的控制循环、自动伸缩器和路由层，因此多任务系统也应与它们的调度和伸缩决策相协调。它可能还需要管理跨内存层级的 KV 缓存分层，并暴露标准化的指标以支持联合自动伸缩和路由。为了在大规模部署中维持服务等级目标（SLO），工作负载感知的放置、动态适应和故障安全的抢占也同样至关重要【45, Prism: Unleashing GPU Sharing for Cost-Efficient Multi-LLM Serving, 2025, arXiv】。

网络共享。在同一 GPU 上运行的任务也可能共享网络资源。对于时间共享来说，这相对直接，因为每个任务可以在其时间片内正常使用网络。然而，空间共享会带来几个挑战。首先，系统必须使像 NCCL 【22, NVIDIA Collective Communications Library (NCCL), 2025, NVIDIA】这样的通信库能够将 GPU 分片识别为独立的设备。在当前的实现中，除非启用了 MIG 【27, NVIDIA Multi-Instance GPU, 2025, NVIDIA】，否则 NCCL 将每个物理 GPU 视为单个设备。一个可能的解决方案是通过扩展内核级支持来暴露逻辑 GPU，类似于 SR-IOV 【7, High performance network virtualization with SR-IOV, 2010, HPCA】为网络设备创建虚拟功能的方式。这将允许每个 GPU 分片被通信栈独立寻址和调度。

通信资源隔离。第二个挑战是隔离通信资源以提供性能保证。在现代 GPU 机器上，节点内通信通常使用 NVLink 【28, NVLink & NVSwitch..., 2025, NVIDIA】，而节点间通信则通过 GPUDirect RDMA 【21, GPUDirect, 2025, NVIDIA】高效处理。像 NCCL 这样的通信库可以自动在这些路径之间选择。然而，当前硬件缺乏对 NVLink 带宽进行切片或分区的原生支持。一个潜在的解决方法是拦截 NCCL 启动的通信内核（用于 NVLink 和 RDMA 传输），并在该层级强制执行自定义的调度或共享策略。

A7 补充细节

4 开放性问题

安全隔离。GPU 多任务处理应确保安全性，例如，保护合法任务免受恶意或有问题的共存任务的影响。我们提出的虚拟内存设计为不同任务强制执行独立的虚拟地址空间，提供了基本的内存安全。然而，要完全消除其他安全漏洞，如侧信道攻击，仍然是一个开放性问题。

内存带宽控制。在 GPU 空间共享下，内存带宽隔离对于性能保证也很重要。然而，当前的 GPU 硬件没有提供直接控制内存带宽的机制。即使是物理上划分其他 GPU 资源的 MIG 【27, NVIDIA Multi-Instance GPU, 2025, NVIDIA】，也无法对内存带宽进行精确控制。一个关键挑战是，内存带宽消耗往往不与活动 SM 的数量成线性关系。例如，仅 20% 的 SM 就可能饱和整个内存带宽。一个潜在的变通方法可能是对内存加载/存储指令进行插桩，并插入空操作（no-ops）来延迟执行。通过调整这些延迟，系统可以节流内存访问并控制带宽。

A4 实验环境与结果

实验环境

本文是一篇展望性（vision）论文，并未提供详尽的实验设置。文中提到的唯一具体实验配置用于图1b的动机性示例：
* 模型: LLaMA-3-8B
* 硬件: 单个 NVIDIA A100 GPU
* 负载: 重放来自一个流行模型提供商的生产流量追踪。

实验结果

本文没有提供系统的实验评估结果，其主要内容是提出一个 GPU 多任务处理的框架和愿景。
* 动机性实验结果 (图1b)：该实验展示了在单任务模式下，将整个 A100 GPU 专用于服务 LLaMA-3-8B 模型时，计算（SM Occupancy）和内存（Memory Usage）利用率都非常低。SM 占用率长期低于 15%，而内存利用率在请求处理阶段最高也仅达到约 50%。这直观地证明了单任务模式在现代 LLM 服务场景下的低效性，从而引出对多任务处理的迫切需求。

A5 结论

本文论证了随着 GPU 硬件能力的飞速发展和 AI 工作负载的日益多样化，传统的 GPU 单任务范式已变得低效且不可持续。为了应对这一挑战，GPU 系统正处于一个必须拥抱多任务处理的转折点。

论文明确了高效实用的 GPU 多任务处理应满足的四个关键要求：高资源利用率、性能保证、故障隔离和大规模部署支持。通过分析现有工业界和学术界方案的局限性，本文提出了一个构建统一 GPU 资源管理层的愿景。该层的功能类似于一个操作系统，旨在通过灵活的计算与内存复用、协作式资源协调、可靠的故障隔离以及与云原生生态系统的深度集成，来满足上述所有要求。

本文详细探讨了实现这一愿景所面临的挑战和潜在的技术路径，希望能启发社区进行更广泛的努力，共同构建基于多任务处理的下一代 GPU 计算范式，使高效、实用的 GPU 规模化共享成为现实。作者的初步工作已通过 openvgpu 项目开源。