利用 NVIDIA Run:ai 和 NVIDIA NIM 最大化 GPU 利用率

部署 LLM 的机构正面临着资源需求各异的推理工作负载带来的挑战。小型嵌入模型可能仅占用几 GB 的 GPU 显存，而参数规模达 70B+ 的 LLM 则可能需要多块 GPU。这种差异性往往导致 GPU 平均利用率偏低、计算成本高昂以及延迟难以预测。

该问题并非仅仅在于将更多工作负载塞入 GPU，而在于如何进行智能调度。若缺乏能够理解推理工作负载模式的编排机制，机构将不得不在过度配置（浪费资源）与配置不足（降低性能）之间做出抉择。

本文将涵盖以下内容：

• 推理利用率问题：传统调度为何未能充分利用 GPU 资源。
• NVIDIA NIM 如何实现生产级推理交付：容器化微服务在标准化模型部署中的作用。
• NVIDIA Run:ai 智能调度策略：四项关键能力，可在提升性能（降低延迟、提高 TPS/GPU）的同时，提高 GPU 利用率并降低计算成本。
• 基准测试结果：在吞吐量损失极小的情况下，GPU 利用率提升约 2 倍；在高并发与动态比例场景下，吞吐量最高提升约 1.4 倍；结合 GPU 内存交换技术，首次请求延迟缩短 44-61 倍。
• 如何入门：在 NVIDIA Run:ai 上使用 NIM 实施这些策略的实践指南。

推理利用率问题

GPU利用率决定了在给定集群上能够运行的工作负载数量及其成本。在实际应用中，大多数推理部署会导致大量GPU算力闲置，因为出于“保险起见”会为每个模型分配整张GPU，又或者是因为缺乏内存隔离的简单共享在流量压力下会引发内存溢出（OOM）状况与延迟突增。

缺乏智能编排时，团队被迫在过度配置（资源浪费）与配置不足（性能风险）之间做出选择。

NVIDIA NIM 如何实现生产级推理

NVIDIA NIM 软件包将推理引擎优化为容器化微服务，具体包括：

• 预封装的推理引擎：为提升吞吐量/降低延迟而预配置的推理运行时
• 行业标准 API：兼容 OpenAI 的端点，便于集成
• 模型优化：自动选择量化、批处理及加速技术。
• 生产就绪容器：预置依赖项，并经过大规模测试
• 安全与合规：企业级安全控制与部署用容器签名
• 企业支持：为生产部署提供 NVIDIA 支持与维护

NIM 实现了部署层的标准化，但要最大化 GPU 利用率仍需智能编排。这正是 NVIDIA Run:ai 的调度能力发挥关键作用之处。

NVIDIA Run:ai 如何为 NVIDIA NIM 实现高效的资源管理

推理资源的利用不仅关乎调度，更在于适应工作负载的实际运行特征。借助 NVIDIA Run:ai，NIM 部署可获得推理优先策略、具备完整内存隔离的 GPU 切分、基于工作负载需求的智能放置、动态内存管理以及自动扩缩容（包括副本扩缩容和缩容至零）。这使得用户能够跟随流量变化，并在模型空闲时释放 GPU 资源。

推理优先级保护面向用户的工作负载

NVIDIA Run:ai 会自动为推理工作负载分配最高的默认优先级，确保训练任务永远不会抢占它们。这为何重要：

• 推理直接面向用户：延迟飙升与停机将影响用户体验及 SLA 合规性。
• 训练可容忍中断：模型训练支持保存检查点并恢复；推理请求无法等待。

这种自动优先级分配在大多数环境中免除了手动调优的需求。对于运行混合工作负载的组织而言，这确保了训练任务能够围绕推理需求灵活调度，而非与之争抢资源。当推理负载较低时，GPU可执行训练任务，并在面向用户的请求到达时自动让出资源。

在单个GPU上通过装箱算法为多个小型模型分配GPU分片

许多 NIM 工作负载（如嵌入模型、重排序模型和小型大语言模型）通常无需占用整张 GPU。结合 GPU 分片使用时，NVIDIA Run:ai 的装箱策略会在分配新 GPU 前优先填满现有 GPU，从而最大化整个集群的利用率。

基于装箱策略的GPU分片工作原理：

• GPU 切分提供真正的内存隔离（而非软限制）。每个模型均可获得有保障的内存分配。
• 装箱策略根据当前利用率对 GPU 进行评分，在分配全新 GPU 之前，优先填满已部分使用的 GPU。
• 调度器会优先将新工作负载分配给已部分使用的 GPU。

基准测试结果：

