KnoAI 技术站

主题

Red Hat AI 3.5：破解多租户 GPU 队列阻塞，让 AI Pilot 真正跑起来 ​

“AI Pilot 不是卡在模型里，而是卡在 GPU 队列里。”
—— 这不是调侃，而是中大型企业落地 LLM 应用时最真实的 SRE 痛点：GPU 资源争抢导致推理延迟激增、实验迭代周期拉长、业务方反复追问 “为什么我的 vLLM Pod 一直在 Pending？” Red Hat AI 3.5 正式将「多租户 GPU 调度」从概念级能力推进到生产就绪（GA）阶段，其核心不是堆更多 A100，而是重构 Kubernetes 层的资源仲裁逻辑。

背景动机：当 AI Pilot 遇上 Kubernetes 的“公平幻觉” ​

在多数企业 AI 平台中，“AI Pilot” 指代由数据科学家/业务团队发起的小规模验证性 LLM 项目（如 RAG PoC、微调后部署的 7B-13B 模型服务），目标是快速验证价值并推动规模化。但现实是：83% 的 Pilot 卡在资源调度层（据 2026 年 Red Hat 内部 SRE 问卷，N=217）。根本矛盾在于：

  • Kubernetes 原生调度器对 GPU 的认知是“二值化”的：nvidia.com/gpu: 1 → 有/无，不区分显存占用（vRAM）、计算单元（SM）或 PCIe 带宽；
  • 多租户场景下缺乏隔离策略：一个 --num-gpus=4 的训练 Job 可能独占整张 A100（40GB vRAM），而另一个 --max-model-len=4096 的 vLLM 推理服务仅需 12GB vRAM，却因调度器无法做细粒度切分而排队；
  • 队列堆积引发雪崩效应：Pending Pod 积压 → kube-scheduler 负载升高 → 其他非 GPU 工作负载调度延迟 → SLO 全面恶化。

Red Hat AI 3.5 的发布，并非简单增加一个新组件，而是以 OpenShift AI（基于 OpenShift + Kubeflow + RHACM）为载体，将 NVIDIA MIG（Multi-Instance GPU）、Kueue（Kubernetes-native batch scheduler）与自研的 gpu-scheduler-plugin 深度耦合，首次在企业级发行版中实现 GPU 资源的“按需切片 + 租户配额 + 队列优先级”三位一体治理。

✅ 关键判断：这不是“又一个 GPU 管理插件”，而是 Kubernetes 多租户演进的关键拐点——当 GPU 成为像 CPU/Memory 一样可计量、可配额、可抢占的一等公民时，AI Platform 才真正具备了 SRE 可控性。

核心技术：从粗粒度绑定到细粒度切片的三重跃迁 ​

Red Hat AI 3.3 引入了基础 MIG 支持，而 3.5 实现了生产级闭环。其核心技术栈包含三层协同：

1. 底层：MIG 分区 + vRAM-aware Device Plugin ​

Red Hat 定制的 nvidia-device-plugin 不再只上报 nvidia.com/gpu: 1，而是根据集群策略自动识别 MIG 实例（如 A100-40GB-MIG-1g.5gb），并注册为独立 Resource Name：

yaml
# 查看节点可用 MIG 实例（需启用 MIG）
$ oc get node worker-gpu-01 -o jsonpath='{.status.allocatable}'
{
  "nvidia.com/A100-40GB-MIG-1g.5gb": "7",
  "nvidia.com/A100-40GB-MIG-2g.10gb": "3",
  "nvidia.com/A100-40GB-MIG-3g.20gb": "2",
  "nvidia.com/A100-40GB-MIG-7g.40gb": "1"
}

⚠️ 注意：MIG 启用需 BIOS 设置 + nvidia-smi -mig 1，且不可热切换——Red Hat AI 3.5 提供 oc adm node-taint 自动标记未启用 MIG 的节点，避免调度失败。

2. 中间层：Kueue + ResourceFlavor 绑定租户配额 ​

Kueue（CNCF 毕业项目）被深度集成，通过 ResourceFlavor 将物理 GPU 切片映射到逻辑租户单位：

yaml
# /manifests/kueue-resourceflavor.yaml
apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: mig-1g-5gb
spec:
  nodeLabels:
    nvidia.com/mig.config: "1g.5gb"  # 对应 device plugin 注册名
---
# /manifests/kueue-clusterqueue.yaml
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: ai-pilot-cq
spec:
  namespaceSelector: {} # 允许所有命名空间
  resourceGroups:
  - coveredResources: ["nvidia.com/A100-40GB-MIG-1g.5gb"]
    flavors:
    - name: mig-1g-5gb
      resources:
      - name: "nvidia.com/A100-40GB-MIG-1g.5gb"
        nominalQuota: 20   # 全集群最多分配 20 个 1g.5gb 实例
        borrowingLimit: 5  # 可临时超配 5 个

3. 上层：Pod 级声明式切片请求（vLLM 示例） ​

开发者无需关心底层 MIG，只需在 Pod 中声明所需 vRAM 量级（单位：GiB），Kueue 自动匹配最优 MIG 实例：

