TensorRT-LLM 源码完全拆解（九）：KV Cache 压缩框架——冷页 NVFP4 编码、TriAttention 驱逐与物理压实

三个部件

整个设计拆成三部分，不修改任何已有运行时组件：

• Compression config：一个配置块选择方法、携带方法自己的参数；一个工厂在模型跑起来之前根据它构造方法。
• Compression manager：方法继承的类。它已经坐在执行器循环的每个钩子上以及缓存管理器的页迁移路径里；方法只需要覆写它需要的那些函数。
• Method-specific kernels：方法自带的内核；既可以是新算法，也可以是与运行时已有部分的融合。

执行器和 KV 缓存管理器都是已存在的组件——框架不替换它们，只在钩子处与它们相遇，把调度和内存所有权留在原地。

图里把整条装配线画得很清楚，值得逐格读：配置先构造管理器（1）；管理器向执行器插一个钩子、向 KV 缓存管理器插一个钩子（2）；具体方法继承管理器并在这些钩子里运行（3），启动自己的内核（4）。高亮的方框是框架部件，白色方框是已有系统组件。两条路径的接线方式不同，这是一个容易忽略但很关键的设计细节：

• Iteration-driven 管理器：在工厂阶段注册给生命周期回调；如果它需要访问 KVCM，就通过 bind_kv_cache_managers() 在 KVCM 构造之后绑定。
• Storage-bound 管理器：在 KVCM 构造期间提供一个 NativeColdPageCodec，并且不注册迭代回调。

工厂必须跑在 KVCM 构造之前，正是因为 storage-bound 方法要在 KVCM 建冷布局时就已经就位。

配置与准入

kv_cache_compression_config 块里有两个东西：algorithm（选哪个方法）和方法自己的参数（例如 TriAttention 的 token budget、驱逐周期、eviction_mode 与校准文件）。公开的方法配置继承自 tensorrt_llm/llmapi/llm_args.py 里的 KvCacheCompressionConfig，方法特有字段留在具体子类上而不是公共基类。

create_kv_cache_compression_manager()（在 tensorrt_llm/_torch/pyexecutor/_util.py）在模型执行或存储迁移之前校验配置并构造具体管理器。为了支持构造与兼容性检查，压缩配置暴露以下契约：

这里有一个很容易误判的语义，值得单独说清楚：changes_physical_kv_length 与 supports_block_reuse() 不冲突。它们描述的是两个独立性质。一个方法完全可以只压缩/压实”生成侧的后缀”，同时完整保留可复用的提示词前缀块及其身份——这样的方法可以设 changes_physical_kv_length = True，同时 supports_block_reuse() 返回 True。只有当方法无法保留可复用前缀或其映射契约时，才应该把块复用报为不支持。

兼容性方法是准入谓词，不是运行时回退：不支持的组合在构造阶段用明确信息拒绝，而不是跑起来之后悄悄降级。这与下一篇会讲的”压缩管理器不得在可见状态半更新时静默回退”是同一条原则的两个面。

所有权与失败边界

框架把职责切得很硬，这张表实际上是整套设计的”宪法”：

两条规则值得拎出来独立记：

• 在物理改动之前，方法可以拒绝、推迟或执行一个合法的 no-op；
• 在提交工作或移动字节之后，必须遵守框架的完成与失败契约：不得在留下部分更新的可见状态时静默回退。

这条契约的存在，是因为压缩的产物往往被别的东西引用：块表、页表、前缀复用树的哈希、以及调度器的容量账。半更新的状态不会崩溃，只会让数值和容量悄悄偏掉——和第八篇结尾说写入路径错误模式时的结论完全一致。

为什么校准必须离线

框架还划了一条”推理平台不做训练/拟合”的界线，这条界线比它看起来更重要。

有些压缩方法需要校准或其它离线产物（TriAttention 就需要一份按注意力头采集的查询统计校准文件）。TensorRT-LLM 是推理平台，因此压缩方法不得在推理关键路径上做模型校准、语料收集、参数拟合或校准文件生成。用户应当在服务之前用自己的工具链、NVIDIA ModelOpt 或其它有文档的离线流程产出这些产物。

运行时的行为是：配置接受一个产物路径，管理器或模型初始化期间加载并校验它；一旦请求开始执行，生命周期钩子和冷页 encode()/decode() 只能消费已经就绪且不可变的状态。缺产物、与模型不兼容或格式损坏，要在初始化时快速失败。

