我这次要聊的，是最近在本地模拟项目X上完整走通的一套多模态推理压缩方案。核心就三件事：自适应感知、KV缓存优化、Token容量扩展。这三条线单独拎出来都有文章可讲，但真正有价值的是把它们组合起来，用Python复现并验证"能把KV缓存压到原来的五分之一到四分之一，问答准确率基本不掉"——这个结果对我实际部署多模态服务的吸引力非常大。如果你正在做大模型推理优化，或者被长上下文、多图输入时的显存爆炸搞得焦头烂额，这篇内容应该能给你一套可以直接抄作业的路线。

先说为什么会写这个。之前我在调一个7B级别视觉语言模型的推理服务，输入一张高分辨率截图加一段对话，显存很快就见了底。排查下来发现，真正吃显存的其实不是权重，而是KV缓存。一张336×336的图切出来的patch token数量轻松超过五百个，这些token进入Transformer后产生的KV缓存和文本token一样占用显存，而且自回归生成阶段越积越多。传统的训练时量化、剪枝对权重有效，但对推理阶段动态生长的KV缓存几乎束手无策。这种情况下，必须在推理侧做文章，也就是标题里说的那三个方向。

1. 多模态推理的显存痛点：KV缓存到底吃掉了多少资源

1.1 一张图为什么比一百个词更吃显存

先把基础概念理清楚。Transformer解码时，每生成一个新token，都需要用当前query去和前面所有token的key、value做注意力计算。为了避免每一步都重新计算前面的映射关系，工程上会把已经算好的K、V矩阵缓存下来，这就是KV cache。它是典型的"空间换时间"策略。

KV缓存的显存占用可以用一个公式估算：

显存占用 = 2（K和V两份） × batch_size × seq_len × num_layers × num_heads × head_dim × 字节数

以一个7B模型为例，假设32层、32头、head_dim为128，全部用fp16存储，那么每个token每个层需要的KV元素数是2×32×128=8192，32层就是262144个元素，乘2字节就是约0.5MB。也就是说，这个模型处理4096个token时，单条序列的KV缓存大约需要2GB。

文本场景下，一句话也就二三百个token，很多人对KV缓存的感知不强烈。但多模态场景完全不同：一张图被视觉编码器切成patch后，每个patch就是一个token。336×336的输入、14的patch size，会得到24×24共576个图像token。这相当于凭空多出576个token的KV缓存，比一段四五百字的文本还多。要是输入多张图，或者做视频帧序列理解，KV缓存直接线性膨胀。而且多模态对话往往是多轮交互，历史图像和文本的KV缓存全部留着，显存压力远非纯文本可比。

1.2 传统压缩方案在推理阶段的局限

很多做模型压缩的人第一反应是量化权重或做结构化剪枝。这两种手段确实能把模型从7B压到更小，但请注意，它们压缩的是静态权重，对推理时动态生成的KV缓存没有任何帮助。只要生成序列变长、输入图像变多，KV缓存照样暴涨。

蒸馏是另一个常见方向，用大模型教小模型。但蒸馏改变的是模型本身的能力上限，Multimodal推理时的冗余主要来自输入侧和信息侧——不是模型参数太多，而是"模型被迫处理了太多不重要的视觉信息"以及"缓存里存了大量低价值token"。这需要的是推理态的、输入自适应的压缩手段，而不是训练态的模型瘦身。

还有一个隐蔽问题：多模态推理的显存瓶颈往往不是"峰值算力不够"，而是"显存带宽和容量不够"。模型权重可以一次性加载到显存里，KV缓存却是生成过程中逐步追加的，追加到一定程度就会触发显存溢出或者频繁换页。实测中，16GB单卡跑7B多模态模型，提示词只占不到一半显存，剩余空间全被KV缓存吃掉，生成长句时经常直接Out of Memory。

1.3 三条压缩路线怎么分工

针对上面这些问题，我设计的分工是这样：

• 自适应感知负责"从源头减量"。它让模型在看图时不要一视同仁地处理所有patch，而是动态判断哪些patch重要、哪些可以直接忽略，从源头减少进入KV缓存的视觉token数量。
• KV缓存优化负责"对存量做瘦身"。已经计算好的KV矩阵，通过剪枝、量化、合并等手段进一步压缩显存占用，同时尽量保住信息量。
• Token容量扩展负责"花最少的显存放最多的内容"。它的核心逻辑是：KV缓存每token成本降下来了，同样的显存预算就能容纳更多的token，等于扩展了可承载的序列长度和图像数量。

