Kubeflow

1. 3 秒看懂

Kubeflow 是一個以 Kubernetes 為底座的開源機器學習平台，覆蓋從資料準備、模型訓練、超參調優、模型服務到流水線編排的完整 MLOps 生命週期。你可以把它理解為 “跑在 K8s 上的 AI 生產線管理系統”——它不解決單點演算法問題，而是解決”如何在生產環境中規模化、可復現、可治理地執行 ML 工作負載”的問題。

2. 3 分鐘產業解釋

為什麼需要 Kubeflow？

一個典型的 AI 團隊面臨的真實困境：

階段	痛點
實驗/訓練	資料科學家在本地筆記本寫好程式碼，無法直接跑到 GPU 叢集上；依賴環境不一致導致”在我機器上能跑”
超參調優	手動 grid search 效率低下，沒有統一的實驗追蹤和對比
模型服務	訓練完成後模型部署需要另一套基礎設施，與訓練環境割裂
流水線管理	多步驟流程（資料清洗→特徵工程→訓練→評估→部署）靠人工串聯，不可復現
資源排程	多團隊共享 GPU 叢集，缺乏隔離、配額和彈性伸縮

Kubeflow 的核心價值是把上述所有環節統一到 Kubernetes 生態中：利用 K8s 的容器化、宣告式 API、排程能力和資源隔離，為 ML 工作負載提供標準化執行環境。

產業定位

┌─────────────────────────────────────────────────┐
│              AI 應用層 (ChatBot / 推薦 / CV)       │
├─────────────────────────────────────────────────┤
│           ML 架構 (PyTorch / TensorFlow / JAX)    │
├─────────────────────────────────────────────────┤
│    ★ Kubeflow / MLOps 平台層 ★                    │
│  訓練編排 │ 模型服務 │ 流水線 │ 實驗管理 │ 調參    │
├─────────────────────────────────────────────────┤
│          Kubernetes 叢集 (排程/編排/資源管理)       │
├─────────────────────────────────────────────────┤
│     GPU/CPU 硬體 │ 儲存 │ 網路 │ 雲端/資料中心        │
└─────────────────────────────────────────────────┘

Kubeflow 在 MLOps 平台層 與 MLflow、Airflow、Seldon Core、Ray 等形成競爭與互補關係。其優勢在於 K8s 原生、元件解耦可插拔；劣勢在於部署和運維複雜度高，被社群批評”入門門檻過高”。

3. 15 分鐘專家深入

3.1 專案起源與演進

2017 年底：Google 內部以”如何將 TensorFlow 訓練便捷地部署到 K8s”為起點，開源 Kubeflow，最初定位為”TensorFlow on Kubernetes 的便捷工具”。
2018–2019：快速擴充套件為多架構平台，加入 PyTorch Operator、Kubeflow Pipelines（源自 Google 內部 Argo-based 流水線系統）、Katib（超參調優，其名稱源自阿拉伯語，意為“寫者”或“文書”，設計靈感主要來自 Google Vizier 等超引數最佳化系統）、KServing（模型服務）。
2020–2021：v1.0–v1.4 釋出，生態逐步穩定；社群治理從 Google 主導轉向更廣泛的 vendor-neutral 模式。
2022–2023：專案開始進入 CNCF 沙箱/孵化流程（具體狀態以 CNCF 官網為準），KServe 作為模型服務元件獨立演進，Training Operator 增加對 MPI Job（支援 Horovod 分散式訓練）和 PaddlePaddle 等支援。
2024–2025：社群持續迭代，重點方向包括：對 LLM 訓練場景的支援（如 PyTorchJob 與 DeepSpeed/FSDP 整合）、與 KServe/Knative 的更深度整合、簡化安裝體驗（Kubeflow Manifests / Charmed Kubeflow）。

⚠️ 以上版本時間線基於社群公開 changelog 與博文的大致脈絡，具體版本釋出時間請以 GitHub release notes 為準。

