前言

在進行 LLM 相關專案時，模型訓練只是第一步。真正的挑戰在於：

• 模型體積巨大（動輒數十 GB）
• 推理需要 GPU 資源，成本高、資源稀缺
• 模型更新與回滾風險高
• 不同版本模型需並行測試與監控

本篇目標：

• 使用 KServe / Seldon Core 部署 LLM 推理服務
• 實作 多版本部署與流量分配
• 探討 Canary Deployment 與 零停機熱更新策略

架構總覽：LLM 推理服務在 K8s 的位置

典型的 LLM 推理服務架構如下：

User → Ingress / API Gateway → Model Inference Service → GPU Pod → Model Runtime

部署層次：

| 層級 | 說明 |
|------|------|
| 容器化 | 將模型包裝成 Docker 映像 |
| Kubernetes | 使用 Deployment / Service 管理 Pod |
| KServe / Seldon Core | 提供高階模型抽象、版本管理與流量控制 |

KServe / Seldon Core 可視為「ML 服務的控制塔」，專門處理推理層的版本、流量與監控。

使用 KServe 部署 LLM 推理服務

以下以 Hugging Face 的 Llama-2 模型為例。

建立 InferenceService

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: llama2-service
spec:
  predictor:
    model:
      modelFormat:
        name: pytorch
      runtime: kserve-pytorchserver
      storageUri: "s3://your-bucket/models/llama2/"
      resources:
        limits:
          nvidia.com/gpu: 1
          memory: 16Gi

重點說明：

• runtime: 指定推理執行環境（KServe 內建 pytorch / tensorflow / triton 等）
• storageUri: 模型存放位置（支援 S3、GCS、PVC）
• resources: GPU 資源設定，可與前一篇的 GPU Operator 整合使用

驗證服務是否成功啟動

kubectl get inferenceservice llama2-service
kubectl get pods | grep llama2
kubectl port-forward svc/llama2-service-predictor-default 8080:80
curl -X POST http://localhost:8080/v1/models/llama2:predict -d '{"text": "Hello, world"}'

⸻

多版本模型部署與 A/B Testing

KServe 支援同一服務下運行多版本模型，可用來做 A/B 測試。

同時運行多版本模型

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: llama2-multi
spec:
  predictor:
    canaryTrafficPercent: 30
    model:
      modelFormat:
        name: pytorch
      storageUri: "s3://your-bucket/models/llama2-v1/"
    canary:
      modelFormat:
        name: pytorch
      storageUri: "s3://your-bucket/models/llama2-v2/"

說明：

• v1 版本：接收 70% 流量
• v2 版本：接收 30% 流量
• 可透過監控觀察兩版本的延遲、輸出品質與效能差異。

觀察成效
整合 Prometheus + Grafana 監控以下指標：

• 推理延遲（Latency）
• GPU 使用率（GPU Utilization）
• Token Throughput
• 錯誤率與超時次數

Canary Deployment 模型更新流程

為降低更新導致的中斷或異常，可採用 Canary 部署策略。

Canary 流程範例

1. 新版本模型（v2）部署，設定 10% 流量
2. 持續監控延遲、錯誤率、品質
3. 確認穩定後逐步擴大流量（10% → 50% → 100%）
4. 新版本完全穩定後下線舊版本
5. 若異常，立即回滾到前一版本

這樣可以確保即使新版本模型效能或行為有問題，也能安全回退。

模型熱更新（Zero Downtime Deployment）

問題：模型載入時間過長，大型 LLM 模型載入常需數十秒到數分鐘，若直接重啟，會導致中斷。

解法策略

| 策略 | 說明 |
|------|------|
| **Preload + Switch** | 預先啟動新版本 Pod，健康檢查通過後再切流量 |
| **Async Warmup** | Pod 啟動後執行預熱請求，提前載入權重 |
| **Layer Caching** | 共用模型層快取（PVC / vLLM runtime） |
| **KServe ModelMesh** | 適合多模型場景，可動態載入與快取模型 |

⸻

實作：使用 GitOps + Argo Rollouts 自動化模型更新

架構流程

Git Commit → Argo Rollout → KServe InferenceService → Canary 分流 → Metrics 驗證 → 自動升級/回滾

YAML 範例（簡化）

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: llama2-rollout
spec:
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 5m}
      - setWeight: 50
      - pause: {duration: 10m}
      - setWeight: 100
  template:
    spec:
      containers:
      - name: llama2
        image: your-registry/llama2:v2

操作指令

kubectl argo rollouts get rollout llama2-rollout --watch

此流程可結合 Prometheus metrics 自動判斷是否要繼續放量或回滾。

結語

本篇是 DevOps x AI 系列中最關鍵的實作之一。
它將 Day 26 的「GPU 資源管理」與 下一篇 Day 28 的「自動伸縮策略」連接起來，
讓模型從「訓練完成」到「穩定上線」真正成為一個 可維運、可迭代的 LLM 服務。