做过大模型推理优化的朋友应该都有同感：模型规模越来越大，单张A100/H100的显存和算力却成了最金贵的资源，推理延迟和吞吐怎么也压不下来。尤其在线上服务里，长prompt请求一多，首字延迟飙升，整个batch都被拖住。今天我想结合自己做线上推理服务优化和基于nano-vllm源码调优的经历，系统聊聊目前工业界最常用的三板斧：量化、投机采样、PD分离。这三项技术分别对着显存瓶颈、显存带宽瓶颈和计算调度瓶颈下刀，理解清楚它们的原理和适用边界，比单纯抄配置参数重要得多。文章不会只贴结论，我会把每个方案背后的算账逻辑和实操踩过的坑一并写出来，适合正在做模型部署、推理引擎二次开发，或者准备给生产环境做性能调优的同学参考。
1. 先搞清楚推理到底慢在哪：PreFill 和 Decode 的瓶颈差异
1.1 一次推理请求的两个阶段，性能特征完全相反
大模型生成回答的过程不是一锅炖，而是被严格切成两个物理阶段：PreFill（预填充）和 Decode（逐token生成）。
PreFill阶段做的事情是把用户的完整prompt一次性灌进模型，走一遍完整的自注意力计算，把中间产生的Key和Value缓存下来（也就是KV Cache）。这个阶段是典型的计算密集，矩阵乘法的规模很大，GPU的算力利用率是高走的。你输入一篇几千字的文档，PreFill可能也就几百毫秒到一两秒，跟后面的Decode时间完全不成比例。
Decode阶段则是每次只生成一个token，生成方式是把新token拼到KV Cache后面，再做一次自回归推理。单次推理的计算量极小，但权重和KV Cache都得完整过一遍显存带宽。瓶颈从算力转移到了HBM带宽上。以A100为例，80GB显存的总带宽约2TB/s，一个7B模型FP16的权重就有14GB，就算把全部带宽都拿去读权重，每秒最多也就过约140次权重，理论token峰值大约就在这个数量级。所以Decode阶段经常看到吞吐上不去，不是GPU算不过来，是显存带宽不够搬数据。
1.2 为什么逐token生成这么“慢”？从算力利用率的账说起
简单算一笔账。一个7B参数模型，FP16精度下权重约14GB。A100 40GB版的显存带宽约1.5TB/s，H100 SXM约3.35TB/s，H20的带宽虽然高一些但算力相对弱，所以很多人说H20是“带宽卡”。如果我们用静态batch为1跑，每生成一个token，GPU要把14GB的权重读一遍。就算用足带宽，每秒钟能发起的token生成次数也有上限：1.5TB/s除以14GB大约是107 token/s，这还没算KV Cache读取和计算本身的时间。实际跑起来，很多自研推理引擎单流Decode速度就在这个理论值附近徘徊。听起来很慢对吧？但这就好比食堂只有一个窗口，每个人来打饭的时候厨师都得重新翻一遍菜谱才知道怎么做，瓶颈根本不在炒菜的手速，而在于翻菜谱的时间。
所以推理优化的本质任务就两个：一是让模型更“小”，省得每次翻菜谱都花那么大功夫——这是量化干的活；二是在不牺牲正确性的情况下少翻几次菜谱——投机采样干的就是这个；三是让不同就餐需求的人分开排队，别让打自助餐的和吃套餐的人互相堵——这就是PD分离的价值。
1.3 区分场景：你是被延迟卡住，还是被吞吐卡住？
很多人在优化前没有先明确自己到底被什么卡住，导致选错了技术方向。这里分三类典型场景：
- 交互式对话/Agent编排：用户在线等，要求TTFT尽可能低。这类通常被PreFill的长输入所拖累，或者被同batch里的其他长序列挤占。适合优先做PD分离，把长文本处理挪到单独的prefill节点。
- 离线批处理/数据生成：不要求单条快，只看总吞吐。这类适合大batch连续运行，量化能明显提升每秒钟处理的请求数。
- 边缘部署/个人电脑跑模型：显存极其有限，优先量化到INT4甚至更低位，把模型装进显存是第一位，速度反而是其次。
判断方法也很简单：先做一轮profiling。如果GPU利用率长时间不到50%，大概率是访存瓶颈或调度等待；如果KV Cache OOM或者batch一涨就崩，那是显存管理问题；如果单条请求慢但GPU打满，才是算力不够。不同的病得下不同的药，下面这三板斧正好各有对应。
2. 量化：用精度换通量，但这件事没那么简单
2.1 量化为什么能加速？三个层面各自起作用
量化的核心思路是把权重从FP16/FP32压缩到INT8、INT4甚至更低，从而在运行时获得三重收益：
第一重，也是立竿见影的：显存占用大幅下降。7B模型FP16约14GB，量化到INT4大约4GB左右，这意味着单卡能塞下更大的模型，或者在同一张卡上给KV Cache和并发请求腾出更多空间，batch size可以往上提。
第二重：访存带宽压力变小。前面算过，Decode阶段是带宽瓶颈，权重变小后，单token生成需要搬运的字节数变少，decode速度理论上能跟着翻倍。比如7B模型从14GB降到4GB，相同情景下生成速度可能提升近3倍（前提是没被其他环节卡住）。
第三重：算子计算在某些硬件上有专门加速。比如INT8的Tensor Core在A100/H100上吞吐是FP16的两倍，INT4配合特定格式在某些推理引擎里也能获得不错的计算加速。不过对Decode这种访存密集阶段来说，主要收益还是前两点。
2.2 主流量化方案横向对比：GPTQ、AWQ、GGUF、FP8
主流路线分两大类：训练后量化（PTQ）和量化感知训练（QAT）。训练后量化里，行业内实际部署用得最多的就下面这几个：
| 方案 | 位宽 | 典型工具链 | 特点 | 适用场景 |
|---|---|---|---|---|
| GPTQ | 4bit/3bit/2bit | GPTQ-for-LLaMA、AutoGPTQ | 基于二层近似误差最小化，逐层校准 | NVIDIA GPU、TensorRT-LLM中使用广泛 |
| AWQ | 4bit | AutoAWQ、vLLM | 激活感知，按通道重要性保护显著权重 | 通用性好，速度与精度平衡 |
| GGUF | 2~8bit | llama.cpp、Ollama | 量化粒度细，支持CPU/GPU混合运行 | 本地部署、跨平台 |
| FP8 | 8bit | TensorRT-LLM、vLLM | 几乎无损，硬件原生支持 | 高端数据中心卡 |
从我的实践经验看，如果目标是跑在vLLM/TensorRT-LLM这类大引擎上，AWQ和GPTQ是主流里的主流，AWQ在INT4下保留的精度通常略好一点，因为它不是简单最小化量化误差，而是根据激活值分布保护对输出影响最大的权重通道。GGUF则更灵活，但算子适配、KV Cache量化和vLLM的兼容性要花精力去排查，适合Ollama这类轻量级出版场景。
还有一点不能忽视：KV Cache本身也可以量化。在长上下文场景里，KV Cache可能占据几十GB显存，把它从FP16压到FP8或INT8，往往能让有效batch size翻倍。vLLM和SGLang里都有开关（比如--kv-cache-dtype fp8），但对精度损失要亲自测试，尤其是长上下文和复杂推理任务。
2.3 量化实操中要注意的坑：精度下降、异常token、张量并行
量化不是简单的“压一压”就完事。实际部署中有几个最容易翻车的地方：
第一，校准数据集不能乱选。GPTQ和AWQ都需要一小部分校准数据来调整量化参数。如果校准数据跟实际业务数据分布差异很大，量化后的模型在业务场景上精度掉得会特别厉害。我有一次用通用对话数据校准的模型，放到RAG场景里，检索相关性一塌糊涂，后来换了一批包含长文档和结构化知识的样本重新量化才恢复正常。
第二，INT4对某些能力的影响不可忽视。数学计算、逻辑推理、特殊token输出（比如JSON格式的括号、代码缩进）这些任务对精度敏感度极高。4bit量化后模型经常“一本正经胡说八道”。建议上线前做针对性的能力评估，不要只看困惑度或几个通用benchmark。如果发现敏感能力损失，可以考虑混合精度方案：关键层保留FP16，其他层用INT4。
第三，推理引擎的算子支持不统一。同一个量化模型，在vLLM里跑得好好的，换到llama.cpp可能因为某些自定义算子不支持而性能骤降甚至报错。部署前一定要检查目标引擎的量化算子覆盖，尤其是自定义模型结构和新增模块的情况。
第四，张量并行与量化的配合。多卡推理时，量化模型的分片方式和显存负载分布需要重新评估。有些引擎对量化模型的TP（Tensor Parallelism）实现有额外通信开销，在2卡以下可能反而比单卡慢。小规模部署时先测单卡，别盲目上多卡。
3. 投机采样：让“蹩脚”小模型当排头兵
3.1 投机采样的核心思想：用另一个小模型帮你猜答案
投机采样（Speculative Sampling）的思路乍一听有点奇怪：用一个很小的草稿模型（draft model）先猜出接下来的几个token，再用大模型一次性验证这些草稿。如果草稿猜得对，那这些对的部分就省掉了大模型逐token生成的时间；猜错了也没关系，大模型在验证过程中已经拿到足够信息来纠正错误，保底不会比正常生成差。
这里面的关键是：大模型验证多个token的成本，远小于逐token生成相同数量token的成本。因为验证过程在batch维度上把这些候选token一起算，而生成过程是串行走步的。在数学上，只要草稿模型的接受率（accept rate）高于一个阈值，投机采样的期望延迟就低于标准自回归解码。这个阈值主要由草稿模型速度和大模型验证的开销决定。
打个比方就很好理解了：你写代码时不直接让面试官逐行看，而是先在草稿纸上写个大概版本，面试官一次性扫一遍，哪里不对改哪里。草稿只是猜测，面试官才是最终裁决者，最终答案的正确性有保障。
3.2 工业界主流实现：EAGLE、Medusa、Lookahead Decoding
投机采样不是只有一个模板，围绕“怎么生成一个好的草稿序列”衍生出了多种方案：
- EAGLE（及其后续版本）：不直接用单独的小模型做草稿，而是把大模型前一层的高维特征拿来当输入做自回归草稿预测，接受率达到很高水平。它是目前在LLaMA系列上效果最好的投机采样方案之一，vLLM已经支持。
- Medusa：在模型顶端加多个并行解码头，让大模型自己一次性猜多个位置的token，不需要额外的小模型，但需要微调模型结构。
- Lookahead Decoding：不引入任何草稿模型，纯粹从输入序列中找重复片段做猜测，在代码生成这类重复率高的任务上非常有效。
- 单独草稿模型方案：主流思路还是轻量级同架构小模型（比如70M不到的LM Head蒸馏模型），可以直接和主模型共用一个KV Cache前缀，接受率也不错。
从部署角度讲，EAGLE方案在vLLM里开箱即用的概率最高，代码解耦也做得比较干净。如果你在做二次开发，这个切入成本最低。
3.3 实测数据和调参经验：草稿长度、接受率、batch的影响
把投机采样部署到生产环境前，有几个参数是必须调的：
第一个是草稿长度（draft length）。太长，小模型猜后面大概率越来越不准，大模型验证代价反而变大；太短，省下的时间不够覆盖验证开销。vLLM里speculative_max_draft_len默认值通常是5或者更高，但我实测在多数对话场景下，4到8个token的草稿长度性价比最高。具体得画一条延迟-长度曲线自己找拐点。
第二个是接受率。不同业务场景差异巨大。代码生成、JSON结构化输出这类规律性强的任务，接受率能到0.7以上；自由对话、创意写作这类熵高的任务，经常只有0.3~0.5。而且接受率会随温度变化——温度越高，采样随机性越大，草稿模型越难猜。我建议固定业务场景后专门跑一批数据把接受率测出来，再决定要不要加投机采样。
第三个是草稿模型的参数选择。草稿模型太大，它自己生成草稿的速度优势就没有了；太小，猜不准。实际经验是草稿模型速度至少要比主模型快5到10倍才有部署价值。对于7B主模型，几百M级别的草稿模型往往就够了；对于70B主模型，可以试试3B量级的草稿模型。
还有个大坑要提醒：投机采样在batch size比较大的时候优势会明显减弱。因为大batch本身就是把很多请求拼在一起算，访存带宽已经被权重复用摊薄了，草稿模型节省的那些权重读取在整个batch开销里占比下降。如果你们服务长期跑在batch size 64甚至更高的水平，投机采样带来的加速比可能从1.8倍掉到1.1倍，这时候不如去优化量化或调度。
4. PD分离：别让长Prefill拖垮在线Decode
4.1 为什么要把Prefill和Decode分开部署？
前面提到，PreFill是计算密集，Decode是访存密集。如果把两者放在同一个GPU实例上处理，问题就来了：一个吃满算力的长PreFill请求，会把同实例上所有正在Decode的请求的调度周期全部挤占掉。GPU是并发计算设备，但它同时执行大量小kernel时，Decode的小请求们得排队等大kernel跑完。结果就是单个长RAG文档请求一进来，整批对话服务的TTFT集体飙升，体验断崖下跌。
PD分离（Prefill-Decode Disaggregation）的答案很直接：把这两个阶段拆到不同的实例节点上。PreFill节点专职干重计算，快速吃完所有输入并产出KV Cache；Decode节点专职做低延迟的自回归生成，不再被大kernel打断。听起来简单，工程上其实涉及整条推理链路的重构。
4.2 PD分离的架构形态与工程挑战
PD分离在工程上的形态大致有三类：
- 同机双卡分工：一个GPU专职PreFill，另一个专职Decode，通过共享显存或高速总线传KV Cache。适合单机环境验证，但灵活性一般。
- 机内多实例调度：同一台机器上划分prefill和decode的GPU组，调度器根据请求长度动态分配。这种方案实现成本适中，兼顾一定扩展性。
- 跨机分布式PD分离：prefill和decode节点分布在不同机器上，通过RDMA/网络传递KV Cache。这就是行业内常说的“分离式推理”或微服务化推理架构，能灵活伸缩，但对基础设施要求最高。
这套架构的核心难点是KV Cache的跨节点传输。一个长序列的KV Cache可能是几十MB甚至上百MB，如果传输链路不做专门优化，传输耗时可能把PreFill省下来的时间全部吃回去。业界常用的优化手段是：KV Cache量化传输（把FP16压到FP8再传）、异步预取（decode节点提前准备）、和基于“预测性调度”的缓存复用（同一前缀的多个请求共享KV Cache副本）。
还有一个调度层面的老问题：如何决定一个请求先去prefill节点还是直接去decode节点？线上经验是给每个请求设置一个长度阈值。比如输入小于512 token的对话请求，可以直接在decode节点内完成整个推理；大于阈值的RAG/文档分析请求，才走PD分离链路。阈值定多少，得根据你们业务的实际输入长度分布来测算。
4.3 PD分离的实际收益：延迟、吞吐和QoS的平衡
从我接触的部署案例看，PD分离最大的价值不是单点测速变快，而是性能的可预测性和隔离性变好了。在你没说清楚需求之前，很多团队都观察到类似现象：平均延迟还行，但P99尾延迟惨不忍睹。原因就是偶发的长Prefill请求把Decode节点上的小请求周期性“打嗝”。PD分离之后，Decode节点上的计算负载变得非常均匀，P99能稳在一个相对低的水平上，这对SLA敏感的线上服务特别关键。
吞吐方面，分离后PreFill节点可以做更大的动态batch，因为不用再顾及Decode阶段的时延敏感；Decode节点可以做成纯吞吐型服务，用Continuous Batching把带宽吃满。两者整体吞吐一般比混合部署高20-40%，具体幅度取决于业务里长输入的占比。
不过PD分离也绝对不是万能药。如果你们的请求平均输入长度都不到一两百token，prefill本身就很快，分离架构的网络传输和调度开销反而会得不偿失。另外，跨机部署一定要考虑好KV Cache序列化格式、背压策略和故障恢复机制。预制好这些，再微调也不迟。
4.4 实际部署后的性能数据参考
拿一套我实际跟进的配置举例：主模型是7B规模，原来单机混跑时，长文档请求占整体请求的5%，结果P99 TTFT能到6秒多，因为每次长请求出来都会抢占公共kernel资源。后来做了PD分离，prefill节点专用处理长输入，decode节点用连续批处理跑短对话，整体P99降到了1.8秒左右，吞吐也有明显缓解。具体数字没法直接套用到所有环境，但能明显感受到隔离带来的收益。
需要补充的是，PD分离之后单个token的生成延迟不会变快，甚至因为网络传输可能略微增加平均延迟。它优化的是系统级的稳定性指标，也就是P99/P95，而不是P50。如果你的核心诉求是单请求尽量快，PD分离不是首选；如果你的诉求是高并发下不让大家体验集体劣化，那它比任何其他单项优化都值得优先上。
5. 三者的协同策略：先测瓶颈再选武器
5.1 哪种优化优先级最高？按场景对号入座
很多人拿到这三个技术清单就开始“全都要”，这是不对的。实际项目里应该按瓶颈来选：
| 瓶颈表现 | 首选技术 | 备选技术 |
|---|---|---|
| 显存OOM / 模型塞不进 | 量化（INT4/FP8） | 模型剪枝、减少KV Cache预留 |
| Decode吞吐上不去 | 投机采样 | KV Cache量化、批处理优化 |
| 长输入导致尾延迟高 | PD分离 | 输入降采样、缓存相似前缀 |
| 算力打满但延迟高 | 量化/投机采样 | 优化算子、减小batch |
一句话总结：显存不够先量化，带宽不够想投机，稳定性不行上PD分离。
另外有一个很容易忽略的点：量化和投机采样之间存在一定的“代偿关系”。如果权重已经量化到INT4，大模型的Decode速度本身已经很快，那么投机采样的相对收益会被摊薄。因为它省的同样是“读权重的时间”，权重越小，省下的时间越少。反过来，投机采样的草稿模型如果也量化了，可能因为精度下降反而接受率变差。所以组合使用时务必要把每个环节的收益单拆开来测。
5.2 组合使用时的链路设计和参数配置参考
以vLLM为例，一套典型的组合方案长这样：
python -m vllm.entrypoints.openai.api_server \ --model Qwen2.5-7B-Instruct-AWQ \ --quantization awq \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --speculative-config '{"model": "Qwen2.5-1.5B-Instruct"}' \ --speculative-max-draft-token-len 8 \ --kv-cache-dtype fp8 \ --enforce-eager这里做了三件事：主模型AWQ量化降低权重体积；挂一个1.5B草稿模型做投机采样；KV Cache用FP8压缩。这套组合在对话场景下实测，比未优化的FP16基线能快2到3倍，同时显存占用少了近一半。我自己测试时候的经验是：先把量化和KV Cache量化做掉，看显存和单流速度；再加投机采样看是否还有额外收益；最后如果尾延迟还是不达标，再上PD分离。顺序不能乱，不然你分不清楚到底是谁带来的收益。
5.3 别忽视推理引擎版本和内核的影响：在线数据的持续校验
最后也是最重要的提醒：推理加速技术在论文里的效果跟生产环境的效果经常是两码事。原因是引擎版本、CUDA版本、GPU型号都会影响算子的实际性能。比如某些旧版本的vLLM对EAGLE的调度实现不成熟，可能造成接受率高但整体延迟反而变差的情况；新版本重写了内核后又完全不一样。
所以我强烈建议，所有优化完成后必须做持续性的在线校验。不光是延迟和吞吐指标，更要监控生成质量的变化。量化模型加投机采样，如果某个上游任务的准确率悄悄掉了几个点，可能一段时间内都不容易发现。在自己的推理服务里定期捞一批线上真实样本做质量回归对比，把困惑度、任务准确率、拒绝率这些业务指标纳入监控，这是上线优化时最容易被忽略但整条链路最不该省的环节。
6. 常见问题与排查技巧实录
6.1 量化后输出质量明显变差怎么定位？
排查顺序我一般是这样：先确认是量化本身导致的还是校准数据选错了。把原始FP16和量化模型放到同一批评测集上并固定temperature=0，逐条对比输出。如果FP16也差，那就是数据或任务本身的问题，别甩锅给量化。如果只有量化版本差，去看校准集与业务数据的分布差异，换校准样本再量化一次。还不行，就考虑混合精度：把跟推理强相关的层（比如注意力层和最后几层）设为FP16，其余用INT4。最后的手段才是换位宽或换方案，从AWQ换GPTQ或者反过来再测一轮。
6.2 投机采样的开启后反而变慢？
这是最常见的返工问题。依次排查：
- 是不是batch size已经很大？大batch下投机采样收益本来就稀薄。
- 草稿模型和主模型的tokenizer是否完全一致？不一致会导致前缀不匹配，接受率骤降。
- 温度是否很高？温度越高接受率越差，可以试试把草稿模型的采样温度调低（甚至greedy）而主模型保持高温。
- 有没有做prefix caching？如果草稿模型和主模型不共用前缀缓存，草稿生成的开销会额外增加。
- 草稿长度是不是设得太长？降到4或5再测。
6.3 PD分离后网络延迟反而成为新瓶颈？
跨机PD分离最容易栽在KV Cache传输上。排查时先测量单次KV Cache传输耗时占整体TTFT的比例，如果超过10%，优先做三件事：启用KV Cache量化传输（FP8）、开启NVLink/RDMA建链、改造为异步传输模式让decode节点边收边算。另外还要确认序列化格式，不要用JSON这类文本格式搬二进制权重，要用自定义二进制协议。
6.4 显存管理：KV Cache OOM怎么快速缓解？
先把gpu-memory-utilization调高，但这只是治标。真正的解法是：开启PagedAttention/Continuous Batching（vLLM默认支持，但要注意block大小设置），启用KV Cache量化，以及用投机采样降低有效生成token数。如果模型是FP16但显存被权重撑爆，那量化权重是第一步。如果只是并发高导致KV Cache满，可以限制最大并发数、设置请求超时，让长连接及时释放。
6.5 常见问题速查表
| 现象 | 最可能的原因 | 快速解法 |
|---|---|---|
| 量化模型在数学任务上崩溃 | 4bit精度不足 / 校准集不含此类任务 | 混合精度、换AWQ、关键任务用fp16备用服务 |
| 投机采样接受率低于0.3 | 草稿模型过小 / 数据熵高 | 换更大草稿模型、降低温度、增加草稿长度 |
| P99延迟高但平均延迟正常 | 长Prefill抢占Decode | 上PD分离或限制单请求长度 |
| GPU利用率极低但CPU忙 | 调度/数据预处理瓶颈 | 检查tokenizer并行、换引擎版本 |
| 多卡TP后性能反而下降 | 通信开销大于计算分摊收益 | 减少TP卡数、换NVLink组网 |
| 显存提示OOM但实际占用不高 | 碎片化 / 缓存未清理 | 调block size、重启引擎定时回收 |
7. 实操总结与后续扩展
我自己的体会是，大模型推理优化的方法论跟调试业务代码很像：先定位瓶颈，再选工具，最后用数据验证，别光凭经验拍脑袋。量化、投机采样、PD分离，每一项技术都在某些场景下有奇效，但把它们当成银弹去生搬硬套，往往会收获“优化了个寂寞”的结果。
最后再分享两个小技巧：第一，优化时永远先建立可复现的基准测试集，把输入长度分布、batch策略、采样参数都固定下来再动刀，不然代码一改动，你根本分不清延迟变化是来自优化还是来自流量波动。第二，推理优化是一个持续迭代的过程，建议把这三个技术都封装成引擎内部的开关配置，线上压测通过A/B切换逐步放量，而不是一口气全量替换。这样即使某个优化在实际业务上翻车，你也能快速回滚，把损失控制在最小范围内。
后续如果想继续深入，推荐沿着几条线延伸：一是关注KV Cache量化plus长上下文结合的调度策略；二是研究投机采样和并行解码在LoRA服务化场景里的应用（不同LoRA adapter对接受率影响很大）；三是把PD分离踩熟之后，再去看基于请求级调度的全局优化方案。推理引擎没有银弹，但把骨架搭对了，很多性能问题其实都能提前规避掉。