3.2 核心元件架構

                    ┌──────────────────────────────┐
                    │      Kubeflow Central Dashboard │
                    │      (統一 Web UI 入口)          │
                    └──────────┬───────────────────┘
                               │
       ┌───────────┬───────────┼───────────┬──────────────┐
       ▼           ▼           ▼           ▼              ▼
  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌───────────┐
  │ Notebook │ │Training │ │ Pipelines│ │  Katib   │ │  KServe /  │
  │ Servers  │ │Operator │ │          │ │(超參調優)│ │  KFServing │
  │ (Jupyter)│ │(TFJob / │ │ (Argo    │ │          │ │(模型推論   │
  │          │ │PyTorch  │ │  Workflows)│ │          │ │  服務)     │
  │          │ │Job /MPI │ │          │ │          │ │           │
  │          │ │Job etc.)│ │          │ │          │ │           │
  └─────────┘ └─────────┘ └─────────┘ └─────────┘ └───────────┘
       │           │           │           │              │
       └───────────┴───────────┴───────────┴──────────────┘
                               │
                    ┌──────────▼───────────┐
                    │   Kubernetes 叢集      │
                    │  (排程 / PVC / RBAC /  │
                    │   GPU 資源 / Networking)│
                    └──────────────────────┘

各元件詳解：

① Kubeflow Pipelines（KFP）

定位：ML 工作流編排引擎，類似 Airflow 但專為 ML 設計
核心概念：
- Pipeline：有向無環圖（DAG），由多個 Step 組成
- Step（Component）：一個容器化的執行單元，有輸入/輸出定義
- Experiment & Run：實驗管理，支援引數化執行
執行後端：基於 Argo Workflows。社群存在基於 Tekton Pipelines 的獨立發行版 KFP-Tekton，不屬於 KFP 官方內建支援。
關鍵特性：pipeline 快取（相同輸入+元件 hash 可跳過重執行）、ML Metadata 追蹤、視覺化指標對比

② Training Operator

定位：在 K8s 上宣告式管理分散式訓練作業
支援的作業型別（以社群最新文件為準）：
- TFJob：TensorFlow 分散式訓練
- PyTorchJob：PyTorch 分散式訓練（支援 DDP / FSDP 等）
- MPIJob：基於 MPI 的訓練（常用 Horovod）
- XGBoostJob、PaddleJob 等
工作原理：通過 K8s CRD（Custom Resource Definition）定義訓練作業，Operator 控制器負責建立 Pod、管理生命週期（建立、重試、清理）、協調多角色（Master/Worker/PS）的啟動順序
與 LLM 訓練的關聯：PyTorchJob 可以配合 DeepSpeed、FSDP 等架構，通過配置 Worker 數量和資源請求來排程大規模分散式訓練

③ Katib

定位：自動超引數調優 / Neural Architecture Search
支援的搜尋演算法：Grid Search、Random Search、Bayesian Optimization（基於 Gaussian Process 等）、Hyperband 等——具體支援哪些演算法以 Katib 官方文件為準
機制：通過 K8s CRD 定義 Experiment，Katib 控制器自動建立 Trial Pod 執行訓練任務，收集指標，根據搜尋策略生成下一組超參

④ KServe（原 KFServing）

定位：無伺服器模型推論平台，後從 Kubeflow 獨立成為 CNCF 孵化專案（具體 CNCF 階段以官方為準）
關鍵特性：
- 基於 Knative Serving 實現自動擴縮容（包括縮容到零 / scale-to-zero）
- 支援 InferenceService CRD 宣告式部署模型
- 內建支援常見推論執行時（Triton Inference Server、TorchServe、TFServing、自定義容器等）
- 支援模型版本管理、流量切分（金絲雀釋出）、A/B 測試
- 支援推論圖（InferenceGraph）進行請求路由

⑤ Notebook Servers

