大模型推理这件事真正落到生产环境里最扎心的往往不是模型效果不够好而是延迟压不下来、显存吃不下、单卡吞吐上不去。我最早接触推理优化的时候天真地以为把模型权重加载进去、跑通generate就完事了结果一上并发P99 延迟直接飙到十几秒GPU 利用率却只有百分之二三十。后来才慢慢明白推理加速是一整套系统工程量化、投机采样、PD 分离这三样东西基本覆盖了从单卡到集群、从计算到调度的主要优化路径。这篇就把我踩过的坑和实际调优的思路完整梳理一遍适合已经跑通过基础推理、想进一步把成本和延迟压下来的同学参考也适合刚接触这块、想建立整体认知的朋友。1. 为什么推理加速不能只盯着一个点1.1 推理的两个阶段决定了优化方向完全不同要理解加速技术得先搞清楚大模型推理到底在干什么。一次完整的生成过程分成两个阶段Prefill预填充和Decode解码。Prefill 阶段把用户输入的整段 prompt 一次性喂进去计算量集中在矩阵乘法上属于典型的计算密集型任务GPU 的算力能被吃得很满。Decode 阶段就不一样了它每次只生成一个 token每生成一个都要把之前所有的 KV 缓存读一遍计算量小但访存量大属于访存密集型任务。这两个阶段的特性差异直接决定了优化手段的分野。量化主要解决的是权重和激活值的存储与访存开销对 Decode 阶段的收益尤其明显投机采样针对的是 Decode 阶段串行生成的本质用并行验证来换时间PD 分离则是从系统架构层面把两种特性不同的任务拆到不同的资源池上避免互相拖累。你要是只优化其中一个点往往会出现按下葫芦浮起瓢的情况——比如光做量化Prefill 阶段的计算瓶颈还在光做 PD 分离单卡的 Decode 效率没提升整体收益也有限。1.2 三个技术的收益边界在哪里我在实际项目里做过一组粗略的对比用同一个 7B 级别的模型在单张 24G 显存的卡上跑输入 512 token、输出 256 token 的场景优化手段显存占用首 token 延迟单 token 生成耗时吞吐提升基线FP16约 14G380ms42ms1xINT8 量化约 8G340ms28ms约 1.5xINT4 量化约 5G320ms22ms约 1.9x量化 投机采样约 5G330ms14ms约 2.8x量化 投机 PD 分离约 5G/卡290ms12ms约 3.5x集群口径这组数据不是让你照搬因为不同模型、不同硬件、不同并发下差异很大但它能说明一个趋势量化的收益最直接、门槛最低投机采样对 Decode 的加速最显著PD 分离的收益要放到集群和高并发场景才体现得出来。三者是叠加关系不是替代关系。提示不要一上来就三个全上。先把量化做扎实确认精度损失可接受再考虑投机采样最后才是 PD 分离这种架构级改造。顺序反了排查问题会非常痛苦。2. 量化把权重和激活值瘦身的几种活法2.1 量化的本质是数值精度的重新映射量化的核心思想很朴素原来用 16 位浮点数存的权重现在用 8 位甚至 4 位整数来存显存占用直接砍半甚至砍到四分之一。但这里有个关键问题——浮点数的动态范围很大直接截断成整数会丢失大量信息。所以量化不是简单地把 float 转 int而是要找到一个缩放因子scale和零点zero point把浮点区间线性映射到整数区间。公式大概是这样real (int_val - zero_point) * scale。scale 决定了映射的粒度zero_point 保证了 0 能精确表示。听起来简单但实际做的时候是按整个张量算一个 scaleper-tensor还是按每个通道算per-channel还是按每组算per-group效果差别很大。per-tensor 最省事但精度损失最大per-group 精度好但元数据开销上来了。我一般建议权重用 per-channel 或 per-group激活值用 per-tensor这是比较稳妥的折中。2.2 训练后量化与量化感知训练的取舍训练后量化PTQ是最常用的路子模型训练完了拿一批校准数据跑一遍统计激活值的分布算出 scale 就完事。优点是快几十分钟就能搞定缺点是遇到分布比较极端的模型精度掉得厉害。量化感知训练QAT则是在训练过程中就模拟量化的误差让模型自己去适应精度通常更好但需要重新训练成本高。我的经验是7B 以上的模型做 INT8 PTQ精度损失基本可以忽略直接上就行要做 INT4尤其是 group size 比较小的时候最好还是用 QAT 或者至少用 GPTQ、AWQ 这类进阶 PTQ 方法。AWQ 的思路是保护那些对精度影响大的权重通道实测下来在 INT4 下比朴素 PTQ 稳不少。2.3 实操用现成工具做一次 INT4 量化以常见的开源量化工具为例流程大致如下。先准备校准数据一般从训练集或业务数据里抽 128 到 512 条就够了覆盖要尽量广from transformers import AutoModelForCausalLM, AutoTokenizer model_path your-model-path tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForCausalLM.from_pretrained(model_path, device_mapauto) # 校准数据准备这里用几条示例 calib_texts [ 大模型推理加速的核心在于减少访存开销。, 量化通过降低数值精度来压缩模型体积。, # ... 补充到 128 条以上 ] calib_inputs tokenizer(calib_texts, return_tensorspt, paddingTrue, truncationTrue, max_length512)然后调用量化接口指定 group size、是否对称量化等参数。group size 一般取 128对称量化在权重上更常见激活值则多用非对称。量化完保存加载的时候注意要用对应的量化后端否则会报错或者精度异常。注意量化后的模型加载时一定要确认推理框架支持对应的量化格式。我见过有人用 GPTQ 量化完结果用不支持 GPTQ 的框架加载权重被当成普通浮点读进去输出全是乱码排查了半天才发现是格式不匹配。2.4 量化踩坑那些文档里不会写的细节第一个坑是校准数据的分布。如果你用英文语料校准然后拿中文推理精度可能会掉得比预期多。校准数据最好和实际业务数据的分布接近这一点很多人忽略。第二个坑是KV 缓存的量化。权重量化了但 KV 缓存还是 FP16长上下文场景下 KV 缓存反而成了显存大头。现在有些方案支持 KV 缓存也做 INT8 量化收益很明显但要注意它对注意力精度的影响建议单独做消融测试。第三个坑是量化泄露未来信息这种说法**。** 这其实是某些量化交易领域的术语跟大模型量化不是一回事搜索的时候容易被带偏。大模型量化里没有这个概念别被误导。3. 投机采样用草稿换时间的并行艺术3.1 自回归生成的串行瓶颈Decode 阶段最要命的地方在于它是严格串行的生成第 n 个 token 必须等第 n-1 个 token 算完。这意味着无论你的 GPU 多强每个 token 的生成时间都下不来因为算力根本没用满瓶颈在访存和依赖上。投机采样就是冲着这个瓶颈去的。它的思路是用一个又小又快的草稿模型Draft Model先连续猜出 k 个 token然后用目标模型Target Model一次性并行验证这 k 个 token 对不对。如果猜对了就相当于一次前向传播生成了多个 token如果猜错了就从第一个错的位置重新来。关键在于验证是可以并行的因为目标模型一次性看到 k 个位置的输入能同时算出每个位置的输出分布。3.2 接受率决定了加速上限投机采样的加速比核心取决于接受率acceptance rate也就是草稿模型猜的 token 里有多少被目标模型认可。假设草稿模型每次猜 k 个 token平均接受 α 个那么理论加速比大约是α / (1 k * c)这种量级的关系其中 c 是草稿模型相对目标模型的计算开销比。草稿模型越小越快c 越小但接受率可能越低草稿模型越大接受率越高但 c 上来了。我实测下来草稿模型用目标模型的 1/10 到 1/5 参数量比较合适。比如目标模型 70B草稿模型用 7B目标模型 7B草稿模型用 0.5B 到 1B。k 一般取 4 到 8太大反而因为验证开销和接受率下降而不划算。3.3 几种投机采样的变体怎么选最基础的是Draft-Target 模式需要单独训练或准备一个草稿模型。好处是接受率高坏处是得多维护一个模型。还有Medusa 模式在目标模型上加几个额外的解码头并行预测多个未来 token不需要单独的草稿模型但需要训练这些头。另外还有Lookahead Decoding这类不需要额外模型的方法用 Jacobi 迭代来并行生成实现简单但加速比相对有限。选哪个取决于你的场景如果已经有现成的小模型Draft-Target 最省事如果不想维护两个模型Medusa 值得一试如果只是想快速验证效果Lookahead 门槛最低。3.4 实操中的参数调优与常见问题投机采样最容易出问题的地方是草稿模型和目标模型的 tokenizer 不一致。如果两个模型的词表不一样草稿模型猜出来的 token 在目标模型里可能根本不存在接受率会低得离谱。所以选草稿模型时优先选同系列、同 tokenizer 的。另一个问题是批处理下的收益衰减。单请求时投机采样加速明显但高并发批处理时因为验证阶段的计算量上来了加速比会下降。这时候要动态调整 k 值并发高的时候把 k 调小甚至关掉投机采样。# 伪代码示意根据并发动态调整投机采样参数 def get_speculative_config(batch_size): if batch_size 4: return {num_speculative_tokens: 8, enabled: True} elif batch_size 16: return {num_speculative_tokens: 4, enabled: True} else: return {num_speculative_tokens: 0, enabled: False}提示投机采样的加速效果和任务类型强相关。代码生成、翻译这类确定性强的任务接受率高加速明显开放式创作、闲聊这类多样性强的任务接受率低收益有限。上线前一定要用真实业务数据测。4. PD 分离把两种性格不同的任务拆开4.1 Prefill 和 Decode 互相拖累的根源前面说过Prefill 是计算密集型Decode 是访存密集型。如果把它们放在同一张卡上跑会出现很尴尬的局面Prefill 来了把算力吃满Decode 的请求就得排队首 token 延迟和 token 间延迟一起恶化Decode 在跑算力用不满Prefill 又插不进来GPU 利用率上不去。更麻烦的是Prefill 和 Decode 对显存的需求也不一样。Prefill 需要大 batch 来吃满算力显存占用高Decode 需要长期持有 KV 缓存显存占用也高但模式不同。混在一起调度器很难同时满足两边的需求。4.2 分离架构的核心设计PD 分离的思路就是把 Prefill 和 Decode 拆到不同的实例或不同的资源池上。Prefill 实例专门处理输入算完 KV 缓存后把缓存传给 Decode 实例Decode 实例专门做逐 token 生成。这样两边可以各自用最适合的并行策略和 batch 策略互不干扰。关键难点在于KV 缓存的传输。KV 缓存可能很大几十 MB 到几百 MB 不等传输延迟如果控制不好反而会拖累整体性能。所以 PD 分离通常要求节点间有高速互联传输要走 RDMA 这类低延迟通道。如果传输带宽不够分离带来的收益会被传输开销吃掉。4.3 什么场景下 PD 分离才划算PD 分离不是银弹。如果你的请求量不大或者 Prefill 和 Decode 的比例比较均衡分离带来的调度复杂度和传输开销可能得不偿失。它真正划算的场景是高并发、长输入短输出或者输入输出长度差异很大的混合负载。举个例子RAG 场景下输入可能几千 token输出只有几十 tokenPrefill 占绝对大头这时候把 Prefill 单独拆出来扩容Decode 用少量资源就够整体成本能降不少。反过来如果是长文本创作输出几千 tokenDecode 是瓶颈那就该重点优化 Decode 侧。4.4 落地时的调度与容错PD 分离落地时调度器要能感知 Prefill 和 Decode 实例的负载动态分配请求。Prefill 实例算完 KV 缓存后要能找到对应的 Decode 实例并完成传输。这里涉及一个请求路由的问题同一个请求的 Prefill 和 Decode 必须配对不能乱。容错也要考虑。如果 Decode 实例挂了已经传过去的 KV 缓存就丢了请求得重来。所以一般会做 KV 缓存的冗余或者快速重建机制。我见过有团队为了省事KV 缓存不落盘也不冗余结果一个节点抖动一批请求全部失败用户体验很差。场景特征是否推荐 PD 分离理由低并发、长短均衡不推荐调度开销大于收益高并发、长输入短输出强烈推荐Prefill 是瓶颈分离后可独立扩容高并发、短输入长输出谨慎推荐Decode 是瓶颈重点应放在 Decode 优化混合负载、长度差异大推荐分离后各自用最优策略5. 三者叠加时的相互影响与调优顺序5.1 量化会改变投机采样的接受率这一点很多人没意识到。量化后的目标模型输出分布和 FP16 时不完全一样草稿模型如果没量化两者分布差异变大接受率会下降。所以如果目标模型做了量化草稿模型最好也做同样的量化保持分布一致。我实测过目标模型 INT4、草稿模型 FP16 的情况下接受率比两者都 INT4 低了将近 15 个百分点。5.2 PD 分离下的量化策略差异Prefill 实例和 Decode 实例对量化的敏感度不同。Prefill 是计算密集量化带来的访存收益相对小但精度损失会直接影响 KV 缓存的质量进而影响 Decode。Decode 是访存密集量化收益大但精度损失会累积到每个生成的 token 上。我的建议是Prefill 侧可以用相对保守的量化比如 INT8Decode 侧可以激进一些INT4但都要做充分的精度验证。5.3 我推荐的调优顺序第一步先把基线跑通测出 FP16 下的首 token 延迟、token 间延迟、吞吐、显存占用作为对照。第二步上量化从 INT8 开始确认精度可接受后再试 INT4记录每一步的收益。第三步在量化基础上加投机采样调 k 值和草稿模型大小找到接受率和开销的平衡点。第四步如果并发上来了、单机扛不住再考虑 PD 分离先小规模验证 KV 缓存传输的延迟再逐步扩容。这个顺序的好处是每一步的收益都能单独归因出问题也容易定位。如果一上来三个全上性能不达预期时你根本不知道是哪个环节拖了后腿。注意每一步都要做精度回归测试。加速不能以牺牲效果为代价尤其是量化一定要用业务数据跑一遍评测集确认关键指标没有明显下降。6. 一些实测数据和踩坑记录6.1 量化精度损失的实测对比我在一个中文问答任务上做过对比用同一个 13B 模型评测集 500 条指标是回答的准确率和流畅度人工评分满分 5 分配置准确率人工评分显存占用FP1682.3%4.626GINT882.1%4.614GINT4 (group128)80.5%4.48GINT4 (group64)81.2%4.59G可以看到 INT8 几乎无损INT4 有轻微下降但可接受group size 越小精度越好但显存占用略高。这个权衡要根据你的显存预算来定。6.2 投机采样接受率的波动同样的模型和草稿模型在不同任务上的接受率差异很大。代码补全任务接受率能到 0.75 以上开放域闲聊只有 0.4 左右。这意味着投机采样在代码场景下加速比能到 2 倍以上在闲聊场景下可能只有 1.3 倍。所以不要盲目上投机采样先测你业务场景的接受率。6.3 PD 分离的传输延迟实测在小规模集群上测过 KV 缓存传输1MB 的缓存走普通网络传输要 8 到 10ms走高速互联能压到 1ms 以内。这个差异在高并发下会被放大因为每个请求都要传一次。所以 PD 分离对网络的要求很高网络不行的话分离反而更慢。6.4 几个容易忽略的配置项推理框架里有些配置项对性能影响很大但容易被忽略。比如max_num_batched_tokens它决定了单批最多处理多少 token设太小 GPU 吃不满设太大显存会爆。还有gpu_memory_utilization控制框架能用多少显存默认值往往偏保守适当调高能提升吞吐但要留足余量防止 OOM。这些参数没有万能值得根据你的硬件和负载慢慢试。7. 写给准备动手的你如果你现在正准备在自己的项目里做推理加速我的建议是别贪多。先把量化做扎实这是投入产出比最高的一步工具链也最成熟。量化做完观察一下瓶颈到底在 Prefill 还是 Decode再决定下一步。Decode 慢就上投机采样Prefill 慢或者并发上不去就考虑 PD 分离。还有一点监控一定要做在前面。首 token 延迟、token 间延迟、吞吐、GPU 利用率、显存占用、接受率、KV 缓存传输延迟这些指标要能实时看到。没有监控优化就是盲人摸象改了一个参数不知道是变好了还是变坏了。最后分享一个我自己的习惯每次调优只改一个变量改完跑固定的一批测试请求记录所有指标和上一次对比。这样积累下来你会对自己这套系统的脾气摸得很清楚遇到问题也能快速定位。推理加速这件事没有什么一招鲜靠的就是对系统每个环节的理解和持续的实测迭代。