如何设计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 也是浪费。 参考资料 Kubernetes for GPU Orchestration - Introl - OpenAI 25K GPU 集群实践 GKE AI/ML Platform - Google - Google GKE AI 平台 Volcano Scheduler - Gang 调度官方文档 Kueue - kubernetes-sigs - K8S 原生队列管理 Kubeflow Training Operator - 训练编排文档 KServe Documentation - 模型推理服务 阿里云 ACK AI 套件 - ACK GPU 方案 GKE Inference Gateway - 推理网关 CNCF AI on Kubernetes - CNCF 最佳实践 KAI Scheduler - CNCF - NVIDIA AI 调度器 关注公众号「coft」，获取更多 AI 实战干货和 AI-Infra 深度教程。