如何修复会复述不停的大模型Qwen3.8-Whittle-MoE-27B-A17.8B 从69%循环率到8%的完整训练方法论Qwen3.8-Whittle-MoE-27B-A17.8B 是一个把 Qwen3.8-27B 切分出来的开源 MoE 大模型项目它完整公开了修复大模型复述不停故障的全过程单轮循环率从 69% 一路压到 8%方法、数据集和所有失败记录全部透明。如果你的模型也在无限复述、列表越列越长、或者突然只回一个词就沉默这套训练方法论值得仔细看一遍。一、先量化故障69%循环率是怎么测出来的谈修复之前项目方先回答了一个看似简单的问题模型到底有多少次在循环这个 MoE 模型直接从 Qwen3.8-27B 切分而来基线的单轮循环率是 69%——几乎每 10 次长回答里有 7 次会陷入重复。但得出这个数字的过程有两个大坑。1. 旧指标对最常见的复述是盲的最初用的指标是rep-4gram重复 4-gram 占比它能抓同一句话逐字重复的情况比如某次生成把 Providing help with gaming 连续输出了 6 遍。但更常见的故障是模板式复述模型反复使用同一个句式骨架只轮换结尾的词——Helping with financial planningHelping with health and wellnessHelping with travel and tourism……这些行两两之间没有一个 4-gram 是相同的rep-4gram 打分是干净的 0.000。指标完全看不见这种故障。这就是为什么此前多轮修复都在数据上看起来还行用户体验却依旧复述不停——不是训练的错是仪表看不见缺陷。2. 换上一套三件套新指标团队改用三模式判定任一模式越线即判该次生成失败实现见仓库中的 loop_test.py检测模式阈值抓什么4-gram 重复rep4 0.15逐字重复同一句整行重复line_dup 0.20去掉序号/符号后整行重复模板头重复tmpl_rep 0.40列表项共用同一句首两词配套的铁律写进了发现日志任何指标用来下结论之前先拿已知故障样本和已知干净样本验证过。实测中干净样本打 0.200真实故障全部 ≥ 0.6090.40 的阈值两侧都有真实余量。完整的测试脚本就是 loop_test.py12 条单轮提示词 × 3 个随机种子、6 条结构化输出、2 段各 7 轮的多轮对话共约 90 次生成。项目公布的所有循环率数字都可以用它复现或挑战。二、核心发现复述和停止是同一条轴这是整个项目最有价值的结论复述与提前截断是同一种行为的两个端面不是两个独立的 bug。五轮实验的数据地图在最终解法之前团队做了 5 轮不同的训练配置同一套测试集、同一个基线记录在 WHITTLE_FINDINGS.md轮次数据策略教师目标中的 EOS结束符单轮循环率基线不修保留69%A仅长文档蒸馏保留长回答仍在循环B增加 on-policy 循环样本8 倍权重保留~0%但 6/16 回答被截断C循环样本减半 全局屏蔽 EOS全部屏蔽90%D8 倍循环样本仅对循环行屏蔽 EOS部分屏蔽75%规律一目了然越接近教会模型停截断越严重越保护截断循环越回来。机制在回头看时几乎是显然的在循环样本上学生模型刚开始复述的那一刻教师模型的意见几乎都是该停了。这是整批数据中最大的分歧点梯度被它主导。训练久了模型学到的就不只是在循环点停下而是泛化成到处都早点停——有的回答只剩一个 Sure有的直接是空的。推理端验证EOS 偏置剂量曲线为了证明这是模型本身的性质而非训练事故的产物团队直接在推理端做了实验给 EOS 对数概率加正偏置人为推模型停下从 0 一路加到 9。结果很说明问题循环确实从 11/12 降到 0/12但中位回答长度也从 278 词掉到 7 词。这个旋钮从全循环一路滑向全沉默中间根本没有健康的工作点。这等于证明了一件事答案完了就该停的知识完全不在权重里。任何推理端的全局压力、神经元修补都救不回缺失的信息——只能靠训练把它放进权重。三、v2 方案蒸馏完整答案教会模型何时停想清楚缺什么之后解法就明确了蒸馏那种因为写完了而结束的完整答案。教师数据集245 份完整答案让父模型 Qwen3.8-27B 回答同一批曾触发循环的提示词并在每个位置采集前 32 个 token 的完整概率分布不止正确答案还有教师在每个位置的概率判断。数据集刻意覆盖所有长度尺度一句话就结束的事实型短答案7 个 token中等长度的解释数到第 N 项就结束的长列表最长 4000 token 的结构化文档代码回答多轮对话——且每段对话的最后一轮故意要求总结整段对话因为实测中模型退化最严重的正是后段轮次有两个细节救了这一轮也最值得学习者注意先生成数据前先做泄漏审计。最初测试用的 12 条提示词里有 11 条已经出现在训练列表里——拿它们训练再拿去测试循环率必然下降但数字毫无意义。最终训练集与测试集完全重划。只用长答案的数据集教会的是长度先验而不是停止。如果每条答案都 150–400 词模型学到的捷径是到 300 词左右就停——那只是把 EOS 偏置曲线用数据重造了一遍。必须混入全长度尺度才能教会依据内容判断何时结束。v2 的训练适配器就保存在仓库的 v2-adapter/ 中。四、v2.2 停止门0.33M 参数打赢 1.26 亿参数的 LoRA如果说 v2 教会了模型完整答案长什么样v2.2 又加装了一小块硬件停止门stop gate。Qwen3.5-MoE 风格的检查点里每层都有一组出厂时是随机初始化的张量shared_expert_gate——共 64 个、合计 0.33M 参数只占整个模型的 0.001%。它位于每个 token 都必然经过的共享专家路径上。做法是用父模型蒸馏 在预测终止符的那个位置上做显式监督把这 64 个门训练成每个 token 都生效的停止信号。由于标准 llama.cpp 本来就会应用这个张量权重直接可用、无需改任何代码。实测效果README.md指标v2.1v2.2计数列表能终止的比例18/3627/36对话轮次能终止的比例48 轮27/4841/48最坏窗口重复度0.2370.048对照实验同样关键用同一目标训练一个125.8M 参数的 shared-expert LoRA只做到 25/36 终止、超长率 3.24x——0.33M 的停止门打赢了380 倍参数量的方案。道理也在点子上停止信号必须放在永远活跃的路径上而不是放在随机才被选中的专家分支里。⚠️ 这组门张量还有一个教训第一次蒸馏采集差了一位——采集在终止符前一格就停了于是权重最高的训练位置恰好是教师预测换行的位置模型被放大了 32 倍地学会了继续说。规则用蒸馏 logits 训练停止行为时务必断言权重最高的位置真的携带终止符标签。旧版 v2.2 门张量归档在 v2.2/shared_expert_gate.safetensors方便对照。五、修复效果全景循环率从 69% 到 8%最终数字与基线相同的提示词、种子和测试脚本README.md指标修复前基线v2.1 修复后单轮循环率12 提示词 × 3 种子69%8%多轮对话循环率64%7%后段轮次第 5 轮起循环率56%8%结构化输出SQL/HTML/表格循环率~75%22%静默或截断的回答未测0知识题库39 题28/3928/39中位回答长度268 词388 词 循环率降到原来的九分之一知识分没有受损中位回答长度反而变长了——说明模型不是学会了用沉默来停而是真正学会了说完该说的再停。六、踩坑清单训练停止行为的 6 个陷阱这个项目的价值不只在于最终模型更在于它把错误完整公开了13 条完整记录见 WHITTLE_FINDINGS.md这里挑 6 条最通用的只测故障的验收关卡会被坏模型通过。只回一个词的模型重复度得分是 0.000——你会发布一个只说 Sure 的大模型。规则每个验收关卡至少配一个修复过头时会更差的指标这里是回答字数下限。全局屏蔽 EOS 摧毁停止能力。起初为了去掉该停的有害梯度把教师目标里的 EOS 全部屏蔽结果循环率反弹到 90%——因为在干净文档结尾EOS 恰恰是正确答案。规则一个信号在某种上下文有害、在另一种上下文正确时用条件化处理不要全局删除。门控提示词泄漏进训练集。训练和测试用同一批提示词数字就变成了记忆测试。规则先生成数据前审计重叠不要等训练完才发现。够不着的检查点。一次约 28 步的训练设了save_steps25只存一个检查点中途崩了等于白跑。后来固定为保存间隔 ≤ 总步数 / 3。悄悄吃显存的优化器。默认 fp32 AdamW 占 8.2GB 动量状态换 paged 8bit AdamW 省出 3.7GB——正好够把每步 token 预算翻倍。专家权重静默加载成随机噪声。键名不匹配时权重被随机初始化日志一切正常、输出全是胡话。规则每次加载后断言专家权重非平凡。七、如何部署运行 Qwen3.8-Whittle-MoE-27B-A17.8B架构上它是从 Qwen3.8-27B 切出的事后 MoE每层 17408 宽的稠密 FFN 被切成 64 个宽度 192 的专家碎片 1 个永远在线的宽度 5120 共享专家64×192 5120 17408算术完全精确没有发明任何新权重。路由器每个 token 只选 16 个碎片每个 token 实际激活 17.8B 参数总参数 27B——量化后 24GB 显存可跑还能切分到两张 12GB 显卡。当前版本是 v2.2.1根目录权重config.json 为模型配置修复了开启思考模式时在思维链内部提前结束回合的问题。用 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 注意GGUF 量化版尚未用 v2.2.1 的新门张量重建用量化版时请先关闭思考模式。启动后可以用仓库自带的验收脚本自测循环率python loop_test.py http://localhost:8090八、诚实的局限性与版本选择建议项目对残留问题毫不含糊结构化输出仍弱SQL、HTML、markdown 表格的生成仍有 39% 退化比 75% 好但还不够好能终止 ≠ 能计数v2.2 能可靠结束列表但不一定在要求的数量上结束。30 项以上的精确计数疑似是单遍 transformer 生成的架构深度上限——如果你的场景是给我恰好 N 项请固定使用 v2.1算术继承家族弱点实测样本可见偶发算错arith-shexp-lora/arith_eval_shexp.json所有数字都由一个人在小型测试台上测得请当作工坊测量而非基准测试。仓库里保留了完整谱系v1/早期权重、v2/v2 的 bf16 权重、v2.1/adapter/、router-heal-adapter/让模型从胡话恢复到 27/39 的 router 修复 LoRA以及规划下一轮工作的 ROADMAP.md。写给新手的方法论总结如果你要接手类似的模型行为修复任务从这个项目可以直接带走四条经验先测量再修复。它在循环不是一个数字。先建一套可复现的测试台像 loop_test.py并拿已知正/负样本验证过指标再谈方案。每个验收关卡都要配防过头指标。单一修复指标总能被退化解满足变沉默必须搭配长度下限这类健康度检查。缺失的知识只能靠数据放进权重。复述的本质是不知道何时停推理参数、神经元消融、加大专家数量都救不了缺失的知识蒸馏因为完成而结束的完整答案才是解药。把失败也发布出来。这个项目的真正价值是连同所有错误——包括比不修还糟的 90% 循环率——一起把数字公开了。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考