该方法通过在 NVIDIA H100 GPU 上模拟包含三个 NIM 模型（一个 7B LLM、一个 12B VLM 和一个 30B MoE）的场景进行了测试：

• 场景 A：三个 GPU，每个 NIM 分配一个 H100 GPU（基准）
• 场景 B：使用 NVIDIA Run:ai 的 GPU 资源切分技术，在 1.5 个 H100 GPU 上运行三个 NIM，同时保持 NIM 配置与客户端负载模式恒定

对短上下文与长上下文提示词进行测试后，关键发现包括：

• 每个 NIM 均保留了约 91–100% 的单 GPU 吞吐量，首 Token 生成时间（TTFT）与端到端（E2E）延迟仅有适度增加。
• 在长上下文输入下，Mistral-7B 的吞吐量达到 834 token/s，与其专用 GPU 的吞吐量持平（100%）。
• Nemotron-3-Nano-30B 保留了 95% 的吞吐量（582 vs. 614 token/s）。
• 在短上下文输入下，Nemotron-Nano-12B-v2-VL 保留了 91% 的吞吐量（658 vs. 723 token/s）。

原先需占用三张专用 H100 的三个 NIM 微服务现已整合至约 1.5 张 H100 上，从而释放出剩余容量供其他工作负载使用。

动态 GPU 份额分配可在高并发请求下维持性能。

静态GPU显存份额能够保证内存隔离，但也设定了硬性上限，从而形成“标准容量”。随着并发请求的增加，每个NIM的KV缓存会动态增长以跟踪活跃序列。当这种增长触及固定的份额边界时，吞吐量将进入平台期，延迟随之恶化。这一瓶颈迫使面临艰难取舍：是过度分配份额（导致GPU容量浪费），还是限制并发量以维持在固定的显存预算内。

NVIDIA Run:ai 的动态 GPU 份额通过采用请求/限制模型取代固定分配，并借鉴 Kubernetes 针对 GPU 显存的资源语义，解决了这一问题：

• 请求：保证的最小份额，始终为该工作负载预留。
• 限制：可突发上限，使 NIM 能够在按需 KV 缓存或计算压力增加时扩展至可用的 GPU 显存。

当 NIM 在其请求配额内运行时，请求与上限之间未使用的余量仍可供同节点的其他工作负载使用。当并发流量突增时，NIM 会向上限突增，占用该内存并将其转化为实际吞吐量。请求与上限之间的状态切换由系统自动处理。工作负载在需要资源时自动扩容，在需求下降时释放资源，从而在无需人工干预的情况下最大化 GPU 的总体利用率。

基准测试结果：

沿用实验1中相同的三个NIM模型与1.5张H100 GPU的资源占用，将静态比例替换为动态比例，以测量在并发量不断增加时的性能表现：

• Mistral-7B NIM（请求：0.3，限制：0.4）
• Nemotron-Nano-12B-v2-VL NIM（请求：0.4，限制：0.5）
• Nemotron-3-Nano-30B NIM（请求：0.65，限制：0.75）

对比场景：

• 场景 A（静态份额 + 装箱）：实验 1 中的固定份额部署（见图 1），其中每个 NIM 均设有严格的内存上限并实现完全隔离。
• 场景 B（动态份额 + 装箱）：在约 1.5 张 H100 GPU 上采用相同的装箱布局，但每个 NIM 使用请求/限制（request/limit）配对，而非固定分配。

在图 2、图 3 和图 4 中，随着并发量增加，静态份额触及性能瓶颈，吞吐量停滞且延迟激增，因为模型无法为不断增长的 KV 缓存获取更多内存。而采用动态份额时，NIM 微服务能够在流量高峰期间向限制值突发以吸收压力，并在负载下降时释放内存。

在所有三个 NVIDIA NIM 微服务中，动态比例分配实现了最高 1.4 倍的吞吐量提升和 1.7 倍的延迟降低，且能随并发量平稳扩展。例如：

• 使用动态比例分配时，Nemotron-3-Nano-30B 在 256 个并发请求下可维持 1,025 token/s 的吞吐量；相比之下，采用静态比例分配时，仅在 4 个并发请求下达到 721 token/s 的上限即出现不稳定（提升 1.4 倍）。
• 在处理 64 个并发且长度为 2,048 token 的请求时，Mistral-7B-Instruct-v0.3 的 p50 端到端延迟从 5,235 ms 降至 3,098 ms（降低 1.7 倍）。

p50 延迟曲线保持平滑且单调变化，未出现突增或骤降，这证实请求与限制的余量能够有效适应 KV 缓存的增长模式，从而提升了 GPU 利用率。

