CMU与Meta提出LithOS：节省 GPU51% 容量、26%能耗，迈向高效机器学习操作系统

关键词：GPGPU、软件资源调度、机器学习

机器学习（ML）工作负载在数据中心对 GPU 的需求激增，使得高效利用 GPU 变得至关重要。然而，在满足各个 ML 模型的多样化需求的同时优化资源使用是一个挑战。

为了实现透明的、细粒度的 GPU 资源管理，以最大化 GPU 利用率和能源效率，同时保持强大的隔离性，需要一种操作系统（OS）方法。

因此，本文介绍了 LithOS，这是迈向 GPU 操作系统的第一步。LithOS 包括以下用于高效 GPU 资源管理的新抽象和机制：

1.一种新颖的 TPC （Thread Processing Cluster）调度程序，支持以单个 TPC（线程处理簇）为粒度的空间调度，解锁工作负载间高效的 TPC 借用（stealing）；

2.透明的 GPU 内核原子化（kernel atomization），减少队首阻塞（head-of-line blocking），并允许在执行中途动态重新分配资源；

3.一种轻量级的硬件适配（rightsizing）机制，动态确定每个原子（atom）所需的最小 TPC 资源；

4.一种透明的电源管理机制，根据在 in-flight 工作特征降低功耗。NeuralTalk 注：“in-flight” 通常用来描述那些已经被提交给 GPU 并且正在处理过程中的工作或操作。简单来说，“in-flight” 的工作就是那些已经被 GPU 接收并开始处理，但尚未完成的工作。这些工作可能处于不同的执行阶段，比如正在等待执行、正在执行，或者已经执行完毕但结果尚未返回等状态。

我们用 Rust 实现了 LithOS，并在深度学习环境中评估其性能，将其与 NVIDIA 的最新解决方案以及先前研究进行了比较。

在推理（inference）堆叠（stacking，指多个任务或工作负载同时在 GPU 上执行的过程）方面，与 MPS（多进程服务）相比，LithOS 将尾部延迟（tail latencies）降低了 13 倍；
与表现最佳的现有技术（SotA）相比，它将尾部延迟降低了 3 倍，同时将总吞吐量（aggregate throughput）提高了 1.6 倍。
此外，在混合推理 - 训练堆叠方面，与 MPS 相比，LithOS 将尾部延迟降低了 4.7 倍；与表现最佳的 SotA 相比，它将尾部延迟降低了 1.18 倍，同时将总吞吐量提高了 1.35 倍。

最后，对于不到 4% 的性能损失下，LithOS 的硬件适配平均节省了四分之一的 GPU 计算容量（capacity）；而对于 7% 的性能损失下，LithOS 的透明电源管理平均节省了四分之一的 GPU 总能耗。总体而言，LithOS 透明地提高了 GPU 效率，为未来的 GPU 操作系统研究奠定了基础。

https://arxiv.org/abs/2504.15465

一、引言

机器学习（ML）工作负载的广泛采用导致了 GPU 在数据中心的大规模部署。然而，尽管人们越来越关注功耗和硬件供应限制，但 GPU 资源仍然显著未被充分利用。

微软和阿里巴巴的公开报告指出，平均和中位 GPU 利用率分别仅为 52% [23] 和 10% [49]。我们对 Meta 生产环境中的一个广告（Ads）推理服务的分析也显示了类似的低利用率，平均仅为 27%，如图 1 所示。

鉴于 GPU 的高成本和日益增长的功耗需求（现在每 GPU 超过 1,000W[26, 31]），这种情况是不可持续的。要在不进行 GPU 共享的情况下实现高利用率是非常具有挑战性的。虽然将 GPU 专用于单个工作负载可以实现高性能，但单个工作负载通常无法充分利用 GPU：由于通信停滞导致 GPU 核心闲置、小批量导致并行性不足、动态请求负载导致过度配置等[18, 20, 49]。

随着 GPU 变得更强大（流式多处理器（SM）数量和内存带宽不断增加[8, 31]），实现高利用率将变得更加困难。

一种潜在的 GPU 共享方法是将对延迟敏感的（latency-critical，LC）任务（性能至关重要）与尽力而为的（best-effort，BE）任务（没有硬性截止时间）共同放置（collocate）。

然而，现有系统在资源竞争时没有提供实际的解决方案来优先处理 LC 任务。许多方法缺乏透明性，导致它们与 ML 软件堆栈的大部分不兼容 [1, 12, 13, 19, 20, 22, 29, 32, 34, 39, 41, 44]。

例如，有些方法依赖于特定版本的框架（如 PyTorch 或 TVM），而这些框架已不再维护 [1, 13, 19, 44, 49]。

其他解决方案（如 TGS [48] 或 Clockwork [19]）由于有限的时间调度（temporal scheduling），无法并行执行多个模型，因此无法实现高 GPU 利用率。

空间调度解决方案（包括 NVIDIA 的 MPS [7] 和 MIG [10] 或研究工作如 REEF [20]、Orion [44] 等）允许多个应用程序并行执行。然而，它们过于粗粒度，调度整个推理请求、训练批次或深度神经网络（DNN）操作符，导致利用率低和队首阻塞 [1, 4, 13, 15, 20, 27, 29, 32, 39, 44, 45, 48, 50]。

高效的 GPU 多租户调度一直难以捉摸。除了共同放置机制之外，为了在不牺牲性能或透明性的情况下解决 GPU 效率低下的问题，数据中心 GPU 管理必须超越静态配置。当前系统未能根据深度学习工作负载的变化特征进行调整——不同模型和执行阶段的计算强度和平行性水平会波动。这是 GPU 经常未被有效利用的另一个原因，即使它们消耗了大量电力。

这种利用率危机与 CPU 的情况形成鲜明对比，在 CPU 上，分时操作系统通过廉价的上下文切换将任务分配给内核，提供隔离、资源分配、电源管理和透明性。GPU 其数据并行的特性带来了与 CPU 不同的权衡，但也暴露了围绕编译器、框架和驱动程序构建的当前抽象的局限性。为了透明地提高利用率和效率，我们认为 GPU 必须朝着操作系统模型发展——为控制、隔离和资源管理提供支持。

1.1 我们的方法：用于 GPU 的操作系统

为应对数据中心 GPU 效率挑战，我们推出 LithOS，为 GPU 深度学习引入操作系统方法。

LithOS 对 ML 堆栈完全透明，无需对模型、运行时或框架做任何修改（透明性意味着 LithOS 能在不干扰现有 ML 软件结构的情况下运行）。LithOS 将大部分 GPU 调度从业界特有的驱动程序和硬件转移到软件中，首次实现了 ML 工作负载的细粒度时间和空间调度。LithOS 以单个内核线程块为单位，动态映射到 GPU 的线程处理簇（TPC），操作这些线程块。

为实现此目标，LithOS 引入新抽象和机制，将内核工作提交与 GPU 上的线程块执行解耦，从而实现智能调度决策、资源分配和电源管理。首先，LithOS 推出细粒度 TPC 调度程序，异步确定每个工作的计算单元分配和提交时间。它能精确控制到单个 TPC 级别，为工作负载提供强大隔离。调度程序借助在线内核延迟预测器，引导高效调度决策，并采用 TPC 借用（stealing）技术提升 GPU 利用率。

由于缺乏硬件预emption（预emption可以理解为硬件层面强制中断某个任务，让更重要的任务先执行的能力），LithOS 引入内核原子化机制。该机制无需编译器、运行时、源代码或 PTX 代码修改（这就保证了 LithOS 的通用性，不管原来是用什么编程语言、什么架构写的程序，都能用 LithOS），将内核透明地拆分为可独立调度的单元，称为原子（atom）。每个原子包含内核线程块的一个子集，减少队首阻塞和跨工作负载干扰。原子化还使 LithOS 能在执行中途动态重新配置 TPC 分配，实现单体式内核无法比拟的调度灵活性。

