AI 算力基础设施深度系列（四）：AI 算力平台架构设计——从调度到编排的全栈实战

AI 算力基础设施深度系列（四）：AI 算力平台架构设计——从调度到编排的全栈实战

本文是《AI 算力基础设施深度系列》第 4 篇，共 6 篇。
系列目录：① 容器与 K8S 基础 → ② K8S 底层原理 → ③ GPU 与异构算力 → ④ AI 平台架构 → ⑤ 高性能网络与存储 → ⑥ 生产运维与成本优化

导语

2024 年底，OpenAI 公开了一个让基础设施工程师集体沉默的数字：在 Kubernetes 上编排 25,000 块 GPU，平均每 2.5 小时发生一次硬件故障，依然维持了 97% 的利用率。

这不是实验室数据，而是 GPT 系列模型训练的生产指标。

同一时期，Google GKE 宣布单集群支持 65,000 个节点，并在一次测试中协调了 50,000 块 TPU 芯片进行超大规模训练。阿里云 ACK 从 2018 年发布首个开源 GPU 容器共享调度方案以来，已在内部和外部支撑了大量 AI 负载。

这些数字背后不是单个工具或组件的功劳，而是一套从硬件到应用的完整平台架构。

前三篇文章我们从容器基础、K8S 原理、GPU 管理逐步建立了技术栈。本篇将把这些知识点串联起来，回答一个核心问题：如何从零开始设计一个生产级的 AI 算力平台？

一、AI 工作负载的本质差异

1.1 为什么不能照搬微服务架构

AI 工作负载和传统 Web 应用的差异不是"程度上的不同"，而是"范式上的不同"：

维度 传统 Web/微服务 AI 训练 AI 推理
资源类型 CPU + Memory GPU/TPU + HBM + NVLink GPU + Memory
调度语义 单 Pod 调度 Gang 调度（全有或全无） 弹性调度
生命周期 持续运行（ms-s 级请求） 小时-周级（Job） 持续运行（Service）
数据 I/O KB-MB TB-PB GB（模型加载）
网络 普通 TCP RDMA 400Gbps+ 低延迟 TCP
故障容忍 无状态重启 Checkpoint + 恢复 无损滚动更新
扩展模式 水平 Pod 扩缩 数据并行 + 模型并行 + 流水线并行 自动弹性扩缩
成本 中等 极高（H100 ~$30K/块） 高

1.2 两种 AI 工作负载的核心矛盾

小模型推理:                          大模型训推:
  需要"把一块卡切成多份"              需要"把多块卡合成一块"
  1 Pod < 1 GPU                      1 Pod = N GPUs
  核心挑战: 显存隔离，防 OOM           核心挑战: 拓扑感知，最大化通信效率

        ┌─────────┐                         ┌─────────────────┐
        │  GPU-0  │                         │ GPU-0  GPU-1    │
        │┌──┐┌──┐│                         │ GPU-2  GPU-3    │
        ││A ││B ││  ← 多任务共享单卡        │ GPU-4  GPU-5    │
        │└──┘└──┘│                         │ GPU-6  GPU-7    │
        └─────────┘                         └─────────────────┘
                                              ↑ 单个 Pod 独占 8 卡

一个合格的 AI 算力平台必须同时支持这两种截然不同的工作模式。

二、总体架构设计：六层分离

2.1 参考架构

┌────────────────────────────────────────────────────────────────────┐
│                         用户接入层                                  │
│   Web Console │ CLI / SDK │ JupyterHub │ VS Code Server            │
├────────────────────────────────────────────────────────────────────┤
│                       AI 平台服务层                                 │
│   训练管理 │ 推理管理 │ 模型仓库 │ 数据集管理 │ 实验管理            │
├────────────────────────────────────────────────────────────────────┤
│                     AI 编排与调度层                                  │
│   Kubeflow │ KServe │ Volcano/KAI │ Kueue │ Training Operator      │
├────────────────────────────────────────────────────────────────────┤
│                    Kubernetes 核心层                                 │
│   API Server │ Scheduler │ Controller │ DRA │ Device Plugin         │
├────────────────────────────────────────────────────────────────────┤
│                     基础设施资源层                                   │
│   GPU Operator │ RDMA/RoCE │ 高性能存储 │ Container Runtime         │
├────────────────────────────────────────────────────────────────────┤
│                        硬件层                                       │
│   NVIDIA H100/B200 │ NVLink/NVSwitch │ InfiniBand │ NVMe SSD       │
└────────────────────────────────────────────────────────────────────┘

