Cloud Native AI：如何在雲原生環境中建構 AI/ML 工作流程【2025】

AI/ML 專案最常見的問題不是模型不夠好，而是「模型上不了線」。資料科學家在 Jupyter Notebook 裡訓練出來的模型，要變成生產系統中穩定運行的服務，中間的鴻溝很大。

Cloud Native 的理念可以幫助解決這個問題。這篇文章會介紹如何在雲原生環境中建構完整的 AI/ML 工作流程，包括 MLOps 實踐、Kubeflow 平台、GPU 資源管理，以及模型部署策略。

---

AI/ML 與 Cloud Native 的結合

為什麼 AI 需要 Cloud Native？

傳統的 AI/ML 開發模式有幾個痛點：

1. 環境不一致

資料科學家的筆電環境和生產環境差異大。模型在本地可以跑，部署到伺服器就出問題。

2. 手動流程太多

資料處理、模型訓練、評估、部署，每個步驟都需要手動執行。容易出錯，無法重現。

3. 資源管理困難

GPU 很貴，但使用率往往很低。沒有好的調度機制，資源浪費嚴重。

4. 模型版本混亂

哪個模型在生產？用什麼資料訓練的？沒有追蹤，出問題時無法回溯。

5. 擴展困難

推論服務需要根據流量自動擴展，傳統部署方式做不到。

AI 工作流程的挑戰

一個完整的 ML 專案包含：

資料收集 → 資料處理 → 特徵工程 → 模型訓練 → 模型評估 → 模型部署 → 監控回饋
    ↑                                                              │
    └──────────────────────────────────────────────────────────────┘
                              持續改進

每個步驟都有挑戰：

步驟	挑戰
資料處理	大量資料、分散式處理
模型訓練	GPU 資源調度、長時間運行
模型評估	自動化測試、版本比較
模型部署	零停機更新、A/B 測試
監控	模型效能追蹤、資料漂移偵測

Cloud Native 如何解決這些挑戰

挑戰	Cloud Native 解法
環境不一致	容器化，確保一致性
手動流程	工作流程自動化（Argo Workflows）
資源管理	K8s 調度 + GPU 管理
版本管理	Git + Model Registry
擴展	K8s HPA + KServe

想了解 Cloud Native 完整概念？請參考 Cloud Native 完整指南。

---

MLOps 在 Cloud Native 中的實踐

什麼是 MLOps？

MLOps（Machine Learning Operations） 是把 DevOps 理念應用到機器學習的實踐。目標是讓 ML 模型的開發、部署、維運變得自動化、可重現、可追蹤。

MLOps 的核心理念：

• 自動化：減少手動步驟
• 版本控制：程式碼、資料、模型都要追蹤
• 可重現性：任何人都能重現實驗結果
• 持續整合/部署：模型更新可以快速、安全地部署
• 監控：持續追蹤模型效能

MLOps 核心流程

┌─────────────────────────────────────────────────────────────────┐
│  資料層                                                         │
│  └─ 資料版本控制（DVC）→ 資料處理 → 特徵儲存（Feature Store）  │
└─────────────────────────────────────────────────────────────────┘
                                │
┌───────────────────────────────▼─────────────────────────────────┐
│  訓練層                                                         │
│  └─ 實驗追蹤（MLflow）→ 模型訓練 → 模型評估 → Model Registry   │
└─────────────────────────────────────────────────────────────────┘
                                │
┌───────────────────────────────▼─────────────────────────────────┐
│  部署層                                                         │
│  └─ 模型打包 → 模型部署（KServe）→ A/B 測試 → 生產服務        │
└─────────────────────────────────────────────────────────────────┘
                                │
┌───────────────────────────────▼─────────────────────────────────┐
│  監控層                                                         │
│  └─ 效能監控 → 資料漂移偵測 → 回饋迴圈                         │
└─────────────────────────────────────────────────────────────────┘

MLOps vs DevOps

面向	DevOps	MLOps
版本控制	程式碼	程式碼 + 資料 + 模型
測試	單元測試、整合測試	+ 模型效能測試
部署	應用程式	應用程式 + 模型
監控	系統指標	+ 模型效能指標
持續性	CI/CD	CI/CD + CT（Continuous Training）

關鍵差異： MLOps 需要處理資料版本控制和模型效能監控，這是傳統 DevOps 沒有的。

---

Kubeflow：Kubernetes 上的 ML 平台

Kubeflow 介紹

Kubeflow 是 Google 發起的開源專案，為 Kubernetes 提供完整的機器學習平台。

設計理念：

• 可移植：任何 K8s 叢集都能運行
• 可擴展：支援自訂元件
• 可組合：只用需要的元件

發展歷程：

