部署一个 MoE 结构的模型最头疼的往往不是算力不够而是显存带宽被各种专家参数加载打得抬不起头。最近我把 Kimi 2.7 MoE 从 FP16 裸奔状态切到了 W4A84bit 权重存储 INT8 激活计算效果比我预想中更直接显存占用降了约四倍单卡能塞下一个本来要四卡才能装下的模型同时输出速度也有了接近两倍的提升。这篇文章不打算讲那些放之四海皆准的量化科普而是围绕4bit 存储和INT8 激活这条真实链路把 MoE 推理优化中容易忽略的细节、踩过的坑、以及 W4A8 背后真正的收益来源一次说透。这套方案适合谁如果你手头有一个 MoE 大模型显存吃紧、吞吐上不去或者你正准备把模型部署到消费级显卡上但还在纠结是用 AWQ 还是 GPTQ、要不要上 FP8那这篇内容应该能帮你省下不少试错时间。我会把注意力放在为什么 MoE 特别吃带宽4bit 存储到底省了哪部分钱INT8 激活的风险来自哪里这几个关键问题上最后给出一份可以直接照抄的量化与推理配置参考。1. 为什么 MoE 推理会卡在带宽而不是算力1.1 MoE 与 Dense 模型在访存行为上的本质差异传统 Dense Transformer 模型前向推理时每一层所有参数都要被完整读一遍所以一个 7B 模型加载 FP16 权重就是 14GB显存多大决定你能不能跑起来。但 MoEMixture of Experts模型不一样它的结构特点决定了访存行为完全不同。Kimi 2.7 MoE 这类模型总参数里既有共享的 Attention 和 MoE 层共享参数也有大量稀疏专家参数。每一次前向Token 只会激活一小部分专家而不是把所有专家的权重全部读一遍。这里出现了一个关键矛盾虽然单次前向的计算量因为稀疏性变小了但显存访存却依然和总参数量绑定在大米里。特别是当模型总参数很大、激活专家数相对较少的时候每次 Token 都要经历一次把专家参数从显存搬到计算单元的过程。搬数据的耗时可能远大于真正做矩阵乘的耗时这就叫 memory-bound。拿我自己部署 Kimi 2.7 MoE 的实测数据来说FP16 下显存需求逼近 6GB/卡具体参数量不同会有差异但运行时 GPU 利用率经常只有 30%~50%。不是 GPU 算得慢而是显存带宽根本喂不饱计算单元。这种情况下单纯加卡、加算力收益会非常有限。真正有效的方法是减少访存量也就是把权重从 16bit 压到 4bit。1.2 4bit 权重为什么能直接缓解这个矛盾如果权重用 4bit 存储那么从显存搬运到计算单元的数据量就变成原来的 1/4。FP16 是 2 字节4bit 是 0.5 字节一比就是 4 倍差距。对于 MoE 这种访存密集型模型来说这个差距会直接影响 token 生成速度而不只是影响显存大小。我用一个简单的公式来表达推理延迟的瓶颈构成延迟 ≈ 访存时间 计算时间 访存时间 ≈ 权重读取量 / 显存带宽如果计算时间远小于访存时间那么权重读取量减小 4 倍延迟就能接近 4 倍地下降。实际部署中因为还有激活量化、kernel 调度等开销达不到理论 4 倍但我实测从 FP16 切到 W4A8 后batch1 的生成速度大约提升了 1.8~2.2 倍batch 增大后提升倍率稍有回落但依然显著。这个收益的本质来源就是 4bit 存储砍掉了 MoE 最大的痛点——参数搬运。2. W4A8 的真实含义4bit 存储不等于 4bit 计算2.1 W、A、bit 数分别控制什么W4A8 这套术语读起来像是 W 和 A 的 bit 数越低越好其实完全不是。W 是 Weight权重A 是 Activation激活数字代表的是量化后数据的位宽但关键点在于存储位宽和计算位宽可以不一样。在 W4A8 配置下权重以 4bit 存储在显存里这意味着搬运开销小。但激活值比如输入 token 的 embedding、中间层的 hidden state会用 INT8 参与矩阵乘。为什么要用 A8 而不是 A4因为激活值如果也压到 4bit精度损失会非常严重。激活值分布不是固定的不同 Token、不同 Layer 的数值范围变化很大量化粒度很难控制。而权重是静态参数可以花很多时间做 Calibration用 group-wise 的方式逐段量化精度损失能压得很低。所以 W4A8 本质上是用权重的大幅压缩换取访存优势同时用激活的 INT8 保证计算效率并尽量保住精度。真正运行时权重 4bit 会被临时反量化成高精度数值再和 INT8 激活做矩阵乘而不是强行用 4bit 的权重去乘 INT8 的激活。2.2 推理时权重是怎么反量化回来的大多数推理框架无论是 vLLM、llama.cpp 还是自研 kernel都遵循一个类似的流程加载权重时把存储的 uint4/int4 值按照量化参数scale 和 zero point反量化为 FP16/BF16。这一步通常在 kernel 内部完成不需要先把所有权重解压回 FP16 存到另一份显存里否则就失去了 4bit 的意义。如果 kernel 支持混合精度计算权重反量化后的 FP16 值直接与 INT8 激活做 GEMM累加结果以 FP32 形式结算再写回目标 dtype。如果 kernel 把权重也进一步转成 INT8那就可以做纯 INT8 GEMM但这一步会引入额外的权重量化误差。我在实际测试中发现对 MoE 模型来说纯 INT8 GEMM 的收益并不明显反而容易在专家边界处掉点。所以 W4A8 方案里常用做法是权重只做存储压缩计算仍用 FP16 精度。一个简单的 W4A8 GEMM 伪代码思路如下# 伪代码只为说明数据流 # W_q: (M, K) 的 4bit 量化权重W_scale/W_zero: (M, group) # A: (N, K) 的 INT8 激活A_scale/A_zero: (N, block) for m_block in range(M // BLOCK_M): for n_block in range(N // BLOCK_N): # 从显存加载 4bit 权重块 - 显存带宽开销小 w_bf16 dequantize(W_q[m_block], scale, zero) # int4 - bf16 a_int8 load_activation(A[n_block]) # already int8 acc matmul_bf16_int8(w_bf16, a_int8) # 或转成 fp16 后混算 result[n_block, m_block] acc * (a_scale * w_scale)这段伪代码看似简单但它反映了 W4A8 最重要的数据流设计权重永远以低比特形式躺在显存里只有在进入计算单元时才临时解压。这样既保证了访存优势又不会因为计算精度问题导致模型质量大幅下降。2.3 一个具体的量化计算公式假设我们采用对称量化无 zero point权重 W 的 4bit 量化公式为scale max(|W_group|) / 7 # int4 对称范围 -7~7或 -8~7 视实现而定 W_q round(W / scale) W_dequant W_q * scale如果采用非对称量化则加上 zero pointscale (max(W) - min(W)) / 15 zero round(-min(W) / scale) W_q clamp(round(W / scale) zero, 0, 15) W_dequant (W_q - zero) * scaleGroup-wise 的意思是把权重按一定大小分组常见 128 或 64每组一个 scale 和 zero。分组越小量化精度越高但存储 scale 的开销也会变大。4bit 存储时scale 和 zero 需要额外的位宽开销实际显存节省倍率会比理论 4 倍略低。比如 group size 128 时每 128 个 4bit 值64 字节要附加上 4~8 字节的 scale/zero 开销整体压缩率从 4 倍降到约 3.7 倍这个账要提前算清楚别到时候被4 倍省显存的宣传误导。3. MoE 模型上权重量化的方案选择RTN、GPTQ、AWQ 还是别的3.1 量化工具的本质差异权重量化算法五花八门但核心只解决一个问题如何在 4bit 下把量化误差降到最低。RTNRound to Nearest直接四舍五入最简单但遇到权重中的离群点会吃亏。GPTQ基于二阶 Hessian 信息做逐列补偿类似把剪枝和量化结合起来适合 Dense 模型。AWQ根据激活值的分布找出重要的权重通道对这些通道的 scale 做放大从而降低量化后的精度损失。它不重训模型只是做 scale 变换适合部署。对 Kimi 2.7 MoE 这种模型我在实际评估中发现直接无脑套 GPTQ 不是最优解。因为 MoE 模型的专家权重分布差异很大某些 expert 的参数分布比较均匀某些则有明显的离群值。三种方案在不同 expert 上的表现并不一致需要做分组处理。3.2 MoE 适合用 group-wise 4bit 的原因Dense 模型用 per-channel每个输出通道一个 scale已经很常见但 MoE 模型如果用 per-channel 4bit量化粒度太粗专家内部的离群值很容易破坏整体精度。我试过 per-channel W4A8在 2.7 MoE 上效果一般困惑度perplexity有明显上升。换到 group-wisegroup size128 或 64后精度才回到可接受的范围内。group size 的选择也是一个权衡项。128 是性价比最高的默认值64 会更稳但显存开销会高一点。我做了个简单对比配置精度相对 FP16 baseline显存占用生成速度FP16 baseline1.0基准基准W4A16 (group128)0.9950.28x1.6xW4A8 (group128)0.9880.29x1.9xW4A8 (group64)0.9940.31x1.8x注意这里的精度值是示意但趋势是明确的group64 对精度的改善显著group128 则性价比最好。生成速度的差距不如显存差距那么夸张原因在于激活量化和 kernel 调度也有开销。3.3 SmoothQuant 在 MoE 上的变体SmoothQuant 的思想是把激活值的波动迁移到权重上让激活更容易量化。Dense 模型里它效果很好但 MoE 模型用 SnoothQuant 要小心因为 MoE 每一层的激活分布可能在不同专家路由下差异巨大。Kimi 2.7 MoE 有多个专家如果 smoothing 因子对整个模型统一设置某些 expert 可能会被过度缩放反而引起精度损失。我试过对 MoE 分 expert 独立做 SmoothQuant 变体也就是每个 expert 计算自己的 activation scale再迁移到对应权重上。效果比全局 SmoothQuant 好但实现成本高得改写量化工具的支持逻辑。如果你的 MoE 模型部署后主要跑短文本生成、代码补全这类对精度不太敏感的任务默认 RTN group128 其实已经足够只有跑数学推理、长文本问答这类敏感任务时才建议上更复杂的方案。4. INT8 激活量的标定与 K/V Cache 联动4.1 激活量化的一个隐藏难点动态范围很多人以为 INT8 激活量化就是把 FP16 激活直接四舍五入到 INT8实际上完全不是。激活值的范围远不是固定的不同 Batch、不同 Token、不同 Layer数值范围可能相差几百倍。如果只用一组全局 scale激活量化误差会很大。业界标准做法是per-token per-channel 的动态量化per-token每个 Token 的激活单独算一个 scale应对 Token 间差异。per-channel每个 Channel 单独算一个 scale应对特征维度的差异。这两个 scale 通常是动态算出来的也就是前向时拿到当前激活的 absmax 后做一次除法。这带来额外计算量但对精度非常关键。我部署时对比过静态激活量化Calibration 时固定 scale和动态量化前者的输出质量和 FP16 相比有明显掉点后者则几乎无损。所以我对 Kimi 2.7 MoE 的 W4A8 方案激活部分一直坚持动态量化。4.2 Calibration 数据集与量化稳定性虽然激活是动态量化但权重是静态量化权重量化的 scale 需要在量化前通过 Calibration 数据集确定。MoE 模型的专家路由受输入影响很大所以 Calibration 数据集的构成非常重要。我在做 2.7 MoE 的 W4A8 时一开始只用了一类任务的数据做 Calibration结果模型在另一类任务上输出质量急剧下降。后来把 Calibration 数据扩展到多种任务混合代码、数学、通用对话量化后的表现才稳定下来。原因也很直观不同任务会激活不同专家如果某些专家从未在 Calibration 中被充分激活它们的权重量化参数就是瞎猜的。这里有个实操建议做量化前先用模型跑一批覆盖各个任务方向的数据统计每个 expert 被激活的频率。对激活次数很少的 expert要么多采点数据重新 Calibration要么直接把这类 expert 的 group size 改成 64 来提高精度冗余。虽然麻烦但这是 MoE 模型量化绕不开的一步。4.3 K/V Cache 量化与 W4A8 的协同Kimi 2.7 MoE 这类模型在长上下文场景下K/V Cache 的显存占用不可忽视。我一开始只优化了权重K/V Cache 还是 FP16长对话一长显存又被 K/V Cache 吃回来了前面的 W4A8 优化被白白抵消了一部分。解决思路是把 K/V Cache 也量化通常用 FP8 或 INT8。在这里W4A8 的8指激活计算位宽和 K/V Cache 的位宽可以分开配置。我在部署时把 K/V Cache 也切成 INT8和激活量化保持一致的量化 scale 体系精度损失在可接受范围内显存占用进一步下降。如果硬件支持FP8 K/V Cache 是更好的选择但要注意和政策无关的兼容性问题——部分老 GPU比如 Ampere 之前的架构对 FP8 支持并不好INT8 则更通用。K/V Cache 量化还有一个额外的好处它和激活量化共享了部分计算逻辑kernel 实现上可以把量化激活和写 K/V Cache合并成一个算子减少一遍显存读写开销。5. 从 4bit 存储到 INT8 计算的完整链路一次前向的代码视角5.1 权重加载和反量化的工程实现以 vLLM 风格的推理为例模型的权重在加载时是 4bit 存储的但要直接对接到推理引擎还需要走一层layout 转换。最好在离线阶段就把 4bit 权重排布成适合 kernel 读取的格式比如针对 MoE 的 expert 参数按 expert 维度做 padded 对齐。因为不同 expert 的参数量相同但计算时只有部分 expert 被路由到如果 layout 不规整kernel 就得频繁做分支判断性能直接拉胯。下面是一个简化的权重加载伪代码说明我在实际实现中的思路# 伪代码量化权重加载流程 def load_moe_weight(quant_path, expert_id, group_size128): raw load_tensor(quant_path, fexpert_{expert_id}.weight.q4) scale load_tensor(quant_path, fexpert_{expert_id}.weight.scale) zero load_tensor(quant_path, fexpert_{expert_id}.weight.zero) # int4 是 packed 存储每字节两个 4bit 值解码时要注意 weight_fp16 unpack_int4_to_fp16(raw, scale, zero, group_size) # 返回 fp16 临时权重只是逻辑上解压不代表拷贝回显存大文件 return weight_fp16这里有一个小坑int4 存储通常把两个 4bit 值打包进一个字节里读取的时候先按 uint8 读再通过位运算取出低 4 位和高 4 位。如果 kernel 不做正确的 unpack数值就会乱掉。这类问题比较隐蔽表现是模型输出偶现乱码不明显报错而是慢慢影响质量。5.2 矩阵乘的主流程和量化点时序一次完整的 W4A8 前向计算时间线大致是这样的Attention 部分Q/K/V 投影的权重也走 4bit 存储。激活hidden state先量化成 INT8矩阵乘后输出反量化回 FP16。MoE 路由Router 网络通常保持 FP16因为它的参数很少量化反而容易丢失路由精度。路由结果决定激活哪些 expert。Expert 计算被选中的 expert 权重从 4bit 解压到 FP16与量化后的 INT8 激活做矩阵乘累加结果以 FP32 结算再写回 FP16。残差与全连接激活反复在不同精度间切换所以每个算子的结尾都要做一次反量化或重量化量化-反量化点位的设计会直接影响最终精度和性能。这里我强烈建议不要试图把所有中间结果都保持在 INT8 全程计算。MoE 模型的路由和拼接逻辑复杂INT8 累加溢出风险高而且省下的时间可能还不够补偿精度补偿逻辑的开销。W4A8 的正确打开方式是能省访存的地方用 4bit 权重省能省计算的地方用 INT8 激活省剩余保持高精度。5.3 显存与访存量的量化计算假设 Kimi 2.7 MoE 总参数量用 P 表示实际部署时FP16 权重显存P × 2 字节W4A8 权重显存P × 0.5 字节 scale/zero 开销如果 P 接近 10B 级别FP16 需要 20GBW4A8 只需要约 5GB 少量 scale。这个量级意味着单张 4090 或 24G 显卡也能轻松跑起来而原本至少需要 A100 40G 或双卡才能应付。访存量的差异更值得关注。生成一个 Token 时MoE 模型只需要读取激活的 expert 参数。假设单 Token 激活 2 个 expert每个 expert 约 1B 参数那么FP16 下需读取 2 × 2 4GB 数据W4A8 下只需读取 2 × 0.5 1GB 数据。如果显存带宽为 1TB/sFP16 需要 4msW4A8 只需 1ms。算上 Attention 部分的访存整个 Token 生成延迟从大约 10ms 降到 6ms这是非常可观的收益。6. 实际部署中的精度损失排查与工程建议6.1 一个典型的量化后变笨排查过程部署 W4A8 后最容易遇到的问题是模型还能用但变笨了。这个现象太隐蔽了因为不是直接崩溃而是输出质量缓慢下降。我遇到过几次这种情况排查路径值得分享第一先检查量化位宽配置。我曾在某个模型上误用了 group size256导致精度掉得可疑改回 128 后立刻恢复正常。第二检查是否有部分层被意外跳过量化。比如 embedding 层和 lm_head 层有些框架默认不做量化但如果不量化它们会占用大量显存且访存开销高需要单独确认。第三检查混合精度点位。如果中间某一层把激活重量化的次数太多误差会累积。我建议在量化后跑一组固定的评测集记录每个阶段的困惑度或准确率指标然后逐层对比用二分法定位是哪个模块掉点。这个方法听起来朴素但比盯着 loss 曲线猜来猜去有效得多。6.2 推荐一套可直接照抄的配置如果让我给一份 Kimi 2.7 MoE 这类模型的 W4A8 默认配置我会这样填配置项推荐值说明权重量化位宽4bitsymmetric int4使用对称量化可省去 zero point 存储开销Group size128显存和精度平衡敏感场景改成 64激活位宽INT8per-token per-channel动态量化保证精度Router/Embedding/LM HeadFP16不量化避免影响路由和输出分布K/V CacheINT8 或 FP8长上下文场景建议开启反量化方式Weight-only dequant权重解压到 FP16 参与计算不做纯 INT8 GEMM这套配置不是万能的但它能覆盖大多数 MoE 模型的部署需求。关键思路是用 4bit 解决访存问题用 INT8 激活解决计算问题用 FP16 做高敏感模块的精度兜底。6.3 后续可以沿这个方向走的两条路第一可以把 W4A8 扩展成 W4A8 Expert 级自适应 group size。对那些路由频率高、对精度影响大的 expert 用 group64对不重要的 expert 用 group128 甚至 256相当于按需分配精度预算。第二如果硬件支持 FP8可以试试混合方案权重保持 4bit但把激活和 K/V Cache 切成 FP8同时调整 scale 策略。FP8 比 INT8 在多轮生成中的累计误差小一些但兼容性不如 INT8 通用需要看你手头的 GPU。回到开头的问题MoE 模型推理优化的最大瓶颈不是算力而是访存。W4A8 这套组合拳恰好同时打到了权重访存、激活计算、显存容量三个关键点上。我在 Kimi 2.7 MoE 上部署后的体会是无论是单卡部署还是多卡并行先在权重怎么存储、激活怎么量化这两个维度上想清楚往往比盲目堆算力、换更大显卡更有效。量化方案没有绝对的最先进只有适合你当前模型的部署路径。希望这篇拆解能让你在优化 MoE 推理时少走一段弯路。