2.2 各层职责

第一层：硬件层 —— AI 算力的物理基础

主流配置：

  • GPU：NVIDIA H100 80GB / B200 192GB / AMD MI300X
  • 互联：NVLink 4.0 (900GB/s) + NVSwitch，节点间 InfiniBand NDR (400Gbps)
  • 存储：本地 NVMe SSD + 分布式并行文件系统
  • 网络：双平面——计算网络（RDMA）+ 管理网络（TCP）

第二层：基础设施资源层 —— 将硬件抽象为 K8S 可管理的资源

  • GPU Operator：自动管理 GPU 驱动、容器运行时、设备插件、监控
  • 网络：Multus CNI 多网卡、RDMA 设备插件
  • 存储：CSI 驱动对接高性能存储
  • 运行时：containerd + NVIDIA Container Runtime

第三层：Kubernetes 核心层 —— 增强原生能力

  • DRA：基于属性的 GPU 调度（K8S 1.31+）
  • Device Plugin：GPU 资源发现和分配
  • Topology Manager：NUMA 亲和性

第四层：AI 编排与调度层 —— AI 特有的编排能力

  • Volcano / KAI：Gang 调度、公平共享、优先级抢占
  • Kueue：批处理作业队列管理
  • Kubeflow：端到端 ML 流水线
  • KServe：模型推理服务

第五层：AI 平台服务层 —— 面向用户的上层抽象

屏蔽底层复杂性，提供训练管理、推理管理、模型仓库等业务能力。

第六层：用户接入层 —— 交互入口

Web 控制台、CLI、Jupyter Notebook、IDE 插件等。

三、Gang 调度：全有或全无

3.1 为什么需要 Gang 调度

分布式训练最怕"部分启动"：

场景: 训练任务需要 128 个 Worker，每个 8 卡 GPU

不使用 Gang 调度:
  调度器逐个调度 Pod
  → 120 个 Pod 成功，8 个因资源不足排队
  → 120 个 Pod 白白占着 960 块 GPU，等 8 个兄弟
  → 如果一直等不到，960 块 GPU 就一直空转
  → 每小时浪费 $2,880 (960 × $3/h)

使用 Gang 调度:
  → 128 个 Pod 全部满足才调度，否则整体排队
  → 要么全部启动干活，要么全部不占资源
  → 没有资源空转浪费

3.2 Volcano 调度器

Volcano 是 CNCF 孵化项目，专为批处理和 AI 工作负载设计：

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: llm-training
spec:
  schedulerName: volcano
  minAvailable: 128         # Gang 语义：至少 128 个 Pod 同时就绪
  queue: high-priority
  plugins:
    sla: ["--max-wait=1h"]  # 最长排队 1 小时
  policies:
  - event: PodEvicted
    action: RestartJob       # Pod 被驱逐时重启整个 Job
  - event: TaskCompleted
    action: CompleteJob
  tasks:
  - replicas: 128
    name: worker
    template:
      spec:
        containers:
        - name: trainer
          image: nvcr.io/nvidia/pytorch:24.01-py3
          command: ["torchrun", "--nproc_per_node=8", "train.py"]
          resources:
            limits:
              nvidia.com/gpu: 8
          env:
          - name: MASTER_ADDR
            value: "llm-training-worker-0.llm-training"
          - name: MASTER_PORT
            value: "29500"
        restartPolicy: OnFailure

Volcano 的核心能力：

