LLM 推論瓶頸

核心結論

來源主張 LLM推論 常見瓶頸集中在 decode phase，主要不是單純 compute 不足，而是：

1. 記憶體頻寬：反覆讀取權重與 KV Cache
2. KV Cache 容量：上下文越長，VRAM 占用越大
3. 自迴歸順序性：一次生成一個 token，無法完全平行化
4. Serving 資源：batching、網路延遲、CPU-GPU transfer、本地 VRAM 容量

Prefill vs Decode

• Prefill：處理 prompt，可較好利用平行計算。
• Decode：逐 token 生成，batch/parallelism 較受限，容易受 memory bandwidth 與 KV Cache 限制。

與 AI 記憶體投資框架的連結

這個瓶頸解釋為什麼 AI 推論需求會拉動記憶體階層：

• HBM：支撐 hot path 的高頻寬。
• KV Cache：造成長上下文與多使用者 serving 的容量壓力。
• CXL Memory / LPDDR：可能提供容量延伸或 offload。
• 高階 SSD / NAND Flash：更適合冷資料、權重載入與較低頻資料層。
• HBF：若能在 latency、耐久性與標準化上成立，可能補充推論暖資料層。
• Processing-In-Memory：理論上可降低資料搬移，但商業化仍待驗證。

常見緩解手段

來源提到：

• quantization：降低權重與 KV Cache 的記憶體占用與頻寬需求。
• continuous batching：提高 serving throughput。
• FlashAttention：改善 attention memory access pattern。

未來可補充：PagedAttention、speculative decoding、KV cache quantization、prefix caching、MoE routing 與 cache offload。

主要張力

• 推論瓶頸不是永遠固定在同一處；會依模型、上下文長度、batch size、硬體與 serving stack 改變。
• 「HBM 需求」與「低成本容量層需求」可能同時存在：hot decode path 需要高頻寬，長上下文與多租戶 serving 需要容量。
• 推論成本下降可能刺激更多 token demand，連接到 Token Economics Flywheel。

系統性優化堆疊

新來源補充 LLM推論瓶頸 的解法：memory bandwidth 以硬體升級與量化處理，KV Cache 以 PagedAttention、offloading、MQA/GQA 與 KV cache quantization 處理，自迴歸順序性以 推測解碼、MTP/EAGLE 與 continuous batching 處理。所有公司與 benchmark 數字均待核驗。

未來解法的瓶頸對應

新來源補充未來 roadmap：memory bandwidth 以 HBM4/SRAM/LPU/TPU 解，KV Cache 以分層 context storage、TurboQuant、disaggregation 解，自迴歸順序性以 speculative decoding/DFlash/continuous batching 解。