在此基础上，LithOS 引入动态硬件适配（rightsizing）机制，使用轻量级建模确定每个内核及其原子所需的最小 TPC 资源，从而大幅节省计算容量。

最后，LithOS 提出细粒度电源管理机制，根据 in-flight 工作特征调整 GPU 频率，实现显著节能。我们用 Rust 实现 LithOS，并在广泛深度学习环境中评估性能，与 NVIDIA 最新解决方案及先前研究对比。

二、背景与相关工作

在本节中，我们首先简要介绍 NVIDIA GPU 架构，然后概述相关工作。

2.1 GPU 简要背景

现代 GPU 拥有海量硬件资源，满足 ML 工作负载需求。图 2 展示了典型 GPU 架构。

每个 GPU 包括多个通用处理簇（GPC）。
每个 GPC 是多个线程处理簇（TPC）的集合，每个 TPC 包含少量流式多处理器（SM）。
每个 SM 由数十个核心组成。

例如，NVIDIA 的 H100 包括 8 个 GPC，每个 GPC 有 9 个 TPC，每个 TPC 有 2 个 SM，每个 SM 有 128 个核心。

GPU 编程中，GPU 应用由内核组成，内核执行特定操作符（如卷积）。
内核在启动时定义资源——线程块、线程、寄存器和共享内存。
程序员将内核的工作分配给线程块。
每个线程块在 SM 上执行，包含多个 SIMD 线程。

GPU 流允许独立任务并行执行，类似于 CPU 线程。流工作按 FIFO 顺序执行。部分 CUDA 调用是异步的，而其他则等待所有先前任务完成。

2.2 相关工作

协作式多租户

涉及租户协调共享资源，通常在 ML 框架级别进行，所有模型在同一进程中运行 [1, 12, 13, 19, 20, 22, 29, 32, 34, 39, 41, 44]。

这些方法需要定制 ML 框架，因此受限于无法支持任意应用。一些方法还依赖于广泛的离线分析[20, 44] 或内核源代码修改[20, 32]，在大规模应用中不切实际。此外，任何不合作的租户都会破坏运行时的保证，使得实际采用变得困难。

透明式多租户

支持未经修改的应用。包括 NVIDIA 提供的原生机制，如时间片、MPS[7] 和 MIG[10]。几乎所有先前的软件解决方案都不透明，依赖于应用或框架修改。TGS[48] 是一个例外，它在容器化应用之间提供透明共享。然而，实践中，不合作任务和有限的应用特定信息使透明多任务处理成为一个严峻挑战。

时间多租户

通过原生时间片或软件调度，将整个 GPU 一次分配给一个任务。
一些方法在推理请求级别工作（例如，Clipper [12]、Nexus [41]、TensorFlow-Serving [34]、Clockwork [19] 和 INFaaS [39]），而其他方法则在 GPU 内核级别调度（例如，PipeSwitch [1]、AntMan [49] 和 TGS [48]）。

时间片是 NVIDIA 的默认时间多租户解决方案。它以轮询方式共享 GPU，给每个任务几毫秒的独占访问权。

这些方法一次只执行一个作业，导致利用率低下。

空间多租户

通常基于 MIG 或 MPS 构建，允许多个应用在 GPU 上并发运行，提高利用率。MPS 将多个 GPU 上下文多路复用到一个，允许多个任务同时使用 GPU。

这可以带来更大的吞吐量，但会导致性能干扰。MIG 沿 GPC 边界划分 GPU 的计算和内存资源，提供强大的硬件隔离。然而，其划分粒度较粗，重新配置开销大（>5 秒[47]），可能导致资源闲置。与时间系统类似，现有的空间共享系统粒度较粗，在推理请求或内核级别操作。

其目标是通过限制其他作业启动的内核或限制尽力而为任务分配的 GPU 资源来保护延迟敏感应用，如 REEF [20]、MuxFlow [29] 等系统 [4, 15, 22, 27, 32, 45, 50] 所示。

然而，这些方法的粗糙性限制了对 GPU 资源的控制，通常导致队首阻塞、利用率低和干扰。

图 3 突出了空间共享的挑战。在图 3（a）中，单个工作负载在 GPU 上运行，发出两个请求，共有五个内核。这导致 A 和 B 快速完成，但 GPU 大部分计算容量未被充分利用。当 MPS 在图 3（b）中启用多个任务的并发执行时，利用率提高，但原始任务的请求面临显著延迟。

总体而言，先前工作解决了一些多租户 ML 调度挑战，但未能提供完整、透明的解决方案。重要的是，先前的时间和空间策略操作粒度较粗，限制了利用率，并导致队首阻塞，干扰了共存工作负载。

硬件适配

以往的研究已探索过通过 GPU 作业适配来提升资源效率。然而，这些方法往往依赖于硬件修改 [5, 54]，对应用程序软件缺乏透明性 [3, 4, 15, 25, 53]，并且依赖于离线分析 [4–6, 15, 25, 53]。至关重要的是，大多数现有解决方案以整个作业为粒度进行操作，这限制了它们充分利用细粒度适配的优势，并可能导致次优性能。

动态电压频率调节

近期的研究工作 [24, 36, 37, 43, 52] 已将动态电压频率调节（DVFS）应用于最小化 GPU 的功耗，尤其关注大型语言模型（LLM）推理集群[24, 43]。这类方法基于对多种输入长度的广泛离线分析，并训练专门的输出长度预测器，未能提供一种透明的机制。以往关于 DVFS 的工作以更粗的粒度进行操作，观察整个推理请求的性能，从而错失了更细粒度的优化机会。

三、研究动机

在本节中，我们将展示数据中心 GPU 基础设施面临的挑战和机遇的详细研究。

3.1 理解数据中心的 GPU 利用率

为了深入了解数据中心的 GPU 利用率，我们分析了 Meta 的一部分广告（Ads）推理服务，这些服务在 NVIDIA H100 GPU 节点上运行。这些节点每个配备 8 个 GPU，每个 GPU 通过多实例 GPU（MIG，Multi-Instance GPU，一种将 GPU 资源分割成多个独立实例的技术）进行分区。

生产服务会对每个模型进行离线分析，然后分配模型到 GPU/MIG 分区以进行部署。其目标是在严格的尾部响应时间服务等级协议（SLA，Service Level Agreement，即服务提供商与用户之间定义的服务质量保证合同）约束下运行每个模型。

3.2 GPU 利用率

图 1 展示了一周内的 GPU 计算和内存利用率。设备计算利用率在 17% 到 40% 之间，平均为 27%。

流式多处理器（SM，Streaming Multiprocessor，GPU 中用于执行计算任务的核心组件）的利用率更低，平均为 14%，峰值 21%，最低 6.7%。内存带宽利用率平均为 20%。

总体而言，利用率呈现与推理流量相关的昼夜变化模式。然而，内存容量保持稳定，为 28%，因为为了满足严格的 SLA，模型始终驻留在 GPU 内存中。

推理流量（Inference Traffic）

为了探究低 GPU 利用率的原因，我们首先检查了推理流量。图 4 显示了一周内的平均每秒请求数（RPS）。RPS 在最小值和最大值之间可以扩展 2.2 倍，与图 1 中显示的 GPU 利用率趋势密切相关。

模型大小（Model Sizes）

为了更好地理解 GPU 利用率，我们检查了最常用的模型的大小。图 6 显示，模型大小差异显著，最大和最小模型之间存在超过 10 倍的差异。

