我之前负责过一个文本生成项目在单卡上跑通的那一刻大家都觉得稳了。结果一放到真实业务里就被打回原形用户发来一段几千字的背景材料模型直接超时GPU显存在生成到一半的时候炸了。后来我才意识到Transformer模型从“能训练、能出结果”到“扛得住真实场景”中间隔着一整条关于效率和资源的路。这第五篇我想写的就是这条路。前几篇我们聊了注意力机制、Encoder与Decoder结构、预训练与微调范式这些都是“把模型造出来”的部分。这篇聚焦的是“把模型用好”的部分推理阶段为什么这么慢、显存去哪了、长文本为什么崩、量化蒸馏到底怎么选。适合已经跑通过Transformer模型、想把部署质量和吞吐提上去的读者也是我自己踩过不少坑之后的系统性复盘。1. 训练跑通只是第一步Transformer落地时绕不开的效率瓶颈1.1 自回归生成的隐形成本一个token一个token地算很多同学第一次接触Transformer推理时会有个错觉模型训练都能跑推理不就 forward 一下吗确实一次 forward 很简单但生成任务不是一次 forward 就结束的。以Decoder-only结构的生成模型为例每生成一个token都要把之前生成的所有token重新喂进去再跑一次完整的前向计算。训练的时候我们做并行化整个序列一次算完矩阵运算噼里啪啦很爽。但推理生成是串行的第t个token没算出来第t1个就无从谈起。这里就出现第一个核心矛盾同一段前缀每次生成下一个token时都要重复计算一遍它的Key和Value矩阵。假设你在生成一篇1000字的文章模型每往前写一个字前面999个字的K和V都得重新算一遍。累计下来的计算量是平方级别增长的。我在项目里实测一个100M参数左右的模型不做什么优化的情况下生成128个token耗时可能还能接受但到了512个token响应时间直接翻了好几倍用户侧体验就是“转圈圈转半天”。1.2 显存不只是用来放模型参数的很多人算显存只会算模型参数占多少7B模型FP16精度下大概14GB于是拿着24GB的卡觉得绰绰有余。但实际一跑生成任务直接OOM。为什么因为推理阶段还有两笔隐藏开销KV Cache的缓存和激活值。KV Cache是自回归生成中为了解决重复计算而引入的缓存机制后面我会单独细讲。这里先看它的显存公式对Decoder-only模型来说每个token的KV Cache显存 2K和V各一份 × 层数 × 注意力头数 × 每头维度 × 每个数值的字节数拿一个7B模型举例约32层每层32个头每头维度128FP16下每个数值占2字节。那么每个token的缓存大小是2 × 32 × 32 × 128 × 2 524,288 字节约512KB听起来单看一个token还好但生成长度为2048的序列光KV Cache就是512KB × 2048 1GB这才只是一条请求。如果做在线服务batch_size8同时处理8个用户请求KV Cache直接吃掉8GB显存。很多7B模型在24GB卡上部署失败不是模型参数装不下而是KV Cachebatch把显存挤爆了。1.3 计算密集与访存密集两个阶段的性格完全不同在深入优化之前还有一个概念必须先厘清Transformer推理的prefill阶段和decode阶段性能瓶颈的本质完全不同。Prefill阶段是用户把整段输入prompt一次性给到模型模型一次性把所有token并行算完。这个阶段是典型的计算密集大矩阵乘法铺满GPU算力利用率能跑到很高瓶颈在FLOPS。Decode阶段则是逐个token生成的阶段每步只需要做一个token的Attention和MLP计算计算量很小但需要把KV Cache里所有历史的K和V读出来做点积。这一步主要花时间在显存带宽上也就是从显存往计算单元搬数据的速度。这个时候GPU算力其实在大量闲置等数据搬运。这两个阶段性格相反所以很多优化要分开做prefill阶段拼算力decode阶段拼带宽和缓存策略。你如果拿着一套固定batch的推理服务扛高并发很可能卡在decode的带宽上而不自知加再多的算力卡都没有用。2. KV Cache省掉重复算Attention的关键机制以及它带来的新麻烦2.1 核心思想历史K和V只算一次存在缓存里上一节提到不使用缓存时每生成一个token前面所有token的K和V都要重算一遍。KV Cache的做法非常朴素第一次算完就把每个历史位置的K和V缓存起来后续每步只计算新token的K和V然后拼接进缓存。这样一来生成第t个token时注意力计算就从“对完整序列做一次QK^T”变成“只对新token的Query去跟缓存的全部Key做点积”。省掉了大量重复矩阵运算。没有KV Cache时生成N个token的总注意力计算量大约正比于N的三次方每步都要算前面所有历史token的注意力每步为O(t×d)累加为O(N²×d)有了KV Cache每个生成步的增量注意力计算基本是常数级总体变成O(N×d)换来了接近一个数量级以上的提速。举个具体数字生成1024个token不缓存时最后一个token的Attention要跟1023个历史token的K和V做运算而且前面每一步都重复过类似的计算。累计下来光Attention部分在缓存前后的计算量差距就是大约上千倍的关系。这也是为什么工业化推理框架把KV Cache列为默认必开的优化不是可选项是没有它就活不下去的那种级别。2.2 多头注意力下的Cache布局为什么维度顺序会坑到你KV Cache不是简单的一个数组它的结构要跟着多头注意力的计算方式走。常见的存储形状是[batch_size, num_heads, seq_len, head_dim]也就是把每个头的K和V分开存。这样在计算新token的注意力分数时可以直接按头切块做矩阵乘不需要频繁做维度permute。这里有个实战里很容易踩的坑如果你自己写推理代码用PyTorch的Tensor拼接KV时要用torch.cat在seq_len那一维上做而不是在batch维度上做。我之前在某次代码里把维度顺序写错了缓存每次拼接都在复制整个历史性能不仅没有优化反而因为内存复制开销变得更慢花了半天才通过profiler定位到问题。KV Cache的存储布局直接决定了推理时能不能走高效矩阵乘以及显存碎片化的程度。2.3 缓存的长度管理动态扩容与预分配KV Cache在生成过程中不断变长。如果每次增长都重新申请一块显存再整体复制会产生大量显存碎片而且复制本身也有开销。常见做法是预分配一个最大序列长度的空间然后通过记录当前长度来访问有效区域。但预分配也不是越大越好。按最大长度一次性分配意味着不管你实际生成多短显存都被占住了。对于线上服务这个“预留浪费”会很可观。有的推理框架会按请求预估长度动态伸缩也有框架用分页式缓存管理把缓存切成固定大小的块哪条请求需要就分配哪一块用完归还。这个思想和操作系统内存分页很像也是现在高性能推理引擎的核心技术之一。我在实际调优中发现KV Cache这块儿特别需要结合真实业务长度分布来配而不是盯着最大长度算。如果80%的请求生成长度在200~400token之间那就按400token去预分配剩下的长尾请求走慢路径动态扩容整体显存占用能降30%以上。3. 长文本场景下的位置编码外推为什么模型一读长文就“脑子短路”3.1 见过多长就只会多长把训练好的模型直接拿去做长文本推理经常会发现一个诡异的现象输入长度稍微超过训练长度生成质量突然崩塌甚至开始输出大量重复内容。这不是模型变笨了而是位置编码外推失效。Google最早在Transformer里用的是绝对正弦位置编码模型在训练时只见过不超过训练长度范围的位置组合。推理时来了个更长的位置序号这个位置上没有见过对应的位置编码向量模型就等于面对一个未知的外部输入行为自然就乱了。后来的相对位置编码、旋转位置编码RoPE缓解了部分外推问题但也不是无限外推。RoPE本质上是把位置信息编码成旋转角度模型见过的最大位置差决定了它能否正确处理更长的相对距离。3.2 RoPE的旋转直觉与NTK缩放思路旋转位置编码RoPE现在的使用范围很广。它的核心想法是把向量的相邻两个维度分组成二维平面然后让每个维度的平面按位置编号做不同角速度的旋转。两个向量的点积在旋转后只跟它们的相对角度差有关也就是相对位置。这里有个直觉如果把模型的注意力机制比作一个收音机RoPE给每个频率设定了一个带宽训练长度范围内的信号都调好了台超出范围就收不到清晰信号。所以要让模型处理更长文本不是把它拉到长文本上重新训练就完事更常见的做法是修改旋转频率的缩放比例让高频部分适当降低速度把已有的频率覆盖范围整体“压”到更长序列上这种思路一般叫NTK-aware缩放。我在长文本任务中常用的做法是分档缩放低频维度保持原样保留位置精度高频维度做平滑的插值缩放。比统一线性缩放效果更好短文本上的表现也不容易倒退。但要注意这些外推方法本质上是在“硬撑”模型没见过的长度区间如果需求是从2048扩展到8192纯靠缩放已经比较吃力最好在扩展后的长度上补一点微调数据。3.3 别迷信“无限外推”业务里先想清楚截断还是扩展长文本处理的另一个选择是截断策略。说实话很多业务场景里模型“能读多长”不等于“需要读多长”。一篇文章几千字真正关键的信息可能集中在前几百字。盲目做长文本外推KV Cache膨胀带来的显存压力和延迟增长是实打实的。我给某内容审核项目做方案时她们纠结要不要把模型扩到8192长度。我把真实请求的长度分布拉出来一看99.5%的文本都在1000字以内完全没有必要为了0.5%的极端长文付出几倍显存代价。最后方案是超过1500字的文本做两级摘要先抽取关键段落再送进模型效果和显存成本都更优。长文本优化先想想业务是不是真需要长文本再谈技术。4. 显存不够、速度太慢量化与蒸馏的实用选择4.1 量化不是把数字变小那么简单当模型太大、KV Cache又占显存时你自然会想到把参数的精度降下来也就是量化。FP16到INT8单个权重从2字节变1字节7B模型直接省了大约7GB显存到INT4再砍一半3GB多就能装下权重。看起来很简单但量化真正的难点不在权重存储而在计算过程的动态范围。Transformer里的激活值分布很不均匀个别维度会冒出很大的异常值如果直接全局按最大绝对值做线性缩放普通数值的精度会被压缩得特别惨。我见过不少项目量化后模型效果断崖式下跌罪魁祸首基本都是这个。实践中更稳的做法是先拿一小批有代表性的数据跑一遍推理统计每一层激活值的真实分布然后做逐层或逐通道的缩放系数校准对敏感层保留高精度只量化那些分布规整的层。还有更细一步Attention层里Q和K的点积对精度极其敏感V矩阵的投影层则相对宽容。实操里可以QK保持FP16其余MLP层做INT8效果损失会明显低于全量化。4.2 蒸馏花钱换能力的性价比路线蒸馏的本质是“以大教小”让一个大模型当老师输出它自己的概率分布小模型去学这个分布而不是学一个硬标签。硬标签只告诉小模型“这句话是正确的”老师的分布会告诉小模型“这句话大概率正确但另外两个候选也有点靠谱”。这种软标签携带的信息量丰富得多。我实践下来蒸馏方案最适合两种场景一种是目标设备带不动大模型只能上200M~500M的小模型用蒸馏能保住大部分效果另一种是想要多个任务能力的小模型用大模型生成一批高质量的多任务数据来蒸馏比手搓任务数据省力很多。但蒸馏有个代价容易被忽略训练数据的生成成本。你需要拿大模型跑很多次推理才能产出一套像样的蒸馏语料。把这份算力成本和部署省下的资源放到同一个财务模型里算才能判断值不值得。4.3 不同资源约束下的选型对照面对一个具体部署需求优化方案不是越高级越好而是匹配资源约束。我按实际项目经验整理了一张对照表可以直接参考目标场景优先使用的优化组合预期收益主要代价单卡24GB部署7B模型KV Cache上限控制 INT8量化显存占用降一半可跑batch4轻微效果损失需校准数据高并发低延迟问答服务动态批处理 INT4量化 解码长度限制吞吐提升2~4倍需处理长尾效果退化长文摘要任务2048预分配KV Cache RoPE外推 截断策略分级支持更长输入稳定性提升外推需微调适配否则有风险边缘/移动端部署蒸馏到小模型 INT8量化推理延迟低于200ms需投入蒸馏训练资源选择的时候有一个原则能通过工程手段解决的先别动模型动模型优先级从蒸馏到量化损失控制难度递增。5. 真正上线后的隐性瓶颈解码策略与批处理对吞吐的操控5.1 解码策略不只是效果问题更是成本问题生成模型通常提供好几套解码策略贪心搜索、beam search、采样temperature调参。不少文档把它们当作“效果调节选项”但在我眼里它们同时是算力消费选项。Beam search看起来只在每次生成时多算几条候选路径但代价是每条路径都要维护独立的KV Cache。beam width4时缓存占用和计算量直接变4倍而BLEU这类指标的提升可能只有零点几。真实业务里除非是翻译、摘要这类对精确度要求极高的场景我一般不推荐用beam search。很多任务用temperature适中加top-p采样效果差距不大成本却几乎为零。还有一点容易被忽略max_new_tokens的设置。生成长度直接决定decode步数。某个项目把默认最长生成长度设为1024结果平均每条请求实际生成200token剩下824token的KV Cache预分配全部浪费。把max_new_tokens从1024降到512并配合提前停止条件吞吐直接提升了一截。5.2 Continuous Batching把GPU的每一秒钟都填满传统做法是静态batch一批请求同时开始全部生成完再一起结束。问题是有的请求长度短、生成快很快结束了但还要等其他长请求跑完GPU空闲在那里等人。这就是静态batch的浪费。现代高性能推理引擎普遍采用**continuous batching连续批处理**的思路不再等整个batch生成完哪个请求的生成结束了立刻把它的位置腾出来让一个新请求插进去。这样GPU始终在处理有效请求吞吐能提升50%~100%。我当时自己用一个简单的模拟脚本做过验证同样20个请求长度分布不均的情况下连续批处理的总体完成时间比静态批处理快了接近一倍。工程上这个优化性价比极高几乎是线上推理服务必开的选项。5.3 Prefill和Decode要不要分开取决于你的业务比例前面提到prefill和decode的性格不同一个吃算力一个吃带宽。如果你的业务是长prompt短回答比如长文档问答那么prefill占比很高应该优先保证算力供给适合大batch的连续处理。如果业务是短prompt长回答比如聊天机器人续写decode占绝对主导优化重点就放在KV Cache读取和带宽利用率上。有些推理框架会把prefill和decode阶段拆开调度用两组不同配置的资源分别处理避免互相拖累。这个思路在小规模项目里有点重但一旦流量上来分开之后稳定性确实好很多。我在一次峰值流量测试里发现不拆分时GPU利用率波动很大拆分之后整体平稳P95延迟下降了40%。6. 从指标到体验调优过程中的几条实战经验6.1 别只看平均延迟盯住P95和TPOT评测推理性能最容易犯的错误是只看平均延迟。平均延迟会被短请求拉低掩盖长请求的卡顿。我习惯同时盯三个指标TTFT首token延迟用户发出请求到收到第一个token的时间决定了“有没有反应”的体感。TPOT每token生成耗时每生成一个字要等多久直接决定阅读体验是流畅还是卡顿。P95/P99延迟最差情况下的体验这个是线上SLA里真正会被投诉的。某次线上告警排查平均延迟只有800ms但P99到了4秒多。后来发现是几个超长prompt请求把KV Cache顶到接近上限触发了动态扩容的慢路径。只优化平均指标根本发现不了这个问题。6.2 优化顺序先profile再动手我见过太多人一上来就搞量化、搞蒸馏结果问题根本不在模型大小而是解码配置不合理或者batch策略太差。正确的顺序应该是先开profiler看GPU利用率、显存带宽使用率、算子耗时分布。确认瓶颈是prefill还是decode是计算还是访存。先做工程级优化KV Cache、批处理、解码参数调整。再考虑模型级优化量化、蒸馏。我自己在某次项目里按这个顺序走发现瓶颈根本不在显存而是数据加载和预处理环节CPU卡死了GPU的输入管线。修正后延迟降了60%一行模型优化都没做。6.3 小步验证量化后必须做任务级评测最后一条经验是关于验证的。量化或蒸馏之后很多团队只跑一跑困惑度指标看着差不多就上线。但困惑度下降0.5具体任务上的表现可能完全不同。比如摘要任务可能丢失关键实体代码生成任务可能出现格式错乱。我的做法是每次改动后跑一个固定的评测集里面包含业务里最有代表性的用例既看自动指标BLEU、ROUGE、准确率也人工抽查20条典型输出。特别是量化后我会故意测一些带异常长句、专业术语的边界样本专门观察量化误差有没有在最脆弱的点上爆发。说到这儿想起一个朋友做的在线客服项目。他们一开始追求极致量化模型小到不能再小推理速度飞快结果用户经常反馈答非所问最终只能把关键意图识别的分支换回大模型。这件事给我的体会很深Transformer部署优化不是要把模型压到最小而是在效果、延迟、成本三者间找到那个业务可接受的平衡点。每次改动先想清楚你牺牲了什么换来了什么值不值。这个思考框架比任何单一优化技巧都重要。