通过整合未充分利用的 GPU 工作负载最大化 AI 基础设施吞吐量

在生产级 Kubernetes 环境中，模型需求与 GPU 规格之间的差异会导致效率低下。轻量级自动语音识别（ASR）或文本转语音（TTS）模型可能仅需 10 GB 显存，但在标准的 Kubernetes 部署中却会独占整张 GPU。由于调度器通常将模型绑定至单张或多张 GPU，且难以在多个模型之间跨 GPU 共享算力，昂贵的计算资源往往处于闲置状态。

解决这一问题不仅是为了降低成本，更是为了优化集群密度，从而在同一批业界一流硬件上服务更多并发用户。本指南详细介绍了如何实施并对 GPU 分区策略进行基准测试，特别是 NVIDIA Multi-Instance GPU (MIG) 和时间切片（time-slicing），以充分利用计算资源。

我们以生产级语音 AI 流水线作为测试平台，展示如何通过模型组合最大化基础设施的投资回报率（ROI），同时维持 >99% 的可靠性与严格的延迟保障。

解决 GPU 资源碎片化问题

默认情况下，Kubernetes 的 NVIDIA 设备插件会将 GPU 显示为整数资源。Pod 请求 nvidia.com/gpu: 1 ，调度器会将其绑定到一个物理设备。

诸如 NVIDIA Nemotron、Llama 3 或 Qwen 7B/8B 等大型语言模型（LLM）需要专用计算资源，以维持较低的首字延迟（TTFT）和较高的批处理吞吐量。然而，生成式 AI 流水线中的辅助模型（如嵌入模型、ASR、TTS 或安全护栏）通常仅占用单张显卡的一小部分算力。在专用 GPU 上运行这些轻量级模型会导致：

• 低利用率：GPU计算利用率通常徘徊在0-10%左右。
• 集群臃肿：运行相同数量的Pod需要配置更多节点。
• 扩展阻力：新增一项能力需要配备新的物理GPU。

为解决此问题，我们必须打破 Pod 与 GPU 之间 1:1 的对应关系。

架构：切分策略

我们评估了 NVIDIA GPU Operator 支持的两种主要 GPU 切分策略。

基于软件的分区：时间片轮转与 MPS

时间片轮转通过交错执行，使多个 NVIDIA CUDA 进程能够共享同一 GPU。其工作方式类似于 CPU 调度器：上下文 A 运行、暂停，然后上下文 B 运行。

• 机制：通过 CUDA 驱动程序进行软件级调度。
• 优点：最大化利用率。支持“突发”（bursting）模式——若 Pod A 空闲，Pod B 可使用 GPU 100% 的计算核心。
• 缺点：缺乏硬件隔离。单个 Pod 的内存溢出（OOM）可能影响共享的执行上下文，且某 Pod 的高强度计算会限制相邻 Pod 的性能（即“嘈杂邻居”效应）。

除时间片轮转（time-slicing）外，NVIDIA Multi-Process Service (MPS) 提供了一种替代性的软件方案。MPS 采用客户端-服务器架构，允许多个进程并发共享 GPU 资源。相比 MIG 它更具灵活性，且与标准时间片轮转相比，它对内存泄漏等特定问题具有更强的容错能力。

然而，在生产环境中，这两种方法共享单一的执行上下文，限制了隔离性。尽管现代 MPS 提供了隔离的虚拟地址空间，但它缺乏硬件级的故障隔离。这意味着一个进程中的致命执行错误或非法内存访问将在共享上下文中传播，可能导致 GPU 重置，从而影响共享该显卡的其他进程。

MIG：硬件级分区方案

MIG 在物理上将 GPU 划分为独立的实例，每个实例都拥有专用的内存、缓存和流多处理器（SM）。对操作系统和 Kubernetes 而言，它们看起来像是独立的 PCI 设备。

• 机制：硬件级隔离。
• 优点：严格的服务质量（QoS）。一个工作负载无法影响另一个工作负载的性能或内存稳定性。
• 缺点：规格固定。若某分区处于空闲状态，其计算资源无法被邻近分区“借用”。

尽管时间切片提供了灵活性，但在需要严格硬件级故障隔离以满足企业SLA的生产环境中，MIG仍是首选方案。硬件分区能够确保单个模型的内存错误不会在共享GPU上引发级联故障——这对于关键任务型语音AI而言是一项核心要求。

实验设置：语音AI流水线

为了在贴近实际生产的场景中验证这些策略，我们采用了一套多模态语音到语音的 AI 流水线。该工作负载非常适合基准测试，因为它融合了三种截然不同的流量模式：

• ASR（流式）：使用 NVIDIA Parakeet 1.1B 进行持续的低算力流处理
• TTS（突发式）：空闲数秒后，利用率瞬间飙升至 100%，借助 NVIDIA Magpie Multilingual 在毫秒内生成音频
• LLM（重负载）：高计算量、高内存占用，采用 Llama-3.1-Nemotron-Nano-VL-8B-V1。

在进行优化之前，关键在于准确掌握系统的延迟特征。在我们的语音到语音管线中，LLM 是主要瓶颈。在高负载下，LLM 占据总处理时间约 9 秒。该延迟会随上下文长度发生显著波动；例如，与短提示词相比，高输入场景（如用户训练）或不断增长的对话历史会显著增加处理开销。随着历史记录累积，LLM 在生成回复前必须处理更多 token，从而拉长了瓶颈时间，支持模型必须被掩盖在这一瓶颈之后。