一半的模型相对较大，另一半则较小。大小模型均频繁使用：例如，最小的模型 B 的使用频率与较大的模型 E 和 G 相当。

**
GPU 共享的限制和收获（GPU Sharing Limitations and Takeaways）**

尽管迫切需要提高 GPU 利用率，但数据中心通常依赖有限的 GPU 共享或硬件方法（如 MIG）。

原因在于在 ML 软件堆栈内需要兼容性和透明性。非透明解决方案需要对框架或应用进行修改，以实现多租户共享，在大规模应用中不切实际。鉴于维护多个 ML 框架、运行时和编译器的复杂性，透明解决方案有助于避免将基础设施锁定在僵化、过时的设计中。

基于这些见解，我们将 LithOS 设计为一个完全透明的 GPU 操作系统，以实现高效的 ML 多租户共享。

四、LithOS 设计

我们提出 LithOS，这是一种旨在解决数据中心 GPU 效率问题的操作系统。LithOS 在 ML 堆栈中透明运行，实现在 GPU 上的高效机器学习。

4.1 架构概览

图 7 展示了 LithOS 的架构。LithOS 在 CPU 核心上运行，并在驱动程序级别进行干预，提供动态链接库 LibLithOS，该库模拟原生 CUDA 库。

作为一种 GPU 操作系统，LithOS 维护跨应用程序的 GPU 状态的系统视图，这些应用程序具有不同的优先级，从而实现高效调度和管理。应用程序遵循 CUDA 编程模型并提交内核给 LithOS，LithOS 将内核提交与 GPU 执行解耦。

这透明地将调度控制从驱动程序和硬件转移到 LithOS 层。TPC 调度程序以单个 TPC（线程处理簇）为单位管理资源，解锁 TPC 借用机会。空闲 TPC 可以借给其他任务，提高利用率。

LithOS 还引入了内核原子化器，无需访问应用程序源代码或 PTX 代码，即可透明地将内核分解为较小的线程块块，称为原子。这使得 GPU 调度更加细粒度，并减少队首阻塞。

在此细粒度控制的基础上，LithOS 支持动态硬件适配，使用轻量级建模减少单个内核及其原子的 TPC 分配，从而实现显著的容量节省。

最后，LithOS 应用透明的细粒度动态电压频率调节（DVFS），根据在 in-flight 工作调整 GPU 频率以节省能源。

这些机制共同作用，使得 LithOS 能够跨多种 ML 工作负载执行智能调度策略，以最大化 GPU 利用率和效率。

4.2 用户空间接口

内核提交。应用程序通过启动队列与 LithOS 交互，启动队列缓冲工作（下面图 8，步骤 1），使 LithOS 完全控制何时将工作分发到 GPU。

这个过程很重要，因为一旦提交，内核的优先级或资源就无法更改，也无法重新调度。LithOS 延迟分发以最小化 GPU 上的未完成工作数量。当应用程序通过 cuStreamCreate 创建流时，会创建启动队列。

在异步 CUDA 调用（如 cuLaunchKernel）时，LithOS 将内核入队并返回控制给应用程序。

计算配额。LithOS 允许用户和系统管理员定义 GPU 资源限制，公开 TPC 配额（图 8，步骤2），确保每个应用程序在有工作可用时都能获得指定数量的 TPC。

在内部，LithOS 管理 TPC 的方式类似于传统操作系统管理 CPU 核心，从而实现对 GPU 资源的细粒度控制。正如我们将看到的，LithOS 依赖于高效的 TPC 调度程序，该调度程序与启动队列和 TPC 配额交互，以优化 GPU 利用率和效率。

4.3 TPC 调度程序

LithOS 引入了一种新颖的调度程序，其操作粒度为单个 TPC，具有诸多优势。

TPC 级控制实现了细粒度的 GPU 资源管理。与 MIG 等静态分区方案不同，LithOS 支持动态的、即时的 TPC 分配，允许每个内核在不同的 TPC 集合上运行，无需重新配置开销。这种灵活性最大化了利用率，无需粗粒度分区或缓慢的重新分配。内核在其分配的 TPC 上调度，确保高优先级应用程序获得保证的资源。然而，正如前文第 3 节所示，固定分配往往由于流量模式或模型变化而导致 TPC 空闲。

为解决此问题，LithOS 采用动态调度和 TPC 借用来重新分配空闲资源。我们相信，TPC 调度为 GPU 策略的演变奠定了基础，就像 CPU 调度随着时间的推移逐渐成熟一样[17, 35]。

操作。在高层面上，TPC 调度程序使用调度线程监控启动队列（图 8，步骤 1）并向 GPU 提交工作。一个主要目标是使 GPU 保持忙碌，同时维护调度灵活性。调度程序面临两个主要挑战：内核持续时间的变化以及在平衡灵活性与 GPU 饥饿之间的关系。

为解决前者，它应用内核原子化（图 8，步骤 3，第 4.4 节）将长时间运行的内核拆分为较小的线程块块，称为原子。
为解决后者，它通过同步队列（图 8，步骤 5）跟踪未完成的工作，在未完成的工作量降至可调阈值以下时限制提交。专用的跟踪线程监控任务完成情况并更新调度程序状态。

TPC 借用。为提高工作保护（work conservation，指调度程序尽可能高效地利用可用资源，以减少资源浪费并提高整体系统吞吐量），调度程序动态地在应用程序之间重新分配空闲 TPC。

在图 9（a）中，静态分配导致 TPC 空闲。
在图 9（b）中，借用允许 A1 从空闲工作负载借用 TPC，减少浪费。

然而，这可能导致由于优先级反转引起的队首阻塞，例如，如果新请求 B 被 C2 占用的借来的 TPC 延迟。为缓解此问题，调度程序采用分层策略。它维护由延迟预测模块告知的每个 TPC 计时器，该模块会在提交时估计内核（及原子）的持续时间。这些计时器帮助避免从长时间运行的 TPC 中借用。随着任务完成，同步队列被清空，计时器被更新——该过程也在线地完成了延时预测（第 4.7 节）。

LithOS 还限制未完成的原子数量（atomic units of work，原子是构成任务的基本单元），并为借来的 TPC 上的工作使用较低的硬件流优先级。结合内核原子化（将大任务拆分成小的原子），这些机制在最小化干扰的同时提高利用率，同时尽量减少不同任务之间的相互干扰。

4.4 内核原子化器

LithOS 的核心是内核原子化器。

内核原子化器将内核转换为称为原子的小块，每个原子包含网格线程块的子集（图 8，步骤 3）。

重要的是，内核原子化器无需访问源代码或 PTX 代码即可操作，使其对整个 ML 软件堆栈完全透明。

这允许 LithOS 以线程块为单位而不是内核为单位调度工作，这是一个关键要求，因为内核的执行时间可以从几微秒到几十毫秒不等。内核调度对延迟的影响。

图 10 展示了各种训练和推理工作负载的 P99 内核延迟。图 10（a）显示了随着训练批量大小的增加，P99 延迟如何增加。由于每个模型的典型批量大小各不相同，我们通过绘制每个大小的内存使用情况来标准化。大多数模型很快会产生持续几毫秒的长运行内核，其中 DLRM [30] 被突出显示，其内核延迟超过 30 毫秒。虽然训练工作负载是主要罪魁祸首，但在图 10（b）中我们看到，基于 Microsoft Azure [43] 的追踪的大语言模型（LLM）推理也产生了几毫秒长的内核，适用于大的提示长度。

