上下文即缓存：面向高性能AI智能体的KV缓存优化技术报告

第一节：上下文工程与KV缓存的共生关系

本节旨在建立报告的核心论点：高层次的上下文工程（Context Engineering）与底层的键值缓存（Key-Value Cache, KV Cache）机制密不可分。我们将以用户参考的文章作为一个典型案例，阐明这种紧密的耦合关系。

1.1 上下文工程：AI智能体的系统级挑战

上下文工程是一门旨在通过设计、组织和操控输入给大语言模型（LLM）的上下文信息，以优化其性能的学科 ¹。它并非简单地改进提示词（Prompt），而是专注于构建能够“在恰当的时间，提供恰当上下文”的动态系统 ³。其核心目标是提供丰富、结构化且高度相关的信息，引导模型产生准确、个性化且值得信赖的输出，从而为LLM构建一个高效的“操作系统” ¹。

与聚焦于静态、手工制作输入字符串的提示词工程（Prompt Engineering）不同，上下文工程的范畴更为广阔，涵盖了使用嵌入、记忆、链式调用和检索等技术动态构建上下文的全过程 ¹。例如，在一个客户支持场景中，一个优秀的上下文工程系统不仅会传递用户的当前问题，还会动态注入该用户的历史服务记录、账户等级、所在地区以及相关的最新知识库文章摘要 ⁶。这种系统级的上下文构建，使得模型的响应从通用化、无信息量的回答，转变为高度情境化、数据驱动的精准解决方案。

然而，这一过程也引入了显著的系统级复杂性。首先是延迟（Latency），信息检索、格式化和注入等步骤会增加额外的处理开销。其次是上下文污染（Context Poisoning），一旦模型产生的错误（如幻觉）被注入上下文并反复引用，错误就会被固化并不断放大，导致智能体偏离目标。再次是上下文分心（Context Distraction），当上下文变得过长时，模型可能会被海量信息淹没，难以聚焦于当前任务。最后是上下文混淆（Context Confusion），冗余、不相关或相互冲突的信息会干扰模型的判断力，降低输出质量 ¹。这些挑战表明，上下文工程不仅是“信息填充”的问题，更是一个复杂的系统设计与优化问题。

1.2 物理屏障：Transformer推理如何限制上下文

AI智能体（Agent）的运行模式天然地与LLM的物理限制产生了冲突。智能体的工作流本质上是迭代式的：接收用户输入，通过一系列工具调用来完成任务。在每一次迭代中，模型根据当前上下文选择一个动作，该动作在环境中执行后产生一个观察结果，接着这个动作和观察结果被追加到上下文中，形成下一次迭代的输入 ⁷。

这个循环导致上下文随着每一个步骤线性增长。在类似Manus这样的智能体系统中，输入与输出的Token比例可能高达100:1，这意味着绝大部分的计算资源和时间都消耗在处理日益增长的输入（即预填充阶段，Prefill）上，而非生成简短的输出（如函数调用） ⁷。

这种机制使得上下文工程的理想——提供尽可能丰富的上下文（如完整的对话历史、详细的外部文档、全面的工具使用记录）——与Transformer架构的物理限制发生了直接碰撞。尽管现代前沿模型的上下文窗口已经扩展到128K甚至更大，但在真实的智能体场景中，这往往仍然不够用，甚至会成为一种负担 ⁴。主要痛点包括：

观察结果可能极其庞大：当智能体与网页、PDF等非结构化数据交互时，一次观察就可能轻易超出上下文窗口限制 ⁷。
长上下文性能衰减：即便技术上支持，模型在处理超过一定长度的上下文时，性能也往往会下降，出现“迷失在中间（lost-in-the-middle）”等问题 ⁷。
高昂的成本：即使有前缀缓存，长输入依然意味着高昂的传输和预填充成本 ⁷。

因此，一个根本性的矛盾出现了：智能体需要依赖完整的历史状态来预测下一步行动，但物理和经济上的限制却迫使其对上下文进行截断或压缩。任何不可逆的压缩都伴随着信息丢失的风险，因为无法预知哪个历史观察结果会在未来的某个步骤中变得至关重要 ⁷。

1.3 KV缓存：从优化手段到关键瓶颈

manus.im的博文精准地指出了解决上述矛盾的关键：提升智能体性能的核心，并非仅仅是优化提示词策略，而是要围绕KV缓存进行设计（Design Around the KV-Cache） ⁷。对于生产环境的AI智能体而言，

KV缓存命中率是那个最重要的单一指标，因为它直接决定了系统的延迟（尤其是首个Token生成时间）和成本 ⁷。

KV缓存是Transformer模型在自回归生成过程中的一项关键优化。它通过存储先前已处理Token的键（Key）和值（Value）矩阵，避免了在生成每个新Token时重复计算整个序列的注意力，从而将生成过程的时间复杂度从二次方降低到线性 ⁸。然而，这一优化机制的有效性依赖于一个严格的前提：

只有当一个请求的输入序列前缀与先前处理过的序列完全相同时，对应的KV缓存才能被复用 ⁷。

这一前提将高层次的上下文工程问题，直接转化为一个底层的、字节级的系统工程问题。manus.im提出的实践原则深刻地体现了这一点：

保持提示词前缀稳定：在系统提示的开头避免使用动态变化的内容，例如精确到秒的时间戳，因为哪怕一个Token的改变都会使后续所有缓存失效 ⁷。
使上下文成为仅追加（Append-only）：避免修改历史的动作或观察结果，保证上下文的不可变性 ⁷。
确保序列化过程的确定性：许多编程语言在序列化JSON对象时，不保证键的顺序，这种不确定性会“悄无声息”地破坏缓存，导致命中率下降 ⁷。

这些实践揭示了一个在生产级智能体系统中至关重要的优先级反转。在学术研究或简单的聊天机器人应用中，上下文的“语义质量”是首要考量。但在大规模运行的生产级智能体中，上下文的“稳定性”和“可缓存性”变得与语义质量同等重要，甚至更为关键。一个语义上“最优”但动态变化、频繁破坏缓存的上下文，其综合效能远不如一个语义上“足够好”但高度稳定的上下文。

这种转变意味着，构建健壮的AI智能体，既是机器学习的挑战，更是系统工程的挑战。选择一个能保证键序的序列化库，这种看似与AI无关的软件工程决策，已然成为影响AI系统性能的一阶因素。最终，系统架构师能够工程化的上下文，本质上受限于其所能有效管理的缓存。

第二节：深入剖析推理机制与内存占用

本节将提供必要的技术背景，量化KV缓存问题，并定义受其影响的关键性能指标。

2.1 计算与内存之舞：计算密集型Prefill与内存带宽密集型Decode

大语言模型的文本生成过程主要分为两个截然不同的阶段，它们的性能瓶颈也各不相同 ¹⁰。

