从训练到推理：Kubernetes 上 MLOps 平台的构建与优化

1. 引言

随着机器学习模型在生产环境中的落地，MLOps 已成为连接数据、算法与业务的关键工程实践。Kubernetes 凭借其强大的资源编排、弹性伸缩与多云能力，正逐步成为承载 MLOps 平台的主流底座。然而，从模型训练到在线推理，Kubernetes 上构建一套稳定、高效、可观测的 MLOps 平台，仍面临诸多挑战。

本文将围绕 MLOps 在 Kubernetes 上的核心挑战展开，重点探讨分布式训练的 GPU 配额与公平共享策略、推理服务的 Knative Serving 自动扩缩容（含 scale-to-zero）、模型部署的蓝绿与金丝雀策略，以及训练指标、GPU 利用率与推理延迟的统一可观测性建设。

2. MLOps 在 Kubernetes 上的核心挑战

在 Kubernetes 上构建 MLOps 平台，并非简单地把训练脚本和推理服务容器化即可。机器学习工作负载与传统微服务在生命周期、资源需求与运维方式上存在显著差异，由此带来一系列核心挑战。

2.1 分布式训练的资源编排

分布式训练（如 TensorFlow、PyTorch 的分布式模式）需要多节点协同工作，涉及参数服务器、工作节点等多种角色。Kubernetes 原生调度器对这类有状态、多角色、强通信需求的工作负载支持有限，需要借助 Kubeflow、Ray 等框架或自定义 Operator 来管理训练任务的声明式生命周期。

2.2 模型版本管理

模型不是一次性产物，而是随数据与算法迭代持续演进。训练产出的模型文件、超参数、训练数据版本、评估指标等需要统一登记与追溯。Kubernetes 本身不提供模型仓库能力，需要结合 MLflow、DVC 或对象存储来构建模型版本管理链路，并确保训练与推理阶段引用一致的模型版本。

2.3 推理服务的弹性与稳定性

在线推理服务对延迟敏感，且流量波动大。传统 Deployment + HPA 的扩缩容粒度较粗，冷启动时间长，难以满足突发流量与成本节约的双重需求。如何在保证服务质量的同时实现按需伸缩，是推理服务面临的核心难题。

2.4 资源隔离与多租户公平性

在共享集群中，多个团队、多个任务同时提交 GPU 资源请求，容易出现资源争抢、配额不均、任务饿死等问题。如何设计 GPU 配额与公平共享策略，直接关系到集群利用率和团队协作效率。

下图概括了 MLOps 平台在 Kubernetes 上面临的核心挑战：

flowchart TD A["MLOps 平台"] --> B["分布式训练的资源编排"] A --> C["模型版本管理"] A --> D["推理服务的弹性与稳定性"] A --> E["资源隔离与多租户公平性"] B --> F["Kubeflow / Ray / Operator"] C --> G["MLflow / DVC / 对象存储"] D --> H["Knative Serving / HPA"] E --> I["GPU 配额 / 公平调度"]

3. 分布式训练的 GPU 配额与公平共享策略

GPU 是机器学习训练中最昂贵、最稀缺的资源。在 Kubernetes 集群中，合理的 GPU 配额与公平调度策略，是保障训练任务稳定运行、提升集群整体利用率的关键。

3.1 GPU 资源抽象与配额管理

Kubernetes 通过 Device Plugin 机制将 GPU 暴露为可调度的扩展资源（如 nvidia.com/gpu）。管理员可以通过 ResourceQuota 限制每个命名空间的 GPU 总量，防止单个团队独占集群资源。

yaml 复制代码

apiVersion: v1
kind: ResourceQuota
metadata:
  name: gpu-quota
  namespace: ml-team-a
spec:
  hard:
    nvidia.com/gpu: "8"

同时，结合 LimitRange 约束单个 Pod 的 GPU 申请范围，避免超卖导致节点资源过载。

3.2 公平共享调度策略

仅靠配额无法解决动态竞争问题。当多个任务同时排队时，需要公平调度策略来平衡资源分配。Kubernetes 社区与第三方项目提供了多种方案：

Kubernetes 原生优先级与抢占：通过 PriorityClass 区分任务优先级，高优任务可抢占低优任务资源，但需谨慎设计避免饿死。
Kubeflow 的调度器：支持 Gang Scheduling（成组调度），确保分布式训练的所有 Worker 同时获得资源，避免部分节点空转等待。
Volcano 调度器：提供公平性（Fairness）、队列（Queue）与抢占策略，适合大规模 AI 训练场景，支持基于权重的资源分配。

yaml 复制代码

apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: ml-queue
spec:
  weight: 10
  capability:
    nvidia.com/gpu: "32"

3.3 弹性训练与资源碎片治理

