MOE模型死亡循环到6层防御之解决之道！

马甲三号

2026年5月25日 11:49
江苏

在小说阅读器读本章

去阅读

MoE 死亡循环深度拆解：48 小时排障 + 6 个月治理工程实录

基于 oai-mlx 项目一线排障与持续治理

模型：Qwen3.6-35B-A3B-8bit

后端推理引擎：vLLM-MLX → Rapid-MLX

面向读者：正在折腾本地大模型的、想在隔离网折腾Hermes、OpenClaw的、面对有长上下文 Agent+多轮工具链+历史消息膨胀不能自拔的工程师们～

目录

• • 第一部分：事故 — MoE 的「死亡循环」

• • 引子：一个飞书输出循环引出的事故

• • 1. 现象：什么是「死亡循环」
• • 2. 解剖 MoE：为什么它特别脆弱

• • 3. 现场取证：如何在系统里识别死亡循环

• • 第二部分：诊断 — 为什么防御总是不够

• • 4. 死亡循环的四种穿透路径

• • 第三部分：根治 — 六层纵深防御体系

• • 5. 总览：六层防御架构

• • 6. L1 采样层：从一刀切到模型感知
• • 7. L2-L4 推理层：三层检测器协同
• • 8. L5 上下文层：从被动压缩到主动防御

• • 9. L6 路由层：高风险任务不要交给本地 MoE

• • 第四部分：进化 — 从 vllm-mlx 到 Rapid-MLX

• • 10. 为什么换后端是根治的一部分

• • 11. Rapid-MLX 迁移

• • 12. 从「换 Dense」到「让 MoE 可用」

• • 第五部分：工程 Checklist 与最佳实践

• • 结语
• • 附录

第一部分：事故 — MoE 的「死亡循环」

引子：一个飞书输出循环引出的事故

飞书里Hermes Bot 正在执行一个威胁情报分析任务。

一开始一切正常：前 3 轮工具调用正常、MCP 工具返回正常、模型输出也正常，tok/s 稳定在 26 左右。

但到了第 4 轮，模型突然开始反复输出同一段话：

I will be concise. Okay, generating. The response is below.
I will start now…
I will be concise. Okay, generating. The response is below.
I will start now…
……

同样的句子重复了 20 多遍，直到撞上 max_tokens。

最终日志表现：

这不是一次普通 bug。它更像是 MoE 架构在「容量」和「可靠性」之间做取舍时，给推理系统、Agent 系统和运维者开出的一张账单。

一句话概括：

MoE 用更少激活参数换来了更高容量，但在长上下文、多轮工具调用、量化推理场景下，也更容易进入生成退化和专家路由坍缩。

1. 现象：什么是「死亡循环」

这里说的「死亡循环」，不是程序代码里的 while true，而是模型生成过程中的一种退化状态。

模型并没有真的卡死，它还在持续生成 token；但这些 token 不再推进任务，而是在重复同一段话、同一个模式、同一种思考模板。

1.1 三种常见亚型

我们这次遇到的是第二种：Preamble loop。

典型特征：

• • 模型一直说「我要开始了」，但永远没有真正开始
• • 输出看似连贯，实际没有任何任务增量
• • 最终通常以 finish_reason=length 结束

1.2 它和「多样性退化」是什么关系

Holtzman 等人在 2019 年的论文《The Curious Case of Neural Text Degeneration》中已经指出：语言模型在某些解码策略下会出现文本退化，比如重复、空转、低信息密度输出。

MoE 长上下文死亡循环，可以理解为这种退化现象在 MoE 架构下的极端版本。

Dense 模型的退化通常发生在「解码概率」层面：

token 概率分布越来越尖 → 模型越来越倾向选择少数高概率 token → 最终出现重复。

MoE 模型多了一个更危险的环节：

token 不仅会重复 → 重复 token 还会持续激活同一批专家 → 同一批专家又继续生成相似 token → 形成自增强闭环。

