从云原生走向 AI 原生：一套面向未来的架构方法论 → 阅读《AI 原生基础设施》

AI 基础设施的 GPU 管理挑战

已发行

AI 工作负载正在改变基础设施对计算资源的消费方式。当 GPU 成为 AI 集群中最昂贵也最稀缺的资源时，传统的调度方式已经无法胜任。

引言：当 AI 遇见 Kubernetes

过去几年，AI 工作负载经历了从实验到生产的关键转变。大语言模型、图像生成、推荐系统，这些应用无一例外地依赖 GPU 加速。企业 Kubernetes 集群中 GPU 的占比正在快速攀升，但 Kubernetes 的调度能力并没有跟上这一变化。

考虑一个真实场景：一家 AI 公司拥有一个 100 节点的集群，其中 20 个节点配备 GPU。集群上同时运行着模型训练、在线推理、模型评估和开发调试任务。平台团队面对的核心问题是，如何让有限的 GPU 服务尽可能多的工作负载？

这不是一个简单的运维问题。它涉及调度语义、资源抽象和多厂商设备管理等多个层面。

Kubernetes 的 GPU 调度局限

围绕 CPU/Memory 设计的调度器

Kubernetes 的调度器围绕 CPU、内存和 Pod 数量设计，核心抽象是“资源请求”（Requests）和“资源上限”（Limits）。这套机制对 CPU 和内存非常有效，它们是可分割的、可超卖的、可精确计量的。

但 GPU 完全不同。GPU 有显存、有算力核心、有 NVLink 拓扑、有 PCIe 带宽，这些维度无法用一个标量来表示。

GPU 作为不透明设备

Kubernetes 通过 Device Plugin 机制支持 GPU，但它只做了一件事：把整张 GPU 卡作为一个不可分割的设备分配给 Pod。

# Kubernetes 原生方式：独占整张 GPU
apiVersion: v1
kind: Pod
metadata:
  name: llm-inference
spec:
  containers:
  - name: inference
    image: llm-serving:latest
    resources:
      limits:
        nvidia.com/gpu: 1  # 必须申请整张 GPU

这段配置说明了一切，nvidia.com/gpu: 1 意味着这个 Pod 独占一张完整的 GPU。无论它只用了 2GB 显存还是全部 80GB，无论算力只用了 10% 还是跑满，这张卡都不会再分配给其他 Pod。

真实代价

假设一个集群有 8 张 NVIDIA A100（80GB），每张约 15,000 美元，总硬件投入约 12 万美元。在原生调度模式下：

场景GPU 需求实际占用利用率
LLaMA 推理（7B 模型）14GB 显存，10% 算力整张 A100~18%
ResNet 评估4GB 显存，5% 算力整张 A100~5%
Jupyter 开发环境2GB 显存，间歇性使用整张 A100<5%

一张价值 15,000 美元的 A100，可能只被一个用了 2GB 显存的 Jupyter Notebook 独占。这不是个别现象，而是 AI 集群中的常态。

GPU 利用率低的根因分析

GPU 利用率低不是监控问题，而是调度问题。 在深入理解这个论断之前，我们需要分场景分析。

推理任务：显存占用高但计算空闲

在线推理是 GPU 集群中资源浪费最严重的场景。以一个 LLaMA-7B 的推理服务为例：

模型加载阶段：
  - 加载模型权重到 GPU 显存：约 14GB
  - GPU 利用率：短暂峰值后回落

推理服务阶段：
  - 显存占用：14GB（持续）
  - 计算利用率：5-30%（取决于请求 QPS）
  - 空闲时段：显存仍被占用，算力完全空闲

推理服务的特点决定了它的资源使用模式，显存是常驻的，但计算是间歇性的。在独占模式下，这张 GPU 剩余的 66GB 显存和 70% 的算力被完全浪费。

训练任务：静态分配与动态负载不匹配

模型训练看起来应该能充分利用 GPU，但实际情况更复杂：

  • 数据预处理阶段 GPU 闲置，等待 CPU 完成 ETL
  • 小模型微调只用了 GPU 的一部分能力
  • 多轮训练的间隙评估、检查点保存期间 GPU 空闲
  • 训练收敛后期计算密度远低于初始阶段

静态的整卡分配无法适应训练过程中的资源波动。

开发环境：大量闲置但被独占的 GPU

AI 研究人员的开发环境是 GPU 资源的“黑洞”：

  • 研究员启动一个 Jupyter Notebook，加载 GPU 运行时
  • 大部分时间在写代码、查资料、调试逻辑，GPU 完全空闲
  • 但 GPU 被这个会话独占，其他人都无法使用
  • 下班后，Notebook 可能还开着，GPU 继续被独占

一个 50 人的 AI 团队，可能需要 50 张 GPU 来满足开发需求，但任何时刻的实际利用率可能不到 10%。

根因总结