阶段一：预填充（Prefill）
在此阶段，模型并行处理整个输入提示（Prompt）的所有Token，以生成第一个输出Token 12。这一过程涉及大规模的矩阵与矩阵相乘（Matrix-Matrix Multiplication），其计算量巨大，性能通常受限于GPU的浮点运算能力（TFLOPS）。因此，Prefill阶段被认为是
计算密集型（Compute-Bound） ¹²。此阶段的主要延迟指标是
首个Token生成时间（Time To First Token, TTFT） ¹¹。在Prefill过程中，输入提示对应的KV缓存会被计算并填充到GPU内存中 ¹²。
阶段二：解码（Decode）
在此阶段，模型以自回归的方式逐个生成后续的Token 11。每生成一个新Token，模型只需处理这一个Token，并利用已缓存的、来自所有先前Token（包括Prefill阶段的提示和Decode阶段已生成的Token）的K和V向量进行计算。这个过程主要涉及矩阵与向量相乘（Matrix-Vector Operation），其计算强度远低于Prefill阶段，无法充分利用GPU的并行计算单元 13。因此，Decode阶段的性能瓶颈转向了数据传输速度，即从GPU的高带宽内存（HBM）中加载模型权重和庞大的KV缓存到计算核心的速度。这一阶段被认为是
内存带宽密集型（Memory-Bandwidth-Bound） ¹¹。此阶段的关键性能指标是
单个输出Token生成时间（Time Per Output Token, TPOT） ¹⁵。
干扰问题（Interference Problem）
在同一个GPU上混合处理这两个阶段的请求会导致严重的性能干扰。当一个批次（Batch）中同时包含Prefill任务和Decode任务时，耗时较长的Prefill步骤会阻塞批次内所有Decode步骤的执行，显著增加它们的TPOT。反之，Decode步骤的存在也会略微增加Prefill任务的TTFT 15。即使通过调度将它们分开，两者依然会竞争GPU资源，导致排队延迟增加。

2.2 量化负担：计算KV缓存的内存占用

KV缓存的内存占用是限制LLM处理长上下文和高并发请求的核心物理瓶颈。其大小可以被精确计算。综合多个来源的资料 ¹⁸，其计算公式如下：

KV_Cache_Size (bytes)=b×s×L×2×nkv×dhead×p

其中：

b (batch_size): 批处理大小，即同时处理的序列数量。
s (sequence_length): 序列长度，即上下文中的Token总数。
L (num_layers): 模型的Transformer层数。
2: 代表每个Token在每层每个头中都需要存储一个Key向量和一个Value向量。
nkv (num_kv_heads): 关键变量，表示每层中Key/Value头的数量。在标准多头注意力（MHA）中，$n_{kv}$等于查询头（Query Head）的数量；但在分组查询注意力（GQA）或多查询注意力（MQA）中，$n_{kv}$会显著减少。
dhead (head_dim): 每个注意力头的维度。
p (bytes_per_element): 每个数值元素占用的字节数。例如，FP16（半精度浮点数）为2字节，INT8（8位整数）为1字节。

这个公式清晰地表明，KV缓存的大小与序列长度和批处理大小成线性关系。对于长序列任务，KV缓存的内存占用会急剧增长，甚至可能超过存储模型权重本身所需的内存 ¹⁶。例如，一个500B+参数的模型，其KV缓存可能达到TB级别 ²²。对于像Llama-3-70B这样的模型，处理一个4096 Token的上下文，KV缓存就需要大约10.5 GB的显存 ²³。这使得KV缓存成为GPU显存的主要消耗者和性能瓶颈。

2.3 关键性能指标：TTFT、TPOT与吞吐量

在评估LLM推理系统时，需要区分并关注以下几个核心指标：

延迟（Latency）：衡量处理单个请求的速度，对于需要实时交互的应用（如聊天机器人）至关重要。延迟通常分解为两个部分：
- TTFT (Time To First Token)：从发送请求到接收到第一个输出Token的时间。主要由Prefill阶段的计算耗时决定，直接影响用户感知的“响应速度” ¹¹。
- TPOT (Time Per Output Token)：生成每个后续Token的平均时间。主要由Decode阶段的内存带宽决定，影响用户感知的“生成速度” ¹⁵。
- 总延迟可以近似为：Latency=TTFT+(TPOT×num_output_tokens) ¹¹。
吞吐量（Throughput）：衡量系统在单位时间内处理的总工作量，通常以“每秒处理的Token数（tokens/sec）”或“每秒处理的请求数（requests/sec）”来度量。吞吐量是衡量系统成本效益的关键指标 ¹¹。

延迟和吞吐量之间存在典型的权衡关系。例如，通过增加批处理大小（Batching）可以提高GPU利用率，从而提升系统总吞吐量，但通常会因为请求排队和批处理等待而增加单个请求的延迟 ¹⁸。KV缓存优化的核心目标之一，就是打破或缓解这种权衡，通过降低单个请求的内存占用，使得系统能够在不牺牲过多延迟的情况下，支持更大的批处理规模和更长的上下文，从而同时提升吞吐量和应用能力。

表1：主流大语言模型KV缓存大小估算（FP16精度）

为了具体地展示KV缓存的内存压力，下表估算了在FP16精度（每个元素2字节）下，单批次（batch_size=1）不同模型在不同序列长度下的KV缓存大小。这使得抽象的“线性增长”问题变得具体可见。

模型	参数量	隐藏层维度 (dmodel)	层数 (L)	KV头数量 (nkv)	头维度 (dhead)	每Token缓存大小 (MB)	4k Tokens缓存大小 (GB)	32k Tokens缓存大小 (GB)	128k Tokens缓存大小 (GB)
Llama-3.1-8B	8B	4096	32	8 (GQA)	128	0.52	2.05	16.38	65.54
Mistral-7B	7B	4096	32	8 (GQA)	128	0.52	2.05	16.38	65.54
Llama-3.1-70B	70B	8192	80	8 (GQA)	128	1.31	5.24	41.94	167.77
MHA基线 (假设8B)	8B	4096	32	32 (MHA)	128	2.10	8.19	65.54	262.14

注：计算公式为 1×序列长度×L×2×nkv×dhead×2 字节。MHA基线假设KV头数量与查询头数量（通常为32）相同，以作对比。

从表中可以清晰地看到，随着序列长度的增加，KV缓存的占用呈线性飙升。对于Llama-3.1-8B，当上下文达到32k时，缓存大小已接近许多消费级GPU的显存上限；而当达到128k时，其大小（65.54 GB）已超过了单个A100 40GB GPU的容量。对于70B模型，这一问题更加严峻。同时，通过对比GQA模型和MHA基线，可以直观地看到GQA架构（将$n_{kv}$从32降至8）带来的显著内存节省（减少了4倍）。这张表格为后续章节中讨论的各种优化技术的必要性和有效性提供了坚实的量化依据。

第三节：架构级解决方案：从源头减少缓存

本节聚焦于主动式策略，即通过修改注意力机制本身来从根本上减少生成的KV数据量。这是最基础、最核心的优化路径。

3.1 基线：多头注意力（MHA）

多头注意力（Multi-Head Attention, MHA）是原始Transformer论文中提出的标准注意力机制 ²⁴。其核心思想是将注意力计算分解到多个“头”（Head）中并行进行，每个头学习输入序列的不同子空间表示 ²⁵。在MHA中，每个查询头（Query Head）都拥有自己独立的一套键（Key）和值（Value）投影权重和向量。这意味着，如果一个模型层有

