短期记忆 (Short-Term Memory) · AI推理架构核心概念

3 秒看懂

一句话： 大模型的”短期记忆”就是上下文窗口——它一次能”看到”多少 token，直接决定对话质量、推理成本和部署门槛。

关键词： Context Window / KV Cache / 注意力内存

3 分钟产业解释

这是什么？

在 Transformer 架构的 LLM 中，“短期记忆”并非生物学概念的直接映射，而是指模型在单次推理过程中能处理的 token 序列长度，即 Context Window（上下文窗口）。每次生成 token 时，模型需要”回顾”此前所有 token 的信息，这部分信息以 KV Cache（键值缓存） 的形式驻留在 GPU 显存中。

为什么是产业核心变量？

产业现状（定性）

• 主流商用模型上下文已从早期的 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 长度外推

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）的空间
→ 吞吐量急剧下降

技术演进史

注：以上公开数字来自各厂商当时的产品公告，实际可用长度与宣传可能存在差距。

技术路线对比

长上下文实现路线

KV Cache 压缩技术

注：压缩比和精度损失为行业共识估算范围，具体效果因模型和任务而异。

上下游

上游（制约短期记忆的基础设施层）:
├── GPU 显存容量（HBM 代际/容量）
├── 显存带宽（决定 KV Cache 读取延迟）
├── 互连带宽（多卡推理时 KV 传输瓶颈）
└── 推理框架（vLLM、TensorRT-LLM、SGLang 等）

中游（短期记忆的技术实现层）:
├── 模型架构设计（GQA/MQA、位置编码选择）
├── 注意力优化（FlashAttention 等）
├── KV Cache 管理策略
└── 调度与批处理策略

下游（短期记忆的产品体现层）:
├── 对话产品（上下文长度 → 对话轮次/记忆持久性）
├── 文档理解（单次可处理文档长度）
├── 代码生成（上下文越大，可参考代码越多）
└── Agent/工具调用（长规划链对上下文的消耗）

关键指标

供需与市场数据

定性供需分析

需求侧驱动：

• 企业级 RAG 场景需要处理长文档（合同、财报、代码库）
• 多轮对话的用户体验要求持久记忆
• Agent 框架的规划链消耗大量上下文

供给侧约束：

• 高端 GPU 显存容量有物理上限
• 超长上下文推理的算力成本随序列长度二次方增长
• 推理服务的每 token 成本中，长上下文场景的 prefill 成本占比显著上升

成本结构示意（估算）：

推理成本构成（长上下文场景，定性）：

Prefill 阶段（处理输入）:
├── 计算密集（O(n²)注意力）
├── 耗时随输入长度急剧增加
└── 占总成本比例：长上下文时可达 60-80%（估算）

Decode 阶段（生成输出）:
├── 内存密集（逐 token 读取全部 KV Cache）
├── 吞吐受限于显存带宽
└── 占总成本比例：相对固定

→ 这就是为什么"输入贵、输出便宜"的定价模式在长上下文产品中常见

注：上述比例为基于架构原理的估算，无公开财务数据支撑。

代表公司与资本映射

模型/产品层

基础设施层

注：上述为公开信息整理，不构成投资建议。

投资逻辑

核心命题

短期记忆（上下文窗口）是 LLM 产品化的”体验天花板”和”成本放大器”。

三条投资线索

关键观察点

• 各厂商”宣称的上下文长度”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 的显存占用决定，是模型能力、推理成本和产品体验的核心交汇点——长上下文的竞争本质是显存效率与注意力机制的双重优化竞赛。

延伸阅读与来源

数据/规格声明： 本页未引用搜索结果（检索失败），所有技术规格均为基于公开论文和行业共识的定性表述或数量级估算。具体模型的上下文长度以各厂商最新官方文档为准。

撰写日期：2025年 · 本页内容仅供学习参考，不构成投资建议