Kubernetes AI/ML 基础设施项目全景调研 #

调研日期：2026-05-08 | 覆盖项目：Volcano、HAMi、Ray、LeaderWorkerSet、Kueue、KServe、Kubeflow、Seldon Core、vLLM、Triton、GPU Operator 等

一、技术栈全景图 #

Kubernetes AI/ML 基础设施可按层次理解：

┌──────────────────────────────────────────────────────────────────────┐
│                        ML 平台层 (Platform)                          │
│     Kubeflow、Caikit、Open Data Hub、MLflow                          │
├──────────────────────────────────────────────────────────────────────┤
│                        模型服务层 (Serving)                           │
│     KServe、Seldon Core、vLLM、SGLang、Triton、Ray Serve              │
├──────────────────────────────────────────────────────────────────────┤
│                        训练层 (Training)                              │
│     Kubeflow Trainer、MPI Operator、Ray Train、DeepSpeed              │
├──────────────────────────────────────────────────────────────────────┤
│                        调度层 (Scheduling)                            │
│     Volcano、Kueue、LeaderWorkerSet、KAI Scheduler、JobSet            │
├──────────────────────────────────────────────────────────────────────┤
│                        GPU/设备层 (Device)                            │
│     NVIDIA GPU Operator、HAMi、DRA (Dynamic Resource Allocation)     │
├──────────────────────────────────────────────────────────────────────┤
│                        Kubernetes 基础                                │
│     kube-scheduler、Device Plugins、Node Feature Discovery            │
└──────────────────────────────────────────────────────────────────────┘

二、核心项目热度总览 #

三、重点项目深度分析 #

1. Volcano — 云原生批调度系统 #

📦 GitHub | ⭐ ~5,000+ | 🏷️ CNCF Incubating (2022)

使用场景 #

Volcano 解决 Kubernetes 默认调度器对批处理和 AI 工作负载的不足：

• Gang Scheduling（全或无调度）：分布式训练（PyTorch、TensorFlow）需要所有 Pod 同时启动，否则造成资源死锁
• 队列管理与公平调度：多租户集群需要资源配额、优先级调度、跨团队公平分配
• GPU/异构设备调度：AI 工作负载需要高效的 GPU 共享、MIG 分区、NPU 调度
• 回填调度（Backfill）：大作业等待时，小作业填充空隙以提高利用率

典型场景：AI/ML 训练与推理、大数据处理（Spark/Flink）、HPC/MPI、生物信息学、在线离线混合部署

生产用户：腾讯、百度、AWS、ING Bank、科大讯飞、小红书、滴滴、爱奇艺、理想汽车、Apache Spark (v3.3+ 内建)

工作原理 #

三大组件：

• vc-scheduler：基于插件的自定义调度器，与 kube-scheduler 并行运行
• vc-controller-manager：管理 Volcano Job 生命周期
• vc-webhook-manager：准入 Webhook

调度模型（Action + Plugin 组合模式）：

调度周期 → Enqueue → Allocate → Preempt → Reclaim → Backfill
             ↑          ↑         ↑         ↑         ↑
           配额检查    节点选择    抢占      回收      回填

核心插件：

• gang — 全或无调度（分布式作业核心）
• drf — 多维资源公平调度
• proportion — 队列资源按比例共享
• binpack — 紧凑分配减少碎片
• priority — 作业/ Pod 优先级排序

CRD：VolcanoJob (batch.volcano.sh/v1alpha1 Job)，通过 minAvailable 字段启用 Gang Scheduling

使用方法 #

# 安装
helm repo add volcano-sh https://volcano-sh.github.io/helm-charts
helm install volcano volcano-sh/volcano -n volcano-system --create-namespace

# VolcanoJob 示例
apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: training-job
spec:
  minAvailable: 3
  schedulerName: volcano
  tasks:
    - replicas: 3
      name: worker
      template:
        spec:
          containers:
            - name: worker
              image: pytorch/training:latest
              resources:
                limits:
                  nvidia.com/gpu: 1
          restartPolicy: Never

