LLM 記憶體瓶頸新解：TurboQuant、OSCAR 與 EpiCache 如何突破長文本處理極限？
編輯核心觀點
- ✦大型語言模型在處理長文本時，KV 快取記憶體佔用量常超越模型權重，成為限制效能的關鍵瓶頸。
- ✦TurboQuant 與 OSCAR 分別以「無需校準的通用性」與「針對部署優化的 INT2 量化」兩大路徑，解決量化過程中的離群值干擾問題。
- ✦Apple 推出的 EpiCache 則從對話歷史管理切入，透過語意分群與層級預算分配，與量化技術互補，進一步降低記憶體峰值。
長文本 LLM 的記憶體惡夢：KV 快取
大型語言模型（LLM）在處理長文本時，面臨著一個與模型權重無關的記憶體瓶頸。在解碼過程中，Transformer 架構必須為每一層的每一個 Token 快取鍵（Key）與值（Value）向量，以避免重複計算注意力。隨著序列長度與批次大小增加，這些 KV 快取會呈線性成長，在長文本與高併發場景下，其佔用空間甚至會超越模型本身的權重。
以 Llama-3.1-70B 為例，其 KV 快取在 BF16 精度下，每處理 128K 個 Token 就需消耗約 40GB 記憶體；若長度達到 1M，快取需求將超過 300GB，遠高於模型權重本身的 140GB。此外，解碼過程需頻繁從高頻寬記憶體（HBM）讀取快取，導致效能受限於記憶體頻寬。因此，壓縮 KV 快取成為降低成本與延遲最直接的手段。
三大技術路徑：TurboQuant、OSCAR 與 EpiCache
目前業界主要透過 Token 剔除、量化、低秩投影、合併與架構共享等方式進行優化。近期研究重點轉向超低位元量化，其中 Google 與紐約大學（NYU）合作的 TurboQuant 與 Together AI 的 OSCAR 代表了兩種截然不同的技術路徑，而 Apple 的 EpiCache 則解決了前兩者未觸及的對話管理問題。
TurboQuant：理論上的通用解方
TurboQuant 採取「數據無關（Data-oblivious）」策略，透過兩階段處理離群值：首先利用隨機旋轉使向量座標近似高斯分佈，再應用最佳化的標量量化；其次對殘差應用 1-bit 量化 Johnson–Lindenstrauss（QJL）轉換。其優勢在於無需校準，適用於任何模型，在 3-4 bit 的近無損區間表現優異。
OSCAR：生產環境的部署利器
OSCAR 則採取「注意力感知（Attention-aware）」路徑，透過離線校準計算旋轉矩陣。其核心優勢在於系統整合度高，不僅支援混合精度分頁快取（Mixed-precision paged cache），還提供完整的 Triton 核心與 SGLang 整合。在 Qwen3-8B 與 GLM-4.7-FP8 等模型上，OSCAR 展現了極高的吞吐量提升與記憶體壓縮比，是目前少數能在 INT2 精度下運作且不崩潰的方案。
EpiCache：對話歷史的智慧管理
Apple 開發的 EpiCache 則針對多輪對話場景，透過「情節分群（Episodic clustering）」將對話切分為語意連貫的區塊，並根據層級敏感度動態分配記憶體預算。由於它關注的是「保留哪些 Token」而非「如何儲存」，因此能與上述量化技術結合，進一步優化記憶體使用。
結論：互補而非競爭
這三項技術並非零和競爭。根據開發團隊與研究指出，將校準感知旋轉與最佳化標量量化結合，是未來極具潛力的發展方向。開發者應根據具體的位元預算、模型可攜性需求以及對話長度，選擇最合適的組合方案。
