修复三个Bug，Qwen3.5-122B成Mac Studio日常主力

背景

在本地运行大型语言模型的浪潮中，Mac Studio 凭借统一内存架构成为发烧友的利器。作者是一名软硬件皆钻的极客，趁着育儿假入手了一台 M3 Mac Studio Ultra（96GB 统一内存），目标是单机上跑一个前沿模型，保持“温热”，实现能真正理解上下文的对话式 AI。起初他尝试了 antirez/ds4 栈与 DS4 Flash 模型，但发现长上下文场景下的预填充延迟无法忍受——50k token 后的简单跟进需要 3–5 分钟才出现第一个 token，这根本不是聊天机器人，而是批处理作业。于是作者转向了 Qwen3.5-122B，并基于 rapid-mlx 分支开发了自己的服务栈 qMLX（已在 GitHub 开源）。然而，新模型并非开箱即用，而是隐藏着三个与模型本身无关的 bug，作者花了三周调试才让缓存真正工作起来。

核心内容

作者从 DS4 Flash 切换到 Qwen3.5-122B，主要是硬件匹配和延迟决策。Qwen3.5-122B 是 MoE 架构，活跃参数约 10B，恰好匹配 M3 Ultra 的带宽；低比特量化后可在 96GB 内存中留出空间给 SSD 支持的 KV 缓存，实现长上下文保留。但切换后，模型虽然能跑通，每次对话却都要从头重新处理整个上下文——130k token 的上下文需要数分钟才能吐出第一个词。

问题根源在于混合注意力架构（GatedDeltaNet SSM层 + 密集注意力）。SSM 层的循环状态无法回滚或裁剪到先前位置，导致内存中的前缀缓存每次都会错过（实测内存命中 0 次，磁盘命中 109 次）。唯一保持“温热”的手段是磁盘缓存：将注意力 KV 检查点到 SSD，下一轮恢复。但磁盘缓存本身不断在三个层面失效。

Bug 一：系统提示中的时间戳

KV 复用要求字节精确匹配。代理框架每轮对话都会在系统提示中写入一个唯一的消息 ID，这个 ID 靠近 130k token 提示的顶部，导致提示文本永远无法保持字节稳定。即使只有一个字符不同，缓存匹配也会在第一处差异处失败，之后全部需要重算。修复很简单：删除这行。消息 ID 是装饰性的，没有代码读取它；代理已经通过每轮的用户消息获得了 ID。任何每轮独有的内容都不应放在需缓存的提示前缀里，而应放在会变化的用户消息部分。

Bug 二：被中断的回复从未保存

当用户在前一条回复仍在流式输出时就发送新消息，代理会中断生成。正确的中断行为是跳出循环，但作者的服务栈在中断路径上没有保存已经流式输出的 token。推理服务器已经将这些 token 解码进了 KV 缓存，但对话历史中缺少了助手的那一轮回复。导致后续匹配时历史不一致，缓存失效，需要从头填充。修复：在中断路径上先持久化已流式的回复，再 break。这个修复与代码中已为网络断开做的恢复逻辑一致。通用规则：只要生成的 token 能到达服务器缓存，该轮生成就必须在所有退出路径（包括错误和中断）上提交到历史。

Bug 三：检查点存储中的“毒数据”

两个写入者操作检查点存储。一个是正常写入者：以提示哈希为键，写入一个可恢复的检查点。另一个是后台钩子：每生成 256 个 token 就写一个完整的检查点，但没有附加任何 token 键——因此永远无法被匹配或恢复，成为死数据。这些死数据占用了磁盘上限。一个长工具调用轮次会生成很多 token，触发大量垃圾写入，导致存储超过上限。清理策略是删除最旧的数据，于是好的检查点与垃圾一起被驱逐。修复：优先驱逐不可匹配的检查点，并在恢复模式开启时完全关闭后台钩子。这样好的检查点得以存活，下一轮可以正常恢复，冷填充停止。

修复后，同一段对话从每轮冷填充 30k token 变成缓存命中，子秒级响应。日志显示：uid=58 到 62 的对话中，缓存命中 token 数从 53267 增长到 55996，而预填充（新消息）仅数十到数千 token。缓存不再仅仅是辅助，它改变了使用体验——让 Qwen3.5-122B 从“批处理作业”变成了真正的日常驱动对话模型。

关键要点

• 模型选择：DS4 Flash 并非不好，但对作者的长上下文编程助手场景，预填充延迟过高；Qwen3.5-122B 的 MoE 架构（活跃参数 ~10B）正好匹配 M3 Ultra 的带宽和 96GB 内存，且支持 SSD 备份的 KV 缓存。
• 混合注意力架构的缓存挑战：GatedDeltaNet SSM 层的循环状态无法回退，导致内存前缀缓存彻底失效，必须依赖磁盘检查点，但也放大了缓存一致性的脆弱性。
• Bug 一：系统提示中的动态内容：任何每轮都变化的字符串（如消息 ID）放在缓存前缀开头，都会破坏字节精确匹配，导致整轮从头计算。修复：删除无意义的 ID，将唯一元素放在变化的用户消息部分。
• Bug 二：中断路径丢失回复：用户触发中断时，已流式输出的 token 未写入历史，导致后续历史不匹配。修复：在所有退出路径（包括中断）都持久化已生成的 tokens。
• Bug 三：后台钩子产生的不可匹配检查点：每 256 token 写一次没有键的检查点，不仅无复用价值，还占用磁盘配额，驱逐时连带好的检查点一起删除。修复：优先驱逐不可匹配的检查点，并在恢复模式下禁用垃圾写入。
• 最终效果：同一对话从每轮冷填充数万 token（等待数分钟）变为缓存命中，预填充仅几十至几千 token，实现子秒级响应，使本地大模型真正可日常使用。

意义与影响

1. 为本地大模型部署提供工程范式：作者不仅展示了特定硬件（Mac Studio Ultra）与特定模型（Qwen3.5-122B）的适配，更揭示了在混合注意力架构下实现高效缓存复用的普遍工程陷阱。三个 bug 分别涉及提示设计、中断处理和存储管理，对任何试图在本地运行长上下文大模型的开发者都有直接参考价值。

2. 推动“可日常使用的本地 AI”：Mac Studio 的统一内存让大模型推理不再依赖昂贵 GPU 集群，但之前的长延迟让“对话”名存实亡。修复后，130k token 对话的响应降至亚秒级，让本地模型真正具备与在线服务（如 ChatGPT）竞争的使用体验。这对隐私敏感、需要离线工作的用户（如作者在育儿假期间）意义重大。

3. 开源栈迭代的典范：作者基于 rapid-mlx 分支创建了 qMLX（GitHub 开源），专门针对混合注意力优化。这种“先fork再修补”的模式降低了入门门槛，其他用户可以直接复现或改进作者的缓存方案，加速社区在 Apple Silicon 上的本地推理生态。

4. 启示：系统级 bug 比模型本身更致命：作者强调，模型交换是一个“速度与适配”的选择，而让新模型真正可用的是修复与模型无关的服务栈 bug。这说明在本地大模型部署中，推理框架、缓存策略和代理架构的健壮性往往比模型代数更重要。很多前沿模型可能因为工程实现缺陷而无法落地。

5. 对硬件/内存管理的启发：96GB 统一内存虽大，但在 122B 模型、SSD 备份缓存、工具调用轮次下仍然紧张。作者对检查点存储的清理策略（优先驱逐不可匹配项）是一种轻量级但有效的资源管理思路，可推广到其他受内存或磁盘配额限制的推理场景。