MLOps 工程实践

先把结论放前面

MLOps 解决的是"模型训出来后，怎么管、怎么部署、怎么监控"的问题。没有 MLOps，模型会变成"实验时能用，上线就出问题"的尴尬状态。核心三件事：实验可追踪（Experiment Tracking）、特征可复用（Feature Store）、部署可回滚（Model Registry + CI/CD）。

为什么这个问题值得单独讲

机器学习项目的失败通常不是"模型不够准"，而是"模型上线后没人知道为什么不准了"——数据漂移没监控、训练配置丢失、回滚不知道用哪个版本。A层的 MLOps 实践把这些问题变成可工程化的事情。

实验管理：MLflow vs Weights & Biases

MLflow

定位：开源的机器学习生命周期管理平台，支持 Experiment Tracking、Model Registry、MLflow Projects、MLflow Models。

核心概念：

MLflow Tracking Server
  └── Experiments
        ├── Experiment 1
        │     ├── Run 1（train.py，params, metrics, artifacts）
        │     ├── Run 2
        │     └── Run 3
        └── Experiment 2

典型用法：

import mlflow

mlflow.set_experiment("recommendation_model")

with mlflow.start_run(run_name="baseline_lr"):
    mlflow.log_param("model_type", "logistic_regression")
    mlflow.log_param("C", 0.1)
    mlflow.log_metric("AUC", 0.82)
    mlflow.log_metric("Recall@10", 0.65)
    mlflow.log_artifact("feature_importance.csv")
    mlflow.sklearn.log_model(model, "model")

优点：开源、可私有部署、和各大框架集成好（Sklearn/PyTorch/TensorFlow）。

弱点：UI 不如商业工具好看，分布式训练日志管理能力有限。

Weights & Biases（W&B）

定位：商业化的实验跟踪工具，UI 好看，社区活跃（公开项目可以白嫖）。

核心概念：W&B 和 MLflow 功能完全对应，但体验更好：

W&B Dashboard
  └── Projects
        ├── Run 1（config, summary metrics, system metrics, artifacts）
        ├── Run 2
        └── Run Comparison Table

优点：UI 极其友好，自动记录 GPU 利用率 / 训练曲线 / 模型梯度分布，支持 Sweeps（超参自动搜索）。

弱点：不开源，数据在第三方（商业版有私有部署选项）。

选哪个

维度	MLflow	Weights & Biases
成本	开源免费	免费有限，商业版付费
部署	完全私有	主要 SaaS（也有私有版）
UI	一般	极其好
Sweeps	需自己实现	内置，易用
分布式训练	支持（需要 Tracking Server）	支持（需要 W&B Agent）
适用	企业内部、金融（数据不出域）	快速迭代团队

Feature Store

核心问题

训练和推理时，用的特征定义必须一致。如果训练时"用户年龄"是"当前年份 - 出生年"，推理时用了另一个计算方式，模型就会出错。

Feature Store 把特征定义（Transformation）集中管理，保证训练和推理用同一套逻辑。

架构

┌─────────────────────────────────────────┐
│            Feature Store                  │
│  ┌─────────────┐    ┌──────────────┐    │
│  │  Offline    │    │   Online     │    │
│  │  Store      │    │   Store      │    │
│  │  (S3/Hive)  │    │  (Redis/     │    │
│  │             │    │   DynamoDB)  │    │
│  └──────┬──────┘    └──────┬───────┘    │
│         │  同步              │ 实时读取   │
│         └────────┬───────────┘            │
│                  ▼                        │
│         ┌───────────────┐                │
│         │  Feature      │                │
│         │  Registry     │                │
│         │  (元数据管理)   │                │
│         └───────────────┘                │
└─────────────────────────────────────────┘

Offline Store：历史特征，用于训练。数据量大，查询延迟不敏感。

Online Store：最新特征，用于推理。延迟敏感，需要 Redis/DynamoDB 这类KV存储。

Feature Registry：特征的元数据（名称、类型、数据源、ETL 逻辑、所有者）。

主流 Feature Store

工具	出品方	特点
Feast	Gojek（开源）	开源最活跃，支持 Spark、Flink、Redis
Tecton	商业版（Feast 创始团队）	企业级，功能完整
SageMaker Feature Store	AWS	和 SageMaker 深度集成
Databricks Feature Store	Databricks	和 Delta Lake 集成

Feature Store 适合什么时候用

特征数量 > 20 个，多个模型共用特征
训练和推理特征定义容易不一致
需要特征血缘追踪（哪个特征来自哪个数据源）

模型部署：Serving 框架

TorchServe

PyTorch 官方 Serving 框架，不需要额外的推理服务。

# 导出 TorchScript 模型
import torch
model = load_model()
model.eval()
 scripted = torch.jit.trace(model, example_input)
 scripted.save("model.pt")