定位：在 K8s 中快速建立 Jupyter Notebook 和 JupyterLab 伺服器例項，官方預設未內建 VSCode 伺服器支援（通過自定義映象可能實現）
特性：預配置 GPU 支援、PVC 持久化儲存、自定義映象，降低資料科學家使用叢集資源的門檻

⑥ Volumes / PVC 管理

提供資料卷管理 Web UI，方便使用者建立和管理 K8s PersistentVolumeClaim

3.3 安裝與運維複雜度

Kubeflow 的一個核心痛點是 安裝複雜。一個完整的 Kubeflow 部署涉及大量元件：

每個元件通常是一組 CRD + Operator + Web UI + 相關 RBAC/ServiceAccount 配置
依賴項包括：Istio 或其他 Service Mesh（用於流量管理/鑑權）、Dex + OIDC（認證）、Knative（KServe 依賴）等
社群提供的安裝方式：
- Kubeflow Manifests：Kustomize overlay 方式，社群維護，需逐步 apply 多個 manifest
- Charmed Kubeflow（Canonical 提供）：基於 Juju 的部署方案
- 各雲端廠商託管方案：AWS（EKS + 自定義）、GCP（Vertex AI 的部分元件源於 Kubeflow）、Azure（AzureML 整合）等

實操提醒：Kubeflow 叢集版本相容性是常見問題。Kubeflow 版本與特定 K8s 版本範圍對應（如 Kubeflow 1.8 通常對應 K8s 1.26–1.28，具體以 release notes 為準），升級時需仔細核對相容矩陣。

4. 技術原理（最深）

4.1 Kubeflow Pipelines 的執行機制

使用者定義 Pipeline (Python DSL / YAML)
        │
        ▼
┌─────────────────┐     ┌───────────────────────┐
│  KFP API Server  │────▶│  資料庫 (MySQL)         │
│  (REST API)      │     │  儲存 Pipeline 定義、     │
│                  │     │  Run 狀態、ML Metadata    │
└────────┬────────┘     └───────────────────────┘
         │
         ▼  提交 Run
┌─────────────────┐
│  Argo Workflows  │
│  (執行引擎；社群   │
│   發行版支援 Tekton)│
└────────┬────────┘
         │  每個 Step = 一個 K8s Pod
         ▼
┌──────────┐  ┌──────────┐  ┌──────────┐
│  Step 1   │──│  Step 2   │──│  Step 3   │
│  Pod A    │  │  Pod B    │  │  Pod C    │
│(資料載入)  │  │(模型訓練)  │  │(模型評估)  │
└──────────┘  └──────────┘  └──────────┘

KFP v2 的關鍵設計：

輕量級元件（Lightweight Components）：用 @component 裝飾器將 Python 函式轉化為 Pipeline Step，自動生成容器映象（或使用預建置映象 + 傳入程式碼）
資料交換器制：v2 引入了型別化的 artifact 系統（Input[Dataset]、Output[Model] 等），大產物通過物件儲存（S3/GCS/MinIO）傳遞，小引數通過 Argo Workflow 的輸出引數機制（如內聯引數）傳遞
快取機制：基於元件映象 digest + 輸入引數 hash 的確定性快取

4.2 Training Operator 的 Controller 模式

// 簡化的 Reconciliation 邏輯（概念性虛擬碼）
func (r *PyTorchJobReconciler) Reconcile(ctx context.Context, req Request) {
    // 1. 獲取 PyTorchJob CR
    job := getPyTorchJob(req.Name, req.Namespace)

    // 2. 期望狀態 vs 實際狀態比較
    desiredWorkers := job.Spec.PyTorchReplicaSpecs["Worker"].Replicas  // e.g., 4
    actualWorkers := countActivePods(job, "Worker")

    // 3. 收斂：建立/刪除 Pod 以滿足期望
    if actualWorkers &lt; desiredWorkers {
        createWorkerPods(desiredWorkers - actualWorkers)
    }

    // 4. 管理 Pod 啟動順序（通常 Master 先啟動）
    // 5. 監聽 Pod 狀態，更新 Job Status（Running/Succeeded/Failed）
    // 6. 處理失敗重試（backoff / restartPolicy）
}

