家用硬體環境與原始瓶頸

該使用者使用的硬體配置包括 AMD RX 9070 XT (16 GB VRAM)、Ryzen 5800X3D CPU、64 GB DDR4 RAM 以及 PCIe 3.0 NVMe SSD。在此環境下，透過 Strata 專案離線執行 DeepSeek V4.1 Flash 模型，支援 1M context，並使用 IST-DAS 1.75 bpw 量化格式。

根據實驗室報告，此量化版本達到完整模型任務平均表現的 98.7%。生成速度約為每秒 7 個 token，對於一般對話而言尚可接受。然而，主要問題在於提示詞讀取階段：每次啟動新的 OpenCode 代理會話時，系統需重新讀取約 37K token 的系統提示詞與工具定義，導致首個 token 輸出前需等待約 100 秒。

技術修改一：KV Splice 避免重複讀取

代理程式通常會將工作目錄、日期、專案設定檔與隨機 ID 的技能路徑等動態資訊嵌入系統提示詞中，導致前綴快取在每次新會話時失效。為解決此問題，修改後的引擎會將新提示詞與已儲存的對話進行對齊，從快取狀態中移除過期的行，並僅讀取變更的行以及使用者的訊息。

具體實作上，系統會移動快取的列、旋轉視窗環形緩衝區，並記錄 RoPE 間隙。由於變更的行是以整行單位移動，模型不會看到破碎的片段。此方法旨在避免重複處理已讀取過的內容，從而縮短啟動時間。

技術修改二：Resident-only Routing 優化記憶體使用

即使是很短的提示詞，也可能觸及幾乎每一層的每一個專家模型參數。在原始實作中，讀取提示詞時會從 SSD 串流傳輸大部分模型參數，例如處理一個 1.2K token 的提示詞需從 SSD 讀取約 58 GB 數據。

修改後的機制僅在讀取提示詞階段生效，此時 token 僅從已駐留在 VRAM 或 RAM 中的專家模型中進行選擇與路由。而在生成階段，路由邏輯則恢復正常運作。此舉旨在讓家用 DRAM 發揮更大效用，減少對 SSD 頻寬的瓶頸依賴。

測試結果與限制條件

該修改目前僅支援 HIP (gfx1201) 架構，作者尚未建置或測試 CUDA、SYCL 或 Metal 版本。KV Splice 技術被描述為近似方法，因為在切割點之後的 token 是在包含已移除文本的上下文中計算的。雖然作者表示對於簡短的指導性行未見明顯影響，但缺乏正式的評估數據來驗證其對所有情境的影響。

Resident-only Routing 會略微改變回答內容，因為在讀取提示詞時會使用替代的專家模型。作者的編碼測試套件結果未變（兩次測試均為 12/13），但這僅基於單次運行的樣本。這兩項功能預設啟用，可透過環境變數 STRATA_DS4_REORDER=0 和 STRATA_DS4_PROMPT_RESIDENT=0 關閉。

此外，該分支還包含一個修復 GPU 頁面錯誤的一行程式碼修正（Issue #4912），該錯誤在處理 37K token 提示詞時發生。若使用者使用 OpenCode，需在模型設定中加入 "interleaved": { "field": "reasoning_content" }，否則 OpenCode 會丟棄早期的推理內容，導致快取更容易失效。

建置與上游貢獻

修改後的程式碼位於 GitHub 分支 dsv41-kv-splice。作者提供了 HIP 架構的建置範例指令，包括使用 CMake 和 Ninja 進行編譯，並指定 gfx1201 架構。相關技術細節已提交至上游 Issue #4921 (KV Splice) 與 #4936 (Resident Routing)。

作者呼籲其他硬體使用者，特別是 CUDA 使用者，提供測試數據以協助將這些修改合併到主線分支中。該專案旨在證明家用 DRAM 在適當的軟體優化下，能有效輔助大型語言模型的本地執行，回應了關於家用記憶體資源閒置的觀點。