训练任务往往不是恒定资源消耗。借助 Elastic Training（如 Elastic Horovod、Ray），可以在训练过程中动态调整 Worker 数量，将空闲 GPU 释放给其他任务，减少资源碎片。同时，结合节点池（Node Pool）与抢占式实例，可进一步降低成本。

下图展示了 GPU 配额与公平共享调度的整体流程：

flowchart LR A["训练任务提交"] --> B["ResourceQuota 配额校验"] B --> C{"配额充足?"} C -- "否" --> D["排队等待"] C -- "是" --> E["公平调度器"] E --> F["Volcano / Kubeflow / 原生抢占"] F --> G["GPU 资源分配"] G --> H["分布式训练执行"] H --> I["弹性训练释放空闲 GPU"] I --> D

4. 推理服务优化：Knative Serving + 自动扩缩容

在线推理服务对延迟与成本同样敏感。Knative Serving 基于 Kubernetes 构建，为无状态工作负载提供了强大的自动扩缩容能力，尤其适合 AI 推理场景。

4.1 Knative Serving 核心概念

Knative Serving 以 Service、Revision、Route 等资源抽象管理应用版本与流量。每个 Revision 对应一个不可变的版本快照，Route 负责将流量按权重分发到不同 Revision，天然支持灰度发布。

yaml 复制代码

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: inference-service
  namespace: ml-inference
spec:
  template:
    spec:
      containers:
        - image: registry.example.com/model-server:latest
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "1"
              memory: 2Gi
            limits:
              nvidia.com/gpu: "1"

4.2 自动扩缩容与 scale-to-zero

Knative 默认基于并发数（Concurrency）或请求速率（RPS）进行自动扩缩容，支持从零到 N 的弹性伸缩。scale-to-zero 是 Knative 的杀手锏能力：当服务长时间无流量时，自动将副本缩容到零，释放 GPU 与内存资源，显著降低闲置成本。

yaml 复制代码

spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "10"
        autoscaling.knative.dev/minScale: "0"
        autoscaling.knative.dev/maxScale: "20"

当请求到来时，Knative 的 Activator 组件会快速拉起新副本，完成冷启动。对于 AI 推理场景，模型加载耗时较长，可通过以下手段优化冷启动：

预留副本（minScale > 0）：为关键服务保留最小副本，避免冷启动延迟。
镜像预热与模型缓存：将模型文件挂载到共享存储或节点本地缓存，减少加载时间。
自定义指标扩缩容：结合 KEDA 或 Knative 自定义指标，基于 GPU 利用率或队列深度扩缩容。

4.3 推理服务的资源与并发调优

推理服务通常受 GPU 显存与算力限制。合理设置并发上限（containerConcurrency）可防止 GPU 过载导致延迟飙升。同时，可结合模型批处理（Dynamic Batching）提升 GPU 吞吐，在延迟与利用率之间取得平衡。

下图展示了 Knative Serving 的自动扩缩容与 scale-to-zero 机制：

flowchart TD A["请求流量"] --> B["Activator 组件"] B --> C{"当前副本数?"} C -- "0（scale-to-zero）" --> D["冷启动拉起新副本"] C -- ">0" --> E["负载均衡分发"] D --> F["模型加载与预热"] F --> G["处理请求"] G --> H{"持续无流量?"} H -- "是" --> I["缩容到零，释放 GPU"] H -- "否" --> G E --> G

5. 模型部署的蓝绿与金丝雀策略

模型更新是高频操作，如何在保证服务可用性的前提下平滑上线新版本，是 MLOps 平台必须解决的问题。蓝绿部署与金丝雀发布是两种最常用的策略。

5.1 蓝绿部署

蓝绿部署维护两套独立环境（蓝、绿），新版本在绿环境验证通过后，将流量一次性切换到绿环境。若出现问题，可快速回切到蓝环境。

在 Kubernetes 中，可通过 Knative Route 或 Service Mesh（如 Istio）实现蓝绿切换：

yaml 复制代码

apiVersion: serving.knative.dev/v1
kind: Route
metadata:
  name: inference-route
  namespace: ml-inference
spec:
  traffic:
    - revisionName: inference-v1
      percent: 100
    - revisionName: inference-v2
      percent: 0

蓝绿部署适合模型兼容性风险较高、需要快速回滚的场景，但资源成本翻倍。

5.2 金丝雀发布

金丝雀发布将少量流量（如 5%--10%）导向新版本，在真实流量下验证模型效果与稳定性，再逐步扩大流量比例，直至全量切换。

yaml 复制代码

spec:
  traffic:
    - revisionName: inference-v1
      percent: 90
    - revisionName: inference-v2
      percent: 10

金丝雀发布可结合自动化评估：当新版本的延迟、错误率、模型指标（如 AUC）达到阈值后，自动提升流量比例；否则自动回滚。这需要与可观测性系统联动。