也就是说：

Dense 模型的问题主要发生在「解码概率」上；
MoE 模型的问题同时发生在「解码概率」和「专家路由」上。

这就是 MoE 死循环更难处理的原因。

2. 解剖 MoE：为什么它特别脆弱

2.1 Dense 和 MoE 的核心差异

Dense 模型：每个 token 都经过全部参数。无论输入是什么，模型都会调用完整网络。它的状态变化更平滑，即使某一步开始重复，也还有机会通过后续上下文扰动自然跳出来。

MoE 模型：每个 token 只激活少数几个专家。

例如我们这次使用的 Qwen3.6-35B-A3B-8bit：

这带来了很大的性能优势：只用 3B 级别激活成本，获得接近 35B 总容量的模型能力，本地推理速度不错，显存压力也相对可控。

但代价是：每个 token 的计算路径不再连续，而是由 router 离散选择专家。这让模型状态更容易出现「跳变」和「锁定」。

2.2 什么是「专家吸引子」

可以把 MoE 的生成过程理解成下面这条链：

1. 1. 当前 token 进入模型
2. 2. Router 根据 hidden state 选择一组专家
3. 3. 专家生成下一个 token 的表示
4. 4. 下一个 token 被采样出来
5. 5. 新 token 拼回上下文
6. 6. 下一步 router 再次选择专家

正常情况下，不同 token 会激活不同专家组合。但在死亡循环中，会出现一个现象：

同类 token 总是被路由到同一组专家，而同一组专家又继续生成同类 token。

这就是「专家吸引子」（Expert Attractor）。

它类似一个坑：模型一旦掉进去，下一步还是同一组专家，再下一步还是同一组专家，最后输出越来越相似，直到整个生成过程被锁死。

简化模型：

重复 token → 同一组专家 → 更像的输出 → 更重复的 token → 更稳定的专家路由

这就是 self-reinforcing feedback（自增强反馈）。

在我们的 Hermes 案例中，模型反复输出：

I will be concise. Okay, generating. The response is below.
I will start now…

这类 preamble token 很可能持续激活了相同或高度重叠的专家组合，导致模型始终停留在「准备输出」这个局部状态中，无法进入真正的任务内容。

2.3 为什么长上下文会放大问题

长上下文本身不是坏事，但它会放大三个问题。

第一，近邻污染。 模型生成时会参考已有上下文。一旦最近几百个 token 都是重复内容，模型就会误以为这种重复模式就是当前任务最合理的延续，于是继续重复。

第二，RoPE / YaRN 远端衰减。 长上下文模型通常依赖 RoPE、YaRN 等位置编码扩展技术。当上下文变长后，远处信息的有效权重会下降，模型更容易关注近处 token。如果近处 token 已经被循环污染，模型就更容易 copy 近邻内容。

第三，工具调用历史会制造重复结构。 Agent 系统里的上下文不是普通自然语言，而是高度模板化的内容：system prompt、tool schema、function call、tool result、observation、assistant reasoning、retry log。这些结构本来就重复。

在我们的案例里，Hermes 注册了 60 个 MCP 工具，多轮任务里不断堆积工具调用和工具返回。到第 4 轮时，输入已经接近 25K token。

这就是最容易诱发 MoE 路由坍缩的输入形态：

长、重复、结构化、工具化、多轮累积。

2.4 量化为什么会继续放大问题

很多人直觉上会觉得 8-bit 应该比 4-bit 稳。但我们的实测结果反过来：

为什么 8-bit MoE 反而比 4-bit Dense 脆？关键不在 bit 数，而在 MoE 多了一个 router。

• • Dense 模型的量化误差主要影响 token logits 和采样分布
• • MoE 模型的量化误差同时影响 token logits、router logits、专家选择和后续激活路径

也就是说，MoE 的误差不只是「输出有点偏」，而可能变成「走错专家」。更麻烦的是，一旦专家路径被锁住，后续每一步都在同一路径上继续累积误差。

