做模型部署这几年我最大的感受是部署这件事从来没有像现在这样让人又爱又恨。早些年部署一个 BERT 分类模型起个 Flask 服务套上 PyTorch 就能上线压测不行就加副本日子简单又充实。直到 LLM 推理任务砸到头上原来的那套起服务、接流量、看监控三板斧彻底失灵了——显存怎么都不够、延迟怎么压都压不下去、一道简单的流式输出就能把网关搞到超时。这篇文章想聊的就是从单个模型的常规部署一步步走到 LLM 推理平台这条路上我自己踩过的坑、筛选过的框架以及正式环境里真正管用的架构全景。适合正在从传统 CV/NLP 模型部署转向大模型推理的工程师也适合那些被业务逼着搭推理平台的架构师参考。内容偏实战不太涉及算法训练侧的东西重点放在模型训练完之后怎么稳定高效地跑在生产环境这件事上。1. 为什么单模型服务撑不起大模型时代的流量1.1 传统推理服务的基本盘一次请求、一次前向先把时间拨回到 2020 年前后的常规部署。那个阶段我处理最多的任务是文本分类、实体识别、语义相似度这类判别式模型。部署形态几乎固定TorchServe 或者 TensorFlow Serving 加载一个训练好的模型文件对外暴露 HTTP/gRPC 接口客户端传一段文本进来服务端做 tokenize、前向计算、后处理返回一个分类结果或者一组向量。这整套链路有一个隐含前提一次请求对应一次确定性的计算。请求之间互不干扰显存占用基本等于模型参数加激活值吞吐不够就横向扩容多挂几个 Pod 就完事了。静态批处理也简单把多个请求攒到一起模型一次前向算完单位时间吞吐量就上去了。传统推理框架的优化重心普遍放在这里减少单次前向的耗时、提高 batch 利用率、压低框架本身的调度开销。这套模式在判别式模型上非常够用。但一旦换成交互式文本生成也就是 LLM 的典型用法情况就完全变了。生成不是一次前向而是逐 token 生成生成多少个 token 就要做多少次前向。而且每一次前向都依赖前面所有 token 的中间结果这个中间结果就是常说的 KV Cache。请求越长KV Cache 越大它占的显存甚至能超过模型参数本身。1.2 LLM 推理的三个量变引发质变第一个质变是显存模型变了。传统模型部署看的是参数大小比如一个 7B 模型 FP16 权重约 14GB算上激活值预留 18~20GB 显存就够了。LLM 部署还得单独算 KV Cache7B 模型、4096 上下文、每请求 512 字节显存预算单用户并发一高显存立刻吃紧。更让人头疼的是不同请求的生成长度不一样显存分配没法提前固定分配少了会 OOM分配多了整卡利用率又难看。这就是为什么第一代 LLM 推理框架都在 KV Cache 管理上做文章vLLM 的 PagedAttention 就是典型代表思路类似操作系统内存分页按需分配、动态扩展把显存碎片和浪费压下去。第二个质变是批处理策略变了。传统静态批处理是攒一批、算一批所有请求一起开始、一起结束。LLM 场景里请求的生成长度差异巨大有的问一句你好就结束了有的要生成上千 token。静态批处理会让短请求傻等长请求GPU 利用率上不去。后来业界普遍换成了 continuous batching连续批处理一个请求生成完了空出来的位置立刻让新请求顶上GPU 一直在算不会有整批空转的情况。这个机制是 LLM 推理引擎性能的分水岭也是调度复杂度的主要来源。第三个质变是延迟指标变了。传统服务的延迟是请求进来到响应返回的一个标量LLM 服务必须拆成两个指标TTFTTime to First Token首 token 延迟和 TPOTTime per Output Token每输出一个 token 的耗时。用户体验主要取决于 TTFT不能让用户盯着空白页面干等而 TPOT 决定了生成速度俗称每秒蹦出多少个字。这两个指标此消彼长同一个服务不可能同时做到 TTFT 极低和 TPOT 极快需要按业务场景做取舍。这也是很多新手部署 LLM 时最不容易想明白的一点——你用传统服务的眼光看监控全是异常其实是没建立正确的指标坐标系。1.3 生产环境真正的分水岭吞吐与延迟的取舍部署框架选型时最核心的一个问题就是你服务的业务到底更看重吞吐还是延迟面向 C 端的产品比如聊天助手、客服机器人要求响应快TTFT 最好控制在 500ms 以内TPOT 也要接近人眼流畅的程度这类场景就得牺牲一部分吞吐用小 batch 或动态批处理来控制排队时间。面向内部工具、离线批量生成、数据标注辅助吞吐优先延迟可以放宽到秒级甚至十秒级这时可以把 batch 拉大用高并发把 GPU 利用率顶满。就我自己的经验来说很多团队在这个问题上没想清楚就上了框架结果就是要么用户抱怨转圈太久要么 GPU 利用率只有百分之十几还天天 OOM。部署框架不是越先进越好而是先明确业务约束再谈架构选型。2. 单模型服务的正确打开方式框架选型与踩坑记录这一节先回到单模型服务本身。尽管大模型平台是当下的热点但绝大多数团队手里还有一批传统模型在线上跑着把它们维护好同样重要。而且单模型服务里积累的不少经验放到 LLM 平台里依然适用。2.1 TorchServe、TensorFlow Serving 与 Triton 的适用边界先说 TorchServe。PyTorch 生态的官方服务框架优点是和 PyTorch 模型无缝衔接支持自定义 handler适合快速上线、模型迭代频繁的团队。缺点也明显它对高并发和 GPU 利用率的优化比较弱动态批处理能力有限模型多的时候资源隔离做得不够细。我用它部署过不少短文本模型体量小、逻辑简单够用且省心。TensorFlow Serving 我没实际碰过但团队里有同事长期维护用 TF 训练的排序模型它的优势在于 TensorFlow 生态的成熟度和 SavedModel 格式的标准化适合纯 TF 技术栈。缺点是对 PyTorch 模型支持基本靠转换维护成本比较高。真正让我觉得上线后可以几个月不管的是 NVIDIA Triton Inference Server。它最大的价值不是单模型性能而是统一了多框架、多模型的管理同一个进程里可以同时跑 PyTorch、TensorRT、ONNX Runtime 的模型每个模型独立配置并发数、批处理参数、显存预算还能做模型版本管理、动态加载卸载。如果团队里模型形态五花八门Triton 几乎是必选项。2.2 模型格式与运行时ONNX、TensorRT 与国产硬件的适配单模型服务部署绕不开模型格式转换。PyTorch 的 .pt/.pth 文件直接扔给 TorchServe 没问题但真要压性能绝大多数场景还是得转 ONNX 或者 TensorRT。ONNX 的最大价值是中间格式它不直接带来推理加速但解决了部署链路碎片化的问题。模型转成 ONNX 后可以用 ONNX Runtime 跑也可以再转成 TensorRT 引擎跑还能在部分国产加速卡上直接加载。需要注意的是ONNX 导出时最容易出问题的是动态维度模型训练时输入长度固定导出 ONNX 时把维度写死了推理时稍微变长就报错。我的经验是导出时务必指定 dynamic_axes把 batch 维和序列长度维都设为动态否则部署阶段会被各种奇葩输入折腾到怀疑人生。TensorRT 则是把加速做到极致的选择FP16 下通常能比原始 PyTorch 快一倍以上配合 Triton 使用效果最好。但 TensorRT 有两个劝退点一是转换时间以小时计模型版本迭代快了根本等不起二是它对动态 shape 的支持比 ONNX 更苛刻转换时就要定好 max batch、max sequence之后超出就没商量。所以我的做法一直是线上稳定版本用 TensorRT 保性能新版本先用 ONNX Runtime 顶着灰度转好 TensorRT 再切换。另外如果公司有国产加速卡务必提前确认框架兼容性Triton 对部分国产卡有适配但 ONNX Runtime 和 TensorRT 的生态覆盖差异很大这一块建议在选卡阶段就做好验证别等到部署时才发现驱动、框架全是坑。2.3 单模型服务里的三个经典坑坑一批处理参数拍脑袋。很多人部署 Triton 时 max_batch_size 随便填 32结果高并发下延迟直接爆炸。批处理不是越大越好它依赖模型的前向耗时和请求到达速率。正确做法是压测时逐步加大 batch观察 TPOT 和 GPU 利用率的变化曲线找到边际收益开始下降的那个点。坑二忽略显存碎片。多模型共用一个 Triton 实例时如果模型的输入尺寸波动大显存碎片会越来越严重。Triton 对显存的分配策略不是无限动态增长的必要时得给模型预留独立显存池或者干脆拆成多个实例用资源隔离换稳定性。坑三预处理没做对tokenize 耗时被忽略。小模型往往几毫秒就算完了但 Python 侧做中文分词、正则清洗可能就要花几十毫秒直接成了性能瓶颈。正确姿势是预处理器独立部署或者用 C/Rust 实现的 tokenizer至少也要做进程池并行别让 CPU 预处理拖累 GPU 推理。3. 从单服务走向 LLM 推理平台架构演进的关键节点到了这一步你已经能把单个模型稳定跑起来了。但 LLM 业务通常不是一个模型在战斗对话要用基座模型知识库问答要挂了 RAG 检索内容安全审查还要过一个审核模型。这时候核心问题变成了怎么把一堆推理能力组织成一套稳定的平台而不是怎么部署某一个模型。3.1 网关层路由、限流与多模型编排LLM 推理平台的入口通常不是推理服务本身而是 LLM 网关。这个词在去年的热词榜上很火但很多团队理解得比较简单以为就是个反向代理。真实场景下网关承担的事情远比转发多第一路由。同一个业务可能同时接入多个模型网关要根据用户画像、成本预算、当前负载把请求分发到不同的模型实例上。低成本模型兜底、高精度模型兜复杂请求这是最常见的路由规则。第二限流与配额。LLM 推理资源昂贵不可能让所有用户无限调用。网关层面需要按 API Key、按部门、按应用做配额管理还要区分并发限制和 token 速率限制——前者限制同时处理的请求数后者限制每秒消耗的 token 数两者缺一不可。第三协议转换与兼容。目前主流的做法是让所有推理服务都暴露 OpenAI 兼容接口网关统一承接外来请求内部再根据模型类型做差异处理。这样业务方接入成本极低一个 OpenAI SDK 到处用。我在实际落地中深有体会协议统一这件事做得越早后续接入新模型的成本就越低千万别让每个模型各自定义一套 API 格式。网关选型方面技术功底强的团队可以用 Envoy 之类的通用网关二次开发想要开箱即用的话LiteLLM、Portkey 这类专门的 LLM 网关项目值得关注它们把多模型路由、费用统计、fallback 重试这些高频需求都预置好了。3.2 推理引擎层vLLM、SGLang、TGI 的定位差异网关之下是真正的推理引擎。LLM 推理引擎这两年迭代非常快最常被拿来比较的三个是 vLLM、SGLang 和 Hugging Face 的 TGI。vLLM 是目前社区采用率最高的核心创新是 PagedAttention就是前面说的 KV Cache 分页管理。它的优势是生态好、兼容广几乎所有主流模型都能直接跑OpenAI 兼容服务开箱即用还支持 LoRA 动态加载。我大部分线上模型都是在 vLLM 上跑的稳定性经过了长时间验证。SGLang 的优势在于复杂场景下的调度优化它把 prefill预填充和 decode解码两个阶段拆开调度配合 RadixAttention 做前缀复用在 RAG 这类大量请求共享相同前缀的场景里收益非常明显。如果你有大量 RAG 查询、多轮对话长上下文的需求SGLang 值得重点评估。TGI 的优势是 Hugging Face 生态的原生支持上线早、文档全但性能优化节奏相比前两者稍慢。我的建议是新项目优先 vLLM性能不够再拿 SGLang 做对比测试TGI 则适合那些重度依赖 HF 生态、不想折腾自定义特性的团队。还有一个不得不提的选项是 TensorRT-LLM。它把 TensorRT 的极致性能带到了 LLM 场景支持高度优化的 kernel 融合生产环境吞吐表现经常比 vLLM 高一截。代价是配置复杂、模型转换慢、灵活性差。我的经验是如果 GPU 型号统一、模型版本稳定、追求极致吞吐TensorRT-LLM 值得投入如果模型迭代频繁、环境杂vLLM 是更稳妥的底座。3.3 调度与弹性推理平台不是简单的多副本传统服务扩容就是加 Pod流量来了横向拉伸流量走了缩容。LLM 推理平台的扩容要复杂得多原因有两点。一是显存约束。每个推理实例要预留 KV Cache 的显存空间实例数不是想加就加得看整卡显存是否充足。靠 GPU 利用率做自动扩缩容容易被生成阶段 GPU 打满、空闲阶段 GPU 闲置的假象误导需要结合排队长度、KV Cache 命中率等指标综合判断。二是冷启动。LLM 模型加载动辄几十 GB从新实例启动到对外提供服务可能需要好几分钟流量突增时根本来不及弹性扩容。因此平台的容量规划必须做冗余预算 优先级抢占核心业务预留常驻实例非核心任务允许排队或者走低优先级调度关键时刻能抢资源。这块的架构选型如果团队已经重度使用 KubernetesKServe 这类云原生推理平台可以把部署、扩缩容、监控的体验标准化适合平台化需求明确的团队。如果只是想尽快上线、不想陷入 K8s 运维泥潭用 Docker Compose 加自研调度脚本也能顶一阵子只是后续治理成本会高一些。我的经验是先想清楚平台要支撑多少模型、多少调用量再决定要不要上 K8s而不是为了先进而上 K8s。4. 正式环境的 LLM 推理平台全景拆解这一节把完整平台的各个部件摆出来给一张全貌图。正式环境的推理平台至少包含以下五层。4.1 平台的核心组件从 API 网关到推理池从上到下梳理一遍我这边实际落地的平台结构接入层统一 API 网关负责身份认证、限流、路由、可观测性埋点。所有请求先进网关业务方不直接访问推理实例这是平台治理的第一道边界。控制面模型注册、版本管理、部署配置、扩缩容策略。控制面不参与数据面转发只管哪些模型在哪些实例上以什么配置跑着。模型上线流程在这里定义灰度发布、回滚都在这一层做。推理池一组承载推理引擎vLLM、SGLang、Triton 等的 GPU 实例池。池内实例按模型分组也可按优先级划分核心业务池、批量任务池、实验池。池与池之间资源隔离避免一个高负载任务拖垮线上服务。缓存层这里指两类缓存。一类是 KV Cache 前缀缓存多轮对话和 RAG 场景下重复前缀直接复用能省大量 prefill 计算另一类是结果缓存完全相同的问题直接用缓存答案适合 FAQ 类业务。这一层往往被忽略但优化收益极大。数据面配套日志采集、指标监控、链路追踪。LLM 平台需要比传统服务更细的监控维度见 4.3 节。4.2 Token 经济与成本吞吐优化为什么直接等于省钱大模型部署绕不开成本话题。GPU 昂贵推理平台做得好的团队单位 token 成本可能比做得差的团队低数倍。从我的角度看成本优化的杠杆主要集中在三处。第一是连续批处理的效率。同一个推理引擎batch 策略调得好吞吐可以翻倍甚至更多。批处理不是说调大就行而是要让长短请求合理混批让 GPU 的算力在每个时间片都有人干活。vLLM 这类引擎把这块封装好了但你的并发设置、max_num_seqs 参数仍然直接影响收益需要压测调参。第二是量化。FP16 是安全默认值但显存压力大时可以考虑 INT8、INT4 量化。目前 AWQ、GPTQ 这类量化方案的精度损失在多数场景下可接受换来的显存节省却是实打实的——7B 模型从 FP16 的 14GB 压到 INT4 的 4GB 左右单卡并发能力直接翻几倍。量化不是越多越好建议先在核心场景做离线评测把精度指标跑一遍再决定别只看显存数据。第三是前缀缓存复用。RAG 场景下用户问题的检索结果往往很长每次请求都要对同样的上下文做一次全量 prefill既慢又贵。用 SGLang 的 RadixAttention 或者 vLLM 的前缀缓存能力把高频前缀缓存起来prefill 耗时能大幅下降。这块的收益我在知识库问答场景实测过TTFT 能压掉一半以上值得优先投入。4.3 可观测性GPU 利用率、排队长度、TTFT 与 TPOT很多团队上线了 LLM 服务监控面板还是那几张老图CPU、内存、QPS、P99 延迟。这些指标在 LLM 场景远远不够。我自己的监控面板至少包含四类指标推理质量指标TTFT、TPOT、端到端延迟。这些指标要按模型、按场景分别统计不能混在一起算均值。对话场景看 TTFT 和首屏体验批量生成看 TPOT 和吞吐。资源指标GPU 利用率、显存占用、KV Cache 使用率、显存碎片率。注意 GPU 利用率要区分计算利用率和显存带宽利用率前者高不代表推理快后者才是 decode 阶段真正的瓶颈。调度指标排队请求数、平均排队时长、批处理大小分布、拒绝请求数。排队长度是扩缩容的核心依据比 GPU 利用率可靠得多。成本指标每百万 token 成本、每请求平均 token 数、有效 token 占比生成结果里非填充符的 token 比例。空转的 prefill、生成大量无用 token都是隐形烧钱。有了这套指标平台的问题才能被及早发现。我踩过一个很典型的坑某次线上对话服务延迟飙升看 GPU 利用率是满的以为是模型负载高后来查了 KV Cache 使用率才发现是前缀缓存没命中大家都在重复做 prefill。如果监控面板里没有 KV Cache 命中率这个指标这个问题很难定位。5. 框架选型决策矩阵与我的实测经验5.1 不同规模、不同场景怎么选做了这么多项目我把选型逻辑总结成一张决策表供参考场景特征推荐路径理由单一模型、低并发、快速上线TorchServe / 自研 FastAPI 服务运维简单迭代快多模型共存、框架杂、追求稳定Triton Inference Server统一管理资源隔离好主流 LLM、OpenAI 兼容接口、社区生态优先vLLM稳定可靠生态完善RAG 场景多、长上下文、共享前缀多SGLang前缀复用收益明显版本稳定、GPU 型号统一、极致吞吐TensorRT-LLM性能上限最高规模化平台、多团队共用、K8s 环境成熟KServe vLLM/SGLang标准化、自动化程度高这个表不是绝对标准它的作用是帮你把约束条件列清楚。选型时先回答三个问题模型迭代频率高不高业务流量波动大不大团队有没有 K8s 运维能力三个问题答完方案基本就收敛了。5.2 一次线上问题的完整排查链路分享一个真实案例。某次知识库问答服务上线后监控显示 TTFT 从 300ms 涨到了 2s用户反馈明显变卡。这个问题的排查过程挺有代表性完整链路如下第一步看网关层的限流和路由日志。确认没有限流拦截、请求都正常路由到了知识库问答的模型实例排除网关层问题。第二步看推理引擎的指标。vLLM 暴露的 Prometheus 指标里排队长度的曲线在问题时段持续爬升说明请求到达速率超过了引擎处理能力。但奇怪的是 GPU 利用率此时并不高只有 60% 左右。第三步深挖 prefill 和 decode 的耗时分布。发现 TTFT 的暴涨主要来自 prefill 阶段。进一步看前缀缓存命中率发现从某个版本更新之后系统提示词里加了一段动态时间戳文本导致所有请求的前缀都看起来不同RadixAttention 完全失效每个请求都得全量 prefill。第四步修复。把动态时间戳从系统提示词里挪出去改为生成后注入对话历史中前缀不再变化命中率回升TTFT 降到 400ms 左右。这个案例说明三件事一是 LLM 服务的延迟问题未必是资源问题调度和缓存逻辑往往是真正的瓶颈二是监控指标必须有针对性没有 KV Cache 命中率这类指标排查就靠猜三是系统提示词这类看似无关的细节在 LLM 部署里会引发重大性能差异改动任何提示词都要做性能回归。5.3 一些来自生产环境的实在建议最后分享几条经验都是踩过坑之后才想明白的。先把流式体验做好再谈优化。LLM 服务十有八九需要流式输出。用 SSE 还是 WebSocket、断线重连怎么处理、网关的超时时间怎么配合这些基础体验问题不解决性能优化得再好用户也感知不到。我见过太多团队上来就研究 batch 调参结果前端拿到的还是整个响应体用户对着空白页面干等几十秒。压测一定要用真实流量分布。用固定长度的测试文本压测测出来的指标没有参考意义。真实流量里请求长度、生成长度都服从长尾分布必须用线上采样流量回放压测才能暴露显存峰值和排队波动问题。我们内部专门维护了一套压测流量集每次引擎调参都拿它做基准。正式环境至少要两条模型版本通道。一条是稳定通道承载线上全部流量一条是候选通道新模型先进来做影子流量对比。收益指标延迟、吞吐、成本和效果指标人工评估、离线评测双向对比达标后候选才转稳定。没有这套流程模型上线就永远靠拍脑袋出了问题影响面还特别大。不要迷信单一框架平台层要有抽象。推理引擎迭代太快今天 vLLM 最优明天可能 SGLang 追上来了。我强烈建议平台的数据面通过 OpenAI 兼容协议或者内部统一的推理抽象层来对接引擎这样换引擎只是配置层面的事。我们就是这么做的后来从 vLLM 引入 SGLang 做对比测试只改了一行配置这种灵活性在技术选型快速变化的阶段非常宝贵。5.4 后续可以怎么扩展如果团队规模再往上走平台还可以在三个方向演进一是把模型微调和推理链路打通形成训练到上线的一体化闭环模型迭代周期从周级压缩到天级二是加一层更细粒度的多租户治理按团队、按应用做独立的配额、审计和成本分摊三是把评测体系产品化不只是模型效果评测还要把延迟、成本、稳定性纳入自动门槛每个模型上线前自动跑一遍全套指标。这些不是必选项但对平台而言有了它们才真正具备了规模化的价值。根据我个人在实际部署中的体会模型部署这件事难的从来不是某个框架的某个功能而是把业务约束翻译成技术选型再在选型之上建立起一套可观测、可治理、可演进的体系。单模型服务是起点LLM 推理平台是终点中间这段路上框架会不断更替但先定指标、再选方案、后建流程的方法论不会变。希望这篇全景梳理能帮正在这条路上摸索的同行少走几步弯路。