一位做端侧AI应用的朋友上周找我他要在16G显存的笔记本上跑35B模型问我有没有办法。我说有答案就是模型量化。模型量化这几年从不得已而为之变成了主流部署手段原因很直接同样的模型量化之后显存占用砍一半甚至四分之三推理速度还更快有时反而比原版更实用。这篇文章把我自己从 INT8 到 INT4、再到三元量化这条路上踩过的坑、算过的账、实测的数据整理出来给准备做模型压缩或本地部署的朋友一个参考。内容不会太学术更多是我实际跑下来是什么样的实话。1. 先把量化这笔账算清楚位宽、显存与精度的三角关系1.1 量化的本质用整数去逼近浮点深度学习的权重和激活值默认是 FP16 或 BF16 的浮点数。一个 FP16 数值占 2 个字节表达范围宽精度也细腻。但在推理的时候你会发现这些浮点数里有大量冗余信息——很多权重集中在某个小区间内没有必要用 16 位去表示。量化的核心思路就是找一个小的整数集合比如 INT8 的 256 个值或 INT4 的 16 个值用它们去逼近原来的浮点分布。我习惯用一个身高尺的例子解释给一群人量身高浮点表示等于精确到毫米而 INT8 量化等于把人群分成 256 个身高档每个人归到最近的档位。档位分得细高位宽误差小但存储多档位分得粗低位宽误差大但存储少。量化就是在档位数量和测量精度之间做权衡。具体到公式最基础的是对称量化q round(x / scale)其中 scale 由权重绝对值的最大值决定scale max(|x|) / (2^(bits-1) - 1)非对称加一个 zero pointq round(x / scale) zero_point实际工程里你不需要自己实现这些公式因为 GGUF、GPTQ、AWQ 这些方案已经把校准和映射做完了。但你作为使用者必须理解一个关键事实量化损失的是权重表达精度而不是模型结构。模型还是那个模型只是权重被压进了更小的表示空间。1.2 一张显卡能跑多大模型先算显存账很多朋友问我的显卡能不能跑某某模型我一般先甩给他们一张表。以 35B 参数为例精度每参数占用35B 权重占用FP16 / BF162 字节约 70GBINT81 字节约 35GBINT40.5 字节约 17.5GB三元量化约 0.2 字节约 7GB注意这个表算的只是纯权重。实际跑起来还有激活值、KV Cache、CUDA context。所以一张 24GB 的 4090 想跑 35B 模型FP16 想都不用想INT8 勉强但上下文稍长就爆INT4 是现实且舒服的选择。我给朋友的明确建议是先算清自己的显存预算再决定量化位宽。显存公式可以简化为总占用 ≈ 权重占用 KV Cache 占用 激活值开销KV Cache 又和上下文长度、batch size、层数、注意力头数直接相关。经验值一个 35B 模型INT4 量化后权重约 18GB4K 上下文的 KV Cache 大约还要 1~2GB所以 24GB 显卡跑起来是刚好够的16GB 就紧张了。1.3 位宽选择的实用分界线跑过的项目多了我总结出三个档位的适用边界8-bitINT8精度损失极小许多任务上和 FP16 几乎无异。适合对输出质量敏感、显存又不是特别紧张的场景。比如 7B 模型在 8GB 显存上跑 INT8权重 7GB 左右体验很好。4-bitINT4性价比最高的档位。显存直接砍到 FP16 的 1/4推理速度也快精度损失可控。当前绝大多数本地部署的 13B、30B、70B 模型主力档位就是 INT4。3-bit 及以下损失明显只适合特定模型或在显存极度受限时救急。下面要讲的三元量化属于另一个极端适用范围更窄。2. GGUF、GPTQ、AWQ三种主流量化方案的实测对比与选型思路2.1 GGUF / K-quant生态最全通吃 CPU 和 GPUGGUF 是 llama.cpp 项目带火的一种文件格式也是目前 Hugging Face 上量化模型最多的格式之一。它把模型权重、分词器、超参数打包成一个文件用 K-quant 这类方案做量化常见档位有 Q4_K_M、Q5_K_M、Q6_K、Q8_0 等。K-quant 在命名上有个规律Q 后面的数字是目标位宽K 表示使用了 K-quant 方法M 代表中间档。Q4_K_M 是 4-bit 量化里比较均衡的选择Q5_K_M 质量更高但体积大一些。实际使用中我通常拿 Q4_K_M 做能不能跑通的验证拿 Q5_K_M 做正式部署。GGUF 最大的优势是通用性。llama.cpp 的后续衍生项目如 Ollama、LM Studio都基于它CPU 推理、GPU 加速、CPUGPU 混合加载都支持。对用户来说下载一个 GGUF 文件丢给 Ollama 就能跑几乎没有门槛。代价是纯 GPU 场景下GGUF 的算子优化没有专用方案极致吞吐量未必比得上 GPTQ 或 AWQ。不过对一个普通用户来说这个差距通常感受不明显。2.2 GPTQ用二阶信息逐层压缩GPTQ 是最早在 GPU 上普及的 4-bit 量化方案之一。它和前者的思路很不一样不是简单做数值映射而是逐层去最小化量化后的输出误差。实现上GPTQ 利用 Hessian 矩阵损失函数对权重的二阶导数来估计每个权重的重要性量化时优先保留对输出影响大的权重把误差重新分配到其他层。这也导致 GPTQ 有两个特点第一量化过程比 GGUF 慢很多需要跑校准数据第二量化后的权重文件在 GPU 上有专门的内核支持如 exllama、AutoGPTQ推理速度快但对 CPU 就不友好。我在 7B、13B 模型上用过 GPTQ INT4生成质量确实能打。但它的坑在于校准集如果校准数据和你实际使用的数据分布差异大量化误差会放大。建议用代码类、对话类混合的校准集而不是单一语料。2.3 AWQ按通道感知重点保护敏感权重AWQActivation-aware Weight Quantization的核心观察是权重的重要性并不完全由权重本身决定还要看激活值的分布。某些通道的激活值很大这些通道对应权重即使被量化一点点输出的偏差都会被放大。AWQ 会识别这类显著通道量化时对它们做特殊缩放把保护资源用在刀刃上。听起来复杂使用体感却很简单AWQ 的校准流程和 GPTQ 类似但通常更快。推理时用的内核如 vLLM、AutoAWQ、llama.cpp 新版本兼容性越来越好。在多个模型上AWQ INT4 的精度和 GPTQ 相当有时还略高。2.4 一张表看完然后是我的选型习惯对比维度GGUFGPTQAWQ精度保持中上高高CPU 推理支持好弱弱GPU 推理速度中快快量化速度快慢中部署门槛低中中典型场景本地一键跑GPU 服务部署高吞吐服务我的个人习惯是这样的本地个人电脑优先 GGUF Q5_K_M省心GPU 服务器上长期跑的优先 AWQ INT4对某个模型特别看重输出质量的用 GPTQ INT8 对比测试再定。没有最好的方案只有最适合当前硬件和任务的方案。3. MoE 模型的量化特殊性35B-A3B 结构实战记录3.1 混合专家模型给量化出了三道难题这几年 MoEMixture of Experts混合专家模型越来越多思路是把大模型拆成多个专家子网络每个 token 只激活其中一部分。典型的例子是 Qwen3-30B-A3B总参数 30B但每次激活只有 3B所以推理速度比同等总参数的稠密模型快得多。这种结构对量化提出了额外挑战。我总结为三点第一路由层不能粗暴量化。路由器决定 token 去哪些专家它一旦量化误差变大token 可能被分到错误的专家后患无穷。第二专家的激活频率不均衡。MoE 里的专家有热门和冷门之分热门专家的权重会被频繁访问量化误差会被反复放大冷门专家的误差则被掩盖在低频使用中。校准过程如果让每个专家平均出力热门专家的误差没被充分优化效果就会打折。第三KV Cache 的占比结构变了。MoE 的注意力层往往比同规模稠密模型少KV Cache 相对小但长上下文时的总量依然不能忽略。量化后显存腾出来了很多人会把上下文拉得很长结果 KV Cache 反而成了新的瓶颈。3.2 实测Qwen3.6-35B-A3B-Apex-MTP-I-Compact 的量化全流程最近社区里热度很高的 Qwen3.6-35B-A3B-Apex-MTP-I-Compact就是典型的 MoE 大模型。名字里拆一下重点35B 是总参数量A3B 表示激活参数约 3BMTP 是多 token 预测Multi-Token PredictionApex 是版本代号Compact 说明做了压缩优化。这类带 Compact 标记的版本往往官方已经做了部分结构精简本身就比标准版更适合量化部署。我做了一次完整的量化推演与实测目标环境是 24GB 显存、CPU 为 16 核、不做任何额外加速卡。流程是先拿到原始 BF16 权重跑了几个标准样例记录生成质量基线。用 AWQ 做 INT4 量化校准集混合了代码、通用对话、数学三类数据共 128 条左右。加载量化后的模型继续跑同样的样例对比输出。结果在意料之中BF16 版本 24GB 显存直接吃满加载到一半就开始告急AWQ INT4 量化后权重占用大概 18GB 出头加上 KV Cache24GB 显卡能在 4K 上下文下流畅运行。生成速度稳定在每秒 30~40 token和 BF16 版本对比没有明显速度下降。最关键的是生成质量在代码补全和逻辑问答两个测试 sets 上量化版基本保持了原版的水平个别回答出现细节简化但没有结构性错误。MTP 机制在多 token 预测下对长文本连贯性有正向帮助这个优势即使在量化后也还在。3.3 三个实战中遇到的坑第一个坑不要对路由层做激进量化。有人为了再省点显存把路由层也压到 4-bit结果 token 路由错乱率上升生成开始循环重复。我的建议是路由层保持 8-bit 或直接不量化。第二个坑校准集要覆盖足够多专家。我刚开始用纯代码数据校准结果模型在处理对话时明显变笨了。加回通用对话数据后恢复正常。原因就是纯代码数据没有均匀激活所有专家。第三个坑量化后一定要重测长文本。MoE 模型的长上下文行为可能和短文本差异很大。我踩过一次模型在 2K 上下文下一切正常拉到 8K 后开始丢失前面的关键信息排查发现是 KV Cache 的量化相关配置没跟上。现在我的流程是量化后必跑一组长短文本对比测试。4. 三元量化不是万能药1.58-bit 的适用边界4.1 BitNet b1.58 到底在做什么先说结论三元量化ternary quantization不是把普通模型再降一个档位它需要模型在训练阶段就适配这种极限精度。代表方向的 BitNet b1.58把权重约束在三个值-1、0、1。权重只有三种可能存储开销约等于 1.58 bit/参数比 INT4 又省了一大半。为什么是 1.58 而不是 2因为三值本身可以编码 log2(3) ≈ 1.58 bit 的信息量。这里有个数学直觉当你把权重压缩到三个值矩阵乘法中大量运算变成了加法甚至条件判断这在 CPU 和端侧设备上有巨大的速度优势。以我的实测为准一个 7B 级别的三元量化模型在消费级 CPU 上跑token 生成速度能接近甚至超过 GPU 上 INT4 的普通模型——这在以前是不敢想的。但代价也很明确权重被压缩到三个值信息容量急剧下降。模型能记住的知识变少推理链变短复杂逻辑容易断裂。三元适合的场景是轻量调用、功耗敏感、任务简单不适合高难度的数学推理、长文写作和复杂多轮对话。4.2 三元量化的实操体验成也极端败也极端我最早是在一个 1.5B 的小模型上试水的先按 BitNet 的方案做了重训练适配再量化到三元。效果让我意外小模型在某些基础任务情感分类、关键词提取、简单事实问答上的表现甚至比同尺寸的 4-bit 普通模型还好。原因在于它是在三元约束下训练的权重分布本身就更适合这种表示不存在先训练后压缩带来的损失。但我又做了一个对比实验拿一个现成的 7B 稠密模型不做任何适配直接强行三元化。结果很惨生成的内容基本是词语碎片连完整句子都组不出来。这验证了一个重要观点三元量化不是压缩手段而是训练范式。你必须在模型设计阶段就决定要不要走这条路。4.3 三元、INT4、FP16 的实际差距指标FP16INT4三元每参数占用2B0.5B~0.2B7B 模型权重体积~14GB~3.5GB~1.4GB精度表现基准接近基准明显下降适用任务通用大部分场景简单任务CPU 推理友好度低中极高端侧部署友好度低中极高这张表是我反复测出来的。结论如果目标是跑一个能用、不笨的通用助手INT4 是底线如果目标是嵌入式设备、电池驱动、任务固定三元方向值得投入。中间地带没有特别好的折中方案。5. 开源量化模型排名表背后的真实信息5.1 榜单怎么读同模型比档位跨模型比意义社区里经常能看到开源模型量化档排名这类榜单。我的读榜经验很简单同一模型的不同量化档位之间排名有参考价值不同模型之间的横向排名参考意义极其有限。原因在于评测集差异。有的榜单用标准 benchmark如 MMLU、C-Eval有的用困惑度perplexity有的干脆是社区用户投票。标准 benchmark 对量化误差敏感用户投票则更关注生成时是否明显变傻这种体感。这两者在排序上经常冲突。举一个实测例子一个模型在榜单上 INT4 排第 20 名INT8 排第 15 名差距 5 名——这基本可以忽略。但如果 INT4 比 FP16 排名掉了超过 10 名说明这个模型对量化不友好要么换方案要么换模型。5.2 选量化模型时我必查的四个检查点第一显存占用看实际推理峰值不要只看文件大小。模型文件 18GB加载后 KV Cache 一长24GB 显卡一样爆。第二上下文长度对量化的影响必须测。有些量化档位在 2K 上下文下没问题拉到 8K 就开始漂移。长文本场景是量化精度问题的放大器。第三确认量化后是否保留对话和指令能力。有的量化版本只做了基座模型没做对齐部分导致聊天体验明显下降。下载页面上如果写了base和chat两个版本优先选 chat 衍生版本量化。第四看社区反馈里有没有崩坏报告。下载页面评论区是最真实的情报来源。如果一个量化版本下面有大量生成乱码突然输出无关内容的反馈那大概率是量化参数适配没做好换别的方案。5.3 一个朴素但好用的选择策略我自己的选型流程概括成一句话先定硬件边界再定任务类型最后才看量化方案。硬件边界是显存和算力任务类型是我要它做什么。如果只是做文本摘要INT4 足够如果做代码生成建议 INT8 起步如果是数学推理尽量保住 BF16 或找更高质量的量化方案。还有一种很实用的策略同一个模型准备 INT8 和 INT4 两个量化版本在不同节点上用。我的项目就这么干边缘设备分发 INT4中心节点用 INT8。成本几乎可以忽略但应对场景变化时非常从容。最后分享一个小技巧。量化完成后别急着上线先跑一组 100 条的验收测试集包含代码、摘要、对话、数学四类任务每类 25 条把输出和原版模型对比。这不是理论洁癖而是我踩过太多次显存省了模型蠢了的坑。量化这件事省下来的显存只是开始模型变得如何才是决定成败的关键。