跳转至

AI/LLM on Kubernetes 基础设施

这套文档讨论的不是“怎样把一个带 GPU 的 Pod 跑起来”,而是怎样把 Kubernetes 建设成一套可持续演进的 AI/LLM 基础设施:设备能被发现和隔离,作业能公平排队,数据能跟上算力,训练能够恢复,推理能够满足延迟目标,模型和依赖能够追溯,平台能够升级、观测和审计。

内容覆盖从硬件到应用的完整链路,并尽量回答四类问题:组件负责什么、什么时候需要、怎样验证、出问题从哪里排查。

按主题浏览 查看参考架构 运行 GPU 平台实验 进入实战与排障

基础设施全景

用户、SDK、应用与工作流
        │
        ├─ 大数据 / RAG / Agent / 在线推理 / 训练任务
        │
Gateway、Serving、Trainer、Pipeline、Queue
        │
Kubernetes API、控制器、调度器、准入与策略
        │
Device Plugin / CDI / DRA / CNI / CSI / CRI
        │
GPU、TPU、NPU、CPU、RDMA、NVMe、对象存储
        │
供电、散热、机架、故障域与数据中心网络

任何一层都可能成为瓶颈。GPU 利用率低不一定是 GPU 问题,也可能是排队策略、CPU 解码、模型下载、存储吞吐、网络拥塞、请求路由或批处理参数造成的。阅读和排障时,应沿着完整请求或作业链路逐层验证。

从哪里开始

你的目标 建议路径
从零理解 AI 如何运行在 Kubernetes 上 Kubernetes 如何承载 AI → 集群架构设计 → 术语表
建设或接管 GPU 集群 GPU 节点软件栈 → 设备管理 → GPU 调度 → 平台运维
选择开源集群管理平台 开源集群管理工具与方式 → 平台运维 → 跨集群与大规模 GPU
选择国内外云厂商 Kubernetes 云厂商托管 Kubernetes → 集群架构设计 → 异构加速器
建设 GPU Notebook 开发平台 GPU Notebook 平台与存储 → GPU 调度 → 数据与缓存 → MLOps
建设大数据与 AI 数据平台 大数据 on Kubernetes → 数据与缓存 → 模型制品 → MLOps
建设多租户训练平台 队列与多租户 → 分布式训练 → RDMA 网络 → 可靠性
建设 Ray 大模型平台 Ray 训练与推理 → 分布式训练 → 大数据 on Kubernetes → 可靠性
建设在线 LLM 推理服务 本地运行与测试 → 推理平台总览 → 推理引擎 → Serving 框架 → API 中转与网关选型 → 网关与路由 → Higress 实战
规划多地域或多 GPU 集群 集群架构设计 → 跨集群与大规模 GPU → 生产参考架构
建设 RAG 或 Agent 平台 Agent 现状与趋势 → Agent Harness → HarnessRouter → DeepSeek Harness 容器化 → Kubernetes 实战 → Agent Sandbox 选型 → 安全治理
负责 SRE、成本或容量 可观测性 → 性能基准 → 成本与容量 → 落地路线图

完整主题地图

基础与架构

集群、节点与加速器

队列、弹性与容量

网络、数据与模型制品

分布式训练

LLM 推理

RAG、Agent 与边缘

平台工程与生产运维

参考架构与实验

工具不等于架构

同一层通常有多个项目可选,项目之间也可能重叠。选择工具前先写清输入、输出、所有者和验收指标。

能力 常见实现 先回答的问题
设备接入 Device Plugin、CDI、DRA、厂商 Operator 需要整卡、分片、拓扑还是动态声明?
批调度 kube-scheduler、Kueue、Volcano 需要准入队列、公平共享还是 Gang Scheduling?
大数据计算 Spark、Flink、Trino、Ray Data 是批处理、流状态、交互 SQL 还是 AI 数据准备?
训练控制 Kubeflow Trainer、JobSet、KubeRay 训练框架、容错和弹性边界是什么?
模型服务 KServe、Seldon、自建控制器 需要标准模型 API、多模型还是 LLM 专用能力?
推理运行时 vLLM、SGLang、TensorRT-LLM、Triton 目标模型、硬件、延迟和吞吐是什么?
请求入口 Gateway API、Inference Extension、服务网格 路由需要理解模型、KV Cache 和队列状态吗?
Agent 执行 Agent Sandbox、gVisor、Kata、托管 Sandbox API 生命周期、隔离运行时和工具授权是否已经分层?
可观测性 Prometheus、OpenTelemetry、DCGM Exporter 能否从用户请求追到 Pod、GPU、网络和模型版本?

内容状态和更新规则

  • stable:原理和生产方法相对稳定,仍需结合目标 Kubernetes 和组件版本验证。
  • evolving:上游 API、项目边界或最佳实践仍在快速变化,上线前应检查官方版本说明。
  • lab:用于复现和学习的最小实验,不应不经评审直接复制到生产。
  • last_reviewed:最近一次按一手资料复核的日期,不代表所有依赖都固定在该日期。
  • 示例优先表达结构和验证方法;生产配置还必须补齐镜像固定、容量、身份、密钥、备份、SLO 和变更流程。

建议的建设顺序

  1. 先建立节点、驱动、网络、存储和 GPU 的可重复验收基线。
  2. 再统一资源模型、队列、租户、镜像、模型制品和可观测性。
  3. 分别为训练、在线推理、离线推理、RAG 和 Agent 建立黄金路径。
  4. 用性能基准、故障演练、成本指标和升级矩阵形成持续交付门禁。
  5. 最后再根据规模引入 DRA、高级拓扑、分离式推理、多集群和复杂调度策略。

如果正在规划第一版平台,可以从 生产参考架构 选一个最接近的起点,再用 落地路线图 拆成阶段目标。