能力 描述
Gang Scheduling 全有或全无调度语义
Queue Management 分层队列，支持权重和优先级
Fair Sharing 基于 DRF 的公平资源分配
Preemption 高优先级任务抢占低优先级
SLA Policy 最长排队时间、最长运行时间
Task Topology 支持 Master-Worker、PS-Worker 等模式

3.3 KAI 调度器（2026 新发布）

NVIDIA 主导并捐赠给 CNCF 的 Sandbox 项目，专为 AI 优化：

KAI 调度器核心特性:

┌─────────────────────────────────────────────┐
│ Gang 调度           → 全有或全无              │
│ 分层队列           → DRF 公平性              │
│ 子 GPU 分配         → 原生 MIG 支持           │
│ 预调度模拟         → 减少不必要的抢占          │
│ DRA 深度集成       → 感知 GPU 属性调度         │
│ Topology 感知      → NVLink/NUMA 优化         │
└─────────────────────────────────────────────┘

3.4 Kueue：K8S 原生队列管理

Kueue 是 K8S SIG Scheduling 的官方项目，提供集群级别的作业队列管理：

# ClusterQueue - 集群级资源池
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: gpu-pool
spec:
  resourceGroups:
  - coveredResources: ["cpu", "memory", "nvidia.com/gpu"]
    flavors:
    - name: h100-spot
      resources:
      - name: nvidia.com/gpu
        nominalQuota: 128       # Spot 资源配额
    - name: h100-ondemand
      resources:
      - name: nvidia.com/gpu
        nominalQuota: 64        # 按需资源配额
  preemption:
    withinClusterQueue: LowerPriority

---
# LocalQueue - 团队级队列
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  name: nlp-team-queue
  namespace: nlp-team
spec:
  clusterQueue: gpu-pool

---
# 提交作业到队列
apiVersion: batch/v1
kind: Job
metadata:
  name: bert-finetune
  namespace: nlp-team
  labels:
    kueue.x-k8s.io/queue-name: nlp-team-queue
spec:
  parallelism: 4
  completions: 4
  template:
    spec:
      containers:
      - name: trainer
        resources:
          requests:
            nvidia.com/gpu: "8"

Volcano vs Kueue 选型：

维度 Volcano Kueue
定位 完整的批处理调度器 队列管理+准入控制
Gang 调度 内建 需配合 JobSet
队列管理 基础 精细（多级队列、ResourceFlavor）
公平共享 基础 DRF 精细（借用、抢占策略）
K8S 原生度 自定义 Job CRD 利用原生 Job/JobSet
适合场景 MPI/Spark/AI 混合 纯 AI 训练作业管理

建议：如果只是做 AI 训练队列管理，Kueue 更原生更简洁；如果需要复杂的 Gang 调度语义（如 MPI Job），Volcano 更成熟。两者也可以组合使用。

四、拓扑感知调度深入

4.1 为什么拓扑至关重要

GPU 互联带宽层级:

NVLink (同 NVSwitch 域):  900 GB/s
PCIe 5.0 (跨 NUMA):      128 GB/s   → 7x 下降
InfiniBand NDR (跨节点):   50 GB/s   → 18x 下降
TCP/IP (跨机架):           12.5 GB/s → 72x 下降

在 AllReduce 通信密集的大模型训练中，调度器选错 GPU 拓扑，性能可能下降 3-8 倍。

4.2 拓扑调度策略

                        拓扑调度决策树

训练任务请求 N 块 GPU
    │
    ├── N <= 单节点 GPU 数 ?
    │   └── YES → 调度到同一节点，选同一 NVSwitch 域内的 GPU
    │
    ├── N > 单节点 GPU 数 ?
    │   └── YES → 多节点调度
    │       │
    │       ├── 优先选择同一机架（ToR 交换机域）的节点
    │       ├── 其次选择同一 Pod/Cluster（Spine 交换机域）
    │       └── 最后选择跨数据中心（最差）
    │
    └── GPU 型号是否一致 ?
        └── 必须一致（混合型号会导致通信不对称）