h个查询头，那么它同样有h个独立的键/值头。因此，KV头的数量与查询头的数量相等，即nkv=nq ²⁷。

这种设计提供了最大的模型表达能力，因为每个头都可以学习关注完全不同的信息模式。然而，它的代价也是巨大的：MHA产生了最大量的KV缓存，直接导致了前文所述的内存带宽瓶颈，尤其是在内存带宽受限的解码（Decode）阶段 ²⁶。

3.2 多查询注意力（MQA）：激进的削减与质量权衡

为了解决MHA带来的内存瓶颈，多查询注意力（Multi-Query Attention, MQA）被提出 ²⁸。MQA采用了一种激进的简化策略：在同一层中，

所有的查询头共享唯一一个键头和值头 ²⁹。这意味着，无论模型有多少个查询头，每层的KV头数量始终为1，即

nkv=1 ²⁷。

影响：

MQA极大地减小了KV缓存的大小以及加载K和V张量所需的内存带宽，其缩减因子约等于查询头的数量（nq） 27。例如，对于一个有32个查询头的模型，MQA能将KV缓存的占用空间和相关内存带宽需求降低约32倍。这显著加速了内存带宽密集型的解码阶段，从而提升了推理速度 28。

权衡：

然而，这种激进的参数共享并非没有代价。主要权衡点包括：

模型质量下降：由于所有查询头被迫共享同一套K/V表示，模型的表征能力受到限制，可能导致在复杂任务上性能下降 ²⁸。
训练不稳定性：MQA在训练过程中有时会表现出不稳定的情况 ²⁷。
张量并行效率问题：在多GPU的张量并行（Tensor Parallelism）场景下，由于只有一个K/V头，这个共享的头必须被复制到每个参与计算的GPU上，造成了冗余计算和存储 ³¹。

3.3 分组查询注意力（GQA）：业界的务实妥协

分组查询注意力（Grouped-Query Attention, GQA）作为MHA和MQA之间的一种折衷方案应运而生，并迅速成为业界的主流选择 ²⁴。GQA的核心机制是将查询头分成若干个组（Group），每个组内的所有查询头共享一套键/值头 ²⁷。因此，其KV头的数量

$n_{kv}$介于MQA和MHA之间，即$1 < n_{kv} < n_{q}$。例如，Llama-3.1-70B模型拥有80个查询头和8个KV头，这意味着查询头被分成了8个组，每组10个查询头共享同一套K/V ²⁰。

影响：

GQA提供了一个可调节的“旋钮”，允许模型设计者在模型质量和推理效率之间做出精细的权衡。它旨在实现接近MHA的模型质量，同时保留与MQA相当的速度和内存优势 28。

行业趋势分析：

GQA的广泛采用，尤其是在Llama 2/3、Mistral、Qwen等一系列领先的开源大模型中 26，揭示了一个深刻的行业趋势。这表明，对于追求长上下文能力和高吞吐量的大规模模型而言，MHA所提供的极致表达能力已经成为一种“无法承受的奢侈”。KV缓存瓶颈已经从一个部署阶段的优化问题，上升为了一个

预训练阶段的核心设计约束。

这一演变过程清晰地展示了系统工程压力如何反向塑造了模型架构本身：

早期的模型（如T5）普遍采用MHA架构，优先保证模型质量 ²⁸。
随着模型规模化部署，推理过程中的内存带宽瓶颈（尤其是在解码阶段）日益凸显 ³⁵。
MQA作为解决方案被提出，但其对质量的牺牲过于激进，未被广泛接受 ²⁷。
GQA作为一种可调节的“甜点”方案出现，提供了更优的权衡 ²⁸。
关键的转变在于，尽管研究表明可以将已有的MHA模型通过少量额外训练（Uptraining）转换为GQA模型 ²⁷，但最新的旗舰模型（如Llama 2 70B、Llama 3、Mistral）却选择
从头开始就使用GQA架构进行预训练 ²⁶。

这一决策意味着，GQA带来的性能和成本优势是如此巨大，以至于模型开发者愿意在投入数万亿Token进行预训练之前，就将其作为核心架构的一部分固定下来。这标志着LLM的设计理念已经发生了根本性的转变：不再是先追求理论上的最佳模型，再考虑如何优化部署；而是在模型设计的最初阶段，就将系统效率和硬件限制作为一等公民纳入考量。

3.4 新兴变体与未来方向

在GQA的基础上，研究社区仍在探索更精细的优化方案：

加权GQA (Weighted GQA, WGQA)：传统的GQA在将MHA头合并为GQA组时，通常采用简单的均值池化。WGQA则引入了可学习的标量权重，对每个K/V头进行加权平均，使得模型可以在微调阶段学习到最优的聚合方式，从而提升性能 ³⁴。
非对称GQA (Asymmetric GQA, AsymGQA)：该方法认为均匀地划分查询头组是次优的，并提出了一种基于激活值信息的非对称分组策略，以期获得更好的性能 ³⁷。
跨层注意力 (Cross-Layer Attention, CLA)：这是一种更为激进的共享策略，它不仅在层内共享K/V头，更进一步地在多个连续的层之间共享K/V头，从而能够将KV缓存的大小再一步压缩 ³⁸。

表2：注意力机制对比分析 (MHA vs. MQA vs. GQA)

为了清晰地总结上述架构的权衡，下表提供了一个直观的对比。

特性	多头注意力 (MHA)	多查询注意力 (MQA)	分组查询注意力 (GQA)
核心机制	每个查询头拥有独立的K/V头。	所有查询头共享单一的K/V头。	查询头分组，每组共享一个K/V头。
KV头数量	nq	1	G (其中 1<G<nq)
KV缓存大小	基准 (最大)	最小 (减少约$n_{q}$倍)	中等 (减少约nq/G倍)
推理速度	最慢 (受内存带宽限制)	最快	快速 (与MQA相当)
模型质量	最高 (表达能力最强)	较低 (有性能下降风险)	高 (接近MHA)
训练稳定性	稳定	可能不稳定	稳定
代表模型	Llama 2 (7B, 13B), GPT-3	PaLM, Falcon	Llama 3 (8B, 70B), Mistral 7B, Qwen

第四节：生成后优化：压缩与修剪缓存

本节探讨在KV缓存由注意力机制生成之后，对其进行处理的反应式策略。这些技术可以与第三节的架构级解决方案叠加使用，以实现更极致的优化。

4.1 通过量化压缩缓存

量化是一种通过降低数值表示的精度来减小内存占用的技术。它直接作用于KV缓存大小计算公式中的“每元素字节数”(p)，是实现内存优化的关键手段之一。

4.1.1 低精度表示原理

核心概念：量化的本质是将高精度浮点数（如FP16，16位）映射到低精度数据类型（如INT8，8位整数；或INT4，4位整数） ¹⁹。这种转换显著减少了存储每个数值所需的内存。例如，将KV缓存从FP16量化到INT8，内存占用减半；量化到INT4，则减少为原来的四分之一 ²⁹。

收益与权衡：