5.3 策略选型建议

模型效果差异大、风险高 → 蓝绿部署，便于快速回滚。
模型迭代频繁、希望持续验证 → 金丝雀发布。
结合 Istio 的流量镜像（Traffic Mirroring），可在不污染线上流量的情况下对比新旧版本输出。

下图对比了蓝绿部署与金丝雀发布的流量切换策略：

flowchart TD A["新版本上线"] --> B{"选择发布策略"} B -- "蓝绿部署" --> C["部署到绿环境"] C --> D["验证通过"] D --> E["流量一次性切换 100%"] E --> F{"出现问题?"} F -- "是" --> G["快速回切到蓝环境"] F -- "否" --> H["保留绿环境"] B -- "金丝雀发布" --> I["部署新版本"] I --> J["流量 5%-10% 导向新版本"] J --> K{"自动评估指标"} K -- "达标" --> L["逐步扩大流量比例"] L --> M["全量切换"] K -- "未达标" --> N["自动回滚"]

6. 可观测性：训练指标、GPU 利用率与推理延迟的统一监控

MLOps 平台的可观测性横跨训练与推理两个阶段，需要统一采集、存储与展示指标，帮助工程师快速定位问题。

6.1 统一监控架构

推荐基于 Prometheus + Grafana 构建统一监控体系：

Prometheus 采集 Kubernetes 资源指标、GPU 指标（通过 DCGM Exporter）、训练框架指标（如 TensorBoard 指标导出）与推理服务指标（Knative 自动暴露）。
Grafana 提供统一可视化面板，将训练、GPU、推理延迟等指标汇聚到同一视图。
Thanos / VictoriaMetrics 解决多集群、长期存储与高可用问题。

6.2 训练阶段指标

训练阶段需要关注：

GPU 利用率与显存占用：判断训练是否充分利用硬件。
训练吞吐（样本/秒）与 Loss 曲线：监控模型收敛情况。
分布式训练的通信效率：关注 All-Reduce 耗时、网络带宽。

通过 DCGM Exporter 可采集细粒度 GPU 指标：

yaml 复制代码

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: dcgm-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: dcgm-exporter
  template:
    metadata:
      labels:
        app: dcgm-exporter
    spec:
      containers:
        - name: dcgm-exporter
          image: nvidia/dcgm-exporter:latest
          ports:
            - containerPort: 9400

6.3 推理阶段指标

推理阶段需要关注：

P99 / P95 延迟：衡量服务质量的核心指标。
QPS 与并发数：反映服务负载与扩缩容效果。
错误率与模型漂移：监控推理结果质量。

Knative 自动暴露请求延迟、并发等指标，可直接接入 Prometheus：

yaml 复制代码

apiVersion: v1
kind: ServiceMonitor
metadata:
  name: knative-serving-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: activator
  endpoints:
    - port: metrics
      interval: 15s

6.4 统一告警与关联分析

将训练与推理指标统一存储后，可建立跨阶段告警规则，例如：

GPU 利用率长期低于阈值 → 提示资源浪费或任务异常。
推理延迟突增 → 关联检查 GPU 利用率、副本数、模型版本，快速定位根因。
新版本上线后错误率上升 → 触发自动回滚。

结合 Prometheus Alertmanager 与 Grafana 告警，可实现训练到推理的全链路监控闭环。

下图展示了训练到推理的全链路可观测性架构：

flowchart LR subgraph A["训练阶段"] A1["训练框架指标"] A2["DCGM GPU 指标"] A3["通信效率指标"] end subgraph B["推理阶段"] B1["P99/P95 延迟"] B2["QPS 与并发"] B3["错误率与模型漂移"] end A --> C["Prometheus 采集"] B --> C C --> D["Thanos / VictoriaMetrics 存储"] D --> E["Grafana 统一可视化"] E --> F["Alertmanager 告警"] F --> G["自动回滚 / 扩缩容"]

7. 总结

在 Kubernetes 上构建 MLOps 平台，需要从训练与推理两个维度系统性地解决资源调度、弹性伸缩、发布策略与可观测性问题：

分布式训练：通过 GPU 配额、公平调度（Volcano/Kubeflow）与弹性训练，提升集群利用率。
推理服务：借助 Knative Serving 的自动扩缩容与 scale-to-zero，兼顾延迟与成本。
模型发布：通过蓝绿与金丝雀策略，实现平滑、可回滚的版本更新。
可观测性：基于 Prometheus + Grafana 统一监控训练指标、GPU 利用率与推理延迟，形成全链路可观测闭环。

MLOps 平台的构建不是一蹴而就的，需要结合团队规模、业务场景与基础设施现状持续迭代优化。希望本文的梳理能为你在 Kubernetes 上构建高效、稳定的 MLOps 平台提供参考。