FLAVA三塔与五损失实战：多模态预训练复现落地避坑

手里同时压着三件事的时候，人最容易做的一个动作就是"再加一套模型"。我去年就干过这么一回：项目里既要给内容打图像标签、又要做图文检索、还要回答关于图片的问题，结果一口气养了三个模型，三个训练脚本、三份数据管线、三套超参配置，改一个共享的预处理逻辑就得同步改三处，维护起来非常折腾。后来我把注意力转到FLAVA这类统一模型上——它的核心卖点就是用一套Transformer 架构，把图像、文本、以及图文对三类输入塞进同一个多模态预训练框架里，一个权重文件同时覆盖单模态和多模态任务。这篇就聊聊我照着这套思路做复现和落地时，真正踩到的东西：三塔结构各自的分工边界、五个损失函数为什么不能砍、代码怎么写才能跑起来、以及在什么规模的数据和显存条件下这套方案会开始"不划算"。适合已经熟悉基础 Transformer、想动手跑一遍跨模态预训练，或者正准备在业务里引入视觉语言模型的读者，小白也能看懂大框架，老手可以直接抄走配置和避坑点。

1. FLAVA统一了什么：三塔各自的实际职责与边界

先把这个架构最容易被误解的地方讲清楚。很多人第一次看统一模型，脑子里想的是"一个大模型处理所有输入"，于是下意识觉得应该只有一个主干。FLAVA 不是这么干的，它用的是三塔并行：图像编码器、文本编码器、多模态编码器，三个独立的 Transformer 主干，参数量加起来两亿多，量级在 ViT-Base 那档。这个设计选择非常关键，因为它决定了很多后续的工程细节——显存怎么算、batch 怎么组、哪些层可以冻结、微调时该动哪一块。

为什么不用一个主干？原因在于任务形态不同。纯图像输入没有文本 token，纯文本输入没有图像 patch，如果强行共用一个主干，那么每次前向都得把另一模态的位置空出来或者用占位符补齐，注意力计算里会混进大量无效位置，训练效率和表征质量都受损。分成三塔之后，每个塔只处理自己擅长的那种输入形态，职责清晰，而"统一"体现在它们共享同一套预训练流程和同一份权重文件，推理时按输入类型选择走哪条路径。我一开始觉得这是妥协，后来发现这恰恰是它实用的地方：图像分类任务只走图像塔，速度快；图文检索走两个单模态塔加对比头；视觉问答走多模态塔，各取所需。

1.1 图像塔：ViT 主干与离散标签的配合逻辑

图像塔是标准的 ViT 结构，patch 大小 16，输入 224×224 时切成 14×14 共 196 个 patch，加上一个 [CLS] token 总共 197 个位置，12 层、768 维隐层、12 个注意力头。这套配置和通用 ViT-Base 基本一致，好处是可以直接加载现成的图像预训练权重做初始化，省掉大量冷启动时间。

真正需要单独说的是它的预训练任务。图像塔上挂的不是分类头，而是掩码图像建模（Masked Image Modeling）。具体做法是把 196 个 patch 随机遮掉约 40%，让模型根据剩下的 patch 去预测被遮住位置的离散视觉 token。这里就引出第一个实操上的关键点：这些离散 token 从哪来？需要预先训练一个离散自编码器（dVAE 这一类），把每个 patch 映射到码本里的一个编号，码本大小通常在 8192 这个量级。也就是说，你要跑完整的 FLAVA 预训练，前置条件是先有一个能用的视觉 tokenizer。

我第一版为了省事，直接拿像素回归代替离散 token 预测，也就是让模型预测被遮住 patch 的原始像素均值。跑是能跑，但下游检索指标明显偏低，大概掉了三到四个点。原因不复杂：像素回归的监督信号太"局部"，模型学会的是补全颜色和纹理，而不是学语义类别，而离散 token 因为有码本这个瓶颈，天然带一点聚类性质，预测它更接近在学"这块是什么东西"。所以我的建议是：如果要做真正的预训练，务必先把离散 tokenizer 搞定；如果只是想快速验证下游任务，可以先用现成的通用视觉 tokenizer 权重，别自己从头训。