三条线组合起来的效果，就是标题里的"高效压缩"。下面我按这三条线分别讲原理和复现细节。

2. 自适应感知：怎么让模型学会"挑重点"看

2.1 自适应感知的基本思路

自适应感知的核心假设是：图像patch的信息量高度不均匀。一张PPT截图上，文字密集区域可能只有十几个patch，但承载了90%的语义；一张风景照中，大片天空和地面的纹理patch对回答"图片里有什么"几乎没贡献。

传统做法是固定下采样，把patch统一融合或降低分辨率。但固定式的问题在于：它不看内容，对所有图一视同仁。比如一张密集文字图需要保留200个patch，一张纯色背景图可能20个就够，固定策略要么浪费显存要么损失信息。自适应感知的做法是让模型根据输入内容自己决定"这张图我要细看哪里、粗看哪里、根本不看哪里"。

我复现时把感知模块拆成两个步骤：先对每个patch做重要性评分，再根据评分做动态保留。评分本质上是给每个patch打一个"信息密度分"，保留阶段则根据显存压力和图像复杂度决定保留多少patch。

2.2 视觉Token重要性评分的两种实现路径

第一种是训练一个轻量评分网络。在视觉编码器后面接一个小的一维卷积或线性层，对每个patch输出一个0到1的重要性分数。训练时可以用对比学习或者软注意力损失来约束，让评分高的patch确实对最终问答结果影响更大。这种方案效果最稳定，也可以端到端优化，但需要额外训练，并且换一个模型就要重新训练，迁移成本偏高。

第二种是直接用模型自身已有的注意力分布来打分，不需要任何训练。这是我在项目X里优先采用的方式，因为它即插即用，几乎适配所有Transformer架构的多模态模型。

具体做法是：在预填充阶段，把提示词序列和图像token一起送入模型，取文本侧最后一个token对视觉token的注意力权重，作为视觉token的重要度近似。如果模型有多层，可以取最后几层的平均，减少单层噪声。公式上大致是这样：

def score_visual_tokens(attn_weights, visual_indices, text_last_idx): # attn_weights: [num_layers, batch, num_heads, seq_len, seq_len] # 取文本末尾token对视觉token的注意力，跨层、跨头求平均 visual_scores = attn_weights[:, :, :, text_last_idx, visual_indices].mean(dim=(0, 1, 2)) return visual_scores

这里有个很反直觉的发现：直接按注意力分数做top-k剪枝，在某些图上会严重掉点。比如图像里主体很小、但背景和主体纹理相近时，模型注意力会分散到大量背景patch上，这些patch的单点分数不高不低，按绝对分数截断很容易把真正的主体patch也一起剪掉。

我的解决办法是引入两项修正：第一，对分数做软化，不是硬top-k，而是用温度系数放大高分patch和低分patch之间的差距；第二，结合一个很朴素的显著性先验——图像中心区域和高频纹理区域的patch，重要性权重略高。这两项修正不需要训练，只是改变了保留阈值附近patch的排序，却实实在在把复杂构图场景下的准确率救了回来。

2.3 门控与压缩率动态调节

感知模块不能永远用固定压缩率。同一个模型，处理单张图时剪掉40%没问题，但处理密集文字截图时剪掉40%可能就漏了细节。项目X里我加了一个显存和内容联合感知的门控：

• 显存压力信号：用当前KV缓存已经占用的字节数除以显存预算，得到一个0到1的压力系数。压力越大，压缩率上限越高。
• 图像复杂度信号：用patch注意力分布的熵来衡量。attention熵低，说明模型高度集中在一小部分patch上，可以激进压缩；attention熵高，说明信息分散，压缩要保守。

实际逻辑可以写成一个简单公式：

compression_rate = base_rate * (0.5 + pressure) * (0.5 + (1 - entropy_norm)) compression_rate = clamp(compression_rate, 0.2, 0.7)

这个门控让同一个感知模块在不同显存压力下自适应调整，而不是一个压缩率打天下。实测下来，在16GB单卡上跑长对话时，门控会自动把压缩率提到50%以上；在短对话场景，压缩率则自动回落到20%-30%，保住更多细节。

2.4 对精度的影响分析与反例