基于此分析，并且考虑到模型可能有非常严格的 SLO（服务等级协议）约束（在几十毫秒的低范围内），我们指导 LithOS 的设计走向更细粒度的调度单位，以减轻队首阻塞效应。

操作。当长时间运行的内核即将被调度时，LithOS 使用预测模块（第 4.7 节详细描述）根据 TPC 分配预测内核的持续时间。LithOS 然后通过将预测的内核持续时间除以可调参数（称为原子持续时间）来计算将内核拆分为多少个原子。如果此参数设置过低，原子化的内核可能实际上需要更长时间才能完成。

至关重要的是，LithOS 能够在运行时透明地将内核拆分为原子。

原子随后被提交到 GPU，并可以根据 TPC 调度程序的指示（图 8，第4步）在 TPC 上调度。因此，LithOS 解决了先前工作在堆栈更高处面临的主要挑战：内核原子化器可在任何框架编写的应用程序上工作，这些应用程序使用任何库（包括封闭源代码的库如 cuDNN）并使用任何编译器构建。为了理解以原子粒度调度的好处，我们回到图 9（b）。借用改善了调度，但并未消除队首阻塞和浪费的容量。

通过将内核划分为原子，工作可以更紧密地打包，如图 9（c）所示，并且可以在内核执行过程中动态调整 TPC 分配。现在，A1 不再被 A2 阻塞，因为一旦提交请求 A，就禁用了 A2 后续原子（如 ^A2）的借用。为了演示 LithOS 的内核原子化器如何工作，我们考虑一个卷积内核，其网格维度为 {8,8,1}，生成 64 个线程块，其块索引范围从 0 到 63。LithOS 不直接启动卷积内核，而是调用前奏内核，该内核使用相同的启动配置调用原始内核。前奏内核如算法 1 所示。在高层面上，它检查块索引是否在指定范围内 — 如果是，则调用卷积；否则提前退出。

例如，将网格划分为 2 个原子，内核原子化器两次启动前奏内核，块索引范围分别为 [0,32) 和 [32,64)。

使用此技术，LithOS 可以将内核划分为最多 64 个原子。通过指定不重叠的块范围，原子化器确保每个块只执行一次，从而保持正确性。

原子化考虑因素。内核启动时带有明确的一组资源；因此，内核原子化器确保前奏内核使用与原始卷积内核相同的资源集。此外，前奏内核需要知道卷积内核的入口点。内核原子化器通过原子元数据结构（如算法 1 所示）将此信息传递给前奏内核。

性能优化。LithOS 持续监控内核原子化器的有效性，以提高性能。

首先，为了避免因前奏内核中额外代码而对具有许多短线程的内核引入开销，LithOS 可能会禁用此类内核的原子化。
此外，对于具有大量线程块的内核，内核原子化器动态调整原子持续时间参数，以控制其激进程度。

这最大限度地减少了由于线程提前退出而导致的线程块流量增加的性能损失。

4.5 适配硬件资源

LithOS 在 TPC 级别的调度能力解锁了新的细粒度 GPU 适配机会。

图 11 突出了这种潜力，绘制了内核加速比与分配的 TPC 数量的关系（第 6 节）。选定的内核占总执行时间的 99%，颜色梯度表示每个内核的相对贡献。例如，对于 Llama 推理，通用矩阵乘法（GEMM）和多头注意力内核表现出递减回报，而应用令牌（token）频率惩罚的内核则没有扩展性。

结果表明，整个模型的适配是次优的 — 没有一种 TPC 配置适合所有内核。相反，内核级别的适配存在巨大机会。

首先，各个内核表现出不同的扩展行为：一些呈线性扩展，而另一些则表现出递减回报。
其次，不同工作负载的执行时间分布在多个内核上的程度不同 — 突出了对自适应的、每个内核的调度的需求，以充分优化 GPU 资源消耗。

4.6 透明电源管理

LithOS 通过 DVFS（动态电压频率调节）实现了透明且高效的电源管理。

就像适配让 LithOS 根据内核在 TPC 上的可扩展性调整资源分配一样，DVFS 通过频率调整实现垂直扩展。

图 12 显示了来自各种工作负载的内核对频率调整的响应。许多内核表现出可预测的行为，从而有机会在对性能影响有限的情况下实现节能。为了实现高效的 DVFS，LithOS 必须解决两个关键挑战。

首先，当前 GPU 支持相对较慢的频率切换（≈50 毫秒）。虽然未来架构可能会降低此延迟 [11]，但 DVFS 对于具有非常短内核的模型仍不切实际。因此，LithOS 必须考虑跨内核序列的频率调整的累积影响。
其次，尽管许多内核的频率降低呈线性关系 — 允许显著节能 — 但 LithOS 必须仔细平衡这些收益与增加的延迟之间的关系。

4.7 在线延迟预测

延迟预测模块学习内核的执行时间，增强 TPC 调度和内核原子化。

它提高了 TPC 借用的效率，通过估计未完成任务的持续时间来指导内核原子化器将每个内核拆分为多少个原子。它还协助适配和 DVFS，提供用于根据 TPC 和频率扩展计算加速比的延迟。这消除了广泛的离线分析的需要，这对于透明操作系统来说是不切实际的。

延迟预测为独立的启动队列分别运行，允许 LithOS 动态适应不同应用程序的行为。在执行过程中，该模块记录内核延迟并使用此数据来完善预测。每个内核的延迟根据分配的 TPC、GPU 频率和原子化的粒度而变化；因此，预测模块必须监控这些条件以产生准确的估计。

如果特定原子的元数据不可用，预测模块会假设保守的线性扩展。

例如，如果原子之前在 100% 的 TPC 分配下执行，它会拟合一个线性趋势来估计在分配一半 GPU 时的持续时间。实现准确的内核延迟预测的一个陷阱是假设给定内核函数始终具有相同的延迟。

实际上，持续时间可能取决于内核的启动参数和输入参数。例如，单个卷积内核函数可以多次用于具有不同张量大小的模型层。这要求延迟预测模块跟踪操作而不是内核函数本身。通过记录应用程序的显式同步事件，我们可以确定批次的开始和结束。我们将内核启动与序号索引关联，指模型数据流图（DFG）中操作符节点的序号索引，尽管 LithOS 缺乏对此高级信息的显式访问。这个额外的序号索引足以识别模型操作符并进行准确的延迟预测。

五、方法实现

我们用 Rust 实现了针对 NVIDIA GPU 的 LithOS 原型，代码行数约为 5000 行，不包括用于拦截整个 CUDA 驱动程序 API 的宏生成代码。

我们的原型支持在本地或容器中运行的应用程序。关于实现的低级细节，我们将部分内容推迟到单独的技术报告中进行阐述。

拦截架构

LithOS 对应用程序完全透明，支持多样化的 ML 生态系统和完整的 GPU 堆栈。一个关键的实现决策是抽象 CUDA 驱动程序 API，这是堆栈中最低的通用接口。应用程序不是直接访问驱动程序，而是与 LithOS 交互，后者保留 CUDA 调用的语义。这种抽象确保了在操作系统级别的通用性和透明性。

LithOS 无缝支持使用 PyTorch、TensorFlow、JAX、TensorRT 和 cuDNN 等框架和库的 ML 应用程序（无需修改应用程序代码），以及闭源库（如 cuDNN）。

除了透明性之外，LithOS 还避免了拦截 CUDA 运行时和其他最终调用驱动程序的库的复杂性。它只实现了一小部分 CUDA API（例如 cuLaunchKernel），而其余部分则通过我们的工具链自动生成。

与以往的 CUDA API 拦截系统不同，LithOS 库消除了跨地址空间的复杂数据序列化过程。这种方法使得能够快速支持新的 CUDA 版本，并且维护工作量小，从而增强了操作系统的长期可维护性。