将 ASR 和 TTS 等支持模型进行整合，为在保持端到端响应速度的同时最大化硬件利用率提供了一条战略路径。尽管整合可能会带来 100-200 ms 的轻微延迟调整，但基础设施吞吐量和 ROI 的提升十分显著。

我们的假设

将ASR与TTS工作负载整合至单张GPU上，可在保持延迟与抖动稳定的同时，释放算力以运行更多LLM实例。

实验

我们设计了三种不同的测试配置。每轮测试使用三个语音样本，并等待LLM+TTS完成首次响应。该环境基于Kubernetes集群构建，模型通过NVIDIA NIM部署，并由NVIDIA NIM Operator统一管理。工作节点配备三块NVIDIA A100 Tensor Core GPU。

• 实验1：三块GPU基线 设置：每个模型（LLM、ASR、TTS）独占一块GPU。目标：确立延迟与吞吐量的“黄金标准”，作为评估优化效果的基准。资源：每个Pod配置 nvidia.com/gpu: 1。
• 实验二：双GPU时间切片 设置：LLM保留专用GPU。ASR与TTS通过软件级时间切片共享GPU 0。目标：测试动态调度能否处理流式ASR与突发性TTS之间的“嘈杂邻居（noisy neighbor）”资源争用。资源：nvidia.com/gpu: 1（通过副本数 replicas: 2 共享）。
• 实验三：双GPU MIG分区 设置：LLM保留专用GPU。GPU 0被物理划分为两个隔离实例。目标：测试硬件隔离是否比软件调度提供更佳的稳定性。资源：nvidia.com/mig-3g.40gb: 1（每个Pod）。

配置说明：为实现这些拓扑结构，我们在NVIDIA GPU Operator中使用了特定的配置。

• 对于实验2，我们采用了 timeSlicing 配置，以便在每张物理 GPU 上宣告多个副本。
• 对于实验3，我们应用了自定义的 mig-configs ConfigMap，将 GPU 划分为两个 3g.40gb 实例。

（有关用于复现此配置的具体 kubectl 命令与 YAML 清单文件，请参阅本文末尾的实现附录。）

结果

为评估资源碎片化情况，我们使用两种不同的流量模式对系统进行了测试：

• 轻负载：5个并发用户模拟约135秒的持续交互。
• 重负载：50个并发用户模拟约375秒的持续交互。

图5对比了不同流量模式下的生成式AI推理吞吐量。数据表明，在轻载与重载条件下，随着并发数增加，分区策略（基线（专用GPU）、时间分片（软件共享）和MIG（硬件分区））如何影响请求处理。所有实验的成功率均为100%，无失败情况。当前的 req/s 是导致流水线中 LLM 出现瓶颈的原因。

平均延迟指标

以下分析评估了不同的GPU分区策略对整体系统效率与响应能力的影响。

吞吐量与延迟对比

将ASR与TTS工作负载整合至单块GPU可优化处理流水线，使集群能够支持更多并发的AI数据流。然而，我们的基准测试显示，这两种分区策略之间存在关键的性能差异：

1. MIG（硬件）：最高效率

实验3实现了最高的单位效能，达到每GPU约1.00 req/s。通过为每个实例提供专用的硬件路径，MIG消除了资源争用。各组织在实现接近系统满载容量的同时，能有效释放一整块GPU用于其他繁重的大语言模型（LLM）工作负载。

1. 时间切片（软件）：密度更高但伴随开销

实验2表明，与基线相比，软件级共享同样能提升单GPU密度，达到每GPU约0.76 req/s。然而，CUDA驱动程序在流式模型与突发模型之间管理快速上下文切换会引入调度开销。尽管该基于软件的方案切实可行，但其整体吞吐量效率仍无法达到硬件分区所提供的水平。

延迟与突发性

时间切片处理单个突发任务的速度略快，平均TTS延迟为144.7 ms，而MIG为168.2 ms。然而，在当前规模下，这23.5 ms的差异仅占端到端处理流水线总响应时间的一小部分。在高负载下，LLM占据了总交互时间的绝大部分。由于终端用户无法在数秒级的响应中感知到20 ms的差值，因此MIG的吞吐量稳定性成为了更具实际价值的生产环境指标。

基于基准测试数据，我们推荐以下决策矩阵：

1. 面向生产规模与稳定性，默认采用 MIG。实验 3 表明，MIG 可处理更高的请求量（2 req/s），仅在延迟方面有轻微妥协。严格的硬件级故障隔离可防止一个进程的内存溢出导致另一进程崩溃。最适合将吞吐量与 100% 可靠性作为首要任务的生产环境。
2. 面向开发或低并发应用，采用时间片轮转。这将导致总吞吐量降低 32%，并产生共享资源依赖。最适合开发、CI/CD 和 PoC 阶段，以最小的硬件占用运行完整流水线。

快速入门

1. 进一步实验：试用该代码库。
2. 实施分区：按照我们的实施指南配置 MIG 配置文件，并使用提供的 YAML 清单来消除集群中的资源碎片。
3. 借助 NIM 实现扩展：部署 NVIDIA NIM 流水线，充分利用您的 ASR、TTS 和 LLM 工作负载，以实现最大投资回报率。