5.2 进阶方向：MoE 量化、多卡分片、INT2 与更激进的压缩

5.2 进阶方向：MoE 量化、多卡分片、INT2 与更激进的压缩

讲完基础方案，这一节聊聊进阶方向。先打个预防针：我下面写的每个方向，要么是我自己在 POC 阶段、要么是看了一些团队的实践但还没大规模验证的。INT4 是已经被千锤百炼验证过的工程方案，但这些进阶方向还在快速演进，到 2026 年你读到这段的时候，有些方向可能已经成熟落地、有些可能被证明是死路。所以这一节不是"该怎么做的教程"，是"接下来值得往哪看的地图"。

方向一：MoE 模型的专属量化

DeepSeek V4 是 MoE 架构，这意味着它和稠密模型的量化策略不能完全照搬。MoE 的核心特征是"专家路由"——每个 token 只激活一部分专家，所以专家权重的使用频率是不均匀的。

我自己在量化 DeepSeek-MoE 系列时观察到一个现象：有些专家被频繁激活（"热门专家"），有些几乎不被激活（"冷门专家"）。如果一刀切地量化到同样的位宽，热门专家的精度损失会被放大（因为它承担了大部分计算），冷门专家则白白占了显存。理论上更优的策略是——热门专家保留高位宽（INT8 甚至 FP16），冷门专家量化到 INT4 甚至更低。这种"差异化量化"能让总显存占用和精度之间达到更好的平衡。

但这里有几个工程难点。第一，怎么识别热门/冷门专家？需要在校准集上跑一遍，统计每个专家的激活频率。校准集要够大、够有代表性，否则统计出来的"热门"是假的。第二，框架支持有限——主流的 AWQ/GPTQ 工具默认是 per-layer 配置，不支持 per-expert 配置，要做差异化量化得改框架源码或者自己写量化脚本。第三，路由决策本身也是动态的，今天的热门专家明天可能变冷门（如果业务分布变化），所以差异化量化配置有保质期，需要定期重新评估。

我自己做过一版 per-expert 差异化量化的 POC，结论是：在显存极其紧张的场景下值得做（能再省 15-20% 显存），但工程复杂度比一刀切量化高一个数量级，中小团队不建议碰。这块我比较看好的是框架原生支持的演进——当 AutoAWQ、GPTQ 这些工具直接支持 MoE 的 per-expert 配置时，这个方向就会从"前沿探索"变成"标准实践"。

还有一个 MoE 特有的方向是路由器量化。MoE 的路由网络（gate）参数很少但极其关键——路由错了，再好的专家也白搭。我的建议是路由器永远不要量化，保留 FP16 或者更高精度。这点 AutoGPTQ 和 AutoAWQ 默认配置不一定考虑到了，需要手动 check 配置。

方向二：多卡与多机分片

单卡装不下整个模型时，就必须上多卡分片。DeepSeek V4 这种规模，即便是 INT4 量化，单卡通常也不够，所以多卡几乎是必然选择。

多卡分片主要有两种方案，它们的取舍点完全不同：

张量并行（Tensor Parallel, TP）。把每一层的权重沿某个维度切到多张卡上，每张卡算一部分，再用 all-reduce 合并。优点是单请求延迟低（多卡并行算同一个请求），缺点是卡间通信开销大，对带宽敏感（PCIe 不行，要 NVLink）。适合单机多卡、追求低延迟的场景。

流水线并行（Pipeline Parallel, PP）。把模型的不同层分到不同卡上，请求像流水线一样依次流过每张卡。优点是通信开销小（只传激活值，不传权重），缺点是单请求延迟高（要等流水走完），而且容易有 bubble（流水线填充和排空阶段算力闲置）。适合跨机部署、追求吞吐的场景。

我自己的实践组合是 TP 单机 + PP 跨机。单机内的卡用 NVLink 互联，跑 TP 充分利用带宽；跨机的部分用 PP，避免以太网的高延迟拖垮 TP。这套组合在大模型分布式推理里几乎成了事实标准，DeepSeek V4 这种规模的模型基本都是这么部署。

坑主要在配置上。vLLM 里 --tensor-parallel-size 和 --pipeline-parallel-size 的组合要和实际硬件拓扑匹配——TP 跨节点（一台机器的卡和另一台机器的卡组 TP）基本是灾难，因为以太网延迟会让 all-reduce 慢到无法接受。我的规矩是 TP 永远限制在单机内，跨机只用 PP。还有就是 TP 的值要能被 attention head 数整除，否则会报 AssertionError: number of attention heads is not divisible by tensor parallel size，这种低级错误我也犯过。

多机部署的另一个大坑是网络配置。NCCL（NVIDIA 的集合通信库）对网络配置非常挑剔，IB（InfiniBand）和 RoCE（RDMA over Converged Ethernet）的配置差异巨大。我见过一个团队多机推理一直跑不快，最后发现是 NCCL 走了 TCP fallback 没用上 RDMA。排查方法是把 NCCL_DEBUG=INFO 打开，看 log 里是不是真的在用 RDMA。这种问题不查不知道，一查能耗一周。

方向三：INT2 与更激进的低位宽探索

INT4 已经是主流方案的当下限，再往下到 INT2 (2-bit) 就是真正的前沿。我自己对 INT2 是谨慎乐观——理论上有价值，工程上还不成熟。

