前言：從實務痛點說起

近年來幾乎每間公司都在談 AI，從自然語言處理 (NLP)、電腦視覺，到推薦系統，機器學習 (ML) 已經滲透到各種領域。然而，很多團隊在實務中都會遇到相似的問題：

• 環境難以重現：研究人員用的 Python package 版本和工程團隊不同，導致「跑不出一樣的結果」。
• 模型部署困難：訓練好的模型要怎麼從研究人員的筆電搬到雲端環境？
• 流程不一致：不同團隊的 pipeline 各自為政，難以標準化。
• 缺乏資源管理：要在多台 GPU 上跑大規模訓練，常常卡在排程混亂。

這些問題，正是 MLOps (Machine Learning Operations) 想解決的。就像 DevOps 幫助軟體工程團隊把「開發」和「運維」的鴻溝縮小，MLOps 則是把「機器學習」和「工程落地」結合起來。而 Kubeflow，就是目前最知名的 開源 MLOps 平台。

Kubeflow 是什麼？

Kubeflow 是一個建構在 Kubernetes 之上的機器學習平台，目標是：

• Portable：在任何 Kubernetes 環境都能執行，不論是本地叢集、雲端 (GCP, AWS, Azure)，甚至是混合環境。
• Scalable：支援從單機實驗到大規模分散式訓練。
• Composable：模組化設計，使用者可以只挑需要的元件，而不是一次吃下整套。

換句話說，Kubeflow 提供了一個「像 Kubernetes 對應應用程式一樣」的角色，只是這次對象是 ML workflow。

由於它是建構在 Kubernetes 上，所以 Kubeflow 的每個元件其實都是一組 Kubernetes Object，例如 Deployment、Service、Custom Resource (CRD)。舉幾個例子：

• Kubeflow Notebook 實際上會建立一個 Pod + Service 來提供 JupyterLab 的 Web 介面：

apiVersion: v1
kind: Pod
metadata:
  name: notebook-pod
  namespace: kubeflow-user-example
spec:
  containers:
  - name: notebook
    image: jupyter/tensorflow-notebook:latest
    resources:
      limits:
        cpu: "2"
        memory: "4Gi"

• 執行一個 Pipeline 的時候，背後其實是由 Argo Workflow 建立多個 Kubernetes Job：

apiVersion: batch/v1
kind: Job
metadata:
  name: pipeline-step-preprocess
  namespace: kubeflow
spec:
  template:
    spec:
      containers:
      - name: main
        image: my-ml-image:latest
        command: ["python", "preprocess.py"]
      restartPolicy: Never

• 部署模型服務時，KServe 則會建立一個 InferenceService (CRD)，並在背後產生 Deployment、Service 和 Istio Route：

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: my-model
  namespace: kubeflow
spec:
  predictor:
    sklearn:
      storageUri: "s3://my-bucket/models/sklearn/iris"

這些 YAML manifest 讓我們更清楚地看到，Kubeflow 並不是「黑盒子」，而是利用 Kubernetes 原生物件去組合出一個 MLOps 平台。

Kubeflow 能解決什麼問題？

如果把機器學習流程比喻成一條生產線，從資料收集 → 特徵工程 → 模型訓練 → 驗證 → 部署 → 監控，每個階段都可能有不同工具、不同負責人。Kubeflow 嘗試把這些環節統一到同一個平台上：

1. 統一平台
   不需要再分散使用 Jupyter Notebook、獨立的腳本和雲端部署服務，Kubeflow 提供了完整解決方案。

2. 支援多種框架
   TensorFlow、PyTorch、MXNet 等常見框架，都能整合在 Kubeflow 裡。

3. 自動化 pipeline
   訓練流程不再是「人工跑一堆 Python 腳本」，而是可以用 pipeline 描述、版本化、重複執行。

4. 模型服務化 (Model Serving)
   訓練好的模型可以透過 KFServing（後來更名為 KServe）快速部署成 REST/gRPC API。

與傳統 ML workflow 的差異

傳統上，機器學習流程常常是：

1. 資料科學家在本機 Notebook 上訓練。
2. 模型丟給工程師。
3. 工程師再想辦法包裝成 API。

這中間會出現大量溝通成本與落地障礙。而 Kubeflow 的想法是：直接在 Kubernetes 裡做端到端的 ML lifecycle，讓不同角色的人（DS/ML/DevOps）在同一個平台協作。

小結

這篇文章先幫大家釐清一個概念：

• 機器學習專案落地的困難不在「演算法」，而在「流程」與「環境管理」。
• Kubeflow 提供了一個模組化、可移植、可擴展的解決方案。
• 而且它背後其實就是一組 Kubernetes Object，讓我們可以透過 YAML manifest 清楚看到「平台是怎麼被建構出來的」。

下一篇，我會介紹 Kubeflow 的核心元件，以及一個典型的使用方式，幫助大家更具體想像它在團隊裡的角色。

參考資料：

• Kubeflow 官網 Introduction