MiniMind-O MoE版解析0.3B-A0.1B的容量分配实验是怎么做的【免费下载链接】minimind-o️ A 0.1B Omni model trained from scratch, capable of listening, speaking, and seeing!项目地址: https://gitcode.com/gh_mirrors/mi/minimind-oMiniMind-O 是一个从 0 开始开源实现的超小型 Omni 模型单一权重同时支持文 / 音 / 图三模态输入与文本、流式语音输出。项目发布了两个主干minimind-3o约 0.1B和minimind-3o-moe约 0.3B-A0.1B。后者并不是简单地把模型变大而是把稠密前馈网络换成 4 专家、每 token 只激活 1 个的 MoE 结构让总参数涨到 ~315M但每次前向激活的 active 参数仍停留在 ~115M 附近。这本质上是一次容量分配实验在算力基本不变的前提下多出来的容量该不该放进待命专家里本文面向新手讲清楚这个实验怎么设计、怎么实现、得出了什么结论。先看懂 0.3B-A0.1B总参数与激活参数为什么不一样MoEMixture of Experts混合专家的核心思想是网络里放很多专家子模块但每个 token 只路由给其中少数几个。于是会出现两个参数量总参数~0.3B模型文件里真实存储的全部参数激活参数A0.1B推理一个 token 时真正参与计算的部分。MiniMind-O 的两个版本在发布口径上对比如下数据来自 README.md 的模块参数表统计口径minimind-3o (Dense)minimind-3o-moe (MoE)可训练主体113.13M314.89M冻结外部模块音频/视觉编码器、Mimi 编解码424.70M424.70M运行时总加载537.83M739.59M多出来的约 200M 参数去了哪里答案在架构里MiniMind-O 主体由 Thinker8 层、hidden 768负责理解与生成语义和 Talker4 层负责把语义渲染成 8 层 Mimi 音频码组成。MoE 版本中这两条路径的每一层 MLP 都被换成了专家模块模块Dense 参数MoE 参数Thinker8 layers, hidden 76863.91M198.42MTalker4 layers, 8 codebook heads47.05M114.30M这正是实验的分配含义新增容量同时摊给理解侧和声学侧而不是只加大某一边。MoE 具体怎么实现4 个专家每个 token 只激活 1 个整个 MoE 实现集中在 model/model_minimind.py 的MOEFeedForward里配置项见 MiniMindConfig默认值非常克制配置项默认值作用num_experts4每层 4 个专家num_experts_per_tok1top-1 路由每 token 只走 1 个专家moe_intermediate_size与 dense MLP 相同单个专家宽度对齐原 FFNrouter_aux_loss_coef5e-4负载均衡辅助损失系数前向过程可以概括为四步打分一个线性 gate 把 hidden state 映射到 4 个专家分数softmax 归一路由取 top-1 专家其余 3 个专家不参与本 token 的计算梯度直通top-1 的权重用top1 - top1.detach() 1.0构造前向值固定为 1梯度却可以回传给路由器——这是保证路由可学习的直通透梯技巧负载均衡训练时计算辅助损失aux_loss (load × scores) × num_experts × coef惩罚专家被访问的不均匀防止某个专家独占流量同时用一个 0 乘法的 trick 让未激活专家也留在计算图中保证它们每一步都能收到梯度。Thinker 和 Talker 所有 MoE 层的aux_loss会在 model/model_omni.py 中汇总后加进总损失最终以MoeCausalLMOutputWithPast输出。实验设置同一套数据与训练管线只翻一个开关这个实验最有价值的一点是控制了变量。Dense 与 MoE 版本沿用完全相同的数据顺序和训练阶段区别只是训练命令里的一个参数--use_moe定义见 trainer/train_sft_omni.py。trainer/train.sh 中分别给出了 Dense 和 MoE 两套 full 训练管线阶段完全一致sft_t2a先对齐文本到语音让 Talker 学会生成 Mimi codessft_a2a接入语音输入走完整的听—想—说链路sft_i2t最后只更新视觉投影层对齐图像路径。训练时 checkpoint 会带_moe后缀如sft_omni_768_moe.pth加载逻辑见 trainer/trainer_utils.py。同一文件里还有一段active 参数的统计函数它从总参数中减去全部 routed expert再按num_experts_per_tok加回激活的那一份——这就是 317.05M-A115.33M 这类口径的计算方式trainer/trainer_utils.py。实验结果多出来的容量到底买到了什么评估用统一 ASR 转写后计算 CER字符错误率并按回答长度分桶。Talker hidden size 消融中 Dense 与 MoE 各自的结果如下架构Talker hidden参数总-A激活平均 CER ↓短句 ↓中/长句 ↓Dense768115.29M0.08970.15280.0874 / 0.0675Dense51296.13M0.17450.27090.2455 / 0.0976Dense38488.72M0.27670.39040.1865 / 0.4046MoE768317.05M-A115.33M0.09000.20750.0533 / 0.0271MoE512261.32M-A96.17M0.12650.07110.1490 / 0.1464MoE384240.04M-A88.75M0.32800.37570.2777 / 0.4313两个数字要分开看同架构内部趋势明确768 明显优于 512 和 384——小并不自动等于划算压缩到 384 维后中长句的漏词、重复和发音漂移会显著恶化Dense 与 MoE 不宜直接横向比 CER两个 Thinker 生成的内容和长度不同Talker 面对的合成难度也不同。在 768 这一档上MoE 的平均 CER0.0900与 Dense0.0897几乎持平但分布很有意思中长句 MoE 更稳0.0533 / 0.0271 vs 0.0874 / 0.0675短句反而略差0.2075 vs 0.1528。说明待命专家容量主要买到了长句一致性而不是整体平均水平的提升。音色克隆维度的结论同样直接12 个测试音色上Dense 与 MoE 的 CAM speaker embedding 余弦相似度均值非常接近个别音色互有胜负。项目方据此判断——音色保持不主要由 inactive expert 容量决定更直接的影响来自参考片段质量、speaker embedding 的可分性以及 Talker 生成音频本身是否稳定。如何亲自跑一遍 MoE 版推理与训练入口推理下载 transformers 格式权重后用 eval_omni.py 命令行问答或启动webui/web_demo.py体验实时语音交互minimind-3o与minimind-3o-moe均支持训练cd trainer bash train.sh可跑通 mini 数据集链路full 数据集下只需把命令中的--use_moe 0改为--use_moe 1其余超参、数据顺序与 Dense 版保持一致结构阅读MoE 层在 model/model_minimind.pyThinker–Talker 组装与 aux_loss 汇总在 model/model_omni.py 与 model/model_omni.py。结论这是一次容量分配实验不是同算力最优解README 对 MoE 版本的定位很坦诚更像一次容量分配实验而不是同算力最优解。把实验结论浓缩成三点激活算力不变总容量可以翻倍top-1 路由下每个 token 的计算量与 dense 相当存储多 ~200M 专家换来的是中长句稳定性的边际改善容量摊给 Thinker 和 Talker 两边是可行分配MoE 参数增量约四成落在 Thinker63.91M→198.42M、约六成落在 Talker47.05M→114.30M两边都有收益点瓶颈不在专家容量音色克隆相似度在两个版本上基本打平说明 0.1B 级别的短板更多在声学端条件建模参考音色、韵律而不是 FFN 容量不足——这也解释了为什么后续改进方向列的是更细的 prosody 监督和更稳的音色条件而非继续加专家。如果你想动手验证最短路径是读一遍MOEFeedForward约 30 行实现 → 按 trainer/train.sh 跑一次 mini 链路单卡 3090 约 2 小时→ 用 eval_omni.py 对比两个版本在中长句上的发音稳定性。这正是 MiniMind-O 这套代码想支持的研究方式足够小、足够透明、可以从第一行读起。【免费下载链接】minimind-o️ A 0.1B Omni model trained from scratch, capable of listening, speaking, and seeing!项目地址: https://gitcode.com/gh_mirrors/mi/minimind-o创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考