部署DeepSeek-V4：為何百萬Token上下文是推理系統的問題
DeepSeek-V4通過混合注意力設計（CSA、HCA、SWA）壓縮KV緩存，將百萬Token上下文從模型挑戰轉變為推理系統挑戰。Together AI在NVIDIA HGX B200上的早期部署經驗展示了緩存策略、前綴緩存和端點配置對長上下文工作負載性能的關鍵影響。
文章情報
要點
- DeepSeek-V4的壓縮稀疏注意力（CSA）和高度壓縮注意力（HCA）減小了KV緩存大小，但推理引擎需要管理多種緩存佈局。
- 滑動窗口注意力（SWA）在長上下文時成為性能瓶頸，需謹慎選擇存儲策略。
- 前綴緩存變成跨越CSA、HCA和SWA的存儲策略決策。
- V4的性能依賴於工作負載：長上下文解碼受益明顯，短上下文預填則依賴內核成熟度。
為甚麼重要
這條新聞值得關注，因為DeepSeek-V4的壓縮稀疏注意力（CSA）和高度壓縮注意力（HCA）減小了KV緩存大小，但推理引擎需要管理多種緩存佈局。
技術影響
可能影響模型選型、推理成本、產品能力和評測基準。
DeepSeek-V4的百萬Token上下文窗口並非僅靠模型架構實現，其關鍵在於將存儲和計算壓力轉移到了推理系統層面。該模型採用混合注意力機制，包括壓縮稀疏注意力（CSA）、高度壓縮注意力（HCA）和滑動窗口注意力（SWA），大幅壓縮了鍵值（KV）緩存。然而，這些壓縮操作的有效性完全取決於推理引擎能否高效管理生成的多種緩存佈局。
在NVIDIA HGX B200硬件上的早期部署顯示，V4的KV緩存容量受限於對SWA狀態的處理。全量存儲SWA會導致每Token緩存佔用高達3.8KB，超過V3的3.4KB。通過優化緩存策略——僅保留最可能被複用的SWA狀態——單個節點的KV緩存容量從約120萬Token提升至370萬Token。這表明，V4的架構為長上下文效率創造了機會，但實際容量取決於引擎的存儲、重計算和逐出策略。
V4需要三種不同的緩存佈局：CSA以步長4壓縮上下文，每個條目覆蓋8個Token的詞寬，實現細粒度稀疏讀取；HCA以步長128壓縮，將百萬Token縮減至約8000個條目，支持全局密集註意力；SWA保持128Token的精確局部上下文。推理引擎必須同時管理這些生命週期和讀取模式不同的緩存對象。
前綴緩存在V4中變得更為複雜。共享前綴包含CSA、HCA和SWA狀態。DeepSeek論文提出了三種SWA策略：全量存儲、週期性檢查點存儲和命中時重計算。當前部署採用全量存儲以保持簡單，但這也意味着緩存策略在上下文長度和併發度增加時更為關鍵。
V4的性能呈現明顯的工況依賴性。長上下文解碼密集型負載因KV緩存壓縮而顯著受益；短上下文預填密集型負載則受限於內核成熟度，因為CSA的top-k選擇、HCA壓縮讀取和SWA都偏離了成熟的密集註意力內核路徑。開發者應根據實際使用場景進行基準測試。
同一套權重需要不同的服務配置：長上下文代理適合大張量並行和批量處理；短聊天需優化預填延遲；強化學習 rollout 關注每條長軌跡的成本。Together AI正在評估不同端點配置，以匹配各類工作負載。
在遷移至V4之前，應針對上下文長度範圍、前綴複用率、緩存策略和端點配置四項指標進行基準測試。對於長上下文任務，衡量緩存命中率、解碼吞吐量和任務完成成本；對於短聊天，比較實際上下文長度下的延遲；對於共享前綴負載，測試SWA全量存儲與命中時重計算的權衡；對於強化學習，計算每rollout的吞吐量。