这条界线有一个精确的例外：在编码一个页时现算的每块 scale，是运行时变换状态，不是模型校准——它数学上是每次压缩操作的一部分，所以允许在 encode() 里算。

共享的压实内核：只决定”留谁”，不决定”怎么搬”

框架里最有意思的一处工程切分，是把”保留策略”与”压实动作”彻底分开。

在钩子里，方法在自己的内核上跑；然后调用一个共享的、算法无关的压实内核（compaction）把保留的 token 打包、把释放的页还回去。所以方法只决定留谁。两条规则：保留策略与压实分离；GPU 工作必须在任何页被收缩或释放之前完成。

这个压实器的实现值得细看。tensorrt_llm/_torch/kv_cache_compression/compaction.py 的模块注释把这个 mover 的角色写得很清楚：

1
"""Batched physical KV-cache compaction: an algorithm-neutral mover.
2

3
``build_compaction_params`` pre-binds one cache's launch parameters;
4
each round the caller writes its keep decision into the agreed rows and
5
``compact`` packs every cache's move sources and fires its native launches.
6
"""

它的接口被设计成两段式：build_compaction_params() 一次性预绑定一个缓存的启动参数；之后每一轮，调用方把自己的保留决策写进约定好的行，compact(params, request_count) 负责打包所有缓存的搬运源并触发原生启动。

打包发生在 Triton 侧，_pack_move_sources_kernel 的 docstring 一句话说清了语义：

1
Pack one decision row into one family's move sources: dense rows emit the
2
kept tokens then the protected tail; SWA rows emit the latest window
3
(ascending order: the native copy moves in place).

也就是说，一个请求的搬运源是两段拼接的：先是被判定保留的 token 序号，然后是受保护的尾部（保留窗口尾部 / SWA 的最新窗口）。内核里对应的算术就一行：

1
dense_source = tl.where(move < KEEP_COUNT, kept, valid_len + move - KEEP_COUNT)

move < KEEP_COUNT 的部分从保留列表里取，剩下的部分从 valid_len 往前推——这就是”保护尾部”在索引层面的实现。内核还处理一个广播分支：当 DECISION_ROWS == 1 时，每个请求的一行决策要喂给所有 KV 头的打包行（for head in tl.static_range(0, NUM_KV_HEADS)）——因为保留决策通常是按请求全局做出的，而物理缓存是按 (层, 头) 分开存放的。

打包完之后，compact() 对每个 (缓存, 池组) 各发射一次原生算子：

1
torch.ops.trtllm.sparse_kv_cache_compact_layers(*args)

注意最后一段注释里的边界划分：request_count 只用来决定 Triton 打包网格的大小；原生算子从页表视图的行数取 batch，并拿这个行数去校验配套张量。这是一个典型的”主机侧参数与设备侧真相必须对得上”的契约——对不上就应该报错，而不是默默按主机侧的数字处理。

热表示：一页摊在多个池上；冷表示：一页是一个不透明块

• 热表示在 GPU 上：一个页摊在多个面向内核的池上。这正是第七篇讲过的布局——主池、索引器 K 池、MLA latent 池、以及混合模型里那些非注意力的 state 池，它们各有各的 stride，因为注意力内核要按各自的访存模式去读。
• 冷表示在 GPU 之外：一页是一个固定大小的不透明 blob（opaque blob）。

两者之间的变换由 IKvCacheColdPageCodec 完成：

1
Hot representation                         Cold representation
2
multiple kernel-facing pools  <-------->   one opaque blob per page
3
                                 codec

接口名用的是 “Codec” 而不是 “Compressor”，原因文档里明说了：它定义的是一个表示变换，不一定是压缩算法。默认 codec 把所有热池的数据拼接进冷 blob，不减小尺寸；压缩型 codec 产生更小的冷页。两种情况共用同一套 KVCM 的分配、迁移与事件管理路径。

这个”默认 codec 不压缩”的设计非常关键，它让冷页机制本身（KVCM 侧的记账、事件、暂存）可以独立于压缩算法先落地并验证，压缩只是换了一个更小的 queryColdPageBytes 实现。

冷页布局换来的是实打实的工程收益：磁盘存储的文件数与 I/O 次数下降。原本要按”每个热池每页一次操作”发起，现在变成”每个编码后的冷页一次操作”。

Codec 的 ABI

