多模态PaliGemma——Google推出的基于SigLIP和Gemma的视觉语言模型(含SigLIP详解)

前言

本文怎么来的呢？其实很简单，源于上一篇文章《π0——用于通用机器人控制的流匹配VLA模型：一套框架控制7种机械臂(改造了PaliGemma和ACT的3B模型)》中的π0用到了PaliGemma

故本文便来解读下这个PaliGemma

第一部分 PaliGemma

1.1 PaliGemma：基于 SigLIP--So400m 和 Gemma-2B

1.1.1 PaliGemma的发展历史

PaliGemma 是一个开放的视觉语言模型（VLM），基于 SigLIP--So400m 视觉编码器和 Gemma-2B 语言模型

其结合了PaLI视觉语言模型和Gemma语言模型家族的特点

PaLI是一系列最先进的视觉-语言模型，最初的PaLI [23-PaLI:A jointly-scaled multilingual languageimage model]展示了有前景的扩展结果，规模达到了170亿，使用了分类预训练的ViT [131]和mT5 [126]语言模型

随后，PaLI-X [24-PaLI-X: On scaling up a multilingual vision and language model]和PaLM-E [36- PaLM-E: An embodied multimodal language model]进一步推进了这一点，分别结合了ViT-22 B [29]，和32 BUL2 [104]语言模型或540 B PaLM [28]语言模型，并在视觉-语言任务上获得了更高的性能，尽管在标准图像分类和检索任务上的性能趋于饱和

最后，PaLI-3 [25- PaLI-3 vision language models: Smaller, faster, stronger]证明，通过使用SigLIP [133- Sigmoid loss for language image pre-training]进行更好的预训练和更仔细的多模态数据策划，一个2B视觉和3B语言模型（即一个5B视觉-语言模型）可以在大多数基准测试中，与规模大10倍的55B PaLI-X(22B视觉 + 32B语言)、和规模大100倍的562B PaLM-E(22B视觉 + 540B语言)相匹敌
PaliGemma 延续了这一趋势，将 400M SigLIP 和 2B Gemma 模型 [82] 结合成一个小于 3 B 的 VLM，同时仍然保持与 PaLI-X、PaLM-E 和 PaLI-3 相当的性能

至于Gemma [82]，则是一个自回归解码器专用的开放大型语言模型家族，基于用于创建Gemini [7] 模型的相同研究和技术构建。这些模型有不同的大小(2B、7B)，都经过预训练和指令微调，而PaliGemma使用了2B预训练版本「关于gemma的介绍，请见此文：一文速览Gemma1和2及其微调(第5.2版)：通过我司七月的早期paper-7方面review数据集微调Gemma2」

1.1.2 PaliGemma的三个组件：SigLIP、gemma-2B、线性层

总之，PaliGemma由三个组件组成

一个图像编码器，使用SigLIP，其shape optimized ViT-So400m图像编码器，该模型通过sigmoid损失在大规模上进行了对比预训练，且其在小尺寸上也表现出色
一个仅解码器的语言模型，使用gemma-2B v1.0，该模型可以匹配或超越使用相对更大些的语言模型的VLMs的性能，包括之前的PaLIs
一个线性层，将SigLIP的输出投影到与gemma-2B的词汇token相同的维度，以便它们可以被连接「其实PaliGemma的作者也不是没考虑别的选择，而是在他们的早期实验中，他们发现更复杂的替代方案——MLPs，并没有提供明显的优势，因此决定使用最简单的选项」

具体训练时

图像通过图像编码器传递，将其转换为一系列 $N_{\mathrm{img}}$ token，且图像token通过（零初始化的）线性投影进行投影
文本使用Gemma的SentencePiece [58] 分词器转换为 $N_{\mathrm{txt}}$ token，并嵌入到Gemma的词汇嵌入层中
然后，解码器的输入token序列按如下方式创建，如下图图2所示「一般而言，输入为一张或多张图像，以及任务的文本描述（提示或问题，通常称之为 prefix），PaliGemma 然后以文本字符串的形式自回归生成预测（答案，通常称之为 suffix）」，其在图像和前缀中进行块注意，在后缀上进行自回归注意，每个方块表示该行是否可以关注该列

即有

$\begin{aligned} \text { tokens }= & \text { [image tokens..., } \\ & \text { BOS, prefix tokens..., SEP, } \\ & \text { suffix tokens..., EOS, PAD...] } \end{aligned}$