所以：

Dense 的量化误差更像加性噪声；
MoE 的量化误差更像乘性放大器。

这就是我们最后发现的结论：

4-bit Dense 的稳定性，反而好过 8-bit MoE。

3. 现场取证：如何在系统里识别死亡循环

死亡循环不是玄学，可以通过几个指标快速识别。

3.1 看 finish_reason

如果一个任务经常以 length 结束，同时输出内容重复，就基本可以判断进入了死亡循环。

3.2 看生成速度

为什么循环时速度会掉？上下文变长、KV cache 压力变大、重复生成持续消耗 token budget、推理后端在长序列下效率下降。所以 tok/s 暴跌本身也是一个重要信号。

3.3 看 completion tokens 和 unique tokens

一个很实用的指标：

MRI = completion\_tokens / unique\_tokens

3.4 查 route\_events

如果 proxy 里有 route_events，可以查出高风险请求。重点看这些字段：

我们的经验：

tools_registered >= 8、tool_depth >= 3、tool_tokens >= 5000，任意一个满足，就应该进入高风险分流逻辑。

第二部分：诊断 — 为什么防御总是不够

上一部分我们描述了死亡循环的完整现象和取证方法。接下来的问题是：我们做了那么多防御，为什么还是防不住？

答案是：每一层防御都有自己的盲区，而 MoE 死亡循环恰好能穿透这些盲区。

4. 死亡循环的四种穿透路径

4.1 穿透路径一：采样层看不到工具调用

repetition_penalty、presence_penalty、frequency_penalty 这些采样参数只能惩罚 delta.content 中的重复 token。

但 MoE 死亡循环有一种特殊亚型——工具调用循环：模型反复调用同一个工具，每次工具调用在 SSE 流中体现为 delta.tool_calls 字段，而 delta.content 为空。

采样层完全看不到 delta.tool_calls，所以对这种循环毫无感知。

这是我们在 Hermes 场景中实际遇到的：模型连续调用同一个 IP 查询工具 5 次，每次都返回相同结果，但采样层认为一切正常——因为 content 里没有重复。

4.2 穿透路径二：N-gram 检测器看不到结构化重复

N-gram 早停是检测文本重复的有效手段，但它也有盲区。

MoE 死亡循环的输出不总是逐字重复。在工具调用场景中，模型可能每次生成略有不同的参数（比如查询不同的 IP），但整体行为模式完全相同——反复查询、反复分析、反复得出相同结论。

这种语义级重复，N-gram 检测器无法识别。

更隐蔽的是 Thinking loop：模型在 <think/> 中反复「重新审视」「让我再检查」，每次思考的具体内容略有不同，但本质上没有推进任务。N-gram 检测器看到的都是\"新\"文本，不会触发。

4.3 穿透路径三：压缩管线存在但永远不触发

这是最令人沮丧的一种穿透。我们部署了完整的上下文压缩管线——Layer 1（MEMORY.md 注入）、Layer 2（LLM 摘要）、Layer 3（工具结果压缩）、Lingua（token 裁剪）——但在实际运行中，压缩一次都没有触发。

原因有三：

瓶颈 1：工具链扩展吞噬全部可压缩历史。

Hermes 会话中几乎所有消息都携带工具状态。压缩管线的安全保留逻辑会从默认 cut 点向前回溯，直到找到第一条不带工具状态的消息，将整个工具链保留为\"近期消息\"。结果是：可压缩历史为 0，压缩跳过。

瓶颈 2：Token 估算偏低 33%。

代理层的 token 估算只计算消息文本，不包括特殊 token、角色标记、工具 schema 开销。实际测量：代理估算 ≈ 实际 prompt_tokens 的 67%。这意味着即使实际 tokens 已超过触发阈值，代理仍然认为\"低于触发线\"。

瓶颈 3：触发阈值被配置文件覆盖。