# 队列定义
apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: ai-team-queue
spec:
  weight: 1
  capability:
    cpu: "8"
    memory: "16Gi"
    nvidia.com/gpu: "4"

局限性 #

• 学习曲线较陡：使用自定义 CRD，非原生 K8s Job API
• 不替代默认调度器：需显式指定 schedulerName: volcano，否则 Gang Scheduling 无效
• 框架集成侵入性强：每个框架需要源码级修改来适配 Volcano 资源
• 多租户支持有限：不原生控制用户到队列的访问，依赖 RBAC
• 配置复杂：插件/Action 系统强大但需理解调度器内部原理
• 抢占仅驱逐 Running 状态的 Pod：分布式系统中可能出现不完整驱逐

最新动态（v1.14） #

• 可扩展多调度器架构（大规模集群动态分片）
• Agent Scheduler：AI Agent 工作负载快速调度
• HyperNode 级 Binpacking 与网络拓扑感知调度
• 多级 Gang Scheduling（Job 和 SubGroup 范围）
• Kthena 子项目（2026-01）：K8s 原生 LLM 推理路由编排
• AgentCube：AI Agent 工作负载子项目
• 2025-05 完成正式安全审计

2. HAMi — 异构 AI 算力虚拟化 #

📦 GitHub | ⭐ ~3,200+ | 🏷️ CNCF Sandbox (2024-08)

使用场景 #

核心问题：K8s 将 GPU 视为不可分割的整数资源（1 Pod = 1 GPU）。在 80GB GPU 上仅申请 24GB 显存的 Pod 会锁定整张卡，~70% 闲置，集群利用率仅 30-40%。

HAMi 解决的问题：

• GPU 共享：多个 Pod 共享单个物理 GPU，按需分配显存和算力（如 3GB 显存 + 50% 算力）
• 硬隔离：运行时强制执行显存和算力限制，超限即失败而非占用邻居资源
• 异构设备管理：统一管理 NVIDIA GPU、华为昇腾 NPU、寒武纪 MLU、海光 DCU、天数智芯 GPU、摩尔线程 GPU、沐曦 GPU
• 零代码修改：应用无需改动，容器内只看到分配的资源
• 典型效果：GPU 利用率从 30-40% 提升到 70-90%，基础设施成本降低 30-60%

生产用户：蔚来（600 GPU/80 节点自动驾驶）、贝壳（GPU 利用率提升 3 倍）、SNOW（A100 训练推理混部）

工作原理 #

四大组件：

Pod 提交 → MutatingWebhook (注入注解) → Scheduler Extender (选 GPU)
           → Device Plugin (挂载 GPU) → HAMi-core (运行时隔离)

1. MutatingWebhook：拦截 Pod 创建，注入 HAMi 特有资源注解
2. Scheduler Extender：作为 kube-scheduler 或 volcano-scheduler 的扩展，做拓扑感知的 binpack/spread 调度
3. Device Plugins（按厂商）：上报扩展资源 nvidia.com/gpu、nvidia.com/gpumem、nvidia.com/gpucores
4. HAMi-core（libvgpu.so，C 编写）：Hook CUDA Driver API 层，在容器内强制执行显存和 SM 限制

两种隔离模式：

• HAMi-core（软件）：适用所有 GPU 类型，VCUDA 基础的算力和显存控制
• Dynamic MIG（硬件）：仅适用 Ampere+ GPU，NVIDIA MIG 硬件分区

K8s 集成方式（v2.8.0）：

• 传统 Device Plugin 模式
• DRA（Device Resource Assignment）：K8s 下一代设备资源标准
• CDI（Container Device Interface）：更标准的设备注入

使用方法 #

# 安装
kubectl label nodes {nodeid} gpu=on
helm repo add hami-charts https://project-hami.github.io/HAMi/
helm install hami hami-charts/hami -n kube-system