關鍵設計決策：

每個訓練架構有獨立的 CRD（TFJob、PyTorchJob 等）和對應的 Operator
訓練架構級通訊（如 NCCL AllReduce）由架構自身管理，Operator 只負責 基礎設施層：Pod 建立、服務發現、環境變數注入（如 MASTER_ADDR）、資源分配
分散式訓練中的通訊拓撲（如 Torchrun elastic、Horovod 的 ring-allreduce）由訓練架構 + 啟動器決定，不屬於 Operator 職責

4.3 KServe 的推論架構

                    ┌─────────────────────────┐
  HTTP Request ────▶│  Ingress / Gateway       │
                    │  (Istio IngressGateway)   │
                    └───────────┬─────────────┘
                                │
                    ┌───────────▼─────────────┐
                    │  Knative Serving          │
                    │  (自動擴縮容 / Scale-to-0)│
                    └───────────┬─────────────┘
                                │
                    ┌───────────▼─────────────┐
                    │  KServe Predictor         │
                    │  ┌──────────────────────┐│
                    │  │  Transformer (可選)    ││  ← 預處理/後處理
                    │  │  (特徵變換/Tokenize)   ││
                    │  └──────────┬───────────┘│
                    │             ▼             │
                    │  ┌──────────────────────┐│
                    │  │  Predictor (必須)      ││  ← 實際推論
                    │  │  (Triton/TorchServe/  ││
                    │  │   TFServing/自定義)    ││
                    │  └──────────────────────┘│
                    └─────────────────────────┘

資源請求模式：使用者通過 YAML 宣告 InferenceService，指定架構（runtime）、模型 URI（如 s3://bucket/model/）、資源需求（CPU/GPU/記憶體），KServe 自動處理模型拉取、容器編排、擴縮容策略。

4.4 Katib 超參調優的控制迴圈

┌────────────────┐
│ Katib Controller│
│                │
│  ┌──────────┐  │     ┌────────────────────┐
│  │ Suggestion│  │────▶│  Trial Pods (K8s)   │
│  │ Service   │  │     │  執行訓練任務         │
│  │(搜尋演算法)  │◀─│──── │  輸出 metrics        │
│  └──────────┘  │     └────────────────────┘
│                │
│  ┌──────────┐  │
│  │ Metrics   │  │     ← 從 Trial Pod 日誌/Prometheus/
│  │ Collector │  │       自定義 metrics collector 收集
│  └──────────┘  │
└────────────────┘

Suggestion Service 是獨立的 gRPC 服務，封裝搜尋演算法（BO、Hyperband 等），每次返回下一組 Trial 引數
Katib Controller 建立 Trial Pod（實際執行訓練指令碼），收集 metrics，反饋給 Suggestion Service
整個過程通過 Experiment CRD 宣告式管理

5. 技術演進史

時間	里程碑	意義
2017 Q4	Google 開源 Kubeflow 0.1	”TF on K8s” 的起點，社群熱情高漲
2018	加入 PyTorch Operator、Kubeflow Pipelines、Katib	從單一 TF 架構擴充套件為通用 ML 平台
2019	KFServing 釋出、Kubeflow Fairing（簡化部署工具）	模型服務能力補全
2020	Kubeflow 1.0 GA	標誌專案走向生產就緒（實際生產穩定性見仁見智）
2021	KFServing 更名 KServe，開始獨立發展	模型服務與訓練平台解耦
2022	Training Operator 統一（合併 TF/PyTorch/XGBoost Operator 程式碼倉庫）	降低維護複雜度
2023	Kubeflow 1.7/1.8 釋出，社群關注 LLM 訓練場景	PyTorchJob + DeepSpeed/FSDP 整合需求增長
2024	持續迭代，KServe 獨立演進為 CNCF 專案	生態進一步碎片化與專業化並存

以上為基於社群公開資訊的大致脈絡，具體版本號和日期以 GitHub release 為準。

