实例分割新范式：Falcon Perception技术剖析

type

Post

status

Published

date

May 30, 2026

slug

falcon_perception

summary

这篇文章讨论的是一个很有意思的问题：dense perception任务是否一定需要encoder-decoder结构？目前开放词汇检测、promptable segmentation、OCR这类任务，常见做法大概是： • 先用一个vision backbone提取图像features • 单独的 decoder 或 late-fusion module 将这些 features 转换为任务输出虽然上面的范式在业内已经验证了有效性，但它的问题也很明显。模块越多，视觉语言的交互较晚，并且系统的复杂度也会更高。针对dense perception的任务特点，作者提出以下关键设计：1)Unified Dense Transformer with Hybrid Attention Mask; 2)Chain-of-Perception; 3)Specialized heads

1 Motivation

这篇文章讨论的是一个很有意思的问题：dense perception任务是否一定需要encoder-decoder结构？

目前开放词汇检测、promptable segmentation、OCR这类任务，常见做法大概是：

先用一个vision backbone提取图像features

单独的 decoder 或 late-fusion module 将这些 features 转换为任务输出

虽然上面的范式在业内已经验证了有效性，但它的问题也很明显。模块越多，视觉语言的交互较晚，并且系统的复杂度也会更高。

针对dense perception的任务特点，作者提出以下关键设计：1)Unified Dense Transformer with Hybrid Attention Mask; 2)Chain-of-Perception; 3)Specialized heads

下面具体来看。

2 Method

2.1 问题定义（Chain-of-Perception）

对于dense perception的任务而言，一张图片的实例可能在0到几百不等，如何设计输出接口即支持variable-length instances又不会让decoding的代价过高是关键。

Falcon-Perception采用自回归的架构做variable-length instances的生成。如果直接把bbox、polygon或者mask都离散成普通token，每个实例都会带来很长的输出序列，实例一多decoding代价就会迅速上升。为了规避这个问题，Falcon-Perception设计了一种Chain-of-Perception的生成方法。

具体来说：假定自回归模型输入的prefix如：

其输出的序列

从上面不难看出，在segmentation路径下，每一个实例都由：<coord> <size> <seg> 3个触发token构成。

<coord> 代表实例的中心点坐标

<size>代表实例的宽高

<seg>代表实例mask query的生成位置

通过这个方法，模型没有把真实mask逐点写进文本序列，而是把一个实例的输出接口压缩为几个结构化token；连续坐标和高分辨率mask再交给specialized heads解码。并且<coord> -> <size> -> <seg>这个生成顺序要求模型先解决spatial ambiguity，再解决pixel-level details，是一个coarse-to-fine的curriculum过程，训练相对稳定。

从 <coord> <size> <seg> 解码出实例真实的mask需要额外的special head，在后面的章节详细介绍。

2.2 模型架构

模型架构上，作者放弃了额外引入encoder，而是类似Fuyu8B的做法，直接将图片patch化与文本拼接后，送入到单一的transformer中。这里有几点设计细节需要注意：

2.2.1 输入准备

以一个具体的例子理解

<|image|>是图片token的占位符。

给定输入图片，先patch化，再经过linear层后，放到占位处，与文本token进行拼接 $$ X=[\underbrace{v_{1},\ldots,v_{N}}{\mathrm{Visual~Embeddings}},\underbrace{t{1},\ldots,t_{L}}_{\mathrm{Text~Embeddings}}] $$

注1: 对于常规的多模态模型会将visual embedding部分送入到encoder，将encoder的输出与text embedding进行拼接，falcon perception省略了这个过程。

注2: 图片token之间会被表征图片起始、终止的token包裹。并沿用了Dino-v2的register token，以提升patch token聚合信息的质量。

2.2.2 hybrid attention mask

falcon-perception的hybrid attention mask可以理解为一种image-prefix bidirectional attention + 后续causal attention。具体而言：

图片token之间设置为bidirectional attention，文本和task位置为causal attention；文本/task token可以看到完整的image prefix

2.2.3 3D RoPE

falcon-perception的3D-RoPE与Qwen系列的MRoPE实现不同。它将q，k的通道进行对半切分，一半用于编码空间位置信息的2D-RoPE，另一半用于序列/时序信息的1D-RoPE编码。这里有几个小细节：

时序维度，image block内部基本共享同一个temporal ID，后续文本token再继续递增。

空间维度，只有真实image patch会被赋予2D空间坐标；文本和其它非空间token的2D位置为0。