自适应感知不是万能药，它有一个很明显的适用边界：低分辨率输入或小目标检测场景，剪枝带来的风险显著上升。低分辨率图像本身patch总数少，每个patch包含的信息已经比较稠密，强行剪枝等于在本来就有限的信息里再删掉一部分。

我在复现时专门做了一个反向对照实验：把图像分辨率从336降到224，patch数从576降到256，再应用同样的自适应剪枝策略，结果问答准确率掉了近7个百分点；而在336分辨率下，剪掉30%视觉token只掉了0.6个百分点。结论很清楚：自适应感知是有使用条件的，它更适合高分辨率、patch冗余度高、视觉语义分散的场景。低分辨率下宁可不剪，也不要激进压缩。

3. KV缓存优化：剪枝、量化、合并三条技术路线的取舍

3.1 重头Token保留策略的实现与改进

KV缓存剪枝的理论基础是：并不是所有历史token在生成后续内容时都同等重要。有一类token在注意力机制中持续获得高分，可以理解为整段对话的"提纲挈领者"，比如主语、关键名词、图像中的主体区域，业界一般叫它们重头Token（Heavy-Hitter Tokens）。另外大量token只在自己被生成的那个位置附近有作用，后续几乎不会被关注，属于可以被裁剪的对象。

我的实现思路是：为每个token维护一个累计注意力分数，当缓存长度超过预算时，按照累计分数排序，保留分数最高的那部分token，删除其余token。

这里面有几个细节特别容易踩坑。第一点，累计分数不能只算最后一层，要跨层聚合，否则某些层分布不均衡会导致误判。第二点，不能无脑保留"历史最高分"token，因为生成主题会漂移，开头的高分token到后面可能已经不再重要。我采用的方式是滑动窗口加权：最近N步的注意力分数权重更高，更早的分数按时间指数衰减。第三点，剪枝必须同步处理key、value、position_id、attention_mask四样东西，少一个位置都会导致后续位置错乱。

还有一个保险策略：强制保留每个句子的第一个token和最近的K个token。句首token往往承载句子的整体语义，最近token则是下一步生成最直接的上下文。这两个集合即使分数不高也不能剪，否则生成质量会突然崩塌。

3.2 KV Cache的INT8量化与混合精度设计

量化是压缩KV缓存最直接的手段。fp16降到int8，理论上显存直接减半。实际实现时不能简单地round-to-nearest，需要按token或按通道做缩放因子。

我的量化代码大概是这样：

class KVQuantizer: def __init__(self, bits=8): self.bits = bits self.qmax = 2 ** (bits - 1) - 1 def quantize_per_token(self, tensor_fp16): # tensor_fp16: [seq_len, num_heads, head_dim] absmax = tensor_fp16.abs().amax(dim=-1, keepdim=True) scale = (absmax / self.qmax).clamp(min=1e-6) q_tensor = torch.round(tensor_fp16 / scale).clamp(-self.qmax, self.qmax) return q_tensor.to(torch.int8), scale

反量化时直接q_tensor * scale即可。但这里有个隐性成本：scale本身也是要存显存的。如果每个token、每个头都存一个fp16的scale，节省的显存会被吃掉一部分。我的做法是scale按层共享，或者用fp8存储，把这部分额外开销压到最低。

更进一步的方案是混合精度KV缓存：对不同token区别对待。注意力分数高、被判定为重头token的，继续用fp16存储；其余token用int8甚至int4。理由是重头token是信息密集的关键路径，量化误差会被后续层逐步放大，非重头token则允许有更高的量化噪声。

实测中这个混合策略非常管用：KV缓存的平均存储成本可以降到纯fp16的一半以下，但精度表现远好于全部token统一用int8。它本质上是在"省显存"和"保精度"之间找了一个很聪明的平衡点。

3.3 视觉Token合并与缓存去冗余

剪枝是硬删除，token merging则是软融合。多模态图像中大量patch是高度相似的，比如纯色背景上的邻近patch，它们的K、V向量在语义上几乎一样，没必要各自占用一条KV缓存。可以把它们合并成一个代表token，用平均向量替代。

实现分三步：第一步，在视觉token集合内部计算余弦相似度矩阵；第二步，用贪心匹配给每个token找最近邻，要求两两不重复；第三步，把互相匹配的token的K、V按加权重平均合并，同时更新位置信息。

