在 22.1 至 22.3 节中，我们分别讨论了推理的核心指标、量化技术以及通用加速方案。但进入 2024 年后，行业竞争的一个关键战场变成了上下文窗口——从 Llama 2 的 4K，到 GPT-4 Turbo 的 128K，再到 Gemini 1.5 Pro 的百万 Token 级别。模型“能读进去”的长度飞速增长，但推理成本的增长速度远比这个更快。
本节聚焦一个核心问题：当你的用户丢进来一份 200 页的 PDF 或整个代码仓库时，推理系统如何在不耗尽显存、不让用户等到不耐烦的前提下跑完？
一、长上下文推理的核心瓶颈：KV-Cache 爆炸
要理解所有优化方案，必须先精准定位瓶颈在哪里。
回忆 1.1 节的“文字接龙”机制：每生成一个新 Token，模型都需要回顾前面所有已生成的 Token。这个“记忆”不是靠反复重读整个序列实现的，而是把每一层 Transformer 的 Key 和 Value 矩阵缓存下来——这就是 KV-Cache。
问题来了：KV-Cache 的大小随序列长度线性增长。
一个粗略的估算公式：
KV-Cache 显存（每层） = 2 × 批次大小 × 序列长度 × 隐藏层维度 × 层数 × 精度字节数举例：一个 7B 模型（32 层，隐藏维度 4096），在 FP16 精度下处理 128K 长度的单个序列：
- 单层 KV-Cache ≈ 2 × 1 × 131072 × 4096 × 2 字节 = 约 2 GB
- 32 层总计 ≈ 64 GB
而模型参数本身在 FP16 下只占约 14 GB（7B × 2 字节），KV-Cache 反而膨胀到了参数存储的 4 倍以上。长上下文推理的瓶颈通常不是模型加载，而是 KV-Cache 把显存放倒。
二、方案一：GQA 与 MQA——从注意力机制源头减量
最根本的思路是在模型架构层面就减少 KV-Cache 的体积。这是训练阶段决定的，但推理时直接受益。
1. Multi-Query Attention（MQA）
标准多头注意力中，每个注意力头都有独立的 K 和 V 矩阵。MQA 的做法是所有头共享同一组 K 和 V，只有 Q 保持多头。KV-Cache 直接降为原来的 1/头数。
- 代表模型：PaLM、早期的 Gemini 系列
- 代价：表达能力略有下降，部分任务精度受损
2. Grouped-Query Attention（GQA）
折中方案：将注意力头分成若干组，组内共享 K 和 V。例如 Llama 3 70B 有 64 个注意力头，分成 8 组，每组 8 个头共享 KV。KV-Cache 降为原来的 1/8。
- 代表模型：Llama 2/3、Mistral、Qwen2
- 优势：几乎不影响生成质量，但显存节省显著
实用建议：如果你在选型基座模型，优先考虑支持 GQA 的模型用于长上下文场景。对比一个 34B 的 MHA 老模型和一个 34B 的 GQA 新模型，后者的长文本推理显存可能只是前者的一半。
三、方案二：KV-Cache 量化——不舍架构改精度
即使模型用了 GQA，超长序列的 KV-Cache 依然很大。第二个思路是直接对 KV-Cache 做低精度压缩。
1. KV8 / KV4 量化
将存储 Key 和 Value 的数据类型从 FP16 降到 INT8 甚至 INT4：
- INT8 KV-Cache：体积减半，精度损失极小，绝大多数场景无感知
- INT4 KV-Cache：体积降为 1/4，部分模型在超长文本（>100K）下可能出现注意力分数偏差
2. 实现方式
主流推理框架已原生支持：
- vLLM：启动时添加
--kv-cache-dtype fp8或--kv-cache-dtype int8 - TensorRT-LLM：构建引擎时指定 KV-Cache 精度
- HuggingFace Transformers：配合
bitsandbytes或quanto库
但要注意：KV-Cache 量化不是无脑开就好。极低精度下，Key 的量化误差可能在 Softmax 计算中被放大，导致注意力分布出现偏移。建议在自己的业务数据上做 A/B 测试，对比困惑度（Perplexity）或人工评估生成质量。如果任务对事实细节极度敏感（如法律条款引用），可保留 FP16 Key，只量化 Value。
四、方案三：注意力机制优化——从 O(n²) 逼近 O(n)
标准自注意力的计算复杂度是序列长度的平方。128K 的序列意味着单次注意力计算需要 160 亿次内积——这在 GPU 上也非常沉重。
1. FlashAttention（FlashAttention-2/3）
16.4 节和 17.3 节已有详细原理介绍。这里强调它在长上下文场景的两个关键收益：
- 显存不存完整注意力矩阵：通过分块（Tiling）计算，避免了 O(n²) 的中间矩阵存储
- IO 优化：充分利用 GPU SRAM 的带宽优势
目前几乎所有现代 LLM 推理（包括 vLLM、TGI、TensorRT-LLM）都默认采用 FlashAttention。如果你的推理框架还没开（比如某些旧版 PyTorch 直接跑），第一时间切过去，长文本吞吐量可以提升 2-5 倍。
2. Ring Attention / Striped Attention
当单个 GPU 的显存放不下完整序列的 KV-Cache 时怎么办？把长序列切成多段，每张 GPU 负责一段，通过环形通信交换彼此的 KV-Cache 来做跨段注意力。
这是 TensorRT-LLM 多节点部署和 Model Parallelism 的自然延伸。在单机 8 卡 A100 上，Ring Attention 可以让有效上下文窗口扩展到单卡显存上限的 8 倍。
3. 稀疏注意力 / 滑动窗口 + 全局注意
让每个 Token 不跟所有前置 Token 都算注意力，而是：
- 滑动窗口：只看最近的 W 个 Token（如 Mistral 的 4096 窗口）
- 全局 Token：额外设几个“全局节点”能看见所有内容，作为摘要传递
这种方式在 Mistral、Longformer 等模型中已有原型，但牺牲了“随时回头看任何位置”的灵活性，对需要跨文档跨段落精确引用的任务不太友好。
五、方案四：Prompt 压缩与分块策略——从输入端削减长度
很多时候，用户不是真的需要模型逐字读取 200 页文档。更聪明的做法是在输入端做精简。
1. 基于检索的分段处理（RAG-style 长上下文）
不喂全文，而是：
- 先把长文档切成 Chunk，存入向量库
- 用户提问时，检索最相关的 Top-K 个 Chunk
- 只把这些 Chunk 拼接成 Prompt 输入模型
优点是显存友好、响应快；缺点是无法完成“总结整本书”这类全局任务。
2. LLMLingua 等 Prompt 压缩工具
用一个轻量级小模型（如 LLaMA-2-7B 或更小的蒸馏模型）先“预读”长 Prompt，识别出关键句并剔除冗余。压缩率通常可达 2-5 倍，且对最终生成质量影响可控。
适合场景：用户输入的文档中有大量模板、重复性措辞（如各类招商文书、例行报告），但你需要保留核心信息。
3. 关键信息前置 + 尾部保留
针对“文章开头是精华，中后部是细节补充”的文档（如新闻稿、财报），可以：
- Token 预算前 20% 覆盖标题和摘要
- 中间按关键段落均匀采样
- 尾部保留最后几段（因结论常在末尾）
这是缺乏工具时的经验法则，不严谨但在部分场景有效。
六、实战选型决策树
把四种方案组合起来，你的长上下文推理策略应该根据实际长度和任务性质分层：
| 上下文长度 | 业务类型 | 推荐组合方案 |
|-----------|---------|-------------|
| 8K–32K | 长对话/中篇文档 | GQA 模型 + FlashAttention + INT8 KV-Cache |
| 32K–128K | 书籍/长报告 | 上述 + Ring Attention（多卡并跑）或 KV4 量化 |
| 128K–1M | 超长文档/代码库 | 多模态拆解优先（RAG 分块）；若必须全量读入，需多节点 Ring Attention + KV4 + Prompt 前端压缩 |
| 对事实精准度极高 | 法律/金融 | 不量化 Key，允许 Value INT8；优先 RAG 分段而非喂全文 |
三条真实工程经验：
- 别试图把长上下文当数据库用：你的用户可能需要“全文读进去，随时问任何细节”，但当前模型在 100K 以上的“海里捞针”（Needle in a Haystack）测试中仍有明显失败率。RAG 分块 + 短上下文精准生成，在大多数生产场景下更可靠也更可控。
- 长上下文的延迟和成本会吓到用户：128K 提示词 + 生成 2K 输出，可能消耗数百万 Token 并等待十几秒。在 Chunk 策略上多花一天工程，比多采购一箱 GPU 划算得多。
- 监控 KV-Cache 命中率：如果你的应用是多轮对话，把系统 Prompt 和前期历史缓存在服务端，只给新输入做增量注意力计算。vLLM 的 Automatic Prefix Caching 和 Prompt Caching 现在已能自动完成这件事。
长上下文是 2024 年大模型最亮眼的营销卖点之一，但落地时必须认清：它能读，不代表你能付得起成本，也不代表它读完后能准确回忆起每一个细节。 合理的工程组合，才能把“128K 上下文”从实验室 Demo 变成用户愿意用的产品。