2.3 Special Head

在2.1，2.2节中，我们已经理解了falcon-perception如何定义dense-perception问题，以及它如何把图像patch、文本prompt和任务token放进同一个Transformer。本小节补上最后一块拼图：模型预测出的special token <coord> <size> <seg>，到底如何转化成bbox和mask。

这里有一个关键点：LM head只负责预测“下一个token是什么”。但<coord>、<size>和<seg>并不是普通文本内容，它们更像是调用不同head的触发器。

代码中对应的模块集中在：

2.3.1 Coord / Size Head

很多自回归视觉模型会把坐标当成普通token集成到词表中。比如定义一组0到999的token表示坐标：

这样就可以把检测、分割问题转化为token预测问题，再通过后处理解析坐标。

上述方案实现简单，也在很多模型上得到了验证，例如检测领域的Pix2Seq，以及一些OCR/文档解析模型中的location token设计（如MinerU）。但它有几个明显弊端：

坐标token的embedding相对离散，坐标的空间位置关系只能被隐式学习。

坐标精度受bin数量限制，bin太少会粗糙，bin太多又会增加词表或序列建模难度。

如果把mask边界也转成token序列，dense output会非常长，不适合高实例数场景。

Falcon Perception采用的是另一种折中方案：序列里仍然只生成<coord>和<size>这两个special token，但真实的连续坐标由额外的bbox head预测。

模型初始化时可以看到四个相关模块：代码位置：https://github.com/tiiuae/Falcon-Perception/blob/main/falcon_perception/model.py#L317

这四个模块分成两组：

encoder：把已经得到的连续坐标/尺寸编码回Transformer输入流中。

decoder：从Transformer hidden state中预测连续坐标/尺寸。

Fourier Encoder：把连续值注入token embedding

训练时，target序列里有<coord>和<size>位置，但模型不能只看到一个静态special token embedding。否则后续的<size>和<seg>并不知道前一步真实预测/标注的中心点在哪里。换句话说，常规的做法<coord>对应的是这个token得embedding，但无法提现示例的信息，因此需要用真实的坐标信息的embedding来对它进行替换。也就是说，<coord>可以视作是一个placeholder。

那么，如何构建这个坐标信息的embedding呢？

坐标信息的编码：

Falcon Perception采用Fourier feature mapping的方式构建坐标的embedding （Nerf中的做法），核心思路是用连续空间的频率模式来表示坐标。

x为坐标信息

B为随机频率矩阵

这个思路将坐标学习转化为了频率模式匹配问题。

代码中对应 https://github.com/tiiuae/Falcon-Perception/blob/main/falcon_perception/model.py#L34：

坐标信息解码：

推理时，模型先通过LM head采样下一个token：

如果采样出的token是<coord>或<size>，则调用：

内部会将当前hidden state送入两个MLP decoder：

https://github.com/tiiuae/Falcon-Perception/blob/main/falcon_perception/model.py#L705

坐标x, y按归一化bin预测。尺寸h, w则不是线性bin，而是经过process_sizes映射到log2尺度：

这样做比较合理，因为目标尺寸天然是跨尺度分布的：小目标之间的差异需要更细粒度，大目标则更关注相对比例。

得到xy或hw后，它们会在下一步forward时重新编码回输入序列：

完整链路：

Step1: LM head预测 <coord>

Step2: 将hidden state输入到coord decoder中，输出中心点

Step3: Fourier encoder将中心点编码为embedding，写入下一步输入

Step4: LM head预测 <size>

Step5: 将hidden state输入到size decoder中，输出宽高

Step6: Fourier encoder将宽高编码为embedding，写入下一步输入

Step7: LM head预测 <seg>

2.3.2 Segmentation Head

<seg>也可以理解为placeholder。需要引入额外的head提取真实的mask。只用单个token的hidden state来生成high-resolution的mask是比较难的。Falcon Perception采用了一种dot product的方式来生成mask。

具体来说，在prefill阶段，将image patch token位置的所有hidden state与原图送入到一个模型中，获得一个feature map V* ∈ R^{H×W×d} （AnyUP这篇paper的做法）。代码位置：https://github.com/tiiuae/Falcon-Perception/blob/main/falcon_perception/batch_inference.py#L248

生成阶段中，若当前生成的token为<seg>, 随后对其hidden state进行linear transform后与上述feature map做点乘，从而得到mask，代码位置：https://github.com/tiiuae/Falcon-Perception/blob/main/falcon_perception/aux_output.py#L210