INT2 的吸引力是显而易见的：相比 INT4 再省一半显存，对于 DeepSeek V4 这种千亿参数的模型，省下来的空间是几十 GB 级别的，意味着能跑更长上下文、能用更便宜的硬件。但 INT2 的代价也非常显著——精度损失急剧放大。简单的 round-to-nearest 量化到 2bit，模型基本就废了；要让 INT2 可用，必须配合更复杂的方案。

目前看 INT2 能用的方案大概有这么几类：

GPTQ + 2bit。GPTQ 这种基于二阶信息的量化方法在低位宽上比简单 RTN 强很多，但即便如此，2bit 的精度损失通常还是难以接受。我自己测过，2bit GPTQ 在通用任务上比 4bit 掉 10-15 个点的指标。

量化 + 蒸馏联合。把 2bit 量化后的模型作为 student，用原始 FP16 模型作为 teacher 做蒸馏，能补回一部分精度。这条路工程量大，但效果比纯后训练量化好。

稀疏化 + 量化。先把模型剪枝（去掉不重要的权重），剩下的权重再量化到更低位宽。难点是稀疏化和量化的交互很复杂，调优空间巨大。

专门的 2bit 算法。比如 AQLM、QLoRA 的某些变体，专门为 2bit 设计了更好的编码方式。这些方法效果比朴素 GPTQ-2bit 好，但框架支持有限、工程复杂度高。

我的判断是：INT2 在 2026 年还是研究性质多于生产性质。除非你的场景显存极度紧张（比如边缘设备、消费级硬件）并且能接受显著精度损失，否则 INT4 是更稳健的选择。INT2 真正成熟可能还要一两年，关键看框架原生支持的进展。

方向四：量化感知微调（QAT）

前面讲的量化都是后训练量化（PTQ, Post-Training Quantization）——模型先训练好，再量化。PTQ 的优点是简单（不需要训练），缺点是低位宽下精度损失大。

量化感知训练/微调（QAT, Quantization-Aware Training） 反过来——在训练/微调阶段就引入量化噪声，让模型在训练时就适应低精度表示，最终量化时损失更小。理论上 QAT 在任何位宽下都比 PTQ 精度更高，特别是 INT4 以下。

但 QAT 的代价是要训练，对算力和数据要求高。对于 DeepSeek V4 这种千亿模型，完整 QAT 几乎不可行（算力成本巨大），但量化感知 LoRA 微调是可行的——只对 LoRA 适配器部分做量化感知训练，主体模型保持量化状态。这条路有几个团队在走，效果比纯 PTQ 好，工程量也可控。

我自己做过一些 QAT 的实验，体感是：QAT 的收益在 INT8 不明显（INT8 PTQ 已经够好），在 INT4 有几个点的提升，在 INT2 提升最显著（可能从不可用变成勉强可用）。所以 QAT 的价值随位宽降低而上升——你越激进地量化，QAT 越值得做。

这块的难点在工具链。主流的 LoRA 训练框架（PEFT、TRL）对量化感知训练的支持还不完善，需要自己改训练脚本引入量化噪声。期待未来一两年这块的工具链成熟，让 QAT 变成 INT4 量化的标准配套而不是高级选项。

方向五：量化与推理框架的协同

最后一个方向是工程层面的——量化方案和推理框架的协同优化。这块最近两年进展很快。

最早量化就是"压缩权重，推理时反量化回 FP16 计算"，所以 INT4 的实际推理速度并不一定比 FP16 快（反量化开销吃掉了节省）。但现代推理框架开始支持原生 INT4 计算——权重以 INT4 存储、以 INT4 直接参与矩阵乘（用 tensor core 的 INT4 模式），完全省去反量化。这种情况下 INT4 不只是省显存，还能加速。

vLLM、TensorRT-LLM、SGLang 都在这块投入，但各家支持程度不一。TensorRT-LLM 在 NVIDIA 硬件上对 INT4/INT8 的优化最深，性能最好但灵活性差（绑死 NVIDIA）；vLLM 通过 Marlin kernel 实现了不错的 INT4 加速，灵活性更好。我的建议是：选量化方案时一定要考虑目标推理框架的支持情况，不要量化完了发现框架跑不起来。

还有 KV Cache 量化这个方向也属于协同优化。前面提过 FP8 KV Cache，能进一步省显存。但 KV Cache 量化对精度更敏感（因为它直接影响每个 token 的 attention），建议谨慎，先用 FP8 而不是 INT4。

写在最后

进阶方向讲到这里，我想强调一个判断：进阶不是必须，是选择。如果你的基础 INT4 方案能跑稳、能满足业务，那完全可以不碰这些进阶方向，省下时间做别的。我自己做量化部署，90% 的项目最终用的就是基础 INT4 + 合理的硬件，没碰任何进阶方案。

进阶方向的价值在两个场景：一是你的硬件约束极端（边缘设备、消费级硬件），不进阶就跑不起来；二是你想榨干最后一点性能/显存，愿意为此承担工程复杂度。其他场景下，基础方案的性价比是最高的。

最后一个建议——追前沿的时候，一定要保持对"实测"的执念。看到任何 paper 吹嘘 INT2 多好用、QAT 多提升，都拿自己的模型、自己的硬件、自己的测试集测一遍。领域变化太快，论文和实测之间永远有 gap，只有你自己的数据不会骗你。这本教程从头到尾强调的就是这件事：不轻信单一指标，不照搬他人参数，用自己的硬件和任务去实测、去取舍。INT4 是起点，但你能走多远，取决于你把这套方法论内化得多深。