模型部署手册

外观

部署演进简史：从脚本时代到 LLM 推理时代

本页速览 从 2015 年的「脚本 + 手工复制权重」到今天的 vLLM 连续批处理与云原生推理平台，模型部署十年走过了怎样的路？本文按时间线梳理四个时代的关键工具、痛点与转折，帮你理解今天每个工具的由来。

部署演进简史：从脚本时代到 LLM 推理时代 ​

模型部署的历史只有大约十年，却已经走完了「手工脚本 → 服务框架 → 云原生与引擎竞赛 → LLM 推理」四个时代。理解每个工具为什么存在，比记住它怎么用更重要——今天的 ONNX Runtime、Triton、vLLM、KServe，每一个都是上一代痛点的直接产物。本文按时间线拆解四个时代的工具、痛点与转折，让你从「会用工具」升级到「看得懂工具背后的逻辑」。

一、时间线总览：四个时代 ​

text
2013-2016         2016-2018            2018-2022                2022-至今
┌─────────────┐  ┌─────────────────┐  ┌───────────────────┐  ┌───────────────────┐
│ 第一代       │→ │ 第二代           │→ │ 第三代             │→ │ 第四代             │
│ 脚本时代     │  │ 服务框架时代      │  │ 云原生与引擎竞赛     │  │ LLM 推理时代       │
│             │  │                  │  │                    │  │                    │
│ Flask+手写   │  │ TFServing 2016   │  │ ONNX 2017 / TensorRT│  │ vLLM 2023 (PagedKV)│
│ 批处理脚本   │  │ TorchServe 2018  │  │ Triton 2018        │  │ continuous batch   │
│ 手工复制权重 │  │ 单机部署          │  │ K8s/KServe 2020     │  │ KV Cache 优化      │
│             │  │ gRPC 起步         │  │ Serverless 兴起     │  │ 投机解码/前缀缓存    │
└─────────────┘  └─────────────────┘  └───────────────────┘  └───────────────────┘
   痛点：不可复现    痛点：框架锁定/        痛点：多引擎碎片化    痛点：LLM 长序列
   无并发/无监控      并发能力弱           GPU 利用率低          显存爆炸/延迟高

四代的共性规律：每一次演进都是上一代痛点的系统化回答。

二、第一代：脚本时代（2013-2016） ​

代表性工具：Flask 手写 HTTP 接口、Cron 批处理脚本、scp/U 盘复制权重文件。

那时的典型做法：训练完把 .pth 或 .h5 文件手动拷到一台服务器，写一个几十行的 Flask 应用 model.load_state_dict() 后 predict()，再用 supervisor/nohup 挂着跑。批处理场景则写 Shell + Python 脚本，每天 Cron 跑一轮。

当时的痛点：

  • 不可复现：环境靠「那台机器上碰巧装了什么」，换一台机器就挂。
  • 无并发：Flask 多线程直接抢 GPU，请求一多就排队超时，没有批处理（batching）概念。
  • 无监控无回滚：挂了就挂了，最多看一眼日志；想换版本等于重来一遍。
  • 升级即灾难：框架版本一升级，依赖全崩，谁都不敢动。

关键转折：当深度学习从「实验室玩具」变成「推荐、搜索、语音等产品的在线组件」时，手写脚本的脆弱性第一次成为业务瓶颈。业界意识到：模型上线需要的不是「跑起来的代码」，而是「能管理的系统」。

三、第二代：服务框架时代（2016-2018） ​

代表性工具：TensorFlow Serving（2016）、TorchServe（2018）、Seldon Core（2018）、模型格式开始标准化（ONNX 2017）。

TensorFlow Serving 是第一个把「模型服务」做成产品级框架的软件：它带来了模型版本管理（模型路径即版本）、热加载新版本、动态批处理（dynamic batching） 和 gRPC 接口，2018 年随 TensorFlow 一起成为主流。TorchServe 则是 PyTorch 阵营 2018 年的回应，官方出品，补齐了 PyTorch 生态的服务化短板。

当时的痛点：

  • 框架锁定：TFServing 只能服务 TensorFlow 模型，PyTorch 模型得等 TorchServe，跨框架迁移成本极高。
  • 单机天花板：早期框架大多面向单机多卡，跨机器、多副本的流量调度要自己写。
  • 部署 ≠ 服务：框架只解决了「服务」这一段，镜像、发布、扩容、监控还得自己拼，远未自动化。

关键转折：2017 年 ONNX（Open Neural Network Exchange）出现——「模型格式」第一次与「框架」解耦。同一个 ONNX 文件可以被多个运行时执行，这为下一时代的「引擎竞赛」埋下了伏笔。模型格式的演进详见 模型格式。

四、第三代：云原生与引擎竞赛（2018-2022） ​

代表性工具：ONNX Runtime（2018）、NVIDIA TensorRT（长期迭代）、NVIDIA Triton（2018）、Kubernetes + KServe（KServe 前身 KFServing 2020）、Serverless（SageMaker Serverless、Knative）。

这一代有两条并行线：

