修复三个Bug，让Qwen3.5-122B在Mac Studio上成为日常驱动

作者在尝试将Qwen3.5-122B模型作为Mac Studio的日常驱动时，遇到了严重的性能问题。该模型虽能适配统一内存并流畅运行，但在长上下文对话中，每次后续消息都需要从头处理整个对话历史，导致130k令牌的上下文中，首个令牌的生成需要等待数分钟。经过三周的调试，作者发现了三个隐藏在缓存机制中的Bug，并逐一修复。

第一个Bug源于系统提示中的时间戳。每次对话轮次，代理框架都会在系统提示中插入唯一的消息ID，这导致提示内容发生变化，使得基于字节精确匹配的KV缓存失效。修复方法很简单：删除这一行装饰性的代码，因为该ID并未被实际使用。

第二个Bug出现在中断场景。当用户在模型仍在回复时发送新消息，代理会中断当前生成，但中断路径上未保存已流式输出的回复，导致历史记录缺失助手回复，进而引发缓存不匹配。修复方案是在中断路径上持久化已流式输出的回复。

第三个Bug与检查点存储相关。在长工具调用轮次中，一个后台钩子每生成256个令牌就写入一个无令牌键的检查点，这些无用的检查点堆积到磁盘限额，导致驱逐策略移除旧的且有用的检查点。修复后，驱逐策略优先删除无法匹配的检查点，并关闭了无用写入。

修复后，相同对话的缓存命中率大幅提升，预填充时间从88秒降至0.64秒。作者还强调了正确衡量性能的重要性：将预填充和解码阶段分开测量，避免使用“总令牌数/总时间”这种误导性指标。混合注意力架构中的DeltaNet层使得长上下文解码的衰减曲线平缓，而非急剧下降。文章最后指出，当前版本的内存余量检查器过于保守，可能需要进一步优化。

作者使用的硬件为M3 Ultra Mac Studio，配备96GB统一内存。测试显示，预填充吞吐量在短上下文中约为700 tok/s，随上下文增长至64k时降至386 tok/s；解码吞吐量从55 tok/s降至28 tok/s。由于75%的层为DeltaNet（状态大小恒定），解码速度仅缓慢下降，而非悬崖式跌落。混合设计在此并非妥协，而是保持长上下文解码可用的关键。

此外，作者对性能指标提出了诚实要求：拒绝将预填充和解码混为一谈的“吞吐量”谎言。认为缓存命中率应基于磁盘恢复率，因为内存缓存结构上已失效。同时，内存余量检查器过于保守，当前已默认关闭，需要重新设计以准确估计。

总之，通过修复这三个Bug，Qwen3.5-122B模型在Mac Studio上从需要等待数分钟的批处理任务，转变为亚秒级响应的日常驱动，为长上下文、强交互的本地AI应用铺平了道路。