Google GKE 的 Compact Placement Policy：

# GKE 确保 Pod 调度到物理拓扑相邻的节点
apiVersion: scheduling.gke.io/v1
kind: CompactPlacement
metadata:
  name: training-placement
spec:
  topologyConstraint:
    type: COLLOCATED     # 物理相邻
    maxDistance: 2        # 最多 2 跳交换机

通过减少网络跳数，大模型训练可获得 10-20% 的吞吐提升。

五、训练编排

5.1 Kubeflow Training Operator

Kubeflow Training Operator 为主流 AI 框架提供 K8S 原生的训练任务管理：

# PyTorchJob - 分布式 PyTorch 训练
apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
  name: llm-pretrain
spec:
  elasticPolicy:
    minReplicas: 64
    maxReplicas: 128
    rdzvBackend: etcd
    rdzvEndpoint: "etcd-service:2379"
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      template:
        spec:
          containers:
          - name: pytorch
            image: nvcr.io/nvidia/pytorch:24.01-py3
            command:
            - torchrun
            - --nproc_per_node=8
            - --nnodes=$(WORLD_SIZE)
            - --node_rank=$(RANK)
            - --master_addr=$(MASTER_ADDR)
            - --master_port=$(MASTER_PORT)
            - train.py
            - --model=llama-70b
            - --batch-size=32
            resources:
              limits:
                nvidia.com/gpu: 8
                memory: "256Gi"
                rdma/rdma_shared_device_a: 1
            volumeMounts:
            - name: training-data
              mountPath: /data
            - name: checkpoints
              mountPath: /checkpoints
          volumes:
          - name: training-data
            persistentVolumeClaim:
              claimName: training-data-pvc
          - name: checkpoints
            persistentVolumeClaim:
              claimName: checkpoint-pvc
    Worker:
      replicas: 127
      template:
        spec:
          containers:
          - name: pytorch
            # ... 同 Master 配置

支持的框架：

CRD 框架 典型使用场景
PyTorchJob PyTorch 大模型预训练、微调
TFJob TensorFlow 推荐系统、传统 DL
MPIJob Horovod/MPI 混合并行训练
XGBoostJob XGBoost 表格数据 ML
PaddleJob PaddlePaddle 百度生态
JAXJob JAX Google 生态

5.2 Kubeflow Pipelines

端到端的 ML 工作流编排：

数据准备 → 特征工程 → 模型训练 → 模型评估 → 模型注册 → 部署上线

┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
│ 数据预处理│──►│ 特征提取  │──►│  训练     │──►│  评估    │
│ (CPU Job)│   │ (CPU Job)│   │(GPU Job) │   │ (CPU Job)│
└──────────┘   └──────────┘   └──────────┘   └────┬─────┘
                                                   │
                                            ┌──────▼─────┐
                                            │ 精度达标?   │
                                            └──┬──────┬──┘
                                              YES     NO
                                               │      │
                                         ┌─────▼──┐   └──→ 重新训练
                                         │ 模型注册│
                                         │ + 部署  │
                                         └────────┘

# Kubeflow Pipelines SDK 定义工作流
from kfp import dsl

@dsl.pipeline(name="llm-training-pipeline")
def training_pipeline(model_name: str, dataset: str, epochs: int):
    # Step 1: 数据预处理
    preprocess = preprocess_op(dataset=dataset)

    # Step 2: 训练（GPU）
    train = train_op(
        data=preprocess.outputs["processed_data"],
        model_name=model_name,
        epochs=epochs,
    ).set_gpu_limit(8).set_memory_limit("256Gi")

    # Step 3: 评估
    evaluate = evaluate_op(
        model=train.outputs["model"],
        test_data=preprocess.outputs["test_data"],
    )

    # Step 4: 条件部署
    with dsl.Condition(evaluate.outputs["accuracy"] > 0.95):
        deploy = deploy_op(model=train.outputs["model"])