最直接的收益是，在相同的硬件上支持更长的上下文或更大的批处理规模。例如，一块A100 GPU的FP16 KV缓存可能只能支持40k Token的上下文，而通过量化技术，其支持能力可以扩展到128k Token 19。然而，这种优化也存在权衡：

延迟开销：量化和反量化操作本身会引入一定的计算开销，可能略微增加延迟 ¹⁹。
精度损失：低精度表示不可避免地会丢失信息，如果处理不当，可能会影响模型的最终性能 ¹⁹。

4.1.2 先进技术：逐Token与逐通道量化及异常值处理

简单的均匀量化在处理KV缓存时会遇到挑战，因为研究发现Key缓存和Value缓存具有截然不同的数据分布特性。

异常值挑战：一个关键的发现是，Key缓存的激活值在某些特定通道（即特征维度）上存在显著的异常值（Outliers），而Value缓存的分布则相对平滑，没有这种现象 ¹⁹。这些异常值的存在，使得传统的、对整个张量使用相同缩放因子的量化方法效果不佳，容易导致巨大的精度损失。
KIVI (Key-Value cache quantization)：为了应对这一挑战，KIVI论文提出了一种非对称的量化策略。它根据K和V缓存各自的分布特点，对Key缓存采用逐通道（Per-Channel）量化，为每个特征维度计算独立的量化参数；而对Value缓存采用逐Token（Per-Token）量化 ¹⁹。这种精细化的处理方式能更好地适应各自的数据分布，从而在低比特（如2-bit）下保持较高的模型性能。
KVQuant：这项工作进一步推动了低比特（sub-4-bit）KV缓存量化的边界。它引入了多项创新技术 ⁴⁰：
1. 旋转位置编码前量化（Pre-RoPE Quantization）：发现在应用旋转位置编码（RoPE）之前，Key缓存的异常值通道更为稳定。因此，KVQuant选择在RoPE操作之前对Key进行量化，以规避RoPE带来的分布变化。
2. 敏感度感知非均匀量化（Sensitivity-aware NUQ）：不同于仅考虑数值大小的传统量化方法，该技术在确定量化点时还考虑了模型的敏感度，从而更有效地保护关键信息。
3. 异常值显式分离：KVQuant设计了一种机制，可以高效地识别并提取激活值中的异常值，将它们与普通数值分开，用一种独立的稀疏表示格式进行紧凑存储。仅分离1%的异常值，就能在3-bit量化下实现极小的性能下降。

4.2 通过稀疏化驱逐缓存

与压缩每个缓存条目不同，驱逐（Eviction）策略通过制定规则，选择性地从缓存中丢弃整个Token的K/V对。这种方法旨在将缓存大小维持在一个固定的预算内，从而理论上能够处理无限长的序列，但代价是必然的信息丢失。

4.2.1 “注意力沉洞”现象与StreamingLLM框架

现象发现：研究人员发现，在标准的自回归LLM中，无论其语义内容是否重要，模型都会将不成比例的大量注意力分配给序列最开始的几个Token。这些初始Token就像一个“注意力沉洞（Attention Sink）” ⁴¹。这种现象被认为是Softmax函数的一个副产物：由于Softmax要求所有Token的注意力权重之和必须为1，当后续Token与上下文中大部分内容都不太相关时，模型需要一个地方来“倾倒”多余的注意力权重。而初始Token由于对所有后续Token都可见，便自然而然地成为了这个“沉洞” ⁴²。
朴素滑动窗口的失败：基于这一发现，一个简单的、只保留最近N个Token的滑动窗口策略会遭遇灾难性失败。一旦滑动窗口移动，导致最初的几个“沉洞”Token被从缓存中驱逐，模型的性能（以困惑度Perplexity衡量）会立即飙升，生成内容变得语无伦次 ⁴¹。
StreamingLLM的解决方案：StreamingLLM提出了一种简单而极其有效的启发式策略。它维持一个固定大小的缓存，其中同时保留最初的几个（例如4个）“沉洞”Token和最近的一段（例如1020个）Token的滑动窗口 ⁴²。通过保留注意力沉洞，为注意力机制提供了一个稳定的“锚点”，使得模型即使在不断有新信息流入、旧信息被丢弃的情况下，也能保持稳定的性能，从而实现对流式数据的处理 ⁴²。

4.2.2 “重磅击球手”预言机（H2O）：基于注意力的驱逐策略

现象发现：H2O（Heavy-Hitter Oracle）基于另一个不同的观察：注意力分数的分布是高度稀疏的，并遵循幂律分布。这意味着，只有一小部分Token，被称为“重磅击球手（Heavy Hitters, H₂）”，在注意力计算中贡献了绝大部分的价值 ⁴⁶。实验证明，移除这些关键的H₂ Token会导致模型性能严重下降 ⁴⁶。
H2O的解决方案：H2O设计了一种动态的KV缓存驱逐策略。它同样维持一个固定大小的缓存，但其保留的内容是最近生成的一小部分Token和根据历史注意力分数识别出的最重要的“重磅击球手”Token ⁴⁷。一个Token的重要性是通过其在过去所有生成步骤中累积的注意力分数来衡量的。与StreamingLLM基于位置的静态策略不同，H2O是一种更具动态性、内容感知的策略。实验表明，仅保留20%的KV缓存（由H₂和近期Token组成），H2O就能在大幅提升吞吐量的同时，保持与原模型相当的准确率 ⁴⁶。

深层分析：缓存中“重要性”的多重维度

“注意力沉洞”和“重磅击球手”这两个现象的并存，揭示了KV缓存中“重要性”并非单一概念，而是具有多重维度：

结构重要性（Structural Importance）：指那些对于注意力机制稳定运作至关重要的Token，即“注意力沉洞”。它们的重要性源于其在序列中的位置（通常是初始位置），即使其本身语义可能为空（如<s>起始符）。
语义重要性（Semantic Importance）：指那些承载了任务关键信息的Token，即“重磅击主手”。它们的重要性源于其内容和上下文（如文档中的一个关键名词或动词）。

现有的驱逐策略各有侧重：一个简单的滑动窗口策略之所以失败，是因为它无差别地驱逐了具有结构重要性的沉洞Token。StreamingLLM通过保留沉洞Token修正了这一点，但仍可能驱逐掉非近期的、具有语义重要性的Token。H2O旨在解决后一个问题，但它需要实时追踪和计算累积注意力分数，实现上更为复杂 ⁵⁰。

更有趣的是，后续研究（如Q-Hitter）发现，被H2O识别为重要的Token，在经过量化后，其重要性可能会发生剧烈变化 ⁴⁸。这引出了第三个维度的重要性：

表示依赖的重要性（Representation-Dependent Importance），即一个Token的重要性还取决于其数值表示的精度（如FP16 vs. INT4）。

因此，一个真正最优的KV缓存驱逐策略，未来可能需要同时建模和平衡这三个维度的重要性：结构稳定性（沉洞）、动态语义价值（重磅击球手）和表示敏感度（量化友好性）。这预示着未来的发展方向将是从简单的启发式规则，走向更复杂的、甚至是可学习的、多维度的驱逐策略。

表3：KV缓存驱逐策略对比分析

下表清晰地对比了主要的驱逐策略，以帮助系统架构师根据具体应用场景（如流式聊天 vs. 长文档分析）做出恰当选择。