核心要点：

• 静态配额 + 装箱策略：流量可预测，并发量中低，模型显存占用稳定
• 动态 GPU 配额 + 装箱策略：流量波动较大，并发量高，KV 缓存显著增长

动态 GPU 配额在保持工作负载密度的同时，消除了高并发场景下静态分配的性能上限。采用静态配额时，KV 缓存无法突破固定的显存边界，推理引擎会因缺乏接纳新序列的余量而开始拒绝请求。动态 GPU 配额则有效解决了该问题：NIM 可按需突发利用可用余量，使企业无需额外分配 GPU，即可兼顾装箱策略的效率与应对流量峰值的弹性。

GPU 内存交换：高效服务极少使用的模型

提供大语言模型服务的组织面临着延迟与成本之间的根本权衡。从零启动大语言模型需要完整的容器初始化、从磁盘加载模型权重以及分配 GPU 内存，该过程可能耗时数十秒至数分钟。由于这种冷启动延迟对于面向用户的应用而言无法接受，大多数组织选择过度配置资源，即使在流量较低或空闲时段，也保持多个副本始终在线并独占 GPU。

这保证了低延迟，但造成了 GPU 容量的浪费，企业仅为避免冷启动风险就需为闲置硬件买单。Scale-to-zero（缩容至零，即 Kubernetes 中完全关闭空闲副本并按需重启的模式）虽能释放 GPU，但冷启动带来的延迟惩罚使其难以应用于对延迟敏感的推理工作负载。

GPU 内存交换的工作原理：

借助 GPU 内存交换，模型会常驻于 CPU 内存中，并在请求到达时在 CPU 与 GPU 之间动态交换模型权重。任何时刻，仅有活跃模型的权重驻留在 GPU 内存中。当请求指向空闲模型时，NVIDIA Run:ai 的 GPU 内存交换功能会将当前已加载模型的权重移至 CPU RAM，并将目标模型加载至 GPU 内存，在可配置的时间窗口内保持其预热状态。模型始终不会完全脱离内存，仅是在 GPU 与 CPU 之间迁移，从而免除了容器重启、磁盘 I/O 以及冷启动初始化的需求。

GPU 内存交换适用于单 GPU、多 GPU 及分片 GPU 工作负载。此前针对单 GPU 部署的基准测试表明，与从零扩展（scale-from-zero）相比，首 Token 生成时间（TTFT）最高可提升 66 倍。本次基准测试将 GPU 内存交换与分片 GPU 上的 NIM 部署相结合，旨在验证当模型通过装箱（bin packing）共享硬件且受内存限制时，是否仍能保持同等的延迟优势。

基准测试结果：

针对相同的三个 NIM 部署，对比了 GPU 内存交换与从零扩展之间的延迟：

• 场景 A（从零扩展）：当流量到达时，每个 NIM 均在专用的 H100 GPU 上从零冷启动（共计三块 GPU）。
• 场景 B（GPU 内存交换）：三个 NVIDIA NIM 微服务共享 1.5 块 H100 GPU（采用与先前实验相同的分片比例），并在 GPU 与 CPU 内存之间进行换入/换出操作。

采用从零扩展（scale-from-zero）时，由于完整的冷启动过程，访问频率较低的NIM微服务会出现较高的首次请求延迟。而采用GPU内存交换后，首次请求延迟保持在可接受范围内，后续请求则能实现热态TTFT。这三个NIM微服务仅运行在一半的GPU上，从而释放出剩余容量用于高流量或其他工作负载。

在128-token输入下，冷启动TTFT范围为75.3秒（Mistral-7B）至92.7秒（Nemotron-3-Nano-30B），而GPU内存交换将其降至1.23–1.61秒，性能提升55–61倍。在2,048-token输入下，冷启动TTFT从158.3–180.2秒降至使用内存交换后的3.52–4.02秒，降幅稳定在约44倍。

核心结论：与从零扩展相比，GPU内存交换的TTFT快44-61倍，且在结合GPU分区（GPU fractions）使用时资源占用更少，无论模型部署在专用GPU还是分区GPU上，均能消除低频访问模型所面临的冷启动延迟惩罚。

开始使用 NVIDIA Run:ai 和 NVIDIA NIM

请参阅本指南，了解如何在 NVIDIA Run:ai 上将 NVIDIA NIM 部署为原生推理工作负载。观看本次网络研讨会，了解团队如何通过智能调度、细粒度 GPU 控制、Kubernetes 原生流量负载均衡以及自动扩缩容来管理不断增长的 AI 工作负载，并了解新平台更新在访问控制、端点管理和可见性方面的改进。