• 2017：Google 開始開發
• 2018：正式發布
• 2019：成為 CNCF 專案
• 2020-現在：持續演進

核心元件

1. Kubeflow Pipelines

把 ML 工作流程定義為可重現的 Pipeline：

from kfp import dsl

@dsl.component
def train_model(data_path: str) -> str:
    # 訓練邏輯
    return model_path

@dsl.component
def evaluate_model(model_path: str) -> float:
    # 評估邏輯
    return accuracy

@dsl.pipeline(name='ml-pipeline')
def ml_pipeline(data_path: str):
    train_task = train_model(data_path=data_path)
    evaluate_task = evaluate_model(model_path=train_task.output)

2. Kubeflow Notebooks

在 K8s 上運行 Jupyter Notebook：

apiVersion: kubeflow.org/v1
kind: Notebook
metadata:
  name: my-notebook
spec:
  template:
    spec:
      containers:
      - name: notebook
        image: kubeflownotebookswg/jupyter-scipy:v1.7.0
        resources:
          limits:
            nvidia.com/gpu: 1

3. Katib（超參數調校）

自動搜尋最佳超參數：

apiVersion: kubeflow.org/v1beta1
kind: Experiment
metadata:
  name: random-search
spec:
  objective:
    type: maximize
    goal: 0.99
    objectiveMetricName: accuracy
  algorithm:
    algorithmName: random
  parameters:
    - name: learning_rate
      parameterType: double
      feasibleSpace:
        min: "0.001"
        max: "0.1"
    - name: batch_size
      parameterType: int
      feasibleSpace:
        min: "32"
        max: "128"

4. Training Operators

分散式訓練支援：

• TFJob（TensorFlow）
• PyTorchJob
• MPIJob
• XGBoostJob

Kubeflow Pipelines

Kubeflow Pipelines 是最核心的元件，讓你可以：

• 定義可重現的 ML 工作流程
• 追蹤每次執行的結果
• 比較不同實驗
• 版本控制 Pipeline

Pipeline 執行流程：

Pipeline 定義（Python DSL）
          │
          ▼
    編譯成 YAML
          │
          ▼
    提交到 K8s
          │
          ▼
    Argo Workflows 執行
          │
          ▼
    結果儲存到 MySQL/MinIO

KServe 模型部署

KServe（原 KFServing）是 Kubeflow 的模型服務元件，提供：

• Serverless 推論服務
• 自動擴展（包括縮到 0）
• 多框架支援（TensorFlow、PyTorch、XGBoost 等）
• A/B 測試和金絲雀部署

部署範例：

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: sklearn-iris
spec:
  predictor:
    sklearn:
      storageUri: gs://my-bucket/sklearn/iris
      resources:
        limits:
          cpu: "1"
          memory: "2Gi"

自動擴展：

spec:
  predictor:
    minReplicas: 0  # 可以縮到 0
    maxReplicas: 10
    scaleMetric: concurrency
    scaleTarget: 10  # 每個 Pod 處理 10 個併發請求

了解更多 Kubernetes 概念？請參考 Cloud Native 技術棧入門。

想在企業導入 AI？從 Kubeflow 到自建 MLOps，讓有經驗的人幫你避坑。預約 AI 導入諮詢

---

GPU 資源管理

K8s GPU 支援

Kubernetes 透過 Device Plugin 支援 GPU：

NVIDIA Device Plugin：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nvidia-device-plugin-daemonset
spec:
  selector:
    matchLabels:
      name: nvidia-device-plugin-ds
  template:
    spec:
      containers:
      - name: nvidia-device-plugin-ctr
        image: nvcr.io/nvidia/k8s-device-plugin:v0.14.0

Pod 使用 GPU：

apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  containers:
  - name: cuda-container
    image: nvcr.io/nvidia/cuda:12.2.0-runtime-ubuntu22.04
    resources:
      limits:
        nvidia.com/gpu: 1  # 使用 1 個 GPU

GPU 調度策略

1. 獨佔 GPU

一個 Pod 使用整個 GPU，最簡單但效率低。

2. GPU 分時共享（Time-Slicing）

多個 Pod 共享 GPU，輪流使用：

# NVIDIA GPU Operator 設定
apiVersion: v1
kind: ConfigMap
metadata:
  name: time-slicing-config
data:
  any: |
    version: v1
    sharing:
      timeSlicing:
        replicas: 4  # 每個 GPU 可被 4 個 Pod 共享

3. MIG（Multi-Instance GPU）

A100/H100 支援硬體層級的 GPU 分割：

分割模式	記憶體	適用場景
1g.5gb	5 GB	小型推論
2g.10gb	10 GB	中型訓練
7g.40gb	40 GB	大型訓練

成本優化

GPU 資源昂貴，如何優化成本？

