短期記憶 (Short-Term Memory) · AI推論架構核心概念
3 秒看懂
一句話： 大型模型的”短期記憶”就是上下文視窗——它一次能”看到”多少 token，直接決定對話質量、推論成本和部署門檻。
關鍵詞： Context Window / KV Cache / 注意力記憶體
3 分鐘產業解釋
這是什麼？
在 Transformer 架構的 LLM 中，“短期記憶”並非生物學概念的直接對映，而是指模型在單次推論過程中能處理的 token 序列長度，即 Context Window（上下文視窗）。每次生成 token 時，模型需要”回顧”此前所有 token 的資訊，這部分資訊以 KV Cache（鍵值快取） 的形式駐留在 GPU 視訊記憶體中。
為什麼是產業核心變數？
| 維度 | 影響路徑 |
|---|---|
| 使用者體驗 | 上下文越長，多輪對話越連貫、長文件理解越完整 |
| 推論成本 | KV Cache 大小與序列長度線性相關，長上下文 = 高視訊記憶體 = 高單價 |
| 部署門檻 | 128K 級上下文對單卡視訊記憶體壓力巨大，倒逼分散式推論或量化壓縮 |
| 產品差異化 | 主流廠商的上下文長度已成為營銷核心指標 |
產業現狀（定性）
- 主流商用模型上下文已從早期的 4K 級向 128K–1M 級演進
- 開源模型跟進，但受視訊記憶體和訓練成本約束，實際可用長度常打折扣
- “支援 1M 上下文”≠“1M 上下文下質量不衰減”——長距離資訊檢索（Needle-in-a-Haystack）測試暴露顯著衰減
15 分鐘專家深入
核心矛盾：記憶容量 vs. 計算成本
標準 Transformer 的自注意力機制計算複雜度為 O(n²)，其中 n 為序列長度。這意味著：
- 序列長度翻倍 → 計算量約 4 倍
- KV Cache 視訊記憶體佔用與序列長度 線性增長（O(n)），但注意力計算本身是二次方
KV Cache 是什麼？
在自迴歸生成過程中，每生成一個新 token，需要計算該 token 與所有歷史 token 的注意力分數。為避免重複計算，歷史 token 的 Key 和 Value 向量被快取下來，這就是 KV Cache。
KV Cache 大小（粗略估算公式）：
≈ 2 × 層數 × 頭數 × 頭維度 × 序列長度 × 精度位元組數
示例：某 70B 級模型（假設約 80 層、64 頭、128 維、FP16）
- 1K tokens: ~2 GB 量級
- 128K tokens: ~335 GB 量級
*具體數值因模型架構而異，上述為數量級估算*長上下文的關鍵技術棧
| 技術層級 | 代表方案 | 核心思路 |
|---|---|---|
| 位置編碼 | RoPE（旋轉位置編碼）、ALiBi | 讓模型外推至訓練時未見的長度 |
| 注意力變體 | FlashAttention、Ring Attention、PagedAttention | 最佳化視訊記憶體訪問模式，降低峰值記憶體 |
| 稀疏注意力 | Sliding Window、Longformer 思路 | 只關注區域性+少量全域性 token，降複雜度 |
| 壓縮/解除安裝 | KV Cache 量化、CPU/磁碟 offload | 犧牲延遲換容量 |
| 架構替代 | Mamba（SSM）、RWKV、RetNet | 用線性複雜度替代二次方注意力 |
RoPE 長度外推
RoPE（Rotary Position Embedding）通過旋轉矩陣編碼相對位置。原始訓練長度外推時效能急劇衰減，後續出現多種改進：
- NTK-aware Scaling：調整旋轉基頻
- YaRN：結合 NTK 和注意力縮放
- Dynamic NTK：推論時根據實際長度動態調整
這些方法使得模型在遠超訓練長度時仍能保持一定效能，但質量衰減不可避免，通常在 2–4 倍外推範圍內表現尚可。
PagedAttention 與 vLLM
PagedAttention 將 KV Cache 分頁管理，類似作業系統虛擬記憶體：
- 解決視訊記憶體碎片化問題
- 提升 GPU 視訊記憶體利用率（從傳統方案的 ~50% 提升至接近 90%+，為行業共識估算）
- vLLM 專案是該技術的開源代表，已廣泛用於推論服務
技術原理
自迴歸生成中的 KV Cache 機制
時間步 t 生成 token x_t:
1. 計算 x_t 的 Q_t, K_t, V_t
2. 將 K_t, V_t 追加到 Cache
3. 計算注意力: Attn(Q_t, [K_1..K_t]) → 加權求和 V
4. 輸出 → 預測 x_{t+1}
┌─────────────────────────────────────────────┐
│ KV Cache 記憶體版面配置 │
│ │
│ Layer 0: [K_0, K_1, ..., K_t] [V_0, ..., V_t]│
│ Layer 1: [K_0, K_1, ..., K_t] [V_0, ..., V_t]│
│ ... │
│ Layer L: [K_0, K_1, ..., K_t] [V_0, ..., V_t]│
│ │
│ 每層每 token 佔用 = 2 × d_model × dtype_bytes│
└─────────────────────────────────────────────┘注意力複雜度對比
標準注意力: O(n² · d) 計算 + O(n · d) 記憶體（KV Cache）
FlashAttention: O(n² · d) 計算 + O(n) 額外記憶體（tiling）
線性注意力/SSM: O(n · d²) 計算 + O(d) 固定狀態
Sliding Window: O(w · n · d) 計算 + O(w · d) 記憶體（w為視窗）
n = 序列長度, d = 模型維度, w = 視窗大小視訊記憶體瓶頸圖示
GPU 視訊記憶體分配（長上下文推論場景，示意）：
┌──────────────────────────────────┐
│ 模型權重（固定） │ ~50-60%（短上下文時）
│ KV Cache（隨序列增長） │ ████████████ 快速膨脹
│ 啟用值 / 工作區 │ ██
│ 系統開銷 │ █
└──────────────────────────────────┘
當上下文很長時，KV Cache 可能佔 70%+ 視訊記憶體
→ 擠佔本可用於批處理（batch size）的空間
→ 吞吐量急劇下降技術演進史
| 時期 | 代表 | 上下文長度 | 關鍵技術 |
|---|---|---|---|
| 2017–2019 | GPT-1, BERT | 512–1024 | 標準 Transformer，無 KV Cache 概念普及 |
| 2020 | GPT-3 | ~2048–4096 | 大規模訓練確立上下文基準 |
| 2022 | ChatGPT (GPT-3.5) | ~4K (公開) | 產品化，上下文長度成為使用者體驗瓶頸 |
| 2023 Q1 | GPT-4 | 8K / 32K (公開) | 長上下文開始商業化 |
| 2023 H2 | Claude 2.1, GPT-4 Turbo | 100K–200K (公開) | RoPE 外推、FlashAttention-2 普及 |
| 2024 H1 | Claude 3, Gemini 1.5 Pro | 宣稱 200K–1M+ | 超長上下文成為競賽焦點 |
| 2024 H2 | 多家跟進 | 128K–1M+ | SSM/混合架構、KV Cache 壓縮成為熱點 |
注：以上公開數字來自各廠商當時的產品公告，實際可用長度與宣傳可能存在差距。
技術路線對比
長上下文實現路線
| 路線 | 複雜度 | 外推能力 | 質量保持 | 工程成熟度 | 代表方案 |
|---|---|---|---|---|---|
| RoPE 外推 | O(n²) | 中（2–4x） | 中 | 高 | LLaMA 系列、多數開源模型 |
| FlashAttention | O(n²) | 不改變 | 高 | 高 | FlashAttention-2/3 |
| Sliding Window | O(w·n) | 好 | 區域性高/全域性低 | 高 | Mistral 系列 |
| PagedAttention | O(n²) | 不改變 | 高 | 高 | vLLM |
| SSM / Mamba | O(n) | 好 | 任務依賴 | 中 | Mamba、Jamba（混合） |
| Ring Attention | O(n²) | 分散式 | 高 | 中 | 長序列分散式訓練/推論 |
KV Cache 壓縮技術
| 方法 | 壓縮比 | 精度損失 | 適用場景 |
|---|---|---|---|
| FP16→INT8 量化 | ~2x | 低 | 通用推論 |
| FP16→INT4 量化 | ~4x | 中 | 視訊記憶體極度受限 |
| Token 剪枝/驅逐 | 任務依賴 | 中-高 | 流式對話、檢索增強 |
| GQA/MQA | 2–8x | 低 | 架構層面減少 KV 頭數 |
| 共享 KV (SharedPrefix) | 取決於字首重用 | 無 | RAG、系統提示覆用 |
注：壓縮比和精度損失為行業共識估算範圍，具體效果因模型和任務而異。
上下游
上游（制約短期記憶的基礎設施層）:
├── GPU 視訊記憶體容量（HBM 代際/容量）
├── 視訊記憶體頻寬（決定 KV Cache 讀取延遲）
├── 互連頻寬（多卡推論時 KV 傳輸瓶頸）
└── 推論架構（vLLM、TensorRT-LLM、SGLang 等）
中游（短期記憶的技術實現層）:
├── 模型架構設計（GQA/MQA、位置編碼選擇）
├── 注意力最佳化（FlashAttention 等）
├── KV Cache 管理策略
└── 排程與批處理策略
下游（短期記憶的產品體現層）:
├── 對話產品（上下文長度 → 對話輪次/記憶永續性）
├── 文件理解（單次可處理文件長度）
├── 程式碼生成（上下文越大，可參考程式碼越多）
└── Agent/工具呼叫（長規劃鏈對上下文的消耗）關鍵指標
| 指標 | 定義 | 產業重要性 |
|---|---|---|
| Context Window | 模型單次輸入的最大 token 數 | 產品核心賣點 |
| Effective Context | 實際能有效利用的上下文長度（通常 < Window） | 衡量真實能力 |
| KV Cache 單 token 佔用 | 每 token 每層的 Key+Value 視訊記憶體佔用 | 決定長上下文的硬體門檻 |
| 首 Token 延遲 (TTFT) | Prefill 階段處理完整輸入的時間 | 長上下文時 TTFT 顯著增加 |
| 解碼吞吐 (Tokens/s) | 生成階段每秒輸出 token 數 | KV Cache 壓力越大，吞吐越低 |
| Needle-in-a-Haystack 得分 | 長文本中檢索特定資訊的準確率 | 衡量有效上下文質量 |
供需與市場資料
定性供需分析
需求側驅動：
- 企業級 RAG 場景需要處理長文件（合同、財報、程式碼庫）
- 多輪對話的使用者體驗要求持久記憶
- Agent 架構的規劃鏈消耗大量上下文
供給側約束：
- 高階 GPU 視訊記憶體容量有物理上限
- 超長上下文推論的算力成本隨序列長度二次方增長
- 推論服務的每 token 成本中，長上下文場景的 prefill 成本佔比顯著上升
成本結構示意（估算）：
推論成本構成（長上下文場景，定性）：
Prefill 階段（處理輸入）:
├── 計算密集（O(n²)注意力）
├── 耗時隨輸入長度急劇增加
└── 佔總成本比例：長上下文時可達 60-80%（估算）
Decode 階段（生成輸出）:
├── 記憶體密集（逐 token 讀取全部 KV Cache）
├── 吞吐受限於視訊記憶體頻寬
└── 佔總成本比例：相對固定
→ 這就是為什麼"輸入貴、輸出便宜"的定價模式在長上下文產品中常見注：上述比例為基於架構原理的估算，無公開財務資料支撐。
代表公司與資本對映
模型/產品層
| 公司 | 上下文長度（公開宣稱） | 技術特色 |
|---|---|---|
| OpenAI | GPT-4 Turbo: 128K（公開） | 產品化標杆 |
| Anthropic | Claude 3 系列: 最高宣稱 200K（公開） | 長上下文質量口碑較好 |
| Gemini 1.5 Pro: 宣稱最高 1M+（公開） | 超長上下文營銷 | |
| Meta | LLaMA 系列: 原生 8K，社群外推擴充套件 | 開源生態帶動 RoPE 外推研究 |
| Mistral | Mistral Large: 128K（公開） | Sliding Window Attention |
基礎設施層
| 公司/專案 | 定位 | 關聯邏輯 |
|---|---|---|
| vLLM（UC Berkeley） | 推論引擎 | PagedAttention 開源實現，長上下文效率最佳化 |
| Anyscale | 推論平台 | 提供 vLLM 推論服務的平台 |
| Together AI | 推論服務 | 長上下文推論 API 服務 |
| Cerebras | AI 晶片 | 晶圓級晶片的片上 SRAM 可能緩解 HBM 瓶頸 |
| Groq | AI 晶片 | LPU 架構強調確定性延遲，但長上下文適配性待驗證 |
注：上述為公開資訊整理，不構成投資建議。
投資邏輯
核心命題
短期記憶（上下文視窗）是 LLM 產品化的”體驗天花板”和”成本放大器”。
三條投資線索
| 線索 | 邏輯 | 風險 |
|---|---|---|
| HBM/視訊記憶體擴容 | 長上下文 = 更大 KV Cache = 更多視訊記憶體需求 → 利好 HBM 供應商 | 週期性、產能過剩風險 |
| 推論最佳化軟體 | PagedAttention、KV Cache 壓縮等降低長上下文推論成本 → 利好推論架構/服務商 | 技術迭代快，護城河存疑 |
| 架構範式轉移 | SSM/混合架構可能從根本上改變長上下文的成本曲線 → 關注 Mamba 等新架構 | 學術到工程的跨越期，商業化不確定性高 |
關鍵觀察點
- 各廠商”宣稱的上下文長度”vs”有效上下文質量”的差距何時收斂
- 推論成本隨上下文長度的增長曲線是否能從二次方壓到線性
- HBM 每 GB 成本的下降速度是否能匹配長上下文的需求增速
常見誤讀糾偏
誤讀 1：“支援 1M 上下文 = 1M 內全距離等質量”
糾偏： 實測（如 Needle-in-a-Haystack 測試）普遍顯示，模型在上下文視窗的中間段存在”注意力盲區”，對中間位置資訊的檢索準確率顯著低於首尾。這是注意力機制的已知特性（Lost in the Middle 現象），並非所有廠商都公開揭露此衰減程度。宣稱的視窗長度是上限，不是質量保證。
誤讀 2：“KV Cache 大小隻和模型引數量有關”
糾偏： KV Cache 大小主要取決於 層數 × KV 頭數 × 頭維度 × 序列長度 × 精度。關鍵誤解在於忽視了 GQA/MQA 等架構設計 會大幅減少 KV 頭數（例如 LLaMA 2 70B 使用 GQA，KV 頭數遠少於 Q 頭數），以及序列長度才是長上下文場景的決定性變數。同參數量模型的 KV Cache 可能差異數倍。
誤讀 3：“線性注意力/SSM 可以完全替代標準注意力”
糾偏： SSM（如 Mamba）的固定大小狀態意味著它無法像標準注意力那樣”精確回憶”任意歷史 token。在需要精確檢索的任務（如引用特定句子）上，純 SSM 架構可能不如標準注意力。當前趨勢是混合架構（如 Jamba: Mamba + 少量標準注意力層），取兩者之長。聲稱”SSM 完全取代注意力”過於絕對。
誤讀 4：“上下文越長越好”
糾偏： 超長上下文帶來：
- 顯著增加的推論成本（尤其 prefill 階段）
- 注意力稀釋——過多上下文可能引入噪聲
- 產品設計挑戰——如何讓使用者有效利用長上下文
實際上，多數場景下 32K–128K 已能滿足需求，1M+ 更多是技術展示而非普遍需求。
學習路徑
入門:
├── [必讀] Vaswani et al., "Attention Is All You Need" (2017) — 理解自注意力基礎
├── [必讀] Hugging Face 部落格: "KV Cache Explained" — 直觀圖解
└── [動手] 使用 vLLM 部署一個長上下文模型，觀察視訊記憶體隨輸入長度變化
進階:
├── [論文] Dao et al., "FlashAttention" (2022) — 理解 IO-aware 注意力最佳化
├── [論文] Su et al., "RoFormer: Enhanced Transformer with Rotary Position Embedding" (2021)
├── [論文] Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention" (2023) — vLLM 核心論文
└── [實踐] 對比同一模型在 4K/32K/128K 輸入下的延遲和視訊記憶體佔用
前沿:
├── [論文] Gu & Dao, "Mamba: Linear-Time Sequence Modeling with Selective State Spaces" (2023)
├── [論文] Liu et al., "Ring Attention with Blockwise Transformers for Near-Infinite Context" (2023)
├── [論文] 微軟 "LongRoPE" 等長度外推工作
└── [關注] 各廠商技術部落格關於長上下文質量評估的揭露一句話總結
短期記憶（上下文視窗）是 Transformer LLM 的”工作記憶”，其長度由 KV Cache 的視訊記憶體佔用決定，是模型能力、推論成本和產品體驗的核心交匯點——長上下文的競爭本質是視訊記憶體效率與注意力機制的雙重最佳化競賽。
延伸閱讀與來源
| 來源 | 內容 | 連結/說明 |
|---|---|---|
| Vaswani et al. (2017) | 自注意力機制原始論文 | arXiv:1706.03762 |
| Dao et al. (2022) | FlashAttention | arXiv:2205.14135 |
| Kwon et al. (2023) | PagedAttention / vLLM | arXiv:2309.06180 |
| Su et al. (2021) | RoPE 位置編碼 | arXiv:2104.09864 |
| Gu & Dao (2023) | Mamba (SSM) | arXiv:2312.00752 |
| Anthropic 技術部落格 | Claude 上下文質量討論 | anthropic.com/research |
| Hugging Face 文件 | KV Cache 技術詳解 | huggingface.co/docs |
| vLLM 官方文件 | PagedAttention 實現細節 | docs.vllm.ai |
| NVIDIA 技術部落格 | TensorRT-LLM 中的 KV Cache 最佳化 | developer.nvidia.com |
資料/規格宣告： 本頁未引用搜索結果（檢索失敗），所有技術規格均為基於公開論文和行業共識的定性表述或數量級估算。具體模型的上下文長度以各廠商最新官方文件為準。
撰寫日期：2025年 · 本頁內容僅供學習參考，不構成投資建議