Model Serving（模型服务化）
就是把训练好的模型挂上网，让别人能发请求来调用它。
亦作、亦称：模型服务化 · LLM Serving · 推理服务 · 在线推理 · Inference Serving
Model Serving 是将训练好的 AI 模型变为可被业务系统实时调用的推理服务的工程实践。它贯穿从模型封装、API 暴露到生产监控的全链路，是 MLOps 与 AI 工程落地的核心环节。
概述
Model Serving 是 MLOps 流水线的最后一公里，负责将离线训练产物转化为在线生产服务。
- 核心目标：让应用系统能通过标准协议（REST/gRPC）实时获取模型预测，无需了解模型内部实现
- 与模型训练的区别：训练关注精度最优，Serving 关注延迟（Latency）、吞吐（Throughput）、可用性（Availability）三者的平衡
- 与模型部署的关系：部署是广义概念，Serving 特指提供在线实时推理能力的子集
- 典型调用链：客户端 → 负载均衡 → Serving 框架 → 推理引擎 → 模型 → 返回预测结果
工作原理
一次完整的 Model Serving 请求经历以下关键步骤。
- 模型加载与预热：服务启动时将模型权重加载至 GPU/CPU 显存，并以虚拟请求预热以消除首请求冷启动延迟
- 请求接收与队列：HTTP/gRPC 网关接收客户端请求，按优先级或 FIFO 送入推理队列
- 动态批处理（Dynamic Batching）：将短时间窗口内的多个请求合并为一个 batch 并行推理，显著提升 GPU 利用率
- 推理执行：调用底层推理引擎（TensorRT、ONNX Runtime 等）完成前向计算
- 结果序列化与返回：将张量输出转为 JSON/Protobuf 格式响应给客户端
- 监控与指标采集：记录延迟分位数（P50/P95/P99）、QPS、错误率等，供告警与自动扩缩容使用
主流框架与技术变体
不同场景下 Model Serving 有多种实现路径，框架选型至关重要。
- 通用框架：NVIDIA Triton Inference Server 支持多后端（TensorFlow/PyTorch/ONNX），BentoML 提供 Python 原生打包，TorchServe 专为 PyTorch 设计
- LLM 专用框架：vLLM（PagedAttention + Continuous Batching）、TensorRT-LLM（NVIDIA 优化内核）、SGLang（结构化生成加速）针对大模型推理做深度优化
- 云原生方案：KServe（原 KFServing）、Ray Serve、Seldon Core 提供 Kubernetes 上的多模型管理与金丝雀发布
- 托管服务：AWS SageMaker Endpoints、Google Vertex AI Prediction、Azure ML Online Endpoints 降低运维门槛
- 边缘/端侧部署：TensorFlow Lite Serving、ONNX Runtime Mobile 面向资源受限设备
应用场景
Model Serving 广泛应用于需要实时 AI 推理的各类业务场景。
- LLM 对话服务：ChatGPT、Claude 等产品通过 LLM Serving 提供流式生成（SSE/WebSocket），需要极低首 Token 延迟（TTFT）
- 推荐与搜索排序：电商、短视频平台每秒数万次推理请求，对 QPS 和 P99 延迟要求极高
- 计算机视觉：图像分类、目标检测（如安防摄像头实时分析）要求毫秒级响应
- 金融风控：信贷审批、反欺诈实时评分，对可解释性与审计日志有额外要求
- 医疗辅助诊断：CT/MRI 影像分析，需要高精度且满足 HIPAA 合规要求的部署环境
局限与常见误区
实际落地中存在若干典型误区和工程陷阱需要注意。
- 误区：只需包装 Flask 接口即可上线：裸 Flask/FastAPI 方案缺少批处理、健康检查、GPU 调度优化，在高并发下性能差数倍
- 误区：GPU 推理一定比 CPU 快：对小 batch、低并发场景，CPU + INT8 量化可能延迟更低且成本更低
- 局限：LLM Serving 显存碎片化严重：不同序列长度导致 KV Cache 碎片，PagedAttention 等技术可缓解但未完全解决
- 局限：冷启动延迟：Serverless Serving 在流量低谷缩容后的冷启动可达数秒，不适合延迟敏感业务
- 常见问题：模型版本漂移：线上模型版本未及时更新或多版本共存导致预测不一致，需严格的版本管理策略
发展脉络
Model Serving 领域经历了从专用框架到 LLM 时代的快速演进。
- 2017 年：Google 发布 TensorFlow Serving（NIPS 2017），UC Berkeley 发布 Clipper（NSDI 2017），Model Serving 作为独立研究方向正式确立
- 2018-2019 年：NVIDIA Triton Inference Server（原 TensorRT Inference Server）发布，支持多框架后端和动态批处理
- 2020-2021 年：KFServing（现 KServe）、Seldon Core 将 Serving 与 Kubernetes 深度整合，云原生 MLOps 成型
- 2022 年：ChatGPT 发布后，LLM Serving 面临超长上下文、高并发流式生成的全新挑战
- 2023 年：vLLM 发布（SOSP 2023），PagedAttention 解决 KV Cache 碎片化问题，吞吐提升数十倍；TensorRT-LLM、SGLang 相继推出
- 2024-2026 年：分布式 Prefill-Decode 分离、KV Cache 跨节点共享、推测解码（Speculative Decoding）等技术持续突破 LLM Serving 性能上限
常见误解
日常交流中容易听到的简化说法，未必准确，但能帮助理解误解从何而来。
- 「就是把训练好的模型挂上网，让别人能发请求来调用它。」
- 「模型推理服务嘛，就是把 model 包成一个接口，业务代码直接调就行，不用关心怎么跑的。」
- 「常见误解是把 Model Serving 等同于纯粹的推理计算，其实它还要负责负载均衡、版本管理、监控告警这些工程层的事情。」
相关术语
和本术语关联紧密的其他词条，便于串联理解。
延伸阅读
从知识库精选 3 篇文章，帮助深入理解该术语。
外部参考
维基百科：查看「Model Serving」词条本页内容为本站原创撰写；维基百科链接仅作延伸参考。