相比Mask2Former需要用复杂的 Hungarian matching 来解决 instance ambiguity问题。Falcon Perception设计的<coord><size><seg>链路的指代是清晰的。

2.4 如何训练

2.4.1 训练目标概览

理解完上面的结构后，训练逻辑其实就比较自然了：Falcon Perception不是把dense perception完全变成普通语言建模，而是采用“自回归token + speaial head解码”的混合建模。

换句话说，Transformer主干按next-token prediction训练；但当序列走到<coord>、<size>、<seg>这些位置时，模型还会额外接收对应的坐标、尺寸和mask监督。

目标函数有下面几部分构成

其中：

：普通token的cross entropy，包括文本token和<coord>、<size>、<seg>`这些special token的生成。

：坐标head的cross entropy。代码中coord_decoder输出2 x Nbins个logits，默认每个维度2048个bin。

：尺寸head的cross entropy。注意：尺寸不是线性空间，而是log2尺度上的bin

：mask监督，使用focal loss + dice loss。

：主要包括蒸馏/特征对齐相关loss，比如Gram feature alignment。

可见，坐标和尺寸虽然最终是连续值，但训练时仍然转成bin分类问题；mask则没有被转成token序列，而是用像素级loss直接监督。这个设计避免了把高维dense output硬塞进语言序列。

2.4.2 更多的训练细节

（一）multi-teacher distillation

teacher模型有2个：DINOv3-ViT-H和SigLIP2-So400m

为了训练好early-fusion perception models，作者使用 multi-teacher distillation pipeline 初始化模型权重。其动机是利用不同 vision backbones 的优势。

论文对这一步没有公布太多的细节。有几点是明确的：

这个蒸馏不是简单的logits蒸馏。

蒸馏的核心目的之一是为了让模型能够继承DINOv3-ViT-H强大的提取local feature的能力，这对segmentation很重要。

目的之二期望继承SigLIP-So400m图文embedding对齐的特性，便于 open-vocabulary expression understanding。

蒸馏的数据： OpenLVD200m , 900 万 high-resolution scraped images,1100 万 SAM dataset images, 500 万 documents。

训练流程：

multi-resolution stage，最高到 1024×1024 pixels，约 200k steps
Muon为优化器
4*8-A100 GPU nodes，采用sequence packing
local batch size 为 6，最大 sequence length 为 4096 tokens

（二）优化器的选择

Falcon Perception对Muon和AdamW这两个优化器做了消融实验。在perception这个场景下，Moun优化器有明显的优势

（三）masking order

当有多个实例时，该如何设计target sequence的顺序呢？（本质上就是：一个包含多实例的图片，有多条合理的轨迹）。作者比较了random、按照size从大到小、按照raster order（自上而下、自左到右）。作者发现raster order的方式效果更好（直觉上这个方法先验的约束了轨迹，限制了模型需要拟合的轨迹空间）。

更多的细节请参考原论文。

3 结果

结果部分我觉得主要看三个点。

第一，Falcon Perception在SA-Co上mask quality比较强，Macro-F1达到68.0，高于SAM3的62.3，但 presence calibration 明显弱于 SAM3，例如 Average MCC 是 0.64 vs 0.82。

第二，在PBench(论文提出的benchmark)上优势明显。PBench更强调attribute、OCR、spatial relation和dense场景，这些任务都需要更强的视觉-语言-空间联合建模。论文中Falcon Perception平均57.0，SAM3为44.4；Dense场景下是72.6 vs 58.4。

第三，sampling对结果提升很大（类似语言模型中do-sample的做法，同个数据多跑几次，非贪心采样）。SA-Co上cgF1可以从baseline的34.7提升到Pass@8的54.3。这说明模型分布里其实包含不少正确答案，只是greedy decoding未必总能选中。

作者额外研究了将Falcon-Perception架构应用到OCR领域中，提出了Falcon-OCR-0.3B。笔者实测下来，效果还有提升空间，可能是训练的数据规模不够大。

4 小结

本文系统梳理了Falcon-Perception的技术原理。整体上，论文中的工作量是非常扎实的，不论从代码上、数据上还是实验上，值得一读。

ㅤ	info
paper	https://arxiv.org/abs/2603.27365
code	https://github.com/tiiuae/Falcon-Perception
org	TII Falcon Vision Team
model	https://huggingface.co/tiiuae/Falcon-Perception
benchmark	https://huggingface.co/datasets/tiiuae/PBench