# Pod 示例：申请 1 GPU，3GB 显存，50% 算力
apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  containers:
    - name: cuda-container
      image: nvidia/cuda:11.8.0-base-ubuntu22.04
      command: ["sleep", "infinity"]
      resources:
        limits:
          nvidia.com/gpu: 1
          nvidia.com/gpumem: 3000     # 3GB 显存
          nvidia.com/gpucores: 50     # 50% 算力

# 与 Volcano 集成时使用 volcano 前缀
resources:
  limits:
    volcano.sh/vgpu-number: 2
    volcano.sh/vgpu-memory: 3000
    volcano.sh/vgpu-cores: 50

局限性 #

• 不支持 KubeVirt/Kata Containers：依赖直接 GPU 挂载，与虚拟化隔离方案不兼容
• 不能合并多个 vGPU：同一物理 GPU 上只能分配 1 个 vGPU 给单个 Pod
• 非 NVIDIA 厂商多卡拆分限制：昇腾、海光等厂商申请多设备时不支持拆分
• 必须预知显存需求：显存需在创建 Pod 时指定，过少 OOM，过多浪费
• 与 NVIDIA 官方 Device Plugin 冲突：使用相同资源名 nvidia.com/gpu，不能共存
• GPU 节点必须标注 gpu=on
• 海外采用度有限：项目起源于中国，国内采用强于国际
• CUDA 版本兼容性：Hook CUDA Driver API，版本覆盖仍在扩展

与 NVIDIA 方案对比 #

3. Ray / KubeRay — 分布式 AI 计算框架 #

📦 GitHub | ⭐ ~42,400 | 🏷️ PyTorch Foundation (2025-10)

使用场景 #

Ray 定位为 AI 工作负载的统一计算引擎：

• ML 训练：分布式多节点深度学习训练（PyTorch、TensorFlow、XGBoost），LLM 预训练和微调（OpenAI 曾用 Ray 协调 ChatGPT 训练）
• 模型服务：实时推理（Ray Serve）、LLM 服务（前缀感知路由降低 60% TTFT）、vLLM 集成
• 数据处理：多模态数据处理、异构 CPU+GPU 流水线批推理
• 超参调优：大规模并行超参搜索（Ray Tune）
• 强化学习：生产级分布式 RL（RLlib）

企业用户：OpenAI、Uber、Shopify、Snowflake、Robin Hood、Google、Meta、Microsoft、NVIDIA、Cursor

商业化支持：Anyscale（融资 ~$260M，估值 $1B 独角兽）

工作原理 #

三层架构：

Layer 3: Ray Clusters     → Head Node + Worker Nodes + Autoscaler
Layer 2: Ray AI Libraries  → Ray Train / Serve / Data / Tune / RLlib
Layer 1: Ray Core          → Tasks (@ray.remote) + Actors + Objects

• Ray Core：微秒级任务调度（1.8M+ tasks/s）、两级层次化调度器、Global Control Store (GCS)、内存对象存储（零拷贝共享）
• Ray AI Libraries：
  • Ray Data：Apache Arrow 基础的可扩展数据集处理
  • Ray Train：分布式训练 + 容错（集成 PyTorch、DeepSpeed、HuggingFace）
  • Ray Serve：生产级模型服务，自动扩缩、微批次、部署级 Actor
  • Ray Tune：可扩展超参优化
  • Ray RLlib：分布式强化学习

KubeRay（K8s Operator）：

• CRDs：RayCluster、RayJob、RayService、RayCronJob
• 自动扩缩、Kueue 集成、GCS 容错、Token 认证

使用方法 #

# 安装
pip install "ray[serve]"   # 或 ray[train]、ray[data]、ray[tune]

# 远程任务
@ray.remote
def process_data(item):
    return result

futures = [process_data.remote(item) for item in data]
results = ray.get(futures)