六、推理服务：从训练到上线

6.1 推理架构

                 ┌───────────────┐
                 │  API Gateway  │
                 │ (限流/认证)    │
                 └──────┬────────┘
                        │
                 ┌──────▼────────┐
                 │   Inference   │
                 │   Gateway     │
                 │ (智能路由)     │
                 └──────┬────────┘
            ┌───────────┼───────────┐
            ▼           ▼           ▼
     ┌──────────┐ ┌──────────┐ ┌──────────┐
     │  vLLM    │ │  vLLM    │ │  vLLM    │
     │ Instance │ │ Instance │ │ Instance │
     │ Model A  │ │ Model A  │ │ Model B  │
     │ 2x H100  │ │ 2x H100  │ │ 1x H100  │
     └──────────┘ └──────────┘ └──────────┘

6.2 KServe 部署

KServe 是 Kubernetes 上最成熟的模型推理服务框架：

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: llm-service
spec:
  predictor:
    minReplicas: 2
    maxReplicas: 10
    scaleTarget: 70
    scaleMetric: concurrency
    model:
      modelFormat:
        name: vllm
      runtime: kserve-vllm
      storageUri: "s3://models/llama-70b"
      resources:
        limits:
          nvidia.com/gpu: "2"
          memory: "128Gi"
      args:
      - "--tensor-parallel-size=2"
      - "--max-model-len=8192"
      - "--gpu-memory-utilization=0.9"

6.3 推理网关：智能路由

传统的轮询负载均衡不适合 LLM 推理。不同请求的 token 数量差异巨大，需要基于模型服务器的实时状态做路由：

传统路由 (Round Robin):
  Request-A (100 tokens) → Instance-1 (空闲)      ✅
  Request-B (8000 tokens) → Instance-2 (空闲)     → Instance-2 忙碌
  Request-C (50 tokens) → Instance-3 (空闲)       ✅
  Request-D (100 tokens) → Instance-1              ✅
  Request-E (4000 tokens) → Instance-2             → Instance-2 更忙了，排队！

智能路由 (基于 KV Cache 利用率):
  Request-E (4000 tokens) → Instance-3 (KV Cache 10%)  ← 选最空闲的

Google 实践：GKE Inference Gateway 根据模型服务器的实时 KV Cache 利用率和队列深度路由请求。效果：成本降低 30%，尾部延迟降低 60%。

6.4 弹性伸缩

# KEDA 自定义指标伸缩
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: llm-scaler
spec:
  scaleTargetRef:
    name: llm-deployment
  minReplicaCount: 2
  maxReplicaCount: 20
  cooldownPeriod: 300
  triggers:
  - type: prometheus
    metadata:
      query: |
        sum(vllm_num_requests_waiting{model="llama-70b"})
      threshold: "10"           # 等待请求 > 10 则扩容
  - type: prometheus
    metadata:
      query: |
        avg(vllm_gpu_cache_usage_perc{model="llama-70b"})
      threshold: "80"           # KV Cache > 80% 则扩容

缩容到零：对于低频调用的模型，可以配置缩容到 0 副本，有请求时再冷启动。但 GPU 模型加载通常需要分钟级，需要配合模型预热和镜像缓存优化冷启动时间。

七、多集群联邦架构

7.1 为什么需要多集群

单 K8S 集群的规模上限：

维度 官方上限 实际瓶颈
节点数 5,000 etcd 性能、API Server 负载
Pod 数 150,000 调度器吞吐量
Service 数 10,000 kube-proxy 规则量

OpenAI 的经验：单集群在 ~5,000 节点时遇到 etcd 性能瓶颈和 API Server 负载二次方增长。他们采用分层集群联邦管理 25,000 GPU。