策略	核心思想	缓存中保留的内容	内存占用模式	信息丢失风险	理想应用场景
滑动窗口 (Sliding Window)	只保留最近的Token。	k个最新的Token。	恒定大小。	极高。丢失所有长程上下文和结构锚点，导致模型崩溃。	不推荐用于现代LLM。
StreamingLLM	通过保留注意力沉洞来维持结构稳定性。	最初的s个沉洞Token + 最新的k个Token。	恒定大小。	中等。保留了局部上下文，但会丢失非近期的语义上下文。	流式应用、多轮对话，其中近期上下文最为关键。
H2O (Heavy-Hitter Oracle)	通过保留高注意力Token来维持语义重要性。	最新的$k_{recent}个Token+历史上最重要的k_{heavy}$个Token。	恒定大小。	中低。旨在保留语义上重要的Token，但预言机并非完美。	长文档问答、摘要，其中关键信息可能出现在文本的任何位置。

第五节：系统级与混合优化策略

本节将探讨在推理服务器（如vLLM）层面实现的系统级技术，这些技术负责管理KV缓存的存储和处理方式，并常与前述的架构和算法优化相结合。

5.1 PagedAttention：在vLLM中缓解内存碎片

机制：受到操作系统中虚拟内存和分页机制的启发，PagedAttention将KV缓存的内存分配在物理上不连续的块（“页”）中 ²⁰。传统的做法是为每个序列预留一块大的连续内存，这会导致严重的内存碎片问题——如果一个序列没有用满其预留空间，多余的部分就无法被其他序列使用（内部碎片）；同时，即使总空闲内存足够，也可能因为没有足够大的连续块而无法服务新请求（外部碎片）。PagedAttention通过将序列的逻辑KV缓存块映射到物理上的非连续内存页，完美解决了这个问题。

收益：PagedAttention能够实现近乎100%的内存利用率，从而在同等硬件上支持更大的批处理规模和更高的系统吞吐量。此外，它灵活的内存管理方式也为实现更高级的调度策略（如持续批处理，Continuous Batching）奠定了基础 ²⁰。

5.2 卸载策略：利用CPU和CXL内存

机制：当GPU显存（VRAM）耗尽时，可以将KV缓存的全部或部分内容“卸载”（Offload）到主机系统容量更大但速度较慢的CPU内存（DRAM）中 ¹⁶。当需要访问被卸载的缓存时，再将其重新加载回GPU。

新兴硬件：计算快递链接（Compute Express Link, CXL）是一种新兴的高速互联标准，它允许服务器通过PCIe接口连接额外的DRAM内存模块。CXL内存提供了介于高速GPU HBM和低速CPU DRAM之间的性能层级。研究表明，将KV缓存存储在CXL内存上，可以显著降低对GPU的需求（最高可达87%），并大幅提升系统吞-吐量 ⁵²。

权衡：这是一种典型的以延迟换容量的策略。数据在GPU和主机内存之间传输的带宽（由PCIe或CXL总线决定）成为了新的性能瓶颈 ¹⁶。

5.3 分离式推理：解耦Prefill和Decode硬件

机制：鉴于Prefill（计算密集型）和Decode（内存带宽密集型）阶段迥异的计算特性，像DistServe这样的系统提出了将它们彻底分离的架构 ¹⁵。在这种设计中，Prefill和Decode任务被分配到不同的、专门的GPU集群中处理。

收益：

消除干扰：彻底解决了两种任务混合部署时的性能干扰问题，允许各自的延迟（TTFT和TPOT）得到独立保障。
资源专用化：可以为每个阶段选择最适合的硬件。例如，Prefill集群可以部署计算能力强（高TFLOPS）的GPU，而Decode集群可以部署内存带宽大（高GB/s）的GPU。
独立扩展：可以根据应用负载的特点（例如，长提示短生成 vs. 短提示长生成）独立地扩展Prefill或Decode集群的规模。
实验表明，与混合部署相比，分离式推理系统可以实现高达2.1倍的吞吐量提升 17。

5.4 整体视角：优化技术的叠加效应

理解这些优化技术的关键在于，它们并非相互排斥，而是可以构成一个强大、多层次的优化栈。一个顶尖的LLM推理系统通常会协同运用多种技术，形成复合效应。

一个典型的先进部署方案可能如下：

架构层：选择一个本身就采用GQA架构预训练的模型，从源头上减少KV缓存的生成量。
系统层：在像vLLM这样的推理服务器上部署该模型，利用其内置的PagedAttention机制实现高效的GPU内存管理。
算法层：对于需要处理超长或流式上下文的应用，启用一种缓存驱逐策略，如StreamingLLM或H2O，以保持缓存大小恒定。
压缩层：为了在有限的缓存预算内存储更多信息，或进一步扩展上下文长度，启用FP8或INT4的KV缓存量化。
硬件/集群层：为了应对海量并发和峰值负载，将整个服务部署在分离式推理集群上，并可能利用CXL内存卸载来处理超出GPU显存容量的请求。

这种层层叠加的优化策略清晰地表明，现代LLM推理优化是一个贯穿从模型架构设计到硬件互联的全栈工程问题。任何单一层面的优化都无法达到极致性能，只有将这些技术有机结合，才能构建出既高效又经济的大规模AI服务。

第六节：范式转移：使用状态空间模型的无缓存架构

本节将探讨一种颠覆性的替代方案，它通过完全不同的架构设计，从根本上规避了KV缓存问题，为未来发展提供了新的视角。

6.1 Mamba简介：选择性状态空间模型（SSM）

Transformer的核心问题：Transformer的注意力机制是无状态的。为了理解上下文，它必须在每一步都显式地回顾（Attend to）所有之前的Token。这种机制催生了KV缓存，但也带来了其固有的缺陷：推理时内存占用随序列长度线性增长（O(N)），训练时计算复杂度随序列长度二次方增长（O(N2)） ⁵³。

Mamba的解决思路：Mamba是一种基于状态空间模型（State Space Model, SSM）的新型架构，它本质上是一种循环网络（RNN）的现代变体 ⁵⁴。与Transformer不同，Mamba以线性方式处理序列，并将整个历史信息压缩到一个固定大小的**隐藏状态（hidden state）

h**中 ⁵³。

“选择性”创新：传统RNN的局限在于其状态转换矩阵是固定的，难以有效处理长距离依赖。Mamba的核心创新在于引入了“选择性”机制：其状态转换矩阵（在SSM理论中表示为A,B,C等矩阵）不再是静态参数，而是输入数据的函数 ⁵⁴。这意味着Mamba可以根据当前输入动态地、有选择地决定要从历史状态中“遗忘”什么，以及要从当前输入中“记忆”什么。这种选择性赋予了Mamba媲美Transformer的强大建模能力，同时又避免了其二次方复杂度的瓶颈 ⁵³。

6.2 循环状态：Mamba如何实现O(1)推理内存

