共计 1619 个字符，预计需要花费 5 分钟才能阅读完成。
开篇：模型交付的三大痛点
刚入行时，我总以为机器学习项目最难的是调参，直到第一次参与生产部署才意识到：
- 环境差异 ：本地训练好的模型，在服务器上因 CUDA 版本不一致直接崩溃
- 版本混乱 ：团队同时修改了 3 个模型分支，却没人能说清线上跑的是哪个版本
- 监控缺失 ：半夜接到业务方电话，才知道模型预测结果已偏离预期 2 周
这些问题消耗了团队 60% 以上的精力，直到引入 MLOps 才实现高效交付。下面分享我们的实战方案。
工具链选型：Airflow vs Kubeflow vs MLflow
选对工具能事半功倍，我们的对比结论：
- Airflow：适合调度依赖复杂的 ETL 任务，但机器学习特性支持弱
- Kubeflow：Kubernetes 原生方案，适合大规模分布式训练，学习曲线陡峭
- MLflow：轻量级实验管理工具，版本追踪和部署功能完善
最终方案：MLflow（实验管理）+ Kubernetes（部署）+ Prometheus（监控） 组合，兼顾灵活性与易用性。
核心实现三步走
1. 环境容器化：Docker + Kubernetes
# 模型训练镜像
FROM nvidia/cuda:11.7.1-base
# 固定所有依赖版本
RUN pip install \
tensorflow==2.10.0 \
mlflow==2.3.0 \
pandas==1.5.3
# 启动训练脚本
CMD ["python", "train.py"]关键点：
- 基础镜像明确指定 CUDA 版本
- 所有 Python 依赖固定版本号
- 通过 K8s 的 ResourceQuota 限制 GPU 使用量
2. 模型版本管理：MLflow 全链路追踪
import mlflow
# 自动记录参数和指标
with mlflow.start_run() as run:
mlflow.log_param("learning_rate", 0.01)
model.fit(X_train, y_train)
mlflow.log_metric("accuracy", test_acc)
# 注册模型版本
mlflow.sklearn.log_model(
sk_model=model,
artifact_path="model",
registered_model_name="churn_prediction"
)3. 监控告警：Prometheus 指标设计
# prometheus-config.yml
scrape_configs:
- job_name: 'model_server'
metrics_path: '/metrics'
static_configs:
- targets: ['model-service:8000']核心监控指标：
- 请求延迟（P99 < 200ms）
- 每秒查询量（QPS）波动
- 预测概率分布变化（PSI 值）
避坑实战指南
数据漂移检测方案
# 计算 PSI 指标
from scipy.stats import entropy
def psi(base, current, bins=10):
# 分箱计算分布差异
base_perc = np.histogram(base, bins=bins)[0] / len(base)
current_perc = np.histogram(current, bins=bins)[0] / len(current)
return entropy(base_perc, current_perc)GPU 资源争抢解决
# k8s-gpu-config.yaml
resources:
limits:
nvidia.com/gpu: 1
requests:
nvidia.com/gpu: 1完整架构示意图
graph TD
A[数据存储] --> B[MLflow 实验跟踪]
B --> C[模型训练容器]
C --> D[模型注册中心]
D --> E[K8s 部署服务]
E --> F[Prometheus 监控]
F --> G[Grafana 看板]思考题：跨团队协作规范
当多个团队共用同一套 ML 平台时，如何设计：
- 模型版本命名规范
- 资源配额审批流程
- 生产环境发布标准
欢迎在评论区分享你的实践经验。
正文完
