17 · MoE 与 PLE 正交共存稀疏专家加逐层查表的完整实现English version:en/17-ple-under-moe.md本篇对应源码tools/mistral_ple.py·tools/train_moe_ple.py·docs/moe_framework.md目标把 MoE 叠进 PLE完成「更大模型」的最终配方。前面几篇的 PLE 验证都在 dense FFN 上做esp32-ai 原始结构而我们的真实模型是 MoE。本章讲实现——MoEFFN 怎么加、MoE 与 PLE 怎么共存、验证怎么设计。一、为什么需要这一章前文已锁定的「更大模型」形态是三块拼图部件作用放置coreMoE 稀疏激活省带宽SRAMheadtied 小省全扫PSRAMtablePLE 三值查表承载容量flash但 PLE 的验证14 篇 / 16 篇都是在dense FFN上做的。我们的真实模型是MoE 8 专家所以「MoE PLE」的组合是否成立、实现怎么做是完整配方落地前的最后一块。二、实现MoEFFN在 esp32-ai 的model.py里把 Block 的 dense SwiGLU 换成 MoEFFNclassMoEFFN(nn.Module):def__init__(self,cfg):super().__init__()self.n_expertcfg.n_expert self.top_kcfg.top_k self.routernn.Linear(cfg.d_model,cfg.n_expert,biasFalse)hcfg.ffn_eifcfg.ffn_e0elsecfg.ffn_hidden self.expertsnn.ModuleList([SwiGLU(cfg,hiddenh)for_inrange(cfg.n_expert)])defforward(self,x):B,T,Dx.shape pF.softmax(self.router(x),dim-1)topk_val,topk_idxtorch.topk(p,self.top_k,dim-1)xfx.view(B*T,D)outtorch.zeros(B*T,D,devicex.device,dtypex.dtype)idx_ftopk_idx.view(B*T,self.top_k)val_ftopk_val.view(B*T,self.top_k)forkinrange(self.top_k):foreinrange(self.n_expert):selidx_f[:,k]eifsel.any():out[sel]val_f[sel,k].unsqueeze(-1)*self.experts[e](xf[sel])returnout.view(B,T,D)设计要点稀疏 top-k只对选中的专家算 FFN未选中的专家不参与 forward省计算、省带宽。ffn_e 独立于 ffn_hidden每个专家是独立 SwiGLUhidden 用ffn_e与 dense 的ffn_hidden解耦。router 算进 corerouter d_model × n_expert也是每 token 全算的 dense 权重自然归入 core 预算。三、PLE 与 MoE 的共存关键点MoE 和 PLE 在 Block 里是正交的互不干扰defforward(self,x,cos,sin,pleNone):xxself.attn(self.attn_norm(x),cos,sin)xxself.ffn(self.ffn_norm(x))# 这里 ffn 是 MoEFFN 或 SwiGLUifpleisnotNone:# PLE 注入在 FFN 之后gF.gelu(self.ple_gate(x))xxself.ple_norm(self.ple_proj(g*ple))returnxMoE 稀疏化 core 的 FFN→ 省带宽top-2 激活只算 2/8 专家PLE 加 table 承载容量→ 省 head25M 参数塞 flash 查表每 token 只读一行两者解决的是不同问题叠加不冲突。四、验证设计对比moe vs moeplecore-matched二分 ffn_e 使两者 core 都 ≈ 10MarmFFNffn_ecoretablemoeMoE8 专家 top-2819.99M0moepleMoE8 专家 top-2求解≈10M40.96M配置dim 312 / 10 层 / vocab 32002 / n_expert 8 / top_k 2TinyStories3000 步。五、结果PLE 在 MoE 框架下成立armcoretabletotalbest pplmoe9.99M019.98M5.84moeple9.99M40.96M60.94M5.35moe 5.84 → moeple 5.35 0.088 nats / 9.2% ppl 改善core-matched两者 core 都 ≈ 9.99MPLE 只多了 40.96M 的 flash 查表每 token 只查 10 行几乎免费PLE 在 MoE 框架下成立且收益比 dense 框架0.078 nats还略大六、结论完整配方验证通过「更大模型」的最终形态至此三块拼图全部用硬数据走通部件验证结果coreMoE 稀疏激活省带宽top-2 只算 2/8 专家tablePLE 三值查表0.088 nats三值 20× 压缩几乎无损headtied 小省全扫PLE 在 dense 框架成立0.078 nats16 篇PLE 在 MoE 框架成立0.088 nats本篇三值 table 几乎无损0.001 nats20× 压缩15 篇完整配方MoE core PLE table三值 headtied是「更大模型又不慢」的已验证正解。对应源码文件关键符号 / 位置支撑本文哪部分tools/mistral_ple.pyMistralPLEConfig配置n_expert/top_k/ffn_e/ple_dimtools/mistral_ple.pyMoEFFN二、实现MoEFFN 稀疏 top-k 专家tools/mistral_ple.pyDecoderLayer三、PLE 与 MoE 在 Block 中正交共存tools/train_moe_ple.py--top_k四、验证设计moe vs moeple 对照训练docs/moe_framework.mdffn_e五、结果PLE 在 MoE 框架下成立《Kestrel-MCU 手记》· 全系列 28 篇在 ESP32-P4 上从零训练并部署 32M~64M 参数 MoE 大模型5.7~6.4 tok/s源码、权重、训练脚本与全部文章开源可复现。仓库https://gitee.com/pei-xiaoguang/kestrel-llm-mcu · 觉得有用欢迎 Star
17 · MoE 与 PLE 正交共存稀疏专家加逐层查表的完整实现English version:en/17-ple-under-moe.md本篇对应源码tools/mistral_ple.py·tools/train_moe_ple.py·docs/moe_framework.md目标把 MoE 叠进 PLE完成「更大模型」的最终配方。前面几篇的 PLE 验证都在 dense FFN 上做esp32-ai 原始结构而我们的真实模型是 MoE。本章讲实现——MoEFFN 怎么加、MoE 与 PLE 怎么共存、验证怎么设计。一、为什么需要这一章前文已锁定的「更大模型」形态是三块拼图部件作用放置coreMoE 稀疏激活省带宽SRAMheadtied 小省全扫PSRAMtablePLE 三值查表承载容量flash但 PLE 的验证14 篇 / 16 篇都是在dense FFN上做的。我们的真实模型是MoE 8 专家所以「MoE PLE」的组合是否成立、实现怎么做是完整配方落地前的最后一块。二、实现MoEFFN在 esp32-ai 的model.py里把 Block 的 dense SwiGLU 换成 MoEFFNclassMoEFFN(nn.Module):def__init__(self,cfg):super().__init__()self.n_expertcfg.n_expert self.top_kcfg.top_k self.routernn.Linear(cfg.d_model,cfg.n_expert,biasFalse)hcfg.ffn_eifcfg.ffn_e0elsecfg.ffn_hidden self.expertsnn.ModuleList([SwiGLU(cfg,hiddenh)for_inrange(cfg.n_expert)])defforward(self,x):B,T,Dx.shape pF.softmax(self.router(x),dim-1)topk_val,topk_idxtorch.topk(p,self.top_k,dim-1)xfx.view(B*T,D)outtorch.zeros(B*T,D,devicex.device,dtypex.dtype)idx_ftopk_idx.view(B*T,self.top_k)val_ftopk_val.view(B*T,self.top_k)forkinrange(self.top_k):foreinrange(self.n_expert):selidx_f[:,k]eifsel.any():out[sel]val_f[sel,k].unsqueeze(-1)*self.experts[e](xf[sel])returnout.view(B,T,D)设计要点稀疏 top-k只对选中的专家算 FFN未选中的专家不参与 forward省计算、省带宽。ffn_e 独立于 ffn_hidden每个专家是独立 SwiGLUhidden 用ffn_e与 dense 的ffn_hidden解耦。router 算进 corerouter d_model × n_expert也是每 token 全算的 dense 权重自然归入 core 预算。三、PLE 与 MoE 的共存关键点MoE 和 PLE 在 Block 里是正交的互不干扰defforward(self,x,cos,sin,pleNone):xxself.attn(self.attn_norm(x),cos,sin)xxself.ffn(self.ffn_norm(x))# 这里 ffn 是 MoEFFN 或 SwiGLUifpleisnotNone:# PLE 注入在 FFN 之后gF.gelu(self.ple_gate(x))xxself.ple_norm(self.ple_proj(g*ple))returnxMoE 稀疏化 core 的 FFN→ 省带宽top-2 激活只算 2/8 专家PLE 加 table 承载容量→ 省 head25M 参数塞 flash 查表每 token 只读一行两者解决的是不同问题叠加不冲突。四、验证设计对比moe vs moeplecore-matched二分 ffn_e 使两者 core 都 ≈ 10MarmFFNffn_ecoretablemoeMoE8 专家 top-2819.99M0moepleMoE8 专家 top-2求解≈10M40.96M配置dim 312 / 10 层 / vocab 32002 / n_expert 8 / top_k 2TinyStories3000 步。五、结果PLE 在 MoE 框架下成立armcoretabletotalbest pplmoe9.99M019.98M5.84moeple9.99M40.96M60.94M5.35moe 5.84 → moeple 5.35 0.088 nats / 9.2% ppl 改善core-matched两者 core 都 ≈ 9.99MPLE 只多了 40.96M 的 flash 查表每 token 只查 10 行几乎免费PLE 在 MoE 框架下成立且收益比 dense 框架0.078 nats还略大六、结论完整配方验证通过「更大模型」的最终形态至此三块拼图全部用硬数据走通部件验证结果coreMoE 稀疏激活省带宽top-2 只算 2/8 专家tablePLE 三值查表0.088 nats三值 20× 压缩几乎无损headtied 小省全扫PLE 在 dense 框架成立0.078 nats16 篇PLE 在 MoE 框架成立0.088 nats本篇三值 table 几乎无损0.001 nats20× 压缩15 篇完整配方MoE core PLE table三值 headtied是「更大模型又不慢」的已验证正解。对应源码文件关键符号 / 位置支撑本文哪部分tools/mistral_ple.pyMistralPLEConfig配置n_expert/top_k/ffn_e/ple_dimtools/mistral_ple.pyMoEFFN二、实现MoEFFN 稀疏 top-k 专家tools/mistral_ple.pyDecoderLayer三、PLE 与 MoE 在 Block 中正交共存tools/train_moe_ple.py--top_k四、验证设计moe vs moeple 对照训练docs/moe_framework.mdffn_e五、结果PLE 在 MoE 框架下成立《Kestrel-MCU 手记》· 全系列 28 篇在 ESP32-P4 上从零训练并部署 32M~64M 参数 MoE 大模型5.7~6.4 tok/s源码、权重、训练脚本与全部文章开源可复现。仓库https://gitee.com/pei-xiaoguang/kestrel-llm-mcu · 觉得有用欢迎 Star
![打卡信奥刷题（3622）用C++实现信奥题 P11827 [TOIP2024] 大步小步向前走](http://pic.xiahunao.cn/yaotu/打卡信奥刷题（3622）用C++实现信奥题 P11827 [TOIP2024] 大步小步向前走)