# 启动服务
torchserve --model-name model --version 1.0 \
  --model-file model.py --handler handler.py \
  --batch-size 4 --max-batch-delay 100

优点：PyTorch 原生，不需要单独维护推理服务。

弱点：功能较基础，没有自适应批处理（adaptive batching）。

Triton Inference Server

NVIDIA 出品的推理服务器，支持 PyTorch / TensorFlow / ONNX / TensorRT。

核心特性：

动态批处理（Dynamic Batching）：把多个请求自动合并成一个 batch，提升 GPU 利用率
并发模型执行：同一 GPU 上跑多个模型
TensorRT 加速：把 FP32 模型自动转为 TensorRT 引擎（FP16/INT8）
模型流水线（Model Pipeline）：Preprocess → Inference → Postprocess 在同一个 Pipeline 里

适合场景：生产环境大吞吐推理，GPU 利用率优化。

推理优化的常见手段

ONNX Runtime：把模型转为 ONNX 格式，跨框架推理（PyTorch → ONNX → 目标框架），通常能加速 1.5-2 倍。

TensorRT：NVIDIA 专属，对 GPU 做了极致优化（Layer Fusion、Kernel Auto-Tuning），大型 Transformer 可加速 3-10 倍。

KV Cache（LLM 推理）：在自回归生成时，把已计算的 Key-Value Tensor 缓存起来，避免重复计算。显存占用大（和上下文长度成正比），但生成速度提升显著。

模型监控

核心指标

训练时监控：Loss 曲线、梯度分布、学习率变化、Early Stopping。

推理时监控（生产）：

数据漂移（Data Drift）：输入数据分布变了
概念漂移（Concept Drift）：输入和输出的关系变了
模型性能（Performance）：线上 AUC / Precision / Recall 实时监控
延迟 / QPS：P50 / P95 / P99 推理延迟
错误率：模型报错率

漂移检测

Population Stability Index（PSI）：

PSI = Σ [(Actual% - Expected%) × ln(Actual% / Expected%)]

PSI < 0.1：稳定
PSI 0.1-0.2：轻微漂移，需要关注
PSI > 0.2：严重漂移，需要重新训练

协变量漂移 vs 概念漂移：

协变量漂移：P(X) 变了，但 P(Y|X) 没变（输入变了，模型还 OK）
概念漂移：P(Y|X) 变了（模型和现实的关系变了，必须重训）

监控工具

工具	定位	特点
Evidently AI	开源漂移检测	专门做漂移统计，可嵌入 Pipeline
Arize	商业模型监控	接入简单，UI 好，支持 Embedding 漂移
WhyLabs	SaaS 监控	和 LangChain 有集成
Prometheus + Grafana	通用监控	自建，适合有监控基础设施的团队

端到端 MLOps 流程

1. 数据采集 → 2. 特征工程 → 3. 模型训练 → 4. 模型评估 → 5. 模型注册 → 6. 部署 → 7. 监控
     ↓               ↓              ↓               ↓              ↓            ↓
  Feature         Experiment    Evaluation    Model           Serving     Monitoring
  Store          Tracking       自动比对       Registry        CI/CD        Dashboard

关键实践：

每个阶段都留痕：Feature Store 记录特征血缘，MLflow 记录训练配置，Model Registry 记录模型血缘
自动化评估：用 CI/CD 跑回归测试，线上 AUC 下降 > 2% 自动报警
影子部署（Shadow Mode）：新模型在影子模式下同时跑，和线上模型对比，验证后再切换

如果放到面试里怎么讲

"你们怎么做模型管理的？"

我们用 MLflow 记录每次实验的参数、metrics 和 artifacts，模型注册到 Model Registry 里。每次上线前会在验证集上跑回归测试，对比 AUC、Precision 是否有明显下降。新模型用影子部署模式运行一段时间，确认没问题再切换。

"怎么监控模型是否变差了？"

两层监控：数据漂移监控（PSI 检测输入分布变化）和模型性能监控（实时追踪线上 AUC）。漂移超过阈值或者 AUC 下降超过 2%，自动触发重新训练 Pipeline。

最后记几个点

MLOps 三个核心：实验可追踪（MLflow/W&B）、特征可复用（Feature Store）、部署可回滚（Model Registry）
MLflow 适合企业内部（完全私有），W&B 适合快速迭代团队（体验好）
Feature Store 解决训练-推理特征不一致问题，>20 个特征时价值明显
Triton Inference Server 是生产推理的首选，Dynamic Batching + TensorRT 能显著提升 GPU 利用率
ONNX Runtime 是跨框架推理的标准中转格式，TensorRT 是 NVIDIA GPU 上的最终加速方案
模型监控三层：数据漂移（PSI）、概念漂移、性能指标（AUC/Precision）
漂移超过 PSI > 0.2 或 AUC 下降 > 2% 时，必须触发重训