PARCEL: 基于池锚定重采样与条件弹性查询的高效视觉-语言理解

TL;DR PARCEL 用池化锚点保留空间布局，以条件弹性查询补充细节，在多种视觉标记预算下统一解决压缩混叠与定位退化，提升效率-性能帕累托前沿。

问题

问题背景

LVLM 推理受限于视觉 token 生成的密集序列，其自注意力计算复杂度随 token 数二次增长，成为部署瓶颈。弹性视觉 token 压缩旨在训练单一模型，使其能在多个 token 预算下运行，实现“训练一次，随处部署”，已成为兼顾精度与效率的核心范式。

现有方法局限

现有弹性压缩方案可归为两类，但均存在难以调和的缺陷：

• 空间压缩（如嵌套池化）：本质为低通滤波，缺乏抗混叠设计，在高压缩比下引发频谱混叠 (spectral aliasing) ，破坏高频细节，导致 OCR、小目标识别等细粒度任务性能断崖式下降。
• 查询压缩（如嵌套查询重采样）：用可学习的查询 token 替代网格对齐 token，虽能提取全局语义，却牺牲了显式的空间映射关系，造成空间定位 (spatial grounding) 能力严重退化，难以胜任文档理解、图表问答等需要精确坐标感知的场景。 两种范式互斥，无法在单一模型中兼顾低预算下的空间布局与语义细节。

为什么这个问题难且重要

核心挑战在于：低 token 预算下必须同时保留低频空间锚点和高频语义补充，但传统方法缺乏特征提取的任务分工，导致信息折损不可逆。频谱分析揭示池化压缩的混叠效应源于下采样前缺失抗混叠滤波，而查询压缩则忽略了 token 间的拓扑约束。该问题直接制约 LVLM 在资源受限设备（移动端、边缘计算）的实用化，以及多模态 Agent、具身智能等需实时空间推理的场景。此外，弹性“一次训练，多预算部署”要求架构在所有预算层级均维持可用性能前沿，这考验模块设计的组合泛化性。

行业类比

类似视频编解码中 I 帧与 P 帧的分工：I 帧提供全帧基准，P 帧编码差异；PARCEL 以池 token 作为空间锚点，查询 token 补充差异特征，在压缩与保真度间取得协作平衡。

核心洞察

• Pool-Conditioned Query Resampling 通过把特征提取任务拆分给空间锚点 token 和弹性查询 token，解决了仅空间压缩的频谱混叠与仅查询压缩的空间定位退化之间的表示冲突。与既有 Matryoshka 方案单一压缩范式不同，该设计鼓励查询 token 聚焦于互补的高频细节，使模型在激进压缩下仍能维持细粒度感知与空间 grounding。
• Budget-Aware Piecewise Routing 和 Nested Dropout 使单一模型在多个视觉 token 预算下都能高效推理，无需重训即可逼近各预算独立模型的上界。相比均匀预算或简单嵌套基线，该路由策略动态分配计算资源，扩展了“一次训练、随处部署”的帕累托前沿，尤其提升了低预算区间的实用性。

方法

PARCEL 的视觉标记化流程从视觉编码器输出的密集特征图开始。首先通过空间池化（如自适应平均池化）生成一组固定数量的池标记（pool tokens），它们作为低频布局锚点，保持粗粒度的空间结构，避免纯池化导致的谱混叠与细节丢失。

随后，在池条件查询重采样（Pool-Conditioned Query Resampling）阶段，引入一组可学习的弹性查询标记（query tokens）。这些查询标记通过交叉注意力机制，以池标记为条件，动态地从视觉特征图中聚合信息。设计上，查询标记不再绑定于网格坐标，而是聚焦于互补的高频细节，同时依赖池标记提供的空间上下文，从而缓解纯查询方法中常见的空间定位退化问题。

为进一步支持多预算部署，PARCEL 采用预算感知分段路由（Budget-Aware Piecewise Routing）和嵌套丢弃（Nested Dropout）训练策略：

• 分段路由为不同 token 预算（如 64、128、256）分配专门的查询标记子集，使模型能高效运行在不同计算约束下。
• 嵌套丢弃在训练时随机保留靠前的子集，迫使查询标记按重要性排序，实现单次训练即可弹性调整 token 数量。

最终，池标记与选定数量的查询标记拼接为统一的视觉 token 序列，输入语言解码器。该方法的核心差异在于动态分工：池标记锚定全局布局，查询标记补充细节，二者协同避免了纯空间压缩的混叠伪影与纯查询压缩的空间漂移，同时通过训练一次即可覆盖多个推理预算，显著提升了效率-性能帕累托前沿。

实验

实验设计

评估覆盖27个基准，涵盖视频理解（VATEX）、通用VQA（VQAv2）、文本VQA（TextVQA）、文档与图表解析（DocVQA, ChartQA）等。采用多任务、多分辨率、多视觉token预算（如16–576 tokens）的弹性部署设定。基线包括仅空间压缩的嵌套池化（如FasterViT）与仅查询压缩的嵌套查询重采样（如Matryoshka Query）。以PaliGemma-2系列模型为骨干，通过统一训练流程实现一次训练即可在任意token预算下推理（train once, deploy anywhere）。