1
enum class PageIndexLocation : int
2
{
3
    kBadLocation = -1,
4
    kHost,
5
    kDevice,
6
};
7

8
struct alignas(8) PageIndexPair
9
{
10
    int32_t dst;
11
    int32_t src;
12
};
13

14
class IKvCacheColdPageCodec
15
{
16
public:
17
    virtual bool configure(
18
        PoolGroupDesc const* gpuDescs, PoolGroupIndex numGpuDescs) noexcept = 0;
19

20
    // Zero indicates failure.
21
    [[nodiscard]] virtual size_t queryColdPageBytes(LayerGroupId layerGroupId) const noexcept = 0;
22

23
    [[nodiscard]] virtual LayerGroupId getBatchingLayerGroupId(
24
        LayerGroupId layerGroupId) const noexcept;
25

26
    [[nodiscard]] virtual PageIndexLocation queryPageIndexLocation(
27
        LayerGroupId layerGroupId) const noexcept = 0;
28

29
    virtual bool encode(LayerGroupId layerGroupId, void* dstBasePtr,
30
        PageIndexPair const* pageIndices, size_t numBasePages,
31
        cudaStream_t stream) noexcept = 0;
32
    virtual bool decode(LayerGroupId layerGroupId, void const* srcBasePtr,
33
        PageIndexPair const* pageIndices, size_t numBasePages,
34
        cudaStream_t stream) noexcept = 0;
35
};

几个契约值得逐条解释：

• queryColdPageBytes() 返回每个生命周期固定的冷页载荷大小，不支持变长输出。固定大小是”base + slot × size”寻址的前提，也是”磁盘一次 I/O 一页”的前提。
• configure() 一次调用就把所有热 GPU 池的布局与基地址交出去，描述符按 PoolGroupIndex 连续排列；KVCM 只调用一次，返回 false 表示整个配置被拒绝。
• getBatchingLayerGroupId(lifecycle) 返回同一 codec 等价类里最小的生命周期 ID。相同 ID 是一个承诺：算法、参数、冷页大小、编码后的表示都相同；额外的必要前提是它们属于同一个已配置的 GPU 池组。默认实现返回入参本身，即禁用跨生命周期批处理。这解释了表格里那句”只有等价的页才允许合并成一次 codec 调用”。
• queryPageIndexLocation() 显式选择 encode()/decode() 用的指针位置。压缩型 codec 通常选 kDevice；而一个同步消费索引来构造批量 DMA 描述符、逐页 cudaMemcpyAsync 调用或内核参数的 codec 可以选 kHost。
• KVCM 可以把同一 batching ID 下任意子集生命周期的索引对拼起来，用代表 ID 调一次 encode()/decode()；KVCM 不承诺这个等价类里的每个成员都出现。
• encode/decode 在给定 CUDA 流上入队工作，不做同步；返回的 bool 报告的是同步校验或提交是否成功，不是异步 CUDA 工作已完成。

最后两条指针生命周期规则是 ABI 里最容易写错的地方：

• kHost：索引指针只在 codec 调用返回之前有效，异步工作不得保留或解引用它们；
• kDevice：索引指针在所有在该流上入队的 codec 工作完成之前有效，codec 只能在那个流上使用它们，且不得在工作之外保留。

PageIndexPair 的数组结构体（AoS）布局是刻意的：一个 GPU 工作项可以用一次对齐的 64 位加载同时取到 dst 与 src，而主机侧 codec 可以遍历同一个数组逐页发起拷贝。这就是为什么它是 alignas(8) 且 sizeof == 8 并带 static_assert。

布局等价类：LifeCycleId 与 PoolGroup

KVCM 用两个不同层次的概念管理映射：LifeCycleId 是稳定的语义键，池组（PoolGroup） 是物理分配的等价类，且具体属于某一种存储表示。

1
LifeCycleId ----> hotPoolGroup(lifecycle):  multi-pool hot layout
2
            +---> coldPoolGroup(lifecycle): one-pool cold layout

热与冷的生命周期到池组的映射互相独立。举个文档里的例子：两个生命周期可以共享一个 GPU 池组（因为未编码布局完全相同），却映射到不同的冷池组（因为编码后大小不同）。反过来，每个非热池组恰好包含一个物理池；冷页 stride 兼容的生命周期可以共享一个冷池组，而它们的编码内容可能不同——因为传给 decode() 的 lifecycle 会选择正确的解释方式。

