TensorRT-LLM 源码完全拆解（七）：KV Cache 的内存布局与量化存储——NHD/HND、FP8 scale 与 MLA latent 池如何决定内核访存

系列进度与本篇定位

前六篇把 TensorRT-LLM 的推理路径从服务入口一路读到了注意力内核门口。第一篇建立仓库地形；第二篇走完 create_py_executor 装配线与 PyExecutor 的单步闭环；第三篇钻进调度器的准入算术与微批选择；第四篇打开 KV 账本，讲清 KVCacheManager 的两级池、块表构造与前缀复用树；第五篇讲 PyTorchModelEngine 如何把动态请求拼成静态形状的输入缓冲；第六篇进入注意力后端，看 AttentionMetadata.prepare() 如何把块句柄翻成各后端要的块表、页索引与块偏移数组。

第六篇结尾留下一个明确的口子：那一篇讲的所有索引数组——paged_kv_indices、kv_cache_block_offsets、kv_block_ids_per_seq——都只是块的编号或偏移，它们最终都要乘上 stride 才能变成显存地址。而 stride 从哪来？取决于块池在显存里到底怎么排。这一篇补的就是这一段：KV 池的物理布局、K/V 分池还是合池、NHD 与 HND 两种维序的 stride 差异如何决定内核的访存模式、量化缓存（FP8/INT8）的数值怎么存、scale 因子放在哪里、以及 MLA 的 latent 池为什么只有一份张量却要同时满足 K 和 V 的读取。

这里要回答五个问题：

• 第四篇说块是”固定大小的页”，那这一页在显存里到底是几个张量、几维、什么维序？为什么同一个模型在 Hopper 和 Blackwell 上可能用不同的维序？
• FP8/INT8 的 KV 缓存，一个 token 的 K 向量只占原来一半甚至四分之一的空间，那 scale 因子（缩放系数）存在哪？为什么不能简单地”存 int8 再乘回来”？
• 常量缩放（per-tensor scale）与逐 token / 逐头缩放（per-token-head scale）在精度和访存上各付什么代价？内核要不要为它们走不同的路径？
• 滑动窗口与多池（VSWA）下，块池是怎么切分的？为什么 Gemma 这类模型必须分池？
• MLA（Multi-head Latent Attention）的 KV 缓存为什么只有一份 latent 张量，却能同时扮演 K 和 V？它和普通 GQA 的缓存布局差在哪？

池的形状：一个张量装下所有层

第六篇结尾的那个”乘法”的答案藏在 C++ 侧的 KVCacheBlockPool 结构里。先把它的字段读出来：

上图把本篇的核心要素画在一起：池的六个维度各代表什么、HND 与 NHD 下同一个头的第 $t$ 个 token 偏移如何换算、以及 MLA 如何只靠改三个参数就复用同一套容器。数据来源：TensorRT-LLM 源码 cpp/include/tensorrt_llm/batch_manager/kvCacheManager.h（池形状与 KVCacheBlockPool 注释）与 DeepSeek-V2 技术报告（MLA 的 $d_c$ 取值）。

1
class KVCacheBlockPool
2
{
3
public:
4
    SizeType32 numLayers;     // 共享这个池的层数
5
    SizeType32 kvFactor;      // K/V 因子：通常 2，MLA 为 1
6
    SizeType32 numKvHeads;    // 该池的 KV 头数（GQA 之后）
7
    SizeType32 sizePerHead;   // 每头维度 head_dim
8
    SizeType32 tokensPerBlock;// 一个块装多少 token（页大小，2 的幂）
9
    SizeType32 blockSize;     // = numKvHeads * sizePerHead * tokensPerBlock
10

11
    runtime::ITensor::SharedPtr primaryPtr;    // 快存储（显存）
12
    runtime::ITensor::SharedPtr secondaryPtr;  // 慢存储（宿主，用于卸载）
13

14
    bool containsBlockScales;      // FP4 缓存的第二级 scale 池
15
    bool containsIndexerKCache;    // 稀疏注意力的索引器 K 缓存（DSA 这类）
16
    bool layerFirstLayout;         // 线性注意力的循环状态用 {layers, blocks, ...} 排布
17
};

