為什麼 context window 會卡在 1M 很多年? SemiAnalysis 談 40 年一遇的記憶體短缺

原始來源與檔名：2026-08-24T161848+0800-為什麼 context window 會卡在 1M 很多年? SemiAnalysis 談 40 年一遇的記憶體短缺.md

SOURCE | 資訊源評估

• 來源：Latent Space Podcast / SemiAnalysis (Doug O’Laughlin)
• 作者：ihower / 博客文章
• 可信度：高。基於深耕半導體與 AI 產業分析的 SemiAnalysis 觀點。

NAPKIN | 餐巾紙

• 核心論點：LLM 的 Context Window 短期內將卡在 1M 左右，這是物理與記憶體供應鏈的限制，而非演算法限制。
• 關鍵因素：DRAM 微縮停滯、擴產停滯、HBM 生產排擠效應、伺服器 DRAM 被 KV cache 需求耗盡。
• 應對策略：發展 Context Engineering（如 RAG、記憶壓縮、拆分 Agent），因為 Token 容量將成為昂貴且稀缺的配給品。

ROUND 1: SKELETON | 骨架掃描

• 40 年一遇的記憶體短缺之四大成因
• 從 2 月到 7 月的市場惡化情況
• Nvidia 對決 TPU：勝負取決於 HBM 供應鏈掌握度
• Context Window 卡在 1M 的物理與經濟限制
• Context Rationing (配給制) 與硬體/演算法解法
• 小結：Context 的價值在於密度，需依賴 Context Engineering

ROUND 2: DISSECTION | 血肉解剖

• DRAM 成本下降停滯：記憶單元縮小至極限，電荷僅存幾萬顆電子，無法再隨製程進步降價。
• HBM 排擠效應：HBM 每產出一個位元，等同消耗 3-4 個位元的 DRAM 產能。
• KV Cache：以 70B 模型（80層, 8 KV head, head_dim 128, FP16）為例：
  • 1M token 的 KV cache 約需 330 GB（需 3 張 H200）
  • 100M token 的 KV cache 高達 32 TB（需超過 230 張 H200）
• Nvidia 的供應鏈優勢：TPU v7 在 TCO 上優異，但在缺貨時代，Nvidia 高層親自鎖定 HBM 產能，確保下一代 Rubin 平台（配 HBM4）的記憶體優勢。

ROUND 3: SOUL | 靈魂提取

• Context 容量受限於物理與經濟成本，而非單純的演算法問題。即使演算法能壓縮，也改變不了 KV Cache 隨 Context 長度「線性成長」的本質。
• 硬體限制倒逼軟體工程進化：既然硬體無法提供無限容量，軟體端必須將 Token 視為稀缺資源，轉向優化資訊「密度」（Context Engineering）。

DEEP READ | 精讀指引

• 適合：AI 架構師、硬體工程師、LLM 應用開發者（特別是 Agent 架構設計者）。
• 重點關注：KV cache 的計算方式，以及 Context Engineering 的四個方向（寫入、選擇、壓縮、隔離）。

為什麼 context window 會卡在 1M 很多年? SemiAnalysis 談 40 年一遇的記憶體短缺 (Architectural Deep Dive)

前言/背景

本文基於 Latent Space 播客中 SemiAnalysis 的 Doug O’Laughlin 的訪談，探討為何大語言模型（LLM）的 Context Window 在未來幾年內難以突破 1M 量級。核心原因在於全球面臨 40 年一遇的記憶體短缺，這不僅是供應鏈問題，更是 KV Cache 帶來的物理與經濟限制。這對於依賴長 Context 的 AI 應用與 Agent 架構有著深遠影響。

章節詳細總結

40 年一遇的記憶體短缺成因

記憶體短缺由四個關鍵因素疊加造成：

1. DRAM 微縮停滯：過去 50 年依賴製程進步降低每 GB 成本的規律失效。DRAM 記憶單元（Cell）已縮至極限（僅存幾萬顆電子），無法再藉由微縮降價。
2. 擴產停滯：上一輪不景氣導致記憶體廠大砍資本支出，現今僅存 3-4 家供應商，無人在低點擴產。
3. HBM 的產能乘數效應 (交換比)：AI 加速器所需的 HBM 透過垂直堆疊封裝，良率耗損大。每製造 1 位元的 HBM，實質上會消耗 3-4 位元的標準 DRAM 產能。
4. KV Cache 卸載耗盡 DDR5：推論系統為節省昂貴的 HBM，會將暫時未用的 KV Cache 卸載 (Offload) 至伺服器 DRAM，導致中階記憶體亦被搶購一空。

Nvidia 與 TPU 的加速器之爭：決戰供應鏈

• TPU 具備 TCO 優勢：在不缺貨的理想狀態下，TPU v7 (Ironwood) 是目前總持有成本 (TCO) 最優的加速器。
• 勝負在於 HBM 掌控力：在全面缺貨時代，比拚的不是晶片設計，而是供應鏈綁定。Nvidia 執行長親自固樁三星與 SK 海力士，確保下一代 Rubin 平台 (搭配 HBM4) 能取得足夠記憶體。
• 記憶體決定 Context Window：Rubin 世代將藉由龐大記憶體頻寬與容量，確立其在長 Context 時代的霸主地位。

Context Window 卡在 1M 的物理限制與 KV Cache 計算

這是一個軟體端無法輕易克服的物理限制，核心在於 KV Cache。模型在生成時，每個 Token 的 Key 和 Value 必須駐留在 GPU HBM 中。

• KV Cache 的線性成長特性： 以 Llama 3 70B 等級 (80 層, 8 KV head, head_dim 128, FP16) 估算，每個 Token 的 KV Cache 約需 0.33 MB：

  [ 128K Tokens ] ---> KV Cache ~ 43 GB   (1 張 H200 放得下)
  [ 1M Tokens ]   ---> KV Cache ~ 330 GB  (需 3 張 H200 分攤)
  [ 100M Tokens ] ---> KV Cache ~ 32 TB   (需 >230 張 H200 僅存對話)

• 頻寬瓶頸：生成新 Token 時，必須完整讀取整份 KV Cache。Context 越長，解碼 (Decode) 階段越慢且昂貴。
• 演算法的局限：GQA、MLA 等技術僅能改變常數倍，無法改變 KV Cache 隨長度「線性成長」的物理本質。

Context Rationing (配給制) 與 Context Engineering

• Context 成為配給品：未來計價模式可能走向 Context Rationing，1M Context 視為高價奢侈品。
• 開發者的應對策略 (Context Engineering)： 與其期待無限大的 Context Window，不如優化 1M 容量內的「資訊密度」。
  1. 寫入 (Write)：將長期記憶或非必要資訊存於外部。
  2. 選擇 (Select)：依賴 RAG 與動態檢索，僅注入當下必要資訊。
  3. 壓縮 (Compress)：自動總結或修剪過長 Token。
  4. 隔離 (Isolate)：利用 Sub-Agent 架構，將支線任務拆分執行，主 Context 僅保留最終結果。

總結與結論

硬體發展的物理極限與供應鏈現狀已明確宣告：長 Context Window 是一項昂貴且稀缺的資源。在記憶體頻寬與容量未能產生跳躍式突破（如直接將記憶體堆疊於運算晶片上）之前，軟體架構必須轉向 Context Engineering。對於架構師而言，系統設計不應依賴將巨量文件一股腦塞給 LLM，而應構建具備精密記憶體管理、資料檢索與 Agent 協作機制的基礎設施。