1.4 CNCF AI 生态全景与本书地图

1.4 CNCF AI 生态全景与本书地图

云原生 AI 的开源生态是一片茂密的森林——Kubeflow、Ray、vLLM、KServe、Kueue、Volcano、Feast、MLflow……项目动辄上百。本书要做的事，是给这片森林画一张清晰的「四层地图」，让你随时知道自己在哪、要去哪。

1.4.1 生态全景：四层架构与项目谱系

云原生 AI 的开源生态可以按本书的四层架构来归类。这种归类方式不是唯一的，但最贴合工程视角——因为每一层解决的是 AI 生产流程中一个独立的问题域。

💡 判读：CNCF 维护着一张「云原生景观全景图」（CNCF Landscape），收录了上千个项目。可参考该全景图获得完整生态概览，但实际工程选型时，按本书四层架构归类会更清晰。

下表是主流项目的四层归类与本书章节定位：

1.4.2 关键项目的角色与定位

光看分类还不够，要理解这些项目之间「谁替代谁、谁配合谁」的关系。下面按几个常见困惑做辨析。

调度层：Volcano、Kueue、YuniKorn 三选一？

这三个都是批处理/作业调度器，定位相近但来源不同：

• Volcano：源于华为，CNCF 孵化项目。强项是 Gang Scheduling（成组调度），适合分布式训练「要么全调度成功、要么全不调度」的需求。
• Kueue：Kubernetes SIG 官方项目。强项是与原生 Job API 深度集成，配额与排队模型清晰，是 K8s 官方力推的方向。
• YuniKorn：源于 Apache，强项是大数据与流式作业调度，适合 Spark/Flink 场景。

💡 选型经验：纯 AI 训练集群首选 Kueue（官方、轻量、路线清晰）；混部大数据与 AI 的集群可考虑 Volcano；以 Spark/Flink 为主的场景考虑 YuniKorn。第 3 章会详细对比。

流水线层：Kubeflow Pipelines vs Argo Workflows

两者都是 DAG 编排引擎，但定位不同：

• Kubeflow Pipelines（KFP）：专为 ML 设计，与 ML 实验跟踪、模型注册深度集成，组件以 ML 为一等公民。
• Argo Workflows：通用工作流引擎，更底层更灵活，KFP 早期版本就是构建在 Argo 之上。KFP v2 已迁移到独立的引擎后端。

简言之，做 ML 流水线选 KFP，做通用 CI/CD 工作流选 Argo。第 5 章会详述。

训练层：Training Operator vs Ray Train

两者都能在 K8s 上跑分布式训练，但哲学不同：

• Training Operator：K8s 原生 CRD 范式（PyTorchJob、MPIJob、DeepSpeedJob），声明式、与 K8s 深度融合，适合「K8s 优先」的团队。
• Ray Train：基于 Ray 的 Actor 模型，编程式 API，更灵活、跨语言，适合「Python 优先」、需要灵活调度 CPU/GPU/异构资源的团队。

第 5 章会给出详细的选型矩阵。

推理层：KServe、Triton、vLLM、TGI 怎么选？

这是工程界最高频的困惑。一句话概括：

• KServe：是推理服务的标准与框架，定义了 InferenceService CRD，后端可以接 vLLM、Triton 等。适合「我要一个 K8s 原生的推理服务抽象」。
• Triton：是通用多框架推理服务器，能跑 PyTorch、TensorFlow、ONNX、TensorRT 等多种格式，适合「我有一个传统模型 zoo」。
• vLLM：是 LLM 专用推理引擎，PagedAttention 的发明者，适合「我要跑大语言模型」。
• TGI：Hugging Face 的 LLM 推理引擎，与 HF 生态深度集成。

实际生产中常见组合是「KServe + vLLM」——KServe 做服务抽象与流量管理，vLLM 做底层推理引擎。第 6 章会深入剖析。

1.4.3 用一张图把生态与本书对应起来

下面这张图把四层架构、典型项目、本书章节三者对齐，是全书最重要的一张导航图：

1.4.4 本书阅读地图：按角色定路径

不同角色的读者关心不同的层。把第 1 章 README 中提到的五条阅读路径，再结合生态项目做一次聚焦：

⚠️ 提醒：本书不追求把每个项目都讲到 API 细节，而是讲清「这个项目解决什么问题、与其他项目什么关系、在云原生 AI 架构中处于什么位置」。具体的安装配置与 API 用法，建议结合各项目官方文档学习。

1.4.5 生态演进的几个趋势

最后，展望云原生 AI 生态的几个明显趋势，帮助读者判断未来 1-2 年的技术方向：

1. 官方化：Kubernetes SIG 持续吸纳原本由第三方承担的能力（如 Kueue 接管作业排队、Device Manager 接管 GPU），开源生态正在向「官方标准 + 周边工具」收敛。
2. LLM 专用化：vLLM、SGLang、TensorRT-LLM 等 LLM 推理引擎层出不穷，推理优化成为最活跃的赛道。
3. ** disaggregation（解耦）**：Prefill/Decode 分离、调度与执行分离、训练与推理混部，AI 基础设施正在向更细粒度的解耦演进。
4. 绿色与成本治理：随着大模型训练与推理成本居高不下，FinOps（AI 财务运营）与能效优化成为新议题。

这些趋势会在第 7-8 章的展望部分详细讨论。

本节小结

• 云原生 AI 开源生态可按四层架构归类：调度底座（K8s/Device Plugin/Volcano/Kueue）、生产流水线（Kubeflow/MLflow/Feast）、高效交付（KServe/Triton/vLLM）、稳定运行（Prometheus/KEDA）。
• 同层项目之间常有「替代或配合」关系：Volcano/Kueue/YuniKorn 三选一、KFP/Argo 按场景、Training Operator/Ray Train 按团队偏好、KServe/Triton/vLLM/TGI 按「标准 vs 引擎」分层组合。
• 「KServe + vLLM」是当前 LLM 推理的主流生产组合——KServe 做服务抽象，vLLM 做推理引擎。
• 不同角色应按本书五条阅读路径定方向，避免陷入「逐个项目啃文档」的低效学习。
• 生态演进的四大趋势：官方化、LLM 专用化、解耦化、绿色与成本治理，是判断未来方向的指南针。

至此第 1 章完结。理解了传统痛点、云原生 AI 的五大特性、MLOps 到 LLMOps 的演进以及完整的开源生态地图后，第 2 章将正式进入四层架构的最底层——Kubernetes 基础设施与 GPU 调度，讲清 K8s 如何承载 AI 负载。