这里有一个对整个分层存储都生效的简化：所有冷层使用同一套逻辑编码表示和同一套 lifecycle→冷池组映射。这使得主机与磁盘之间的原始 blob 拷贝无需解码再编码。物理层仍然可以按自己的分配粒度或 padding 包在逻辑载荷外面。

内存切分的口径也随之从”按热池组”改成”按层组”。KVCM 先为每个公开层组推导一个正的归一化热层字节配额权重（来源可以是 initial_pool_ratio、典型 batch 或约束）；热初始化把映射到同一热池组的生命周期字节权重加起来；冷初始化先把每个热字节权重转成隐含的槽位计数权重，再用该生命周期的冷页大小转成冷字节，最后加进冷池组。这一步转换的目的很具体：当热与冷的页大小不同（或者池组映射不同）时，仍然保持层组之间的槽位计数比例。

于是 initial_pool_ratio 与更高层的 KvCacheConfig.pool_ratio 里每个层组恰好有一个热层字节比例，按层组 ID 顺序排列，而不是每个热池组一个。热层约束仍作为可行性下界，可能钳制最终的热分配；它们不会被投影到冷存储——冷池组只使用其分配器所需的结构性最小值。

迁移时，源与目的池组独立地从页的生命周期与缓存层级解析出来。文档里有一句警告必须记住：池组索引不得跨表示比较，仿佛它们标识同一个物理布局。

事务性：批处理代表如何被校验

在构造阶段，KVCM 会校验每个 batching 代表：已被配置、不大于每个成员、映射到自身、与每个成员属于同一组已配置的 GPU 池组与冷池组、且冷页大小与页索引位置相同。

对一次热/冷转换，迁移键包含物理源池组、物理目的池组与 batching 代表；KVCM 随后拼接已经排好序的索引对，做一次 codec 调用。热/热与冷/冷拷贝不使用 codec batching ID——它们不需要表示变换，直接拷字节。

内存契约：谁拥有内存、事件怎么保护字节

这一节是 C++ 侧最”硬”的部分，但理解它对判断一个压缩方法是否可行很关键。

• KVCM 拥有所有热、冷与暂存分配。冷存储不暴露给 codec 用户；除冷存储外只有 GPU 存储通过既有 KVCM API 暴露。
• KVCM 保证传给 codec 的每个热/冷数据基地址都是 GPU 可访问的（GPU 内存或 pinned mapped 主机内存）。磁盘地址永远不会传给 codec。当没有主机层时，KVCM 用临时 pinned 主机暂存缓冲做 GPU↔磁盘迁移。
• 索引的搬运路径有一个精巧设计：KVCM 先在获取稀缺暂存资源之前构造一个 packed 的 thread_local std::vector<PageIndexPair>。主机索引就直接传这个 vector，codec 在返回前消费完；设备索引则获取设备暂存，并提交一条 H2D 的 cuMemcpyBatchAsync，带 CU_MEMCPY_SRC_ACCESS_ORDER_DURING_API_CALL。 这条 flag 的含义是：CUDA 必须在 API 返回前完成对可分页主机 vector 的每一次访问，而 H2D 传输仍在 codec 流上异步进行。于是 KVCM 可以立即复用主机 vector，不需要 pinned 主机索引环。上传还带 CU_MEMCPY_FLAG_PREFER_OVERLAP_WITH_COMPUTE，在平台支持时优先走拷贝引擎。 CUDA 12.8 之前没有 cuMemcpyBatchAsync，KVCM 改用版本门控的分段内核上传可分页主机索引，其参数在启动期间被消费。
• 暂存设施与 CopyEngine 解耦。当任一冷层既不是 GPU 也不是主机内存时，StorageManager 独占一个 pinned 页环；在查询并校验每个生命周期的冷页大小后，把它定容成 max(64 MiB, 3 * maxColdPageBytes)（带检查的乘法）。纯 GPU/主机冷存储不分配页环。
• 暂存管理器刻意不做内部线程安全：每个属于一个 KVCM 实例，而该实例的 API 目前串行化访问。文档还给出了将来的做法：如果 KVCM 日后支持并发公开调用，同步应当放在 KVCM 边界（每实例一把互斥锁），而不是放进每个暂存管理器内部。