7.2 联邦架构设计

              ┌──────────────────┐
              │    管理集群       │
              │   (控制平面)      │
              │  ┌────────────┐  │
              │  │ 联邦调度器  │  │
              │  │ ArgoCD     │  │
              │  │ 监控聚合   │  │
              │  │ 成本分析   │  │
              │  └────────────┘  │
              └────────┬─────────┘
         ┌─────────────┼─────────────┐
         ▼             ▼             ▼
  ┌────────────┐ ┌────────────┐ ┌────────────┐
  │ GPU 集群 A │ │ GPU 集群 B │ │ GPU 集群 C │
  │ H100 ×1K  │ │ H100 ×1K  │ │ A100 ×2K  │
  │ 训练专用   │ │ 训练专用   │ │ 推理专用   │
  └────────────┘ └────────────┘ └────────────┘

分治策略：

  • 训练集群：配备高端 GPU（H100/B200）+ RDMA 网络，优化大规模训练
  • 推理集群：混合 GPU 配置（H100 + A100 + T4），优化成本和延迟
  • 开发集群：中低端 GPU + Time-Slicing/HAMi，最大化利用率

7.3 跨集群调度

# 联邦层面的工作负载分发策略
apiVersion: federation.example.com/v1
kind: FederatedJob
metadata:
  name: large-scale-training
spec:
  placement:
    clusterSelector:
      matchLabels:
        cluster-type: training
        gpu-model: h100
    preferences:
    - clusterName: gpu-cluster-a
      weight: 60                # 60% 负载到集群 A
    - clusterName: gpu-cluster-b
      weight: 40                # 40% 负载到集群 B
  template:
    spec:
      # ... 训练 Job 定义

八、云厂商方案横评

8.1 全方位对比

维度 Google GKE AWS EKS 阿里云 ACK
最大集群 65,000 节点 10,000 节点 20,000 节点
GPU 调度 DRA + Compact Placement Device Plugin + EFA cGPU + 拓扑感知
GPU 共享 MIG + Time-Slicing + DRA MIG + Time-Slicing cGPU（内核级隔离）
网络 GPUDirect TCPX + Multi-NIC EFA (400Gbps) eRDMA
推理优化 Inference Gateway SageMaker + EKS KServe + AI 套件
调度器 原生 + JobSet 原生 + Karpenter Volcano + 自研
弹性伸缩 Autopilot + Karpenter Karpenter ACK 弹性伸缩
模型加载 Secondary Boot Disk (29x) Cache Mount CPFS + 镜像缓存
成本优化 Spot VM + Compute Class Spot + Savings Plan 抢占式实例
独特优势 TPU、Inference Gateway SageMaker 生态、EFA cGPU、ACK One 混合云

8.2 选型建议

选 Google GKE 如果:
  → 超大规模单集群 (65K 节点)
  → 使用 TPU 训练
  → 重视推理优化 (Inference Gateway)

选 AWS EKS 如果:
  → 已有 AWS 生态 (S3/SageMaker/CloudWatch)
  → 需要 EFA 做大规模分布式训练
  → 使用 Karpenter 成本优化

选阿里云 ACK 如果:
  → 业务主要在国内
  → 需要 GPU 共享 (cGPU 最成熟)
  → 有混合云需求 (ACK One)

自建如果:
  → 有 GPU 硬件，需要最大化利用率
  → 安全合规要求本地部署
  → 有 K8S + GPU 运维能力
  → 开源组合: K8S + Volcano + GPU Operator + Kubeflow + KServe

九、平台化交付：让 AI 工程师不感知基础设施

9.1 抽象层设计

一个好的 AI 算力平台应该让数据科学家完全不需要关心 K8S 概念：

数据科学家看到的:                     平台内部实际发生的:

"我要训练一个 LLM"                   → 创建 PyTorchJob CR
"用 8 机 64 卡"                       → Gang 调度 + 拓扑感知
"数据在 /data/pretrain"              → 挂载 PVC (Lustre CSI)
"每 30 分钟存一次 checkpoint"         → 配置 Checkpoint Sidecar
"训练完自动评估"                      → Kubeflow Pipeline
"精度达标就上线"                      → KServe InferenceService

9.2 API 设计示例