线 1：推理引擎军备竞赛。 ONNX Runtime 以跨平台 + 图优化 + 多后端（CPU/GPU/DirectML 等）快速抢占市场；TensorRT 则用层融合（layer fusion）、FP16/INT8 量化把 NVIDIA GPU 上的性能推到极限；Triton 另辟蹊径——它不自己做算子，而是统一调度多框架引擎（TensorRT、ONNX Runtime、PyTorch、TensorFlow 都能挂进去），同时提供高吞吐的批处理与并发模型管理。三条路线的对比见 推理引擎对比。

线 2：部署形态云原生化。 Kubernetes 成为部署底座，KServe（前身 KFServing）把「模型服务」做成了 K8s 原生资源：一键多副本、自动伸缩（HPA）、灰度发布、Serverless 按流量扩缩容（缩到 0）。部署不再是「运维脚本」，而是「声明式资源」。

当时的痛点：

  • 多引擎碎片化：TensorFlow 模型、PyTorch 模型、老模型各要一套服务，运维成本爆炸。
  • GPU 利用率低：固定副本数要么峰值打满要么闲时空转，Serverless 与自动伸缩应运而生。
  • 部署与训练脱节：模型从训练到上线要手工转格式、手工配环境，MLflow 等模型注册与 MLOps 流水线 因此成为标配。

关键转折：推理从「把模型跑起来」变成「把 GPU 榨干 + 让平台自管理」。性能与成本的精细化，成为部署工程师的核心战场——这条路一直延续到今天，详见 性能优化。

五、第四代：LLM 推理时代（2022-至今） ​

代表性工具：vLLM（2023，论文见 vLLM 论文）、TGI（Hugging Face）、TensorRT-LLM、SGLang、Triton 的 LLM 后端。

大语言模型（LLM）把推理的约束彻底改写：模型巨大（7B-70B+ 参数）、生成长（一次请求产生上千 token）、显存极度敏感。自回归解码（autoregressive decoding）意味着每个 token 都要跑一次前向，且必须串行生成，传统「一次请求一个 batch」的静态批处理完全失效。

这一代的核心创新都围绕「让 GPU 在生成时也保持满载」：

技术解决什么效果量级
连续批处理（continuous batching）静态批处理等最慢的请求，GPU 空转吞吐提升可达数倍至一个数量级
PagedAttention / KV Cache 管理长序列的 KV Cache 显存碎片化、浪费显存利用率显著提升，见 vLLM 论文
投机解码（speculative decoding）自回归逐 token 太慢生成速度提升约 2-3 倍
前缀缓存（prefix caching）共享 prompt 前缀重复计算命中时延迟大幅下降

理解 LLM 推理的三个新变量

传统 CV/NLP 推理的瓶颈是单次前向耗时；LLM 推理的瓶颈是 KV Cache 显存、生成长度和批内动态性。这三者的系统后果是：调度器（scheduler）第一次成为推理系统的核心组件——「先给谁算、批多大、Cache 怎么放」直接决定吞吐。这部分完整展开在 LLM 推理。

当时的痛点：LLM 服务贵到离谱、慢到用户流失；用传统引擎部署 LLM，GPU 利用率常不到 20%。转折是软件层解耦：vLLM 这类「引擎 + 调度 + 服务」一体化框架，让部署 LLM 从「运维难题」变成「一条命令」，同时也把连续批处理、显存优化带成了整个行业的标准能力。

六、部署形态的演进：从物理机到边缘 ​

十年间，部署形态（deployment footprint）沿着「更轻、更近、更弹性」的方向演进：

时代部署形态代表技术优点代价
2015物理机/虚拟机裸机 + supervisor简单扩缩容慢、资源浪费
2017容器Docker可复现、环境隔离调度仍需手工
2019容器编排Kubernetes + KServe自愈、弹性、声明式运维复杂度高
2021ServerlessKnative、SageMaker Serverless按需扩缩、缩到 0、成本最优冷启动延迟
2019-边缘部署TensorRT、OpenVINO、Jetson低延迟、离线可用硬件受限、更新难

边缘与 Serverless 的选型权衡详见 部署模式，边缘实战见 TensorRT 边缘部署。

七、历史规律总结 ​

回看十年，四条规律清晰可辨：

  1. 平台化：从「每模型一套脚本」到「平台统一接入」。TFServing → Triton → KServe，都是把重复劳动固化成平台能力。
  2. 标准化：模型格式（ONNX）、接口协议（gRPC/HTTP）、镜像规范（OCI）、编排标准（K8s）层层标准化，让「换引擎、换机器」成本趋近于零。
  3. 性能军备竞赛：从图优化、量化到连续批处理，每一代都把「单位 GPU 的产出」往极限推，性能工程师的稀缺性始终在涨。
  4. LLM 重新定义边界：调度器、KV Cache、前缀缓存成为新基础设施——当模型本身变成瓶颈时，系统的胜负手就在引擎与调度上。

读史的价值

部署面试的最高频问题之一是「为什么选 vLLM 而不选 Triton」或「ONNX 和 TensorRT 是什么关系」。答好这类题靠的不是背文档，而是知道它们各自属于哪个时代、解决了哪个痛点。这套背景现在你已经有了——去 框架对比 把结论落到选型表上。

延伸阅读 ​

参考资料 ​