1. 使用 Spot/Preemptible Instances

訓練工作可以接受中斷，用 Spot 實例省 60-90%：

apiVersion: v1
kind: Pod
metadata:
  name: training-job
spec:
  tolerations:
  - key: "cloud.google.com/gke-spot"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"
  nodeSelector:
    cloud.google.com/gke-spot: "true"

2. 自動擴展

根據佇列深度自動調整 GPU 節點：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: gpu-worker
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: gpu-worker
  minReplicas: 0
  maxReplicas: 10
  metrics:
  - type: External
    external:
      metric:
        name: queue_depth
      target:
        type: Value
        value: 5

3. 推論服務縮到 0

用 KServe 的 Serverless 功能，沒有流量時不佔用資源：

spec:
  predictor:
    minReplicas: 0
    scaleDownDelay: 600s  # 10 分鐘後縮到 0

---

AI 模型部署與擴展

部署模式

1. 批次推論

適合大量資料的離線處理：

apiVersion: batch/v1
kind: Job
metadata:
  name: batch-inference
spec:
  template:
    spec:
      containers:
      - name: inference
        image: my-model:v1
        command: ["python", "batch_predict.py"]
        volumeMounts:
        - name: data
          mountPath: /data

2. 即時推論（Serving）

適合線上服務：

• KServe：Serverless、多框架支援
• Triton Inference Server：高效能、多模型
• TensorFlow Serving：TensorFlow 專用

3. 邊緣推論

適合延遲敏感或離線場景，模型部署到邊緣設備。

模型版本管理

Model Registry 追蹤模型版本：

import mlflow

# 記錄模型
mlflow.sklearn.log_model(model, "model")

# 註冊到 Registry
mlflow.register_model(
    "runs:/abc123/model",
    "my-model"
)

# 標記版本
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
    name="my-model",
    version=1,
    stage="Production"
)

A/B 測試和金絲雀部署

KServe 支援流量分割：

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: my-model
spec:
  predictor:
    canaryTrafficPercent: 20
    model:
      modelFormat:
        name: sklearn
      storageUri: gs://my-bucket/model-v2
  transformer:
    containers:
    - name: transformer
      image: my-transformer:v2

20% 流量導向新版本，驗證後再全量切換。

---

Cloud Native AI 工具生態

CNCF AI/ML 專案

專案	類型	用途
Kubeflow	平台	完整 ML 平台
Argo Workflows	工作流程	DAG 執行引擎
KServe	部署	模型服務
KEDA	擴展	事件驅動擴展

了解更多 CNCF 專案？請參考 CNCF 與 Landscape 導覽。

其他重要工具

實驗追蹤：

• MLflow
• Weights & Biases
• Neptune

資料版本控制：

• DVC（Data Version Control）
• LakeFS

特徵儲存：

• Feast
• Tecton

監控：

• Evidently
• WhyLabs

---

FAQ

Q1: Kubeflow 適合小團隊嗎？

Kubeflow 是完整的平台，對小團隊可能太重。可以先從 KServe + Argo Workflows 開始，需要更多功能再逐步加入。

Q2: 不用 GPU 可以跑 AI 嗎？

可以。推論可以跑在 CPU 上，效能夠用的話不一定需要 GPU。訓練通常需要 GPU，但小模型也可以用 CPU。

Q3: MLOps 和傳統軟體開發流程有什麼差異？

最大差異是資料版本控制和模型監控。ML 專案需要追蹤資料版本，而且模型效能會隨時間衰退，需要持續監控和更新。

Q4: 如何處理模型效能衰退？

監控模型指標（準確度、F1 等）和資料漂移。設定告警閾值，當效能下降時觸發重新訓練。可以用 Evidently 等工具自動偵測。

Q5: 企業導入 MLOps 要從哪裡開始？

建議順序：(1) 容器化現有模型 (2) 導入模型版本控制 (3) 建立自動化 Pipeline (4) 加入監控。不需要一步到位。

---

下一步

Cloud Native AI 讓機器學習專案更容易管理和擴展。建議：

1. 先容器化現有的 ML 工作流程
2. 嘗試 KServe 部署模型服務
3. 評估 Kubeflow Pipelines 自動化工作流程
4. 建立模型監控機制

延伸閱讀：

• 回到核心概念：Cloud Native 完整指南
• 深入 Kubernetes：Cloud Native 技術棧入門
• 了解 CNCF 生態系：CNCF 與 Landscape 導覽

想在雲原生環境建構 AI 能力？預約 AI 導入諮詢，讓有經驗的專家幫你規劃最適合的 MLOps 架構。

---

參考資料

• Kubeflow Documentation
• KServe Documentation
• NVIDIA GPU Operator
• MLflow Documentation
• CNCF AI/ML Working Group