6. 技術路線對比

維度	Kubeflow	MLflow	Airflow + 自建	雲端廠商託管平台（Vertex AI / SageMaker / AzureML）
基礎設施耦合	深度繫結 K8s	架構無關，輕量	通用	深度繫結特定雲端
訓練編排	✅ 原生（Training Operator, CRD）	❌ 不含（需外接）	✅ DAG 編排（非 ML 專用）	✅ 託管，使用者無感
Pipeline 編排	✅ KFP（專用 ML DAG）	✅ MLflow Projects（較輕）	✅ 通用 DAG	✅ 託管 Pipeline
實驗追蹤	✅（KFP metadata + Katib）	✅✅（核心優勢，功能豐富）	❌ 需自建	✅ 內建
模型註冊	有限（需配合外部方案）	✅✅（Model Registry）	❌	✅ 內建
模型服務	✅ KServe（功能強大）	✅ MLflow Serving（較簡單）	❌ 需外接	✅ 內建
超參調優	✅ Katib（原生整合）	❌ 需外接 Optuna 等	❌	✅ 內建
運維複雜度	🔴 高（元件多、升級難）	🟢 低（pip install 即可）	🟡 中	🟢 低（託管）
多租戶	✅ K8s namespace + RBAC	❌ 弱	❌ 需自建	✅ 內建
GPU 排程	✅ K8s 原生（nvidia-device-plugin）	❌ 不涉及	取決於 executor	✅ 託管
適用規模	中大型團隊/多團隊共享叢集	小→中型團隊/快速迭代	通用 ETL/ML 混合	預算充足、希望免運維

趨勢判斷：純 Kubeflow 作為自建方案的運維成本正在被質疑，社群出現向 輕量組合（如 MLflow 做實驗追蹤 + Ray/KubeRay 做分散式訓練 + KServe 做模型服務）轉型的趨勢。但 Kubeflow 作為 K8s 原生 ML 平台參考實現 的學習和參考價值依然很高。

7. 上下游

上游依賴

層級	技術/產品	關係
基礎設施	Kubernetes（1.25+，以官方相容矩陣為準）	執行時底座
GPU 基礎設施	NVIDIA GPU Operator / device plugin	GPU 資源暴露給 K8s
儲存	PVC / S3 / GCS / MinIO	Pipeline artifact 和模型儲存
Service Mesh	Istio（典型選擇）/ 原生 K8s Ingress	流量管理、鑑權
Serverless	Knative Serving	KServe 的擴縮容基礎
工作流引擎	Argo Workflows（原生）；Tekton Pipelines（社群發行版 KFP-Tekton，非官方內建）	KFP 的 DAG 執行後端
認證	Dex + OIDC Provider	多租戶認證
ML 架構	PyTorch / TensorFlow / XGBoost 等	使用者實際訓練程式碼

下游使用者/場景

使用者	典型使用場景
MLOps 工程師	搭建和維護 ML 平台，管理多團隊資源配額
資料科學家	通過 Notebook Server 開發、通過 Pipeline 復現實驗
ML 工程師	建置自動化訓練 Pipeline，部署模型服務
平台團隊	提供內部 ML PaaS（Kubeflow 作為底層）
AI 基礎設施供應商	基於 Kubeflow 二次開發商業產品（如 Arrikto 的 Kale/Rok、Canonical 的 Charmed Kubeflow）

8. 關鍵指標

指標	說明	參考量級
元件數	完整部署涉及的微服務/控制器數量	15–25+ 個 Pod（估算，含 Istio/Dex/Knative 等依賴）
最低叢集資源	空載 Kubeflow 控制面的資源開銷	CPU 數核 + 數 GB 記憶體（估算，取決於元件啟用範圍）
支援的 K8s 版本	與特定 Kubeflow 版本相容	通常支援最近 2–3 個 K8s 次版本（以 release notes 為準）
Pipeline 併發 Run 數	KFP API Server 的吞吐能力	取決於資料庫和 API Server 資源，通常數十到數百併發（估算）
訓練 Pod 啟動延遲	從 CRD 建立到 Pod Running 的時間	秒級到分鐘級（取決於映象大小、節點預熱、GPU 驅動就緒）
KServe 冷啟動	Scale-from-zero 到首次推論返回	數秒到數十秒（取決於模型大小和容器啟動時間）