关键发现

PARCEL 在所有视觉token预算下均建立了新的性能–效率帕累托前沿，且低预算时优势最为突出。与仅空间池化相比，它通过在池锚点上条件化查询，有效抑制了频谱混叠，保留了更多纹理细节；与仅查询重采样相比，池锚点提供了显式布局参照，显著改善了空间定位能力（如RefCOCO指向精度）。在高分辨率文档、图表任务上，PARCEL以约50% 的token预算即可达到与全量token相当的性能。在极低预算（如16 tokens）下，嵌套池化出现严重细节丢失，嵌套查询则产生位置漂移，而PARCEL依旧保持语义完整与空间准确。

与基线的深度对比

传统空间池化能保留局部邻域关系，但在激进压缩时会产生频率混叠，类似于低通滤波失效，导致小物体和纹理丢失。纯查询重采样能全局聚合信息，却丢弃了网格对齐的位置先验，造成“回答正确但位置错误”的问题。PARCEL将二者分工：池token作为稳定布局锚点（低通信号），查询token作为弹性特征补充（高通细节），通过Pool-Conditioned Query Resampling实现互补融合。这种设计在极低预算下仍能维持语义完整性与空间准确性，从而推动帕累托前沿整体上移，并避免了现有方法在单一压缩策略下的瓶颈。

行业影响

落地场景

PARCEL 的弹性视觉 token 压缩可直接用于多模态对话助手、移动端视觉搜索、智能座舱交互、工业质检与文档解析等场景。由于单一模型支持多个 token 预算（如 64/128/256 tokens），同一权重可按需部署到云服务器、边缘设备甚至浏览器端，让视觉语言模型覆盖从高精度离线分析到低延迟实时交互的完整谱系。

商业价值

• 降本：推理时动态选择 token 预算可大幅降低 FLOPs 与 KV-cache 占用，在相同硬件上提升吞吐量，减少云端 GPU 实例费用。
• 增收：更低的延迟和弱网环境下的高可用性，可提升用户留存与转化率。
• 体验提升：在资源受限设备（如手机、可穿戴设备）上实现接近大预算时的性能，避免因压缩过度导致的空间定位失败或细节丢失，保障可用性。

与现有产品/工作流的接口

PARCEL 可以作为视觉编码器与语言模型之间的弹性 tokenizer 集成到现有 LVLM 推理管线。它提供 Pool-Anchored Resampling 与 Budget-Aware Piecewise Routing，训练时只需一次 run，部署时通过简单的 budget 参数切换即可输出不同数量的 token。推理框架（如 vLLM、TensorRT-LLM）可将 PARCEL 包装为一个支持动态 shape 的算子，无需反复加载不同模型。

具体落地 use case

1. 电商视觉搜索：用户上传商品图片进行相似款搜索。峰值流量时，系统自动切换至低 token 预算（如 64 tokens），确保 10ms 内返回候选，同时维持细粒度属性理解能力（颜色、纹理、logo）。非高峰时段恢复高预算以提升长尾查询的 recall。
2. 自动驾驶环视理解：车载 VLM 同时处理 6 路摄像头输入，每帧总 token 数直接影响决策延迟。PARCEL 允许根据车速动态分配每路 token 预算：高速时降低远景摄像头预算，聚焦前向高精度感知；泊车时提升环视稠密特征，保证空间定位准确性，无需切换模型。

局限

• 1. **训练开销与复杂度**：PARCEL 引入预算感知分段路由（budget-aware piecewise routing）和池条件查询重采样，虽然实现了“训练一次、多处部署”，但训练过程中需同时优化多个token预算路径，可能导致训练内存和计算成本高于单预算模型。此外，路由策略依赖于预设的预算档位，若实际推理时所需预算未在训练中见过，模型可能仍需回退或重新训练，灵活性受限。
• 2. **对空间细节任务的上限**：尽管池锚定设计旨在缓解纯查询压缩的空间定位退化，但池化本身作为低通滤波器仍会丢失高频纹理信息。在极端低预算下，空间锚点数量过少，可能限制密集空间定位任务（如分割、小目标检测）的性能，与直接用全分辨率token的方法相比仍有差距。论文未详细分析不同池化核大小对频率响应的影响，可能在实际高分辨率场景中需要额外的池化策略调整。
• 3. **跨模态泛化能力未验证**：评估集中在图像和视频理解基准，但未涉及与纯文本推理或其他模态（如音频）的混合任务。弹性token压缩是否在多模态交织输入下保持稳定，以及池条件查询是否会在长序列中引入新的注意力偏差，仍需进一步探索。实际部署中，接口兼容性与现有LVLM框架的迁移成本也是一个潜在问题。