# Actor（有状态工作者）
@ray.remote
class ModelWorker:
    def __init__(self, model_path):
        self.model = load_model(model_path)
    def predict(self, data):
        return self.model.predict(data)

# 分布式训练
from ray.train.torch import TorchTrainer
trainer = TorchTrainer(
    train_loop_per_worker=train_func,
    scaling_config=ScalingConfig(num_workers=4, use_gpu=True),
)
result = trainer.fit()

# 模型服务
from ray import serve
@serve.deployment(num_replicas=3, ray_actor_options={"num_gpus": 1})
class ModelDeployment:
    async def __call__(self, request):
        return self.model.predict(await request.json())

# KubeRay 安装
helm repo add kuberay https://ray-project.github.io/kuberay-helm/
helm install kuberay-operator kuberay/kuberay-operator --version 1.6.0

局限性 #

• 复杂度高：学习曲线陡峭，调试分布式应用困难
• Head Node 单点协调：故障时集群暂停（GCS 容错可缓解但增加复杂性）
• 对象存储内存需精心配置：磁盘溢出严重影响性能
• 数据处理能力有限：不支持 Join 和复杂 SQL，非完整 ETL 引擎
• 运营复杂：生产部署需精心管理集群、监控和可观测性

与替代方案对比 #

4. LeaderWorkerSet (LWS) — 多节点 LLM 推理编排 #

📦 GitHub | ⭐ ~694 | 🏷️ K8s SIGs 子项目

使用场景 #

LWS 填补了一个特定空白：管理 Leader-Worker Pod 组用于分布式 LLM 推理。

• 模型分片跨多节点多设备（如 vLLM Tensor Parallelism TP=4/8）
• Leader Pod 运行 API Server/Scheduler，Worker Pods 持有模型分片
• 比 StatefulSet 更适合 LLM 推理场景（支持双模板、拓扑感知、全或无重启）

采用者：AWS EKS、Google GKE（DeepSeek-R1 671B、Llama 3.1 405B）、NVIDIA NIM、Red Hat OpenShift、DaoCloud

工作原理 #

核心概念：每个 LWS 副本由 1 个 Leader Pod + N 个 Worker Pod 组成

用户请求 → Gateway/Ingress → Leader Pod (vLLM API Server)
                                   |
                              Worker Pod 1 (GPU 模型分片 1)
                              Worker Pod 2 (GPU 模型分片 2)
                              Worker Pod N (GPU 模型分片 N)

关键特性：

• 双模板：Leader 和 Worker 使用独立 PodTemplateSpec
• 拓扑感知放置：exclusive-topology 注解确保同组 Pod 落在同一拓扑域（如同机架）
• SubGroup：组内逻辑子分区（用于 disaggregated serving：一个子组 prefill，另一个 decode）
• 全或无重启：一个 Pod 失败时整组重启（Tensor Parallelism 场景必需）
• Gang Scheduling（Alpha）：确保整组同时调度
• HPA 集成：动态扩缩副本组数

使用方法 #

# 安装
helm install lws oci://registry.k8s.io/lws/charts/lws \
  --version=0.8.0 --namespace lws-system --create-namespace --wait

# vLLM 多节点推理示例
apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
  name: vllm-serving
  annotations:
    leaderworkerset.sigs.k8s.io/exclusive-topology: rack
spec:
  replicas: 1
  startupPolicy: LeaderReady
  leaderWorkerTemplate:
    size: 4  # 1 leader + 3 workers (TP=4)
    leaderTemplate:
      spec:
        containers:
          - name: vllm-leader
            image: vllm/vllm-openai:latest
            args: ["--tensor-parallel-size", "4"]
            resources:
              limits:
                nvidia.com/gpu: "1"
    workerTemplate:
      spec:
        containers:
          - name: vllm-worker
            image: vllm/vllm-openai:latest
            resources:
              limits:
                nvidia.com/gpu: "1"

集成框架：vLLM、SGLang、TensorRT-LLM、NVIDIA NIM

