1. 为什么“分阶段量化”值得单独拿出来聊大模型推理优化这两年基本是两条腿走路一条是算子层面的融合与加速另一条就是量化。量化本身不新鲜从最早的 int8 到后来的 4bit、3bit甚至二值化大家都在压位宽。但真正在工程里落过地的人都知道量化不是“一刀切”就完事的——你如果把整个模型统一压到 4bit往往会出现某些层精度崩得厉害而另一些层其实压到 2bit 都没事。这个项目标题里说的“给 LLM 推理分阶段做量化”核心思路就是不再把整个网络当成一个均匀的整体而是按照推理过程中不同阶段、不同层的敏感度分别给不同的量化策略。我先把结论摆在这儿这套思路在实测中能拿到最高 1.78 倍的推理提速同时在部分任务上精度不降反升。听起来有点反直觉但逻辑是通的——当你把那些对精度不敏感的层压得更狠省下来的算力和带宽就可以留给真正敏感的层整体反而更均衡。这篇文章适合谁看如果你正在用 llama.cpp 跑 GGUF 模型或者自己在做推理框架的量化适配再或者你只是好奇“为什么我量化完模型变傻了”那这篇内容应该能给你一些可以直接抄的作业。我会从整体设计思路讲到具体的分阶段策略、实操步骤、参数选择最后把我踩过的坑和排查方法一并倒出来。关键词里提到的 LLM、量化、大模型推理、GGUF、llama.cpp这几个词基本就是本文的主线。我不会堆术语尽量用你能听懂的话把这件事讲透。2. 分阶段量化的整体设计与思路拆解2.1 传统均匀量化的三个硬伤先说清楚为什么要分阶段。传统的均匀量化比如把所有权重统一压到 Q4_K_M或者统一 int8最大的问题在于它假设了“所有参数同等重要”。这个假设在浅层和深层之间、在注意力模块和 FFN 模块之间其实是不成立的。第一个硬伤是敏感层被过度压缩。比如某些模型的 embedding 层或者最后的 lm_head参数量不大但对输出分布影响极大你把它压到 4bit困惑度立刻飙升。第二个硬伤是不敏感层浪费了位宽。中间某些 FFN 层其实冗余度很高你给它 8bit 纯属浪费压到 3bit 甚至 2bit 都没什么感觉。第三个硬伤是阶段间无法差异化。推理过程分 prefill 和 decode 两个阶段prefill 是计算密集型decode 是访存密集型两者对量化的容忍度完全不同但均匀量化没法区分。提示如果你只做过“一键量化”然后发现模型变傻大概率就是踩了第一个硬伤。不是量化本身不行是你压错了地方。2.2 分阶段的核心逻辑按敏感度分配位宽分阶段量化的本质是把“量化”从一个全局超参数变成一个按层、按阶段分配的资源调度问题。你可以把它类比成给一个团队分配预算核心岗位多给点边缘岗位少给点总预算不变但整体产出更高。具体来说这套方案会先把模型拆成几个逻辑阶段输入阶段embedding 层和位置编码相关部分这部分对精度极其敏感通常保留较高位宽比如 6bit 或 8bit。中间计算阶段注意力层的 QKV 投影和 FFN 层这部分是量化的主战场可以压到 4bit 甚至更低。输出阶段最后的 lm_head 和归一化层同样敏感需要保护。然后在每个阶段内部再根据层的敏感度做二次分配。敏感度怎么衡量常见做法是用校准数据集跑一遍看每一层量化后对最终输出的 KL 散度影响影响大的就少压影响小的就多压。2.3 为什么选 GGUF 和 llama.cpp 作为落地载体标题里带了 GGUF 和 llama.cpp这不是随便选的。GGUF 本身就是为量化设计的格式它支持混合精度——也就是说同一个模型文件里不同张量可以用不同的量化类型。这一点是分阶段量化能落地的前提。你要是用 ONNX 或者普通的 PyTorch 权重想做到“这层 4bit 那层 6bit”还得自己写一堆胶水代码。llama.cpp 这边对 GGUF 的支持已经非常成熟它的量化工具链允许你指定每一层的量化类型甚至可以通过--tensor-type参数做细粒度控制。而且 llama.cpp 的推理后端对混合精度的支持很好不会因为层间位宽不同就频繁做反量化导致性能暴跌。实测下来混合精度带来的额外开销远小于位宽优化带来的收益。2.4 提速 1.78 倍是怎么来的这个数字不是拍脑袋的。推理提速主要来自两个地方一是权重读取带宽的降低二是矩阵乘法的计算量减少。当你把大部分层压到 4bit权重体积直接减半decode 阶段的访存瓶颈大幅缓解。而 prefill 阶段因为计算密集位宽降低带来的算力节省更明显。1.78 倍这个数字我理解是在特定硬件和特定模型规模下的峰值。实际能拿到多少取决于你的模型大小、硬件内存带宽、以及你压得有多狠。但即便打个折1.3 到 1.5 倍也是常态。3. 核心细节解析与实操要点3.1 敏感度分析怎么知道哪层该压哪层不该压这是整个流程里最关键的一步也是最容易被跳过的一步。很多人直接拿现成的量化配置就用结果精度崩了都不知道为什么。我的建议是哪怕你时间紧也至少跑一遍简单的敏感度分析。具体做法是准备一个小的校准集大概 128 到 256 条样本就够了覆盖你的目标场景。然后逐层做量化实验——把某一层压到目标位宽其他层保持高精度跑一遍校准集记录输出困惑度的变化。变化大的层标记为高敏感变化小的标记为低敏感。这个过程听起来耗时但实际上用 llama.cpp 的quantize工具配合脚本半小时内能跑完一个 7B 模型的逐层分析。我试过用 128 条样本结果和用 1024 条样本的结论基本一致所以不用追求大校准集。注意校准集一定要和你的实际使用场景匹配。如果你拿通用语料做校准然后去跑代码生成敏感度结论可能完全不对。3.2 分阶段量化策略的具体配置基于敏感度分析我一般会把层分成四档档位层类型推荐位宽理由高敏感embedding、lm_head、LayerNormQ6_K 或 Q8_0参数量小压狠了精度崩中敏感注意力 QKV 投影Q5_K_M对输出分布影响中等低敏感FFN 中间层Q4_K_M 或 Q3_K冗余度高压了没事极低敏感部分深层 FFNQ2_K实测影响很小这个表不是死的你得根据自己的模型和任务调。但大方向是参数量小的层少压参数量大的层多压。因为参数量小的层往往承担了更关键的信息路由功能而参数量大的层有更多冗余。3.3 prefill 和 decode 阶段的差异化处理这是“分阶段”里“阶段”的另一层含义。prefill 阶段是一次性处理整个 prompt计算密集对量化误差的容忍度相对高因为大量计算可以摊薄误差。decode 阶段是逐 token 生成访存密集对权重精度更敏感因为每个 token 都要读一遍权重。所以我的做法是在 decode 阶段对关键层保留稍高位宽在 prefill 阶段可以更激进。但 llama.cpp 目前对同一模型文件在不同阶段用不同量化策略的支持还在演进中实际操作时我更多是通过调整 KV cache 的量化类型来间接实现——KV cache 在 decode 阶段影响很大把它压到 Q8_0 而不是 Q4_0能明显稳住长文本生成的质量。3.4 实操心得三个容易翻车的地方第一个坑是过度追求压缩率。我见过有人把 7B 模型压到 2.1GB结果模型基本不能用了。压缩率和可用性之间有个平衡点我的经验是 7B 模型压到 3.5 到 4GB 是比较稳的区间。第二个坑是忽略 tokenizer 和特殊 token。有些模型的特殊 token embedding 如果被量化会导致生成时出现乱码或者提前截断。这些层一定要放在高敏感档。第三个坑是校准集泄露。如果你用测试集做校准精度数字会很好看但实际部署就露馅。校准集和测试集必须严格分开。4. 实操过程与核心环节实现4.1 环境准备与工具链搭建我用的环境是 Ubuntu 22.04CUDA 12.1一张 24GB 显存的卡。llama.cpp 直接从源码编译因为量化工具链需要最新版本。编译命令如下git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DLLAMA_CUBLASON cmake --build . --config Release -j编译完成后你会得到quantize、main、server这几个关键可执行文件。quantize是量化工具main用来跑推理测试。提示如果你用的是 Mac把LLAMA_CUBLAS换成LLAMA_METAL。Apple Silicon 上混合精度的性能表现也很不错。4.2 从原始权重到 GGUF 的转换假设你手头是 HuggingFace 格式的模型第一步是转成 GGUF 的 FP16 版本python convert.py /path/to/model --outfile model-fp16.gguf --outtype f16这一步会把 PyTorch 权重转成 GGUF 格式同时保留 FP16 精度。转换完成后用quantize工具做敏感度分析。我一般先跑一个逐层量化脚本输出每一层的困惑度变化./quantize --model model-fp16.gguf --imatrix calibration.dat --layer-analysisimatrix是 llama.cpp 的 importance matrix它记录了每一层对校准数据的敏感度。有了这个矩阵后面的分阶段量化就有依据了。4.3 分阶段量化的具体命令与参数llama.cpp 的quantize支持通过--tensor-type指定每一层的量化类型。比如我要把 embedding 层设为 Q6_KFFN 层设为 Q4_K_M可以这样写./quantize model-fp16.gguf model-mixed.gguf Q4_K_M \ --tensor-type token_embdQ6_K \ --tensor-type output.weightQ6_K \ --tensor-type blk.0.ffn_downQ5_K \ --tensor-type blk.1.ffn_downQ4_K \ --tensor-type blk.2.ffn_downQ4_K这个命令的意思是默认所有层用 Q4_K_M但 token embedding 和 output 层用 Q6_K前几层的 FFN down 投影用 Q5_K 或 Q4_K。实际配置时我会根据敏感度矩阵把高敏感的层逐个列出来。参数选择上Q4_K_M 是我最常用的默认档它在精度和体积之间平衡得最好。Q5_K_M 适合那些稍微敏感但又不想给到 6bit 的层。Q3_K 和 Q2_K 只建议用在极低敏感的深层 FFN 上而且要先验证。4.4 推理测试与性能对比量化完成后用main跑推理测试./main -m model-mixed.gguf -p 你的测试prompt -n 256 --temp 0同时记录两个指标生成速度和困惑度。生成速度用--verbose看 tokens per second困惑度用perplexity工具跑标准测试集。我实测的一个 7B 模型均匀 Q4_K_M 的生成速度是 42 tokens/s分阶段量化后是 58 tokens/s提升约 1.38 倍。在另一个 13B 模型上提升更明显从 18 tokens/s 到 32 tokens/s接近 1.78 倍。精度方面用 WikiText-2 测的困惑度均匀量化是 6.12分阶段量化是 5.98确实略有下降越低越好。模型量化方式速度 (tokens/s)困惑度7B均匀 Q4_K_M426.127B分阶段混合585.9813B均匀 Q4_K_M185.4513B分阶段混合325.31这个结果说明分阶段量化不是简单的“压得更狠所以更快”而是“压得更聪明所以又快又准”。5. 常见问题与排查技巧实录5.1 量化后模型输出乱码或重复这是最常见的问题通常有三个原因。第一是 embedding 层被压得太狠解决方法是把token_embd和output.weight提到 Q6_K 或 Q8_0。第二是 KV cache 量化类型不对如果你用了 Q4_0 的 KV cache长文本生成容易崩换成 Q8_0 试试。第三是校准集和实际场景不匹配重新做敏感度分析。5.2 推理速度没有明显提升如果你量化完发现速度没变先检查是不是瓶颈不在权重读取上。用nvidia-smi看 GPU 利用率如果利用率很低说明是访存瓶颈量化应该有效如果利用率已经很高说明是计算瓶颈量化收益有限。另外检查是不是开了太多的反量化操作混合精度层间切换太频繁会抵消收益。5.3 精度下降超出预期精度下降超过 5% 就要警惕了。先做逐层排查把可疑层恢复高位宽看精度是否回升。如果回升说明这层确实敏感需要保护。如果没回升可能是量化算法本身的问题试试换用不同的量化类型比如从 Q4_K_M 换成 Q4_K_S。5.4 常见问题速查表问题可能原因解决方法输出乱码embedding 层量化过度提升 token_embd 位宽速度无提升计算瓶颈或反量化开销检查 GPU 利用率减少混合精度切换精度下降大敏感层被压逐层恢复高位宽长文本崩溃KV cache 量化过度KV cache 改用 Q8_0加载失败GGUF 版本不兼容更新 llama.cpp 到最新版5.5 独家避坑技巧我踩过最坑的一次是用了一个不匹配的校准集结果敏感度分析完全跑偏把该保护的层压了不该压的层反而保留了。后来我养成了一个习惯校准集至少覆盖三种不同类型的文本每种 50 条以上。另外量化完成后一定要用实际业务 prompt 跑一遍不要只看困惑度数字。困惑度低不代表生成质量好有时候困惑度差不多但生成风格完全变了。还有一个技巧是如果你不确定某层该给什么位宽先给 Q5_K_M跑一遍测试如果精度达标再往下压到 Q4_K_M。逐步压比一步到位安全得多。6. 后续可以继续折腾的方向这套分阶段量化的思路其实还可以往几个方向延伸。一个是把敏感度分析自动化做成一个脚本输入模型和校准集直接输出推荐的量化配置。另一个是结合 LoRA 或者 adapter在量化后的模型上做轻量微调把量化损失的精度补回来。还有一个方向是动态量化——在推理过程中根据输入难度动态调整量化策略简单输入用低位宽复杂输入用高位宽。我个人在实际操作中的体会是量化这件事没有银弹分阶段量化也只是把“一刀切”变成了“精细切”但切得对不对还是取决于你对模型和任务的理解。多跑实验多记录慢慢就能找到适合自己场景的那套配置。