这里有个容易忽略的细节：掩码比例 40% 不是随便定的。低于 30% 时任务太简单，损失掉得飞快但表征没学到东西；高于 50% 时剩余上下文太少，模型开始靠猜，收敛变慢且不稳定。40% 附近是我实测下来比较平衡的区间，不同数据分布下可以在 35% 到 45% 之间微调。

1.2 文本塔：掩码语言建模的老配方在新场景里的变化

文本塔同样是 12 层、768 维、12 头的 Transformer 编码器，输入是 token 序列，输出是每个位置的隐状态。它的预训练任务是最经典的掩码语言建模，随机遮掉 15% 的 token，让模型预测原词，遮罩策略沿用 80/10/10 那套：80% 换成特殊占位符、10% 换成随机词、10% 保持不变。这套配方用了很多年，稳定可靠，我不建议在这里做花活。

需要注意的是序列长度。做短文本分类或者标签预测，64 到 128 个 token 足够；做长描述匹配或者文档级检索，就得拉到 256 以上。长度直接决定显存和计算量，而且是平方关系。我的做法是先按任务分布统计一下 95 分位的长度，再往上留一点余量，别一上来就设成 512，那会让训练成本凭空翻好几倍。

还有一个实践上的取舍：文本塔要不要和图像塔共享词嵌入？我的答案是不要。图像 patch 嵌入和词嵌入的语义空间完全不同，共享只会互相干扰。真正值得共享的是位置嵌入之外的结构参数吗？也不是。三塔各自独立初始化，靠后面的联合训练让它们对齐，这条路线我试下来比强行共享稳得多。

1.3 多模态塔：拼接序列里的对齐究竟是怎么发生的

多模态塔是三塔里最容易被写错的一个。它的输入不是两路分别过注意力再做交互，而是把图像塔输出的 196 个 patch 特征和文本塔输出的若干 token 特征直接拼成一条序列，前面再加一个专用的 [CLS]，然后在这条长序列上跑标准的自注意力。为了让模型分得清哪段是图、哪段是文，还要给每个位置加一个模态类型嵌入（图像一个向量、文本一个向量），和位置嵌入一起加到输入上。

这个设计的妙处在于，跨模态交互不需要专门的跨注意力模块——自注意力本身就让每个文本 token 能看到所有图像 patch，反之亦然。而 [CLS] 位置的输出，因为能聚合整条序列的信息，天然就成了"这张图和这段文字是否匹配"的整体表征，ITM 二分类头和图文对比损失都从它上面取。

我最初照着某些教程写成了"文本做 query、图像做 key/value 的单向跨注意力"，结果发现视觉问答任务上效果很差。原因很直白：单向跨注意力里图像 patch 之间没有互相看过，视觉侧的上下文是碎的，遇到需要细粒度空间推理的问题就露怯。改成拼接序列加全自注意力之后，同一份数据的准确率提升了将近五个点。这个弯路我觉得值得写出来，因为很多简化版实现就是这么砍的，砍完还能跑通，但上限被压死了。

代价是计算量。拼接之后序列长度是 197 加上文本长度，接近 300 个位置，而自注意力是平方复杂度。这是多模态塔显存吃紧的根本原因，后面第 5 节会具体算。

2. 五个预训练目标为什么必须同时存在

FLAVA 一共挂了五个损失：图像侧的掩码建模、文本侧的掩码语言建模、图文匹配、全模态掩码建模、以及图文对比。刚看到这个清单时我的第一反应是"冗余"，尤其是图文匹配和图文对比，感觉功能重叠，砍一个应该没关系。实测下来这个想法是错的，而且错得挺贵——我砍掉全模态掩码那次，检索指标只掉了一点点，看起来像是验证了"冗余"的判断，但换到视觉问答类任务上直接崩了十几个点。这才让我认真去拆每个损失到底在管什么。

2.1 单模态掩码建模：守住各自的表征质量