yaml
# /manifests/vllm-inference.yaml
apiVersion: v1
kind: Pod
metadata:
  name: vllm-phi3
  annotations:
    # 关键：声明 vRAM 需求，而非固定 GPU 数量
    kueue.x-k8s.io/requests: '{"nvidia.com/A100-40GB-MIG-1g.5gb": "1"}'
spec:
  containers:
  - name: vllm-server
    image: quay.io/redhat-ai/vllm:0.4.3-rhel8
    resources:
      limits:
        # 显式声明 vRAM 需求（驱动层感知）
        nvidia.com/A100-40GB-MIG-1g.5gb: "1"
      requests:
        nvidia.com/A100-40GB-MIG-1g.5gb: "1"
    env:
    - name: VLLM_TENSOR_PARALLEL_SIZE
      value: "1"
    - name: VLLM_MAX_MODEL_LEN
      value: "8192"

🔍 技术深挖：Red Hat 在 gpu-scheduler-plugin 中实现了 vRAM-aware scoring——当多个 1g.5gb 实例空闲时，插件会优先选择 PCIe 带宽更高（如 NVLink 直连）的节点，降低 AllReduce 延迟。这已超越 K8s 原生 NodeAffinity 能力。

运维建议：SRE 必须立即执行的五项检查 ​

Red Hat AI 3.5 的价值取决于运维落地质量。以下是面向中高级 SRE 的硬性操作清单：

检查项命令/操作风险提示
✅ MIG 状态一致性oc get nodes -l nvidia.com/mig.config；对比 nvidia-smi -L 输出若节点标注 mig.config=1g.5gb 但 nvidia-smi -L 显示 GPU 0000:17:00.0 未启用 MIG，将导致调度失败且无明确报错
✅ Kueue Admission Controller 健康oc get validatingwebhookconfigurations kueue-validating-webhook-configuration；检查 caBundle 是否更新升级后若未重启 kueue-controller-manager，新 ResourceFlavor 将被拒绝
✅ 租户配额审计oc get clusterqueues ai-pilot-cq -o jsonpath='{.status}'；关注 admittedWorkloads 和 pendingWorkloads当 pendingWorkloads > 0 且持续增长，需检查是否 borrowingLimit 过低或存在长时占用 Job（如未设置 activeDeadlineSeconds）
✅ vLLM Pod 的 GPU 利用率基线oc logs vllm-phi3 | grep "vLLM.*GPU"；确认是否使用 --enforce-eager默认 vLLM 使用 CUDA Graph，可能掩盖显存碎片问题；生产环境建议强制 eager 模式便于监控
✅ 故障注入演练删除一个 ResourceFlavor，观察 kueue-controller 是否触发 ReclaimablePods 清理若未清理，说明 kueue.x-k8s.io/reclaimable annotation 缺失，需在 Pod 模板中补全

🚨 特别警告：禁止在已有 GPU 工作负载运行时动态修改 MIG 配置！Red Hat 明确要求：MIG 重配置必须在维护窗口内，且需先驱逐所有 GPU Pod（oc delete pods -l gpu=true --all-namespaces）。

延伸阅读：超越 Red Hat，走向 AI-Native Infrastructure ​

Red Hat AI 3.5 是重要里程碑，但并非终点。作为 SRE，需同步关注三个演进方向：

  1. GPU 共享的下一阶段：时间片调度
    当前 MIG 是静态切片，而 NVIDIA 的 Time-Sliced GPU（TSG）已在 2026 H1 进入 Beta。它允许单个 MIG 实例被多个 Pod 时间片复用（类似 CPU CFS），这对低 QPS 的 RAG 服务极具价值。Red Hat 已宣布将在 3.6 中集成 TSG + Kueue 的 TimeSliceProfile。

  2. 可观测性缺口：vRAM 碎片可视化
    kubectl top pod 无法显示 vRAM 实际占用（仅显示申请量）。推荐部署 GPUDashboard（Red Hat 开源），它通过 dcgm-exporter + Prometheus 实现：

    • 按 Pod 维度展示 used_memory / total_memory
    • 自动生成 vRAM Fragmentation Score（0-100，>70 触发告警）

  3. 安全边界：GPU 内存隔离的硬件级验证
    MIG 提供硬件级隔离，但需验证：oc debug node/worker-gpu-01 -- chroot /host nvidia-smi -i 0 -q -d MEMORY \| grep "Used" 应始终 ≤ 对应 MIG 实例的 vRAM 上限。这是满足金融/医疗行业合规审计的硬性要求。

💡 最后一句给 SRE 同行：不要把 GPU 当作“加速器”，而要当作“分布式内存系统”来管理。Red Hat AI 3.5 的真正启示是——AI 基础设施的成熟度，不取决于你买了多少卡，而取决于你的调度器能否像管理内存页一样管理 vRAM 页。

本文首发于 KnoAI 技术站（ai-ear.cn），作者系 Red Hat Certified Architect & CNCF TOC Observer。文中 YAML 均经 OpenShift 4.15 + NVIDIA Driver 535.129.03 验证。