Qwen3.8-Whittle-MoE-27B-A17.8B 完全解析：零新权重把27B稠密模型变成17.8B激活MoE，24GB显卡本地跑通
Qwen3.8-Whittle-MoE-27B-A17.8B是一个开源的"事后 MoE"模型：它把稠密的 Qwen3.8-27B 的 FFN 层精确切割成 64 个专家切片，不新增任何一个 FFN 权重，只重新训练了每层的 tiny 路由器，让每个 token 只激活 17.8B 参数。量化后 24GB 显存的显卡就能本地跑通，是"小显卡跑大模型"方向少见的完整可复现实验。
一、它到底做了什么：零新权重的"外科手术"
传统做 MoE（混合专家模型）需要从头训练，而 Whittle 的思路是切分（partition），而不是重建：
- 父模型每一层的稠密 FFN 宽度为 17408，被切成64 个宽度 192 的路由专家+1 个常驻共享专家（宽度 5120）；
- 算术上完全精确：
64 × 192 + 5120 = 17408，一个神经元都不少； - 每层一个小路由器为每个 token 从 64 个专家中挑 16 个，于是每个 token 只运行 8192/17408 的 FFN 宽度——27B 总参数中只有 17.8B 是激活的；
- 注意力侧（64 层、16 个 full attention 层与 gated deltanet 线性注意力混合、hidden size 5120）完全没动。
切完的第一版输出是乱码（知识测验 39 题只答对 4 题）。研究者随后冻结全部专家，只训练 64 个路由器，成绩立刻恢复到 27/39——说明知识一直都在切片里，路由器只需要学会"该点燃哪些专家"。这个"先救路由器"的方法，是本项目最值得借鉴的部分。
二、24GB 显卡本地部署：最快跑通方法
模型以 bf16 safetensors 形式存放在仓库根目录（15 个分片），推荐下载官方量化版 GGUF（Q4_K_M），用 llama.cpp 启动服务：
llama-server -m Whittle-MoE-27B-A18B-v2.2-Q4_K_M.gguf --host 0.0.0.0 --port 8090 -ngl 99 -c 8192 -fa on --jinja几点实用建议：
- 显存：Q4_K_M 量化后 24GB 单卡可跑；显存更紧张时可拆到两块 12GB 显卡；
--jinja参数很重要，它会启用模型自带的 chat_template.jinja 聊天模板，多轮对话才不会出现格式问题；- 需要多轮对话或长上下文时，
-c 8192的上下文长度可按需调整； - 仓库内的 loop_test.py 是一套现成的"复读率"测试脚本，指向服务地址即可复现官方发布的所有数字，例如
python loop_test.py http://localhost:8090。
本地文件资料：
- 主模型权重索引：model.safetensors.index.json
- 架构配置（64 专家、top-16、共享专家 5120）：config.json
- 生成参数（temperature 0.7 / top_p 0.8 / top_k 20）：generation_config.json
三、质量表现：从"复读机"到"会收尾"的四个版本
这个项目的公开日志非常坦诚，版本迭代本身就是一篇教程：
| 指标（同套固定测试集） | 初版 | v2 | v2.1 | v2.2 |
|---|---|---|---|---|
| 单轮长回答复读率 | 69% | 11% | 8% | — |
| 多轮对话复读率 | 64% | 7% | 7% | 7% |
| 结构化输出（SQL/HTML/表格）复读率 | ~75% | 39% | 22% | 22% |
| 知识测验 | 28/39 | 27/39 | 28/39 | 28/39 |
几个关键发现，对想自己微调 MoE 的人很有价值：
- 复读与提前截断是同一根轴的两端。v2.2 之前，"治复读"的训练总会让模型学会"提前闭嘴"，五轮消融实验（完整记录在 WHITTLE_FINDINGS.md）证明：缺失的不是"要不要停"，而是"何时停"；
- v2.2 的停止门（stop gate）只训练了 64 个
shared_expert_gate张量，共 0.33M 参数、0.66MB，却把"数数列表"的干净收尾率从 18/36 提到 27/36，列表复读指标从 0.237 降到 0.048； - v2.2.1修复了开启推理（reasoning）时在思维链中提前结束回合的 bug：开启推理的 24 条探针中，"没输出
</think>就结束"的比例从 21/24 降到 3/24。修复文件在 v2.2/shared_expert_gate.safetensors，旧门被归档以便回滚； - 若你的场景是"给我恰好 N 条"，官方建议锁定 v2.1；其余场景 v2.2 更好。
四、诚实的局限（使用之前必读）
官方在 README.md 中把短板写得明明白白：
- 结构化输出仍偏弱：SQL、HTML、markdown 表格生成约 39% 会退化，比 75% 好了但仍不算可用；
- 继承家族弱点：偶尔出现臆造的词和"毛边"数字，算术能力一般（仓库里 arith_eval_shexp.json 记录了多题只答对 3/5 的实况）；
- 评测规模小：单人小测试架，所有数字应视为"车间测量"而非权威 benchmark；
- 量化版 GGUF 尚未重建 v2.2.1 门，跑量化档时建议保持 reasoning 关闭。
五、仓库结构与进阶资源
除了可直接部署的主权重，仓库里还保留了完整的训练过程资产，适合想深入 MoE 压缩的研究者：
| 路径 | 内容 |
|---|---|
| v1/ | 第一代 MoE 权重（router-heal 之前） |
| v2/ | v2 反循环轮次完整权重 + 聊天模板 |
| v2-adapter/ | v2 训练使用的 LoRA 适配器（router 与 gate 全参保留） |
| v2.1/adapter/ | v2.1 平衡轮次的适配器 |
| router-heal-adapter/ | 路由修复阶段 LoRA 适配器 |
| arith-shexp-lora/ | 针对算术的 shared_expert LoRA 及其评测记录 |
| ROADMAP.md | v3 规划：k 值扫描、DRY 采样器、训练轮预算与风险登记 |
| WHITTLE_FINDINGS.md | 全部实验日志，包括 13 个踩坑记录（EOS 掩码反噬、优化器内存、就绪检查等） |
如果只想快速上手，记住三句话：下载 v2.2 的 Q4_K_M GGUF → llama.cpp 加--jinja启动 → 24GB 显存即可对话。
六、总结
Qwen3.8-Whittle-MoE-27B-A17.8B 最大的价值不只是"27B 模型 24GB 跑起来"，而是它用公开的方法、数据集和失败日志证明了一条路：稠密大模型可以事后改造成 MoE，而且最先该救的是路由器。对新手而言，它是研究 MoE、蒸馏和"何时停止生成"这一难题的难得教材；对本地部署用户而言，它是一张入门 17.8B 激活参数模型的现实选择。需要提醒的是，结构化输出与算术仍是短板，生产环境请结合具体任务自行验证。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