掩码图像建模和掩码语言建模这两个损失，作用对象是单模态塔。它们的存在意义经常被低估——既然有跨模态对齐了，单模态表征还重要吗？非常重要。图文检索这种任务，效率和精度都依赖"分别编码再算相似度"这条路，如果图像塔单独输出的特征很弱，对比学习再怎么拉也拉不出好的检索效果。

更实际的一点是零样本能力。零样本图像分类的做法是把类别名称转成文本、编码成文本特征，再和图像特征算相似度。这条路径完全不经过多模态塔，纯靠两个单模态塔的特征质量。我做过一组对照：把单模态掩码损失的权重降到 0.2，跨模态损失不变，结果零样本分类掉了接近六个点。所以这两个损失是"地基"，不能因为看不到直接收益就削减。

实操上要注意的是掩码建模的收敛节奏。它俩的损失值下降非常快，通常几千步就到平台期，而跨模态损失还在震荡。如果你用固定权重联合训练，前期会被单模态损失主导，模型几乎不学对齐。我的处理是分阶段：前若干千步只开单模态损失做预热，之后再逐步把跨模态损失权重拉起来。

2.2 图文匹配与全局对比：看着重叠其实分工不同

这两个损失经常被混为一谈，但它们的监督信号粒度不一样。

全局对比损失（InfoNCE 那一套）是在 batch 维度上做的：一个 batch 里有 N 个图文对，把图像特征和文本特征做归一化后算 N×N 的相似度矩阵，对角线是正样本，其余是负样本，双向做交叉熵。它优化的是"在一个 batch 里，正确的那一对相似度要最高"。这本质上是一种排序约束，它不要求匹配对的绝对相似度有多高，只要求比别的对高。

图文匹配损失是把图文对送进多模态塔，取 [CLS] 输出过一个线性层做二分类，判断"匹配/不匹配"。负样本一部分来自 batch 内的错配，一部分来自随机采样。它优化的是绝对判断，模型必须真的理解图文之间的细粒度对应关系，而不是靠相对排序蒙混过关。

区别在哪？举个具体场景。图片是"一只狗在草地上接飞盘"，负样本文本是"一只猫趴在窗台上"。全局对比只要判断出这俩不是一对就行，很容易。但如果负样本文本是"一只狗在草地上追球"，全局对比几乎区分不出来，因为语义太近了；这种情况下 [CLS] 的细粒度匹配判断才有价值。所以两个损失是粗排 + 精排的互补关系，都得留。

温度系数这里有个实操点。对比损失的温度初始值设 0.07 是常见做法，但我建议把它设成可学习参数并加个下界约束（比如不低于 0.01）。固定温度在数据分布不均时容易出问题：温度太低会导致训练不稳定、梯度爆炸，太高则失去区分度。可学习的话模型会自己找平衡点，我实测下来收敛更平滑。

2.3 全模态掩码：让跨模态注意力真正承担预测任务

全模态掩码建模是我认为最容易被砍掉、又最不该砍的一个。做法是把图文对送进多模态塔之前，同时遮住一部分图像 patch 和一部分文本 token，然后要求模型在被遮住的位置上分别预测出正确的视觉 token 和文本词。掩码比例各自沿用单模态的设置，图像 40%、文本 15%，这个组合我试过几轮，比较稳。

为什么它重要？因为它是唯一一个强制模型利用另一模态信息来做预测的任务。掩码语言建模可以只看文本上下文猜词，掩码图像建模可以只看周围 patch 猜块，但全模态掩码里，如果被遮住的是关键名词，光看剩下的文本很难猜准，模型必须去看图；如果被遮住的是图像主体区域，光看周围 patch 也补不出来，得读文字描述。这种"被迫跨模态"的监督信号，是培养细粒度对齐能力的关键。

验证方式很直接：我在一个需要空间关系推理的视觉问答基准上做对比，去掉全模态掩码后准确率从基准值掉了一大截，而且模型倾向于回答"是/否"这类高频答案，说明它其实没在认真看图。加回来之后，注意力可视化能看到文本里的方位词确实把注意力打到了对应的图像区域上。

这个损失的成本不低，因为它要在多模态塔上跑完整的前向加反向，而多模态塔是三塔里最贵的。所以训练时长的瓶颈基本都在它身上。

