去年我接手一个本地推理服务的优化任务，第一反应是换更强的显卡。结果很尴尬：换了显存更大的卡，单token生成速度几乎没有变化，只是能塞进更长上下文了。后来查了性能文档才明白，大模型推理的速度瓶颈往往不在峰值算力，而在显存带宽和调度策略——这也顺带让我把量化、投机采样、PD分离这三套技术从头到尾研究了一遍。它们是目前大模型推理加速里最常被同时提到的三条路线，但很多人（包括当时的我）容易把它们混为一谈：量化解决的是“单次前向太贵”的问题，投机采样解决的是“前向次数太多”的问题，PD分离解决的是“两种不同特性的计算互相拖累”的问题。三管齐下确实能明显提速，但前提是你要知道它们各自作用于哪一层，以及组合时有哪些坑。
这篇文章我就按自己的理解，把这三件事的底层逻辑、实际做法和取舍经验完整拆开讲一遍。不涉及复杂的推导公式，但会把关键的计算思路和工程判断讲清楚，适合正在做本地部署、私有化服务或者大模型应用上线的人参考。
1. 推理慢的根源：自回归结构下的“算力富余”与“带宽饥饿”
1.1 prefill 与 decode：两个阶段的核心矛盾
所有大模型推理加速技术，最终都要回到同一个根源问题：Transformer 是自回归模型，生成文本必须一个 token 一个 token 地串行输出。这段时间被分成两个截然不同的阶段。
第一个阶段叫 prefill，也就是用户输入 prompt 之后的“理解阶段”。模型要一次性读完整段输入文本，并行地计算所有输入 token 的注意力矩阵，把上下文信息加工成中间状态保存下来。这个阶段的特征是：计算量大、并行度高，非常吃 GPU 的矩阵运算单元。你可以把 prefill 理解为“一群人同时读一份长文件并做笔记”，过程中 CPU 和显卡的算力都是满载的。
第二个阶段叫 decode，也就是真正“逐字写答案”的阶段。每生成一个新 token，模型都要根据之前所有的 token 重新计算一次。但每一步只生成一个 token，计算量很小，真正花时间的反而是把权重从显存里读到计算单元里。这个阶段的特征是：显存带宽占用极高、并行度低、GPU 的算力利用率常常只有个位数。
我见过一个很反直觉的实测：一张 A100 跑 70B 模型，理论算力可以做到每秒几千 token 的矩阵运算，但实际 decode 阶段往往只有 20～30 token/s。差距不是算力不够，而是每一步都要把 140GB 的权重从显存搬到计算核心上，显存带宽才是墙。
所以要理解任何加速技术，先记住这条线：prefill 是计算密集（compute-bound），decode 是显存带宽密集（memory-bound）。这两者的瓶颈维度完全不同，解决方案也完全不同。很多人在调参时只看 GPU 利用率，看到算力低就觉得是显卡不行，其实大概率是带宽喂不饱。
1.2 用带宽公式看 decode 的瓶颈，以及量化的底层逻辑
把 decode 的带宽瓶颈算一笔账，会非常直观。
假设一个 70B 参数的模型用 FP16 存权重，意味着每个参数占 2 字节，总共约 140GB。在 decode 阶段，每生成一个 token，理论上都需要把这 140GB 权重读一遍。如果显存带宽是 2TB/s（A100 80GB 的大致水平），那么理想状态下每生成一个 token 需要约 70ms，换算下来每秒只能生成约 14 个 token。这还没算 KV Cache 的读取和其他开销。
现在你把这个模型的权重从 FP16 换成 INT4，每个参数只占 0.5 字节，权重体积直接降到 35GB。同样的带宽下，每 token 的读取时间降到约 17.5ms，每秒可以到 57 token 左右。看到了吗？**量化在 decode 阶段的加速倍数，几乎和显存体积的压缩比例成正比。**这也是为什么在大模型推理里，量化效果最明显的地方不是 prefill 而是 decode。
这也是很多人的一个认知误区：觉得量化只是“为了省显存”。省显存是结果，真正的收益是省显存带宽。显存放得下只是前提，带宽才是影响生成速度的关键。理解了这一点，你就明白为什么某些模型在显存明明放得下的情况下，量化之后依然变快了——因为每次读取的数据量变小了，带宽瓶颈被明显松绑。
而上下文长度对 decode 速度的影响也在这里体现：上下文越长，KV Cache 越大，decode 每一步要读的数据就越多。这也是为什么长上下文场景下，量化往往比换大显卡更有效。
2. 量化：用更少的比特换更快的 token，但远不是“砍一刀”那么简单
2.1 PTQ 与 QAT：量化方案的工作方式
量化，说白了就是用更少的比特位来表示模型参数和中间激活值。FP16 是 16 位，INT8 是 8 位，INT4 是 4 位。位数越少，存储和读取成本越低，但数值精度也越低，模型输出的质量可能受影响。
按工作方式，量化主要分两类。
第一类是训练后量化（PTQ，Post-Training Quantization），不需要动训练流程，直接把已经训练好的模型拿来量化。优点是成本低、速度快，几乎所有开源模型都能用。缺点是在极低位宽下容易掉点，尤其是对模型里的异常值敏感。GPTQ、AWQ、GGUF 里的各种 k-quants 基本都属于这个路线。
第二类是量化感知训练（QAT，Quantization-Aware Training），需要在训练或微调过程中就模拟量化过程，让模型适应低精度表达。效果好得多，但需要额外的训练资源和数据，工程成本高。一般不是个人能轻松玩转的。实践中更适合那些已经确定要长期部署的模型，在微调阶段就加入量化约束。
对于大部分部署场景，我建议先从 PTQ 入手。7B 模型用 INT4 GPTQ 或 GGUF 的 Q4_K_M，真的能保留绝大部分效果；13B、70B 这类大参数模型在 INT4 下也能保持不错的可用性，但要注意校准集选择。比如你用代码模型量化，最好用代码样本校准；用中文通用对话模型，就别拿英文评测集校准。很多人在这一步偷懒，直接用默认校准集，结果量化完的困惑度暴跌，还以为是模型的问题。
2.2 GPTQ、AWQ、GGUF：主流量化方法的原理对比
现在主流量化方法，我个人最常接触的是 GPTQ、AWQ 和 GGUF/K-quants 三大类。它们的思路差异很大。
GPTQ 的核心是逐层量化，用一种基于近似二阶信息的优化方法，在量化每一层权重时尽量补偿前一层带来的误差。你可以理解成：它不是对每个参数独立做四舍五入，而是把权重分成小块，每一块量化完之后，用剩下的误差去修正下一块，尽量让整体误差最小。这个方法对 GPU 部署很友好，量化完的模型可以直接被大多数 vLLM、TensorRT-LLM 等框架加载。
AWQ 走的是另一个思路，它不去复杂地优化每个权重，而是关注 activation（激活值）的分布。研究发现，模型里只有一小部分通道的激活值特别大，而这些通道对输出质量影响极大。AWQ 的做法是对这些重要通道给一个更大的缩放因子，减少它们被量化时的信息损失，从而用很低的成本保住模型精度。AWQ 的最大优势是量化速度快、不需要重训练，而且对小模型（比如 7B）的精度保持比 GPTQ 更稳。
GGUF/K-quants 则是 llama.cpp 生态里的格式标准，它适合 CPU 推理和苹果的 GPU，采用混合位宽策略，比如 Q4_K_M 就是部分张量用 4bit，部分关键张量用 5bit 或 6bit，在推理效率和精度之间取平衡。这也就是你在 Ollama、LocalAI 里经常看到的量化格式。它的优点是部署极简单，跨平台兼容性强；缺点是基于 llama.cpp 的生态，如果你的服务用的是 vLLM 这种 GPU 推理引擎，格式不一定能直接互通。
我自己的习惯是：本机单用户、CPU/Apple Silicon 用 GGUF/Q4_K_M；GPU 服务器上跑 vLLM 服务，优先 AWQ 或 GPTQ INT4；如果模型效果掉得太厉害，再试 INT8。INT8 的显存节省没那么夸张，但精度损失通常小到可以忽略。
2.3 我实际评估量化模型的几个标准
很多人评估量化效果，喜欢看跑分、看评测集，但我实践下来有几个更实用的标准。
第一，看长输出稳定性。一个量化模型在短回答里可能看不出差别，但让它输出几千字的长文时，可能因为数值误差累积出现重复、逻辑断裂、甚至符号错乱。这是我在部署过程中最常踩的坑。短对话测试通过不代表生成质量足够，一定要测长文本生成的连贯性。
第二，看对指令格式的遵循能力。量化后的模型在处理结构化输出（比如 JSON、表格、带缩进的代码）时更容易出格式问题。这个和模型家族的指令微调强度、量化位宽都有关系。如果目标是让它稳定输出可解析的 JSON，我建议至少用 INT8 或高质量 INT4 校准方案，否则解析失败率会明显上升。
第三，看 panic 场景。有些模型对中文输入特别敏感，量化后遇到繁体中文、生僻词、混合语言时会出现异常的重复或乱码。遇到这种情况，检查是不是量化时校准集里这些内容占太少；可以自己准备一批目标场景文本重新校准一次。
最后一定要记住：量化不是免费的午餐。INT4 确实快，但在一些复杂推理、数学计算、代码生成场景里，精度损失直接影响业务结果。宁可先用 INT8 保证效果，再把 INT4 当性能优化选项去测试。
3. 投机采样：让小模型打头阵，大模型做终审
3.1 投机采样的运作流程与接受率
假如你有一台 70B 的大模型，decode 阶段每一步要 70ms，一秒只能生成 14 个 token。想让它变快，常规思路是减少步骤——但自回归结构决定了每步只能出一个 token。
投机采样（Speculative Decoding）玩了一个很聪明的把戏：与其老老实实等大模型一步步出，不如让一个很小很快的 draft model（草稿模型）先连续猜出接下来几个 token，比如 4 个；然后让大模型在一次前向里同时验证这 4 个候选。
你可能觉得，一次前向验证 4 个位置，不是比原来更慢吗？关键区别在于，验证这 4 个 token 的位置，计算的并行度和 prefill 类似，可以在一次矩阵计算里同时处理，不像 decode 那样每步只能处理一个 token。而且验证顺序是：大模型算完这 4 个位置之后，从第一个和草稿不一致的地方截断，一致的前面部分直接接受，省下了多次串行走读权重的带宽瓶颈。
这里有个核心指标叫接受率（acceptance rate），表示草稿模型的猜测有多大概率被大模型认可。接受率越高，一次验证通过率的收益越大。举个例子：草稿模型猜了 4 个 token，大模型一次验证全都接受了，那这一步就直接省下了 3 次原本必须串行的 decode。如果接受率低，比如 4 个里只有 1 个是对的，那么验证后还是得从分歧点重新生成，折腾一圈可能比原来还慢。
所以投机采样能不能加速，本质上取决于草稿模型和主模型在目标分布上的重合程度。草稿模型猜得越准，收益越大。
3.2 加速比为什么能超过草稿模型本身的速度
这里有一个很多人不理解的点：投机采样后，整个生成速度可以逼近甚至超过草稿模型单独生成的速度吗？
答案是：可以接近，但不会超过，而且实际收益比想象中稳定。原因在于，草稿模型生成 4 个 token 的时间，远小于大模型生成 4 个 token 的时间。我们付出的额外成本是草稿模型那几十毫秒，换来的却是大模型少跑 3 次完整 decode。大模型一次 decode 可能要 70ms，草稿模型猜 4 步可能只要 5ms，这笔账非常划算。
有一个粗略的加速效果公式可以做直觉参照：假设草稿长度是 γ（比如 4），接受率是 α，那么平均每一轮能接受 αγ 个 token，而每轮需要一次大模型前向加一次草稿前向。理想情况下加速倍数可以约等于 γ 除以 (1 + (1-α)γ)，再考虑到草稿本身的时间损耗。α 是 0.8 时，γ=4 的理论加速倍率可以到 2 倍以上；α 是 0.5 时，收益会骤降到 1.3 倍甚至更低。所以选好草稿模型是第一优先级。
在实践中，我见过同一个 70B 主模型配一个 1B 到 7B 的同系列草稿模型，生成速度从 14 token/s 提升到接近 30 token/s。注意关键词是“同系列”。Llama 模型用同家族的 Llama 小模型做 draft，比用 Qwen 小模型稳得多，因为它们的 token 分布和词表结构更接近。跨家族做投机采样经常接受率惨淡，不如不开。
3.3 草稿模型选型与投机采样的失效场景
投机采样在工程上最容易被忽视的问题是：草稿模型也要占显存，也要吃带宽。你不能只算主模型省了多少步，不算草稿模型每一步的额外开销。如果显存已经逼近极限，强行塞一个草稿模型可能因为换入换出反而变慢。
草稿长度 γ 也不是越大越好。γ=2～4 是最常见的取值范围，过大时接受率会自然衰减，因为草稿模型猜得越远越容易错，而且大模型一次前向的显存占用也随之上升。我测试过 γ=8，效果反而比 γ=4 差，原因就是后半段候选基本被全部拒绝，白算。
还有两个典型的失效场景。第一，批量推理（比如服务端一次处理多个用户请求）时，投机采样的收益会被稀释，因为连续批处理引擎在每个迭代步骤已经融合了大量请求，单个请求的串行步数不再是瓶颈。第二，流式输出要求的首 token 延迟极低时，投机采样反而可能拖慢首 token 响应，因为它必须先等草稿模型跑完才能进入验证。
所以在判断要不要上投机采样之前，先问自己：你的场景是单用户、延迟敏感的聊天，还是高并发、吞吐优先的 API？如果是后者，建议把注意力放在 PD 分离和连续批处理上，投机采样优先级放低一些。这也是我一开始部署时踩的坑——服务一上并发，投机采样的收益几乎消失，还把显存吃了不少。
4. PD 分离：把 prefill 和 decode 拆到不同机器上，解决的是调度问题
4.1 一个线程里混跑 prefill/decode 会出什么问题
前面我说过 prefill 和 decode 是两种完全不同的负载。在一个统一的推理服务里，它们跑在同一批 GPU 上，就很容易互相干扰。
你可以想象一条流水线：用户 A 发来一段很长的 prompt，这个时候 prefill 阶段会占满整张卡的算力，要持续几百毫秒甚至几秒。而同一时刻，用户 B 正在进行 decode，他的 token 生成速度会被用户 A 的 prefill 拖慢，表现为 B 的回复突然卡顿。反过来，如果 decode 请求多，GPU 的显存带宽被大量占用，prefill 的矩阵运算也会被挤掉一部分带宽。
这种互相拖累的问题，在单用户本地部署里不明显，但在多用户服务里就是真实的体验问题。很多时候你加了显卡数量，却发现每个用户的延迟没有改善，就是因为算力被 prefill 的大块请求吃掉了，decode 的小步长请求始终得不到稳定资源。
传统批处理是凑够一批请求才启动一次前向，所有请求同生共死，一个长 prompt 能拖垮整批短请求。后来很多推理引擎引入连续批处理（continuous batching），允许每个迭代步动态加入新请求、移除已完成请求，长请求不会被整批卡死，但 prefill 和 decode 依然共用同一批显卡资源，只是从“互相排队”变成了“互相抢资源”。
4.2 PD 分离的架构与 KV Cache 传输难题
PD 分离就是从这个矛盾里长出来的架构方案：把 prefill 和 decode 两个阶段拆开到不同的 GPU 池或不同的实例上运行。
具体流程大概是这样的：一个请求进来，先被路由到 prefill 引擎，prefill 引擎一次性把长 prompt 处理完，计算出完整的 KV Cache；然后这个 KV Cache 通过网络传给 decode 引擎；decode 引擎只负责拿到 KV Cache 之后逐 token 生成，输出给用户。
这样做的好处很清晰。prefill 引擎的任务类型单一，可以用高算力的卡（比如 H100），把 batch size 拉大，并行处理一堆长 prompt，把计算密集的优势发挥到极致。decode 引擎的任务也单一，可以用高带宽的卡，不用频繁处理长 prefill，稳定输出每一个 token。两个引擎还能独立扩缩容：白天 prompt 多，prefill 池多开几台；晚上生成长文本多，decode 池多开几台。
但 PD 分离有一个绕不开的代价：KV Cache 传输。prefill 阶段算出来的 KV Cache 数据量非常大，和上下文长度成正比。一个 4K 上下文的请求，KV Cache 可能是几十 MB；扩展到 32K 甚至更长，就可能是几百 MB。把这些数据从 prefill 机器传到 decode 机器，网络带宽立刻变成新瓶颈。
工程上常见的解法包括：prefill 和 decode 节点尽量放在同一台物理机或同一个机架内；用 RDMA/InfiniBand 这种高带宽低延迟网络；还有更激进的做法是把 KV Cache 做压缩、量化后传输，到了 decode 端再解回来。另一个思路是设计成流式传输，prefill 刚产出一部分 KV Cache 就立刻传给 decode，decode 边接收边开始生成，不用等整个 cache 全算完。
这种架构能力一般出现在企业级推理系统里，像 vLLM、TensorRT-LLM 这些高吞吐引擎都有相关的实验性或生产级方案。个人本地部署就别想 PD 分离了，把 vLLM 的连续批处理和 prefix caching 调好，已经能解决大部分问题。
4.3 小规模部署的替代方案：连续批处理与前缀缓存
如果你和我一样，资源有限，跑不起多节点 prefill/decode 集群，也可以从单节点上找到“低配版 PD 分离”的思路。
首先是连续批处理。前面提过，它允许每个迭代步动态增删请求，从而避免长 prompt 请求长时间独占显卡。很多本地推理引擎默认已经开了连续批处理，但配置参数值得调。比如限制单次 prefill 的最大 token 数量，把长 prompt 切成小段分批处理；再比如给 decode 阶段设定更高的调度优先级，让已经生成的请求持续快速输出，而不是被新进请求挤掉。
其次是前缀缓存（prefix caching）。很多服务里用户的前几轮对话内容都是一样的，如果每次都从头 prefill 一遍，就白算了一大堆。前缀缓存会把重复 prompt 部分的 KV Cache 存下来，新请求进来时直接复用。这会大幅降低实际 prefill 的计算量，等于间接缓解了 prefill/decode 的资源争抢。我在部署长上下文产品时就发现，只要 prefix caching 命中率高，整体延迟能降低 30% 以上，这比直接加一张卡划算得多。
小规模部署还有一种土办法：把模型拆成两份，一份专门接受新请求做 prefill，完成之后把它占用的计算资源释放回共享池。本质上是一种手动的、按时间片进行的 PD 分离。虽然粒度粗，但在请求量不大时也能明显改善体验。等流量大了再上多实例真正的 PD 分离，成本曲线会更平滑。
5. 三招叠加的实战取舍：先量化，再分离，后投机
5.1 如何判断当前瓶颈在哪个环节
很多优化方法都是好方法，但用错场景就是负优化。我自己的经验是先定位瓶颈环节，再决定上哪套加速方案。
定位方法分三步。第一步，看显存占用和带宽。用 nvidia-smi 或性能分析工具观察 decode 阶段的显存带宽利用率，如果带宽长期接近峰值但算力利用率很低，说明是典型的 memory-bound，量化的收益会很大，此时优先做量化；如果带宽和算力都低，先确认是否是调度问题，比如 prefill 请求把 decode 阶段挤掉了。
第二步，看平均生成长度和并发量。如果用户问题很短、回答很长，decode 占比高，投机采样和量化都能带来体感提升；如果用户问题很长、回答很短，prefill 占比高，优先级应该放在前缀缓存和扩容 prefill 能力上。
第三步，看延迟目标。首 token 延迟敏感的，重点优化 prefill 速度和调度阻塞；整体吞吐优先的，重点优化 decode 带宽和批处理。滥用投机采样会在首 token 延迟上吃亏，滥用 PD 分离会在 KV 传输耗时上吃亏。
这里整理一个简表，方便你按图索骥：
| 技术方案 | 核心瓶颈 | 收益来源 | 典型风险 | 优先适用场景 |
|---|---|---|---|---|
| 量化 | 显存容量/带宽 | 权重体积压缩，decode 带宽压力降低 | 精度损失、格式兼容问题 | 显存不足、带宽受限的本地部署或高并发服务 |
| 投机采样 | decode 串行步数 | 一次前向验证多个 token，减少串行次数 | 草稿模型选错、批量场景收益稀薄 | 单用户、延迟敏感、草稿模型接受率高的场景 |
| PD 分离 | prefill/decode 资源争抢 | 两阶段独立调度，可分别扩缩容 | KV Cache 传输开销、架构复杂 | 多用户、长上下文、高并发企业级服务 |
| 前缀缓存/连续批处理 | 重复计算与调度阻塞 | 复用历史 KV Cache、动态调度请求 | 命中率低时收益有限 | 几乎所有服务端推理，特别是多轮对话 |
5.2 一个具体的组合配置参考
以我最近一个实践项目为例：12GB 显存的单卡机器，部署一个 7B 模型，面向单个实时对话用户，要求低延迟。我的配置思路是：
第一步，用 GGUF Q4_K_M 量化版模型，把权重体积从 14GB 压到 4GB 左右，留出大量显存给 KV Cache，允许更长的上下文。实测 decode 速度从 FP16 的约 25 token/s 提升到约 40 token/s。
第二步，在 llama.cpp 或兼容框架里开启投机采样，配一个同系列的 0.5B 或 1B 草稿模型。草稿模型吃掉的显存不到 1GB，但对单用户场景，实测输出速度能再提到 60～70 token/s。接受率大概在 0.7 左右，收益符合预期。
第三步，如果后续要接入多用户服务，我会上 vLLM 跑 AWQ 量化版，开启连续批处理和前缀缓存，同时把草稿模型关掉。因为多用户并发时，连续批处理的收益远大于投机采样。这正好印证了前面的观点——方案好坏取决于场景。
当然这只是参考，具体参数要结合你手上的模型、显卡和用户负载去调。量化并不总是越低位越好，投机采样也不是每个请求都能加速，建议每个环节都做一次 AB 测试，记录 p50 和 p95 延迟再做决定。
5.3 我踩过的几个坑和现在会怎么做
最后分享几个我实际踩出来的教训。
第一个坑是盲目追求低比特量化。我当时为了在 8GB 显存上跑 13B 模型，直接上 INT4，结果模型在长代码生成场景里频繁丢括号、漏缩进，根本不可用。后来改成把模型微调出更紧凑的版型，或者换 7B INT8，效果反而好得多。现在我的原则是：先保证结果质量，再看性能；量化位宽尽量选能接受的最低位，但永远留出对比测试的空间。
第二个坑是投机采样和批量服务的冲突。做 API 服务时，我把投机采样打开后上线，结果并发一高，整体吞吐反而下降，而且 GPU 内存多了一块草稿模型的开销。后来看了引擎日志才发现批量越大，投机采样能省下的串行步数越少，还不如把显存让给更大的 batch size。现在我只在单用户、交互式聊天场景里开投机采样。
第三个坑是 KV Cache 传输的忽略。当时我尝试用 PD 分离思路部署一个演示系统，结果 prefill 算完的 KV Cache 通过网络传输到 decode 节点，耗时几乎等于生成时间的一半，用户完全没感觉到变快。后来我把两个阶段部署在同一台物理机并关闭跨机传输，才真正看到收益。要评估 PD 分离的收益，一定要把网络传输时间算进总延迟里，不能只看各阶段的理想加速倍数。
第四个经验是关于工程分层。量化和 PD 分离属于“架构层”优化，补的是基础设施的短板；投机采样属于“算法层”优化，挑的是生成过程的结构性浪费。我的做法是先把架构层调稳，再上算法层。顺序反过来的话，很容易出现一种尴尬：算法优化带来的一部分收益，被架构层的调度抖动吃掉了，导致你根本判断不出方案有没有效。
如果你正在做类似的加速优化，我建议也按照这个顺序来：先量化，把显存和带宽成本降下来；然后调好批次和调度，让服务在并发下不互相拖累；最后再考虑投机采样这种更精细的加速手法。每一步都做前后对比测试，记录生成质量指标和延迟指标，而不是凭感觉调参。整套流程走下来，即便最后只提升了 30%，也不会是一笔糊涂账，因为你已经知道每一分性能是从哪里挤出来的。