这个结构本身就是一篇文章的提纲。先看最反直觉的一条：一个池张量装下了所有层。WindowBlockManager 的注释写得很清楚：

1
Each pool has shape [max_blocks, num_layers, 2, num_kv_heads, tokens_per_block, head_size],
2
where num_layers refers to the number of layers with the same num_kv_heads that share that pool.

也就是说，池张量是六维的，第二维是层。为什么会这样设计？

原因是：块的元数据是所有层共享的。注释里接着说：“The metadata of KVCacheBlocks is shared between layers, so each block spans all of the managed pool”。第四篇讲的块句柄（block id）是一个全局整数，它不对应某一层，而对应每个池里的同一段偏移。当你为一条请求分配块 17，意味着第 0 层、第 1 层……第 numLayers-1 层的这个位置都归你了。这样前缀复用树、空闲队列、引用计数只需要维护一套块编号，而不是每层一套——账本复杂度从 $O(\text{layers} \times \text{blocks})$ 降到 $O(\text{blocks})$。

代价是分池的粒度必须由层间差异决定：只有 KV 头数相同、注意力窗口大小相同的层，才能塞进同一个池。一旦某个模型的层不满足这个条件，就必须拆池。

1
blocks_in_primary_pool = int(max_tokens // tokens_per_block)

NHD 与 HND：同一个池的两种维序

池张量里还有一个维度没讲：tokens_per_block 和 head_dim 谁在前。interface.py 把这个选择显式暴露成 kv_layout：

1
# Paged KV-cache block layout:
2
# NHD: [max_num_pages, 2, page_size, num_kv_heads, head_dim]
3
# HND: [max_num_pages, 2, num_kv_heads, page_size, head_dim]
4
kv_layout: Literal["NHD", "HND"] = "HND"

注意默认值是 HND。N 是 token 数（page size 那一维），H 是 KV 头数，D 是 head_dim。两种排法意味着同一个块的字节内容在显存里以完全不同的顺序排列。

要理解这个差异为什么重要，得回到内核的访存模式。注意力内核在解码阶段做的是：对当前这一个 query token，遍历 KV 序列里所有历史 token，逐个算 $q \cdot k$。它会以头为单位切分工作：每个 warp / 每个线程块负责若干个头，沿着序列方向滑动。

• HND 布局下，同一个头的连续 token 在显存里是相邻的（[head, token, dim]）。内核处理某个头时，读出来的是一段连续内存，天然满足合并访存（coalesced access），L2 命中率高，还可以直接向量化读取（一次读 16 字节 = 8 个 BF16 元素）。
• NHD 布局下，连续 token 之间隔着 num_kv_heads × head_dim 个元素（[token, head, dim]）。同一个头跨 token 读的时候，步长是散的。

上图是 FlashInfer 官方教程给出的分页 KV 布局示意。它画的是逻辑页到物理页的映射这一层——也就是第六篇讲的页表三件套（paged_kv_indices / paged_kv_indptr / paged_kv_last_page_len）承担的工作；而本篇要补的是再往下一层：一个物理页内部的元素如何排列。两者叠起来才构成完整的地址换算。图片来源：FlashInfer 官方文档 KV-Cache Layout。

那为什么还要保留 NHD？两个原因。第一，prefill 阶段的访存模式相反：预填充要处理整段序列的 token，写 KV 时是按 token 顺序生成的，NHD 让”一条 token 的 K 和 V 挨在一起”，写入更连续；许多 FlashAttention 风格的内核与 FlashInfer 的页表约定就是按 NHD 组织的。第二，兼容性与历史：早期内核、部分量化内核、以及 MLA 的 latent 表示是按 NHD 写就的。所以这不是”哪个更先进”，而是哪个更匹配当前内核的访存模式。

第六篇讲过 VanillaAttention 后端把 kv_layout 写死成 "NHD"（vanilla_attn.py 第 68 行：self.kv_layout = "NHD"）。FlashInfer 后端则两种都支持，并且把差异表达成一行”轴位置”判断——这是整个代码库里对维序语义最短的注释：

1
def _slice_paged_kv_cache_heads(
2
    paged_kv_cache, start, end, kv_layout,
3
):
4
    if kv_layout == "HND":
5
        head_axis = 2
6
    elif kv_layout == "NHD":
7
        head_axis = 3
8
    else:
9
        raise ValueError(f"Unsupported kv_layout: {kv_layout}")
10
    ...

同一个语义（“切出前 $k$ 个头”）在两种维序下对应张量的不同轴：HND 是第 2 轴，NHD 是第 3 轴。这个函数在解析布局时必须两个分支都写，因为它拿到的是运行期才知道的 metadata.kv_layout（第 2710 行传的就是这个值）。而 TrtllmAttentionMetadata 契约里的默认值是 "HND"，FlashInfer 侧若干辅助函数的签名默认则是 "NHD"。同一个框架里两种默认值并存，说明维序是后端内核的选择而非框架强制的约定——换个后端，池的维序契约就跟着换，而所有按轴索引的辅助函数都得跟着分叉。

把两种维序的 stride 列在一起，可以看出它们各自服务于谁：

表里最重要的一行是第一行：HND 下”下一个 token”只隔 headDim 个元素，NHD 下要隔 numKvHeads × headDim 个。以 8 个 KV 头、headDim = 128 为例，前者步长 128 个元素（256 字节 @BF16），后者步长 1024 个元素（2048 字节）。注意力是”沿序列方向反复读”的循环，步长越小，cache line 利用率越高、预取越有效——这就是解码阶段 HND 占优的算术原因。而第二行反过来：NHD 下”同一个 token 的不同头”是相邻的，内核按 token 组织写入（一次写整条 K 和 V）时更连续。

没有一种布局对所有人最优，只有”匹配当前内核访存模式”的布局。 这也是为什么这篇反复强调维序是契约字段：它把一个纯性能决策提升成了正确性接口。

这里有一个非常容易踩的坑：kv_layout 一变，第六篇里的所有索引数组的含义都要重解释。paged_kv_indices 给出的块编号本身不变（它指向哪个块），但”块内第 i 个 token 在哪”要乘的 stride 变了。如果后端和池的维序不一致，读到的就不是同一个 token 的 KV——不会报错，只会算错。这也是为什么维序必须作为契约字段显式声明，而不能由各方”约好”。

量化存储：FP8 / INT8 / NVFP4 缓存怎么放

前面两节讲的都是布局。现在讲存什么类型。官方文档把这一步的重要性说得很直白：

Perhaps the most important property is dtype which specifies what data type is held in KV cache.

在 KvCacheConfig 里把 dtype 设成 'fp8' 或 'nvfp4' 就能切换缓存的数值类型。这里必须讲清楚一个容易被误解的点：KV 缓存量化与权重/激活量化是三条独立的线。模型权重可以是 FP8 而 KV 缓存仍是 BF16；反过来一个没有做量化感知训练的 checkpoin，也可以手动把 KV 缓存设成 FP8（文档专门加了一条 Note 说明这件事）。

1
[[nodiscard]] SizeType32 getNumEltsPerContainer() const
2
{
3
#ifdef ENABLE_FP4
4
    return mDataType == tensorrt_llm::DataType::kFP4 ? 2 : 1;
5
#else
6
    return 1;
7
#endif
8
}

1
// FP4 KV caches allocate additional pools for block scale factors. These pools have the same
2
// shape as the regular KV pools, except that the last dim is head_size / N where N is determined
3
// by the precise FP4 format being used (16 for NVFP4). There is one block scale pool per normal pool.

稀疏与索引器缓存：在同一个池体系里多挂一条

C++ 结构里还有一个字段：containsIndexerKCache，以及构造参数里的 indexerKCacheQuantBlockSize、indexerKCacheIndexHeadDim、indexerKCacheUseFp4、indexerKCacheLayerMask。这对应 DeepSeek-V3.2 的 DSA（DeepSeek Sparse Attention）那类两级注意力：先用一个轻量的索引器（indexer）算出每个历史 token 的分数，选出 Top-K，再用真正的注意力只在选中的 token 上算。

问题是：索引器要打分，就得自己有一份 K（通常是低维、低精度的投影）。如果索引器每次重算这份 K，开销就抵消了稀疏带来的收益。所以 TensorRT-LLM 把索引器的 K 缓存也做成了一个池，挂在同一套块管理下。

注意它的参数配置很讲究：

• indexerKCacheQuantBlockSize = 128：索引器 K 自己的量化块大小（和主池的 tokensPerBlock 是两回事）。
• indexerKCacheIndexHeadDim：索引器 K 的维度，独立配置，通常远小于主 head_dim。
• indexerKCacheUseFp4：索引器 K 是否用 FP4 —— 打分只需要相对大小，精度要求低。
• indexerKCacheLayerMask：哪些层需要索引器 K。这是个 vector<bool>，因为稀疏注意力往往只加在部分层上，没必要为全模型都开这条池。

这四件事合起来说明一个设计取向：索引器缓存是”独立但共池”的。独立，是指维度、精度、量化块大小都能单独配；共池，是指它仍然复用 WindowBlockManager 的块编号体系，从而能让前缀复用、卸载、引用计数这些机制原封不动地覆盖它。如果另起一套管理器，前缀复用时”主 KV 命中了但索引器 K 没命中”就会成为一个要单独处理的错误状态。

为什么索引器需要自己的一份 K？因为它的打分逻辑和主注意力不一样。以 DeepSeek-V3.2 的 DSA 为例，索引器是一个轻量打分器：它用一个小的投影把 query 和 key 压到低维（其 index head dim 远小于主 head_dim），算出的分数只用来排序选 Top-K，随后真正的注意力只在这 K 个 token 上做。既然只用来排序，它就只需要”相对大小正确”，不需要数值绝对精确——这正是 indexerKCacheUseFp4 敢把它压到 FP4 的理由：排序对量化误差的容忍度远高于数值计算。

而 indexerKCacheLayerMask 说明了另一件事：稀疏注意力通常只加在部分层上。全模型都挂索引器意味着每层都要多维护一条池、多跑一次打分，而实验上通常只有一部分层对长上下文的贡献最大。把这个选择做成一个 vector<bool> 的层掩码，等于把”稀疏加在哪几层”从代码里的硬编码变成了配置项——换模型不必改内核。

索引器的量化块大小（indexerKCacheQuantBlockSize = 128）和主池的 tokensPerBlock 是两个独立的量：前者是”打分时多少个 token 共用一个 scale”，后者是”一个物理页装多少 token”。把它们分开配，是因为二者的约束来源不同——前者由打分精度决定，后者由显存分配粒度决定。同名的”块”在这两处含义并不相同，读代码时混起来是很容易犯的错误。

站内 DSA 稀疏注意力完全拆解：从 DeepSeek-V3.2 的闪电索引器到 vLLM 的算子实现 详细讲过索引器本身的算法与在 vLLM 里的算子实现；这里补的是它在缓存侧的内存归属——索引器 K 不是临时变量，而是一份和主 KV 同生命周期、同样要记账、同样可复用的持久数据。

MLA 的 latent 池：一份张量同时当 K 和 V

最后一个问题：MLA（Multi-head Latent Attention）的缓存为什么只有一份张量。

普通 MHA/GQA 的注意力是”每个头有自己的 K 和 V”，所以池里 kvFactor = 2，K 和 V 各占一半。MLA 换了做法：它把 K 和 V 共同压缩到一个低维 latent 向量 $c_t^{KV}$ 里存储，注意力计算时再用上投影矩阵把这个 latent 分别展开成 K 和 V。

于是：

• kvFactor 变成 1——池里只有一份 latent 张量，没有分开的 K 和 V。
• numKvHeads 变成 1——MLA 的 latent 是所有头共享的，不存在”每头的 KV”。
• sizePerHead 变成 latent 维度 $d_c$，而不是原来的 head_dim。

上图出自 DeepSeek-V2 技术报告（arXiv:2405.04434）的 Figure 3，并列画出 MHA、GQA、MQA 与 MLA 四种形态。关键在第四格的箭头方向：MLA 不是”少存一些头”，而是先用下投影把 K/V 压成一个 latent 向量存起来，读取时再用上投影还原——这就是本篇说的 kvFactor=1、numKvHeads=1 的来源。图片来源：DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model。

这里有一个很容易搞错的细节：MLA 缓存的不只是那个 latent 向量。因为 MLA 用的是”解耦 RoPE”（decoupled RoPE）策略——位置信息由一组额外的、带 RoPE 的共享 key $\mathbf{k}_t^R$ 承担，它没法被折进 latent 里，必须单独缓存。所以论文给出的缓存量是：

其中 $l$ 是层数，$d_h^R$ 是解耦 query/key 的每头维度。以 DeepSeek-V2 为例，$d_c = 512$、$d_h^R = 64$，所以每 token 每层实际缓存 $512 + 64 = 576$ 个元素。论文表格里把它写作 $\approx \frac{9}{2} d_h l$，并按这个口径给出四种方案的对比：

按这个口径，MLA 的缓存约是 GQA 的 576/2048 ≈ 28%，不到三成（如果漏掉解耦 key、只算 $d_c=512$，会得到”四分之一”这个偏乐观的数）。把 $d_h^R$ 加回去之后结论不变、量级更准确：MLA 依然明显胜过 GQA，而且这还不是靠”少存点信息”换来的——它是靠给 KV 加了一个可训练的低秩压缩，压缩质量由模型自己学会。论文把这一点总结得很直白：MLA 同时拿到了 MHA 的”强表达能力”和 MQA 的”小缓存”。

这个结论在 TensorRT-LLM 的源码里能找到逐字对应。flashinfer.py 对 MLA 缓存的形状有这样一段注释：

1
# with kv_factor=1 and head_dim = kv_lora_rank + qk_rope_head_dim.
2
# [num_pages, 1, page_size, 1, kv_lora_rank + qk_rope_head_dim].

紧接着的代码就是把它切成两段：

1
ckv_cache = combined[..., :self.kv_lora_rank]     # 压缩 latent
2
kpe_cache = combined[..., self.kv_lora_rank:]     # 解耦 RoPE key

head_dim = kv_lora_rank + qk_rope_head_dim 这一行就是论文里 $d_c + d_h^R$ 的工程写法；DeepSeek 系列上它是 $512 + 64 = 576$。所以当你看到一个 MLA 池的 sizePerHead 是 576 而不是 512 时，多出来的 64 正是解耦 key——它不是冗余，是同一条记录里必须一起分配、一起搬运、一起量化的另一段数据。漏掉它，位置信息就没了。

但这份省下来的访存要在内核侧还回去：内核读出一个 latent 向量后，必须先做上投影才能得到 K 和 V，再进入注意力计算。这是一次额外的矩阵乘，代价在计算侧。所以 MLA 的取舍是：用计算换缓存，与 GQA 的”用精度换缓存”是两条不同的路。

这解释了为什么前面看到的 MLA 相关代码会有那么多专门的缓冲：mla_cu_q_rows（累计 query 行数，因为 MLA 里 query 行数 = cumsum(q_lens) * num_heads）、mla_cu_kv_seqlens（累计 KV 长度）、mla_ctx_cu_q_seqlens，以及 flash_mla_tile_scheduler_metadata 和 flash_mla_num_splits 这一对调度缓冲。这些都不是”通用注意力”需要的——它们是 MLA 特有的：因为 latent 只有一份，内核无法像普通注意力那样按头并行地独立调度，必须用一个专门的 tile scheduler 把”读 latent → 上投影 → 算注意力”这条链编排起来。

1
def _gather_paged_mla_latent(kv_cache, block_ids, kv_len):
2
    # NHD [num_pages, 1, tokens_per_block, 1, d_latent]
3
    # A single block ...
4
    tokens_per_block = kv_cache.shape[2]

三个维度上的取舍如何组合

这篇讲了三组独立的选择——池的分法、维序、量化格式。它们并不是各自的”最优解”然后拼在一起，而是必须组合出一个自洽的配置。把组合关系列出来：

三者的耦合点有两个，都很实际：

耦合点一：量化格式必须被后端内核支持，而内核是按维序编译的。 选了 NVFP4 缓存，就要走”主数据 + FP8 scale 双流”的内核；这个内核又必须在某个确定的维序下工作。格式和维序不能各自独立选——它们是同一个 kernel variant 的两个参数。这就是为什么文档里的支持矩阵是按”模型 × 量化方法”列的：矩阵里每个 Y 背后都对应一组已经编译好的、维序确定的内核。

耦合点二：分池会增加池数量，而每个池都要有自己的量化配置与 scale 池。 一个两池的 VSWA 模型若都用 FP4 缓存，就有 4 个张量（2 个 KV 池 + 2 个 scale 池）；如果模型还是混合 Mamba，还要再加 Mamba 状态池。文档提到 V2 管理器会把这些池放在一起按比例定尺寸（“Attention KV and Mamba state pools must be sized together”），正是为了防止某一类池分得过大而另一类饿死。

所以”怎么配”没有单点最优答案，只有在给定模型结构、给定后端内核、给定精度预算下的一个自洽组合。文档给出的默认策略其实是一条很实用的经验规则：

• 小批次（batch ≤ 4）瓶颈在显存带宽，权重占主导，KV 缓存量化收益相对小，优先权重侧量化。
• 大批次（batch ≥ 16）同时受带宽和算力约束，KV 缓存与激活量化才开始显著收益。
• 量化方法先试 FP8——文档的措辞是”we typically see it offers the best performance and accuracy”，只有在 FP8 精度不达标时才退到 INT8 SmoothQuant、AWQ/GPTQ 等更激进的方案。

这条”先 FP8、不达标再降”的顺序值得记住：FP8 是当前精度-性能比最稳的一档，而 NVFP4 属于”显存真的不够时才动用”的手段——它换来的显存收益最大，但需要额外的 scale 池、双流内核和更严格的校准流程。

小结

这一篇补上了第六篇留下的那个乘法：索引数组乘上 stride 变成地址，而 stride 来自池的布局。

• 池是六维张量，[max_blocks, num_layers, kvFactor, numKvHeads, tokensPerBlock, headSize]，一个池装下所有同构的层，因为块的元数据是层间共享的。账本因此只需一套块编号。
• 池的键是（注意力窗口大小，KV 头数）。VSWA 模型（Gemma、GPT-OSS）必然分池；池间显存比例静态分配、运行时不可改，因为池基址被 CUDA Graph 记录。运维上必须在启动时就按负载特征配好权重。
• numKvHeads 直接换算成 tokensPerBlock × headDim × 2 × dtype 的每块字节数，GQA 相对 MHA 省 4 倍，且这个省法不损失任何精度——它只是不给重复的 KV 头分配空间。
• NHD 与 HND 是同一个池的两种维序：HND（[head, token, dim]）让同头跨 token 的访存连续，适合解码；NHD（[token, head, dim]）让同 token 的 K/V 相邻，适合预填充写入与部分既有内核。TrtllmAttentionMetadata 默认 HND、FlashInfer 后端默认 NHD、VanillaAttention 写死 NHD——维序是后端契约，不是框架约定。
• 量化缓存必须逐 token/逐头缩放，否则少量 outlier token 会把整池的动态范围吃掉。per-tensor scale 是激活量化的方案，不是 KV 缓存的方案。
• FP4 的 scale 因子放在独立的 scale 池（containsBlockScales），形状与 KV 池相同、最后一维变成 head_size / N（NVFP4 是 16），与主池共用块编号。代价是内核必须走”主数据 + scale 双流”的流水线。
• 索引器 K 缓存（DSA 这类）同样是一个池（containsIndexerKCache），维度、量化块大小、精度、层掩码都可单独配置，但复用主池的块编号体系，因此前缀复用与卸载机制能原封不动覆盖它。
• MLA 的 latent 池是 kvFactor=1、numKvHeads=1、sizePerHead=d_latent，一份张量同时当 K 和 V；收益是缓存压到 GQA 的约三成（DeepSeek-V2 每 token 每层 $d_c + d_h^R = 512 + 64 = 576$ 元素，对 GQA 的 2048），代价是读出来之后要做上投影，因此需要 flash_mla_tile_scheduler_metadata 这类专用调度缓冲。
• 同一套六维容器靠参数取值就覆盖了 MHA/GQA/MQA/MLA；差别不在结构，只在参数。

把这一篇和第六篇合起来看：第六篇讲的是逻辑账（哪些块属于哪条请求），这一篇讲的是物理账（那些块在显存里长什么样、每个元素在哪个偏移）。两本账之间只隔着一层 stride 乘法，而所有”为什么这么设计”的答案都指向同一条约束：内核要能无条件地、以编译期已知的步长访存。布局、量化格式、块大小全部因此必须在创建时就定死，运行中只允许改内容、不允许改形状。

下一篇进入 KV 缓存的写入与读取路径：一次前向里新 token 的 K/V 究竟由哪个内核写进池（reshape_and_cache 这类 scatter 操作的索引从哪里来）、变长序列的 ragged 写入如何按 kv_indptr 分段、块边界跨越时一次写入怎么拆成两段、以及读取侧的分页 gather 如何与这篇讲的 stride 拼成最终地址。这一篇把”池长什么样”讲完了，下一篇讲”数据怎么进出这个池”。

参考资料

1. TensorRT-LLM 官方仓库（NVIDIA/TensorRT-LLM）
2. TensorRT-LLM 官方文档：KV Cache System（池结构、分池规则、保留策略与驱逐）
3. TensorRT-LLM 官方文档：Quantization（FP8 / NVFP4 KV Cache 配置与模型支持矩阵）
4. TensorRT-LLM 官方博客：Speed up inference with SOTA quantization techniques in TRT-LLM
5. TensorRT-LLM _torch/attention/backends/interface.py：kv_layout 契约与 KVCacheParams
6. TensorRT-LLM cpp/include/tensorrt_llm/batch_manager/kvCacheManager.h：KVCacheBlockPool 与池形状注释
7. TensorRT-LLM cpp/tensorrt_llm/batch_manager/kvCacheManager.cpp：WindowBlockManager 与块分配实现
8. TensorRT-LLM _torch/attention/backends/vanilla.py：NHD 布局与 MLA latent gather
9. TensorRT-LLM _torch/attention/backends/flashinfer.py：kv_layout 分支与页表构造
10. FlashInfer 官方文档：KV-Cache Layout（NHD/HND 与页表三件套）
11. DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model（MLA 的出处，$d_c = 512$、$d_h^R = 64$）
12. DeepSeek-V3.2 技术报告（DSA 稀疏注意力与索引器）
13. FlashInfer: Efficient and Customizable Attention Engine for LLM Inference Serving
14. PyTorch 官方文档：CUDA Graph 语义与捕获前置要求