~/.config/oai-mlx-admin/proxy-env.sh 中设置了 OAI_COMPACT_TRIGGER_TOKENS=16000，覆盖了 restart 脚本中的 10000。配合估算偏低，实际需要约 24000 tokens 才会触发压缩。

这三种瓶颈叠加，导致了一个幽灵故障：压缩管线存在、配置正确、后端正常，但就是不触发。48268 tokens 的会话，Layer 2 压缩一次都没有执行。

4.4 穿透路径四：Lingua 压缩反而诱发循环

我们最早尝试将 LLMLingua 前置到 Layer 2 之前，先压缩工具结果再送入摘要。

但 Lingua 是 BERT 级别的 token 裁剪，不理解语义结构。工具结果中的 JSON 关键字段（IP 地址、CVE 编号、威胁等级标签）被压缩后丢失，导致 MoE 模型的 expert router 无法正确选择专家，触发死亡循环——模型反复生成相同的错误输出。

这揭示了一个深层矛盾：

在 MoE 架构中，语义完整性比 token 节省更重要。

Lingua 只能用于「锦上添花」的辅助压缩，不能用于「雪中送炭」的关键路径。

第三部分：根治 — 六层纵深防御体系

经过 6 个月的持续治理，我们构建了一套从采样到架构的六层纵深防御体系。每一层解决一种穿透路径，层与层之间互为兜底。

5. 总览：六层防御架构

6. L1 采样层：从一刀切到模型感知

6.1 问题：默认参数不够，手动调参容易过头

repetition_penalty 是最常见的止血手段。我们的 A/B 结果：

但问题是：不同模型、不同场景需要不同的惩罚值。MoE 模型需要更激进的参数，而 Dense 模型用同样的参数会损害输出质量。

6.2 方案：模型感知的采样参数注入

我们实现了 _apply_anti_repetition_defaults() 函数，根据模型类型和场景自动注入采样参数：

# 调度器层：MoE 模型使用更激进的参数
_ANTI_REPETITION_FREQUENCY_PENALTY = 0.3
_ANTI_REPETITION_PRESENCE_PENALTY = 1.5   # MoE 专用，符合 Qwen3.6-A3B 模型卡推荐
_ANTI_REPETITION_REPETITION_PENALTY = 1.15