隔离和故障处理

在 LithOS 中，应用程序在单独的地址空间中运行，无法访问彼此的内存。非法访问将导致违规应用程序终止。为了处理其他故障，LithOS 通过拦截信号并终止应用程序而不会影响其他上下文，从而实现常见错误的优雅处理。

六、实验设置和方法论

测试平台。实验在配备 1 个 A100（SXM4）GPU 的 Lambda Labs GPU 实例上进行，该实例拥有 30 个 CPU 核心和 216 GB 主机内存。A100 GPU 拥有 108 个流式多处理器（SM）和 40 GB 内存。

服务器配置为 Ubuntu 22.04，CUDA 12.8，Rust 1.83.0-nightly，Python 3.10，PyTorch 2.3，TensorRT 10.7，TensorRT-LLM 0.16.0 和 Triton 24.12。
实验基线。我们将 LithOS 与 NVIDIA 的四种 GPU 共享方法进行了比较：时间片、MPS（多进程服务）、流优先级和 MIG（多实例 GPU）。

我们还与透明解决方案（TGS [48]）、需要应用程序修改的解决方案（REEF [20] 和 Orion [44]）进行了比较。

对于 TGS，我们直接使用了开源版本，但由于可用代码依赖于特定的 CUDA 驱动程序和软件堆栈，我们不得不重新实现了 Orion 和 REEF，使用我们自己的拦截基础设施。

我们对 REEF 和 Orion 进行了扩展，以处理多个高优先级（HP）应用程序。对于 REEF，当有任何 HP 应用程序运行时，不会启动 BE（尽力而为）内核。对于 Orion，当 BE 内核与其他 HP 内核竞争时，不会启动 BE 内核。

模型和配置。所有高优先级推理任务都在 NVIDIA 的 Triton 推理服务器上运行，采用动态批处理 [9]。

RetinaNet 在 ONNX Runtime 上运行，而其他服务模型则在 NVIDIA 的 TensorRT 和 TensorRT-LLM 后端上运行。

我们选择了三个代表性视觉模型（RetinaNet [28]、YOLOv4 [2] 和 ResNet-50 v1.5 [21]）和三个语言模型（Llama 3 8B [16]、GPT-J 6B [46] 和 BERT-Large [14]）作为推理工作负载。

对于大型语言模型，我们使用了 Microsoft Azure 跟踪 [43]。
对于尽力而为的训练任务，我们使用了三个视觉模型（ResNet-50、MobileNetV2、VGG-19）、一个深度学习推荐模型（DLRM）、一个语言模型 BERT-Large，以及使用 Llama 3 进行的 LLM 微调，如表 1 所示。

训练批量大小调整为最多使用 GPU DRAM 的一半，以便在堆叠时将所有模型保留在内存中。训练任务持续运行。更多详细信息请参见表 1。

七、实验结果评估和结论

我们的评估回答以下问题：

LithOS 是否在不同的多租户环境中提高了性能？
LithOS 的硬件适配节省了多少容量？
LithOS 的 DVFS（动态电压频率调节）节省了多少能源？
不同的 LithOS 功能对性能有何影响？

7.1 多租户环境中的性能

在以下实验中，我们禁用了 LithOS 的硬件适配和电源管理功能，以便与其他系统在调度效率方面进行公平比较，并在后续评估这些功能。

我们评估了 LithOS 在仅推理多租户环境中的表现，其中包含一个尽力而为（BE）应用和两个高优先级（HP）应用。

HP 应用包括 HP A（具有延迟导向的服务等级协议（SLO））和 HP B（具有吞吐量导向的 SLO）。
BE 和 HP B 模型选自 Llama 3、GPT-J 和 BERT。HP A 则添加了 ResNet 和 RetinaNet。HP 应用的延迟约束（以毫秒为单位）如表 2 所示。

所有可能的组合均进行了测试。HP 应用遵循泊松负载（一种随机事件发生模型），在 Triton 推理服务器上运行，而 BE 应用则在闭环中执行。

所有模型的端到端延迟均进行了测量。我们对所有配置进行了比较。对于支持分区的系统，HP A 和 HP B 分别被隔离在 75% 和 25% 的分区上。由于 MIG（多实例 GPU）的分区配置有限，无法支持 25%-75% 的分区，因此我们采用了 3/7-4/7 的分区方案。

MIG 和线程限制（Limits）只能为配置了资源的应用程序提供服务，因此 BE 应用无法在这两个系统上运行。像优先级（Priority）、REEF、TGS 和 Orion 这样的系统无法隔离多个延迟敏感型应用。对于这些系统，我们将两个 HP 应用设置为高优先级，BE 应用设置为低优先级。

图 13 比较了所有系统在两个维度上的表现：SLO 达成率和吞吐量。“SLO” 为 100% 表示两个 HP 应用均达到了 100% 的 SLO 达成率。“吞吐量” 为 1 表示所达到的吞吐量与任一应用独占设备时的吞吐量相当。不出所料，MPS（多进程服务）在吞吐量方面表现最佳。MPS 的细粒度、SM（流式多处理器）级别的堆叠确保了设备资源的最大化利用，并在堆叠时比任何单个应用独占设备时的吞吐量更高，因此其吞吐量达到了 1.08。

MPS 的高吞吐量是以 SLO 达成率为代价的，仅为 42%。MIG 和线程限制均成功达成了 SLO。这是意料之中的，因为每个系统通过为单个应用分配资源来最小化干扰。然而，由于没有 BE 应用，分区的利用率较低。因此，线程限制和 MIG 的总吞吐量分别降至 0.66 和 0.59。优先级系统无法达成 SLO，其中 TGS（透明 GPU 共享）表现最佳，达成了 72%。LithOS 两者兼顾，提供了类似 MIG 的空间隔离，SLO 达成率为 100%，吞吐量为 1。

LithOS 的优势从何而来？

图 14 显示，LithOS 在 HP 应用的有效吞吐量（goodput，即符合 SLO 约束的吞吐量）方面始终领先，同时仍允许显著的 BE 吞吐量（0.15）。虽然分区系统在 HP A 的有效吞吐量方面与 LithOS 相当，但在 HP B 的有效吞吐量方面却不如 LithOS：MIG 为 0.31，而 LithOS 为 0.50。

分区方案无法支持任何 BE 吞吐量，而 LithOS 允许 HP 应用相互借用未使用的资源，并进一步支持 BE 吞吐量。没有现有技术（SotA）能够在所有需求下有效运行。

具体来说，REEF 和 Orion 在延迟敏感型应用的有效吞吐量方面表现不佳，TGS 在吞吐量方面表现不佳。只有 LithOS 能够在保持高 BE 吞吐量的同时，为 HP 应用提供最佳的有效吞吐量。

深入研究后，我们查看了图 15 中 HP A 应用的延迟。该图显示了每个模型在所有组合中的 P99（99 分位数）延迟平均值。延迟在许多情况下出现差异，只有 LithOS 和分区系统将延迟限制在约束范围内。

MPS 在延迟方面表现最差，LithOS 的延迟比 MPS 低 12 倍。LithOS 的延迟比 Orion 低 12 倍，这在意料之中，因为 Orion 无法处理多个 HP 应用。TGS 在限制延迟方面比 Orion 和 REEF 更有效，但 LithOS 仍比 TGS 改进了 3 倍。

总体而言，LithOS 为推理堆叠提供了稳健的解决方案。

7.2 内核 - SM 适配

容量节省