9. 供需與市場資料

開源生態資料

指標	資料（以查詢時點為準，此處為大致量級）
GitHub Stars	~14k（kubeflow/kubeflow 主倉庫，估算）
Contributors	600+（估算，含所有子專案）
發行方/採用方	Google、Red Hat、Bloomberg、中國電信、阿里雲端等（來自社群公開資訊）
競品 GitHub Stars	MLflow ~19k、Airflow ~37k（同一量級參考，估算）

市場定位

MLOps 市場規模：據 Grand View Research 等行業報告，全球 MLOps 市場預計 2030 年達到數十億美元規模（具體數字以報告原文為準，此處不引用具體金額）
Kubeflow 的市場份額難以單獨量化，因為：
- 大量企業使用部分元件（如只用 KFP 或只用 KServe）
- 雲端廠商的託管 ML 平台中部分元件基於 Kubeflow 但不以此品牌出現
- GCP Vertex AI Pipelines 的底層即基於 KFP

商業化路徑

Kubeflow 本身是開源專案，商業化主要通過：

雲端廠商託管版：GCP Vertex AI、AWS（部分元件）、Azure（AzureML 整合）
ISV 增值：Arrikto（已提供企業版 Kubeflow，提供私有化安裝和安全增強）、Canonical（Charmed Kubeflow）
諮詢/服務：SRE/DevOps 公司提供 Kubeflow 部署和運維服務

10. 代表公司與資本對映

角色	公司/產品	關係說明
創始/主導	Google	專案發起方，GCP Vertex AI Pipelines 基於 KFP
主要貢獻者	Red Hat	Open Data Hub 基於 Kubeflow，RHODS 產品包含 KF 元件
商業版	Arrikto	提供企業級 Kubeflow（EKF），含安全增強和簡化安裝
商業版	Canonical	Charmed Kubeflow，Juju-based 部署方案

三步設好你的觀察臺

選 1-3 個想觀察的人或賽道

看一份樣張

設定一次異動告警

Kubeflow

Kubeflow

1. 3 秒看懂

2. 3 分鐘產業解釋

為什麼需要 Kubeflow？

產業定位

3. 15 分鐘專家深入

3.1 專案起源與演進

3.2 核心元件架構

各元件詳解：

3.3 安裝與運維複雜度

4. 技術原理（最深）

4.1 Kubeflow Pipelines 的執行機制

4.2 Training Operator 的 Controller 模式

4.3 KServe 的推論架構

4.4 Katib 超參調優的控制迴圈

5. 技術演進史

6. 技術路線對比

7. 上下游

上游依賴

下游使用者/場景

8. 關鍵指標

9. 供需與市場資料

開源生態資料

市場定位

商業化路徑

10. 代表公司與資本對映

Kubeflow

1. 3 秒看懂

2. 3 分鐘產業解釋

為什麼需要 Kubeflow？

產業定位

3. 15 分鐘專家深入

3.1 專案起源與演進

3.2 核心元件架構

各元件詳解：

3.3 安裝與運維複雜度

4. 技術原理（最深）

4.1 Kubeflow Pipelines 的執行機制

4.2 Training Operator 的 Controller 模式

4.3 KServe 的推論架構

4.4 Katib 超參調優的控制迴圈

5. 技術演進史

6. 技術路線對比

7. 上下游

上游依賴

下游使用者/場景

8. 關鍵指標

9. 供需與市場資料

開源生態資料

市場定位

商業化路徑

10. 代表公司與資本對映

相關推薦

同產業鏈 · 相關公司

相關概念