无KV缓存：Mamba的推理过程与Transformer截然不同。它不需要一个随序列长度增长的KV缓存。在生成每个新Token时，Mamba仅需要维持其紧凑的、固定大小的隐藏状态h。其工作流程是：接收当前状态ht和新输入xt+1，计算出下一个状态$h_{t+1}$和输出$y_{t+1}$，然后旧状态ht就可以被丢弃。因此，无论序列有多长，其推理过程中的内存占用始终是恒定的（O(1)） ⁵⁶。

线性时间复杂度：这种循环的、逐个处理Token的方式也意味着Mamba的推理时间与序列长度成线性关系（O(N)），相比于需要加载越来越大的KV缓存的Transformer解码过程，具有显著的速度优势，尤其是在长序列场景下 ⁵³。

6.3 当前能力与局限性 vs. Transformer

优势：

长程依赖与效率：Mamba在需要处理长距离依赖的任务上表现出色，并且在处理长序列时，其推理速度和内存效率远超Transformer ⁵³。它已在基因组学、音频等信息密集型序列建模领域展现出最先进的性能 ⁵⁴。
高吞吐量：由于无需处理庞大的KV缓存，Mamba的推理吞吐量可达同等规模Transformer的5倍之多 ⁵⁶。

劣势：

上下文学习能力：目前的研究表明，Transformer在少样本（Few-shot）的上下文学习（In-context Learning）任务上表现更优 ⁵⁴。这类任务要求模型能精确地从提示中复制或推理信息。Transformer的KV缓存机制，本质上是一种高保真的“
外部逐字记忆（External Verbatim Memory）”，使其能够近乎完美地回忆上下文中的细节。
压缩状态的权衡：相比之下，Mamba的固定大小隐藏状态更像是一种有损压缩的“内部要点记忆（Internal Gist Memory）”。它擅长捕捉序列的整体动态和核心信息，但在精确回忆任意历史细节方面能力较弱 ⁵⁹。

架构权衡与未来展望：

Transformer与Mamba之间的选择，体现了模型架构在记忆保真度与运行效率之间的根本性权衡。Transformer以高昂的计算和内存成本，换取了高保真的上下文访问能力；而Mamba则以牺牲部分精确回忆能力为代价，换取了极致的运行效率和处理无限长序列的潜力。

未来的AI智能体设计，可能不会是二选一的局面，而是走向混合架构（Hybrid Models） ⁵⁹。一种可能的方向是，利用Mamba的高效性来处理和压缩漫长的对话历史或海量背景文档，形成一个概要性的“记忆状态”；然后，将这个状态与一小段最关键的、需要精确推理的当前上下文，一同输入到一个小窗口的注意力模块中进行精细处理。这样的混合模型，有望兼具Mamba的长程处理效率和Transformer的精确推理能力，为构建更强大、更高效的AI系统开辟新的道路。

第七节：架构师综合指南与建议

本节旨在将报告中的技术分析转化为一套面向AI系统架构师的实用、可操作的综合指南，帮助其在复杂的优化选项中做出明智决策。

7.1 KV缓存优化决策框架

为了系统性地选择最适合的KV缓存优化策略组合，架构师可以遵循以下决策框架，通过回答一系列关键问题来明确需求和约束：

问题1：您的主要性能瓶颈是什么？

A. 内存容量（GPU显存不足）：这是最常见的瓶颈，尤其是在处理长上下文或高并发时。
- 首要策略：
  1. 架构选择：优先选用基于GQA架构的模型，这是最根本的内存节省方式 ²⁶。
  2. 量化：应用KV缓存量化（如FP8或INT4），可直接将缓存大小减半或更多，是扩展上下文长度最有效的方法之一 ¹⁹。
  3. 系统管理：采用PagedAttention（如vLLM）来最大化内存利用率，避免碎片化浪费 ²⁰。
B. 延迟（TTFT或TPOT过高）：对于交互式应用，低延迟至关重要。
- 首要策略：
  1. 架构选择：MQA/GQA通过减少内存带宽需求，能显著降低TPOT ²⁸。
  2. 硬件/部署：考虑分离式推理，将计算密集的Prefill和内存带宽密集的Decode分配到不同硬件上，可同时优化TTFT和TPOT ¹⁵。
  3. 驱逐策略：H2O等策略通过减小有效缓存大小，也能降低每次解码的内存读取量，从而降低TPOT ⁴⁶。
C. 吞吐量（系统总处理能力不足）：目标是最大化单位成本下的处理能力。
- 首要策略：
  1. 所有内存优化策略：任何能减少单个请求内存占用的技术（GQA、量化、驱逐）都能让系统支持更大的批处理规模，从而直接提升吞吐量。
  2. 系统管理：PagedAttention和持续批处理是最大化GPU利用率、提升吞吐量的关键系统技术 ²⁰。
  3. 卸载：在负载高峰期，使用CXL内存卸载可以临时增加系统容量，维持高吞吐率 ⁵²。

问题2：您的应用场景的上下文模式是怎样的？

A. 交互式对话（如聊天机器人）：上下文持续增长，但近期信息最重要。
- 推荐组合：GQA模型 + StreamingLLM + PagedAttention。StreamingLLM的“注意力沉洞+近期窗口”策略完美契合该场景，能以恒定内存处理无限轮对话，同时PagedAttention保证高并发下的吞吐量 ⁶⁰。
B. 长文档分析（如问答、摘要）：需要访问文档中任何位置的关键信息。
- 推荐组合：GQA模型 + H2O + 量化 + PagedAttention。H2O的“重磅击球手”机制旨在保留整个文档中的语义关键点，比StreamingLLM更适合此类任务。量化是支持超长文档上下文的必要手段 ⁴⁶。
C. 流式数据处理（如实时监控）：数据流无限，且模型需要持续运行。
- 推荐组合：StreamingLLM是为此类场景设计的理想选择 ⁴³。如果对历史模式有要求，可考虑H2O。如果性能要求极致，可以探索
  Mamba架构，它天然适合流式处理 ⁵⁶。

问题3：您的硬件环境和模型选择自由度如何？

A. 硬件受限（如单张消费级GPU）：
- 策略：必须采取最激进的内存优化。GQA模型 + INT4/FP8量化 + StreamingLLM/H2O是必选项。
B. 拥有多GPU服务器/集群：
- 策略：可以探索更复杂的部署模式。张量并行与GQA结合，并考虑分离式推理来最大化集群效率。
C. 可影响模型选择：
- 策略：在项目启动阶段，就应将KV缓存效率作为核心指标。强烈建议选择原生支持GQA的现代模型，而不是试图优化老旧的MHA模型。对于需要处理极长序列的全新应用，评估Mamba等非Transformer架构的潜力。

7.2 上下文感知系统的未来：学习型策略与混合模型

LLM推理优化的前沿正在从静态的、基于启发式规则的策略，向更动态、更智能的自适应系统演进。

