资讯动态

从VLMo到BLIP:混合模态专家在多模态预训练中的设计之道

发布时间:2026/10/17 17:51:40 来源:尧图企业网站定制
做过多模态预训练的同学应该都研究过BLIP这套方案统一三塔结构、图文匹配损失、CapFilt自举去噪思路非常清爽。但如果你把这套设计往前追一步会发现一个很有意思的事实——BLIP骨子里很多关于“模态共享与模态特制”的取舍源头其实在一篇更早的工作里就已经铺垫好了那篇工作就是VLMo。VLMo全称Vision-Language MoE核心卖点是“混合模态专家”——把MoEMixture of Experts混合专家这套机制搬进视觉语言预训练让视觉、文本、共享三路专家共存在同一个Transformer块里然后用门控网络按输入动态选专家。这个设计今天看依然挺有辨识度因为大多数多模态模型走的是“统一Transformer”或者“分塔再融合”的路线很少有模型在FFN前馈网络层面同时做模态区分和动态路由的。标题说它是BLIP的架构蓝本不夸张BLIP的三塔式共享设计、不同任务复用不同模块的思路都能从VLMo这里找到影子。这篇文章我打算沿着VLMo的架构设计逐层拆开讲讲清楚MoE专家到底怎么分配到两个模态上、门控网络如何选择专家、训练和推理时专家策略有什么不同再对照BLIP看它继承了哪些、改了哪些。适合正在做多模态预训练、或是想在Transformer里引入MoE机制找工程参考的同学。如果你只是好奇“BLIP为什么长这样”这篇也能帮你把源头理顺。1. VLMo是从哪条路线长出来的MoE与视觉语言预训练的第一次相遇先说个大背景。多模态模型百花齐放之前大家手里的牌其实很有限一边是有超强表现的单模态预训练模型视觉的、文本的另一边是算力瓶颈——从头训一个联合模型非常贵而且联合训练往往互相拖后腿图像任务和文本任务对特征的要求不一样硬塞进同一个Transformer里经常是顾此失彼。MoE当时在纯文本领域已经被验证是能“用更少计算换更多容量”的好东西把FFN复制成多份每个输入token由路由器选择其中一小部分专家来计算这样模型参数量巨大但实际推理只激活少量专家训练时flops开销可控。GShard、Switch Transformer这些工作已经把token级别的MoE玩得很熟了。VLMo的野心很简单能不能把MoE的“多专家”思路用来同时容纳“视觉需要的表征”和“文本需要的表征”让两个模态在同一个模型里既各自专业化又共享一部分通用能力这条路线的关键判断是视觉和文本在Transformer的底层确实差异巨大——视觉token的特征图带有明显的局部性、平移等变性文本token则需要很强的位置敏感与语法依赖但到了高层语义抽象层面两者又高度趋同都需要概念识别、跨模态对齐的能力。如果全部参数共享底层会互相干扰如果全部参数分离跨模态交互又很弱。MoE的“部分共享、部分特制、动态路由”恰好是中间态。于是VLMo给出的架构方案是一个分块TransformerBlock Mixture-of-Experts Transformer每个Transformer块里不只有一个FFN而是有三个专家模块——视觉专家、文本专家、共享专家。视觉token走视觉专家文本token走文本专家共享专家两者都能走。路由器router根据token内容和输入模态动态决定当前token到底交给哪个专家处理。这个设计思路和后来BLIP的三塔结构有个深层的相似点都是承认“模态有差异不能全共享模态有共性不能全分离”。只不过VLMo把这种关系落实在FFN层和动态路由上BLIP把它落实在独立的编码器塔和解码器塔上。理解了这层关系再回去看BLIP你会觉得它的很多选择都顺理成章。2. 混合模态专家到底在混合什么专家、门控与路由的关键机制要拆解VLMo绕不开MoE本身的三个核心机制专家是什么、门控怎么打分、路由怎么选。很多人看MoE容易望文生义觉得“混合专家”就是把好几个模型拼在一起投票——这个理解其实是错的。2.1 专家不是模型是FFN子网络在VLMo这个语境里一个“专家”不是什么独立的完整模型而只是一个FFN块就是Transformer里那个两层全连接加激活函数的模块。视觉专家负责处理视觉token的表征变换文本专家负责文本token共享专家则是两边通用。你把它理解成“几条不同的特征加工流水线”更准确Attention层负责token之间交换信息然后每个token被送去某条流水线做非线性变换。在标准Transformer里这条流水线只有一个在VLMo里它扩展成了三份每个token根据模态和内容选一份。实际的专家选择粒度不是序列级别而是token级别的吗这里有个容易混淆的点VLMo使用的是分块block-level路由而不是细粒度的token级路由。什么意思一个图像块patch对应一个视觉token它进入某个Transformer块后整体被路由到同一个专家文本token也类似。换句话说路由判定的是“这块数据是图像块还是文本块、以及它当前的表征状态更适合哪条流水线”不是像Switch Transformer那样每个token自由选不同的专家。2.2 门控网络怎么打分门控网络router本质上是一个线性映射加Softmax。每个token的输入表征x会先过一个小的线性层和归一化得到它在所有专家上的一个偏好分数然后取Softmax变成概率分布import torch import torch.nn.functional as F # x: token表征形状 (batch, seq_len, hidden) # router_weight: 线性层形状 (hidden, num_experts) def router_logits(x, router_weight): return torch.einsum(bsh,he-bse, x, router_weight) def router_probs(x, router_weight, temperature1.0): logits router_logits(x, router_weight) / temperature return F.softmax(logits, dim-1)温度参数不是摆设。推理时如果温度设得低路由结果更“自信”训练早期温度太高会导致专家选择过于随机、各专家学不到特定表征。实际复现中很多人直接固定温度1.0但如果你发现某个专家长期不激活可以试着把温度调低到0.8让门控更快收敛。2.3 top-1选择与负载均衡VLMo在训练和推理时通常会选择top-1专家也就是每个token只去一个专家计算。这就带来一个经典问题如果门控网络学偏了可能所有token都涌向共享专家视觉专家和文本专家变成摆设。视觉token如果总被路由到共享专家那视觉专家等于白训。解决办法是负载均衡损失auxiliary load balancing loss。这个loss会统计每个专家被选中的概率和频率如果某个专家过于热门就施加惩罚鼓励路由均匀一些。VLMo里还会做模态内的负载均衡——不仅要求总体均衡还要求视觉token内部、文本token内部各自也均衡避免视觉专家实际上被文本token抢走。实际训练时这个loss的系数需要仔细调。太大了会让路由失去差异性各专家变成同质化太小了又会出现专家坍缩。常见的做法是前几个epoch用一个稍大一点的系数把路由分布“稳住”后面再调小。这块没有绝对标准我自己的经验是从0.01起步观察每个专家的激活率如果激活率低于5%就要警惕了。3. 架构级拆解分块Transformer里藏着两个模态的“各干各的”与“一起干”理解了MoE的基本机制再看VLMo的整体架构就清晰多了。它的主体骨架仍是标准的Transformer堆叠但在每一层里做了几个关键改动。这一节我们把每一层从上到下过一遍讲清楚它是怎么让视觉和文本在同一个模型里协奏的。3.1 分块Transformer的块结构VLMo的每个Transformer块可以粗略分成两部分前面的注意力部分和后面的混合专家FFN部分。注意力部分是跨模态信息交换的主战场——视觉token和文本token在这里拼接成一个序列统一做多头自注意力这样图像块能attend到文本词元文本词元也能attend到图像块这是视觉语言模型里最核心的跨模态对齐通道。注意力输出后接下来就是MoE层。每个token的表征经过路由被送到视觉专家、文本专家或共享专家之一做FFN变换。这种“注意力共享、FFN分离”的格局很有意思信息交换是全模态统一的但特征加工是模态特化的。你可以类比成开跨国会议——大家在同一间会议室里听彼此发言共享注意力但每个人回到自己的工位后用各自的工具做笔记专家FFN。块结构在实现上还有一个细节需要注意LayerNorm的位置。VLMo在每个专家的输入处都有独立的LayerNorm门控打分也在进入专家之前做。训练时梯度会同时穿过路由器、专家FFN和注意力层所以整个模型是一体化训练的不需要分阶段冻结。3.2 三套专家各自扮演什么角色视觉专家和文本专家的职责边界看它在整个模型中所处的位置。在浅层视觉专家主要处理的是局部纹理、边缘、颜色等底层视觉特征文本专家则处理词法、句法、词序等语言底层特征。深度越往上两者的抽象程度越高也越来越接近共享的表征空间。共享专家承担的是跨模态的通用语义抽象——比如概念识别、因果关系、常识推理这类与模态无关的信息。实际跑下来有个直观感受共享专家的存在对低资源模态帮助特别大。如果某个下游任务只有很少的视觉标注数据但是文本预训练很充分那么视觉token经过路由被送到共享专家时相当于借用了一部分文本侧的语义抽象能力。这种“软参数共享”比硬共享所有层完全共用更灵活比硬分离视觉塔和文本塔完全隔离更能迁移知识。3.3 权重初始化与分阶段训练策略VLMo的训练不是从零开始的。视觉分支通常会利用公开的视觉预训练权重比如Swin系列的初始参数做初始化文本分支则会使用公开的预训练文本模型权重比如BERT系权重。这一步非常关键——从头训一个多模态模型收敛速度会慢到让你怀疑人生而从单模态权重起步通常只需要一半不到的预算就能达到还行的基础效果。训练策略上也继承了经典的“先单模态后多模态”的思路先在纯视觉或纯文本数据上让各模态专家各自适应再进入视觉语言的联合预训练。联合阶段主要有三个目标图文对比学习ITC拉近匹配图文对的距离、图文匹配学习ITM做二分类判断图文是否匹配、掩码语言建模MLM让模型根据图像和上下文还原被掩码的文本。这三个目标分别锻炼跨模态检索、判别和生成理解能力和BLIP里用的目标几乎一脉相承。4. 推理时专家怎么选从固定模态到“模态提示”动态切换MoE模型训练好之后推理阶段的专家选择策略直接决定下游任务的上限。VLMo最让人称道的一点是它的路由机制不只是“视觉token走视觉专家、文本token走文本专家”这种死规则而是允许通过“模态提示”来控制专家的倾向同一个模型可以在不同任务上灵活切换。4.1 两种专家选择的逻辑硬路由与软提示先说硬路由。硬路由的规则很简单视觉token优先送visual expert文本token优先送text expert路由网络只是在两者之间做补充修正。这样做的好处是稳定性高视觉和文本的专属能力被保留得比较好适合图文检索、图文匹配这类任务。软提示的做法更聪明。你可以在输入序列中插入一个特殊的提示token比如“image condition”或“text condition”这个提示token经过路由网络时的门控输出会影响后续token的专家选择倾向。比如做图像描述生成时文本侧希望更强调视觉信息就可以把提示token的“路由偏好”偏向共享专家和视觉专家让文本token在生成时更多地借鉴视觉侧的表征。这种设计在推理时完全不需要改动模型权重只是改变提示内容就能让同一个模型像几个不同模型一样工作。4.2 逐层路由不是所有层都需要模态分家还有一个值得注意的细节VLMo并不是在每一层都强制分专家的。底层和高层的路由策略会有差异。在底层专家的模态分化最强视觉token基本走视觉专家、文本token基本走文本专家越往高层路由结果越混合很多视觉token开始被分到共享专家甚至文本专家。这完全符合表征学习的直觉——底层特征强模态相关高层语义跨模态趋同。如果你在自己的实现里发现底层就开始大量混路由通常说明预训练数据不够或者负载均衡系数没调好。4.3 推理开销与管理谈到MoE很多人第一反应是“参数量太大了推理会不会爆炸”。这里要澄清VLMo的推理计算量并不等于总参数量而是等于激活的专家数乘以专家参数量。一个token只过一个专家计算量和普通Transformer的FFN几乎一样多出来的开销主要是门控打分和负载均衡的过程非常小。但内存占用会变大因为所有专家权重都在显存里待命。部署时如果显存吃紧可以考虑把不常用的专家比如某些下游任务根本用不到的视觉专家裁剪掉或者用按需换入的方式。我在实际项目里试过对于纯文本下游任务把视觉专家整个裁掉效果几乎没有下降显存却少了一截。5. 为什么敢说它是BLIP的蓝本对照BLIP看取舍与变形既然标题点到了BLIP这块必须单独展开。BLIP本身并没有用MoE它的网络结构是三塔式的一个单模态编码器Unimodal Encoder、一个图像条件文本编码器Image-grounded Text Encoder、一个图像条件文本解码器Image-grounded Text Decoder。很多人把BLIP理解成“ViT加BERT的简单堆叠”但如果你对比VLMo的架构哲学会发现BLIP是在VLMo的基础上做了一个非常聪明的工程化简。5.1 BLIP把“专家”变成了“塔”VLMo的专家是在Transformer块内部的FFN层做文章BLIP则把模态特化和共享问题上升到了模型结构层面。它的单模态编码器负责纯视觉表征提取这是“视觉专家”的放大版图像条件文本编码器负责把视觉信息融合进文本上下文对应“跨模态信息交换”的专门化图像条件文本解码器负责生成任务对应VLMo里通过文本专家和共享专家配合完成生成的路径。这相当于把VLMo里每一层都会出现的“专家选择”给预置成了固定的任务分支。好处是推理更稳定、下游适配更直接坏处是路由的灵活性没有了——BLIP做检索任务时没有VLMo那种“同样的模型换提示就能切换模式”的轻巧感。5.2 BLIP继承了什么BLIP继承得最明显的是“共享与特制并存”的哲学。它的三个塔共享视觉编码器的权重文本侧三个分支也在多个Transformer层共享参数只有进入各分支的最后几层才分化。这种做法本质上和VLMo“视觉共享、文本与视觉专家分开”是同一个思路底层尽量共享、顶层尽量特化只是把共享和特化的位置从FFN层挪到了网络塔结构上。预训练目标上BLIP保留了对ITC和ITM的继承并更强化了生成目标LM还把ITC的计算方式从多个专家动态路由的交互改成了显式的三塔对比。VLMo证明了这些目标在混合专家模型上是可以学的BLIP证明了它们在没有MoE的简化结构里也能学到而且工程上更友好。5.3 BLIP砍掉了什么为什么砍MoE最大的代价是训练和部署的复杂度。分块路由、负载均衡、专家分片、门控调参每一项都让人头大。BLIP选择砍掉MoE换来的是结构简单、易于扩展、可以无缝套用现成的预训练视觉编码器。换句话说VLMo是一个更“学术原型”的方案BLIP是一个更“产品工程”的方案。这在研究路线里很常见原型验证了设计哲学的有效性工程落地通常要在充分性和简洁性之间取平衡。BLIP还有一个明显的增量是CapFilt机制——利用生成模型自动给网络图片打伪标签再用过滤器去噪。这个和VLMo的路线差异就更大了VLMo还在解决“同一个模型怎么同时容纳多模态”BLIP已经在解决“训练数据太脏怎么办”。这其实是两条并行进化的路线BLIP能走得更远一部分原因是它的基础架构更简单可以腾出手来优化数据面。6. 想在自家任务里复刻这种设计值得注意的几件事看完前面的架构拆解你大概率会想我自己能不能在项目里借鉴这种混合专家设计答案是分情况。如果你的场景核心需求是“一个模型同时服务多个多模态任务”VLMo的思路很值得参考如果只是做单个下游任务我建议还是像BLIP那样老老实实走简化路线。下面把我在复刻和实验过程中摸出来的经验整理一下供你落地时避坑。6.1 专家粒度选择块级还是token级这是所有MoE多模态设计里最关键的决策。块级路由VLMo路线实现简单、路由稳定、模块语义清晰每个图像块或文本token整体指定一个专家族token级路由更灵活但是会让同一条序列内的不同token走不同的FFN计算图和工程实现都复杂很多。我的经验是如果你只是想要“模态特化”块级就够了如果你想建模“每个token内部的不同语义角色”这种更细粒度信息才需要考虑token级。而后者通常需要更大的数据和更长的训练时间才能稳定。6.2 路由网络的初始化门控网络是随机初始化的这会导致训练初期路由分布非常不稳定。我的做法是给路由器加上一个偏置项使得初始化时各专家被选择的概率大致接近而不是随机乱跳。具体实现也很简单在router输出的logits上加上一个可学习的bias初始值根据目标专家占比设置。比方说希望共享专家被选概率20%就把它对应的bias初始化成ln(0.2/(1-0.2))。这一步对稳定早期训练帮助很大。6.3 负载均衡loss的调参心得负载均衡loss的系数是最容易让人反复横跳的一个超参。我建议记录每500步的专家激活率画成曲线看趋势。出现下面两种情况就说明系数有问题一是某个专家激活率长期低于10%要加大系数或检查偏置二是各专家激活率过于均匀接近完全平均且下游指标下降要减小系数。实践中最稳的策略是3%到5%的预热期里把系数设为正常值的2到3倍让路由分布先形成基本格局然后降到常规值微调。6.4 融合外部单模态预训练权重时的兼容问题像BLIP那样复用公开的视觉预训练权重很香但直接套进VLMo结构时要注意权重尺寸匹配你的视觉专家FFN结构要和预训练权重的FFN结构一致否则无法加载。如果不一致有两个办法把预训练权重平均拆分到多个专家上适用于专家尺寸相同的情况或者先冻结共享专家、只训练视觉和文本专家几个epoch再解冻所有权重。第二种方案我在多个任务上试下来更稳。6.5 什么场景真的适合这个架构做一下总结模态差异大且都有足够单模态数据时最值得考虑VLMo路线比如视频-音频、图像-表格这类强异构组合。共享专家在低资源模态迁移上的收益非常明显这点在少样本图像分类上体现得很突出。但要注意如果两个模态本身同构性很强比如中文-英文双语文本直接用普通shared Transformer就够了加MoE只会徒增复杂度。另外如果你做的是推理速度敏感的产品建议慎用token级路由器因为它会破坏batch内的计算整齐度即使专家快路由选择和padding处理也会拖慢速度。块级路由不会破坏计算形状更容易写成高效的核函数。这也是VLMo能用相对较小的工程代价跑起来的关键。最后再分享一个我在实际部署里的小技巧如果某个下游任务基本只用共享专家和文本专家比如纯文本问答在导出模型时把视觉专家的权重直接清零而不是删除然后用很小的校准集做一次蒸馏把路由分布重新校准到只走共享和文本专家。这样既保住了模型容量又省了一部分推理显存。你甚至可以再进一步把门控网络剪掉改成固定规则路由效果几乎不掉但工程链路会简单一个量级。这个思路放到BLIP里就是直接复用它的固定三塔结构——所以你看说VLMo是BLIP的架构蓝本除了历史渊源操作逻辑上也是能串起来的。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