# 面向用户的简化 API（平台内部转换为 K8S 原生对象）
apiVersion: platform.example.com/v1
kind: TrainingTask
metadata:
  name: llm-70b-pretrain
  namespace: nlp-team
spec:
  framework: pytorch
  model:
    name: llama-70b
    config: /configs/llama-70b.yaml
  compute:
    nodes: 8
    gpuPerNode: 8
    gpuType: H100                    # 平台自动转换为节点亲和性
  data:
    training: s3://datasets/pretrain
    output: s3://models/llama-70b
  checkpoint:
    interval: 30m
    storage: lustre
    maxKeep: 5
  monitoring:
    wandb:
      project: llm-pretrain
      apiKey:
        secretRef: wandb-api-key

平台 Operator 将这个简化的 CR 转换为底层的一系列 K8S 对象：

TrainingTask CR
    ├── PyTorchJob (Kubeflow)
    │   ├── Master Pod (1x, 8 GPU)
    │   └── Worker Pods (7x, 8 GPU each)
    ├── PVC (training-data, ReadOnlyMany)
    ├── PVC (checkpoint-storage, ReadWriteMany)
    ├── ConfigMap (training-config)
    ├── Secret (wandb-api-key)
    ├── ServiceMonitor (Prometheus)
    └── NetworkAttachmentDefinition (RDMA)

十、总结与下一篇预告

本篇核心要点回顾

1. AI 工作负载 vs 传统应用: 本质不同
   └── 资源类型/调度语义/网络需求/故障处理全不同

2. 六层平台架构:
   └── 硬件→基础设施→K8S 核心→AI 编排→平台服务→用户接入

3. Gang 调度 (Volcano/KAI/Kueue):
   └── 全有或全无，避免部分启动浪费资源

4. 拓扑感知:
   └── NVLink vs PCIe 性能差 7x，必须考虑拓扑

5. 训练编排 (Kubeflow Training Operator):
   └── PyTorchJob/MPIJob 等原生分布式训练支持

6. 推理服务 (KServe):
   └── 弹性伸缩 + 智能路由 + 金丝雀发布

7. 多集群联邦:
   └── 单集群 5K 节点瓶颈，多集群分治

8. 平台化交付:
   └── 让 AI 工程师不感知 K8S 复杂性

下一篇预告

平台架构设计完成了，但有两个关键基础设施还没有深入——网络和存储。如果 GPU 是算力平台的"心脏"，那么高性能网络就是"血管"，存储就是"粮仓"。

第 5 篇《高性能网络与存储：AI 训练的血管与粮仓》 将深入：

  • 为什么 AI 训练需要 RDMA？TCP 到底差在哪里？
  • InfiniBand、RoCE v2、eRDMA 技术原理和选型
  • GPUDirect RDMA 如何将通信延迟降低 10 倍？
  • 双平面网络架构的设计与配置
  • 分层存储架构（NVMe → Lustre → S3）怎么设计？
  • Checkpoint 策略如何在故障频发的 GPU 集群中保住训练进度？

分布式训练的通信开销占总时间的 30-50%，网络做不好，堆再多 GPU 也是浪费。

参考资料

  1. Kubernetes for GPU Orchestration - Introl - OpenAI 25K GPU 集群实践
  2. GKE AI/ML Platform - Google - Google GKE AI 平台
  3. Volcano Scheduler - Gang 调度官方文档
  4. Kueue - kubernetes-sigs - K8S 原生队列管理
  5. Kubeflow Training Operator - 训练编排文档
  6. KServe Documentation - 模型推理服务
  7. 阿里云 ACK AI 套件 - ACK GPU 方案
  8. GKE Inference Gateway - 推理网关
  9. CNCF AI on Kubernetes - CNCF 最佳实践
  10. KAI Scheduler - CNCF - NVIDIA AI 调度器

关注公众号「coft」，获取更多 AI 实战干货和 AI-Infra 深度教程。

posted @ 2026-03-28 23:43  warm3snow  阅读(29)  评论(0)    收藏  举报