可以发现，过程中，一般始终将图像调整为固定的正方形大小（224、4488或896像素）。这导致每个模型变体的图像token数量固定（分别为256、1024或4096个token），且将其放在前面，使图像token易于解释，无需特殊位置token

然后BOS标记标记文本token的开始。作者使用 \n作为SEP标记，它不会出现在任何前缀中。且还将SEP单独标记，以避免它与前缀的结尾或后缀的开头合并（由标记器）

另为了最大化这样一个小模型的模型容量，对整个输入有完整的(未mask的)注意力，包括图像和前缀token「In order to maximize model capacity for such a small model, we have full (unmasked) attention on the whole input, i.e. the image and prefix tokens.说白了，就是图像token可以看到整个输入：图像token和前缀token，而前缀token也可以看到整个输入：图像token和前缀token」
$\rightarrow$ 通过这种方式，图像token也可以“前瞻”手头的任务（前缀），以更新其表示
$\rightarrow$ 后缀是输出，必须由自回归掩码覆盖，包括PAD token
当提到序列长度（ $N_{\mathrm{txt}}$ ）时，通常指的是前缀和后缀的组合，忽略图像token

1.2 预训练：先后进行单模态预训练、多模态预训练、分辨率增加、迁移

PaliGemma的训练遵循与之前的PaLI模型相同的步骤，仅进行了小的修改。训练包括以下几个阶段

1.2.1 阶段0: 单模态预训练

首先，模型的单模态组件单独进行预训练，以便从其经过充分研究和扩展的训练方案中受益。对于PaliGemma，没有进行任何自定义的单模态预训练，而是依赖于现有的公开可用的检查点

根据PaLI-3的强实验结果，Google使用SigLIP图像编码器。虽然PaLI-3（和其他[6,26]）使用大型图像模型如ViT-G，但PaliGemma使用了更小但同样强大的“形状优化”ViT-So400m模型

至于语言模型上，则使用gemma-2B

1.2.2 阶段1：多模态预训练

一般而言，也是之前的PaLI版本所遵循的，是在第一个多模态预训练阶段保持图像编码器冻结。这部分是由于LiT [132]中的研究发现，多模态调优预训练图像编码器会降低其表示能力

然而，最近的研究如CapPa [110]和LocCa [115]表明，字幕生成和其他难以学习的任务可以为图像编码器提供有价值的信号，使其能够学习空间和关系理解能力，而对比模型如CLIP或SigLIP通常缺乏这些能力
因此，为了在预训练期间学习更多技能，作者打破常规，不冻结图像编码器。然而，LiT中概述的挑战依然存在
且为了避免来自最初未对齐的语言模型的破坏性监督信号，作者对图像编码器的学习率采用缓慢的线性预热（如下图图3所示），以确保图像编码器的质量不因最初未对齐的梯度通过LLM而恶化
总之，在分辨率224px下训练Stage1（因此，img = 256个图像标记）和序列长度25txt = 128，总共训练10亿个样本。虽然作者提供了一个消融实验，显示即使Stage1缩短10到30倍，仍然在流行的基准测试中提供了良好的结果，但作者希望尽可能多地将视觉知识灌输到基础模型中，并涵盖广泛的概念、文化和语言 [17 37 68， 85，92 93 136]

1.2.3 阶段2：分辨率增加

阶段1产生的模型已经是许多任务的有用基础模型（参见附录B中的示例图像）。然而，它只能理解224 × 224像素分辨率的图像，这对于某些任务来说太小了

例如，较小物体的检测和分割，以及与阅读较小文本相关的任务，如图表、信息图或文档，都非常受益于更高的分辨率（参见表1）
因此，作者训练了两个进一步的模型检查点以提高分辨率，首先是448 × 448，然后是896 × 896像素分辨率
由于阶段1已经为模型提供了广泛的知识和技能，阶段2可以专注于扩展模型解析高分辨率图像的能力
因此，作者在阶段2中使用较少的总示例，同时增加每个示例的成本和信息密度
对于448分辨率，额外训练了5000万示例
而对于896分辨率，又增加了1000万示例
为简单起见，阶段2由与阶段1完全相同的任务和数据集组成，但显著增加了对需要高分辨率的任务的采样。此外，这些加权任务都可以被修改以提供更长的后缀序列长度