需要注意两点：一是合并只做视觉token，文本token语义密度太高，合并后信息损失不可控；二是合并轮数不宜过多，我实测一轮合并能减少约25%的视觉token，两轮能到40%以上，但三轮之后准确率开始明显下滑，主要是信息粒度太粗了。

token merging与剪枝相比，优点是信息不完全丢失，抗错性更强；缺点是计算开销更高，需要在生成前做额外的相似度矩阵计算。我的建议是用在"视觉token较多且密集相似"的场景，比如风景、纯色背景截图；对于文字截图这种信息本来就高度密集的输入，优先用硬剪枝。

3.4 三种方案组合后的显存变化实测

在项目X上，我把三条路线做了组合实验。基线是不做任何优化的fp16全量KV缓存；第二档只做自适应感知剪枝；第三档加KV cache INT8量化；第四档再叠加token merging。结果如下表：

从数据可以看出来，每叠加一层压缩，显存和延迟都在下降，准确率也在缓慢下降，但四档累计只掉了2.4个百分点，换来的是峰值显存从15.8GB降到7.4GB，省了一半还多。这个性价比在实际部署中相当可观。

不过要提醒一句：延迟下降并不是线性的。第二档到第三档之间，量化和反量化会引入额外计算，在部分GPU上延迟下降幅度会收窄；如果你用的是不支持快速int8运算的显卡，量化甚至可能让延迟变长。我在复现时也遇到过，后面踩坑清单里会细说。

4. Token容量扩展：不增加显存硬伤，如何塞下更多Token

4.1 Token容量扩展与KV缓存压缩的等价关系

项目标题里的"Token容量扩展"，我第一次理解的时候差点走入误区，以为是做长上下文外推或者改位置编码去扩展模型的context window。后来实际操作才发现，在推理部署的场景下，Token容量扩展其实是一个"预算管理"问题：你的显存总预算不变，KV缓存每token的成本降一半，你就能在同样的显存下容纳两倍的token。

好比一个行李箱，箱子大小不变，但你把每个人带的行李压缩了一半，那么能一起登机的人数就翻倍了。这跟模型本身支持多少上下文长度没有直接关系，纯粹是工程上的容量释放。

项目X上有一个很直观的例子：7B模型，16GB显存，权重用int4量化后约占4GB，剩下大约6GB可以分给KV缓存。fp16时每token约0.5MB，6GB只能容纳约12000个token；如果KV缓存经过自适应剪枝加量化，每token成本降到0.17MB，6GB就能容纳大约35000个token；再叠加token merging，每token成本降到0.11MB，能容纳的token数直接超过五万。这就是容量扩展的实际含义——不需要改模型架构，不需要重训练，只是把KV缓存做得更薄，就能在同样的显存预算下塞下更多的视觉token和历史对话。

4.2 位置编码调整在长上下文中的配合

如果确实需要把实际可推理的序列长度推到模型训练长度之外，位置编码就是绕不开的问题。旋转位置编码（RoPE）在训练长度内表现很好，但超出训练长度时，注意力分数会迅速失真，模型几乎没法继续生成有意义的文本。

常见的工程补救手段是把RoPE的基础频率做一次缩放，业界普遍叫NTK-aware缩放。它的核心思想是：不直接插值位置值，而是通过改变频率让高频维度按原节奏转动、低频维度适当放慢，这样模型能外推更多位置而不会立刻崩坏。我在项目X里做了两条数据的对比：不做任何缩放时，上下文长度从4096推到6144，生成质量已经开始退化；做基础频率缩放后，推到8192仍然能保持基本稳定的问答效果。

但我不建议在压缩KV缓存的文章里把位置编码外推说得太重要。它的作用是"让你有可能用得更长"，但真正让你敢用更长的底气，还是KV缓存压缩后的显存余量。两者是配合关系，不是替代关系。

4.3 视觉Token容量扩展时的位置重排问题

有一件特别隐蔽的事情，我复现时栽了好几个跟头，这里必须单独拿出来讲：视觉token做了剪枝或合并之后，位置编码不能直接沿用原来的索引。

多模态模型对图像patch位置的理解依赖的是2D位置编码。比如一张24×24的patch网格，剪掉了第三行第五列的patch之后，如果直接把后面所有patch的索引往前挪，视觉位置关系就错乱了——明明是左上角的patch，位置编码却变成了中间位置。这会导致模型对图像空间布局的理解完全错误，问答结果自然崩盘。