分配器本身用的是字节精确的 next-fit 游标 + 空间有序的区间划分：live range 表示当前租约，retired range 保留这些字节上一个时间所有者的完成事件。分配从游标到物理末尾扫描连续的 retired 区段（跳过 live 区段），然后至多再从开头扫一遍；只有成功分配后游标才移动。如果没有区段满足最小请求，分配失败而不是等待——理由写得很直接：等待一个”不能在同一线程 retirement 的 live 租约”是死锁。

第八篇结尾留的伏笔在这里落地了：压缩必须在写入时决定”要不要写、写多少位”，在读取时决定”读出来怎么还原”。冷页 codec 就是这两个决定的实现位置。

冷页机制与”把 KV 放到更远的层级”是同一带宽预算下的两种走法：一个往”装得更小”走，一个往”放得更远”走。后者在站内 KV Cache Offloading 完全拆解 里已经拆过，包括分层放置、异步流水与跨机调度；两者的交汇点正是这里说的冷页表示——它决定了同一块主机内存在同样的带宽下能装下多少页、一次搬运要花多少字节。

融合的 encode/decode

当 KVCacheManagerV2 卸出一批页时，一个融合内核把它们量化并直接写进主机槽位；页回来时，它的 counterpart 在注意力读之前把它们反量化回 GPU 池。文档中对这套内核形态的描述很具体：

The kernels build on the NVFP4 conversion path TensorRT LLM already uses, so no calibration is needed, and they are shaped like the cache manager’s own copy kernel, streaming the page through shared memory and storing directly into host memory, so quantization rides the transfer instead of adding a pass.

三件事同时出现在这句话里：

1. 不引入新的数值格式——复用已有的 NVFP4 转换路径，因此不需要校准。这直接消掉了框架里”校准产物”那条约束对这个方法的要求。
2. 内核形状照抄缓存管理器自己的拷贝内核：把页流经共享内存、直接存进主机内存。这是性能上的关键——量化骑在传输的带宽上，而不是与之竞争。
3. 只量化注意力的 K 与 V；页里其它东西（例如混合层里的递归 state）在同一次启动里原样拷贝。

目标缓存与草稿缓存都被覆盖，所以投机解码在 codec 开启时仍然可用。这在实现上不是小事：投机解码有独立的草稿缓存，两者都要有各自的冷页生命周期与 codec 映射。

冷页的”一页一块”

热页摊在多个池上是因为那是注意力读取的布局；冷页没有任何人读，所以它的布局纯粹为存储与传输选择：一个固定大小块，装着 NVFP4 数据、scale 以及那些无损缓冲。

由此得到一串连锁的简化：主机和磁盘用”base + slot × size”寻址；一次拷贝搬走一整页而不是每个缓冲一次；磁盘每页一次 I/O 而不是每个池一次；主机与磁盘之间的搬运原样拷字节、不需要解码再编码。这正是 KVCM 对 codec 提出的契约，也正是它能”不改缓存管理器就插进去”的原因。

K 向量里被位置编码（RoPE）的那一段

这是 NVFP4 冷页压缩里唯一需要精细权衡的地方：K 向量里带位置信息（RoPE）的部分对量化最敏感，压缩比与准确性在这里互相拉扯。

• 默认（skip_rope_quantization: false）：整条向量都量化，压缩比最好。DeepSeek-V4 遵循它自己的原生方案，把 RoPE 部分存成两个 FP4 分量（2FP4），第二个分量保存第一个的舍入误差——在这个压缩比下把准确性保住。nvfp4_residual_dim 默认 64，即 64 个 RoPE 值走 2FP4；设成 0 就整行单一 NVFP4（只支持 0 和 64）。
• 另一侧（skip_rope_quantization: true）：RoPE 部分按热缓存精度原样拷进冷页（FP8 或 BF16），其余值走 NVFP4。代价是冷缓存存储更大。

开发指南把”K/V 向量的哪些数字变成 NVFP4”讲成了内核必须能表达的形状约束：

For each row the kernel turns one contiguous piece into NVFP4 (4-bit values plus one scale per 16 numbers) and copies everything before and after that piece unchanged.

也就是说，每行只有一段连续区间可以被量化，前后原样拷贝；压缩缓冲用 quantized_range_start 与 quantized_range_elements 记录这段区间。codec 会拒绝内核表达不了的情形：整条向量都是 RoPE（没有东西可量化）、RoPE 在向量中间（会变成两段）、或者这段区间的起点/长度不是 16 的倍数（scale 组的大小）。

