企业官网建设流程全解析

1. 项目是什么

Snowflake MoE 是一个可组合的稀疏 MoE 架构。与标准 MoE 维护一个固定专家池不同，Snowflake MoE 用少量基础的「细胞器」（organelle）加上可学习的「忆点」（memory），通过组合的方式在运行时生成临时专家：细胞器提供可复用的计算原语，忆点负责按输入检索并读出领域相关信息，二者组合出远超参数量的有效表达能力。项目由个人独立研究推进，全部代码与实验脚本开源。

这个设计想回答的问题很具体：稀疏 MoE 能不能不靠「堆专家」也能获得足够的容量，同时保留两条标准架构没有的能力——一是往模型里增量加入新领域知识（终身学习），二是按需擦除某些记忆（安全擦除），三是把已经学会的组件组合到未见过的输入上（组合泛化）。围绕这三条能力线，我们做了一系列有数据支撑的验证，也踩了一个影响深远的参数 bug。这篇博客记录截至 2026-10-05 的真实进展，包括成果、负结果、根因修复与工程经验。

2. 已验证的成果

目前有五个有数据支撑的正向结果。

（1）可导容量惩罚优于 Token Dropping。在合成数据（12 epoch）上，可导容量惩罚（differentiable capacity penalty）的验证准确率为 0.8955，Token Dropping 只有 0.7383。Token Dropping 通过硬丢弃 token 强制负载均衡，代价是约 79% 的训练 token 被丢弃、信息大量损失；可导容量惩罚把均衡约束放进损失项，不丢 token，精度显著更高。它唯一的劣势是负载均衡不如硬丢弃那么极致（CV 0.132 vs 1.4 量级），但以精度为代价的均衡不可取。这是项目里最强的正结果之一，也是后续论文的主线方向。

（2）单级 CellMoE 与同参数 Fixed MoE 打平。在 TinyStories 上，CellMoE 的 PPL 为 10.0157，同参数量的 Fixed FFN MoE 为 10.0152，差异在噪声范围内。这个结果本身不算突破，但意义在于：可组合架构在同等参数下没有劣化，为后续在大规模上体现组合优势提供了基线。参数效率曲线进一步显示，在 0.5M 到 1.8M 区间两种架构的 PPL 都稳定收敛在 10.01–10.02，说明当前规模下模型还没有真正「吃满」容量。

（3）终身学习 v4（InputAwareGate）显著改善旧域退化。把全局标量门控换成输入相关门控（投影零初始化 + pooled mean + softmax）后，旧领域（TinyStories）退化从 v3 的 +0.78 降到 -0.57（不仅没有退化，PPL 反而略降），新领域（圣经 KJV）困惑度下降 21.6%，跨过 20% 的验收线。这一改动证明：门控必须能按输入区分旧/新领域，全局标量做不到。剩余的未达标项是新忆点激活率口径（当前统计天然恒为 100%，需要改为门控硬判定口径），属于统计口径而非门控失效。

（4）单卡算力被有效榨干。在单张 DCU 上通过 4 路并行 + 大 batch 把 GPU 利用率从约 30% 拉到 100%，CPU 使用率降到约 10%，GPU 温度稳定在 56°C。多路并行共享单卡且互不 OOM，说明小参数模型的主要瓶颈是计算密度不足而非显存。这也为后续多路并行跑参数效率曲线铺了路。

（5）参数压缩空间存在。把模型从 1.8M 参数压到 0.5M，两种架构的 PPL 差异都小于 0.03%（CellMoE 0.5M=10.0172 vs 1.8M=10.0160；Fixed 0.5M=10.0142 vs 1.8M=10.0141）。当前规模下参数冗余明显，模型还有很大的压缩空间，这对低资源部署是利好。

3. 发现的负结果

负结果同样重要，这里如实记录四个未达标的实验。

（1）终身学习 v3/v5：旧领域退化 +1.8。在 v3（标量分组门控）与 v5 实验中，加入新忆点后旧领域 PPL 稳定退化约 +1.8，远超 0.3 的验收线。原因有两层：一是标量门控无法按输入区分旧/新领域；二是当时叠加了另一个 bug（见第 4 节 scale bug），新忆点输出被放大后直接淹没旧领域。v4 用 InputAwareGate 修复了第一层，scale bug 到更晚才被定位。所以 v3/v5 的失败现在被判定为「根因未清理前的假失败」，需要 scale=1.0 下重跑验证，而非简单采信旧结论。

（2）安全擦除未达标。100% 擦除 memory_value 后 PPL 为 22.83，低于 30 的验收线。也就是说，擦除记忆槽并不能让模型「忘记」到可接受的程度。机制探索进一步表明：细胞器本身也承载了与记忆键不可分离的知识，仅解耦 memory_value 不足以实现干净的安全擦除，需要更彻底的架构级解耦（例如擦除时把 assembly 一并归零，或引入独立的可擦除记忆总线）。这是安全方向最重要的开放性挑战。