图 17 显示了适配带来的 GPU 容量节省。我们通过比较适配前后 TPC（线程处理簇）利用率的时间加权平均值来计算节省。LithOS 在所有工作负载中提供了高达 51% 的节省，平均节省为 26%。我们预计，在未来拥有更多 TPC 的 GPU 架构中，LithOS 的细粒度适配方法将提供更具侵略性的节省潜力。

延迟和吞吐量成本

在将延迟滑落参数（latency slip parameter）设置为 1.1 的情况下，适配的性能成本（以 P99 延迟和吞吐量为衡量标准）相对较低。P99 延迟的平均增加和吞吐量的平均减少均为 4%。我们的延迟滑落参数较为保守，因为并非所有推理或训练迭代的端到端执行时间都花费在 GPU 内核中。

为了量化我们预测技术的准确性，我们计算了拟合曲线（即对于可能的 TPC 值超过阈值的内核）的 R² 值的加权平均值。在所有评估的工作负载中，R² 值的平均范围从 Llama 微调的 0.92 到 RetinaNet 推理的 0.99，表明我们的技术高度准确。

7.3 内核依赖 DVFS 能源节省

图 18 显示了 LithOS 的 DVFS（动态电压频率调节）机制在不同推理和训练工作负载下的能源节省情况。

通过记录工作负载在最大频率下执行，与在 LithOS 的 DVFS 策略下执行的能耗差异来定义能源节省。LithOS 在所有工作负载中提供了高达 46% 的显著能源节省，平均节省为 26%，无需离线分析要求。

性能成本将本次实验的滑落参数设置为 1.1，P99 延迟的平均增加仅为 7%。

这表明 LithOS 的 DVFS 策略本质上是保守的，在尊重工作负载的延迟约束的同时，透明地提供了显著的能源节省。更细粒度的频率控制可以释放更多的能源节省潜力。

7.4 消融研究和案例分析

多租户环境中的性能分析。图 19 展示了对于图 16 中探讨的推理 - 训练环境的性能分析。

通过限制 BE 工作负载，同时保持理想的 HP 吞吐量，启用 TPC 调度程序将 HP 尾部延迟改善到理想情况的 1.38 倍。内核原子化提供了额外的增益，将尾部延迟平均降低到 1.19 倍，最高可达 1.55 倍，通过分割长 BE 内核并改进 TPC 借用。

由于篇幅限制，我们仅绘制了延迟数据。内核原子化引入了 10% 的吞吐量开销，因为 LithOS 通过降低 BE 吞吐量来优先 HP 工作负载。

总体而言，LithOS 的每个功能都在优化端到端性能中发挥着关键作用。

内核原子化。为了突出调度长运行内核的挑战，我们将一个 HP BERT 推理工作负载与 BE VGG 训练或 BE Llama 3 推理共同放置。在图 20 中，我们分别改变了 BE 训练作业的批量大小和 BE 推理作业的序列长度，并测量了 HP 推理作业的 P95 延迟。

LithOS 在（a）和（b）中分别比 REEF 提高了 6.5 倍和 3.9 倍。与 REEF 不同，LithOS 考虑了内核持续时间。为了进一步了解内核原子化的影响，我们在不启用内核原子化的情况下评估了 LithOS。内核原子化分别在（a）和（b）中提供了 2 倍和 1.3 倍的改进。

由于内核原子化允许 LithOS 以线程块为单位进行调度，从而最小化了队首阻塞。因此，即使对于最大的批量大小或序列长度，完整 LithOS 系统的 HP 尾部延迟也分别在理想值的 14%（或 1 毫秒）或 7%（或 0.45 毫秒）以内。

延迟预测模块。接下来，我们评估了增强 TPC 调度程序和内核原子化的 LithOS 延迟预测模块的准确性。我们记录了预测的原子延迟，并与相应的 CUDA 事件进行了比较。我们将绝对误差大于 50 微秒的预测视为误预测。

总体而言，我们发现对于推理 - 推理和推理 - 训练环境中的 HP 工作负载，误预测率非常低，分别为 0.9% 和 0.38%。此外，预测误差的尾部较小，P99 值分别为 49 微秒和 31 微秒。对于 BE 工作负载，误预测率较高，分别为推理 - 推理环境的 14% 和推理 - 训练环境的 11%。这是可以接受的，因为 BE 工作负载经常被 HP 工作负载抢占，并且对 GPU 资源的优先级较低。

八、结论

本文介绍了 LithOS，这是迈向高效 GPU 机器学习操作系统的一步。

LithOS 对整个 ML 堆栈透明运行。通过 TPC 调度、内核原子化、硬件适配和电源管理等功能，LithOS 显著提高了 GPU 效率，同时为未来的 GPU 操作系统研究奠定了基础。

参考文献