例如，对于CR任务，可以简单地请求模型以从左到右、从上到下的顺序读取图像上的所有文本
对于检测和分割任务，可以请求模型检测或分割所有提供了注释的对象
因此，我们还将文本序列长度增加到 $N_{\mathrm{txt}}=512$ 个token

虽然PaLI一直有这个分辨率增加阶段，并且对于图像分类，分辨率的重要性早已为人所知[55, 109]，但最近的几项工作[81,114,121]也提高了分辨率在VLMs中的重要性

1.2.4 阶段3：迁移(本质是微调)

阶段1和阶段2的结果是一系列三个PaliGemma检查点，分辨率为224px、448px和896px，预先配备了广泛的视觉知识

然而，这些检查点并不是“用户（或基准）友好”的，因为它们的预训练仅专注于学习信号的密度，而不是可用的界面

这些基础模型需要被迁移以实现其预期的最终目的。这可能采取在特定、专业化任务上进行微调的形式，例如COCO Captions、遥感VQA、视频字幕或InfographicQA，以适应新的输入，例如多张图像（NLVR2）或在图像中绘制的边界框（WidgetCap）。或者，它可以采取指令[70]甚至聊天[46]调优的形式

为了展示基础模型的有效性，作者将它们迁移到广泛的单个学术基准上，使用一个简单统一的迁移方案，只有少量的超参数
为了展示超越学术任务的多功能性，作者还提供了一个“混合”迁移检查点，同时迁移到这些任务的一个子集，并附有详细的字幕和长问答数据。虽然这不是指令微调，但这是朝着这个方向迈出的一步
作者还将PaliGemma迁移到需要多张图像作为输入的任务中。NLVR2就是这样一个任务，它要求对两张图像提出一个问题，并需要查看两者以给出正确答案。其他此类任务是标准的短视频理解任务，抽样到16帧

在所有上面这些情况下，作者遵循PaLI-3的做法，分别编码每张图像，然后连接图像token，而不使用任何特殊分隔符或嵌入token

因此，224px分辨率下的16帧导致 $N_{\text {img }}=4096$ 个图像token，与986px分辨率下的单个图像数量相同

对于所有迁移，作者对所有模型参数进行微调，且作者根据任务修改的超参数如下，按重要递减排序

分辨率（即.检查点）： 224,448, 896
周期：1,3,10,30,100
学习率：3e-5, 1e-5, 3e-6
标签平滑：0.0,0.1,0.3
LLM中的丢奔：0.0,0.1,0.3
权重衰减：0.0或 0.1x学习率
冻结ViT： false, true
Beam-search可能有利于字幕生成

1.2.5 预训练任务组合

就像之前的PaLI模型一样，预训练（阶段1和阶段2）的设计目的是为了得到一个迁移效果好的模型，而不一定是一个可以直接使用的模型（“0 shot”）

这里的直觉是作者希望任务的混合能迫使模型获得广泛的“技能”范围。故为每个任务加上其
独特的前缀，以避免跨技能的学习信号冲突 [14]

在迁移阶段（阶段3），模型只需识别出对任务有用的技能，并重新调整自身以使用该技能，同时遵循任务的输出语法和词汇。根据作者的经验，这些都可以相对快速地完成，并且基于少量示例（原论文第6.3节）

至于在预训练期间不使用任何迁移数据集，并且从预训练数据集中，进一步移除所有与其图像近似重复的内容「We do not use any of our transfer datasets during pretraining, and furthermore remove all near-duplicates of their images from the pretraining datasets [55]」

大体上遵循之前的PaLI工作，这些是预训练
任务：

caption {lang}
作者在各种数据集上包括简单的字幕目标，包括超过100种语言的WebII和CC3M-3510 之前的PaLI使用带有Split-Cap目标的编码器-解码器语言模型
然而对于PaliGemma，使用仅解码器语言模型，简单的字幕是一个更具信息性和更简单的目标
ocr
通过公共OCR系统转录的图像上所有文本的（按光栅顺序）连接。可能会跳过OCR的随机片段，以便在不偏向光栅顺序开头的情况下适应序列长度
回答en {question}
在CC3M-35L上生成的VQA，遵循[19]，问题使用35种语言，但答案为英语
此外，在OpenImages上生成的仅限英语的以对象为中心的问题，遵循[91]：
listing: What objects are in the image?,
presence: Is {thing} in the image?,
multi-object presence: Which of {thing},{thing}... are in the image?,
and newly, counting: How many {thing}?.
问题 {lang] {English answer}
在CC3M-35L上生成的VQG，遵循[19]，为给定的英语答案生成35种语言的问题
检测 {thing} ; {thing} ; ...
类似于 Pix2Seq [22] 的多目标检测，通过伪标签在生成的开放世界数据上进行，如OWI-ViTv2[83] 中所述
分割 {thing} ; {thing} ; ...
在生成的开放世界数据上进行多目标实例分割，类似于 OWL-ViTv2 [83] 和 SAM [54]
描述 <ymin><xmin><ymax><xmax>
根据 LocCa [115]，对框内内容进行定位描述。框由检测和分割中使用的相同位置标记指示：
归一化的图像坐标被分为1024个token