学习型驱逐策略：未来的KV缓存管理将不再依赖固定的规则（如保留前4个Token）。取而代之的将是可学习的驱逐策略。例如，Q-Hitter的工作已经表明，一个Token的重要性不仅取决于其注意力分数，还取决于其对量化的敏感度 ⁴⁸。未来的系统可能会训练一个小型“策略网络”，实时决策哪些Token应该被保留、压缩或驱逐，以在给定的硬件和延迟预算下最大化模型性能。
混合架构模型：Transformer和Mamba的根本性权衡（高保真记忆 vs. 高效压缩记忆）预示着混合模型的巨大潜力 ⁵⁹。未来的智能体架构可能会包含一个Mamba“主干”，负责高效地处理和压缩海量的、非结构化的历史上下文，形成一个紧凑的“世界模型”状态。然后，当需要进行精确的、多步的逻辑推理时，系统会将这个压缩状态和一小部分最关键的上下文（如当前的用户指令和工具输出）送入一个高保真的注意力模块中进行处理。这种架构有望实现“两全其美”：既能“博闻”，又能“强识”。

7.3 结论：以缓存为中心的设计思想的持久重要性

本报告从manus.im博文的一个核心洞察出发——上下文工程在实践中等同于KV缓存工程——并对其背后的技术栈进行了系统性的深入剖析。分析表明，随着AI模型的能力日益强大，支撑其运行的系统工程正成为决定其应用成败的关键差异化因素。

从GQA成为预训练标准，到StreamingLLM和H2O等精巧的驱逐算法，再到PagedAttention和分离式推理等系统级创新，整个技术生态都在围绕着同一个核心问题演进：如何高效地管理和利用有限的KV缓存资源。

对于AI系统架构师而言，这意味着必须转变观念。为缓存而设计（Designing for the cache），不再是一项部署阶段的底层优化，而是构建高性能、可扩展且经济可行的AI智能体系统的基本设计原则。一个智能体能够有效利用的上下文边界，最终是由其底层系统能够高效管理的缓存边界所决定的。在通往更强大通用智能的道路上，我们能工程化的上下文，就是我们能缓存的一切。

引用的著作