2.4 损失配比与梯度冲突的实测经验

五个损失放在一起，最直接的麻烦是量纲不一致。掩码建模的损失是逐 token 的交叉熵平均，量级通常在个位数；对比损失经过温度缩放后可能只有零点几；匹配损失又是二分类交叉熵。如果不做权重调整直接相加，模型会自动忽略那些数值小的损失。

我的起步配置是五个损失权重都为 1，但因为前面说的分阶段策略，实际跑起来是动态的。下面这张表是我在中等规模数据上试出来的几组配置，供参考：

"梯度冲突"这个说法听起来玄，实际表现是：某些步数里跨模态损失的梯度方向会和单模态损失打架，导致损失曲线一起往上翘。缓解手段有两个，一是梯度裁剪（裁剪阈值 1.0），二是分阶段放开损失。我用的是前 3000 步只开两个单模态掩码损失，3000 到 8000 步逐步加上对比和匹配，8000 步之后全开。这个节奏下曲线从来没有出现同步上翘的情况。

3. 把三塔骨架搭起来：可直接改的代码级实现

理论讲完，进入能跑的部分。我用 PyTorch 写了一个最小可运行的骨架，去掉了一些工程包装，保留核心结构，方便你直接拿去改。整体思路是三个模块各自独立，然后一个顶层容器负责调度。

3.1 三塔的初始化策略与投影层设计

图像塔直接用现成的 ViT-Base 权重初始化最省事，去掉原来的分类头，保留主干和 [CLS]。文本塔和它结构一样，但如果你的语料是中文或者混合语言，建议换一个匹配的词表，词表大小直接决定嵌入层参数量，差一倍很常见。

import torch import torch.nn as nn from transformers import ViTModel, BertModel class FlavaTowers(nn.Module): def __init__(self, img_ckpt="path/to/vit-base", txt_ckpt="path/to/text-base", dim=768, mm_depth=12, mm_heads=12): super().__init__() # 图像塔：ViT-Base，patch16，输出 196 个 patch 特征 + 1 个 CLS self.image_tower = ViTModel.from_pretrained(img_ckpt) # 文本塔：同维度的 Transformer 编码器 self.text_tower = BertModel.from_pretrained(txt_ckpt) # 多模态塔：拼接序列上的标准自注意力 self.mm_cls = nn.Parameter(torch.zeros(1, 1, dim)) self.mm_modal_emb = nn.Embedding(2, dim) # 0=图像, 1=文本 self.mm_pos_emb = nn.Parameter(torch.zeros(1, 512, dim)) layer = nn.TransformerEncoderLayer( d_model=dim, nhead=mm_heads, dim_feedforward=dim * 4, dropout=0.1, activation="gelu", batch_first=True, norm_first=True ) self.mm_tower = nn.TransformerEncoder(layer, num_layers=mm_depth, enable_nested_tensor=False) self.mm_norm = nn.LayerNorm(dim)

这里有两个细节值得停一下。第一，norm_first=True（Pre-LN）在深层 Transformer 上比 Post-LN 稳，尤其是多模态塔这种长序列、深层的结构，用 Post-LN 很容易在训练早期出现损失震荡。第二，多模态塔的层数我设成和单模态塔一样是 12 层，这是原设计的做法，但也意味着它的计算量最大，如果显存吃紧，可以先降到 6 层跑通流程，实测下游指标损失在可接受范围内。

3.2 前向传播的三种模式与模态嵌入的加法位置

前向要支持三种输入组合：只有图像、只有文本、图文对。这个分支逻辑必须写清楚，否则推理时容易走错路径白白算一遍多模态塔。