解决办法是保留"原始网格坐标"作为位置编码依据，而不是用"剩余token的顺序号"。剪枝之后，剩余token仍然使用它们在原始patch网格中的行列坐标，缺失的位置就空出来。这样模型依然能正确理解每个patch在图像中的真实位置。说起来简单，但很多实现都栽在这个细节上，因为默认的Transformer位置索引就是token顺序号，你得显式改掉这一层。

4.4 显存预算与Token容量的换算清单

为了方便实际部署时做预算，我给出一个速查清单：

• 7B模型，fp16权重，加上激活值和CUDA context，基础占用约14-15GB。这种情况下几乎不存在KV缓存空间，必选先量化权重。
• 7B模型，int4权重，基础占用约4-5GB。剩余显存可以全部视为KV缓存预算。
• KV缓存每token成本：fp16约0.5MB，int8约0.25MB，剪枝加混合精度约0.15MB，剪枝加量化加合并约0.10MB（具体数值随模型层数、头数、head_dim变化）。
• 用"预算 ÷ 每token成本"就能算出理论上限：比如6GB预算，fp16只能放12000 token，压缩到0.10MB后能放60000 token。

这张清单就是Token容量扩展的底层逻辑：一切都不靠魔法，只靠单位token存储成本的降低。

5. Python复现的完整路径：从环境搭建到结果评估

5.1 环境、依赖与模拟数据准备

我复现时用的是一台16GB显存的单卡机器，Python 3.10，PyTorch 2.1，CUDA 12.1。依赖主要就四个：transformers用于加载模型和生成，flash-attn用于加速注意力计算，bitsandbytes用于权重量化，pynvml用于实时监控显存。

这里要特别说一句：我把复现目标定义为一个中等规模的多模态视觉语言模型，本文统一用"M-VLM-7B"代称，它是我在模拟项目X中使用的模型底座，结构上是标准的视觉编码器加语言模型。数据集也是本地构建的图文问答样本集，总共1000条，包含场景描述、文字截图理解和简单的空间关系问答，图像统一缩放到336×336。这样整个复现链路不依赖任何大型外部数据集，跑一遍只需要一个多小时。

5.2 KV Cache量化与剪枝的核心代码

KV cache量化部分，核心函数就是前面展示的KVQuantizer。但真正落到生成流程里，还需要把它挂到模型的计算图上。为了不改动模型内部代码，我采用的方式是包装生成循环：每一轮生成结束，取出模型的past_key_values，对其中每一个K、V矩阵做量化，再放回去。

剪枝部分的代码更像这样：

def prune_kv_cache(past_key_values, token_scores, keep_ratio): # token_scores: [seq_len]，累计注意力分数 keep_len = max(int(seq_len * keep_ratio), min_keep_len) keep_indices = torch.topk(token_scores, keep_len).indices.sort().values new_past = [] for layer_kv in past_key_values: k, v = layer_kv # [batch, heads, seq_len, dim] new_past.append((k[:, :, keep_indices, :], v[:, :, keep_indices, :])) return new_past

这里必须再次强调：keep_indices除了用于剪裁K、V，还要同步传给后续的位置编码和attention mask构建模块，否则位置就错位了。

5.3 视觉Token自适应剪枝的完整实现

自适应剪枝的完整流程在预填充阶段执行，我拆成了三步。

第一步，跑一次完整的预填充前向，拿到各层注意力权重。第二步，按2.2节的方法计算每个视觉token的重要性分数，并用软化和显著性先验修正。第三步，按门控算出的压缩率，选取要保留的视觉token集合，然后把原始输入序列中不重要的视觉token删掉，重新构造压缩后的输入，再跑一次前向生成压缩后的KV缓存。

核心代码示意：

def adaptive_visual_pruning(image_input, text_input, model, score_fn, gate_fn): # 第一步：预填充，收集注意力 inputs = build_inputs(image_input, text_input) outputs = model(inputs, output_attentions=True) attn = outputs.attentions # 第二步：计算视觉token重要度 scores = score_fn(attn, inputs.visual_indices, text_last_idx=inputs.text_last_idx) compression_rate = gate_fn(outputs.kv_cache_bytes, entropy_of(scores)) # 第三步：保留top-k视觉token，重构输入 keep_count = int(len(inputs.visual_indices) * (1 - compression_rate)) keep_idx = topk(scores, keep_count).indices new_image_input = merge_patches(image_input, keep_idx) new_inputs = build_inputs(new_image_input, text_input) compressed_kv = model(new_inputs, use_cache=True).past_key_values return compressed_kv

