大模型推理部署实战：从量化到连续批处理的性能优化指南

做了两年多的大模型高效推理与部署技术实战我最大的感受是模型训练只是开始真正让模型产生价值的是后面那段路。很多人拿到一个开源基座模型在单卡上能跑起来就以为完事了结果一测延迟、一压并发漏洞百出。这篇文章我不打算讲训练也不会把Transformer结构翻来覆去地推公式而是聚焦于“如何把一个大模型高效、稳定、低成本地部署到生产环境”这一件事。适合谁看你刚从训练切到推理部署想搞懂量化、KV Cache、批处理这些概念或者你已经能跑通demo但被显存、延迟、并发问题折磨过这篇会非常对胃口。1. 先搞清楚大模型部署难的根源在哪里1.1 训练和推理是两种完全不同的工程问题很多从算法转工程的同学初期会不适应因为他们习惯用训练的思路看推理。训练阶段我们关心的是收敛速度和GPU利用率一批batch可以很大跑一个step哪怕花几秒都没关系反正最后看的是loss曲线。但推理阶段完全相反在线服务的用户等不了几秒才收到第一个token后台的并发可能同时来几十上百个请求每一毫秒的延迟都会变成真金白银的机器成本和用户体验损失。打个比方训练像是印刷厂批量印书印一万本分摊下来每本成本很低推理像是现场答疑每个人问的问题都不同你必须一个一个回答还要尽量让对方少等。这个根本差异决定了技术选型训练堆算力、拉大batch就够了推理则要反复优化“单次响应时间”和“单位显存能同时服务多少人”。还有一个隐藏差异是访存瓶颈。Transformer前向推理时每一层都要读取全部权重矩阵做矩阵乘法一个7B参数的模型光是权重就有14GBFP16而一次推理实际需要的计算量相对固定。GPU的算力很强但显存带宽往往跟不上很多场景下推理速度不是被“算力”卡住而是被“搬运权重”卡住。这也是为什么后面所有加速手段本质都在想办法减少权重的搬运量。1.2 先看三个数字延迟、吞吐、显存占用部署大模型团队里必须统一一套度量口径不然后面所有优化都是各说各话。我建议从三个数字入手。第一个是延迟细分为首Token延迟TTFT和单Token生成延迟TPOT。TTFT是用户从发出请求到收到第一个输出字的耗时决定“有没有反应”TPOT是随后每生成一个字需要的耗时决定“读起来顺不顺”。假设一个回答要输出1000个tokenTTFT是600msTPOT是30ms那么用户感知的总时间就是600ms 1000 * 30ms 30.6秒。如果TPOT从30ms变成60ms总时间直接飙到60.6秒体验天差地别。所以不要只看端到端总耗时要把TTFT和TPOT分开测。第二个是吞吐常用单位是“每秒生成token数”或“每秒处理请求数”。吞吐和延迟通常是矛盾的并发越高每个请求分到的资源越少单路延迟越差但整体吞吐会上升。生产环境要的不是单纯“快”而是“在可接受的延迟范围内尽量多接请求”。第三个是显存占用。部署一个模型显存里放三样东西模型权重、KV Cache、中间激活值。7B模型FP16权重约14GB看起来一张24GB的卡放得下但一旦并发上来KV Cache会迅速膨胀可能比权重还大。我在后面的章节会给具体计算公式这里先记住一个原则看显存不能只看“模型多大”要看“模型并发上下文长度”三者叠加后的峰值。这三个数字对应三类业务问题延迟决定单用户体验吞吐决定服务成本显存决定硬件预算。上线前把这三张表拉出来谁能说服谁就清楚了。1.3 部署场景决定优化方向同样是部署一个大模型不同业务场景的优化优先级完全不同别指望一套方案通吃。在线对话类应用最看重TTFT和TPOT用户已经养成了“秒回”预期。这类场景适合做连续批处理、KV Cache复用、尽量压低单请求延迟。即使吞吐稍微低一点也不能让P99延迟太难看。离线批量任务比如深夜跑一批文档摘要、数据清洗、批量标签生成用户不关心单条多快只关心总耗时和成本。这类场景可以把batch拉到很大甚至牺牲单条延迟换取吞吐让模型在一个batch里尽可能处理更多请求。边缘和端侧部署则是另一套逻辑设备显存小、功耗敏感、网络不稳定。这种情况下INT4量化几乎是必选项有时还要配合剪枝和蒸馏甚至直接换一个更小的模型。端侧跑大模型不是把数据中心那套搬过去而是要重新做一遍“资源约束下”的取舍。明确场景后再选引擎、选量化精度、选并发参数才不会南辕北辙。2. 高效推理的核心技术拆解2.1 权重量化用INT8/INT4换速度与显存量化是推理部署里性价比最高的优化手段之一。核心逻辑很简单原本用FP16表示的每个权重占2字节换成INT8占1字节换成INT4只占0.5字节。所以7B模型FP16权重14GBINT8约7GBINT4约3.5GB。显存降下来了搬运权重的字节数也降下来了访存瓶颈明显缓解。但量化不是白拿的好处。权重精度降低后模型输出的质量会有轻微下降尤其是复杂推理、数学、多轮对话这类任务。实际项目中通常的做法是大模型尽量用INT4/INT8小模型如果质量损失明显就退回FP16对业务关键指标做AB测试不要只看一两个评测分数。量化的粒度也有讲究按Tensor、按Channel、按Group量化效果差很多。目前业内常用的AWQ这类方案会根据激活值分布自动选择更重要的权重通道用更高精度保护它效果比朴素量化好不少。还有一个常被忽略的点不仅权重可以量化KV Cache也可以量化。长上下文场景下KV Cache会吃掉大量显存把它从FP16降到INT8能腾出接近一半的缓存空间相应地就能提升并发或者支持更长的上下文。不过KV Cache量化对质量更敏感需要谨慎验证。2.2 KV Cache和自回归解码的隐藏瓶颈大模型生成文本是自回归的每次只能生成一个token然后把新的token拼到输入末尾再跑下一次前向。如果不做缓存每生成一个token都要重新计算之前所有token的中间状态计算量随序列长度线性膨胀生产环境根本没法用。KV Cache就是用来避免这种重复计算的。它把每个token在每一层产生的Key和Value缓存下来后续生成时只计算新token对应的部分。问题是KV Cache占用的显存非常惊人。计算公式可以简化成这样KV Cache大小 2 × 层数 × 注意力头数 × 每个头的维度 × 序列长度 × batch大小 × 每个元素字节数。我算过一个实际例子假设一个模型有32层32个注意力头每个头的KV维度是128FP16同时服务8个请求每个请求上下文长度2048。那么KV Cache大小 2 × 32 × 32 × 128 × 2048 × 8 × 2字节约8GB。这个数字和7B模型的14GB权重放在一起已经非常可观。如果上下文长度翻倍到4096KV Cache直接变成16GB一张24GB的卡很容易爆。这也是为什么新模型都在用GQA这类分组注意力机制目的就是减少KV Cache的体量。推理框架方面vLLM之所以快很大程度得益于它把KV Cache切成固定大小的块来管理按需分配避免了传统静态缓存预留带来的浪费和碎片。这个概念叫PagedAttention类比操作系统的分页内存管理本质是“按页分配、动态续租”用极小的代价换来了更高的显存利用率。理解自回归之后就会明白推理过程天然分为两个阶段prefill阶段处理用户输入的整段prompt计算量大、耗时集中decode阶段逐个生成token计算量小但极度依赖访存和KV Cache。优化方向完全不同prefill靠几何级并行算力decode靠减少访存和增加有效batch。2.3 连续批处理把GPU利用率拉满的秘诀传统批处理有一个很笨的做法等到攒够一批固定数量的请求再一起处理批次内所有请求一起开始、一起结束。问题在于如果批次里A请求的答案只有50个tokenB请求的答案有500个tokenB会拖住整批直到全部完成空出的显存和算力全浪费了。连续批处理Continuous Batching彻底改掉了这个模式。它不再以“整个批次”为单位调度而是以“一个token生成步骤”为单位调度。具体来说每个请求独占一个逻辑槽位某个请求生成结束后这个槽位立刻释放新请求马上补进来不需要等整批结束。GPU永远在处理不同进度、不同长度的请求像一个餐厅里每张桌子吃完就翻台而不是等所有客人统一离场。实际使用时连续批处理对吞吐的提升非常明显尤其在请求长度参差不齐的在线场景。但它也有代价调度频率变高框架本身的逻辑更复杂如果某类请求特别长仍然会占用大量KV Cache挤压其他请求。所以生产环境还要配合最大并发数、最大序列长度、排队策略一起控制。2.4 投机采样看起来“偷懒”但很有效的加速方法生成一个token要跑一次模型前向前向速度看着不快所以有人想了个“歪招”大模型生成要不要先让一个小模型猜几个token再用大模型一次性校验如果猜对了一个前向就能确认多个token的合法性相当于一个生成步骤“白赚”了好几个tokendecode阶段耗时立减。这个思路就是投机采样。它不改变最终输出分布只是在保证质量的前提下减少解码步数。实际收益取决于小模型的猜中率猜得越准加速比越高。我看过一些场景在短文本和常见句式上用投机采样能把TPOT压到原来的三分之一。实现上可以绑定一个额外的草稿模型也可以用一个模型内部的提前退出分支。要注意的是投机采样不是所有场景都有效。当输出内容高度不确定、逻辑跳跃很大时小模型猜不中就会反复校验反而增加开销。另外额外部署草稿模型也有显存和工程成本。它更适合在线低并发、单路延迟敏感的场景离线高吞吐任务里不如把batch拉大实在。3. 部署方案选型模型、硬件、推理引擎怎么配3.1 推理引擎选择和对比当前开源推理引擎不少我简单说一下常见选择的适用边界。vLLM是目前GPU服务端部署里口碑最稳的方案之一特色就是PagedAttention加连续批处理吞吐高、并发能力强而且对外提供标准HTTP接口接入成本低。适合在线高并发场景也适合快速搭建一个可用的推理服务。它的缺点是对某些自定义模型结构支持需要额外适配版本迭代频繁有时升级会带来兼容性变化。llama.cpp走的是另一条路主打轻量化和跨平台甚至能在纯CPU环境跑。它的显存占用极低适合端侧设备、MacBook、无GPU服务器这类场景。缺点是GPU大规模高并发能力不如vLLM功能丰富度也一般。还有一些专用推理后端针对特定型号的GPU做深度优化性能上限往往是最高的。但这类方案通常和硬件绑定较深部署和运维复杂度也高适合对性能压榨到极致的大型生产集群不适合小团队一上来就踩坑。我自己的建议是第一套方案优先用vLLM因为它最容易跑通、社区大、问题好查等业务真的到了需要极限性能或者特殊硬件优化的时候再评估专用后端。不要一开始就在“极致性能”上耗费大量工程时间先把服务跑稳更重要。3.2 显存估算与硬件选型硬件选型不能只看“模型多大”我通常按下面的公式估算显存需求总显存 ≈ 模型权重 KV Cache 激活值 框架冗余激活值一般占几个GB可以先忽略或者按1-2GB估算。权重按精度换算7B模型FP16约14GBINT8约7GBINT4约3.5GB。KV Cache按照上一节的公式估算取决于并发数和序列长度。框架冗余通常是预留10%的显存防止碎片和临时峰值。举例来说如果我要部署一个7B模型INT8权重占7GB希望支持8路并发、上下4000左右KV Cache可能要5-6GB再留一点冗余合计约15GB。那么一张24GB单卡勉强够用。如果把模型改成INT4权重降到3.5GBKV Cache不变合计约10GB同一张卡能支撑的并发数就上去了。多卡并行方面常用的张量并行可以把权重切到多张卡上但卡间通信会成为新的瓶颈。7B模型通常单卡搞定13B可以看显存情况70B级别才需要认真考虑多卡方案。我的经验是能用单卡就不用多卡多卡带来的通信开销和工程复杂度远高于想象。3.3 服务化封装与对外接口设计部署大模型不是把引擎跑起来就行还要让业务方方便调用。现在主流做法是封装成HTTP服务接口设计尽量兼容业界常见的Chat格式请求里包含prompt、max_tokens、temperature等参数返回内容支持流式输出。流式输出非常重要用户第一句话能很快显示出来体感会比等完整回复好很多。接口下面要做三件事。第一设置合理的超时和重试策略。大模型单次请求耗时可能几十秒网关超时绝不能按普通接口的几秒来配置。第二健康检查接口要和推理引擎的状态绑定不能只检查进程活着。最好暴露模型是否就绪、当前排队长度、显存占用等状态。第三限制单请求的max_tokens上限防止用户传入一个极大的生成长度把整个服务的KV Cache拖垮。服务化本身的技术栈并不复杂复杂的是把并发控制、排队、监控这些生产细节处理好。一个能跑通的Demo和能扛住线上流量的服务差别往往就在这些细节上。4. 手把手部署一个高效推理服务4.1 环境准备和模型就绪在一套全新环境里我习惯先用Docker把运行时固定下来。大模型部署最烦的就是依赖冲突用容器镜像把PyTorch版本、CUDA版本、推理引擎版本一起锁住换机器也能复现。模型准备方面先确认权重格式和分词器是否齐全尤其是chat版本的模型一般自带对话模板和特殊token服务化时会自动套用。如果要用量化版本可以直接下载已经量化好的权重也可以自己对原始权重跑一遍AWQ这类量化脚本。自己量化需要准备一份校准集校准集内容要和你的业务接近不然量化后效果会偏差。准备环境时还需要检查GPU驱动和CUDA版本是否匹配。很多启动失败的案例根本不是模型问题而是驱动和PyTorch要求的CUDA版本对不上。先跑一个简单的矩阵乘法脚本验证GPU可用再启动推理服务能省掉大量排查时间。4.2 启动推理服务最小可用配置以vLLM为例一个最小可用启动命令大概是这样的python -m vllm.entrypoints.api_server \ --model ./models/my-7b \ --tokenizer ./models/my-7b \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --quantization awq \ --max-num-seqs 64 \ --port 8000逐个解释关键参数。--model和 --tokenizer 指定模型路径要确保模型权重和分词器都放在本地避免每次启动都去远程拉取既慢又不可控。--tensor-parallel-size 表示张量并行卡数单卡部署就是1。除非模型单卡放不下否则不建议开大。--max-model-len 是模型能处理的上下文最大长度包括输入和输出。设得太长会让KV Cache预留空间变大实际并发能力下降设得太短又会截断用户内容。要根据业务实际内容长度来定。--gpu-memory-utilization 控制推理引擎最多使用多少比例的GPU显存剩余部分留给其他任务和系统开销。我一般用0.9不要设成0.95以上很容易在并发波动时撞上显存天花板。--quantization awq 表示使用AWQ量化权重。如果模型本身就是FP16就不需要这个参数。--max-num-seqs 限制同时处理的序列数。这是并发上限不是越大越好要根据显存容量来调后面会专门讲崩溃问题。启动完成后先用curl发一个简单请求验证curl http://localhost:8000/generate \ -H Content-Type: application/json \ -d {prompt: 用一句话解释什么是缓存, max_tokens: 128, temperature: 0.7}如果返回正常文本说明最小链路已经跑通然后才是性能和并发调优。4.3 性能测试和关键调优参数跑通之后不要急着上线先做一次完整的性能摸底。我常用的方法是写一个Python脚本用线程模拟不同并发数统计TTFT、TPOT和总吞吐。先测单路确认没有明显延迟问题再逐步增加并发观察P50和P99。调优有几个关键参数值得反复试。一是max-num-seqs。它直接决定KV Cache上界。并发数提上去吞吐往往提高但单个请求的TPOT会变慢因为算力和带宽被分摊了。如果P99延迟超出预期就往下调。这个参数需要做一组对照实验而不是拍脑袋定。二是gpu-memory-utilization。设得太低浪费资源设得太高容易OOM。0.9只是一个起点如果并发压测时频繁报显存不足可以考虑降到0.85同时把max-num-seqs降下来。三是量化精度。同一个模型FP16和INT4的延迟表现完全不同但业务质量也可能不同。这里没有统一答案必须用你的业务数据集做AB测试选一个“质量和性能综合最优”的组合。四是max-model-len。很多团队习惯把8K、16K甚至更大设到最大结果KV Cache爆炸并发只能开到很小。如果业务实际只有2K上下文就要果断把它设成2K或4K省下的显存全都可以兑换成并发能力。性能测试完要沉淀一份基线数据包括模型名称、精度、参数配置、TTFT、TPOT、吞吐、显存峰值。这组数据以后每次改动都拿来对比能很快看出优化是正向还是负向。4.4 生产环境运维要点推理服务上线后的运维比起普通后端服务多了一层“显存和排队”的维度很多故障表现很隐蔽。首先是监控指标。除了常规的CPU、内存、QPS还一定要看GPU显存利用率、GPU利用率、排队请求数、TTFT和TPOT分位数。我见过GPU利用率很高但TTFT也飙升的情况原因是请求都挤在prefill阶段抢算力decode阶段的响应反而被拖慢。光看一个指标会误判。其次是弹性伸缩。大模型服务不能简单地看CPU使用率扩容更合理的信号是排队长度和TTFT。如果排队请求超过阈值且TTFT明显恶化就再拉起一个新副本如果长期空闲就缩容。多副本之间没有状态关联扩容很方便但要注意把模型权重放在共享存储或提前预热到本地磁盘否则新副本启动会非常慢。第三是版本和回滚。模型参数、推理引擎版本、量化方式都会影响线上效果任何改动都要有明确的版本记录。我习惯把每个模型版本打包成一个独立的可部署目录里面包含配置文件和启动脚本回滚时直接切换目录重启。5. 实战中踩过的坑和排查手册5.1 显存OOM最经典的翻车现场大模型部署遇到最多的故障就是CUDA OOM而且往往不是启动时报错而是跑了一会儿、并发一上来才爆。典型的故障链路是模型权重14GBKV Cache按max-num-seqs和max-model-len预留本来算得好好的结果某个用户请求的prompt特别长生成长度又大动态KV Cache瞬间超过预留空间直接OOM。排查的时候先看两个数max-num-seqs和max-model-len。它们的乘积决定了KV Cache的极端上界。如果max-num-seqs64max-model-len8192KV Cache可能会占到几十GB显存必然不够。解决办法就是降并发、缩短上下文上限、或者改用INT4权重释放空间。还有一个常见坑是环境里残留了之前的推理进程显存被占着看不到。启动前执行进程检查确保没有僵尸GPU进程。另外如果用了多个推理副本跑在同一张卡上也会互相挤兑。5.2 首Token慢、生成Token慢瓶颈定位法同样一个模型别人部署TTFT只要200ms你那边却要800ms这就要分阶段定位。TTFT慢重点看prefill阶段。输入prompt越长prefill的计算量越大TTFT自然越慢。如果prompt很短TTFT依然慢通常是模型权重精度太高、GPU算力不够、或者框架没有用上连续批处理。可以试试换成INT4/INT8量化或者在多卡间做张量并行。TPOT慢重点看decode阶段。decode每个token的计算量不大瓶颈主要在显存带宽和KV Cache访问。如果显存带宽没跑满可能根本原因是batch太小GPU没有足够的并行度如果KV Cache太大访问局部性差也会拖慢速度。投机采样在这个阶段往往能发挥奇效。还有一种隐蔽的慢发生在tokenizer文本处理这类CPU环节。如果每次请求都要做特别复杂的模板拼接CPU消耗过高也会拉长整体延迟。可以单独压测tokenizer排除这个因素。5.3 量化后效果变差怎么找回质量很多人量化完一测发现模型说话开始颠三倒四第一反应就是“量化有害还是换回FP16”。但实际项目里量化出来的效果差距往往和量化方式、校准数据紧密相关是可以挽救的。先检查校准集。AWQ这类量化方案需要一个校准集来统计激活分布如果你的校准集是新闻摘要线上跑代码生成分布差异太大量化后效果自然差。把校准集换成贴近业务的样本重新量化通常能改善一大截。再看量化粒度。某些模型对激活值异常敏感粗糙的按层量化会损失太多信息。尝试支持更细粒度量化的配置或者对特定敏感层保留FP16精度效果也会更好。最后是评估方法。量化后模型在通用评测集上的分数可能只掉一两个点但在你业务的高难度样例上可能明显退步。一定要建立自己的业务评估集包含典型场景和边界case量化前后都跑一遍再决定是否接受。5.4 并发高时排队、超时怎么办服务并发一高最直接的反馈就是响应变慢、客户端超时。这时候先看排队数如果排队很长说明推理引擎处理速度小于请求到达速度需要扩容或者限流。常见的做法是给服务加排队策略让短请求优先避免被几个长请求堵死。vLLM这类框架本身会做调度但你也可以在上层网关控制最大并发数超过阈值就返回429或者进入等待队列。流式输出也是一个缓解手段。就算生成时间没有缩短但只要用户可以边看边等主观体验会好很多。这个改动不需要换引擎只需要客户端支持SSE流式解析。还要检查客户端的超时配置是否合理。大模型接口的合理超时往往要设置在60秒以上如果网关层的超时只有5秒再快也白搭。上线前一定要打通全链路超时配置避免网关比模型还“着急”。问题现象排查方向常用解法启动后并发请求显存OOMmax-num-seqs和max-model-len过大调低并发上限和上下文上限单请求TTFT慢prefill阶段算力或长prompt量化权重、加张量并行单请求TPOT慢decode阶段访存或batch过小提升并发、投机采样量化后回答质量下降量化粒度或校准集不匹配细化量化、换校准集、业务AB测试高并发超时排队过长或网关超时配置扩容、限流、流式输出、调大超时时间6. 我在反复部署中的几点实在体会6.1 别把“能跑”当“能上线”刚开始接触部署时我也犯过一个错误模型能在单卡上正常生成文本就觉得项目已经完成了。结果同事一压并发单卡最多同时处理两三个请求稍微长一点的回答就开始超时。后来我才养成了一个习惯任何模型交付前都必须有一份压测报告写明在什么并发下、什么P99延迟、什么吞吐水平。“能跑”只是起点性能达标才是真正的上线标准。6.2 技术选型要跟着业务走不是跟着新词走圈子里每隔几个月就会出现新的加速框架、新的量化算法看起来每一项都值得追但真正要落地时稳定性和团队熟悉度比最新功能重要得多。我见过有人为了一个性能优势换掉整个推理引擎结果迁移花了两周线上还出现一堆兼容问题得不偿失。现在我的原则是用成熟方案撑住业务把新方案放在独立环境做验证验证充分了再考虑切换。6.3 后续可以扩展的方向推理部署本身也在快速变化。长上下文场景下稀疏注意力、状态缓存复用会越来越重要多模态模型部署要额外考虑视觉编码器的开销端侧部署需要把量化、剪枝、蒸馏结合成一套完整流程。还有成本优化比如把不同规格的模型按任务复杂度混合调度热门模型常驻显存、冷门模型动态加载都能省下不少成本。如果你只记住一句话我会说先把延迟的构成拆清楚再动优化。TTFT慢和TPOT慢是两种完全不同的病量化降的是权重搬运连续批处理提升的是GPU利用率调并发提升的是吞吐每一种技术都有自己对应的“症状”。带着指标去做实验用数据判断每一步改动是变好还是变坏才不会在繁多的新名词里迷路。我后来的每一次部署升级都靠这份“指标锚点”做出取舍少踩了很多坑。希望这套实战思路也能让你少走一点弯路。