def forward(self, pixel_values=None, input_ids=None, attention_mask=None): img_out = txt_out = None if pixel_values is not None: img_out = self.image_tower(pixel_values=pixel_values).last_hidden_state if input_ids is not None: txt_out = self.text_tower(input_ids=input_ids, attention_mask=attention_mask).last_hidden_state # 单模态场景直接返回，不走多模态塔 if img_out is None or txt_out is None: return {"image_feat": img_out, "text_feat": txt_out} b, n_img, d = img_out.shape n_txt = txt_out.shape[1] cls = self.mm_cls.expand(b, -1, -1) seq = torch.cat([cls, img_out, txt_out], dim=1) # 模态嵌入：CLS 归为图像侧，图像 patch 记 0，文本 token 记 1 modal_ids = torch.cat([ torch.zeros(1 + n_img, dtype=torch.long, device=seq.device), torch.ones(n_txt, dtype=torch.long, device=seq.device) ]) seq = seq + self.mm_modal_emb(modal_ids).unsqueeze(0) seq = seq[:, : self.mm_pos_emb.shape[1]] + self.mm_pos_emb[:, : seq.shape[1]] mm_out = self.mm_norm(self.mm_tower(seq)) return {"image_feat": img_out, "text_feat": txt_out, "mm_feat": mm_out}

模态嵌入的加法位置是很多人写错的地方。它必须一个位置一个位置地加，而不是整段加同一个向量，否则模型根本分不清第几个位置属于哪个模态。另外mm_pos_emb的长度要够，197 加文本长度可能超过 300，我预留到 512，宁可浪费一点参数也别越界。

3.3 五个损失函数的具体写法

损失这块我按模块拆开写，方便你单独开关做消融。

class FlavaLosses(nn.Module): def __init__(self, dim=768, vocab_size=8192, temperature=0.07): super().__init__() self.img_head = nn.Linear(dim, vocab_size) # 预测离散视觉 token self.txt_head = nn.Linear(dim, -1, bias=False) # 与词表共享权重，稍后绑定 self.itm_head = nn.Linear(dim, 2) # 图文匹配二分类 self.temp = nn.Parameter(torch.tensor(temperature)) def contrastive(self, img_feat, txt_feat): # 取 CLS 位置，L2 归一化后算相似度矩阵 i = nn.functional.normalize(img_feat[:, 0], dim=-1) t = nn.functional.normalize(txt_feat[:, 0], dim=-1) logits = i @ t.t() / self.temp.clamp(min=0.01) labels = torch.arange(i.size(0), device=i.device) return (nn.functional.cross_entropy(logits, labels) + nn.functional.cross_entropy(logits.t(), labels)) / 2 def itm(self, mm_feat, labels): return nn.functional.cross_entropy(self.itm_head(mm_feat[:, 0]), labels)

文本侧的预测头要和词嵌入绑定权重，也就是self.txt_head.weight = text_tower.embeddings.word_embeddings.weight，这一步不做的话参数量白白多出一大块，而且效果通常更差，因为解码头和输入嵌入不在同一个空间里。视觉侧的解码头不能绑，因为码本和 patch 嵌入没有对应关系。

温度参数用clamp(min=0.01)兜底，防止训练中它被优化到极小的值导致除零或者梯度爆炸。这个细节我是在一次跑了半天突然 loss 变 NaN 之后才加上的。

4. 数据管线：图文对的质量比数量更能决定上限

预训练这行有个说法叫"数据即模型"，在跨模态场景下尤其成立。我前期花了大概两周时间在数据清洗上，后面模型效果的提升幅度比调参一个月都大。这里讲三个我认为最容易出问题的环节。

4.1 图文相关性过滤：噪声样本会教坏对齐

网上直接抓的图文对，相关性差的比例相当高。图片里是一张产品图，配文却是一整段营销文案加一堆话题标签；或者图片是拼图，文字只描述了其中一角。这类样本对对比学习的伤害特别大，因为它们会把不该拉近的特征强行拉近。

我的过滤流程分三层。第一层是规则过滤：文本长度过短的（少于 5 个词）、纯符号或纯链接的、图片分辨率低于阈值的，直接丢。第二层是语言检测和去重，用现成的语言识别工具过滤掉语种混乱的样本，再用感知哈希对图片去重，重复图会导致对比学习的负样本里混进假负样本。第三层是模型打分，用一个已经训好的小规模图文匹配模型给每对打相关性分数，低于阈值的丢掉。

第三层最费时间但收益最大。我试过用不同阈值，筛掉 30% 的数据量之后，训练同样的步数，下游检索指标反而上升了。这个反直觉的结果说明了一件事：低质量样本不只是拖后腿，它们是在主动教模型学错的东西。

