做推理优化这一行最常被问的一句话是同一个模型为什么别人能拉满吞吐、压住延迟我这边一上线就 OOM用户稍微一多首字延迟直接飙到十几秒这类问题问多了你会发现大模型推理优化根本不是某一招的事而是显存管理、算子内核、量化精度、调度策略、并行切分这几条线拧在一起的结果。这篇文章不打算复述某个框架的官方文档而是把我在大模型推理优化上真正用过的路数、权衡过的取舍、踩过的坑整理一遍。内容主要围绕几件事展开KV Cache 和显存为什么是推理的第一瓶颈、量化怎么做才能不显著掉点、FlashAttention 和投机解码为什么有效、连续批处理和 prefill/decode 分离解决了什么工程问题最后是推理框架的选型思路和实战中的排查经验。无论你是刚上手部署开源模型的工程师还是想系统理解推理性能瓶颈的研究生这篇应该能帮你把散乱的知识点串成一条可执行的优化路线。1. 推理优化的全局地图先搞清楚瓶颈在哪1.1 为什么训练快慢和推理快慢是两回事很多人刚转过来时有个误区觉得模型在训练卡上跑得飞快推理应该也不难。实际上两者是完全不同的两个问题。训练阶段追求的是吞吐可以把大量样本塞进一个大 batch让 GPU 算得满满的哪怕单条样本慢一点也无所谓。推理阶段尤其是对话场景用户在等回复首字延迟和每个 token 的生成速度直接决定体验batch 大小还得看显存脸色。更本质的区别在于计算特征。自回归生成分成两个阶段prefill 阶段要把整个输入 prompt 一次性算完这一步计算量很大但只需要做一次属于计算密集型decode 阶段是逐个 token 生成每一步都拿上一个 token 去更新状态单次计算量很小却要反复读取权重和 KV Cache属于访存密集型。实际在 GPU 上跑的时候decode 阶段的大部分时间都花在把数据从显存搬到计算单元上而不是在算矩阵乘法。所以单纯堆算力对 decode 帮助不大想办法减少数据搬运量才是关键。这个区别决定了推理优化的两条主线一是减少存储开销让同样显存能装下更多权重和缓存二是减少访存开销让单位时间内能处理更多 token。后面所有技术基本都能归到这两类里。1.2 推理开销是怎么分配的要理解优化方向得先把推理过程中的开销拆开看。一次请求的显存占用主要由三块构成模型权重、KV Cache、激活值和临时缓冲。权重是固定的一个 7B 模型在 FP16 下大约 14GB70B 模型大约 140GB这块通过量化可以成倍压缩。KV Cache 是随请求动态增长的每个请求占用的空间跟序列长度成正比并发一多它往往才是显存里的大头。激活值在推理阶段通过算子融合和显存复用已经压得很小一般不用太操心。从时间维度看prefill 阶段受计算量影响大prompt 越长算得越久decode 阶段基本是恒定速度每出一个 token 都要遍历一遍全部历史 KV Cache并把所有权重读一遍。所以同样的模型、同样的 batch序列越长每个 token 的耗时越高。把这几个数字拉通之后优化思路就很清晰要么让模型变小量化、剪枝、蒸馏要么让每次读取的数据量变少FlashAttention、GQA、KV Cache 复用要么让 GPU 一直处于忙碌状态连续批处理、prefill/decode 分离。1.3 别忽略三个核心指标之间的拉扯做推理优化时有三个指标要时刻盯住首字延迟TTFT、生成速度TPOT、吞吐Throughput。首字延迟影响用户的第一印象生成速度影响整体流利度吞吐影响服务成本和并发能力。问题是这三者经常互相打架追求低延迟就得少做 batch吞吐自然降追求高吞吐就得把请求攒起来延迟又会涨。场景不同优先级完全不同。对话类服务通常更看重首字延迟和生成速度离线批量任务更看重吞吐Agent 类应用则要特别关注长 prompt 下的前缀复用能力。我见过不少团队拿着同一套参数去适配所有业务最后不是延迟超标就是资源浪费。做优化之前先把业务指标定清楚否则后面所有调参都像无头苍蝇。2. 显存优化KV Cache 是绕不开的第一课2.1 KV Cache 为什么是必需品先解释一个新手最容易困惑的问题为什么推理需要 KV Cache不能每次都重新算一遍原因是注意力的计算方式。生成第 t 个 token 时需要让这个 token 的 Query 和前面所有 token 的 Key、Value 做注意力计算。如果每次都不缓存就得把前面 t-1 个 token 的 K、V 全部重新算一遍计算量从 O(t) 变成 O(t²)序列稍微一长就完全没法跑。所以几乎所有推理框架都会把历史 token 的 K、V 存在显存里这就是 KV Cache。KV Cache 有多大可以手算出来。公式是每 token 显存 2K 和 V 两份× 层数 × KV 头数 × 头维度 × 精度字节数。拿一个常见的 70B 开源模型举例80 层、8 个 KV 头、每个头 128 维、FP16 精度2 × 80 × 8 × 128 × 2 327680 字节大约 320KB 一个 token。4096 个 token 的上下文就是 1.25GB如果同时服务 100 个用户光 KV Cache 就要 125GB比模型权重本身还夸张。很多团队按权重大小去买卡一压测才发现全被 KV Cache 吃光了。2.2 PagedAttention 是怎么解决碎片问题的KV Cache 不仅量大还有一个麻烦的问题它是一段一段动态增长的每个请求的 cache 长度都不一样。如果按固定长度预分配会浪费大量显存如果按需分配又会产生严重碎片。传统推理框架通常按请求最大长度预留显存实际用不到的部分就白瞎了。更糟的是显存碎片化之后即使总量够用也可能因为找不到连续空间而 OOM。PagedAttention 的思路是把 KV Cache 切成固定大小的小块用一张索引表管理类似操作系统里的虚拟内存分页。每个请求不再需要连续的显存可以散落在不同块里索引表帮它把逻辑上连续的 KV Cache 映射到物理上不连续的位置。这样显存利用率大幅提升碎片浪费几乎消失同时因为块可以跨请求共享前缀相同的请求还能直接复用已经算好的缓存。实测下来这种页式管理能让单卡容纳的并发请求数成倍上涨吞吐提升非常可观现在主流的吞吐导向推理框架基本都以此为地基。2.3 GQA 和 MQA从源头削减 KV 开销除了在分配侧做文章还有一条更根本的路直接把 KV Cache 变小这就是分组查询注意力 GQA 和它的极端版本多查询注意力 MQA。标准多头注意力里每个 Query 头都对应一份独立的 K、V头一多KV Cache 成倍放大。GQA 的做法是让多个 Query 头共享同一组 K、V比如 32 个 Q 头共享 8 组 KV 头KV Cache 直接降到四分之一。MQA 更激进所有 Query 头共享一份 K、V。很多人担心共享 KV 会影响效果。从主流开源模型的默认配置来看大部分 7B 以上的模型已经用上 GQA配合训练阶段的调整质量损失可以控制在很小的范围而省下来的显存足以换来更长的上下文或更高的并发这个交换非常划算。选模型时注意看配置里 KV 头的数量同样的参数量KV 头少的模型在推理侧的性价比通常更高。注意KV Cache 的量化也是这两年被验证有效的方向。权重量化解决的是把模型塞进显存但 KV Cache 一般还是 FP16 或 BF16长上下文场景下可以考虑降到 FP8。做 KV Cache 量化时重点盯住注意力分数对精度的敏感度先跑小规模验证再全量上别一上来直接压到最低位宽。3. 计算提速量化与注意力内核优化3.1 量化不是把精度调低那么简单量化大概是推理优化里传播最广、误解也最多的一个词。简单理解就是把模型权重从 FP16 表示变成 INT8、INT4 甚至更低精度的整数表示让每个权重占的字节变少从而省显存、提高访存速度。但这里有个关键认知量化真正赚的是访存不是计算。decode 阶段访存密集权重压缩一半每次读取的数据量就少一半速度自然上来prefill 阶段计算密集提速更多靠算子优化量化的帮助相对有限。主流量化方案分几条线。GPTQ 是后训练量化里的经典路线基于二阶信息做逐层误差补偿在 INT4 下能把精度损失压得较小适合 GPU 推理。AWQ 拿激活值的分布来指导权重缩放它发现权重里只有极少数通道是真正关键的重点保护这些通道能显著减少量化误差好处是校准数据需求小部署时用得很多。SmoothQuant 针对的是激活值难量化的问题把激活上的分布方差平滑到权重上让两者都更容易量化适合需要同时量化权重和激活的场景。还有 GGUF 格式下的 Q4_K_M、Q5_K_M 等量化等级在消费级平台上很实用。怎么选要看场景。服务端 GPU 推理优先考虑 AWQ 或 GPTQ 的 INT4 权重量化显存压力小、吞吐高如果模型已经大到必须双卡才能放下量化的收益是决定性的。端侧或 CPU 场景用 GGUF 那套量化生态最省心。我的体会是评估量化方案不能只看显存省了多少更不能光看跑分一定要用真实业务里的 prompt 分布做质量评测。不同量化位宽对生成质量的伤害在长文本、代码、数学这类任务上差异非常大省下 10% 显存但生成质量崩了得不偿失。3.2 FlashAttention没减少计算但快了很多FlashAttention 是近年对长序列推理贡献极大的一个工作。它的核心思想可能和直觉相反它并没有减少计算量反而因为分块操作计算量略微增加了一点但运行速度却快了好几倍原因在于它大幅减少了显存和计算单元之间的数据搬运。标准注意力实现里Q 和 K 相乘得到一个形状为 (seq_len, seq_len) 的大矩阵 S然后做 softmax 得到 P再和 V 相乘。这个中间矩阵会完整写回显存再读回来当序列长度到几千上万时读写开销非常吓人。FlashAttention 把 Q、K、V 切成小块让 S 和 P 的计算停留在芯片内部的高速缓存里再利用在线 softmax 技巧不需要一次性拿到整行的最大值和总和也能分块算出正确的 softmax 结果。这样注意力计算过程中几乎不会有大块数据在高低速存储之间来回倒腾速度自然上去。实际部署里长上下文推理如果没上 FlashAttention 这类算子性能差距是数量级的。尤其 prompt 很长、prefill 占比高的场景用上融合算子后首字延迟能降一个级别。现在主流框架基本默认开启这类内核优化但自己写推理代码或使用较老的部署方案时要特别注意检查算子实现这是最容易白捡的性能提升。3.3 投机解码让大模型少干活还有一个反直觉的加速思路叫投机解码。它的想法是与其让大模型一步一步慢慢生成不如先让一个小模型快速猜出接下来几个 token再由大模型一次性验证。你可能会觉得这不可靠小模型猜错还得返工不是更慢吗关键在于验证的代价。大模型一次前向计算可以同时验证多个 token比逐个生成的代价小得多。小模型猜 k 个 token大模型只需一次前向确认哪些是对的如果猜对大部分实际生成速度就能接近大模型的单步速度乘以接受比例。实际使用中一个 1B 左右的小草稿模型配 70B 主模型在不少任务上能带来 2 到 3 倍的端到端速度提升。不过投机解码不是无脑上。它依赖草稿模型和主模型的分布一致性草稿模型越接近主模型接受率越高任务分布差异很大时收益会明显缩水。另外草稿模型本身占显存显存紧张的场景要权衡。现在很多框架把它做成插件式开关先关着跑基线再打开测收益用数据说话最稳。4. 调度与并行工程层面的硬功夫4.1 连续批处理让 GPU 一直忙起来之前提到 decode 是访存密集型如果只处理一个请求GPU 的计算单元大量时间在空转等数据。传统做法是静态批处理把多个请求攒成一个 batch 一起跑但这里有个经典问题batch 里每个请求的生成长度不一样短请求早就结束了长请求还在生成整个 batch 得等最慢的完成才能整体释放中间这段时间 GPU 效率又掉下去了。连续批处理也叫迭代级调度解决的就是这个问题。它把批处理的粒度从请求细化到单个迭代每生成一个 token 就做一次调度决策完成的请求立刻移出新来的请求马上补进来让 GPU 每个时刻都在处理当前最活跃的那批请求。这个机制配合页式显存管理吞吐能提升 2 到 4 倍是现在服务端推理框架的标配能力。如果你发现服务每个请求单独排队、吞吐上不去优先检查是不是还在用静态 batch。4.2 Prefill 和 Decode 分离两种活不要混着干连续批处理解决的是粒度问题prefill 和 decode 分离则是解决混跑问题。prefill 和 decode 的计算特征完全不同prefill 计算密集、显存占用峰值高、但只做一次decode 访存密集、显存占用稳定、要做很多次。把它们混在同一个 GPU 上时prefill 的突发计算会抢走大量算力导致正在 decode 的所有请求跟着变慢表现为首字延迟和生成速度同时劣化。分离部署的做法是把资源分成两组一组专门处理 prefill一组专门处理 decode中间通过缓存或消息传递衔接。prefill 节点把生成的 KV Cache 传给 decode 节点decode 节点专心做生成。这样两类任务互不干扰各自资源利用率都能拉满。实际落地时需要注意 KV Cache 跨节点的传输开销传输设计不好容易成为新瓶颈一般会配合缓存压缩和预取调度一起做。4.3 模型并行单卡放不下怎么办模型大到单卡放不下时就得做并行切分。张量并行是把一个 Transformer 层的权重按头或按列切成多份分到多张卡上每张卡算一部分再通过集合通信同步结果。它通信频繁适合单机多卡这种高速互联的环境跨机用容易通信撑不住。流水线并行则是按层切分前一层算完传给后一层通信量小但存在流水线气泡利用率会打折扣。数据并行在推理场景很少单独用收益不明显更多是配合切分来扩大可容纳的并发。MoE 模型的推理并行是另一套逻辑走的是专家并行把不同专家分到不同卡上每个 token 按路由结果去访问对应专家。因为 MoE 每层只激活少数专家实际计算量远小于同等参数量的稠密模型但显存依然要装下全部专家权重所以显存优化和专家并行的配合非常关键。选哪种并行策略核心看三件事能不能放下、通信开销能不能承受、能不能让每张卡都保持高利用率。4.4 推理框架怎么选说到落地绕不开框架选型。现在主流思路大致分几个流派吞吐导向的框架强调连续批处理和页式显存管理适合高并发在线服务极致性能导向的框架把模型编译成针对特定 GPU 优化的引擎适合追求最低延迟的场景代价是构建和适配成本高、灵活性稍差轻量级框架主打单文件部署和 CPU、消费级 GPU 支持量化格式生态丰富适合本地和边缘场景还有专注复杂 prompt 调度的框架在前缀缓存、分支复用上做得比较极致适合 Agent 这类多轮调用场景。我的选型建议是别一上来就逐框架折腾先明确瓶颈是显存、延迟还是吞吐。显存紧张优先看量化支持和缓存管理能力延迟敏感优先看算子内核和引擎编译能力吞吐优先看批处理和调度策略。多框架先跑同一份基准数据用真实请求做对比再决定锁定哪一个。框架迭代速度很快盯住自己的业务指标比追新特性实在得多。5. 踩坑实录常见问题与排查思路5.1 服务频繁 OOM 怎么排查遇到 OOM 先别急着调低 batch第一步是搞清楚显存被谁吃了。看监控里模型权重、KV Cache、激活值各占多少。如果 KV Cache 是大头优先检查缓存分配策略是不是还在按最大长度预留换成页式管理或动态分配往往立刻缓解。如果权重是大头考虑上量化。如果两者都不是那可能是显存碎片化严重重启能暂时缓解但根治还是要换用支持页式分配的框架。一个排查技巧用同样的并发压测分别打开和关闭投机解码、前缀缓存选项对比显存曲线。有些加速特性的显存开销是隐性的比如草稿模型、缓存池预留一步步关掉排查很快能锁定是谁在吞显存。线上排查最怕没有监控就拍脑袋改参数先量化再动手这个习惯能省掉大半的半夜告警。5.2 量化之后效果明显变差怎么办量化掉点要分情况看。如果是权重 INT4 量化后能力明显崩坏先检查校准数据集是否和真实业务分布一致。校准集应该是真实业务样本的代表不能随便拿几句话凑数内容分布偏差大量化参数就偏了。其次检查是否用了激活感知的量化方案像 AWQ 这类保住重点通道的方式一般比纯权重后训练量化更稳。还有一个常见坑KV Cache 量化后长文本能力下滑。KV Cache 的量化误差会随着序列增长累积表现就是短文本还行、长文本开始胡言乱语。遇到这种情况可以只对 KV Cache 做 FP8 量化或者对量化敏感的部分层保持高精度逐层做消融找到伤害最大的那几层单独保护。5.3 吞吐上不去卡利用率却不高如果发现 GPU 利用率不高但吞吐也上不去大概率是调度层面出了问题。检查队列里是否长期只有少量请求在跑batch 根本组不起来。此时要么加大并发限制要么检查前置服务有没有把请求压进来。如果请求量不小但每个请求单独排队那就是没开连续批处理赶紧检查调度配置。还有一种隐蔽情况prefill 和 decode 都挤在同一张卡上长 prompt 请求一来就占用大量显存导致能并发处理的请求数骤降。这种情况要么限制单请求最大长度要么考虑 prefill/decode 分离。跑服务就像流水线瓶颈在哪条线上一目了然先用分段计时定位再改配置。5.4 首字延迟突然飙升首字延迟飙升是最容易被用户感知的问题。常见原因有几个排队时间过长、prefill 计算被其他请求拖累、前缀缓存没命中。排查时先看首字延迟的构成如果大部分时间花在排队上说明服务容量不够或调度策略不合理优先查并发和批处理参数如果时间花在 prefill 本身说明 prompt 太长导致单次计算开销太大考虑前缀复用或对 prompt 做摘要压缩。另外很多团队忽略了系统提示词对首字延迟的影响。系统提示词每次请求都要参与 prefill 计算如果它很长且每次相同完全可以通过前缀缓存在不同请求之间复用省掉一大块重复计算。这个优化在智能体类应用里收益很明显同样的工具定义和角色信息反复做 KV 计算既浪费算力又拖慢响应。注意压测时一定要覆盖长 prompt、长输出、高并发混合场景。只测短对话往往发现不了问题真实流量一来KV Cache 和 prefill 的显存争抢立刻暴露。我的习惯是先用模拟流量把服务压到 70% 的显存水位再观察各指标是否稳定这样的数据才有参考价值。6. 关于优化的一点点个人体会做了这么久推理优化最大的体会是优化不是一个点的工作而是一条链的工作。显存不够就量化量化掉点就换激活感知方案还不行就看调度和并行每一步都有专用手段但它们互相影响。比如你上了投机解码吞吐上来了但显存占用涨了如果原来就贴着上限就得回头再调缓存策略。所以做优化一定要有全局指标把首字延迟、生成速度、吞吐、显存占用全部记录下来每次改一个变量观察全部指标再决定下一步。另一个体会是优先做收益最大、成本最低的事。很多服务跑不快根本原因不是没用上最新技术而是基础的量化没做、批处理没开、缓存没复用。把这几件基础的事做好往往已经超过大多数默认配置一大截。新框架新特性层出不穷但推理优化的底层逻辑是稳定的访存量越低越接近硬件上限GPU 越忙越接近吞吐极限缓存复用越多越省钱。沿着这三条线去拆问题任何花哨的技巧都能归位。最后分享一个建议刚接触推理优化时找一个中型开源模型搭一套带监控的服务把上面提到的每一项优化分别打开和关闭跑一遍对比亲手记录数据。这个过程比读十篇论文都有用因为你会真正理解每个优化在什么条件下有效、什么时候无效。数据不会骗人这个习惯会伴随你整个优化生涯。
做推理优化这一行最常被问的一句话是同一个模型为什么别人能拉满吞吐、压住延迟我这边一上线就 OOM用户稍微一多首字延迟直接飙到十几秒这类问题问多了你会发现大模型推理优化根本不是某一招的事而是显存管理、算子内核、量化精度、调度策略、并行切分这几条线拧在一起的结果。这篇文章不打算复述某个框架的官方文档而是把我在大模型推理优化上真正用过的路数、权衡过的取舍、踩过的坑整理一遍。内容主要围绕几件事展开KV Cache 和显存为什么是推理的第一瓶颈、量化怎么做才能不显著掉点、FlashAttention 和投机解码为什么有效、连续批处理和 prefill/decode 分离解决了什么工程问题最后是推理框架的选型思路和实战中的排查经验。无论你是刚上手部署开源模型的工程师还是想系统理解推理性能瓶颈的研究生这篇应该能帮你把散乱的知识点串成一条可执行的优化路线。1. 推理优化的全局地图先搞清楚瓶颈在哪1.1 为什么训练快慢和推理快慢是两回事很多人刚转过来时有个误区觉得模型在训练卡上跑得飞快推理应该也不难。实际上两者是完全不同的两个问题。训练阶段追求的是吞吐可以把大量样本塞进一个大 batch让 GPU 算得满满的哪怕单条样本慢一点也无所谓。推理阶段尤其是对话场景用户在等回复首字延迟和每个 token 的生成速度直接决定体验batch 大小还得看显存脸色。更本质的区别在于计算特征。自回归生成分成两个阶段prefill 阶段要把整个输入 prompt 一次性算完这一步计算量很大但只需要做一次属于计算密集型decode 阶段是逐个 token 生成每一步都拿上一个 token 去更新状态单次计算量很小却要反复读取权重和 KV Cache属于访存密集型。实际在 GPU 上跑的时候decode 阶段的大部分时间都花在把数据从显存搬到计算单元上而不是在算矩阵乘法。所以单纯堆算力对 decode 帮助不大想办法减少数据搬运量才是关键。这个区别决定了推理优化的两条主线一是减少存储开销让同样显存能装下更多权重和缓存二是减少访存开销让单位时间内能处理更多 token。后面所有技术基本都能归到这两类里。1.2 推理开销是怎么分配的要理解优化方向得先把推理过程中的开销拆开看。一次请求的显存占用主要由三块构成模型权重、KV Cache、激活值和临时缓冲。权重是固定的一个 7B 模型在 FP16 下大约 14GB70B 模型大约 140GB这块通过量化可以成倍压缩。KV Cache 是随请求动态增长的每个请求占用的空间跟序列长度成正比并发一多它往往才是显存里的大头。激活值在推理阶段通过算子融合和显存复用已经压得很小一般不用太操心。从时间维度看prefill 阶段受计算量影响大prompt 越长算得越久decode 阶段基本是恒定速度每出一个 token 都要遍历一遍全部历史 KV Cache并把所有权重读一遍。所以同样的模型、同样的 batch序列越长每个 token 的耗时越高。把这几个数字拉通之后优化思路就很清晰要么让模型变小量化、剪枝、蒸馏要么让每次读取的数据量变少FlashAttention、GQA、KV Cache 复用要么让 GPU 一直处于忙碌状态连续批处理、prefill/decode 分离。1.3 别忽略三个核心指标之间的拉扯做推理优化时有三个指标要时刻盯住首字延迟TTFT、生成速度TPOT、吞吐Throughput。首字延迟影响用户的第一印象生成速度影响整体流利度吞吐影响服务成本和并发能力。问题是这三者经常互相打架追求低延迟就得少做 batch吞吐自然降追求高吞吐就得把请求攒起来延迟又会涨。场景不同优先级完全不同。对话类服务通常更看重首字延迟和生成速度离线批量任务更看重吞吐Agent 类应用则要特别关注长 prompt 下的前缀复用能力。我见过不少团队拿着同一套参数去适配所有业务最后不是延迟超标就是资源浪费。做优化之前先把业务指标定清楚否则后面所有调参都像无头苍蝇。2. 显存优化KV Cache 是绕不开的第一课2.1 KV Cache 为什么是必需品先解释一个新手最容易困惑的问题为什么推理需要 KV Cache不能每次都重新算一遍原因是注意力的计算方式。生成第 t 个 token 时需要让这个 token 的 Query 和前面所有 token 的 Key、Value 做注意力计算。如果每次都不缓存就得把前面 t-1 个 token 的 K、V 全部重新算一遍计算量从 O(t) 变成 O(t²)序列稍微一长就完全没法跑。所以几乎所有推理框架都会把历史 token 的 K、V 存在显存里这就是 KV Cache。KV Cache 有多大可以手算出来。公式是每 token 显存 2K 和 V 两份× 层数 × KV 头数 × 头维度 × 精度字节数。拿一个常见的 70B 开源模型举例80 层、8 个 KV 头、每个头 128 维、FP16 精度2 × 80 × 8 × 128 × 2 327680 字节大约 320KB 一个 token。4096 个 token 的上下文就是 1.25GB如果同时服务 100 个用户光 KV Cache 就要 125GB比模型权重本身还夸张。很多团队按权重大小去买卡一压测才发现全被 KV Cache 吃光了。2.2 PagedAttention 是怎么解决碎片问题的KV Cache 不仅量大还有一个麻烦的问题它是一段一段动态增长的每个请求的 cache 长度都不一样。如果按固定长度预分配会浪费大量显存如果按需分配又会产生严重碎片。传统推理框架通常按请求最大长度预留显存实际用不到的部分就白瞎了。更糟的是显存碎片化之后即使总量够用也可能因为找不到连续空间而 OOM。PagedAttention 的思路是把 KV Cache 切成固定大小的小块用一张索引表管理类似操作系统里的虚拟内存分页。每个请求不再需要连续的显存可以散落在不同块里索引表帮它把逻辑上连续的 KV Cache 映射到物理上不连续的位置。这样显存利用率大幅提升碎片浪费几乎消失同时因为块可以跨请求共享前缀相同的请求还能直接复用已经算好的缓存。实测下来这种页式管理能让单卡容纳的并发请求数成倍上涨吞吐提升非常可观现在主流的吞吐导向推理框架基本都以此为地基。2.3 GQA 和 MQA从源头削减 KV 开销除了在分配侧做文章还有一条更根本的路直接把 KV Cache 变小这就是分组查询注意力 GQA 和它的极端版本多查询注意力 MQA。标准多头注意力里每个 Query 头都对应一份独立的 K、V头一多KV Cache 成倍放大。GQA 的做法是让多个 Query 头共享同一组 K、V比如 32 个 Q 头共享 8 组 KV 头KV Cache 直接降到四分之一。MQA 更激进所有 Query 头共享一份 K、V。很多人担心共享 KV 会影响效果。从主流开源模型的默认配置来看大部分 7B 以上的模型已经用上 GQA配合训练阶段的调整质量损失可以控制在很小的范围而省下来的显存足以换来更长的上下文或更高的并发这个交换非常划算。选模型时注意看配置里 KV 头的数量同样的参数量KV 头少的模型在推理侧的性价比通常更高。注意KV Cache 的量化也是这两年被验证有效的方向。权重量化解决的是把模型塞进显存但 KV Cache 一般还是 FP16 或 BF16长上下文场景下可以考虑降到 FP8。做 KV Cache 量化时重点盯住注意力分数对精度的敏感度先跑小规模验证再全量上别一上来直接压到最低位宽。3. 计算提速量化与注意力内核优化3.1 量化不是把精度调低那么简单量化大概是推理优化里传播最广、误解也最多的一个词。简单理解就是把模型权重从 FP16 表示变成 INT8、INT4 甚至更低精度的整数表示让每个权重占的字节变少从而省显存、提高访存速度。但这里有个关键认知量化真正赚的是访存不是计算。decode 阶段访存密集权重压缩一半每次读取的数据量就少一半速度自然上来prefill 阶段计算密集提速更多靠算子优化量化的帮助相对有限。主流量化方案分几条线。GPTQ 是后训练量化里的经典路线基于二阶信息做逐层误差补偿在 INT4 下能把精度损失压得较小适合 GPU 推理。AWQ 拿激活值的分布来指导权重缩放它发现权重里只有极少数通道是真正关键的重点保护这些通道能显著减少量化误差好处是校准数据需求小部署时用得很多。SmoothQuant 针对的是激活值难量化的问题把激活上的分布方差平滑到权重上让两者都更容易量化适合需要同时量化权重和激活的场景。还有 GGUF 格式下的 Q4_K_M、Q5_K_M 等量化等级在消费级平台上很实用。怎么选要看场景。服务端 GPU 推理优先考虑 AWQ 或 GPTQ 的 INT4 权重量化显存压力小、吞吐高如果模型已经大到必须双卡才能放下量化的收益是决定性的。端侧或 CPU 场景用 GGUF 那套量化生态最省心。我的体会是评估量化方案不能只看显存省了多少更不能光看跑分一定要用真实业务里的 prompt 分布做质量评测。不同量化位宽对生成质量的伤害在长文本、代码、数学这类任务上差异非常大省下 10% 显存但生成质量崩了得不偿失。3.2 FlashAttention没减少计算但快了很多FlashAttention 是近年对长序列推理贡献极大的一个工作。它的核心思想可能和直觉相反它并没有减少计算量反而因为分块操作计算量略微增加了一点但运行速度却快了好几倍原因在于它大幅减少了显存和计算单元之间的数据搬运。标准注意力实现里Q 和 K 相乘得到一个形状为 (seq_len, seq_len) 的大矩阵 S然后做 softmax 得到 P再和 V 相乘。这个中间矩阵会完整写回显存再读回来当序列长度到几千上万时读写开销非常吓人。FlashAttention 把 Q、K、V 切成小块让 S 和 P 的计算停留在芯片内部的高速缓存里再利用在线 softmax 技巧不需要一次性拿到整行的最大值和总和也能分块算出正确的 softmax 结果。这样注意力计算过程中几乎不会有大块数据在高低速存储之间来回倒腾速度自然上去。实际部署里长上下文推理如果没上 FlashAttention 这类算子性能差距是数量级的。尤其 prompt 很长、prefill 占比高的场景用上融合算子后首字延迟能降一个级别。现在主流框架基本默认开启这类内核优化但自己写推理代码或使用较老的部署方案时要特别注意检查算子实现这是最容易白捡的性能提升。3.3 投机解码让大模型少干活还有一个反直觉的加速思路叫投机解码。它的想法是与其让大模型一步一步慢慢生成不如先让一个小模型快速猜出接下来几个 token再由大模型一次性验证。你可能会觉得这不可靠小模型猜错还得返工不是更慢吗关键在于验证的代价。大模型一次前向计算可以同时验证多个 token比逐个生成的代价小得多。小模型猜 k 个 token大模型只需一次前向确认哪些是对的如果猜对大部分实际生成速度就能接近大模型的单步速度乘以接受比例。实际使用中一个 1B 左右的小草稿模型配 70B 主模型在不少任务上能带来 2 到 3 倍的端到端速度提升。不过投机解码不是无脑上。它依赖草稿模型和主模型的分布一致性草稿模型越接近主模型接受率越高任务分布差异很大时收益会明显缩水。另外草稿模型本身占显存显存紧张的场景要权衡。现在很多框架把它做成插件式开关先关着跑基线再打开测收益用数据说话最稳。4. 调度与并行工程层面的硬功夫4.1 连续批处理让 GPU 一直忙起来之前提到 decode 是访存密集型如果只处理一个请求GPU 的计算单元大量时间在空转等数据。传统做法是静态批处理把多个请求攒成一个 batch 一起跑但这里有个经典问题batch 里每个请求的生成长度不一样短请求早就结束了长请求还在生成整个 batch 得等最慢的完成才能整体释放中间这段时间 GPU 效率又掉下去了。连续批处理也叫迭代级调度解决的就是这个问题。它把批处理的粒度从请求细化到单个迭代每生成一个 token 就做一次调度决策完成的请求立刻移出新来的请求马上补进来让 GPU 每个时刻都在处理当前最活跃的那批请求。这个机制配合页式显存管理吞吐能提升 2 到 4 倍是现在服务端推理框架的标配能力。如果你发现服务每个请求单独排队、吞吐上不去优先检查是不是还在用静态 batch。4.2 Prefill 和 Decode 分离两种活不要混着干连续批处理解决的是粒度问题prefill 和 decode 分离则是解决混跑问题。prefill 和 decode 的计算特征完全不同prefill 计算密集、显存占用峰值高、但只做一次decode 访存密集、显存占用稳定、要做很多次。把它们混在同一个 GPU 上时prefill 的突发计算会抢走大量算力导致正在 decode 的所有请求跟着变慢表现为首字延迟和生成速度同时劣化。分离部署的做法是把资源分成两组一组专门处理 prefill一组专门处理 decode中间通过缓存或消息传递衔接。prefill 节点把生成的 KV Cache 传给 decode 节点decode 节点专心做生成。这样两类任务互不干扰各自资源利用率都能拉满。实际落地时需要注意 KV Cache 跨节点的传输开销传输设计不好容易成为新瓶颈一般会配合缓存压缩和预取调度一起做。4.3 模型并行单卡放不下怎么办模型大到单卡放不下时就得做并行切分。张量并行是把一个 Transformer 层的权重按头或按列切成多份分到多张卡上每张卡算一部分再通过集合通信同步结果。它通信频繁适合单机多卡这种高速互联的环境跨机用容易通信撑不住。流水线并行则是按层切分前一层算完传给后一层通信量小但存在流水线气泡利用率会打折扣。数据并行在推理场景很少单独用收益不明显更多是配合切分来扩大可容纳的并发。MoE 模型的推理并行是另一套逻辑走的是专家并行把不同专家分到不同卡上每个 token 按路由结果去访问对应专家。因为 MoE 每层只激活少数专家实际计算量远小于同等参数量的稠密模型但显存依然要装下全部专家权重所以显存优化和专家并行的配合非常关键。选哪种并行策略核心看三件事能不能放下、通信开销能不能承受、能不能让每张卡都保持高利用率。4.4 推理框架怎么选说到落地绕不开框架选型。现在主流思路大致分几个流派吞吐导向的框架强调连续批处理和页式显存管理适合高并发在线服务极致性能导向的框架把模型编译成针对特定 GPU 优化的引擎适合追求最低延迟的场景代价是构建和适配成本高、灵活性稍差轻量级框架主打单文件部署和 CPU、消费级 GPU 支持量化格式生态丰富适合本地和边缘场景还有专注复杂 prompt 调度的框架在前缀缓存、分支复用上做得比较极致适合 Agent 这类多轮调用场景。我的选型建议是别一上来就逐框架折腾先明确瓶颈是显存、延迟还是吞吐。显存紧张优先看量化支持和缓存管理能力延迟敏感优先看算子内核和引擎编译能力吞吐优先看批处理和调度策略。多框架先跑同一份基准数据用真实请求做对比再决定锁定哪一个。框架迭代速度很快盯住自己的业务指标比追新特性实在得多。5. 踩坑实录常见问题与排查思路5.1 服务频繁 OOM 怎么排查遇到 OOM 先别急着调低 batch第一步是搞清楚显存被谁吃了。看监控里模型权重、KV Cache、激活值各占多少。如果 KV Cache 是大头优先检查缓存分配策略是不是还在按最大长度预留换成页式管理或动态分配往往立刻缓解。如果权重是大头考虑上量化。如果两者都不是那可能是显存碎片化严重重启能暂时缓解但根治还是要换用支持页式分配的框架。一个排查技巧用同样的并发压测分别打开和关闭投机解码、前缀缓存选项对比显存曲线。有些加速特性的显存开销是隐性的比如草稿模型、缓存池预留一步步关掉排查很快能锁定是谁在吞显存。线上排查最怕没有监控就拍脑袋改参数先量化再动手这个习惯能省掉大半的半夜告警。5.2 量化之后效果明显变差怎么办量化掉点要分情况看。如果是权重 INT4 量化后能力明显崩坏先检查校准数据集是否和真实业务分布一致。校准集应该是真实业务样本的代表不能随便拿几句话凑数内容分布偏差大量化参数就偏了。其次检查是否用了激活感知的量化方案像 AWQ 这类保住重点通道的方式一般比纯权重后训练量化更稳。还有一个常见坑KV Cache 量化后长文本能力下滑。KV Cache 的量化误差会随着序列增长累积表现就是短文本还行、长文本开始胡言乱语。遇到这种情况可以只对 KV Cache 做 FP8 量化或者对量化敏感的部分层保持高精度逐层做消融找到伤害最大的那几层单独保护。5.3 吞吐上不去卡利用率却不高如果发现 GPU 利用率不高但吞吐也上不去大概率是调度层面出了问题。检查队列里是否长期只有少量请求在跑batch 根本组不起来。此时要么加大并发限制要么检查前置服务有没有把请求压进来。如果请求量不小但每个请求单独排队那就是没开连续批处理赶紧检查调度配置。还有一种隐蔽情况prefill 和 decode 都挤在同一张卡上长 prompt 请求一来就占用大量显存导致能并发处理的请求数骤降。这种情况要么限制单请求最大长度要么考虑 prefill/decode 分离。跑服务就像流水线瓶颈在哪条线上一目了然先用分段计时定位再改配置。5.4 首字延迟突然飙升首字延迟飙升是最容易被用户感知的问题。常见原因有几个排队时间过长、prefill 计算被其他请求拖累、前缀缓存没命中。排查时先看首字延迟的构成如果大部分时间花在排队上说明服务容量不够或调度策略不合理优先查并发和批处理参数如果时间花在 prefill 本身说明 prompt 太长导致单次计算开销太大考虑前缀复用或对 prompt 做摘要压缩。另外很多团队忽略了系统提示词对首字延迟的影响。系统提示词每次请求都要参与 prefill 计算如果它很长且每次相同完全可以通过前缀缓存在不同请求之间复用省掉一大块重复计算。这个优化在智能体类应用里收益很明显同样的工具定义和角色信息反复做 KV 计算既浪费算力又拖慢响应。注意压测时一定要覆盖长 prompt、长输出、高并发混合场景。只测短对话往往发现不了问题真实流量一来KV Cache 和 prefill 的显存争抢立刻暴露。我的习惯是先用模拟流量把服务压到 70% 的显存水位再观察各指标是否稳定这样的数据才有参考价值。6. 关于优化的一点点个人体会做了这么久推理优化最大的体会是优化不是一个点的工作而是一条链的工作。显存不够就量化量化掉点就换激活感知方案还不行就看调度和并行每一步都有专用手段但它们互相影响。比如你上了投机解码吞吐上来了但显存占用涨了如果原来就贴着上限就得回头再调缓存策略。所以做优化一定要有全局指标把首字延迟、生成速度、吞吐、显存占用全部记录下来每次改一个变量观察全部指标再决定下一步。另一个体会是优先做收益最大、成本最低的事。很多服务跑不快根本原因不是没用上最新技术而是基础的量化没做、批处理没开、缓存没复用。把这几件基础的事做好往往已经超过大多数默认配置一大截。新框架新特性层出不穷但推理优化的底层逻辑是稳定的访存量越低越接近硬件上限GPU 越忙越接近吞吐极限缓存复用越多越省钱。沿着这三条线去拆问题任何花哨的技巧都能归位。最后分享一个建议刚接触推理优化时找一个中型开源模型搭一套带监控的服务把上面提到的每一项优化分别打开和关闭跑一遍对比亲手记录数据。这个过程比读十篇论文都有用因为你会真正理解每个优化在什么条件下有效、什么时候无效。数据不会骗人这个习惯会伴随你整个优化生涯。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