RoPE 的位置从哪里找？文档给了三条模型特定的规则：MLA 层每 token 只存一个 576 数字的向量（其唯一缓冲是 key），RoPE 是最后 qk_rope_head_dim 个数字；GQA 头若只旋转前导数字（Qwen3.5），是前 head_dim * partial_rotary_factor 个；DeepSeek-V4 压缩条目是 512 个数字里的最后 64 个。V 向量不携带位置，永远整条变 NVFP4。

还有一个实现层面的开关范围约束：skip_rope_quantization 只对 _SKIP_ROPE_QUANTIZATION_MODEL_TYPES 里的模型类型生效（其 RoPE 布局是 codec 知道的）；其它模型会打警告并量化整条向量。而草稿模型的冷页忽略两个 RoPE 选项，一律用单一 NVFP4。

开发指南顺带说了一条新增模型的陷阱，值得写给以后要扩展的人：只加一个 model_type 是不够的。对于交错旋转维度、或者 MLA 缓存同时暴露了 value 缓冲的情况，必须实现显式的放置规则并测试，然后才能把模型加进支持列表。另外，RoPE 宽度取自 rotary-width 字段或 partial rotary factor，绝不能从 theta 或 rotary_emb_base 推。

一轮里的每个内核

这张图是这一节的主干，一个方框一个内核：

• on_generation_step_end 钩子挑出到期（due）的请求——注意是”到期”而不是”全部”，一轮每 beta 个生成 token 才跑一次，且只在序列超过 budget 之后；
• 一个 Triton 内核收集 mean-phase 行；
• 一个融合的 CuTe DSL 内核从 K 页给每个生成 token 打分；union 模式下同一内核里直接产生选择行，per-head 模式下则由一个 Triton 归约产生；
• CuTe DSL 的 radix top-k 加一个 Triton 的 tie-settling 段选出保留的 token；
• 一个原生 CUDA 内核压实 K 与 V；
• 缓存管理器接收新的长度与被释放的页。

三个实现决策值得点出来：

1. 打分与选择用 CuTe DSL，压实用原生 CUDA。理由是每一段用最适合的内核路径：打分/选择是头维小、token 维大的规约型计算，适合 tile 化的 DSL；压实是在分页缓存上原地搬移，需要精确的地址算术与块边界处理，用原生 CUDA 更直接。
2. 整轮驱动来自执行器自己的回调，所以CPU 侧开销也不暴露。文档说得很直接：这些内核把 GPU 时间压到解码步的一个小分数，而轮次是从执行器的回调里驱动的。
3. 注入点是 on_generation_step_end，TriAttention 唯一覆写的钩子。时序要求是：一轮必须在某次解码步写完它的 token 之后、下一次步读缓存之前运行。还有一个边界条件：一次确认了多个 token 的投机步最多触发一次。

物理压实与”保留策略分离”

TriAttention 在钩子里用自己的内核打分并选择 token，然后调用共享的压实器。这就是前面 compaction 那节讲的机制：决策行由方法写，搬运由框架做。

压实器的设计动机在代码注释里交代得很清楚——它要同时处理几类缓存结构：

• dense 行：搬运源 = 保留 token + 受保护尾部；
• SWA 行：搬运源 = 最新窗口，且按升序给出，因为原生拷贝是原地移动的；
• 每层共享的 SWA 行：PER_LAYER 分支里，只有第一个层的决策行写它（decision_row < NUM_KV_HEADS），头号由 decision_row % NUM_KV_HEADS 得到。

原地搬移要求源序号升序，这是一个很典型的”物理压实”约束：压缩后的缓存要占据同一块内存的前缀，所以搬移必须从低序号往高序号做，否则会覆盖还没搬走的源数据。

校准放在哪

TriAttention 需要一份模型特定的离线校准文件。配置里给的是 calibration_path，运行时不生成它。这与前面”校准必须离线”的框架约束一致，也是这个方法在部署上的主要额外步骤。配置形态是：

1
llm = LLM(
2
    model="<path_or_hf_id>",
3
    kv_cache_config=KvCacheConfig(use_kv_cache_manager_v2=True),
4
    kv_cache_compression_config=TriAttentionKvCacheCompressionConfig(
5
        budget=2048,
6
        beta=128,
7
        eviction_mode="union",
8
        calibration_path="/path/to/model-calibration.pt",
9
    ),
10
)