提醒一句，模型打分这步本身有偏，它会给和自己训练分布相近的样本打高分。如果你的目标领域和打分模型差异很大，最好人工抽检几百条看看打分是否合理，别盲信阈值。

4.2 图像增强与离散 token 标签的生成顺序

这个坑我踩得比较实。图像侧的掩码建模需要预先算好每个 patch 的离散 token 作为标签。问题是：这个标签必须在增强之后算，还是之前算？

答案取决于你的增强策略。如果增强只是随机裁剪加缩放，那么裁剪后的图像内容变了，patch 对应的语义也变了，必须先增强、再算 token。如果增强是颜色抖动这类不影响空间结构的操作，顺序影响不大。但如果用到 RandAugment 里那种会改变语义的操作（比如旋转、剪切），那就必须先增强。

我第一版写成了先算 token 再增强，结果模型在训练集上损失降得飞快但验证集不涨，排查了很久才发现是标签和输入对不上，相当于在教模型记错误的映射。改成先增强后算 token，问题立刻消失。这个顺序一定要在代码里写死，别依赖调用者的自觉。

另外 token 生成最好离线批量预处理并缓存，不要在每个 epoch 现场算。dVAE 的编码前向不便宜，现场算会让数据加载成为瓶颈，GPU 利用率掉到 40% 以下都有可能。我用的是分片存储，把 token 索引和图像路径一起写进二进制文件，加载时直接 mmap。

4.3 batch 内负样本与分布式采样的错配问题

对比损失的效果高度依赖 batch 内负样本的数量和质量。单卡 batch 开到 32 的时候，负样本只有 31 个，信号太弱；理想情况是几百甚至上千个负样本。这就得靠多卡训练，让各卡的样本汇聚起来算对比。

多卡带来一个新问题：同一 batch 里可能出现语义极其相似的样本对，比如同一张图的不同裁剪版本，或者同一事件的多篇报道。这些在对比学习里会被当成负样本，但它们其实应该算正样本，强行推开会损害表征。这叫"假负样本"问题。

缓解手段有几个。一是在数据采样阶段就做去重和聚类分散，保证同一个 batch 内的样本尽量多样。二是用跨卡梯度汇聚的时候加一个队列，把历史 batch 的特征存起来当负样本，这样既能扩大负样本池又不必无限增大 batch。三是把温度调高一点，让相似但不相同的样本不至于被过度惩罚。我用的是第二种加第三种组合，实测比单纯加大 batch 更省显存。

分布式训练还有个纯工程的问题：各卡的图文对必须一一对应，不能出现某张卡拿到 31 个对、另一张卡拿到 33 个对的情况，否则汇聚的时候矩阵形状对不上。用标准的分布式采样器能避免，但如果你自己写了采样逻辑，记得检查。

5. 显存与训练稳定性：复现时绕不开的现实约束

聊完数据聊硬件，这一段可能劝退一部分人，但我认为必须说清楚，因为 FLAVA 这类模型的资源门槛是真实存在的，很多人照着论文配置开跑，第一晚就 OOM。

5.1 峰值显存的来源拆解与粗略估算

显存大头在三块：模型参数、优化器状态、激活值。

参数量两亿多，用 FP32 存储大约 800MB 出头，混合精度下参数本身占一半左右，但优化器状态（Adam 的两个动量）还是要按 FP32 存，大约是参数量的两倍。所以光模型加优化器，一张卡上就得准备 2GB 到 3GB。

真正的杀手是激活值。多模态塔的序列长度接近 300，12 层，每层的注意力矩阵是 batch × heads × 300 × 300，光这一项在 batch=16 的时候就吃掉好几 GB。再加上中间 FFN 的激活，整体峰值很容易上到 20GB 以上。

我的估算是这样：单卡 24GB，混合精度加梯度检查点，多模态塔 12 层，batch 大概能到 12 到 16。如果降到 6 层，能翻一倍。如果关掉梯度检查点，直接砍半。这几个数字是我在不同配置下实测的量级，你的图像分辨率、文本长度、patch 数量一变，要重新算。