局限性 #

• API 尚不成熟：Gang Scheduling 仍为 Alpha，API 快速演进中
• 无内置 Worker 自动扩缩：HPA 仅扩缩副本组数，无法独立扩缩 Worker
• 每组仅一个 Leader：不支持多 Leader 或无 Leader 拓扑
• 无内置负载均衡：需在 LWS 之上部署 Gateway/Ingress
• 生态成熟度较低：集成和社区工具少于 StatefulSet/Deployment

与替代方案对比 #

5. Kueue — K8s 原生作业队列管理 #

📦 GitHub | ⭐ ~2,500 | 🏷️ K8s SIGs 子项目

使用场景 #

Kueue 是 Google 主导的 作业级准入控制器，解决共享集群中"作业何时启动、何时抢占"的问题：

• 批处理：K8s Job 队列管理、优先级和资源管理
• AI/ML 训练：PyTorchJob、TFJob、MPIJob、RayJob
• 多租户：团队共享 GPU/CPU 池的公平调度
• 多集群分发：MultiKueue 在集群间调度作业

生产用户：Google Cloud、Red Hat、IBM Research、Shopee、Wayve

工作原理 #

设计哲学：不替代任何 K8s 组件，在标准栈之上添加准入层

Job 提交 (suspend: true) → Kueue 拦截 → 创建 Workload → ClusterQueue 评估
    ↓ 有配额                    ↓ 无配额
  Unsuspend Job               等待队列/触发抢占
    ↓
  kube-scheduler 调度 Pod

核心资源：

• ClusterQueue（集群级）：定义配额、队列策略、共享策略
• LocalQueue（命名空间级）：绑定 Workload 到 ClusterQueue
• ResourceFlavor：不同类别计算资源（架构/价格/可用性）
• Cohort：分组 ClusterQueue 实现资源共享和公平调度
• AdmissionCheck：外部组件影响是否准入

高级功能：

• MultiKueue：跨集群作业分发
• TAS（拓扑感知调度）：优化 Pod 间通信
• Partial Admission：按可用配额减少并行度运行
• Dynamic Reclaim：Pod 完成后即释放配额

使用方法 #

# 安装
kubectl apply --server-side -f https://github.com/kubernetes-sigs/kueue/releases/download/v0.17.2/manifests.yaml

# ClusterQueue 定义
apiVersion: kueue.x-k8s.io/v1beta2
kind: ClusterQueue
metadata:
  name: cluster-queue
spec:
  cohort: "default-cohort"
  resourceGroups:
    - coveredResources: ["cpu", "memory", "nvidia.com/gpu"]
      flavors:
        - name: default-flavor
          resources:
            - name: nvidia.com/gpu
              nominalQuota: 8
---
# LocalQueue 定义
apiVersion: kueue.x-k8s.io/v1beta2
kind: LocalQueue
metadata:
  namespace: default
  name: user-queue
spec:
  clusterQueue: cluster-queue
---
# 提交 Job
apiVersion: batch/v1
kind: Job
metadata:
  labels:
    kueue.x-k8s.io/queue-name: user-queue  # 关键标签
spec:
  suspend: true  # 关键：Kueue 通过切换此字段控制准入
  template:
    spec:
      containers:
        - name: worker
          resources:
            requests:
              nvidia.com/gpu: 1

局限性 #

• 不自行调度 Pod：完全依赖 kube-scheduler 放置
• 不自动扩缩：需配合 cluster-autoscaler + ProvisioningRequest
• 功能在不同 Workload 类型间不一致：Dynamic Reclaim 仅支持部分类型，Partial Admission 仅限标准 K8s Job
• API 仍为 v1beta2：尚未毕业到 v1（2026 路线图目标）

Kueue vs Volcano 深度对比 #

选择建议：