What Is Context Engineering in AI? Techniques, Use Cases, and Why It Matters, 访问时间为七月 21, 2025， https://www.marktechpost.com/2025/07/06/what-is-context-engineering-in-ai-techniques-use-cases-and-why-it-matters/
arxiv.org, 访问时间为七月 21, 2025， https://arxiv.org/html/2507.13334v1#:~:text=Abstract%3A%20The%20performance%20of%20Large,of%20information%20payloads%20for%20LLMs.
What is Context Engineering, Anyway? - Zep, 访问时间为七月 21, 2025， https://blog.getzep.com/what-is-context-engineering/
Why Context Engineering Is Redefining How We Build AI Systems, 访问时间为七月 21, 2025， https://ai-pro.org/learn-ai/articles/why-context-engineering-is-redefining-how-we-build-ai-systems/
Context Engineering: From Pitfalls to Proficiency in LLM Performance - Generative AI, 访问时间为七月 21, 2025， https://generativeai.pub/context-engineering-from-pitfalls-to-proficiency-in-llm-performance-acc0b2c5ec1d
What Is Context Engineering? The Missing Layer Between Prompts and Performance, 访问时间为七月 21, 2025， https://medium.com/@prajnaaiwisdom/what-is-context-engineering-the-missing-layer-between-prompts-and-performance-fe4a729666fe
Context Engineering for AI Agents: Lessons from Building Manus, 访问时间为七月 21, 2025， https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
A Survey on Large Language Model Acceleration based on KV Cache Management - arXiv, 访问时间为七月 21, 2025， https://arxiv.org/html/2412.19442v2
[2407.18003] Keep the Cost Down: A Review on Methods to Optimize LLM’ s KV-Cache Consumption - arXiv, 访问时间为七月 21, 2025， https://arxiv.org/abs/2407.18003
AI Optimization Lecture 01 - Prefill vs Decode - Mastering LLM Techniques from NVIDIA, 访问时间为七月 21, 2025， https://www.youtube.com/watch?v=3SBUCJzogj4
LLM Inference Performance Engineering: Best Practices | Databricks Blog, 访问时间为七月 21, 2025， https://www.databricks.com/blog/llm-inference-performance-engineering-best-practices
All About Transformer Inference | How To Scale Your Model - GitHub Pages, 访问时间为七月 21, 2025， https://jax-ml.github.io/scaling-book/inference/
Mastering LLM Techniques: Inference Optimization | NVIDIA Technical Blog, 访问时间为七月 21, 2025， https://developer.nvidia.com/blog/mastering-llm-techniques-inference-optimization/
A guide to LLM inference and performance | Baseten Blog, 访问时间为七月 21, 2025， https://www.baseten.co/blog/llm-transformer-inference-guide/
DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving - arXiv, 访问时间为七月 21, 2025， https://arxiv.org/html/2401.09670v1
Efficient LLM Inference with KCache - arXiv, 访问时间为七月 21, 2025， https://arxiv.org/html/2404.18057v1
DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving - USENIX, 访问时间为七月 21, 2025， https://www.usenix.org/system/files/osdi24-zhong-yinmin.pdf
LLM Inference Series: 4. KV caching, a deeper look | by Pierre Lienhart | Medium, 访问时间为七月 21, 2025， https://medium.com/@plienhar/llm-inference-series-4-kv-caching-a-deeper-look-4ba9a77746c8
Unlocking Longer Generation with Key-Value Cache Quantization - Hugging Face, 访问时间为七月 21, 2025， https://huggingface.co/blog/kv-cache-quantization
Techniques for KV Cache Optimization in Large Language Models - omrimallis, 访问时间为七月 21, 2025， https://www.omrimallis.com/posts/techniques-for-kv-cache-optimization/
Transformer Inference Arithmetic | kipply’s blog, 访问时间为七月 21, 2025， https://kipp.ly/transformer-inference-arithmetic/
KV Cache is huge and bottlenecks LLM inference. We quantize them to 2bit in a finetuning-free + plug-and-play fashion. - Reddit, 访问时间为七月 21, 2025， https://www.reddit.com/r/LocalLLaMA/comments/1ap3bkt/kv_cache_is_huge_and_bottlenecks_llm_inference_we/
KV Caching in LLMs, explained visually - Daily Dose of Data Science, 访问时间为七月 21, 2025， https://www.dailydoseofds.com/p/kv-caching-in-llms-explained-visually/
Demystifying GQA - Grouped Query Attention for Efficient LLM Pre-training, 访问时间为七月 21, 2025， https://towardsdatascience.com/demystifying-gqa-grouped-query-attention-3fb97b678e4a/
arXiv:2502.07864v2 [cs.LG] 13 Feb 2025, 访问时间为七月 21, 2025， https://arxiv.org/pdf/2502.07864?
Grouped Query Attention (GQA) vs. Multi Head Attention (MHA): Optimizing LLM Inference Serving | by FriendliAI Tech & Research - Medium, 访问时间为七月 21, 2025， https://medium.com/friendliai/grouped-query-attention-gqa-vs-multi-head-attention-mha-optimizing-llm-inference-serving-eaa732beaeac
GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints, 访问时间为七月 21, 2025， https://arxiv.org/html/2305.13245v3
arXiv:2305.13245v3 [cs.CL] 23 Dec 2023, 访问时间为七月 21, 2025， https://arxiv.org/pdf/2305.13245
Core Strategies for Optimizing the KV Cache | by M | Foundation Models Deep Dive, 访问时间为七月 21, 2025， https://medium.com/foundation-models-deep-dive/kv-cache-guide-part-3-of-5-optimizing-the-beast-core-strategies-for-a-leaner-kv-cache-a73df2dee6a7
What is Grouped Query Attention (GQA)? - Klu.ai, 访问时间为七月 21, 2025， https://klu.ai/glossary/grouped-query-attention
Multi-Query Attention (MQA) - Tinkerd, 访问时间为七月 21, 2025， https://tinkerd.net/blog/machine-learning/multi-query-attention/
How KV Cache Works & Why It Eats Memory | by M | Foundation Models Deep Dive, 访问时间为七月 21, 2025， https://medium.com/foundation-models-deep-dive/kv-cache-guide-part-2-of-5-under-the-hood-how-kv-cache-works-why-it-eats-memory-f37abf8ea13b
GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints | Cool Papers - Immersive Paper Discovery, 访问时间为七月 21, 2025， https://papers.cool/arxiv/2305.13245
Weighted Grouped Query Attention in Transformers - arXiv, 访问时间为七月 21, 2025， https://arxiv.org/html/2407.10855v1
Accelerating LLM Inference with efficient Self-Attention — MQA, GQA, MLA(DeepSeek), Adaptive KV Caching | by Sauradeep Debnath | GoPenAI, 访问时间为七月 21, 2025， https://blog.gopenai.com/accelerating-llm-inference-with-efficient-self-attention-mqa-gqa-mla-deepseek-adaptive-kv-2bb48c14e798
[2407.10855] Weighted Grouped Query Attention in Transformers - arXiv, 访问时间为七月 21, 2025， https://arxiv.org/abs/2407.10855
[2406.14963] Optimised Grouped-Query Attention Mechanism for Transformers - arXiv, 访问时间为七月 21, 2025， https://arxiv.org/abs/2406.14963
Reducing Transformer Key-Value Cache Size with Cross-Layer Attention - OpenReview, 访问时间为七月 21, 2025， https://openreview.net/pdf?id=M2UzLRoqic
Reducing Transformer Key-Value Cache Size with Cross-Layer Attention - arXiv, 访问时间为七月 21, 2025， https://arxiv.org/html/2405.12981v1
KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization - arXiv, 访问时间为七月 21, 2025， https://arxiv.org/html/2401.18079v4
Arxiv Dives - Efficient Streaming Language Models with Attention Sinks | Oxen.ai, 访问时间为七月 21, 2025， https://www.oxen.ai/blog/arxiv-dives-efficient-streaming-language-models-with-attention-sinks
Efficient Streaming Language Models with Attention Sinks - arXiv, 访问时间为七月 21, 2025， https://arxiv.org/html/2309.17453v3
Efficient Streaming Language Models with Attention Sinks - MIT HAN Lab, 访问时间为七月 21, 2025， https://hanlab.mit.edu/projects/streamingllm
[2309.17453] Efficient Streaming Language Models with Attention Sinks - arXiv, 访问时间为七月 21, 2025， https://arxiv.org/abs/2309.17453
Attention Sinks in LLMs for endless fluency - Hugging Face, 访问时间为七月 21, 2025， https://huggingface.co/blog/tomaarsen/attention-sinks
H 2 _2 O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models, 访问时间为七月 21, 2025， https://www.researchgate.net/publication/371871295_H_2O_Heavy-Hitter_Oracle_for_Efficient_Generative_Inference_of_Large_Language_Models
H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models - NIPS, 访问时间为七月 21, 2025， https://proceedings.neurips.cc/paper_files/paper/2023/file/6ceefa7b15572587b78ecfcebb2827f8-Paper-Conference.pdf
Q-Hitter: A Better Token Oracle for Efficient LLM Inference via Sparse-Quantized KV Cache - MLSys Proceedings, 访问时间为七月 21, 2025， https://proceedings.mlsys.org/paper_files/paper/2024/file/bbb7506579431a85861a05fff048d3e1-Paper-Conference.pdf
arxiv.org, 访问时间为七月 21, 2025， https://arxiv.org/html/2306.14048v3
[Feature]: H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models · Issue #3532 · vllm-project/vllm - GitHub, 访问时间为七月 21, 2025， https://github.com/vllm-project/vllm/issues/3532
Dialogue Without Limits: Constant-Sized KV Caches for Extended Responses in LLMs, 访问时间为七月 21, 2025， https://arxiv.org/html/2503.00979v1
Exploring CXL-based KV Cache Storage for LLM Serving - ML For Systems, 访问时间为七月 21, 2025， https://mlforsystems.org/assets/papers/neurips2024/paper17.pdf
Mamba Explained - Pelayo Arbués, 访问时间为七月 21, 2025， https://www.pelayoarbues.com/literature-notes/Articles/Mamba-Explained
Mamba Explained - The Gradient, 访问时间为七月 21, 2025， https://thegradient.pub/mamba-explained/
What Is A Mamba Model? | IBM, 访问时间为七月 21, 2025， https://www.ibm.com/think/topics/mamba-model
The Mamba in the Llama: Distilling and Accelerating Hybrid Models - Together AI, 访问时间为七月 21, 2025， https://www.together.ai/blog/the-mamba-in-the-llama-distilling-and-accelerating-hybrid-models
Why bother with RWKV/Mamba instead of decoder transformers? : r/LocalLLaMA - Reddit, 访问时间为七月 21, 2025， https://www.reddit.com/r/LocalLLaMA/comments/1hs3966/why_bother_with_rwkvmamba_instead_of_decoder/
VL-Mamba: Exploring State Space Models for Multimodal Learning - arXiv, 访问时间为七月 21, 2025， https://arxiv.org/pdf/2403.13600
Mamba(2) and Transformer Hybrids: An Overview - Data Artificer and code:Breaker, 访问时间为七月 21, 2025， https://n1o.github.io/posts/ssm-transformer-hybrids-guide/
mit-han-lab/streaming-llm: [ICLR 2024] Efficient Streaming Language Models with Attention Sinks - GitHub, 访问时间为七月 21, 2025， https://github.com/mit-han-lab/streaming-llm
Q-Hitter - TUE Research portal, 访问时间为七月 21, 2025， https://research.tue.nl/files/348856921/MLSys-2024-q-hitter-a-better-token-oracle-for-efficient-llm-inference-via-sparse-quantized-kv-cache-Paper-Conference.pdf

人工智能 > 大语言模型推理优化

#上下文工程 #KV缓存 #推理机制 #内存占用 #TTFT #TPOT #多头注意力（MHA） #多查询注意力（MQA） #分组查询注意力（GQA） #量化 #稀疏化 #StreamingLLM #H2O #PagedAttention #卸载策略 #分离式推理 #Mamba

上下文即缓存：面向高性能AI智能体的KV缓存优化技术报告

https://ai123.win/2025/07/21/上下文即缓存：面向高性能AI智能体的KV缓存优化技术报告/

作者

AIs

发布于

2025年7月21日

许可协议

引力的拥抱：潮汐锁定全面指南，从我们的月球到外星世界上一篇

二甲双胍：一种多效性药物的全面综述——从血糖控制到老年防护下一篇