5.2 有效 batch size 的换算与梯度累积的边界

对比学习需要大 batch，但显存不允许，于是用梯度累积模拟。这里有个常见误区：梯度累积能让优化器看到大 batch，但它不能增加对比损失的负样本数量。因为负样本是在前向时 batch 内算的，累积只是把几个小 batch 的梯度加起来，每个小 batch 的对比矩阵还是只有那么大。

这个区别很重要。如果你的瓶颈是"负样本不够"，梯度累积帮不上忙，得靠跨卡汇聚或者负样本队列。如果瓶颈只是"梯度噪声大、训练不稳"，梯度累积有效。

换算关系要清楚：假设单卡 batch 是 8，8 张卡，梯度累积 4 步，那么优化器每步看到的样本是 8 × 8 × 4 = 256，但对比损失里的负样本只有 8 × 8 = 64 个。我在配置里会把这个区别写进注释，防止后面接手的人误判。

学习率要跟着有效 batch 调整。经验法则是有效 batch 翻倍，学习率线性放大，但放大倍数一般不打满，我通常用平方根缩放，也就是 batch 翻四倍，学习率翻两倍。这个策略在大 batch 下更稳。

5.3 混合精度下的数值稳定性处理

混合精度是必须开的，不然显存和时间都不够用。但它会带来几个具体的坑。

第一个是层归一化的数值问题。在 FP16 下，LN 的方差计算容易溢出或下溢。解决办法是让 LN 层保持 FP32 计算，用自动混合精度的白名单机制把这些层排除在外。

第二个是对比损失的相似度矩阵。归一化后做矩阵乘，结果在 -1 到 1 之间，除以温度 0.07 之后放大到 ±14 左右，再取指数，FP16 的上限是 65504，勉强够但没余量。如果温度被学到 0.02，放大倍数到 50，指数直接溢出。所以相似度计算那一段我强制用 FP32，代价很小。

第三个是损失缩放。梯度裁剪和损失缩放要配合着调，初始缩放因子设 2 的 16 次方，如果连续若干步出现梯度溢出就减半。多模态塔的梯度范数波动比单模态大，我遇到过缩放因子一路降到 2 的 8 次方才稳住的情况，那时候训练其实已经不太健康了，后来是靠调低学习率解决的。

一条经验：训练前 500 步如果损失出现两次以上 NaN 或者剧烈跳变，别急着调损失权重，先怀疑精度问题。把多模态塔单独切成 FP32 跑几百步看看是否恢复正常，这个排查路径比漫无目的地调参快得多。

6. 下游任务落地：三种典型接法与对应调参

预训练完只是开始，真正见效果在下游。FLAVA 这种统一结构的好处是不同任务可以用不同路径接，省掉重复训练。下面是我实际用过的三种接法。

6.1 零样本图像分类：prompt 模板比模型本身更影响结果

零样本分类完全不走多模态塔，只用两个单模态塔。流程是：把每个类别名称套进一个模板（比如"一张{类别}的照片"），编码成文本特征；把待分类图像编码成图像特征；算余弦相似度取最大值。整个过程不做任何微调。

这里最影响准确率的居然是模板设计。我做过对比，单一模板"一张{类别}的照片"和集成多个模板（"一张{类别}的照片"、"这是{类别}"、"{类别}的特写"等，特征取平均）相比，后者能高出两到三个点。原因是文本编码器对句式的敏感度超出预期，不同模板把类别词映射到特征空间的不同位置，平均之后相当于做了一次集成。

还有个细节：特征一定要做 L2 归一化再算相似度，否则不同样本的特征模长差异会污染排序。这个看起来是常识，但我见过不止一个实现忘了做，指标莫名其妙偏低。

类别名称的措辞也值得琢磨。用自然语言里的常见说法比用生僻的学名效果好，因为预训练语料里前者出现频率高。如果某个类别名在语料里很罕见，可以手工补几个同义表述一起编码平均。

6.2 图文检索：用哪一塔的特征决定了效率上限