• 选 Kueue：轻量接入、使用原生 K8s API、需要多集群分发、混合批处理和 Serving
• 选 Volcano：需要原生 Gang Scheduling、重度 AI/ML/HPC 工作负载、需要深度框架集成

6. KServe — 标准化模型服务平台 #

📦 GitHub | ⭐ ~5,300 | 🏷️ CNCF Incubating

使用场景 #

KServe 提供标准化模型推理平台，同时支持生成式（LLM）和预测性（传统 ML）模型：

• 多框架支持：TensorFlow、PyTorch、XGBoost、ONNX、HuggingFace、vLLM
• Serverless 特性：Scale-to-zero（基于 Knative）、请求驱动自动扩缩
• Canary 发布：流量分割、A/B 测试
• InferenceGraph：模型集成/流水线
• ModelMesh：高密度多模型服务

局限性 #

• Knative 依赖增加运维复杂度（完整 Serverless 功能需要 Knative + Istio）
• 多层抽象（Knative + Istio + KServe）导致调试困难
• 无 Knative 安装时缺少 Canary 和 Scale-to-zero

7. 其他重要项目 #

vLLM — LLM 推理引擎之王 #

• ⭐ ~79,400 | 当前最流行的 LLM 服务引擎
• PagedAttention 高效内存管理、连续批处理、Tensor Parallelism
• 与 KServe、Triton、Seldon、Gateway API Inference Extension 集成
• 支持 GPU 和 TPU

NVIDIA Triton Inference Server #

• ⭐ ~10,600 | NVIDIA 生产推理服务器
• 多框架支持（TensorRT、TF、PyTorch、ONNX、vLLM）
• 并发模型执行、动态批处理、模型集成
• 有 vLLM 后端用于优化 LLM 服务

NVIDIA GPU Operator #

• ⭐ ~2,600 | 自动化 GPU 软件栈全生命周期管理
• 驱动、Container Toolkit、Device Plugin、DCGM、MIG Manager 等
• 与 HAMi 互补：GPU Operator 管硬件/驱动，HAMi 管智能共享和调度

Seldon Core #

• ⭐ ~4,700 | BSL 许可（非完全开源）
• 数据驱动流水线（Kafka）、模型漂移检测、多模型服务
• KServe 的直接竞争者，但许可证不同

SGLang #

• ⭐ ~20,000+ | 快速增长的 LLM 推理引擎（vLLM 替代品）
• 高性能 serving runtime，RadixAttention 技术

Gateway API Inference Extension #

• K8s SIGs 项目 | LLM 感知的网关层流量路由
• 与 vLLM 深度集成

Kthena（Volcano 生态） #

• 2026-01 发布 | K8s 原生 LLM 推理路由和编排层
• 面向生产级大规模 LLM serving

四、选型决策矩阵 #

按场景选型 #

按团队能力选型 #

五、发展趋势观察 #

1. LLM 推理成为核心驱动力：vLLM（79K⭐）、LeaderWorkerSet、Gateway API Inference Extension 的兴起都围绕 LLM serving
2. DRA (Dynamic Resource Allocation) 将成标准：HAMi v2.8.0、Kueue v0.17 都在拥抱 DRA
3. Volcano vs Kueue 格局形成：Volcano 更成熟功能更全（Gang Scheduling 原生支持），Kueue 更轻量更 K8s 原生
4. GPU 共享从"软"走向"硬"：HAMi 的硬隔离 > Time-Slicing/MPS 的软隔离
5. 拓扑感知成为标配：Volcano HyperNode、Kueue TAS、LWS exclusive-topology 都强调拓扑感知
6. Ray 生态持续扩张：PyTorch Foundation 成员、OpenAI/Google/Meta 采用、Anyscale $1B 估值
7. 多厂商异构加速器：HAMi 支持 7+ 厂商，中国厂商芯片生态推动
8. AI Agent 调度新方向：Volcano Agent Scheduler、AgentCube 关注 Agent 工作负载

📅 本文档将持续更新，跟踪各项目最新进展。