云原生 AI 平台搭建：从集群规划到 GPU 调度的全链路设计实践

一、AI 平台落地的第一道坎：集群搭建为何总是"踩坑不断"

AI 平台从 POC 到生产落地，集群搭建是绕不过去的第一步。很多团队在 POC 阶段用单机跑通了模型训练和推理，信心满满地准备上云原生架构，结果发现：GPU 驱动版本与容器运行时不兼容、多租户资源隔离形同虚设、存储卷挂载导致训练任务 I/O 瓶颈、网络策略把分布式训练的梯度同步堵死了。这些问题不是"调调参数就能解决"的，它们根植于集群规划阶段的架构决策失误。

更深层的问题是，AI 工作负载与传统微服务有着本质区别------它需要 GPU 直通、高带宽存储访问、RDMA 网络通信，以及对长时间运行任务的容错机制。如果直接套用微服务的 Kubernetes 部署模板，结果往往是"能跑但跑不好"。本文将从集群规划、GPU 调度、存储网络三个维度，拆解云原生 AI 平台搭建的关键设计决策。

二、集群架构与 GPU 调度的底层机制

云原生 AI 平台的核心挑战在于：如何让 Kubernetes 原生的调度体系适配 GPU 这种异构资源。默认调度器只感知 CPU/内存，对 GPU 的显存碎片、算力共享、拓扑亲和等特性一无所知。

graph TB subgraph "Kubernetes 集群" subgraph "控制平面" API[API Server] Sched[默认调度器] DevicePlugin[GPU Device Plugin] end subgraph "GPU 节点组" N1[Node1: 4xA100] N2[Node2: 4xA100] N3[Node3: 8xV100] end subgraph "调度扩展层" ExtSched[扩展调度器] Extender[Scheduler Extender] CRD[PodGroup CRD] end end API --> Sched Sched --> Extender Extender --> ExtSched DevicePlugin --> API ExtSched --> CRD Sched --> N1 Sched --> N2 Sched --> N3

上图展示了 GPU 调度的扩展架构。关键机制包括：

GPU Device Plugin ：NVIDIA 官方提供的 nvidia-k8s-device-plugin 向 kubelet 注册 GPU 资源，将 nvidia.com/gpu 作为可调度资源暴露给调度器。但它默认只做整数分配------一个 Pod 要么占用整块 GPU，要么分配不到。这意味着如果推理服务只需要 4GB 显存，而 A100 有 80GB，剩余 76GB 就被浪费了。

MIG（Multi-Instance GPU） ：A100/H100 支持 MIG 模式，将一块物理 GPU 切分为多个隔离实例，每个实例拥有独立的显存和算力。通过 Device Plugin 的 MIG 配置，调度器可以按 nvidia.com/mig-1g.5gb 这样的粒度分配 GPU 资源，实现显存级别的精细调度。

拓扑感知调度 ：多 GPU 训练任务对 GPU 间的通信延迟极度敏感。同一 PCIe Switch 下的 GPU 通信延迟远低于跨 NUMA 节点的 GPU。Kubernetes 1.26+ 引入的 PodTopologySpread 和 NVIDIA 的 GPU 拓扑发现工具，可以让调度器优先将多 GPU 任务调度到拓扑最优的节点。

三、生产级集群搭建与 GPU 调度实现

3.1 集群初始化与 GPU 节点配置

bash 复制代码

#!/bin/bash
# GPU 节点初始化脚本：驱动、容器运行时、Device Plugin 一键部署
set -euo pipefail

# 1. 安装 NVIDIA 驱动（指定版本，避免自动更新导致不兼容）
NVIDIA_DRIVER_VERSION="535.129.03"
apt-get update && apt-get install -y \
    nvidia-driver-${NVIDIA_DRIVER_VERSION} \
    nvidia-utils-${NVIDIA_DRIVER_VERSION}

# 2. 验证驱动加载
nvidia-smi || { echo "GPU 驱动加载失败"; exit 1; }

# 3. 安装 NVIDIA Container Toolkit（替代旧版 nvidia-docker2）
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
    gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
apt-get install -y nvidia-container-toolkit

# 4. 配置 containerd 集成
nvidia-ctk runtime configure --runtime=containerd
systemctl restart containerd

# 5. 验证 GPU 在容器中可用
ctr run --rm --runtime=nvidia -e NVIDIA_VISIBLE_DEVICES=all \
    docker.io/nvidia/cuda:12.2.0-base-ubuntu22.04 \
    gpu-test nvidia-smi

3.2 Device Plugin 与 MIG 分区配置

yaml 复制代码

# nvidia-device-plugin ConfigMap：启用 MIG 分区策略
apiVersion: v1
kind: ConfigMap
metadata:
  name: nvidia-device-plugin-config
  namespace: gpu-operator
data:
  default: |
    version: v1
    flags:
      migStrategy: mixed
    sharing:
      timeSlicing:
        resources:
          - name: nvidia.com/gpu
            replicas: 4  # 每块 GPU 时间分片为 4 份
---
# Device Plugin DaemonSet
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nvidia-device-plugin-daemonset
  namespace: gpu-operator