图 1: GPU 利用率低下的根因
图 1: GPU 利用率低下的根因

异构算力的管理困境

多厂商设备的现实

越来越多的 AI 基础设施需要面对异构加速器：

  • NVIDIA GPU：A100、H100、L40S、RTX4090 等
  • 华为昇腾 NPU：Ascend 910B 等
  • 寒武纪 MLU ：MLU370 等
  • 海光 DCU：Z100 等
  • 摩尔线程 GPU：MTTS4000 等

在地缘政治和技术主权的背景下，“国产替代”已成为许多企业的战略要求。这意味着一个集群可能同时包含 NVIDIA 和国产加速器。

各自为战的 Device Plugin

每个加速器厂商都提供了自己的 Kubernetes Device Plugin：

NVIDIA     → nvidia.com/gpu
华为昇腾    → ascend.com/npu
寒武纪      → cambricon.com/mlu
海光        → hygon.com/dcu

每个 Device Plugin 使用不同的资源名称、不同的配置方式、不同的监控接口。对于平台团队来说，这意味着：

  • 没有统一的资源视图：无法回答“集群里还有多少可用的加速器资源？”
  • 没有统一的调度策略：每个厂商需要独立配置调度规则
  • 没有统一的运维流程：升级、监控、故障排查各不相同
  • 没有统一的应用接口：工作负载需要针对不同厂商分别适配
# 为 NVIDIA GPU 配置的工作负载
apiVersion: v1
kind: Pod
metadata:
  name: inference-nvidia
spec:
  containers:
  - name: app
    resources:
      limits:
        nvidia.com/gpu: 1

---
# 为昇腾 NPU 配置的工作负载，完全不同的资源名称和配置方式
apiVersion: v1
kind: Pod
metadata:
  name: inference-ascend
spec:
  containers:
  - name: app
    resources:
      limits:
        ascend.com/npu: 1

两份配置，两种语义，两套运维流程。当集群中有三种甚至四种加速器时，管理复杂度呈指数级增长。

缺乏一致的资源视图

在异构集群中，一个简单的资源盘点都需要逐厂商查询：

# 查看 NVIDIA GPU 资源
kubectl get nodes -o custom-columns=NAME:.metadata.name,NVIDIA:.status.allocatable.nvidia\\.com/gpu

# 查看昇腾 NPU 资源
kubectl get nodes -o custom-columns=NAME:.metadata.name,ASCEND:.status.allocatable.ascend\\.com/npu

# 没有统一命令能告诉你：集群中总共有多少加速器算力可用？

我们需要什么？

面对上述挑战，AI 基础设施需要一个 GPU 感知的资源管理层。具体来说，它应该提供以下能力：

GPU 感知的资源管理

系统需要理解 GPU 的多维资源模型，显存、算力核心、设备数量都是可独立调度的维度。工作负载应该能够精确表达“我需要 8GB 显存和 30% 算力”，而不是被迫申请整张 GPU。

显存和算力的独立调度

不同工作负载对 GPU 的需求维度不同：

  • 推理任务主要需要显存（加载模型权重）
  • 训练任务主要需要算力（前向/反向传播）
  • 评估任务两者都需要，但量级较小

一个理想的系统应该允许显存和算力独立分配，让不同需求的工作负载能够互补地共享同一张 GPU。

异构设备的统一抽象

平台团队需要一套统一的资源抽象来管理所有加速器：

理想状态：
  统一的资源名称（如 nvidia.com/gpu）
  统一的调度语义（显存、算力、设备数量）
  统一的运维接口（监控、日志、故障排查）
  统一的应用体验（工作负载无需关心底层硬件）

零应用改动的接入方式

最重要的是，这些能力应该对上层应用透明。AI 工程师不应该需要学习新的 SDK 或修改模型代码。他们只需要在 Pod 的 resources.limits 中声明需要的 GPU 资源，就像声明 CPU 和内存一样自然。

图 2: GPU 资源管理需求的演进
图 2: GPU 资源管理需求的演进

小结

本章从 AI 基础设施的实际需求出发，分析了 GPU 管理面临的三大挑战：

  1. Kubernetes 调度局限：原生调度器只能整卡分配 GPU，无法按显存和算力精细调度
  2. GPU 利用率低下：推理、训练、开发环境中大量 GPU 资源被浪费，根因是调度粒度太粗
  3. 异构设备管理困难：多厂商加速器各自为战，缺乏统一的资源抽象和调度语义

这三个问题的共同指向是：Kubernetes 需要一个 GPU 感知的资源管理平面，它能够理解 GPU 的多维资源模型，支持显存和算力的独立调度，并为异构设备提供统一抽象。

下一章将介绍 HAMi 项目，一个 CNCF Sandbox 项目，正是为了解决这些问题而生。

创建于 2026/06/04 更新于 2026/06/05 2666 字 阅读约 6 分钟