在Mac Studio 96GB上运行Qwen3.5-122B：修复了3个使长上下文推理变得可用的bug

大家好，我最近在我的M3 Ultra Mac Studio上将DS4 Flash换成了Qwen3.5-122B来进行长上下文的智能体编码。虽然模型更合适了，但我遇到了一个障碍：即使上下文是“热的”，后续消息也要花3-5分钟才开始生成（冷填充）。结果发现问题不在于模型，而在于我的服务栈（rapid-mlx的qMLX分支）中的三个特定bug： - **提示不稳定性**：系统提示中的一个唯一消息ID破坏了字节精确的KV缓存匹配，导致每次交互都要完全重新计算。 - **中断路径**：当生成被中断时，流式回复没有被持久化，导致历史记录出现分歧。 - **检查点污染**：一个后台写入器创建了无法匹配的检查点，挤占了有效的检查点，触发了激进的驱逐。 修复这些问题后，预填充时间从几分钟降到了亚秒级（例如，53k tokens被缓存，仅预填充了33个）。我决定fork而不是提交PR，因为这些混合注意力优化非常特定于Qwen，对于通用的上游栈来说可能难以接受。预计qMLX会继续分化，以针对这种架构进行优化。我已经开源了这个分支和一个基准测试脚本（bench_qmlx.py），它将预填充和解码指标分开。非常想知道是否有人也遇到了类似的问题，关于混合注意力缓存，或者有进一步优化的想法。 完整分析：https://mrzk.io/posts/qmlx-maximising-ai-psychosis-minmaxing-mac-studio/ GitHub (qMLX)：https://github.com/marzukia/qMLX 编辑：我也应该清楚地说，这种恢复消除了冷预填充的悬崖，但并没有让深层上下文交互变得免费。下面是我的一次深层上下文会话的示例： Prompt tokens Restored from SSD Delta prefilled Time to first token 168,440 168,373 67 2.6s 167,859 167,727 132 2.6s 163,140 162,764 376 4.4s 168,332 167,912 420 4.8s 167,478 166,667 811 8.2s 164,400 163,206 1,194 11.6s 162,271 160,489 1,782 17.1s