小米MiMo-V2.5-Pro-FP4-DFlash：FP4+推测解码的万亿推理提速指南

小米MiMo-V2.5-Pro-FP4-DFlashFP4推测解码的万亿推理提速指南【免费下载链接】MiMo-V2.5-Pro-FP4-DFlashMiMo-V2.5-Pro-FP4-DFlash 是驱动 MiMo-V2.5-Pro-UltraSpeed 的底层模型 FP4 量化骨干网络对 MoE 专家采用 MXFP4 量化同时保持模型其他部分的更高精度在几乎无损质量的前提下显著减小模型体积并降低内存带宽压力。 BF16 DFlash 草稿生成器用于块扩散推测解码每次前向传播可生成一整个块的 tokens并让骨干网络一步完成验证。 两者协同作用既降低了每参数的位宽又减少了骨干网络前向传播的次数而这两者正是万亿参数模型解码过程中的两大主要成本来源。项目地址: https://ai.gitcode.com/XiaomiMiMo/MiMo-V2.5-Pro-FP4-DFlash万亿参数模型的大模型推理加速瓶颈从来不在算力而在两个更朴素的地方显存装不下、搬数搬不动。小米MiMo-V2.5-Pro-FP4-DFlash 的方案是把专家参数压成 MXFP4 4bit 权重、同时用 DFlash 块扩散推测解码让一次骨干前向传播确认多个 token——带宽和前向次数两头一起省。本文只讲三件事原理怎么成立、效果数据说明什么、SGLang 部署怎么落地并明确这套方案的适用边界。 MXFP4专家量化只压缩占地方的那部分参数把一次搬家想成打包行李不是每件物品都该塞进压缩袋精密仪器必须原样带。MXFP4 专家量化就是这个思路——MoE混合专家架构里路由专家占了 1T 参数的绝大部分且对精度最宽容注意力输出投影这类关键通路则保持原精度。MiMo-V2.5-Pro 的 config.json 里n_routed_experts为 384、num_experts_per_tok为 8也就是每层 384 个专家、每个 token 只激活其中 8 个。专家数量多、单 token 用不了几个意味着它们是显存占用的绝对大头却也是量化最安全的区域反过来每层o_proj把注意力结果投回主干是全模型共享的关键通路一错全错所以排除。MXFP4Microscaling FP4每 32 个参数配一个块级缩放因子用小窗口保留动态范围再叠加 FP4 量化感知训练让模型在低精度下重新学会表达。最终效果权重体积显著缩小、显存带宽被真正打满质量贴近 FP8 版本。配置证据在 config.json 的quantization_config字段quantization_config: { store_dtype: mxfp4, // 权重以 MXFP4 格式落盘 mxfp4_block_size: 32, // 每 32 个参数共享一个块级缩放因子 ignored_layers: [ model.layers.0.self_attn.o_proj, model.layers.1.self_attn.o_proj // …… 共 70 层 o_proj MTP 解码器投影全部排除量化 ] }ignored_layers列出的 70 个self_attn.o_proj外加一个 MTP 解码器投影恰好与 70 层主干一一对应全部专家走 4bit其余模块保持高精度。 DFlash块扩散推测解码一次前向填完整个 token 块先写一整段草稿再一次性交给编辑校对——这就是块扩散推测解码。传统推测解码的草稿模型本身也是自回归的要猜 8 个 token 就得串行跑 8 次前向草稿阶段自己就是个小瓶颈。DFlash 改成块级掩码并行预测把下一个块 8 个位置全部填上掩码草稿模型一次前向同时给出全部候选。两个设计让这件事在万亿 MoE 上成立。其一草稿不读完整 KV 前缀而是复用骨干在 5 个层输出的中间特征作为上下文其二全程用滑动窗口注意力SWAKV 只看最近 1024 个 token——每块预测的计算量从此与上下文长度解耦长上下文服务不再拖慢草稿阶段。骨干对草稿块做一次前向验证拒绝采样保证输出分布与纯自回归完全一致加速但不改结果。草稿模型配置见 dflash/config.jsonblock_size: 8, // 每块预测 8 个 token use_swa: true, swa_window_size: 1024, // 草稿只看最近 1024 个 token 的上下文 target_layer_ids: [0, 15, 31, 47, 69] // 从骨干这 5 层抽取中间特征target_layer_ids这 5 个层均匀撒在 70 层骨干的首、中、尾。dflash/dflash.py 的注意力前向里K/V 由骨干 5 层特征压缩成的上下文与块内其他位置的噪声嵌入拼接而成Q 来自掩码 token 的嵌入——整块位置在一次注意力里同时看到上下文和块内候选def forward(self, hidden_states, target_hidden, ...): q self.q_proj(hidden_states) # Q 来自掩码 token 的噪声嵌入 k_ctx self.k_proj(target_hidden) # 上下文骨干 5 层特征压缩 k_noise self.k_proj(hidden_states) # 块内其他位置的嵌入 k torch.cat([k_ctx, k_noise], dim1) # 拼接后一次注意力 ... return self.o_proj(attn_output), attn_weights验证在spec_generate里骨干对草稿块做一次前向逐位比对从首个不匹配处截断之后改用骨干自身采样继续——整轮输出与不做推测解码时同分布无损。 效果验证FP4量化掉不掉点接受长度差多少先看 MXFP4 相对 FP8 的质量对比数据来自 README.md基准FP8MXFP4变化Claw-Eval (pass^3)63.867.84.0 分约 6.3%SWE-Bench Pro57.258.81.6 分约 2.8%Humanitys Last Exam48.047.0-1.0 分约 -2.1%SWE-bench Verified78.977.4-1.5 分约 -1.9%升得最多的是通用智能体和代码智能体——恰恰是长输出、重推理的场景说明 FP4 专家量化没有伤到长程推理与代码能力降得最多的是带工具调用的评测-1.9% 到 -2.9%属于量化的常规波动。结论很直接整体质量与 FP8 几乎无差换带宽是划算的对精度极端敏感的业务可以只上 DFlash、骨干保留 FP8。再看 DFlash 的接受长度——平均每个块里被骨干认可的 token 数同样来自 README.md场景接受长度WebDev6.30Math5005.56HumanEval4.54SWE-Bench4.29MT-Bench3.18规律清楚任务越可预测、输出越长收益越大。WebDev 和数学推理输出长、句式结构化每块平均 6 个多 token 一次通过骨干前向次数大幅减少MT-Bench 这类闲聊回复短且发散每块平均只省约 2 次前向叠加验证开销后加速有限。 SGLang部署DFlash的完整命令与调优建议SGLang 对 FP4 骨干加 DFlash 草稿的支持开箱即用草稿模型继承骨干的张量/专家并行拓扑。完整命令python3 -m sglang.launch_server \ --model MiMo-V2.5-Pro-FP4-DFlash \ --speculative-algorithm DFLASH \ --speculative-draft-model-path MiMo-V2.5-Pro-FP4-DFlash/dflash \ --speculative-num-draft-tokens 8 \ --ep-size 16 \ --tensor-parallel-size 16 \ --data-parallel-size 2 \ --enable-dp-attention \ --enable-dp-lm-head \ --quantization fp8 \ --attention-backend fa3 \ --moe-dense-tp-size 1 \ --dtype bfloat16 \ --mem-fraction-static 0.65 \ --context-length 65536 \ --trust-remote-code \ --disable-overlap-schedule \ --skip-server-warmup \ --dist-init-addr ${MASTER_ADDR}:20000 \ --nnodes ${WORLD_SIZE} \ --node-rank ${RANK} \ --host 0.0.0.0 \ --port 29999需要解释的参数只有几个--speculative-algorithm DFLASH与--speculative-draft-model-path开启 DFlash 推测解码草稿模型指向仓库的dflash/子目录二者必须成对出现。--speculative-num-draft-tokens 8草稿块大小必须与 dflash/config.json 里的block_size一致改草稿模型时两边同步改。--ep-size 16--tensor-parallel-size 16384 个专家分 16 路专家并行1T 骨干走 16 路张量并行加--data-parallel-size 2共 32 卡这是该模型的最低部署形态。--mem-fraction-static 0.6565% 显存预留给权重与静态 KV 缓存其余留给动态 KV按上下文长度和并发上调或下调。调优建议任务以长代码、长文生成为主时speculative-num-draft-tokens可尝试 10~12但需与草稿模型重新训练对齐官方 8 是验证过的平衡点高并发在线服务把data-parallel-size调大、配--enable-dp-attention摊薄请求离线低并发则反之把卡省给更长的上下文启动时 OOM 优先降mem-fraction-static或context-length而不是直接缩并行度——缩并行会改变专家切分收益不确定。️ 边界与取舍哪些场景值得上哪些不值得先说收益排序。DFlash 的收益上限由接受长度决定WebDev6.30、Math5005.56这类长输出、结构化任务最划算每块省 5 次以上骨干前向代码智能体4.29次之多轮闲聊3.18最弱每块只省约 2 次前向把验证和草稿开销摊进去后端到端加速可能只有两三成。FP4 量化则是纯收益权重位宽从 8bit 降到 4bit带宽压力直接减半且上表显示质量波动在 ±3 分以内。再说前提与限制这部分不客套硬件门槛高。1.02T 参数骨干加 5 层 BF16 草稿上面命令就是 32 卡 H100/H200 级集群的形态单机 8 卡装不下 1T 参数这套方案不是给本地部署准备的。草稿的滑窗只有 1024 tokenswa_window_size超出窗口的上文对草稿不可见。超长上下文里接受长度大概率低于表中数值骨干本身 1M 上下文能力不受影响但最终输出仍是骨干验证过的质量无损。接受长度是离线评测值线上混合流量会因内容分布变化而漂移上生产前建议用自己的请求回放压一轮。收尾小米MiMo-V2.5-Pro-FP4-DFlash 的路线一句话就能说清MXFP4 把专家权重压到 4bitDFlash 让一次骨干前向确认 8 个 token——万亿参数解码的两笔大账单带宽和前向次数各砍一刀。每个数字的出处都在 config.json 和 dflash/config.json 里按上面命令落地即可。【免费下载链接】MiMo-V2.5-Pro-FP4-DFlashMiMo-V2.5-Pro-FP4-DFlash 是驱动 MiMo-V2.5-Pro-UltraSpeed 的底层模型 FP4 量化骨干网络对 MoE 专家采用 MXFP4 量化同时保持模型其他部分的更高精度在几乎无损质量的前提下显著减小模型体积并降低内存带宽压力。 BF16 DFlash 草稿生成器用于块扩散推测解码每次前向传播可生成一整个块的 tokens并让骨干网络一步完成验证。 两者协同作用既降低了每参数的位宽又减少了骨干网络前向传播的次数而这两者正是万亿参数模型解码过程中的两大主要成本来源。项目地址: https://ai.gitcode.com/XiaomiMiMo/MiMo-V2.5-Pro-FP4-DFlash创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考