LLM 推論瓶頸與 Decode 階段記憶體限制

摘要

這份使用者提供的技術筆記說明 LLM推論 的基本流程，並回答「推論常卡在哪裡」：主要瓶頸通常在 decode phase，而不是 prefill phase。來源指出：

• LLM 推論是訓練後的 forward pass，不更新權重。
• 生成流程包含 tokenization、embedding、Transformer layers、next-token decoding。
• 自迴歸生成一次只產生一個 token，因此難以完全平行化。
• decode 階段常受 記憶體頻寬瓶頸 與 KV Cache 成長限制。
• 長上下文會使 KV Cache 隨 token 數增加，占用 VRAM，可能導致 OOM。
• 常見緩解方式包括量化、continuous batching 與 FlashAttention。

可信度註記

此筆記是使用者提供的基礎技術說明，未附論文、benchmark 或系統文件 citation。其方向與主流 LLM serving 經驗相符，但以下細節仍應視為需依模型、硬體、batch size、context length 與 serving stack 核驗：

• decode phase 是否一定比 prefill phase 更主要瓶頸。
• memory bandwidth bound 與 compute bound 的相對程度。
• KV Cache 成長對 VRAM/OOM 的具體影響。
• FlashAttention 對 prefill/decode 的效果差異。
• continuous batching、quantization 等優化在不同 workload 下的收益。

消化後的 Wiki 更新

• 新增 LLM推論。
• 新增 KV Cache。
• 新增 記憶體頻寬瓶頸。
• 新增 LLM推論瓶頸。
• 新增 LLM推論為何常卡在decode階段。
• 更新 AI推論記憶體生產可擴展性、AI記憶體階層化、AI推論記憶體替代技術、HBM與HBF在LLM推論中的角色與競爭技術、HBM與HBF記憶體階層化、HBM、HBF、CXL Memory、LPDDR、高階 SSD、Processing-In-Memory、AI基礎設施五層堆疊、美股大市風險雷達。

待追問 / 待核驗

• 在不同模型大小、batch size 與 context length 下，decode vs prefill 的瓶頸如何轉換？
• 對長上下文、多使用者 serving，KV Cache 容量、頻寬與 eviction/offload 策略的主要 trade-off 是什麼？
• HBM、LPDDR、CXL、SSD、HBF、PIM 分別適合放在推論記憶體階層中的哪個位置？
• FlashAttention、PagedAttention、speculative decoding、KV cache quantization 是否也應納入未來 optimization map？

來源

• 原文保存於 raw/Clippings/2026-05-18-LLM推論瓶頸與Decode階段記憶體限制.md。