检索任务两种方向：图搜文、文搜图。做法都是分别编码后建索引，查询时算相似度。关键决策是用哪一层的特征——单模态塔的 [CLS]，还是多模态塔的 [CLS]？

单模态塔的特征好处是可以离线预计算，所有库里的图文提前编码好存向量库，查询时只编码一次 query，延迟很低。多模态塔的特征必须现场把 query 和目标拼起来跑一遍前向，库有多大就得跑多少次，成本完全不可接受。

所以工业场景基本都是走单模态塔加对比学习的路子。但代价是精度不如多模态塔。我在同一个测试集上对比过，单模态塔的召回率比多模态塔低三到五个点。如果对精度要求极高且库很小，可以两级：先用单模态塔粗排召回 Top-100，再用多模态塔精排，这样兼顾效率和精度。

微调的时候有个技巧：冻结图像塔，只微调文本塔。因为图像数量通常固定，图像特征可以一次性算好缓存，后续只跑文本塔，训练速度能快好几倍。当然如果两个模态的分布都要适配，就得都放开，代价自己权衡。

6.3 视觉问答与推理类任务：多模态塔的微调策略

这类任务必须走多模态塔，因为要理解"图里的某物和问题里的某个词"之间的对应关系。接法是在多模态塔的 [CLS] 或序列输出上加一个分类头，预测答案词表上的分布。

微调策略上，我的经验是分层设置学习率。多模态塔用较大的学习率（比如 5e-5），两个单模态塔用小得多的（1e-5 甚至冻结）。原因是多模态塔的交互能力需要适配具体任务的推理模式，而单模态塔的通用表征已经很好，动太多反而破坏。

另一个要注意的是答案空间的设计。开放式生成很难训，通常是先统计训练集里出现频率最高的若干答案构成封闭词表，做分类而不是生成。词表大小一般在两千到三千之间，覆盖大部分样本。低于这个数会漏答案，高了分类头参数量上来又容易过拟合。

还有个实际经验：这类任务的验证集指标波动很大，尤其样本量不大的时候。我一般会跑三个随机种子取平均，单次结果不作为决策依据。有一次单次跑出来涨了五个点，兴冲冲上线，复跑两次发现其实只涨了一点点，纯属随机波动。

7. 我踩过的坑与当前方案的实际边界

把上面这些串起来，最后整理一份可以直接对照的清单。这些都是我在实际项目里撞过的，不是从文档里抄的。

说完坑，也得说边界。这套方案不是万能的，我在两个场景里明确判断它不划算。

第一个是数据量很小的情况。如果你的图文对只有几万条，从零预训练完全没有意义，模型学不到东西。这种时候正确做法是拿公开的大规模预训练权重直接微调，或者干脆用更轻量的双塔结构做对比学习，别碰五个损失的完整框架。预训练的收益是随数据量超线性增长的，小数据上它是负收益。

第二个是只需要单一任务的情况。如果你的业务里只有图像分类，那用一个图像模型就够，硬上三塔只会让推理成本翻倍、部署复杂度上升，没有任何收益。统一模型的价值在于"多任务共存"，任务只有一个的时候，"统一"就是纯粹的负担。

还有一个隐性的成本：推理延迟。多模态塔的序列长度是单模态的近两倍，注意力是平方复杂度，实际延迟大概是纯图像塔的四倍左右。如果业务对响应时间敏感，得认真评估能不能只用单模态路径。我在一个实时性要求较高的场景里最后就是只部署了图像塔和文本塔，多模态塔只在离线批处理里跑，这个拆分的做法值得考虑。

我个人在实际操作中的体会是，这类统一模型最难的从来不是把代码跑通——照着结构写，一两天就能出个能训的版本。难的是判断"哪些损失在这个数据分布上是真有用、哪些是白烧算力"，以及"这套东西放在我的资源条件下到底划不划算"。前者靠消融实验一个一个试，后者靠先算清楚显存和时间账再动手。我现在的习惯是任何预训练任务开跑之前，先用一千条数据跑通全流程，把每一步的耗时和显存峰值打印出来，确认资源够用再上全量。这个前置动作花两小时，能省掉后面好几天的返工。