（3）RL 动态治理在合成数据上失效。用可学习元控制器（REINFORCE）动态调节容量惩罚、稀疏度等超参，在合成数据上连续三次限制触发，val_acc 都停在约 0.8955 附近，无法突破。根因是数据规模太小（d=16、4096 样本），路由已固化，主模型精度上限就在那里；同时奖励噪声（std≈0.24）淹没了 CV 惩罚信号。这是一个「物理失效下限」，不是调参能解决的。转向 MNIST 后控制器能观察到稀疏度动态调整，但统计上仍不显著，见下一条。

（4）MNIST 上 5 seed 无显著差异。在 MNIST（PCA 64 维）上跑 5 个 seed，learned 控制器 vs fixed vs rules 三种模式的准确率差异统计检验 p > 0.05，无法断言可学习治理优于规则治理。均值上 learned（0.9513）略高于 rules（0.9446），但差异不显著。这类「均值有差、统计不显著」的结果我们按无显著差异如实记录，不写进成果。

4. 关键发现：scale bug

上面这些「失败」里，最值得写的是一个参数 bug。

memory_read_scale 默认值是 25.0。训练脚本里忆点读取的缩放系数默认被设为 25.0，意味着忆点输出被放大 25 倍后再进入最终输出。后果是：忆点输出主导了整个模型输出，梯度几乎全部被吸进 memory_value，细胞器几乎得不到梯度。这解释了为什么终身学习 v2-v5 的旧领域稳定退化 +1.8——新忆点 val 被 25 倍放大后直接淹没旧忆点输出；也解释了为什么安全擦除 100% 后 PPL 只有 22.83——模型已学成「只靠忆点输出」，而擦除又擦不掉细胞器里的知识。

更隐蔽的是，构造链路（FastHierLM → FastHierCellMoE → FastCellMoE）没有显式透传这个参数，全部落到子类默认值 25.0，所以改上游默认值不影响下游，排查时容易被误判为机制失败。这也是把它单独写成一段的原因：一个藏在默认值里的系数，能让一整批机制实验集体失败，而每一个失败单独看都像「架构不行」。

修复方式很简单：统一把 memory_read_scale 改为 1.0，与基线训练一致。当前正在 PAI-DSW（A10）上用 scale=1.0 重跑四个关键实验：阶段一、终身学习 v6、安全擦除 v2、组合泛化 + Fixed 对比。这些实验的结果尚未出来，本文不预测。如果 scale bug 确实是共同根因，预期旧域退化会显著下降、擦除敏感度上升；如果不是，我们会把新数据如实更新到本文。

5. 工程与部署经验

TDD + 红队审查。项目维持测试先行：新增模块先写测试，当前测试 8/8 全绿；每次合入前做红队审查，重点检查门控接线、超参透传、梯度流向等容易「静默出错」的环节。这次 scale bug 能定位，部分要归功于对「超参默认值是否全链路一致」的追查——先 grep 所有 memory_read_scale=25.0 的位置，再确认构造链路的每一层都透传，而不是只改一处默认值。

从曙光 DCU 迁移到 PAI-DSW。项目先在曙光智算 DCU（DTK 环境）上运行，之后迁移到阿里云 PAI-DSW（标准 CUDA，A10）。迁移暴露了一类典型问题：非标准加速卡生态（DTK）的算子行为与 CUDA 有差异，Gumbel-Softmax 之类的随机路径需要单独验证；而 PAI-DSW 是标准 CUDA 环境，代码几乎不用改，成为重跑翻盘实验的首选平台。

踩坑记录。

• DTK 生态适配：DCU 上部分算子行为与 CUDA 不同，需要逐算子验证；通信后端用 rccl、设备可见性用 HIP_VISIBLE_DEVICES，与 CUDA 习惯不同；
• SSH 443 端口：本地 22 端口被墙，改用 ssh.github.com:443 + 自定义 SSH config 才完成代码推送；
• hf-mirror 下载：HuggingFace 直连不稳定，数据与依赖走镜像源解决。

6. 下一步

1. 翻盘实验：等待 PAI-DSW 上用 scale=1.0 重跑的四个实验（阶段一、终身学习 v6、安全擦除 v2、组合泛化 + Fixed 对比），结果出来后更新本文与报告。
2. 规模扩展：把模型扩到 100MB 数据 + 10M 参数，验证可组合架构在大规模下的参数效率与组合优势。
3. 论文投稿：以「可导容量惩罚」为主线整理实验，目标投稿。
4. 注：本文由作者独立研究与撰写，文字整理过程中使用了 AI 辅助，实验数据与结论均来自作者实际运行。