注意第三步中merge_patches并不是简单索引，它需要在视觉编码器层面操作patch序列，因为只删掉语言模型层的KV不够，还得让视觉编码器生成的就只有这些patch的特征。这也是为什么自适应感知必须在预填充阶段做，因为一旦进入生成阶段，视觉token的KV缓存已经和文本token混在一起，再想"从头省"就来不及了。

5.4 评估脚本的指标设计

评估指标如果只看准确率会漏掉很多信息。我设计了一套四维评估：

• 问答准确率：衡量压缩后的模型能力损耗。
• 峰值显存：用pynvml监控整个生成过程的显存最大值，这是硬约束。
• 每token生成延迟：反映压缩带来的计算开销是否值得。
• KV缓存的每token平均成本：直接反映压缩率，方便做容量换算。

评估脚本的基本框架是先跑一批样本的基线结果，再跑各压缩档位，最后汇总成5.3节那种对比表格。我强烈建议做评估时把"逐步增加压缩率"作为固定动作，而不是只测一档。因为不同模型对压缩的敏感度差异很大，只有画出"压缩率-准确率-显存"的曲线，你才能找到适合自己的最佳工作点。

6. 实测数据与踩坑清单

6.1 各压缩档位的效果对比

项目X上的完整数据前面已经给过一张组合表，这里再给一张更细的分档表，按压缩深度细分：

我的建议是部署时优先选均衡档，它在准确率和显存收益之间最平衡。极限档虽然显存省得更多，但掉点已经比较明显，除非显存真的卡死在极端预算下，否则不建议日常使用。

6.2 最容易踩的5个坑及排查方法

第一个坑：只剪KV缓存，不改位置编码和attention mask。后果是生成到后半段突然毫无逻辑，因为所有token的位置关联全乱了。排查方法很简单，生成一段长文后检查attention分布是否仍然平滑，如果出现断层，九成是位置索引没同步。

第二个坑：量化KV缓存时把scale也保存在显存里，导致显存节省缩水。排查方法是通过pynvml对比量化前后的实际峰值显存，如果只降了不到30%，大概率是scale和中间临时tensor的开销吃掉了收益。

第三个坑：flash-attention等高效kernel要求KV缓存是连续的、完整的，一旦做了剪枝，部分kernel会触发回退到标准实现，速度反而变慢。我踩到过显存降了但延迟反而涨了的情况。排查方法是看日志里有没有kernel fallback的警告；如果有，要么换支持稀疏KV的kernel，要么把剪枝粒度改成块级别，让KV尽量保持连续。

第四个坑：剪枝时采用了固定top-k，把关键token误删了。我前面提到过，纯按注意力分数硬截断在高信息密度图像上风险很高。保险做法是加入强制保留集合（句首token、最近K个token）再跑top-k。

第五个坑：长序列生成后期，量化误差逐渐累积，导致输出质量越来越差。这是量化KV缓存的通病，误差会随着token数增加被放大。排查方法是对比短序列和长序列的困惑度上升曲线，如果长序列掉点明显，建议对最近一段token使用更高精度存储（比如int8缓存中最后256个token用fp16）。

6.3 参数调优与后续可扩展的方向

调参方面，我最后分享三点个人经验。

第一，压缩率不要一上来就设50%。从20%起步，每次加10%，用50条样本快速验证，再决定是否继续加压。这个习惯帮我避免了多次"压缩一时爽，精度火葬场"的尴尬。

第二，门控里的显存压力信号非常重要，但注意别让它太灵敏。如果显存稍有波动就把压缩率瞬间拉满，生成的稳定性会受影响。我给压力系数加了一个滞后带：显存使用超过80%才快速上调压缩率，低于60%才缓慢回调。

第三，视觉token重要性评分不一定非要用最后一层注意力。实际上中间层的视觉语义更接近视觉编码器的输出，还没被文本信息过度融合，在有些模型上中间层打分比高层更准。你可以用两三层做平均，一般都比单独取最后一层好。

扩展方向上，我觉得这套框架可以继续和投机解码、稀疏注意力结合。投机解码能减少生成步数，稀疏注意力能从计算图上减少注意力开销，和KV缓存压缩正好在不同维度发力。项目X后续我会把这几件事统一进一个推理服务里，看看端到端延迟还能压到什么程度。这算是目前我最期待的一个方向。