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