# Compact 后端：最高风险场景使用最强防御
def _repetition_penalty() -> float:
    return _float_env(\"OAI_COMPACT_REPETITION_PENALTY\", 1.15)

后端启动脚本自动检测模型类型：

if [[ \"$_model_type\" == \"moe\" ]]; then
    DEFAULT_PRESENCE_PENALTY=\"1.5\"
    DEFAULT_REPETITION_PENALTY=\"1.15\"
fi

查找优先级：topology 配置 → 环境变量 JSON → 全局默认值。使用 setdefault 语义，用户显式设置的参数不会被覆盖。

6.3 presence\_penalty vs frequency\_penalty 的取舍

在威胁情报、代码、医学这类任务里，低频专业词非常重要。presence_penalty=1.5 配合 frequency_penalty=0.3 的组合，既有效抑制重复，又不会过度惩罚低频专业词。

7. L2-L4 推理层：三层检测器协同

7.1 N-gram 早停（文本模式重复）

_NgramLoopDetector 维护滑动窗口 token 缓冲区，对长度 3-24 的 n-gram 检查是否在窗口内出现超过阈值次。

关键设计：

• • 自适应阈值：短模式要求更高重复次数（pattern ≤ 4 需要 ≥ 8 次），长模式更宽松（pattern > 14 只需 3 次）
• • CJK 适配：中文无空格分词，自动切换为字符级 n-gram
• • 只对本地 MoE 后端启用：远端 Dense 模型不需要此检测

if NGRAM_EARLY_STOP_ENABLED and str(route.get(\"source\") or \"\") == \"local\":
    _ngram_det = _NgramLoopDetector()

7.2 Chunk 重复检测（大段文本重复）

_ChunkLoopDetector 在 SSE chunk 级别检测大段文本重复输出。对 CJK 内容使用前缀重叠相似度检测，避免 MoE expert collapse 产生的近重复段落漏检。

这是 N-gram 检测器的补充——N-gram 检测精确重复，Chunk 检测近似重复。

7.3 工具调用循环检测（填补最大盲区）

_ToolCallLoopDetector 是我们为 MoE 死亡循环专门设计的检测器，填补了采样层和 N-gram 检测器的最大盲区：

class _ToolCallLoopDetector:
    \"\"\"MoE models can enter a death loop where the expert router gets stuck
    and the model keeps emitting the same tool call name over and over.
    The N-gram detector only monitors delta.content and cannot see
    delta.tool_calls, so this specialised detector fills that blind spot.\"\"\"

    def feed_tool_name(self, name: str) -> bool:
        self._counts[name] = self._counts.get(name, 0) + 1
        self._total += 1
        return self._counts[name] >= self._max_same  # 默认 5 次即触发

它通过 _extract_sse_tool_call_names() 从 SSE delta 中提取工具调用名称，独立于文本检测路径运行。

7.4 字符级重复检测（病态退化）

_CharRepetitionDetector 检测病态字符级重复（如 !!!!!!），MoE thinking 模式下有时会退化到重复单个字符。默认连续 12 个相同字符即触发。

7.5 三层协同的流式集成

在 _gen() 流式生成函数中，三类检测器并行运行：

# 每收到一个 SSE chunk：
if _ngram_det isnotNoneand _ngram_det.feed(_content):
    yield _build_loop_guard_finish(obj_model=model_seen)
    yieldb\"data: [DONE]\
\
\"
    return

if _tc_det isnotNone:
    for _tc_name in _pt._extract_sse_tool_call_names(line):
        if _tc_det.feed_tool_name(_tc_name):
            yield _build_loop_guard_finish(obj_model=model_seen)
            yieldb\"data: [DONE]\
\
\"
            return

关键细节：loop guard 触发时标记 success=True, error_code=\"loop_guard\"，不触发后端熔断。这是一个重要的设计决策——保护性中断不应该惩罚后端实例，否则会导致实例被错误 cooldown，进一步恶化系统可用性。

8. L5 上下文层：从被动压缩到主动防御

8.1 压缩管线的三个修复

修复 1：百分比扩展限制（解决 no_old_history）

将工具链安全保留的扩展限制从固定消息数改为百分比：

# 修复前：固定值，短会话中太宽松
def _tool_chain_safe_keep_max_extension() -> int:
    return max(0, _int_env(\"OAI_COMPACT_TOOL_CHAIN_MAX_EXTENSION\", 12))

# 修复后：百分比限制，保证至少 65% 可用于压缩
def _tool_chain_safe_keep_max_extension_for_count(total_non_system: int) -> int:
    ratio = _float_env(\"OAI_COMPACT_TOOL_CHAIN_MAX_EXTENSION_RATIO\", 0.35)
    floor = max(0, _int_env(\"OAI_COMPACT_TOOL_CHAIN_MAX_EXTENSION_FLOOR\", 4))
    ceil = max(floor, _int_env(\"OAI_COMPACT_TOOL_CHAIN_MAX_EXTENSION_CEIL\", 24))
    return max(floor, min(ceil, int(total_non_system * ratio)))

效果：

修复 2：Token 估算乘数（解决 below_trigger）

添加 1.45x 开销乘数，使估算达到实际的 ~97%：

def _estimate_payload_tokens(messages: list[Any]) -> int:
    _OVERHEAD_MULTIPLIER = float(os.environ.get(
        \"OAI_COMPACT_ESTIMATE_OVERHEAD_MULTIPLIER\", \"1.45\",
    ))
    total = 0
    for m in messages:
        # ... 计算原始 token 估算 ...
    return max(1, int(total * _OVERHEAD_MULTIPLIER))

修复 3：触发阈值校准

将阈值从 16000 降到 14000（配合 1.45x 乘数，有效触发点约 10000 实际 tokens），压缩从第 9 轮提前到第 3 轮触发。

8.2 三级递进压缩（Layer 3）

基于 OpenHands StateSummary + OpenAI ToolOutputTrimiter，实施 3 级递进压缩：

效果对比：

8.3 Nudge 注入：引导模型跳出循环

Nudge 注入是上下文层的最后一道防线，在预处理管线的最后一步执行。

Continuation Nudge（工具结果后引导继续）

当最后一条消息是 tool 角色或倒数第二条 assistant 含 tool_calls 时，追加隐藏 user 消息：

You have received tool results above. Continue your task:
analyze the results, then either call the next required tool
or provide your final answer to the user.
Do NOT repeat a tool call you already made.

Repeat Tool Nudge（重复工具调用警告）

扫描消息历史中最近 6 次工具调用，当同一工具名出现 ≥ 3 次时，追加提示。严重循环（≥ 5 次）时使用 CRITICAL 级别：

CRITICAL: You have called 'query_ip' 5 times.
This is a loop. STOP calling this tool.
Use the results you already have and provide your final answer now.

Nudge 注入的设计灵感来自 Rapid-MLX PR #162（虽未合并），核心思想是：在模型看到上下文之前，通过隐式消息改变其行为倾向。这不是修改模型权重，而是利用模型的指令遵循能力来对抗路由坍缩。

8.4 增量摘要：避免压缩本身成为瓶颈

增量摘要只摘要新增 span，合并到持久化摘要，避免重复摘要整个历史。

关键细节：旧摘要截断到 1500 chars，避免增量 prompt 过长导致 compact 后端超时。

修复后 15 轮端到端测试：

9. L6 路由层：高风险任务不要交给本地 MoE

9.1 高风险条件

任意满足一个就提高风险等级：

9.2 上下文长度风险边界

9.3 Compact 熔断器

三态熔断器（CLOSED / OPEN / HALF-OPEN），连续失败后打开熔断，指数退避恢复（base=60s, max=600s, factor=2.0）。熔断打开时，不再尝试压缩，直接将请求分流到远端。

9.4 Prefix 路由亲和 + Block-Aware 调度

在多实例部署中，我们引入了 Prefix-Aware Routing 和 Block-Aware Scheduling，确保同一会话的请求命中同一个后端实例，复用 KV Cache，避免重复 prefill 带来的额外上下文膨胀风险。

三层分层采样 Prefix Key：

• • Layer 1: tools 定义（不变部分，2048 字符预算）
• • Layer 2: system prompt（不变部分，512 字符预算）
• • Layer 3: 第一条 user 消息（近似不变，256 字符预算）

跳过 tool 结果消息（每轮变化大，影响亲和性），使用 blake2b hash 生成 32 字符 key。

实测结果：TTFT 增长曲线从指数级降为近常数级。20 轮场景中，末轮 TTFT 仅 1.80s，而无优化的基线在第 8 轮就已达 1.86s 且继续恶化。

9.4.1 核心收益：TTFT 曲线从指数增长变为近常数

这是两项优化最根本的价值。对比三个阶段的 TTFT 演进：

阶段 0：无优化基线（rapid-mlx rc.3，8 轮多轮对话）

问题：每轮对话重新 prefill 全部历史，context 越长 TTFT 越高，到第 6 轮已超过 10s。

阶段 1：加入 Prefix Routing + Block-Aware（20 轮测试）

平均 TTFT：1.461s → 1.324s（-9.4%）

关键变化：TTFT 曲线从指数增长变为近常数。第 20 轮的 TTFT（1.80s）仅比第 1 轮高 0.8s，而无优化时第 8 轮就已经 1.86s。

阶段 2：三层路由 v6（加入 prefix seeding balance + overload guard 调优）

9.4.2 分项收益拆解

9.4.3 定性收益

9.4.4 综合收益评分

第四部分：进化 — 从 vllm-mlx 到 Rapid-MLX

10. 为什么换后端是根治的一部分

前面九节描述的六层防御体系，本质上都是在代理层做防御——模型本身的问题没有解决，我们只是在外面包了一层又一层的保护壳。

但有一个问题代理层永远解决不了：vllm-mlx 的流式工具调用 Bug。

在 vllm-mlx 中，流式模式下工具调用以原始 XML 文本输出到 delta.content，而非结构化的 delta.tool_calls。我们通过 FORCE_TOOL_NON_STREAM workaround 绕过，但这意味着：

• • 工具调用必须等待完整响应，首 token 延迟增加
• • 代理层需要复杂的 _gen_nonstream_as_sse() 逻辑
• • 工具结果后回复仍有部分场景问题

这个 Bug 直接影响了 L3（工具调用循环检测）的效果——因为 delta.tool_calls 格式不正确，检测器无法可靠提取工具名。

11. Rapid-MLX 迁移

Rapid-MLX 是 vllm-mlx 的 fork 增强版，包命名空间完全相同，迁移本质是「升级」而非「替换」。

迁移后的关键收益：

1. 1. FORCE_TOOL_NON_STREAM workaround 完全移除：流式工具调用原生支持，delta.tool_calls 结构正确输出
2. 2. L3 检测器可靠性大幅提升：_extract_sse_tool_call_names() 可以从结构化的 delta.tool_calls 中可靠提取工具名
3. 3. 代理层简化：移除 _gen_nonstream_as_sse()、_strip_reasoning_sse_payloads（条件跳过）、_rewrite_chat_completion_tool_calls（条件跳过）等复杂 workaround
4. 4. 新增防御参数：--pin-system-prompt（系统 prompt 固定在 prefix cache 防止淘汰）、--kv-cache-turboquant（3-4bit V-cache 压缩）、--suffix-decoding（统计投机解码，工具调用场景 3-5x 加速）

端到端验证结果（24/24 PASS）：

• • 流式工具调用：delta.tool_calls 结构正确
• • 多轮工具调用：25 轮连续调用无乱码
• • Hermes Agent 集成：15/15 PASS
• • 性能：Text/MLLM 池 ~49-51 tok/s，TTFT ~0.26-0.29s

12. 从「换 Dense」到「让 MoE 可用」

在原始事故复盘中，我们的最终方案是换 Dense 模型：

Qwen3.6-35B-A3B-8bit MoE → Qwen3.6-27B-4bit Dense

这在当时是正确的决策——Dense 模型的稳定性确实更好。

但 6 个月的持续治理让我们重新审视了这个结论。现在我们有了六层防御体系 + Rapid-MLX 后端，MoE 在很多场景下已经可以安全使用。关键不是「MoE 能不能用」，而是「什么场景下能用，什么场景下不能用」。

更新后的决策树：

┌─ 任务是短链单轮吗？
│  ├─ 是 → 走本地 MoE。享受 3B 激活带来的吞吐优势。
│  └─ 否 → 继续
│
├─ 是否包含多轮工具调用？
│  ├─ 是 → MoE 可用，但必须满足：
│  │       L1-L6 全部开启 + ctx < 16K + tool_depth < 3
│  │       超出范围：优先 Dense 或远端云模型
│  └─ 否 → 继续
│
├─ 输入是否超过 16K？
│  ├─ 否 → MoE 可以尝试，但要开启 repetition penalty 和监控
│  └─ 是 → 继续
│
└─ 是否超过 25K 或 tool_depth >= 3？
   ├─ 是 → 不建议本地 MoE，走 Dense / 云端强模型
   └─ 否 → MoE + N-gram 早停 + 上下文压缩 + Nudge 注入

最终原则：

• • 短、快、可重试：MoE
• • 长、复杂、不能错：Dense 或云
• • 但有了六层防御，MoE 的安全边界已经大幅扩展

第五部分：工程 Checklist 与最佳实践

13. 立即止血

14. 中期治理

15. 长期架构

16. 压缩管线设计原则

结语

MoE 给了我们一个很诱人的承诺：

用 3B 级别的激活成本，获得 35B 级别的模型容量。

这是真的。但这笔交易还有一个隐藏条款：

它把推理可靠性的不确定性，转嫁给了系统工程和运维。

6 个月前我们的结论是：

不要执着于驯服一个本来就不该处理这种任务的模型。

6 个月后的今天，我们的结论更新为：

MoE 可以被驯服，但需要系统性的纵深防御，而不是单点修补。

每一层防御都有自己的盲区：

• • 采样层看不到工具调用
• • N-gram 检测器看不到语义重复
• • 压缩管线可能永远不触发
• • Lingua 压缩反而可能诱发循环

只有六层防御协同工作，才能覆盖所有穿透路径。而 Rapid-MLX 的迁移，让代理层的防御代码（特别是工具调用循环检测）真正可靠地工作。

最后一句话：

MoE 很强，它不是所有场景的正确答案，但有了正确的工程防御，它可以成为更多场景的可行答案。

附录 A：实战关键数据

附录 B：环境变量配置参考

# L1 采样层
export DEFAULT_REPETITION_PENALTY=1.12
export ANTI_REPETITION_DEFAULTS_ENABLED=1
export ANTI_REPETITION_FREQUENCY_PENALTY=0.3
export ANTI_REPETITION_PRESENCE_PENALTY=1.5

# L2-L4 推理层
export NGRAM_EARLY_STOP_ENABLED=1
export NGRAM_EARLY_STOP_MIN_PATTERN=3
export NGRAM_EARLY_STOP_MAX_PATTERN=24
export NGRAM_EARLY_STOP_MIN_COUNT=16
export TOOL_CALL_LOOP_ENABLED=1
export TOOL_CALL_LOOP_MAX_SAME_NAME=5

# L5 上下文层
export OAI_COMPACT_LAYER2_ENABLED=1
export OAI_COMPACT_TRIGGER_TOKENS=14000
export OAI_COMPACT_ESTIMATE_OVERHEAD_MULTIPLIER=1.45
export OAI_COMPACT_TOOL_CHAIN_MAX_EXTENSION_RATIO=0.35
export OAI_COMPACT_LAYER2_TOTAL_BUDGET_SECONDS=45
export OAI_COMPACT_INCREMENTAL_PRIOR_MAX_CHARS=1500
export OAI_L3_TRIM_MODE=structured
export TOOL_CONTINUATION_NUDGE_ENABLED=1
export TOOL_REPEAT_NUDGE_ENABLED=1
export TOOL_REPEAT_NUDGE_WINDOW=6

# L6 路由层
export AUTO_ROUTE_LOCAL_MAX_INPUT_TOKENS=30000
export COMPACT_CIRCUIT_BREAKER_ENABLED=1
export COMPACT_CIRCUIT_BREAKER_MAX_FAILURES=3

附录 C：参考资料

• • Holtzman et al., 2019, The Curious Case of Neural Text Degeneration
• • Xiao et al., 2023, Attention Sink in Large Language Models
• • vLLM Issue #31856, MiniMax-M2.1-NVFP4 repetition loop
• • vLLM PR #35451, N-gram early stop
• • RepetitionCurse, arXiv:2512.23995
• • Sigma-MoE-Tiny Technical Report, arXiv:2512.16248
• • Qwen3 / Qwen3-VL A3B 相关 HuggingFace issues
• • OpenHands — Observation Masking + 滚动摘要
• • Factory.ai — 增量摘要
• • ACON (Microsoft) — 压缩 Guideline
• • Claude Code — 5 层递进压缩
• • OpenAI Agents SDK — ToolOutputTrimmer
• • Rapid-MLX — vllm-mlx fork 增强版