[1] Zhihao Bai, Zhen Zhang, Yibo Zhu, and Xin Jin. 2020. PipeSwitch: Fast pipelined context switching for deep learning applications. In 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). 499–514.
[2] Alexey Bochkovskiy, Chien-Yao Wang, and Hong-Yuan Mark Liao. 2020. YOLOv4: Optimal Speed and Accuracy of Object Detection. arXiv:2004.10934 [cs.CV] https://arxiv.org/abs/2004.10934
[3] Qichen Chen, Hyerin Chung, Yongseok Son, Yoonhee Kim, and Heon Young Yeom. 2021. smCompactor: a workload-aware finegrained resource management framework for GPGPUs. In Proceedings of the 36th Annual ACM Symposium on Applied Computing (Virtual Event, Republic of Korea) (SAC ’21). Association for Computing Machinery, New York, NY, USA, 1147–1155. doi:10.1145/3412841.3441989
[4] Seungbeom Choi, Sunho Lee, Yeonjae Kim, Jongse Park, Youngjin Kwon, and Jaehyuk Huh. 2022. Serving Heterogeneous Machine Learning Models on Multi-GPU Servers with Spatio-Temporal Sharing. In 2022 USENIX Annual Technical Conference (USENIX ATC 22). USENIX Association, Carlsbad, CA, 199–216. https://www.usenix.org/confer...
[5] Marcus Chow, Ali Jahanshahi, and Daniel Wong. 2023. KRISP: Enabling Kernel-wise RIght-sizing for Spatial Partitioned GPU Inference Servers. In 2023 IEEE International Symposium on High-Performance Computer Architecture (HPCA). 624–637. doi:10.1109/HPCA56546.2023.10071121
[6] Marcus Chow and Daniel Wong. 2024. CoFRIS: Coordinated Frequency and Resource Scaling for GPU Inference Servers. In Proceedings of the 14th International Green and Sustainable Computing Conference (Toronto, ON, Canada) (IGSC ’23). Association for Computing Machinery, New York, NY, USA, 45–51. doi:10.1145/3634769.3634808
[7] NVIDIA Corporation. [n. d.]. Multi-Process Service. https://docs.nvidia.com/deplo... Accessed: April 14, 2025.
[8] NVIDIA Corporation. 2023. NVIDIA H100 Tensor Core GPU Architecture. Technical Report. NVIDIA Corporation, Santa Clara, CA.
[9] NVIDIA Corporation. 2024. Triton Inference Server. https://developer.nvidia.com/... Accessed: May 8, 2024.
[10] NVIDIA Corporation. 2025. NVIDIA Multi-Instance GPU User Guide. https://docs.nvidia.com/datac... Accessed: April 14, 2025.
[11] NVIDIA Corporation. 2025. NVIDIA RTX BLACKWELL GPU ARCHITECTURE. https://images.nvidia.com/aem...
[12] Daniel Crankshaw, Xin Wang, Guilio Zhou, Michael J. Franklin, Joseph E. Gonzalez, and Ion Stoica. 2017. Clipper: A Low-Latency Online Prediction Serving System. In 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI 17). USENIX Association, Boston, MA, 613–627. https://www.usenix.org/confer...
[13] Weihao Cui, Han Zhao, Quan Chen, Ningxin Zheng, Jingwen Leng, Jieru Zhao, Zhuo Song, Tao Ma, Yong Yang, Chao Li, and Minyi Guo. 2021. Enable simultaneous DNN services based on deterministic operator overlap and precise latency prediction. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (St. Louis, Missouri) (SC ’21). Association for Computing Machinery, New York, NY, USA, Article 15, 15 pages. doi:10.1145/3458817.3476143
[14] Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. 2019. BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding. arXiv:1810.04805 [cs.CL] https://arxiv.org/abs/1810.04805
[15] Aditya Dhakal, Sameer G Kulkarni, and K. K. Ramakrishnan. 2020. GSLICE: Controlled Spatial Sharing of GPUs for a Scalable Inference Platform. In Proceedings of the 11th ACM Symposium on Cloud Computing (Virtual Event, USA) (SoCC ’20). Association for Computing Machinery, New York, NY, USA, 492–506. doi:10.1145/3419111.3421284
[16] Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Amy Yang, and Angela Fan et al. 2024. The Llama 3 herd of models. arXiv preprint arXiv:2407.21783 (2024).
[17] Joshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). USENIX Association, 281–297. https://www.usenix.org/confer...
[18] Yanjie Gao, Yichen He, Xinze Li, Bo Zhao, Haoxiang Lin, Yoyo Liang, Jing Zhong, Hongyu Zhang, Jingzhou Wang, Yonghua Zeng, et al. 2024. An Empirical Study on Low GPU Utilization of Deep Learning Jobs. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering. 1–13.
[19] Arpan Gujarati, Reza Karimi, Safya Alzayat, Wei Hao, Antoine Kaufmann, Ymir Vigfusson, and Jonathan Mace. 2020. Serving DNNs like Clockwork: Performance Predictability from the Bottom Up. In 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). USENIX Association, 443–462. https://www.usenix.org/confer...
[20] Mingcong Han, Hanze Zhang, Rong Chen, and Haibo Chen. 2022. Microsecond-scale Preemption for Concurrent GPU-accelerated DNN Inferences. In 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22). USENIX Association, Carlsbad, CA, 539–558. https://www.usenix.org/confer...
[21] Kaiming He, Xiangyu Zhang, Shaoqing Ren, and Jian Sun. 2015. Deep Residual Learning for Image Recognition. arXiv:1512.03385 [cs.CV] https://arxiv.org/abs/1512.03385
[22] Saksham Jain, Iljoo Baek, Shige Wang, and Ragunathan Rajkumar. 2019. Fractional GPUs: Software-based compute and memory bandwidth reservation for GPUs. In 2019 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS). IEEE, 29–41.
[23] Myeongjae Jeon, Shivaram Venkataraman, Amar Phanishayee, unjie Qian, Wencong Xiao, and Fan Yang. 2019. Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads. In Proceedings of the 2019 USENIX Conference on Usenix Annual Technical Conference (Renton, WA, USA) (USENIX ATC ’19). USENIX Association, USA, 947–960.
[24] Andreas Kosmas Kakolyris, Dimosthenis Masouros, Petros Vavaroutsos, Sotirios Xydis, and Dimitrios Soudris. 2024. SLO-aware GPU Frequency Scaling for Energy Efficient LLM Inference Serving. arXiv:2408.05235 [cs.DC] https://arxiv.org/abs/2408.05235
[25] Yunseong Kim, Yujeong Choi, and Minsoo Rhu. 2022. PARIS and ELSA: an elastic scheduling algorithm for reconfigurable multi-GPU inference servers. In Proceedings of the 59th ACM/IEEE Design Automation Conference (San Francisco, California) (DAC ’22). Association for Computing Machinery, New York, NY, USA, 607–612. doi:10.1145/3489517.3530510
[26] Beth Kindig. 2024. AI power consumption: Rapidly becoming mission-critical. https://www.forbes.com/sites/...
[27] Baolin Li, Tirthak Patel, Siddharth Samsi, Vijay Gadepally, and Devesh Tiwari. 2022. MISO: Exploiting Multi-Instance GPU Capability on Multi-Tenant GPU Clusters. In Proceedings of the 13th Symposium on Cloud Computing (San Francisco, California) (SoCC ’22). Association for Computing Machinery, New York, NY, USA, 173–189. doi:10.1145/3542929.3563510
[28] Tsung-Yi Lin, Priya Goyal, Ross Girshick, Kaiming He, and Piotr Dollár. 2018. Focal Loss for Dense Object Detection. arXiv:1708.02002 [cs.CV] https://arxiv.org/abs/1708.02002
[29] Xuanzhe Liu, Yihao Zhao, Shufan Liu, Xiang Li, Yibo Zhu, Xin Liu, and Xin Jin. 2024. MuxFlow: efficient GPU sharing in production-level clusters with more than 10000 GPUs. Science China Information Sciences 67, 12 (2024), 222101. doi:10.1007/s11432-024-4227-2
[30] Maxim Naumov, Dheevatsa Mudigere, Hao-Jun Michael Shi, Jianyu Huang, Narayanan Sundaraman, Jongsoo Park, Xiaodong Wang, Udit Gupta, Carole-Jean Wu, Alisson G. Azzolini, Dmytro Dzhulgakov, Andrey Mallevich, Ilia Cherniavskii, Yinghai Lu, Raghuraman Krishnamoorthi, Ansha Yu, Volodymyr Kondratenko, Stephanie Pereira, Xianjie Chen, Wenlin Chen, Vijay Rao, Bill Jia, Liang Xiong, and Misha Smelyanskiy. 2019. Deep Learning Recommendation Model for Personalization and Recommendation Systems. arXiv:1906.00091 [cs.IR] https://arxiv.org/abs/1906.00091
[31] Microsoft Network. 2024. Dell exec reveals Nvidia has a 1,000 watt GPU in the works. https://www.msn.com/en-us/lif...,000-watt-gpu-in-the-works/ar-BB1jlE8f. Accessed: June 24, 2024.
[32] Kelvin K. W. Ng, Henri Maxime Demoulin, and Vincent Liu. 2023. Paella: Low-latency Model Serving with Software-defined GPU Scheduling. In Proceedings of the 29th Symposium on Operating Systems Principles (Koblenz, Germany) (SOSP ’23). Association for Computing Machinery, New York, NY, USA, 595–610. doi:10.1145/3600006.3613163
[33] NVIDIA Corporation. [n. d.]. NVIDIA CUDA Driver API Documentation: Occupancy. NVIDIA Corporation. https://docs.nvidia.com/cuda/...
[34] Christopher Olston, Noah Fiedel, Kiril Gorovoy, Jeremiah Harmsen, Li Lao, Fangwei Li, Vinu Rajashekhar, Sukrit Ramesh, and Jordan Soyke. 2017. TensorFlow-Serving: Flexible, High-Performance ML Serving. arXiv:1712.06139 [cs.DC]
[35] Amy Ousterhout, Joshua Fried, Jonathan Behrens, Adam Belay, and Hari Balakrishnan. 2019. Shenango: Achieving High CPU Efficiency for Latency-sensitive Datacenter Workloads. In 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19). USENIX Association, Boston, MA, 361–378. https://www.usenix.org/confer...
[36] Pratyush Patel, Esha Choukse, Chaojie Zhang, Íñigo Goiri, Brijesh Warrier, Nithish Mahalingam, and Ricardo Bianchini. 2024. Characterizing Power Management Opportunities for LLMs in the Cloud. In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 3 (La Jolla, CA, USA) (ASPLOS ’24). Association for Computing Machinery, New York, NY, USA, 207–222. doi:10.1145/3620666.3651329
[37] Haoran Qiu, Weichao Mao, Archit Patke, Shengkun Cui, Saurabh Jha, Chen Wang, Hubertus Franke, Zbigniew Kalbarczyk, Tamer Başar, and Ravishankar K. Iyer. 2024. Power-aware Deep Learning Model Serving with 𝜀?-Serve. In 2024 USENIX Annual Technical Conference (USENIX ATC 24). USENIX Association, Santa Clara, CA, 75–93. https://www.usenix.org/confer...
[38] Vijay Janapa Reddi, Christine Cheng, David Kanter, Peter Mattson, Guenther Schmuelling, Carole-Jean Wu, Brian Anderson, Maximilien Breughe, Mark Charlebois, William Chou, Ramesh Chukka, Cody Coleman, Sam Davis, Pan Deng, Greg Diamos, Jared Duke, Dave Fick, J. Scott Gardner, Itay Hubara, Sachin Idgunji, Thomas B. Jablin, Jeff Jiao, Tom St. John, Pankaj Kanwar, David Lee, Jeffery Liao, Anton Lokhmotov, Francisco Massa, Peng Meng, Paulius Micikevicius, Colin Osborne, Gennady Pekhimenko, Arun Tejusve Raghunath Rajan, Dilip Sequeira, Ashish Sirasao, Fei Sun, Hanlin Tang, Michael Thomson, Frank Wei, Ephrem Wu, Lingjie Xu, Koichi Yamada, Bing Yu, George Yuan, Aaron Zhong, Peizhao Zhang, and Yuchen Zhou. 2019. MLPerf Inference Benchmark. arXiv:1911.02549 [cs.LG]
[39] Francisco Romero, Qian Li, Neeraja J. Yadwadkar, and Christos Kozyrakis. 2021. INFaaS: Automated Model-less Inference Serving. In 2021 USENIX Annual Technical Conference (USENIX ATC 21). USENIX Association, 397–411. https://www.usenix.org/confer...
[40] Mark Sandler, Andrew Howard, Menglong Zhu, Andrey Zhmoginov, and Liang-Chieh Chen. 2018. Mobilenetv2: Inverted residuals and linear bottlenecks. In Proceedings of the IEEE conference on computer vision and pattern recognition. 4510–4520.
[41] Haichen Shen, Lequn Chen, Yuchen Jin, Liangyu Zhao, Bingyu Kong, Matthai Philipose, Arvind Krishnamurthy, and Ravi Sundaram. 2019. Nexus: A GPU Cluster Engine for Accelerating DNN-Based Video Analysis. In Proceedings of the 27th ACM Symposium on Operating Systems Principles (Huntsville, Ontario, Canada) (SOSP ’19). Association for Computing Machinery, New York, NY, USA, 322–337. doi:10.1145/3341301.3359658
[42] Karen Simonyan and Andrew Zisserman. 2015. Very Deep Convolutional Networks for Large-Scale Image Recognition. arXiv:1409.1556 [cs.CV] https://arxiv.org/abs/1409.1556
[43] Jovan Stojkovic, Chaojie Zhang, Íñigo Goiri, Josep Torrellas, and Esha Choukse. 2024. DynamoLLM: Designing LLM Inference Clusters for Performance and Energy Efficiency. arXiv:2408.00741 [cs.AI] https://arxiv.org/abs/2408.00741
[44] Foteini Strati, Xianzhe Ma, and Ana Klimovic. 2024. Orion: Interference-aware, Fine-grained GPU Sharing for ML Applications. In Proceedings of the Nineteenth European Conference on Computer Systems (Athens, Greece) (EuroSys ’24). Association for Computing Machinery, New York, NY, USA, 1075–1092. doi:10.1145/3627703.3629578
[45] Cheng Tan, Zhichao Li, Jian Zhang, Yu Cao, Sikai Qi, Zherui Liu, Yibo Zhu, and Chuanxiong Guo. 2021. Serving DNN Models with Multi-Instance GPUs: A Case of the Reconfigurable Machine Scheduling Problem. arXiv:2109.11067 [cs.DC]
[46] Ben Wang and Aran Komatsuzaki. 2021. GPT-J-6B: A 6 Billion Parameter Autoregressive Language Model. https://github.com/kingoflolz...
[47] Tianyu Wang, Sheng Li, Bingyao Li, Yue Dai, Ao Li, Geng Yuan, Yufei Ding, Youtao Zhang, and Xulong Tang. 2024. Improving GPU Multi-Tenancy Through Dynamic Multi-Instance GPU Reconfiguration. arXiv preprint arXiv:2407.13126 (2024).
[48] Bingyang Wu, Zili Zhang, Zhihao Bai, Xuanzhe Liu, and Xin Jin. 2023. Transparent GPU Sharing in Container Clouds for Deep Learning Workloads. In 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23). USENIX Association, Boston, MA, 69–85. https://www.usenix.org/confer...
[49] Wencong Xiao, Shiru Ren, Yong Li, Yang Zhang, Pengyang Hou, Zhi Li, Yihui Feng, Wei Lin, and Yangqing Jia. 2020. AntMan: Dynamic Scaling on GPU Clusters for Deep Learning. In Proceedings of the 14th USENIX Conference on Operating Systems Design and Implementation (OSDI’20). USENIX Association, USA, Article 30, 16 pages.
[50] Fei Xu, Jianian Xu, Jiabin Chen, Li Chen, Ruitao Shang, Zhi Zhou, and Fangming Liu. 2023. iGniter: Interference-Aware GPU Resource Provisioning for Predictable DNN Inference in the Cloud. IEEE Transactions on Parallel and Distributed Systems 34, 3 (2023), 812–827. doi:10.1109/TPDS.2022.3232715
[51] Hangchen Yu, Arthur Michener Peters, Amogh Akshintala, and Christopher J. Rossbach. 2020. AvA: Accelerated virtualization of accelerators. In Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems. 807–825.
[52] Yijia Zhang, Qiang Wang, Zhe Lin, Pengxiang Xu, and Bingqiang Wang. 2024. Improving GPU Energy Efficiency through an Application-transparent Frequency Scaling Policy with Performance Assurance. In Proceedings of the Nineteenth European Conference on Computer Systems (Athens, Greece) (EuroSys ’24). Association for Computing Machinery, New York, NY, USA, 769–785. doi:10.1145/3627703.3629584
[53] Yongkang Zhang, Haoxuan Yu, Chenxia Han, Cheng Wang, Baotong Lu, Yunzhe Li, Zhifeng Jiang, Yang Li, Xiaowen Chu, and Huaicheng Li. 2025. SGDRC: Software-Defined Dynamic Resource Control for Concurrent DNN Inference on NVIDIA GPUs. In Proceedings of the 30th ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Programming (Las Vegas, NV, USA) (PPoPP ’25). Association for Computing Machinery, New York, NY, USA, 267–281. doi:10.1145/3710848.3710863
[54] Xia Zhao, Magnus Jahre, and Lieven Eeckhout. 2020. HSM: A Hybrid Slowdown Model for Multitasking GPUs. In Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems (Lausanne, Switzerland) (ASPLOS ’20). Association for Computing Machinery, New York, NY, USA, 1371–1385. doi:10.1145/3373376.3378457

END

作者：CMU，Meta
来源：Neural Talk

推荐阅读

欢迎大家点赞留言，更多 Arm 技术文章动态请关注极术社区嵌入式AI专栏欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。