作者在嘗試將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應用鋪平了道路。