拓冰网站定制 
English version:en/10-moe-sparsification-in-practice.md本篇对应源码tools/legacy/train_moe.py·tools/legacy/train_lambda.py·docs/moe_framework.md目标完整复盘 MoE 稀疏化的两条路线——「结构蒸馏λ_s」为何失败、「全量训练 MoE」为何成功以及 ffn_e 扫描如何锁定甜点。这是整个训练流程最有信息量的一篇。一、技术点 1λ_s 结构蒸馏❌ 判否设计在阶段 0 的稠密模型上叠加结构退火让 FFN 从稠密平滑过渡到 MoEout (1-λ_s)·dense_ffn(h) ⊕ λ_s·moe_ffn(h) λ_s: 0 → 1λ_s0纯稠密收敛态天然不崩λ_s1纯 MoE稀疏激活目标态稠密旁路冻结作 teacher 参考只训 MoE 旁路。四轮修正全部失败版本修正项λ_s→1 时 ppl涨幅router 熵判定v1λ_s 0→1原始59.95587%2.013❌v2 λ_s floor0.5 独立 lr21.36145%1.989❌v4 aux_w0 5000 步15.8481.5%1.965❌ffn_e256 容量翻倍13.6756.7%1.950❌每轮都在变好ppl 587%→145%→81.5%→56.7%但全都过不了闸门要求涨幅 20% 且熵 1.8。根因dense 兜底与 router 分化互斥关键观察四轮里 router 熵始终卡在 1.95~1.97log82.079 均匀态与 ffn_e、aux 开关、λ_s 方向全部无关。死结链条dense 旁路兜底λ_s1 时输出占主导 → CE 对 MoE 的梯度稀释成「微调残差」级别 → router 没有分化压力 → 8 专家看同样 token、学同样残差、越来越同质 → router 更没理由分化负反馈循环「平滑过渡dense 兜底保不崩」与「router 分化」在这个架构下互斥。这是硬数据坐实的结论。二、技术点 1-b全量训练 MoE✅ 成功关键转向放弃 dense 旁路直接把每层 FFN 替换为 LambdaMoE无兜底纯 CE 直接压 router 分化# train_moe.py build_studentforLinstudent.model.layers:L.mlpLambdaMoE(dim,n_expert8,top_k2,ffn_e)# 完全替换无 dense 旁路optAdamW(student.parameters(),...)# 全量训练不冻结lossF.cross_entropy(logits,y)# 纯 CE非 KDλ 只做 router 内部 soft→hard 梯度退火1→0方向正确。决定性对比指标结构蒸馏4轮全败全量 MoE成功router 熵恒卡 1.95~1.97 均匀态1.968 → 1.80真正分化最终质量ppl 13~60崩argmax match0.607router 熵一路波动下降到 1.80与结构蒸馏「熵单调爬向均匀」形成鲜明对照从实证上坐实了「dense 兜底稀释分化压力」的根因。三、技术点 1-cffn_e 扫描甜点锁定ffn_e 每个专家的 FFN 维度决定「带宽收益」与「容量」的 trade-off带宽收益 ffn / (top_k × ffn_e) 容量比 (top_k × ffn_e) / ffnffn_e容量比带宽收益参数量router 熵argmax match1280.234.27x32.18M1.800.6412560.472.13x41.77M1.800.6073840.701.42x51.35M1.800.581反直觉结论argmax match 随 ffn_e 增大反而下降0.641→0.607→0.581。这不是误差——TinyStories 简单数据上容量过剩会轻微过拟合更大的专家网络在固定步数下学得不够聚焦。ffn_e128 双重最优同时拿到最高质量match 0.641和最高带宽收益4.27x是 MCU 部署的甜点。这直接回应了核心约束「CPU 推理受限于内存带宽优先减少带宽占用」。四、结论结构蒸馏路径判否dense 旁路兜底与 router 分化本质互斥四轮修正无法挽救。全量 MoE 是正路无兜底 纯 CE λ 只做 router 内部退火router 分化成功。ffn_e128 甜点TinyStories 简单数据上「越小越好」容量过剩反而过拟合。bandwidth-firstMCU 场景下 ffn_e 由带宽收益比决定而非照搬开源 Mixtral 的容量扩展逻辑。五、补充2026-09-27正式 3 epoch 训练ffn_e128 全量 MoE 跑满 3 epoch342871 步 / 5.9hargmax match 0.744优于扫描甜点的 0.641、CE 1.20、无 NaN产出moe_3ep。端到端部署已闭环该模型经 convertrouter f32 8×expert q4 分类存储 独立 lm_head后在 ESP32-P4 上跑通方案 B权重常驻 PSRAM 只流式读 embed达到0.157 s/token20/20 与 PC 参考一致。详见 13。对应源码文件关键符号 / 位置支撑本文哪部分tools/legacy/train_lambda.pyDenseMoEHybrid、lambda_s_at、--lam_s_floor一、技术点 1 λ_s 结构蒸馏判否tools/legacy/train_moe.pyLambdaMoE、build_student、lambda_at二、全量训练 MoE 与 λ 退火tools/legacy/train_moe.py参数--ffn_e、--n_expert、--aux_w三、ffn_e 扫描甜点锁定tools/legacy/eval_quality.pyperplexity、gen_samples三、ffn_e 扫描的质量评估docs/moe_framework.mdLambdaMoE、R(1-λ)·R_classic ⊕ λ·R_new二、自研 MoE 核心与路由公理《Kestrel-MCU 手记》· 全系列 28 篇在 ESP32-P4 上从零训练并部署 32M~64M 参数 MoE 大模型5.7~6.4 tok/s源码、权重、训练脚本与全部文章开源可复现。仓库https://gitee.com/pei-xiaoguang/kestrel-llm-mcu · 觉得有用欢迎 Star 10 · MoE 稀疏化实战：结构蒸馏判否后，ffn_e 扫描锁定甜点
English version:en/10-moe-sparsification-in-practice.md本篇对应源码tools/legacy/train_moe.py·tools/legacy/train_lambda.py·docs/moe_framework.md目标完整复盘 MoE 稀疏化的两条路线——「结构蒸馏λ_s」为何失败、「全量训练 MoE」为何成功以及 ffn_e 扫描如何锁定甜点。这是整个训练流程最有信息量的一篇。一、技术点 1λ_s 结构蒸馏❌ 判否设计在阶段 0 的稠密模型上叠加结构退火让 FFN 从稠密平滑过渡到 MoEout (1-λ_s)·dense_ffn(h) ⊕ λ_s·moe_ffn(h) λ_s: 0 → 1λ_s0纯稠密收敛态天然不崩λ_s1纯 MoE稀疏激活目标态稠密旁路冻结作 teacher 参考只训 MoE 旁路。四轮修正全部失败版本修正项λ_s→1 时 ppl涨幅router 熵判定v1λ_s 0→1原始59.95587%2.013❌v2 λ_s floor0.5 独立 lr21.36145%1.989❌v4 aux_w0 5000 步15.8481.5%1.965❌ffn_e256 容量翻倍13.6756.7%1.950❌每轮都在变好ppl 587%→145%→81.5%→56.7%但全都过不了闸门要求涨幅 20% 且熵 1.8。根因dense 兜底与 router 分化互斥关键观察四轮里 router 熵始终卡在 1.95~1.97log82.079 均匀态与 ffn_e、aux 开关、λ_s 方向全部无关。死结链条dense 旁路兜底λ_s1 时输出占主导 → CE 对 MoE 的梯度稀释成「微调残差」级别 → router 没有分化压力 → 8 专家看同样 token、学同样残差、越来越同质 → router 更没理由分化负反馈循环「平滑过渡dense 兜底保不崩」与「router 分化」在这个架构下互斥。这是硬数据坐实的结论。二、技术点 1-b全量训练 MoE✅ 成功关键转向放弃 dense 旁路直接把每层 FFN 替换为 LambdaMoE无兜底纯 CE 直接压 router 分化# train_moe.py build_studentforLinstudent.model.layers:L.mlpLambdaMoE(dim,n_expert8,top_k2,ffn_e)# 完全替换无 dense 旁路optAdamW(student.parameters(),...)# 全量训练不冻结lossF.cross_entropy(logits,y)# 纯 CE非 KDλ 只做 router 内部 soft→hard 梯度退火1→0方向正确。决定性对比指标结构蒸馏4轮全败全量 MoE成功router 熵恒卡 1.95~1.97 均匀态1.968 → 1.80真正分化最终质量ppl 13~60崩argmax match0.607router 熵一路波动下降到 1.80与结构蒸馏「熵单调爬向均匀」形成鲜明对照从实证上坐实了「dense 兜底稀释分化压力」的根因。三、技术点 1-cffn_e 扫描甜点锁定ffn_e 每个专家的 FFN 维度决定「带宽收益」与「容量」的 trade-off带宽收益 ffn / (top_k × ffn_e) 容量比 (top_k × ffn_e) / ffnffn_e容量比带宽收益参数量router 熵argmax match1280.234.27x32.18M1.800.6412560.472.13x41.77M1.800.6073840.701.42x51.35M1.800.581反直觉结论argmax match 随 ffn_e 增大反而下降0.641→0.607→0.581。这不是误差——TinyStories 简单数据上容量过剩会轻微过拟合更大的专家网络在固定步数下学得不够聚焦。ffn_e128 双重最优同时拿到最高质量match 0.641和最高带宽收益4.27x是 MCU 部署的甜点。这直接回应了核心约束「CPU 推理受限于内存带宽优先减少带宽占用」。四、结论结构蒸馏路径判否dense 旁路兜底与 router 分化本质互斥四轮修正无法挽救。全量 MoE 是正路无兜底 纯 CE λ 只做 router 内部退火router 分化成功。ffn_e128 甜点TinyStories 简单数据上「越小越好」容量过剩反而过拟合。bandwidth-firstMCU 场景下 ffn_e 由带宽收益比决定而非照搬开源 Mixtral 的容量扩展逻辑。五、补充2026-09-27正式 3 epoch 训练ffn_e128 全量 MoE 跑满 3 epoch342871 步 / 5.9hargmax match 0.744优于扫描甜点的 0.641、CE 1.20、无 NaN产出moe_3ep。端到端部署已闭环该模型经 convertrouter f32 8×expert q4 分类存储 独立 lm_head后在 ESP32-P4 上跑通方案 B权重常驻 PSRAM 只流式读 embed达到0.157 s/token20/20 与 PC 参考一致。详见 13。对应源码文件关键符号 / 位置支撑本文哪部分tools/legacy/train_lambda.pyDenseMoEHybrid、lambda_s_at、--lam_s_floor一、技术点 1 λ_s 结构蒸馏判否tools/legacy/train_moe.pyLambdaMoE、build_student、lambda_at二、全量训练 MoE 与 λ 退火tools/legacy/train_moe.py参数--ffn_e、--n_expert、--aux_w三、ffn_e 扫描甜点锁定tools/legacy/eval_quality.pyperplexity、gen_samples三、ffn_e 扫描的质量评估docs/moe_framework.mdLambdaMoE、R(1-λ)·R_classic ⊕ λ·R_new二、自研 MoE 核心与路由公理《Kestrel-MCU 手记》· 全系列 28 篇在 ESP32-P4 上从零训练并部署 32M~64M 参数 MoE 大模型5.7~6.4 tok/s源码、权重、训练脚本与全部文章开源可复现。仓库https://gitee.com/pei-xiaoguang/kestrel-llm-mcu · 觉得有用欢迎 Star