做过多模态项目的人大概都经历过这种分裂感手上同时挂着三套代码一套双塔模型跑图文召回一套跨模态融合模型做精排还有一套单独的分类头处理下游任务三套代码三套数据管线改一个特征维度要同步改三个仓库调参的时候更是互相打架——召回模型把 batch 开大效果才好融合模型显存又吃不下这么大的 batch。多模态、Transformer架构、跨模态预训练这几个词被说烂了但真正落到工程上统一这两个字值多少钱只有被三套代码折磨过的人心里清楚。FLAVA 这类统一视觉语言模型核心诉求就是把这条被拆碎的产线重新缝成一条一个骨干、一套权重、一份数据管线同一次前向过程里同时吐出单模态特征、跨模态对齐特征和融合特征下游按需取用。这篇文章主要面向已经能独立跑通 CLIP 类对比学习训练、想进一步理解三塔融合 多目标预训练的读者也照顾刚接触多模态、想把整体地图先画出来的同学。我会把架构分工、四个预训练目标的来龙去脉、数据构造、损失权重、显存账本、踩坑清单全部摊开讲包含可以直接抄走改的代码骨架和参数计算过程。1. 先把统一拆开看FLAVA 到底统一了什么1.1 一条被拆碎的产线多模态任务的真实分布要理解 FLAVA 的设计动机得先看清楚多模态任务在真实业务里长什么样。粗略分一下无非三类第一类是检索类给文本找图、给图找文本质是算两个模态之间的相似度要求的是各自模态的独立表征足够好不要求深度融合第二类是判别类图像分类、图文匹配打分需要模型判断这一对配不配往往需要模态间的细粒度交互第三类是生成/问答类视觉问答、图像描述输入是多模态的混合序列输出是文本必须做真正的跨模态注意力。问题就在于这三类任务对模型结构的要求是互相拉扯的。检索任务喜欢双塔因为图像和文本可以离线分别编码成向量建索引十万级、百万级的库也能毫秒级召回一旦你为了做融合把两个模态塞进同一个编码器图像侧就没法预计算了线上必须实时跑一次完整前向延迟直接翻十几倍。反过来VQA 这类任务如果只用双塔两个模态在编码阶段从未见过对方交互只能发生在最后一步的点积上细粒度信息全丢了。主流的做法是分而治之双塔负责召回融合模型负责精排。这套方案能跑通但代价是两套模型、两份训练成本而且两套表征空间是没有对齐的——召回模型认为相似的一对精排模型可能给出完全相反的判断工程师就得在中间加一层阈值校准越调越玄学。FLAVA 这类统一模型的思路是既然两套模型都要学为什么不在预训练阶段就把单模态表征、跨模态对齐、深度融合这三件事一起学掉学完之后检索用哪部分特征、融合任务用哪部分特征按需取用不再需要维护两套参数。这个思路听起来顺理成章但实现上要解决一个硬问题三类目标对表征的要求本身就是矛盾的怎么让它们在一个模型里共存而不互相破坏。1.2 三条技术路线的取舍双塔、融合、单一编码器在动手看 FLAVA 的架构之前我把当时可选的三条路线摆在一起对比过这个对比表后来我在内部评审里反复用因为它能很清楚地解释为什么最后选了看起来最笨的那条路。路线代表结构优势致命短板纯双塔图像编码器 文本编码器末端点积图像可离线编码检索吞吐极高模态间无细粒度交互VQA 类任务天花板低纯融合图像块与文本 token 拼成一个序列单编码器交互最充分生成类任务表现好图像侧无法预计算检索场景成本不可接受单模态特征质量差双塔 融合编码器两个单模态编码器 一个跨模态编码器三种特征都能拿到任务各取所需参数多、训练目标多、训练不稳定调参难度陡增第三条路就是 FLAVA 走的路。它看起来是既要又要但仔细想它其实是在工程上做了一次成本置换用更多的参数和更复杂的训练目标换掉了维护多套模型 表征空间不对齐这两个长期的隐性成本。我认为这个置换在数据量足够大的时候是划算的数据量小的时候则完全不划算——后面讲数据配比的时候我会具体说这个盈亏平衡点大概在哪。关键的设计洞察在于单模态编码器和跨模态编码器承担的角色是不一样的。单模态编码器只需要回答这张图是什么、这段话说了什么它的输出可以离线缓存因此适合检索跨模态编码器只需要回答这图和这段话放在一起是什么意思它天然需要看到两个模态的完整序列因此适合融合任务。把这两件事塞进同一个编码器就会出现为了融合牺牲检索效率或者为了检索牺牲融合深度的二选一分开之后两个目标各得其所互不干扰。1.3 三个编码器的分工与参数账具体到结构FLAVA 由三块组成。图像编码器是一个标准的 ViT输入 224×224 的图切 16×16 的块得到 196 个 patch token加上一个 [CLS]走 12 层 Transformer隐藏维度 768。文本编码器是 12 层的文本 Transformer隐藏维度同样 768结构上接近常见的 base 级编码器。多模态编码器只有 6 层输入是图像编码器和文本编码器输出的 token 序列拼接而成的长序列两个模态在这里做完整的自注意力交互。这个层数配置不是随便定的。单模态编码器要深因为它承担了绝大部分表征学习的活儿特征质量直接决定检索效果多模态编码器可以浅因为它的输入已经是经过充分编码的语义 token它只需要做对齐和整合不需要从像素和字符级别重新学一遍。6 层是个经验值我试过把它压到 4 层VQA 类任务的准确率掉了将近两个点加到 8 层收益就很小了参数量却涨了三成。如果资源紧张把多模态层砍到 4 层、把省下的预算加到单模态编码器上是更划算的做法。参数量粗略算一下ViT-B/16 大约 8600 万参数含 patch embedding文本编码器 12 层 768 维主体约 8500 万多模态编码器 6 层 768 维约 4300 万加上三个模态各自的投影头、两个掩码预测头文本词表头、视觉码本头总量在 2.2 亿到 2.5 亿这个区间取决于词表大小和视觉码本规模。这个量级在今天看不算大但训练的复杂性远高于参数量给人的直觉——四个训练目标同时开火任何一个权重设错整个模型就废了。1.4 为什么不用一个编码器硬扛这里我想多说一句因为这是最容易走偏的地方。很多人第一反应是既然 Transformer 能吃任意序列那我把图像块和文本 token 拼起来喂给一个编码器不就行了何必搞三个。这条路不是没人走过早期的纯融合模型就是这么干的效果在某些生成任务上还不错但有两个绕不过去的坎。第一个坎是单模态特征退化。当图像 token 和文本 token 始终在同一个注意力空间里竞争时模型会倾向于学跨模态的联合表征而不是纯粹的视觉表征。结果是图像侧的 [CLS] 向量在做纯视觉检索时表现明显不如独立训练的 ViT。第二个坎是成本。图像一旦不能离线编码每次文本查询都要重新跑一遍图像编码检索库上到百万级这个开销就没法接受了。所以三编码器不是为了炫技是被这两个约束逼出来的。理解了这一点后面看那四个训练目标的设计就不会觉得是在堆料。2. 四个预训练目标的设计逻辑与数学表达2.1 多模态掩码建模让模型学会补全掩码建模是这套预训练的主干。思路很朴素把输入的一部分遮住让模型根据剩下的部分猜出被遮住的内容。文本侧沿用经典的 15% 掩码、其中 80% 换成掩码符号、10% 随机替换、10% 保持原样的策略图像侧则激进得多遮掉 70% 的 patch并且采用块状掩码而不是随机单点掩码——因为图像相邻 patch 高度冗余随机遮单点的话模型只看邻居就能猜出来学不到东西。三个编码器各自都要做掩码预测但预测的任务不一样。文本编码器做的是文本掩码预测词表分类多模态编码器做的是双模态的掩码预测——它同时要预测被遮住的图像 patch 属于视觉码本里的哪一项以及被遮住的文本 token 是哪个词。图像编码器本身通常不做掩码预测它是被冻结或者只做轻量微调的它的职责是提供干净的视觉特征这一点很关键因为如果图像编码器也参与掩码重建它学到的表征会偏向重建友好而不是语义友好检索性能会掉。视觉码本这块需要说明一下。图像 patch 不能像文本那样直接分类到连续像素必须先离散化。常见做法是用一个离线训练好的视觉 tokenizer 把每张图编码成一串离散索引码本大小通常取 8192 到 16384。这个 tokenizer 的质量直接决定了图像掩码预测这个目标的上限——码本太粗重建任务太简单学不到细粒度码本太细分类头太大训练不稳定。我的经验是 8192 是个不错的起点如果下游任务明显依赖细粒度纹理比如工业质检可以考虑上到 16384。掩码建模的损失就是标准的交叉熵L_MMM_text CE(text_logits[被遮位置], text_labels) L_MMM_image CE(image_logits[被遮位置], image_code_labels)注意只在被遮住的位置算损失没遮的位置不参与这一点和语言模型的因果预测不一样别搞混。2.2 图像-文本匹配给全局一个二分类判据光有掩码建模是不够的因为它学的是局部片段的补全能力模型完全可以把一张图和一段毫不相干的文本各自补全得很好两者的联合表征依然是错的。图文匹配这个目标就是用来堵这个漏洞的把图像和文本一起喂进多模态编码器取 [CLS] 位置的输出过一个二分类头判断这一对到底配不配。负样本怎么采是关键。最省事的做法是从当前 batch 里随机挑另一条文本配给这张图但随机采出来的负样本往往太简单——模型只要看个大概就能区分学不到细粒度。更有效的做法是难负样本挖掘先用当前的模型算一遍相似度把那些模型觉得很像但其实不配的样本挑出来当负样本。这套做法在小 batch 下效果有限因为候选池子太小batch 上千之后难负样本的质量会明显提升。实际实现上有个细节容易踩坑难负样本挖掘需要额外跑一遍前向训练吞吐会掉 20% 到 30%。我的做法是每隔若干步才做一次挖掘把挖到的负样本缓存起来复用这样吞吐损失能压到 10% 以内效果几乎无损。另外负正样本比例不要设得太极端1:1 到 1:2 之间比较稳比例再高模型会偏向判负正样本的得分也被压低。2.3 对比学习把整个 batch 当负样本池对比学习这一路是让两个单模态编码器的输出空间对齐。具体做法是把图像 [CLS] 和文本 [CLS] 各自过一个投影头映射到同一个低维空间通常是 256 或 512 维然后在这个空间里做 InfoNCE一张图和它配对的文本算正样本和 batch 里其他所有文本算负样本。损失长这样我用 PyTorch 风格写出来方便直接对照def clip_loss(img_emb, txt_emb, temperature): # img_emb, txt_emb: [B, D]已经做过 L2 归一化 logits img_emb txt_emb.t() / temperature # [B, B] labels torch.arange(logits.size(0), devicelogits.device) loss_i2t F.cross_entropy(logits, labels) loss_t2i F.cross_entropy(logits.t(), labels) return (loss_i2t loss_t2i) / 2温度系数是个可学习参数初始化 0.07训练过程中会自己往下走——通常会收敛到 0.01 到 0.03 之间。我一开始把温度写死成 0.07 不动结果训练后期损失就卡住不降了改成可学习之后曲线立刻通畅。这是个很小但很实用的细节。对比学习对 batch size 极其敏感因为 batch 里的其他样本就是负样本池。batch 从 256 加到 1024检索召回率通常能涨三到五个点但从 1024 再加到 2048收益就很小了边际递减非常明显。所以我的建议是显存允许的话优先把 batch 堆到 1024 左右再往上加不如把同样的算力花在数据质量上。2.4 四项损失的加权与合并方式把四个目标合起来总损失是这样L_total λ_M · L_MMM λ_I · L_IMG_MLM λ_T · L_TXT_MLM λ_C · L_CLIP λ_ITM · L_ITM权重怎么定是这套方法里最玄学的部分。我见过不少复现失败案例八成栽在这里。几个原则我踩过坑之后总结出来了第一对比学习的权重不要一开始就给满。训练早期单模态编码器的表征还很粗糙对比损失梯度又大权重给高了会把模型往两个模态各自坍缩到一个点的方向推。稳妥的做法是前若干步用较小的权重比如 0.3 到 0.5等掩码建模的损失降到一定程度再逐步提到 1.0。第二掩码建模的权重整体上要比对比学习高一些。因为掩码建模的损失绝对值本身就比对比损失大词表几十类交叉熵量级不同如果不做归一化直接用同样的权重掩码项会完全主导梯度。实践中我会先各跑几百步看一下四项损失的量级再按让四项损失大致落在同一数量级的原则去配权重这比死记一组数字有用得多。第三图文匹配的权重可以稍低。它的作用是修偏不是主力权重给到 0.5 左右通常就够。给太高会让模型过早地在融合空间里锁死判断反而抑制了细粒度的表征学习。下面这张表是我自己的起始配置仅作参考实际一定要根据损失曲线动态调损失项起始权重观察指标调整方向图像掩码建模1.0重建准确率长期不涨则考虑码本太粗文本掩码建模1.0掩码位置准确率曲线抖动则降学习率或加 warmup多模态掩码建模1.0双模态重建准确率明显低于单模态时检查模态类型嵌入对比学习0.3 → 1.0正样本相似度与负样本差值差值不拉开说明 batch 太小或温度不对图文匹配0.5二分类准确率过快到 95% 以上说明负样本太简单3. 数据工程两类数据源与掩码策略3.1 有标注图文对与单模态无标注数据的混配FLAVA 的训练数据由两部分组成这个设计很有意思也最容易被简化掉。一部分是图文对数据用来支撑对比学习和图文匹配这两个需要成对输入的目标另一部分是无标注的单模态数据——纯图像、纯文本它们不参与对比学习只参与各自的掩码建模。为什么要掺单模态数据因为高质量的图文对太贵了。几千万对已经是公开数据的量级但文本语料和图像语料各自都是论亿计的。如果只用图文对训练文本编码器的词表和语言能力会被图文对里的短文本严重限制——图注大多很短二三十个词模型学到的语言分布非常窄。掺入纯文本数据能让文本编码器真正学到语言结构掺入纯图像数据也一样能让图像编码器见到更丰富的视觉分布。配比上我的经验是图文对、纯图像、纯文本大致按 1:1:1 的量级混合比较稳但要保证图文对在每个 batch 里都占足够比例否则对比学习那一项就没法算了。实现上我是这样做的每个 batch 里固定划出一部分样本作为图文对剩下的位置从纯图像池和纯文本池里轮流填。这样既保证了对比学习有足够的负样本池又不浪费单模态数据。有个坑要提醒单模态数据的掩码建模损失和图文对里的掩码建模损失量级是不一样的。纯文本的句子长度分布和图文对里的短图注差异很大如果混在一起不做长度归一化你会看到损失曲线呈现出诡异的周期性波动——每次采样到长文本 batch 就跳一下。解决办法是损失按有效 token 数取平均而不是按 batch 取平均。3.2 图像块掩码与文本掩码的具体做法图像侧的掩码策略值得单独说。前面提到遮 70%但怎么遮比遮多少更影响效果。有两种常见方案随机遮单个 patch或者按块遮把图像切成若干大块随机选一部分块整体遮掉。随机单点遮的问题在于相邻 patch 之间相关性极强模型只看四周就能推断出中心任务太简单。块状遮法逼着模型做更长程的推理学到的表征质量明显更好。实测对比下同样是 70% 的掩码率块状遮法在下游分类任务上能比随机单点遮高出两到三个点。代价是实现复杂一点需要先生成一个块级的随机掩码再上采样到 patch 级别。文本侧的掩码相对标准化15% 的比例按 BERT 那套 80/10/10 的策略。但有个细节图文对里的文本往往很短如果按固定比例遮很短的句子可能一个词都遮不到这个样本就白跑了。我的做法是设一个保底数量比如至少遮一个 token避免浪费。3.3 数据管线的并发与预处理开销数据管线这块说起来枯燥但它决定了你的训练能不能跑满卡。图像解码和增强是 CPU 密集型操作一张 224×224 的图从 JPEG 解码到张量单核大概要几毫秒一个 batch 一千张就是几秒钟完全可能拖垮 GPU 利用率。几个实际有效的优化一是把图像预先解码成低分辨率的紧凑格式缓存起来训练时只做轻量增强这一步能把 CPU 压力降一大半二是增强操作尽量用 GPU 做现在主流的视觉库都支持把解码后的张量直接搬到卡上再做裁剪翻转CPU 只负责 I/O三是数据加载的 worker 数不要凭感觉设按CPU 核数除以单卡数再减二来配通常是个合理的起点。文本侧反而简单提前把分词结果缓存成定长数组训练时直接索引不要在线分词。4. 动手搭一个缩小版代码与配置4.1 输入构造与分词处理下面这套代码是我在单机多卡上验证过的骨架规模做了缩小但结构关系和原版一致可以直接拿去改。先看输入构造import torch from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(your-text-encoder) def build_batch(images, texts, max_len40): # images: list of PIL Image已完成增强 pixel_values torch.stack([img_augment(im) for im in images]) # [B,3,224,224] enc tokenizer( texts, paddingmax_length, truncationTrue, max_lengthmax_len, return_tensorspt, ) return { pixel_values: pixel_values, input_ids: enc[input_ids], # [B, L] attention_mask: enc[attention_mask], # [B, L] }这里max_len设 40 是个经验值图注类数据 95% 以上都在这个范围内再长就是长尾。如果你的业务文本偏长比如商品详情描述得单独评估因为文本长度直接影响到后面多模态编码器的序列长度进而影响显存。4.2 前向传播与跨模态序列拼接这一部分是整个实现的核心也是容易写错的地方。三个编码器的调用顺序和拼接方式如下def forward(self, pixel_values, input_ids, attention_mask, img_maskNone, txt_maskNone): # 1) 单模态编码 img_tokens self.image_encoder(pixel_values) # [B, 197, 768] txt_tokens self.text_encoder(input_ids, attention_mask) # [B, L, 768] img_cls img_tokens[:, 0] txt_cls txt_tokens[:, 0] # 2) 掩码替换被遮住的位置换成可学习的占位向量 if img_mask is not None: img_tokens torch.where( img_mask.unsqueeze(-1), self.mim_embedding.expand_as(img_tokens), img_tokens, ) if txt_mask is not None: txt_tokens torch.where( txt_mask.unsqueeze(-1), self.mask_embedding.expand_as(txt_tokens), txt_tokens, ) # 3) 拼接图像序列在前文本序列在后 fused torch.cat([img_tokens, txt_tokens], dim1) # [B, 197L, 768] # 模态类型嵌入区分这个位置原本属于哪个模态 fused fused self.modality_type_embed(fused) fused_out self.multimodal_encoder(fused, attention_maskbuild_fused_mask(...)) return img_cls, txt_cls, fused_out有两点必须强调。模态类型嵌入不能省。拼接之后图像 token 和文本 token 在同一个注意力空间里模型必须知道每个位置的身份。如果不加这个嵌入模型只能靠位置推断——图像永远在前 197 个文本在后 L 个看似可以推但一旦序列长度变化比如图像分辨率改了这个隐式规则就崩了。加上显式的模态嵌入之后模型的泛化性会明显好很多。融合后的注意力掩码要重新构造。文本有 padding拼到后面之后图像部分全是有效 token文本部分有 padding。掩码矩阵要保证图像 token 能看见所有图像 token 和有效文本 token文本 token 之间按原掩码来padding 位置对任何 token 都不可见。这块写错的话训练能跑但效果会很差而且表面上查不出问题。4.3 四路损失的合并与反向传播拿到三组输出之后损失的组装是这样的# 掩码预测 img_logits self.img_mlm_head(fused_out[:, 1:1196]) # 视觉码本分类 txt_logits self.txt_mlm_head(fused_out[:, 197:]) # 词表分类 loss_mmm_img masked_ce(img_logits, img_labels, img_mask) loss_mmm_txt masked_ce(txt_logits, txt_labels, txt_mask) # 对比损失 z_img F.normalize(self.img_proj(img_cls), dim-1) z_txt F.normalize(self.txt_proj(txt_cls), dim-1) loss_clip clip_loss(z_img, z_txt, self.temperature.clamp(min0.01)) # 图文匹配 match_logits self.itm_head(fused_out[:, 0]) loss_itm F.cross_entropy(match_logits, itm_labels) loss (w_mmm * (loss_mmm_img loss_mmm_txt) w_clip * loss_clip w_itm * loss_itm) loss.backward()masked_ce这个函数要自己写核心是只在掩码位置计算交叉熵其余位置置零。用F.cross_entropy(..., reductionnone)拿到逐位置损失再乘掩码求和除以掩码总数是最直观的写法。记得处理整个 batch 一个掩码都没有的边界情况否则会出现除以零得到一个 NaN然后整个训练静默崩溃——这种 bug 极难定位因为报错信息指向的是几百步之后的某次反向传播。4.4 显存账本与超参配置显存这一块我算一笔账方便你决定 hardware 配置。假设 batch size 为 1024图像序列 197 个 token文本序列 40 个 token隐藏维度 768混合精度训练单层激活值大头是注意力的中间结果按 1024 × 237 × 768 × 2 字节算单个张量约 370MB一层里这类张量有十几个就是四五个 GB。12 层单模态编码器加 6 层融合编码器不做优化的话几十 GB 起步单卡放不下。实际可用的做法是梯度检查点前向只保留每层的输入反向时重算中间激活。代价是计算量增加 30% 左右收益是激活显存降到原来的十几分之一。开了检查点之后batch 1024 大概需要 4 到 8 张 80GB 级别的卡具体取决于序列长度和是否冻结图像编码器。如果只有单卡那就老老实实把 batch 降到 32 到 64靠梯度累积凑等效 batch。这里有个细节对比学习在梯度累积下会被削弱因为每次前向只看到自己那一个微 batch 的负样本累积多步之后的等效 batch 并不等于对比学习的有效负样本池。解决办法是维护一个特征队列把前几步算出来的特征缓存起来当额外负样本或者干脆接受这个损失把单步微 batch 设大一点32 已经能提供不错的负样本池。我自己的机器上是微 batch 64、累积 16 步效果接近真实 batch 1024 的八成。优化器配置大致如下参数取值说明优化器AdamWbeta 用默认的 0.9 / 0.999峰值学习率3e-4等效 batch 1024等效 batch 减半则学习率也大致减半权重衰减0.02比常规的 0.01 略高能压住后期过拟合学习率调度线性 warmup 余弦衰减warmup 步数取总步数的 2%太少容易前期崩梯度裁剪1.0四个损失叠加后梯度范数波动很大必须裁精度bf16 混合精度比 fp16 稳不需要损失缩放梯度裁剪这一项特别要提。四项损失同时反传梯度范数的波动比单目标训练大得多我遇到过梯度范数突然冲到几百的情况不裁剪的话一步就能把模型带偏。裁剪到 1.0 是稳妥的选择如果你发现训练前期损失下降极慢可以试试放宽到 5.0 观察一下。5. 下游迁移三种用法与微调路径5.1 检索任务只用单模态特征别用融合特征检索场景最省事的用法是直接冻结两个单模态编码器取 [CLS] 特征做向量检索。这里有个很多人会犯的错误既然模型有融合编码器那用融合后的特征去检索不是更准吗短期看确实准但代价是图像侧没法预计算。千万级图库上每次查询都跑一遍完整的图像编码延迟和成本都不可接受。正确姿势是用单模态特征建索引用融合特征做重排。具体来说先拿图像编码器的 [CLS] 向量建好向量库用户查询时用文本编码器的 [CLS] 向量做近似近邻检索召回前 100 条然后对这 100 对候选逐个跑一遍多模态编码器算图文匹配分数重排取前 10。这个两阶段结构能把召回率在纯双塔的基础上再提几个点同时延迟只增加一次百级别的融合前向完全可接受。建索引的时候向量的归一化方式要和训练时保持一致。训练时对比学习用的是 L2 归一化后的向量检索时也必须归一化后算余弦相似度用未归一化的原向量算内积会得到完全错误的排序。5.2 判别与问答类任务加轻量任务头微调分类、视觉问答这类任务标准做法是把多模态编码器的输出接一个任务头微调。视觉问答的场景下输入是图文拼接序列输出是答案分类或生成跟预训练时的多模态掩码建模结构很像迁移很自然。微调时我建议分阶段先冻结单模态编码器只训多模态编码器和任务头若干轮等损失降下来再解冻全部参数用小学习率预训练的十分之一左右继续训。这样做的原因是任务头的随机初始化会产生很大的梯度如果一开始就全量微调这股大梯度会顺着多模态编码器一路传回单模态编码器把预训练学好的表征破坏掉。分阶段训练能把这个破坏降到最低。微调数据量少的时候几千条级别还可以考虑只训多模态编码器的最后两三层加任务头其余全冻。这样参数量小过拟合风险低收敛也快。5.3 零样本能力从匹配分数到分类FLAVA 这类模型天然具备一定的零样本能力思路和图文检索一样把类别名转成文本提示比如一张{类别}的照片用文本编码器编码和图像特征算相似度取最高的那类作为预测。这个能力在预训练数据覆盖的类别上表现还不错但在专业领域医疗、工业基本失效因为预训练没见过这些视觉概念。实战里我的态度是零样本结果用来做快速验证和冷启动可以正式上线前一定要用少量标注数据做一次轻量微调或者至少做一次提示词调优。提示词的措辞对准确率影响能到五到十个点值得花半天时间枚举几十个模板做集成。6. 踩坑记录与排查清单6.1 对比损失塌缩最难查的一类故障症状是训练前几十步损失正常下降然后突然所有图像的相似度都变得很高batch 内任意一对的余弦相似度都接近 0.9对比损失卡在 ln(batch) 附近不再下降。这叫表征塌缩模型把所有输入映射到了同一个点。我遇到过三次原因各不相同。第一次是温度参数设得太小写死了 0.01梯度爆炸把表征推到一起第二次是学习率太大训练前期直接发散第三次最隐蔽是数据管线有 bug同一个 batch 里重复出现了同一张图的不同增强版本模型很容易就把它们对齐了然后顺着这条路把所有东西都对齐到一起。排查顺序我总结成一张表现象优先怀疑验证方式处理相似度矩阵全是 0.9温度过小打印温度参数实际值加下界约束clamp 到 0.01 以上损失从第一步就异常数据重复统计 batch 内图像哈希去重率修数据管线加去重逻辑损失周期性抖动样本长度不均按长度分桶看损失损失按有效 token 数归一化前期正常后期爆学习率无衰减打印各步学习率加余弦衰减、梯度裁剪6.2 显存与吞吐被忽视的隐性瓶颈显存不够好办降 batch、开检查点。真正难搞的是显存够但吞吐上不去。这种情况八成是 GPU 在等数据nvidia-smi 上看利用率忽高忽低像心电图。原因通常是数据加载的 worker 不够或者图像增强全压在 CPU 上。我一般会先看数据加载耗时占总步时的比例超过 20% 就要动手优化了。还有一种吞吐问题来自多模态编码器的序列长度。文本长度从 40 涨到 80融合序列从 237 涨到 277注意力计算量涨了 36%但参数量一点没变很容易被忽视。如果你的业务文本偏长一定要单独按最长长度做一次显存和吞吐评估别拿短文本的配置直接上线。6.3 常见问题速查表这张表是我自己攒的遇到问题先扫一遍能省不少时间问题可能原因排查动作掩码重建准确率长期停在很低水平视觉码本太粗或图像编码器被不当冻结检查码本大小确认图像编码器是否在更新图文匹配准确率一上来就 95%负样本太简单检查负样本采样逻辑加入难例挖掘检索召回率远低于预期特征未归一化或用了融合特征建索引确认归一化一致性改用单模态特征微调后效果不如冻结任务头初始梯度破坏预训练表征改成分阶段解冻先冻后放多卡训练损失曲线与单卡差异大对比学习跨卡负样本未打通确认是否做了跨卡 all_gather训练后期验证集指标下滑过拟合权重衰减不足提高权重衰减或加早停多卡那一项特别值得说。如果你的对比学习没有实现跨卡的特征汇聚每张卡各自算自己那部分 batch 的对比损失等效负样本池就缩小到了单卡 batch 大小八卡并行相当于白瞎了七卡的负样本。实现上就是把各卡的图像特征和文本特征 all_gather 拼成全局矩阵再算损失注意梯度要正确回传到各自的卡。这一步写错不会报错只会让你的模型效果比你预期的差一截非常隐蔽。我自己在这个方向上投入的时间大概有一半不是在调模型结构而是在修数据管线和验证训练目标之间的相互干扰。FLAVA 这套框架的价值不在于某个单点技术有多新而在于它把单模态表征、跨模态对齐、深度融合这三件在工程上长期割裂的事塞进了一次训练里。如果你手头的业务同时需要检索和融合两类能力这套思路值得完整复现一遍如果只做检索那双塔加上好数据其实更划算别为了架构优雅给自己加复杂度。 
长河君 · 2026/10/30 17:06:50 · 阅读 1.2k FLAVA统一视觉语言模型：三塔融合与多目标预训练工程实践
做过多模态项目的人大概都经历过这种分裂感手上同时挂着三套代码一套双塔模型跑图文召回一套跨模态融合模型做精排还有一套单独的分类头处理下游任务三套代码三套数据管线改一个特征维度要同步改三个仓库调参的时候更是互相打架——召回模型把 batch 开大效果才好融合模型显存又吃不下这么大的 batch。多模态、Transformer架构、跨模态预训练这几个词被说烂了但真正落到工程上统一这两个字值多少钱只有被三套代码折磨过的人心里清楚。FLAVA 这类统一视觉语言模型核心诉求就是把这条被拆碎的产线重新缝成一条一个骨干、一套权重、一份数据管线同一次前向过程里同时吐出单模态特征、跨模态对齐特征和融合特征下游按需取用。这篇文章主要面向已经能独立跑通 CLIP 类对比学习训练、想进一步理解三塔融合 多目标预训练的读者也照顾刚接触多模态、想把整体地图先画出来的同学。我会把架构分工、四个预训练目标的来龙去脉、数据构造、损失权重、显存账本、踩坑清单全部摊开讲包含可以直接抄走改的代码骨架和参数计算过程。1. 先把统一拆开看FLAVA 到底统一了什么1.1 一条被拆碎的产线多模态任务的真实分布要理解 FLAVA 的设计动机得先看清楚多模态任务在真实业务里长什么样。粗略分一下无非三类第一类是检索类给文本找图、给图找文本质是算两个模态之间的相似度要求的是各自模态的独立表征足够好不要求深度融合第二类是判别类图像分类、图文匹配打分需要模型判断这一对配不配往往需要模态间的细粒度交互第三类是生成/问答类视觉问答、图像描述输入是多模态的混合序列输出是文本必须做真正的跨模态注意力。问题就在于这三类任务对模型结构的要求是互相拉扯的。检索任务喜欢双塔因为图像和文本可以离线分别编码成向量建索引十万级、百万级的库也能毫秒级召回一旦你为了做融合把两个模态塞进同一个编码器图像侧就没法预计算了线上必须实时跑一次完整前向延迟直接翻十几倍。反过来VQA 这类任务如果只用双塔两个模态在编码阶段从未见过对方交互只能发生在最后一步的点积上细粒度信息全丢了。主流的做法是分而治之双塔负责召回融合模型负责精排。这套方案能跑通但代价是两套模型、两份训练成本而且两套表征空间是没有对齐的——召回模型认为相似的一对精排模型可能给出完全相反的判断工程师就得在中间加一层阈值校准越调越玄学。FLAVA 这类统一模型的思路是既然两套模型都要学为什么不在预训练阶段就把单模态表征、跨模态对齐、深度融合这三件事一起学掉学完之后检索用哪部分特征、融合任务用哪部分特征按需取用不再需要维护两套参数。这个思路听起来顺理成章但实现上要解决一个硬问题三类目标对表征的要求本身就是矛盾的怎么让它们在一个模型里共存而不互相破坏。1.2 三条技术路线的取舍双塔、融合、单一编码器在动手看 FLAVA 的架构之前我把当时可选的三条路线摆在一起对比过这个对比表后来我在内部评审里反复用因为它能很清楚地解释为什么最后选了看起来最笨的那条路。路线代表结构优势致命短板纯双塔图像编码器 文本编码器末端点积图像可离线编码检索吞吐极高模态间无细粒度交互VQA 类任务天花板低纯融合图像块与文本 token 拼成一个序列单编码器交互最充分生成类任务表现好图像侧无法预计算检索场景成本不可接受单模态特征质量差双塔 融合编码器两个单模态编码器 一个跨模态编码器三种特征都能拿到任务各取所需参数多、训练目标多、训练不稳定调参难度陡增第三条路就是 FLAVA 走的路。它看起来是既要又要但仔细想它其实是在工程上做了一次成本置换用更多的参数和更复杂的训练目标换掉了维护多套模型 表征空间不对齐这两个长期的隐性成本。我认为这个置换在数据量足够大的时候是划算的数据量小的时候则完全不划算——后面讲数据配比的时候我会具体说这个盈亏平衡点大概在哪。关键的设计洞察在于单模态编码器和跨模态编码器承担的角色是不一样的。单模态编码器只需要回答这张图是什么、这段话说了什么它的输出可以离线缓存因此适合检索跨模态编码器只需要回答这图和这段话放在一起是什么意思它天然需要看到两个模态的完整序列因此适合融合任务。把这两件事塞进同一个编码器就会出现为了融合牺牲检索效率或者为了检索牺牲融合深度的二选一分开之后两个目标各得其所互不干扰。1.3 三个编码器的分工与参数账具体到结构FLAVA 由三块组成。图像编码器是一个标准的 ViT输入 224×224 的图切 16×16 的块得到 196 个 patch token加上一个 [CLS]走 12 层 Transformer隐藏维度 768。文本编码器是 12 层的文本 Transformer隐藏维度同样 768结构上接近常见的 base 级编码器。多模态编码器只有 6 层输入是图像编码器和文本编码器输出的 token 序列拼接而成的长序列两个模态在这里做完整的自注意力交互。这个层数配置不是随便定的。单模态编码器要深因为它承担了绝大部分表征学习的活儿特征质量直接决定检索效果多模态编码器可以浅因为它的输入已经是经过充分编码的语义 token它只需要做对齐和整合不需要从像素和字符级别重新学一遍。6 层是个经验值我试过把它压到 4 层VQA 类任务的准确率掉了将近两个点加到 8 层收益就很小了参数量却涨了三成。如果资源紧张把多模态层砍到 4 层、把省下的预算加到单模态编码器上是更划算的做法。参数量粗略算一下ViT-B/16 大约 8600 万参数含 patch embedding文本编码器 12 层 768 维主体约 8500 万多模态编码器 6 层 768 维约 4300 万加上三个模态各自的投影头、两个掩码预测头文本词表头、视觉码本头总量在 2.2 亿到 2.5 亿这个区间取决于词表大小和视觉码本规模。这个量级在今天看不算大但训练的复杂性远高于参数量给人的直觉——四个训练目标同时开火任何一个权重设错整个模型就废了。1.4 为什么不用一个编码器硬扛这里我想多说一句因为这是最容易走偏的地方。很多人第一反应是既然 Transformer 能吃任意序列那我把图像块和文本 token 拼起来喂给一个编码器不就行了何必搞三个。这条路不是没人走过早期的纯融合模型就是这么干的效果在某些生成任务上还不错但有两个绕不过去的坎。第一个坎是单模态特征退化。当图像 token 和文本 token 始终在同一个注意力空间里竞争时模型会倾向于学跨模态的联合表征而不是纯粹的视觉表征。结果是图像侧的 [CLS] 向量在做纯视觉检索时表现明显不如独立训练的 ViT。第二个坎是成本。图像一旦不能离线编码每次文本查询都要重新跑一遍图像编码检索库上到百万级这个开销就没法接受了。所以三编码器不是为了炫技是被这两个约束逼出来的。理解了这一点后面看那四个训练目标的设计就不会觉得是在堆料。2. 四个预训练目标的设计逻辑与数学表达2.1 多模态掩码建模让模型学会补全掩码建模是这套预训练的主干。思路很朴素把输入的一部分遮住让模型根据剩下的部分猜出被遮住的内容。文本侧沿用经典的 15% 掩码、其中 80% 换成掩码符号、10% 随机替换、10% 保持原样的策略图像侧则激进得多遮掉 70% 的 patch并且采用块状掩码而不是随机单点掩码——因为图像相邻 patch 高度冗余随机遮单点的话模型只看邻居就能猜出来学不到东西。三个编码器各自都要做掩码预测但预测的任务不一样。文本编码器做的是文本掩码预测词表分类多模态编码器做的是双模态的掩码预测——它同时要预测被遮住的图像 patch 属于视觉码本里的哪一项以及被遮住的文本 token 是哪个词。图像编码器本身通常不做掩码预测它是被冻结或者只做轻量微调的它的职责是提供干净的视觉特征这一点很关键因为如果图像编码器也参与掩码重建它学到的表征会偏向重建友好而不是语义友好检索性能会掉。视觉码本这块需要说明一下。图像 patch 不能像文本那样直接分类到连续像素必须先离散化。常见做法是用一个离线训练好的视觉 tokenizer 把每张图编码成一串离散索引码本大小通常取 8192 到 16384。这个 tokenizer 的质量直接决定了图像掩码预测这个目标的上限——码本太粗重建任务太简单学不到细粒度码本太细分类头太大训练不稳定。我的经验是 8192 是个不错的起点如果下游任务明显依赖细粒度纹理比如工业质检可以考虑上到 16384。掩码建模的损失就是标准的交叉熵L_MMM_text CE(text_logits[被遮位置], text_labels) L_MMM_image CE(image_logits[被遮位置], image_code_labels)注意只在被遮住的位置算损失没遮的位置不参与这一点和语言模型的因果预测不一样别搞混。2.2 图像-文本匹配给全局一个二分类判据光有掩码建模是不够的因为它学的是局部片段的补全能力模型完全可以把一张图和一段毫不相干的文本各自补全得很好两者的联合表征依然是错的。图文匹配这个目标就是用来堵这个漏洞的把图像和文本一起喂进多模态编码器取 [CLS] 位置的输出过一个二分类头判断这一对到底配不配。负样本怎么采是关键。最省事的做法是从当前 batch 里随机挑另一条文本配给这张图但随机采出来的负样本往往太简单——模型只要看个大概就能区分学不到细粒度。更有效的做法是难负样本挖掘先用当前的模型算一遍相似度把那些模型觉得很像但其实不配的样本挑出来当负样本。这套做法在小 batch 下效果有限因为候选池子太小batch 上千之后难负样本的质量会明显提升。实际实现上有个细节容易踩坑难负样本挖掘需要额外跑一遍前向训练吞吐会掉 20% 到 30%。我的做法是每隔若干步才做一次挖掘把挖到的负样本缓存起来复用这样吞吐损失能压到 10% 以内效果几乎无损。另外负正样本比例不要设得太极端1:1 到 1:2 之间比较稳比例再高模型会偏向判负正样本的得分也被压低。2.3 对比学习把整个 batch 当负样本池对比学习这一路是让两个单模态编码器的输出空间对齐。具体做法是把图像 [CLS] 和文本 [CLS] 各自过一个投影头映射到同一个低维空间通常是 256 或 512 维然后在这个空间里做 InfoNCE一张图和它配对的文本算正样本和 batch 里其他所有文本算负样本。损失长这样我用 PyTorch 风格写出来方便直接对照def clip_loss(img_emb, txt_emb, temperature): # img_emb, txt_emb: [B, D]已经做过 L2 归一化 logits img_emb txt_emb.t() / temperature # [B, B] labels torch.arange(logits.size(0), devicelogits.device) loss_i2t F.cross_entropy(logits, labels) loss_t2i F.cross_entropy(logits.t(), labels) return (loss_i2t loss_t2i) / 2温度系数是个可学习参数初始化 0.07训练过程中会自己往下走——通常会收敛到 0.01 到 0.03 之间。我一开始把温度写死成 0.07 不动结果训练后期损失就卡住不降了改成可学习之后曲线立刻通畅。这是个很小但很实用的细节。对比学习对 batch size 极其敏感因为 batch 里的其他样本就是负样本池。batch 从 256 加到 1024检索召回率通常能涨三到五个点但从 1024 再加到 2048收益就很小了边际递减非常明显。所以我的建议是显存允许的话优先把 batch 堆到 1024 左右再往上加不如把同样的算力花在数据质量上。2.4 四项损失的加权与合并方式把四个目标合起来总损失是这样L_total λ_M · L_MMM λ_I · L_IMG_MLM λ_T · L_TXT_MLM λ_C · L_CLIP λ_ITM · L_ITM权重怎么定是这套方法里最玄学的部分。我见过不少复现失败案例八成栽在这里。几个原则我踩过坑之后总结出来了第一对比学习的权重不要一开始就给满。训练早期单模态编码器的表征还很粗糙对比损失梯度又大权重给高了会把模型往两个模态各自坍缩到一个点的方向推。稳妥的做法是前若干步用较小的权重比如 0.3 到 0.5等掩码建模的损失降到一定程度再逐步提到 1.0。第二掩码建模的权重整体上要比对比学习高一些。因为掩码建模的损失绝对值本身就比对比损失大词表几十类交叉熵量级不同如果不做归一化直接用同样的权重掩码项会完全主导梯度。实践中我会先各跑几百步看一下四项损失的量级再按让四项损失大致落在同一数量级的原则去配权重这比死记一组数字有用得多。第三图文匹配的权重可以稍低。它的作用是修偏不是主力权重给到 0.5 左右通常就够。给太高会让模型过早地在融合空间里锁死判断反而抑制了细粒度的表征学习。下面这张表是我自己的起始配置仅作参考实际一定要根据损失曲线动态调损失项起始权重观察指标调整方向图像掩码建模1.0重建准确率长期不涨则考虑码本太粗文本掩码建模1.0掩码位置准确率曲线抖动则降学习率或加 warmup多模态掩码建模1.0双模态重建准确率明显低于单模态时检查模态类型嵌入对比学习0.3 → 1.0正样本相似度与负样本差值差值不拉开说明 batch 太小或温度不对图文匹配0.5二分类准确率过快到 95% 以上说明负样本太简单3. 数据工程两类数据源与掩码策略3.1 有标注图文对与单模态无标注数据的混配FLAVA 的训练数据由两部分组成这个设计很有意思也最容易被简化掉。一部分是图文对数据用来支撑对比学习和图文匹配这两个需要成对输入的目标另一部分是无标注的单模态数据——纯图像、纯文本它们不参与对比学习只参与各自的掩码建模。为什么要掺单模态数据因为高质量的图文对太贵了。几千万对已经是公开数据的量级但文本语料和图像语料各自都是论亿计的。如果只用图文对训练文本编码器的词表和语言能力会被图文对里的短文本严重限制——图注大多很短二三十个词模型学到的语言分布非常窄。掺入纯文本数据能让文本编码器真正学到语言结构掺入纯图像数据也一样能让图像编码器见到更丰富的视觉分布。配比上我的经验是图文对、纯图像、纯文本大致按 1:1:1 的量级混合比较稳但要保证图文对在每个 batch 里都占足够比例否则对比学习那一项就没法算了。实现上我是这样做的每个 batch 里固定划出一部分样本作为图文对剩下的位置从纯图像池和纯文本池里轮流填。这样既保证了对比学习有足够的负样本池又不浪费单模态数据。有个坑要提醒单模态数据的掩码建模损失和图文对里的掩码建模损失量级是不一样的。纯文本的句子长度分布和图文对里的短图注差异很大如果混在一起不做长度归一化你会看到损失曲线呈现出诡异的周期性波动——每次采样到长文本 batch 就跳一下。解决办法是损失按有效 token 数取平均而不是按 batch 取平均。3.2 图像块掩码与文本掩码的具体做法图像侧的掩码策略值得单独说。前面提到遮 70%但怎么遮比遮多少更影响效果。有两种常见方案随机遮单个 patch或者按块遮把图像切成若干大块随机选一部分块整体遮掉。随机单点遮的问题在于相邻 patch 之间相关性极强模型只看四周就能推断出中心任务太简单。块状遮法逼着模型做更长程的推理学到的表征质量明显更好。实测对比下同样是 70% 的掩码率块状遮法在下游分类任务上能比随机单点遮高出两到三个点。代价是实现复杂一点需要先生成一个块级的随机掩码再上采样到 patch 级别。文本侧的掩码相对标准化15% 的比例按 BERT 那套 80/10/10 的策略。但有个细节图文对里的文本往往很短如果按固定比例遮很短的句子可能一个词都遮不到这个样本就白跑了。我的做法是设一个保底数量比如至少遮一个 token避免浪费。3.3 数据管线的并发与预处理开销数据管线这块说起来枯燥但它决定了你的训练能不能跑满卡。图像解码和增强是 CPU 密集型操作一张 224×224 的图从 JPEG 解码到张量单核大概要几毫秒一个 batch 一千张就是几秒钟完全可能拖垮 GPU 利用率。几个实际有效的优化一是把图像预先解码成低分辨率的紧凑格式缓存起来训练时只做轻量增强这一步能把 CPU 压力降一大半二是增强操作尽量用 GPU 做现在主流的视觉库都支持把解码后的张量直接搬到卡上再做裁剪翻转CPU 只负责 I/O三是数据加载的 worker 数不要凭感觉设按CPU 核数除以单卡数再减二来配通常是个合理的起点。文本侧反而简单提前把分词结果缓存成定长数组训练时直接索引不要在线分词。4. 动手搭一个缩小版代码与配置4.1 输入构造与分词处理下面这套代码是我在单机多卡上验证过的骨架规模做了缩小但结构关系和原版一致可以直接拿去改。先看输入构造import torch from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(your-text-encoder) def build_batch(images, texts, max_len40): # images: list of PIL Image已完成增强 pixel_values torch.stack([img_augment(im) for im in images]) # [B,3,224,224] enc tokenizer( texts, paddingmax_length, truncationTrue, max_lengthmax_len, return_tensorspt, ) return { pixel_values: pixel_values, input_ids: enc[input_ids], # [B, L] attention_mask: enc[attention_mask], # [B, L] }这里max_len设 40 是个经验值图注类数据 95% 以上都在这个范围内再长就是长尾。如果你的业务文本偏长比如商品详情描述得单独评估因为文本长度直接影响到后面多模态编码器的序列长度进而影响显存。4.2 前向传播与跨模态序列拼接这一部分是整个实现的核心也是容易写错的地方。三个编码器的调用顺序和拼接方式如下def forward(self, pixel_values, input_ids, attention_mask, img_maskNone, txt_maskNone): # 1) 单模态编码 img_tokens self.image_encoder(pixel_values) # [B, 197, 768] txt_tokens self.text_encoder(input_ids, attention_mask) # [B, L, 768] img_cls img_tokens[:, 0] txt_cls txt_tokens[:, 0] # 2) 掩码替换被遮住的位置换成可学习的占位向量 if img_mask is not None: img_tokens torch.where( img_mask.unsqueeze(-1), self.mim_embedding.expand_as(img_tokens), img_tokens, ) if txt_mask is not None: txt_tokens torch.where( txt_mask.unsqueeze(-1), self.mask_embedding.expand_as(txt_tokens), txt_tokens, ) # 3) 拼接图像序列在前文本序列在后 fused torch.cat([img_tokens, txt_tokens], dim1) # [B, 197L, 768] # 模态类型嵌入区分这个位置原本属于哪个模态 fused fused self.modality_type_embed(fused) fused_out self.multimodal_encoder(fused, attention_maskbuild_fused_mask(...)) return img_cls, txt_cls, fused_out有两点必须强调。模态类型嵌入不能省。拼接之后图像 token 和文本 token 在同一个注意力空间里模型必须知道每个位置的身份。如果不加这个嵌入模型只能靠位置推断——图像永远在前 197 个文本在后 L 个看似可以推但一旦序列长度变化比如图像分辨率改了这个隐式规则就崩了。加上显式的模态嵌入之后模型的泛化性会明显好很多。融合后的注意力掩码要重新构造。文本有 padding拼到后面之后图像部分全是有效 token文本部分有 padding。掩码矩阵要保证图像 token 能看见所有图像 token 和有效文本 token文本 token 之间按原掩码来padding 位置对任何 token 都不可见。这块写错的话训练能跑但效果会很差而且表面上查不出问题。4.3 四路损失的合并与反向传播拿到三组输出之后损失的组装是这样的# 掩码预测 img_logits self.img_mlm_head(fused_out[:, 1:1196]) # 视觉码本分类 txt_logits self.txt_mlm_head(fused_out[:, 197:]) # 词表分类 loss_mmm_img masked_ce(img_logits, img_labels, img_mask) loss_mmm_txt masked_ce(txt_logits, txt_labels, txt_mask) # 对比损失 z_img F.normalize(self.img_proj(img_cls), dim-1) z_txt F.normalize(self.txt_proj(txt_cls), dim-1) loss_clip clip_loss(z_img, z_txt, self.temperature.clamp(min0.01)) # 图文匹配 match_logits self.itm_head(fused_out[:, 0]) loss_itm F.cross_entropy(match_logits, itm_labels) loss (w_mmm * (loss_mmm_img loss_mmm_txt) w_clip * loss_clip w_itm * loss_itm) loss.backward()masked_ce这个函数要自己写核心是只在掩码位置计算交叉熵其余位置置零。用F.cross_entropy(..., reductionnone)拿到逐位置损失再乘掩码求和除以掩码总数是最直观的写法。记得处理整个 batch 一个掩码都没有的边界情况否则会出现除以零得到一个 NaN然后整个训练静默崩溃——这种 bug 极难定位因为报错信息指向的是几百步之后的某次反向传播。4.4 显存账本与超参配置显存这一块我算一笔账方便你决定 hardware 配置。假设 batch size 为 1024图像序列 197 个 token文本序列 40 个 token隐藏维度 768混合精度训练单层激活值大头是注意力的中间结果按 1024 × 237 × 768 × 2 字节算单个张量约 370MB一层里这类张量有十几个就是四五个 GB。12 层单模态编码器加 6 层融合编码器不做优化的话几十 GB 起步单卡放不下。实际可用的做法是梯度检查点前向只保留每层的输入反向时重算中间激活。代价是计算量增加 30% 左右收益是激活显存降到原来的十几分之一。开了检查点之后batch 1024 大概需要 4 到 8 张 80GB 级别的卡具体取决于序列长度和是否冻结图像编码器。如果只有单卡那就老老实实把 batch 降到 32 到 64靠梯度累积凑等效 batch。这里有个细节对比学习在梯度累积下会被削弱因为每次前向只看到自己那一个微 batch 的负样本累积多步之后的等效 batch 并不等于对比学习的有效负样本池。解决办法是维护一个特征队列把前几步算出来的特征缓存起来当额外负样本或者干脆接受这个损失把单步微 batch 设大一点32 已经能提供不错的负样本池。我自己的机器上是微 batch 64、累积 16 步效果接近真实 batch 1024 的八成。优化器配置大致如下参数取值说明优化器AdamWbeta 用默认的 0.9 / 0.999峰值学习率3e-4等效 batch 1024等效 batch 减半则学习率也大致减半权重衰减0.02比常规的 0.01 略高能压住后期过拟合学习率调度线性 warmup 余弦衰减warmup 步数取总步数的 2%太少容易前期崩梯度裁剪1.0四个损失叠加后梯度范数波动很大必须裁精度bf16 混合精度比 fp16 稳不需要损失缩放梯度裁剪这一项特别要提。四项损失同时反传梯度范数的波动比单目标训练大得多我遇到过梯度范数突然冲到几百的情况不裁剪的话一步就能把模型带偏。裁剪到 1.0 是稳妥的选择如果你发现训练前期损失下降极慢可以试试放宽到 5.0 观察一下。5. 下游迁移三种用法与微调路径5.1 检索任务只用单模态特征别用融合特征检索场景最省事的用法是直接冻结两个单模态编码器取 [CLS] 特征做向量检索。这里有个很多人会犯的错误既然模型有融合编码器那用融合后的特征去检索不是更准吗短期看确实准但代价是图像侧没法预计算。千万级图库上每次查询都跑一遍完整的图像编码延迟和成本都不可接受。正确姿势是用单模态特征建索引用融合特征做重排。具体来说先拿图像编码器的 [CLS] 向量建好向量库用户查询时用文本编码器的 [CLS] 向量做近似近邻检索召回前 100 条然后对这 100 对候选逐个跑一遍多模态编码器算图文匹配分数重排取前 10。这个两阶段结构能把召回率在纯双塔的基础上再提几个点同时延迟只增加一次百级别的融合前向完全可接受。建索引的时候向量的归一化方式要和训练时保持一致。训练时对比学习用的是 L2 归一化后的向量检索时也必须归一化后算余弦相似度用未归一化的原向量算内积会得到完全错误的排序。5.2 判别与问答类任务加轻量任务头微调分类、视觉问答这类任务标准做法是把多模态编码器的输出接一个任务头微调。视觉问答的场景下输入是图文拼接序列输出是答案分类或生成跟预训练时的多模态掩码建模结构很像迁移很自然。微调时我建议分阶段先冻结单模态编码器只训多模态编码器和任务头若干轮等损失降下来再解冻全部参数用小学习率预训练的十分之一左右继续训。这样做的原因是任务头的随机初始化会产生很大的梯度如果一开始就全量微调这股大梯度会顺着多模态编码器一路传回单模态编码器把预训练学好的表征破坏掉。分阶段训练能把这个破坏降到最低。微调数据量少的时候几千条级别还可以考虑只训多模态编码器的最后两三层加任务头其余全冻。这样参数量小过拟合风险低收敛也快。5.3 零样本能力从匹配分数到分类FLAVA 这类模型天然具备一定的零样本能力思路和图文检索一样把类别名转成文本提示比如一张{类别}的照片用文本编码器编码和图像特征算相似度取最高的那类作为预测。这个能力在预训练数据覆盖的类别上表现还不错但在专业领域医疗、工业基本失效因为预训练没见过这些视觉概念。实战里我的态度是零样本结果用来做快速验证和冷启动可以正式上线前一定要用少量标注数据做一次轻量微调或者至少做一次提示词调优。提示词的措辞对准确率影响能到五到十个点值得花半天时间枚举几十个模板做集成。6. 踩坑记录与排查清单6.1 对比损失塌缩最难查的一类故障症状是训练前几十步损失正常下降然后突然所有图像的相似度都变得很高batch 内任意一对的余弦相似度都接近 0.9对比损失卡在 ln(batch) 附近不再下降。这叫表征塌缩模型把所有输入映射到了同一个点。我遇到过三次原因各不相同。第一次是温度参数设得太小写死了 0.01梯度爆炸把表征推到一起第二次是学习率太大训练前期直接发散第三次最隐蔽是数据管线有 bug同一个 batch 里重复出现了同一张图的不同增强版本模型很容易就把它们对齐了然后顺着这条路把所有东西都对齐到一起。排查顺序我总结成一张表现象优先怀疑验证方式处理相似度矩阵全是 0.9温度过小打印温度参数实际值加下界约束clamp 到 0.01 以上损失从第一步就异常数据重复统计 batch 内图像哈希去重率修数据管线加去重逻辑损失周期性抖动样本长度不均按长度分桶看损失损失按有效 token 数归一化前期正常后期爆学习率无衰减打印各步学习率加余弦衰减、梯度裁剪6.2 显存与吞吐被忽视的隐性瓶颈显存不够好办降 batch、开检查点。真正难搞的是显存够但吞吐上不去。这种情况八成是 GPU 在等数据nvidia-smi 上看利用率忽高忽低像心电图。原因通常是数据加载的 worker 不够或者图像增强全压在 CPU 上。我一般会先看数据加载耗时占总步时的比例超过 20% 就要动手优化了。还有一种吞吐问题来自多模态编码器的序列长度。文本长度从 40 涨到 80融合序列从 237 涨到 277注意力计算量涨了 36%但参数量一点没变很容易被忽视。如果你的业务文本偏长一定要单独按最长长度做一次显存和吞吐评估别拿短文本的配置直接上线。6.3 常见问题速查表这张表是我自己攒的遇到问题先扫一遍能省不少时间问题可能原因排查动作掩码重建准确率长期停在很低水平视觉码本太粗或图像编码器被不当冻结检查码本大小确认图像编码器是否在更新图文匹配准确率一上来就 95%负样本太简单检查负样本采样逻辑加入难例挖掘检索召回率远低于预期特征未归一化或用了融合特征建索引确认归一化一致性改用单模态特征微调后效果不如冻结任务头初始梯度破坏预训练表征改成分阶段解冻先冻后放多卡训练损失曲线与单卡差异大对比学习跨卡负样本未打通确认是否做了跨卡 all_gather训练后期验证集指标下滑过拟合权重衰减不足提高权重衰减或加早停多卡那一项特别值得说。如果你的对比学习没有实现跨卡的特征汇聚每张卡各自算自己那部分 batch 的对比损失等效负样本池就缩小到了单卡 batch 大小八卡并行相当于白瞎了七卡的负样本。实现上就是把各卡的图像特征和文本特征 all_gather 拼成全局矩阵再算损失注意梯度要正确回传到各自的卡。这一步写错不会报错只会让你的模型效果比你预期的差一截非常隐蔽。我自己在这个方向上投入的时间大概有一半不是在调模型结构而是在修数据管线和验证训练目标之间的相互干扰。FLAVA 这套框架的价值不在于某个单点技术有多新而在于它把单模态表征、跨模态对齐、深度融合这三件在工程上长期割裂的事塞进了一次训练里。如果你手头的业务同时需要检索和融合两类能力这套思路值得完整复现一遍如果只做检索那双塔加上好数据其实更划算别为了架构优雅给自己加复杂度。