以下是其他的预训练细节

在整个预训练过程中，我们使用“无限”学习率计划，遵循(131]，这提供了一种简单的方法来连接多个阶段，而不在它们之间衰减学习率。
图3显示了完整的计划：预训练是一个连续的rsqrt曲线，适用于所有阶
段。然后，迁移可以作为冷却期，完全退火学习率。作者建议使用简单的设置进行迁移，采用余弦学习率调度，短线性预热并衰减至零，调整整个模型。
由于持续时间相对较短，图3未能很好地表示这一点
该模型完全在开源 big_vision代码库[12]上的 Cloud TPUv5e [38] 中训练。然而，一些预训练数据集仍然是私有的。在训练过程中，作者使用 JAX [16] 和 GSPMD [125]，以 zero-DP风格[96] 在所有可用设备上划分数据、模型参数和优化器状态

这种完全分片的数据并行 (FSDP [137]）分片策略是通过构建全局数组并相应地注释分片来实现的，XLA编译器[97] 负责计算的具体实现以及设备之间的通信

且他们测量了模型的FLOPS利用率（MFU）为55%，每秒每个设备处理5189个tokens。模型参数和优化器状态保持在float 32，以保证训练的稳定性，但还验证了推理在bfloat11模型参数下同样有效
使用TPUv5e-255进行最终PaliGemma模型的一次训练运行，Stage1耗时略少于3天，每个Stage1耗时15小时。Stage1处理略少于350 B个tokens，两个Stage合计约90 B个tokens。在TPUv3-32上，迁移根据任务不同耗时在20分钟到10小时之间

为了避免模型对不同框架中不同图像处理细节的脆弱性，作者随机化图像预处理细节，如调整大小方法、JPEG编码，并应用非常轻微的inception_crop

第二部分关于PaliGemma的一系列消融实验

2.1 多模态预训练时长

对于PaliGemma这个多模态预训练（Stage1）而言，其到10亿个示例，属于较长的一类，类似于BLIP-2 [62]、InterVL [26]、QwenvL. [10]、Idefics2 [59〕（都在10亿左右），但不同于ShareGPT4-v [21]、Mini-Gemini [65]、LLava [70]及其衍生物（约100万)

且作者进行了各种较短的预训练持续时间，甚至完全跳过Stage1，并在下图图4中显示影响，在附录K.1中对各个任务进行了完整的细分

对于跳过Stage1的情况，作者在为每个任务扫过三个学习率时使用最佳迁移结果

结果表明，较短的训练通常会带来不利影响，而完全跳过Stage1是最糟糕的设置。一些任务受到显著影响，而其他任务仅略有恶化，这突显了需要一套广泛而多样的评估任务

100M的预训练持续时间似乎是消融实验的一个良好折衷：它缩短了10倍，同时没有显著损害任何任务

2.2 因果遮蔽和学习目标

作者在下图图5中对预训练学习目标的几个关键选择进行了消融，原论文附录K.2中有完整的每任务细分

首先，研究了自回归遮蔽的设计选择。PaliGemma 使用了一种前缀-LM策略，该策略允许对数据的“输入”部分进行完整（双向）注意，即图像和前缀token，另见图2
其动机是，它允许更多的token从一开始就积极参与“思考”过程，因为图像token现在可以关注代表查询的前缀token
这在图5（左）中得到实证确认，其中绿色条还包括对前缀token的自回归掩码「where the
green bars also include the auto-regressive masking on the prefix tokens, 」
橙色条进一步将自回归掩码扩展到图像token。两组条形图都有效，但表现明显不如由蓝色条表示的 PaliGemma 的前缀-LM 设置

其次，作者仅对后缀（输出）应用下一个token预测损失。原则上，一旦前缀token被自回归地掩盖，它也可以应用于这些标记。这可以通过要求模型“猜测问题”来提供更多的学习信号。再次，图5显示，虽然这样做有效，但显然降低了平均性能

2.3 冻结还是不冻结？答案是不冻结更好

当前在VLMs中的普遍观点[23-25，45,52，60，62，66，70]是保持图像编码器，有时在多模态预训练（比如Stage1）期间保持LLM冻结

然而，受到GapPa[1101和LocCa[115]的积极结果的启发，这些结果表明使用字幕目标预训练图像编码器基本上解決了对比的盲点[43〕，即关系和定位，作者在预训练PaliGemma时没有冻结任何部分

作者现在在下图图7中消融冻结或调整模型各部分在Stage1期问的效果，完整的每任务细分在附录K.3中。与同时进行的工作类似[81，107]，发现不冻结任何部分模型的确是有利的

首先，迁移后，保持图像编码器冻结（左，TT和TF）没有区别。然而，要求空间理解的任务的验证困惑度（因此，可预测性）（右，绿色）显著提高
此外，实验显示，所有其他包括冻结语言模型的选项 [111] 都显著更差
最后，重置（和训练，R）模型的任何部分会严重损害性能，证实了阶段0（即利用预训练组件）对于获得良好结果确实至关重要

2.4 PaliGemma三大组件中连接器的设计

在上文1.1.2节中，我们已经知道，PaliGemma最终使用线性连接器将SigLiP输出嵌入映射到Gemma的输入

而为何选择线性连接器，有没有考虑过其他的连接器呢？

作者还真考虑过，比如对MLP连接器 [69] 便是VLM文献中的热门选择，作者特此对此选择进行了消融

他们考虑了两种连接器选择：线性连接器和MLP（1个隐藏层，带有GeLU非线性）
且还考虑了两种Stage1预训练设置：调整所有权重（TT），或冻结除连接器之外的所有内容（FF）
在调整所有权重时，线性与MLP的平均迁移分数几乎相同，分别达到77.2和77.1分
在“全冻结”场景中，线性与MLP分别达到70.7和69.7
令人惊讶的是，作者观察到MLP连接器的性能略有下降

总体而言，他们得出结论，在他们的案例中，线性连接器似乎比MLP连接器更可取

2.5 图像编码器：有或没有？

大多数VLM遵循的设置是拥有一个图像编码器，例如CLIP SigLI（大多数工作）或VOCAN Chameleon系列工作[2,3,105, 1291），以便在将图像传递给IIM之前将其转换为soft tokens

作者在论文中说，他们只知道两个工作尝试通过完全移除图像编码器并将原始图像补丁传递给仅解码器的LLM来简化这一整体设置，即Fuyu [11]和EVE [34]
不幸的是，前者Fuyu没有提供训练细节或消融实验。后者EVE是一个同时进行的工作，提供了一些关于训练和各种消融实验的细节，但结果好坏参半
在PaliGemma中移除SigLIP编码器会导致模型成为相同的统一解码器架构，既然想到了，那就试一下呗？
故移除下SigLIP编码器之后，运行Stage1和迁移。不过考虑到由于架构发生了显著变化，作者重新调整了Stage1的学习率

下图图8（每个任务的细分见附录K.4）显示，虽然这种架构仍然显著落后，但随着预训练时间的增加，扩展性似乎具有潜在的前景

且特别值得注意的是，PaliGemma的SigLIP编码器在其Stage 0预训练期间已经看到了400亿对图像-文本对，而Fuyu风格模型在这里展示的Stage1预训练中首次看到图像，并且在作者的实验中最多只看到10亿对

这种消融研究证实，这种仅解码器的VLM可能是朝向更简单的多模态模型的一个有前途的末来方向，尽管由于无法重用视觉组件，它们目前在训练效率上仍然存在问题

2.6 图像分辨率

VLM中的图像分辨率是一个重要话题，最近受到了越来越多的关注 [35,59, 81,107, 121]

PaliGemma使用了一种非常简单的方法来处理分辨率：Stage1在相对较低且经济的224px分辨率下进行预训练，然后短暂的Stage2将此检查点“升级”到更高的分辨率（448px和896px）

因此，最终的PaliGemma模型提供了三个不同分辨率的三个不同检查点

// 待更