MLOps导读
> **本章阅读时间**：约25分钟（共5篇）
MLOps 导读：让模型稳定运行在生产环境
本章阅读时间：约25分钟（共5篇）
模型训练好了，然后呢？
这个"然后"是很多 AI 项目卡住的地方。训练好的模型只是起点，让它稳定运行在生产环境、持续监控性能、可追溯地管理多个实验版本——这才是 MLOps 要解决的问题。
没有 MLOps 会怎样：真实的痛点
先说没有 MLOps 的世界是什么样的。这不是假设，是大多数 AI 团队真正经历过的。
"这个模型是什么时候训练的？用了什么数据？"——没有人知道。实验跑了很多次，每次改了什么参数，用了哪个版本的数据集，谁也记不清。三个月后想复现一个好结果，发现找不到了。
"上次效果更好的模型参数是什么？"——找不到了。没有系统记录实验，模型文件命名是 model_final.pkl、model_final_v2.pkl、model_final_v2_this_time_really_final.pkl……
"线上模型和测试模型不一样！"——环境不一致的经典问题。本地 Python 3.9，服务器 Python 3.8；本地 transformers 4.35，服务器 4.28；依赖版本差异导致行为不同，排查要花几天。
"模型效果下降了，是什么时候开始的？"——没有监控，没有告警，用户已经在投诉了，但完全不知道问题从哪里来、从什么时候开始。
这四个问题，对应 MLOps 的四个核心能力：实验可追踪性（MLFlow）、模型版本管理（MLFlow Registry）、环境一致性（容器化/标准化依赖）、生产监控（指标追踪和告警）。
什么是 MLOps
MLOps = Machine Learning + DevOps
传统软件开发有 DevOps：代码版本控制（Git）、CI/CD（持续集成/持续部署）、监控告警。这套工程实践让软件开发从"凭经验"变成了"可重复的工程流程"。
AI 开发多了独特的挑战：模型是数据+代码共同决定的，不只是代码；模型性能会随数据分布变化而衰退（模型漂移）；实验结果难以复现（随机性、环境差异）；部署不只是把代码跑起来，还涉及模型加载、推理优化、GPU 资源管理。
MLOps 就是把 DevOps 的工程最佳实践扩展到机器学习系统——加上模型版本管理、实验追踪、持续训练（当数据分布改变时自动触发重训练）、生产监控。
用 AWS 的权威定义来说：MLOps 是"将 DevOps 原则应用于机器学习系统的实践，包括持续集成、持续交付和持续训练"。核心是让 ML 系统像现代软件系统一样，可追踪、可复现、可监控、可快速迭代。
MLOps 工具链速查表
| 需求 | 工具 | 用途 | 本章篇目 |
|---|---|---|---|
| 实验追踪 | MLFlow | 记录参数、指标、代码版本 | 01 |
| 模型版本管理 | MLFlow Registry | Staging→Production 生命周期 | 01 |
| 推理优化 | 量化/剪枝/Flash Attention | 减少显存、提升速度 | 02 |
| 模型格式转换 | ONNX | 跨框架部署，CPU 推理 | 03 |
| 生产 LLM 服务 | vLLM | 高并发推理，10-30x 吞吐提升 | 04 |
| 本地部署 | Ollama | 开发测试，本地隐私部署 | 05 |
| 模型打包部署 | TorchServe | PyTorch 官方推理框架 | 03 |
本章内容
本章关注工程实践，不是模型算法。目标是让 AI 模型从"在我电脑上能跑"变成"在生产环境稳定运行"。
| 文章 | 核心问题 | 阅读时间 |
|---|---|---|
| 01.MLFlow 实验管理 | 怎么记录实验、管理模型版本？ | 约8分钟 |
| 02.模型推理优化 | 怎么让模型运行更快、占用更少显存？ | 约10分钟 |
| 03.TorchServe 与 ONNX | 怎么把模型打包成可调用的 API 服务？ | 约8分钟 |
| 04.vLLM 生产部署 | 怎么在生产环境提供高并发 LLM 服务？（生产级，建议先读第05篇） | 约8分钟 |
| 05.本地部署 LLM | 怎么用 Ollama 在本地跑 DeepSeek 和 Qwen？（入门级，建议先于第04篇阅读） | 约8分钟 |
阅读顺序建议：如果你是第一次接触模型部署，建议先读第 05 篇（Ollama 本地部署）再读第 04 篇（vLLM 生产部署）。Ollama 是面向个人开发测试的轻量工具，5 分钟能跑起来；vLLM 是面向生产高并发的专业推理引擎，有一定的配置复杂度。先本地跑通，再理解生产级方案，认知更自然。
文章编号反映的是技术深度递进（01→05 从管理到部署到优化），而非难度递进。
与其他章节的关系
与第 16 章（微调）的关系：微调完成后，模型需要通过本章的工具链进行版本管理（MLFlow）、推理优化（量化/vLLM）、最终上线服务。merge_and_unload() 后的 LoRA 模型与标准模型部署流程完全相同。
与第 18 章（生产化部署）的关系：本章提供模型层面的基础设施（模型版本、推理引擎），第 18 章在上面构建完整的应用服务（FastAPI、监控、成本控制）。
一个 Java 工程师的视角
Java 后端开发有一套成熟的工程化体系：Maven 管理依赖，Git 管理代码，Jenkins 跑 CI/CD，Prometheus+Grafana 监控，Kubernetes 部署。
MLOps 的角色对应关系大致是：MLFlow 对应 Git+Nexus（实验和模型版本管理），容器化+标准化依赖对应 Maven（可复现的构建环境），模型监控对应 APM（应用性能监控），vLLM 对应 Tomcat/Undertow（高性能请求处理）。
有 Java 工程化经验的开发者，上手 MLOps 的概念并不难，关键是理解 ML 系统独特的挑战：模型不只是代码，还依赖数据和随机性；模型性能会随时间衰退，需要持续监控和重训练。