spec:
  selector:
    matchLabels:
      name: nvidia-device-plugin-ds
  template:
    metadata:
      labels:
        name: nvidia-device-plugin-ds
    spec:
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      containers:
        - name: nvidia-device-plugin
          image: nvcr.io/nvidia/k8s-device-plugin:v0.14.1
          args: ["--config-file=/etc/nvidia-device-plugin/config.yaml"]
          volumeMounts:
            - name: config
              mountPath: /etc/nvidia-device-plugin
      volumes:
        - name: config
          configMap:
            name: nvidia-device-plugin-config

3.3 GPU 任务的拓扑感知调度

go 复制代码

package scheduler

import (
	"context"
	"fmt"

	corev1 "k8s.io/api/core/v1"
	"k8s.io/kubernetes/pkg/scheduler/framework"
)

// GPUTopologyScore 基于GPU拓扑关系计算节点得分
// 核心逻辑：同一PCIe Switch下的GPU通信延迟最低，优先调度
type GPUTopologyScore struct{}

func (g *GPUTopologyScore) Score(ctx context.Context, state *framework.CycleState,
	pod *corev1.Pod, nodeName string) (int64, *framework.Status) {

	// 获取节点GPU拓扑信息
	topology, err := g.getNodeGPUTopology(nodeName)
	if err != nil {
		return 0, framework.NewStatus(framework.Error, err.Error())
	}

	requestedGPUs := g.countRequestedGPUs(pod)
	if requestedGPUs <= 1 {
		// 单GPU任务无需拓扑感知，返回默认分数
		return framework.MinNodeScore, nil
	}

	// 计算该节点上可用GPU的最优拓扑分组得分
	// 同一PCIe Switch下的GPU对得分最高
	bestGroupScore := g.calculateTopologyScore(topology, requestedGPUs)

	return bestGroupScore, nil
}

// calculateTopologyScore 评估GPU拓扑分组质量
// NVLink直连 > 同PCIe Switch > 同NUMA > 跨NUMA
func (g *GPUTopologyScore) calculateTopologyScore(
	topology *GPUTopology, requestedCount int) int64 {

	var bestScore int64
	groups := topology.GetAvailableGroups(requestedCount)

	for _, group := range groups {
		var score int64
		for i := 0; i < len(group); i++ {
			for j := i + 1; j < len(group); j++ {
				link := topology.GetLinkType(group[i], group[j])
				switch link {
				case NVLink:
					score += 100 // NVLink直连，最高优先
				case SamePCIeSwitch:
					score += 80
				case SameNUMA:
					score += 50
				case CrossNUMA:
					score += 10 // 跨NUMA，最低优先
				}
			}
		}
		if score > bestScore {
			bestScore = score
		}
	}
	return bestScore
}

四、架构权衡与边界分析

方案一：MIG 分区 vs 时间分片

维度	MIG 分区	时间分片
隔离性	硬件级隔离，显存与算力完全独立	软件级共享，存在上下文切换开销
粒度	固定分区（1g.5gb/2g.10gb/3g.20gb）	灵活配比，可任意设定 replicas
性能	接近原生，无额外延迟	上下文切换导致 5-15% 性能损耗
适用场景	推理服务，需要稳定延迟保证	开发测试，对延迟不敏感

方案二：默认调度器 + Extender vs Volcano 调度器

默认调度器通过 Extender 扩展 GPU 感知能力，实现简单但调度效率低------每次调度决策都需要 Extender 远程调用，增加延迟。Volcano 作为独立批调度器，原生支持 Gang Scheduling 和排队机制，适合训练任务场景，但引入了额外的组件复杂度和维护成本。

关键边界条件：

MIG 模式仅支持 A100/H100 架构，V100/T4 等老架构无法使用，只能退而求其次使用时间分片
拓扑感知调度依赖节点上的 NVLink 拓扑发现工具，如果集群中存在异构 GPU 节点（A100 混 V100），拓扑数据不一致会导致调度决策失准
GPU 时间分片在推理场景下可能导致尾延迟（P99）抖动，对 SLA 要求严格的线上服务需谨慎使用

五、总结

云原生 AI 平台搭建的核心矛盾在于：Kubernetes 的调度体系为通用工作负载设计，而 AI 工作负载需要 GPU 精细调度、高带宽存储和低延迟网络。解决路径分三步：

第一，集群规划阶段明确 GPU 节点分组策略------训练节点用整卡分配 + 拓扑感知，推理节点用 MIG 或时间分片提升利用率。第二，存储选型上，训练场景优先考虑并行文件系统（如 Lustre/CPFS），避免 NFS 的单点带宽瓶颈；推理场景用本地 SSD 缓存模型权重，减少冷启动延迟。第三，网络层面，多机训练必须启用 RDMA 或 NVLink 通信，否则梯度同步的带宽瓶颈会让多卡扩展比接近 1。

平台搭建没有银弹，每个决策都是在资源利用率、延迟稳定性和运维复杂度之间做取舍。理解底层机制，才能在具体场景中做出合理的架构选择。