外观
部署 vs MLOps vs 推理 vs 模型服务：五个高频词一次厘清
在模型部署社区里，有五个词几乎天天出现、几乎人人混用：模型部署（model deployment）、MLOps、推理（inference）、模型服务（model serving）、推理引擎（inference engine）。面试时「你说说 MLOps 和模型服务的区别」，能当场把概念层级画清楚的人不到三成。本文用一句话定义、一张辨析表、一幅层级图，把五个词的边界钉死。
一句话版本：MLOps ⊃ 模型部署 ⊃ 模型服务；推理是运行时行为，推理引擎是执行推理的底层软件。
一、五个概念的一句话定义
| 概念 | 一句话定义 | 反义词/边界词 |
|---|---|---|
| MLOps | 把机器学习全生命周期（数据、训练、部署、监控、治理）工程化与自动化的方法论与实践 | 软件领域的 DevOps |
| 模型部署（model deployment） | 让训练好的模型在真实环境持续生效的工程过程（见 什么是模型部署） | 模型训练 |
| 模型服务（model serving） | 把推理能力包装成网络接口，供其他系统调用的一层技术 | 批处理/离线推理 |
| 推理（inference） | 用模型参数对输入计算预测的一次运行时行为 | 训练（前向 vs 反传） |
| 推理引擎（inference engine） | 负责高效执行推理计算的底层软件库，如 ONNX Runtime、TensorRT、vLLM | 编程框架 PyTorch 原生推理 |
二、概念辨析表：定义、时间点、责任人与工具
同一张表把五个词从四个维度对照：
| 概念 | 本质 | 发生时间 | 谁负责 | 典型工具/平台 |
|---|---|---|---|---|
| MLOps | 方法论/平台 | 全生命周期，持续 | MLOps/平台团队 | MLflow、Kubeflow、SageMaker、MLOps 流水线 |
| 模型部署 | 工程过程 | 训练完成之后，持续 | 部署/推理平台工程师 | KServe、Seldon Core、Triton 部署、自定义 Docker |
| 模型服务 | 技术层 | 部署完成后的常态 | 后端/服务工程师 | FastAPI、Triton、vLLM、KServe |
| 推理 | 运行时行为 | 每个请求发生时 | 引擎/算子开发者 | 前向计算（forward pass） |
| 推理引擎 | 底层软件 | 每个请求发生时 | 框架开发者/厂商 | ONNX Runtime、TensorRT、vLLM、OpenVINO |
用「谁负责」快速自测
同一个工具会横跨多个概念，别用工具反推概念。Triton 既是模型服务框架，也常被用来完成「部署」这个动作，但它是服务层的东西，不是 MLOps 的编排器。判断概念归属，看它在流水线里解决什么问题，而不是看它的 README 写了什么。
三、层级关系图：谁是谁的子集
五个概念不是并列关系，是嵌套关系：
text
┌──────────────────────────────────────────────────────────┐
│ MLOps（全生命周期方法论） │
│ ┌────────────────────────────────────────────────────┐ │
│ │ 模型部署（让模型在真实环境持续生效的过程） │ │
│ │ ┌──────────────────────────────────────────────┐ │ │
│ │ │ 模型服务（把推理包装成网络接口的技术层） │ │ │
│ │ │ ├── FastAPI / gRPC 网关 │ │ │
│ │ │ └── 推理引擎（执行推理的底层软件） │ │ │
│ │ │ ├── ONNX Runtime / TensorRT │ │ │
│ │ │ └── vLLM（LLM 时代的引擎+服务一体） │ │ │
│ │ └──────────────────────────────────────────────┘ │ │
│ │ ↑ 推理（inference）不是「层」，是运行时行为 │ │
│ └────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘读图要点：
- MLOps 是最大的圈：数据管理、训练、部署、监控、治理都在它管界内。
- 部署是 MLOps 的子集：专指「上线与维护模型」那段，不包含数据标注与模型设计。
- 模型服务是部署的子集：部署还要管镜像、滚动发布、灰度回滚；服务只关心「把请求变成预测」。
- 推理不是层，是行为：它发生在服务层之内，是引擎被调用时的一次计算。
- 推理引擎是最底层：服务框架调用引擎，引擎直接操作 GPU/CPU。
最精炼的记忆法
MLOps 管全局，部署管上线，服务管接口，引擎管计算，推理是那一刻的「发生」。
四、一个模型从训练到上线的流水线全景
把五个概念放回真实流水线里，每个概念「出现在哪一步」一目了然：
text
数据准备 → 训练 → 评估 → 模型注册 → 镜像/容器化 → 部署上线 → 服务化 → 监控与迭代
│ │ │ │ │ │ │ │
└────────┴──────┴────────┴────────────┴────────────┴─────────┴───────────┘
└─────────────── MLOps 贯穿全流程 ──────────────┘
(MLflow 记录实验与注册模型)
训练完成后的后半段，才是「模型部署」： │
镜像化 (Docker) → 编排 (K8s/KServe) → 上线 → 灰度 → 监控 │
其中「服务化」这一小节 = 模型服务： │
服务框架 (FastAPI/Triton) 收到 HTTP/gRPC 请求 → │
调用推理引擎 (ONNX Runtime/TensorRT) 执行一次「推理」 → │
返回预测结果 │每一步的职责归属：
| 流水线步骤 | 归属概念 | 典型动作 |
|---|---|---|
| 实验记录、模型版本登记 | MLOps | MLflow 记录 metrics、注册 model registry |
| 训练、评估 | MLOps 范畴（非部署） | PyTorch / TensorFlow 训练脚本 |
| 导出模型格式 | 部署的准备阶段 | 转 ONNX、模型格式 |
| 构建服务镜像、写 API | 模型服务 | FastAPI、gRPC、输入输出 schema |
| 调用引擎执行计算 | 推理 | ONNX Runtime 会话（session）run() |
| 容器编排、灰度、扩容 | 模型部署 | Kubernetes、KServe 部署 |
| 告警、漂移检测、重训触发 | MLOps | Prometheus + 监控 |
五、常见错误说法纠正
下面是面试和社区里最常出现、最容易混淆人的错误说法，逐条纠正：
「部署就是训练完后把模型放上去一次」 ✗ 错。部署是持续进行时：模型会更新、环境会变、流量会变，灰度、监控、回滚、重训闭环才是部署的全貌（详见 什么是模型部署）。
「推理引擎就是服务框架」 ✗ 错。ONNX Runtime / TensorRT / vLLM 负责执行计算；FastAPI / Triton / KServe 负责组织请求与资源。Triton 的独特之处是它内置了多种引擎的调度，所以容易让人混为一谈，但它本身的定位仍是服务框架。
「模型服务 = 部署」 ✗ 错。服务只是部署中「接口层」那一块。部署还包括镜像构建、滚动发布、回滚、容量规划——这些模型服务概念覆盖不到。
「MLOps 就是 CI/CD + 部署」 ✗ 错。MLOps 覆盖数据版本化、实验管理、训练编排、特征工程、模型治理与合规，部署只是它的一道工序。参考 MLOps 流水线全景。
「推理 = 用 PyTorch 跑一下 model(x)」 ✗ 半对。语义上「用模型算预测」没错，但生产语境里推理强调在引擎上高效执行（批处理、量化、内存复用），
model(x)的朴素调用既不高效也不够格（详见 推理基础）。
一句话检验法
当有人混用这些词时，问一个反问：「你说的这个，是在流水线里哪一段、解决什么问题？」 能回答「这一段/这个问题」的，概念就立住了。
六、为什么这五个词需要被严格区分
区分概念不是文字洁癖，而是有工程后果的：
- 团队分工：概念不清会导致「服务工程师写引擎调度」或「平台团队不管接口规范」，责任边界模糊是线上故障的温床。
- 选型决策：选错了层级去挑工具，等于拿 MLOps 的编排器去解决接口的延迟问题。选型框架见 框架对比。
- 故障排查：一个超时问题，如果不知道它是「服务层排队」（模型服务问题）、「引擎执行慢」（推理引擎问题）还是「调度策略问题」（部署层问题），排查会绕大圈。分层排查思路见 推理系统总体架构解剖。
延伸阅读
- 什么是模型部署 —— 部署这一环的完整定义与挑战
- MLOps 流水线全景 —— MLOps 这个「最大圈」的完整展开
- 模型服务 —— 服务层技术与批处理机制
- 推理基础 —— 推理行为的底层原理
- 推理引擎对比 —— 五个引擎的选型对照
- 术语表 —— 更多易混术语的权威定义