尧图网页设计 
上次组会聊多模态大模型有个同学突然问我“为什么有的模型把图片和文字直接拼在一起送进Transformer有的却要走两套编码器”这个问题其实问到了多模态架构设计最核心的一道分叉口——单流模型和双流模型。不管你是准备复现多模态论文、给Agent接视觉能力还是自己在做图文检索、视觉问答都绕不开这两个概念。简单说单流模型把图像和文本当作“同一份序列”来处理双流模型则让它们先各走各的路、最后再融合。这两种路线各自长出了一大片技术家族CLIP是双流的代表作ViLT、Florence-2这类是单流的主力ALBEF、BLIP则属于两边都沾的混合流派。这篇文章我会从概念拆起把两个流派的设计逻辑、代表模型、训练细节、复现代码、部署选型全部过一遍。重点不是让你背结构图而是让你看完之后自己能判断手头的任务到底该用哪种架构以及真上手训练和部署时会在什么地方栽跟头。1. 先把概念对齐单流和双流到底在争什么1.1 单流模型的基本结构单流模型的做法很直接把图像切成一块块的patch经过embedding变成视觉token把文本按BPE或WordPiece切成词token然后两类token拼成一个序列一起送进同一个Transformer编码器。以ViLT为例输入序列大概是这样的[CLS] 这是一只坐在草地上的猫 [SEP] [IMG_PATCH_1] [IMG_PATCH_2] ... [IMG_PATCH_196]Transformer每一层的self-attention都会让文本token看到所有视觉token视觉token也能看到文本token。也就是说模态间的交互不是等到最后才做而是从第一层就开始。文本里“猫”这个词在第二层就能和图像里对应区域的patch做注意力交互这种细粒度的对齐能力是单流最大的本钱。代表模型包括VisualBERT、Uniter、Oscar、VinVL、ViLT以及后来偏生成式的Florence-2、Unified-IO。它们的设计哲学是我不需要专门设计一个融合模块Transformer自带的self-attention天然就是模态交互的场所。1.2 双流模型的基本结构双流模型的做法则是彻底分开图像走图像编码器文本走文本编码器前期完全互不干涉只在最后设计一个交互点。最典型的就是CLIP的双塔结构。图像塔通常是一个ViT或ResNet文本塔是一个Transformer编码器。图像经过编码器得到[CLS]向量文本经过编码器得到[EOS]向量然后把这两个向量做点积用对比学习拉近匹配图文对的距离、推开不匹配的图文对。训练完成后图像和文本各自落在一个共享语义空间里你可以把几十万张图片全部提前过一遍图像塔把向量存进数据库来了一个新文本query只需要过一遍文本塔得到向量然后去向量库做最近邻检索。这种“两边可以分头预计算”的特性让双流模型在检索场景里有巨大的工程优势。代表模型有CLIP、ALIGN、FILIP、SigLIP视频领域还有VideoCLIP这类双塔结构。1.3 为什么不能简单说谁更好很多人第一次接触这个知识点都会下意识问一句那到底哪个厉害说实话这俩没有绝对的优劣关键看你拿它干什么。单流模型交互发生在每一层对“文字和图像局部区域到底怎么对应”这种细粒度问题特别敏感所以视觉问答、图像描述、引用表达式理解这类任务上单流明显更强。但缺点是序列太长了图像patch数量动辄196个、256个甚至更多再拼上文本tokenself-attention的复杂度是平方级往上涨训练和推理都很吃显存。双流模型前期的隔离设计让计算效率高很多而且对比学习目标非常适合大规模弱监督数据——反正只需要判断整个图片和整句描述是否匹配不用做像素级对齐。但缺点是细粒度对齐能力弱你问模型“图片左上角那只狗是什么颜色”双流模型往往答不上来因为它压根没有让视觉token和文本token做过局部交互。所以更准确的说法是单流和双流不是好坏之分而是“交互深度和计算效率”这个天平上的两个极端绝大多数落地项目最终都落在中间某个位置。2. 设计思路拆解为什么同一个问题会长出两条技术路线2.1 单流的底层逻辑把对齐这件事完全交给注意力单流模型有个很硬气的假设只要信息都在同一个序列里Transformer就能自己学会模态对齐。这句话听着简单背后是有道理的。self-attention的每一个头都可以看作一个“软对齐”机制头A可能专门负责文本词和图像物体区域的对应头B可能负责跨模态的共指消解头C可能负责全局语境整合。你不需要像传统方法那样手工设计对齐模块也不用提前检测出图像里的物体再和文本里的词做匹配一切都在端到端训练里自动涌现。我在实际跑ViLT的时候观察过一个有趣现象训练好的模型某些attention头确实会对齐到“猫”这个词和图像里猫的轮廓区域。这种对齐不是有人教它的而是模型为了完成掩码语言建模和图文匹配这两个任务自己摸索出来的捷径。单流的代价也很明显。第一是序列长度的平方级复杂度图像Token和文本Token拼在一起之后序列长度轻松超过两百训练效率被拖累。第二是模态干扰问题有些任务里文本本身的语法信息就足够做预测了视觉信号反而成了噪声模型会学成“忽略图像只靠文本蒙答案”。2.2 双流的底层逻辑先压缩再对比双流模型的出发点完全不一样。它的核心思路是图像和文本各自被压缩成一个向量然后用这个向量是否匹配来做训练信号。这里面的关键在对比学习。假设一个batch里有N个图文对每张图和它对应的文本是正样本和batch里其他N-1个文本都是负样本。模型要学的就是让正样本对的相似度远高于负样本对。目标函数是InfoNCE公式大概长这样L -log( exp(sim(i,t)/tau) / sum_j exp(sim(i,t_j)/tau) )其中sim是余弦相似度tau是温度系数。分母上要遍历batch里所有负样本所以双流对比学习的质量和batch size高度相关——batch越大负样本越丰富学到的语义空间越均匀。CLIP原论文用了几万的大batch普通人根本复现不了后面很多工作都在想办法用更小的batch获得更好的效果。双流的另一个天然优势是可索引性。因为图像和文本经过各自编码器后得到的是独立向量图像库可以被预先编码成向量库线上推理只需要编码query文本然后做近邻检索。这正好是搜索引擎和推荐系统最喜欢的模式。换句话说双流模型把多模态问题转化成了向量检索问题工程上非常好落地。2.3 混合流派人类最终走向了“双流编码、交叉融合”如果你只盯住单流和双流的争论会漏掉一个更重要的趋势真实世界中最能打的模型几乎都是混合架构。以ALBEF为例它有两个单模态编码器图像和文本各自过一遍得到特征然后还有一个多模态融合编码器把图像特征和文本特征一起喂进去做交叉注意力融合。训练时同时用对比损失拉近图文表征和掩码语言建模损失做细粒度理解。这种设计既享受双流编码器的高效预训练又能拿到单流级别的交互能力。BLIP更进了一步在融合编码器上同时又加了生成损失。Flamingo、LLaVA这些多模态大模型表面上看是“把图像特征送进LLM”实际也属于混合思路——视觉编码器把图像压成token序列然后通过projector或cross-attention把视觉信息注入到语言模型里。你会发现面对复杂任务大家还是选择用融合模块来保证交互深度但又不放弃双流带来的计算效率和预训练便利。这就是我给所有刚入门同学的第一条忠告别被“单流vs双流”这个二元对立框住真实的技术演进方向是混合。3. 核心细节拆解几个代表模型是怎么把思想落地的3.1 ViLT把视觉也变成“词”的最简实现ViLT是我建议所有新手复现的第一个单流模型因为它的结构足够简洁。之前的单流模型比如VisualBERT、Uniter视觉特征都要靠一个预训练好的目标检测模型Faster R-CNN来提取每一张图要先检测出几十个物体框再对每个框做特征提取。这个流程又慢又重。ViLT做了一个关键创新直接用线性投影把图像patch映射成embedding跟文本token一样进入Transformer。图像被切成固定大小的patch比如32x32一张224x224的图片被切成7x749个patch再过卷积或线性层变成向量。整个视觉分支只有一个patch embedding层没有CNN backbone没有目标检测器结构极其干净。ViLT-B/32在4张2080Ti上就能训起来用ImageNet做MAE预训练或者直接在COCO等数据集上做下游微调门槛很低。我当时复现的时候整个模型代码加数据管道写了不到三百行就能跑通。从这个项目入手理解单流效率远高于啃VisualBERT这种带检测器的古董结构。如果你打算自己写ViLT有几个细节别搞错位置编码要区分模态视觉token和文本token可以共享一个位置编码表也可以用不同的表ViLT选择在embedding后面直接拼接一个可学习的模态类型向量。损失用ITM图文匹配MLM掩码语言建模ITM的数据要构建难负样本不能只拿随机不匹配的图文对否则模型很快就学废了。推理时如果只做图文匹配直接取[CLS]位置的输出过一个二分类头就行。3.2 CLIP双塔对比学习的教科书CLIP的成功某种程度上是“大力出奇迹”的典范。4亿图文对每个batch一万多靠对比学习硬生生拉出了一个通用的图文语义空间。它的结构简单到不需要过多解释一个图像编码器ViT-L/14一个文本编码器Transformer各自输出一个归一化向量做点积算相似度。有两个细节非常关键值得展开说。第一个是温度系数。CLIP里的温度参数不是固定值而是一个可学习的logit scale初始值大约0.07。为什么要可学习因为温度决定了相似度分布的锐利程度温度越低logits分布越尖锐模型对正负样本的区分越严格温度越高分布越平缓梯度信号越弱。固定温度在很多数据集上不是最优的放开让它自己学模型会自动找到当前数据下的最好尺度。第二个是batch size。我在自己机器上试过把batch从256降到64CLIP的zero-shot效果肉眼可见地变差。原因是对比学习的负样本全都来自batch内部batch小了负样本数量就不够模型很容易学到一些偷懒的短路特征。如果显存不够常见的补救手段是加大梯度累积步数或者用MoCo那种动量队列来保存历史特征当负样本。CLIP的局限我也想多说一句它的图像塔只输出一个全局向量没有保留局部patch级别的特征所以做VQA、引用分割这类需要细粒度理解的场景会力不从心。Layer-wise的冻结训练也让CLIP在不少下游任务上的迁移表现需要额外微调。3.3 ALBEF与BLIP晚期融合的标准答案如果你在工业界做多模态项目大概率会接触到ALBEF和BLIP这条技术线。这两个模型奠定了“双流编码器融合编码器”的混合范式后面很多工作包括部分多模态大模型都沿用了这套结构。ALBEF的完整链路是图像过一个ViT得到patch特征序列文本过一个Bert得到token特征序列把两组特征拼起来或通过交叉注意力方式送入融合编码器。训练时用了三项损失ITC对比损失拉近图文全局表征。MLM掩码语言建模损失让模型学会用视觉上下文预测被掩码的词。ITM图文匹配损失二分类判断图文对是否匹配配合难负样本挖掘。ALBEF还引入了动量蒸馏也就是用模型的指数移动平均版本生成伪标签帮助缓解图文对噪声问题。很多公开数据集里的图文对质量其实不高caption和图像经常弱相关动量蒸馏能有效平滑这些噪声。BLIP进一步迭代把融合编码器升级成了统一的多模态混合编码器-解码器结构并且用CapFilt方法用模型自己生成干净caption来扩充训练数据。如果你在做图文生成、数据清洗相关的工作BLIP这套做法非常值得借鉴。实操层面ALBEF的代码结构其实比ViLT复杂不少主要复杂在动量蒸馏和三个损失头的配合上。新手想复现的话我建议先把ITC和ITM训练通再加MLM最后加动量蒸馏一步一步来不要一上来就全量怼。3.4 多模态大模型时代的架构变体现在最热的多模态大模型LLaVA、Qwen-VL、InternVL它们到底算单流还是双流这个问题没有标准答案但你可以用前面两节的框架来分析。LLaVA走的是“视觉tokenizer LLM”的路线视觉编码器把图像变成token序列过一个可学习的projector最常见是MLP映射到语言模型的embedding空间然后和文本token拼接在一起送给LLM。从模态交互方式来看这很像单流——视觉token和文本token确实在同一个Transformer序列里。但从编码器参数来看视觉编码器是单独预训练好的并不参与文本建模这又有点像双流。Qwen-VL、InternVL这些更复杂一点有的在LLM前面加了专门的视觉-语言适配器有的会在LLM层内部插入交叉注意力模块比如Flamingo。Flamingo的做法是在冻结的LLM层之间插入GATED CROSS-ATTENTION层让语言模型每几层就能“看一眼”视觉特征这本质上又回到了交叉融合的混合范式。所以我个人更愿意把多模态大模型看作是以双流预训练为基础、以单流式token拼接或交叉注意力为交互手段的综合体。理解单流和双流是拆解这些复杂大模型的底层能力。4. 实操上手从零搭一个最简版多模态模型4.1 环境准备和数据集选型动手跑代码之前先把环境和数据准备好。这一节我基于PyTorch和HuggingFace生态代码量不大核心思想是“先跑通、再调优”。环境建议Python 3.9PyTorch 2.0CUDA 11.8及以上transformers、datasets、accelerate这几个库尽量升级到最新如果你要训练视觉模型建议再装timm库加载ViT更方便数据集方面新手追求的是“迭代速度快”所以不要一开始就上CC3M这种百万级数据集。我建议先用Flickr30K或COCO的Karpathy split做训练几万张图足够验证你的模型能不能收敛。等模型结构确定没问题了再考虑CC3M、SBU Captions这些更大规模的数据集。数据预处理的几个坑图片resize到固定尺寸224x224别用随机尺寸。文本统一用小写过滤掉过长的caption。如果数据里有明显的噪声对比如图片是纯色背景但caption是一段完整的文章这种对模型训练没有帮助最好在预处理阶段过滤掉。4.2 最简双流模型代码实现先写双流因为结构更直观。import torch import torch.nn as nn import torch.nn.functional as F from transformers import AutoModel, AutoTokenizer from timm import create_model class DualEncoder(nn.Module): def __init__(self, vis_backbonevit_base_patch32_224, text_backbonebert-base-uncased, embed_dim256): super().__init__() self.vis_encoder create_model(vis_backbone, pretrainedTrue, num_classesembed_dim) self.text_encoder AutoModel.from_pretrained(text_backbone) self.text_proj nn.Linear(self.text_encoder.config.hidden_size, embed_dim) self.vis_proj nn.Linear(embed_dim, embed_dim) self.logit_scale nn.Parameter(torch.ones([]) * 2.6592) # 对应exp(2.6592)≈14.28约等于CLIP初始温度反比 def forward(self, images, input_ids, attention_mask): vis_feat self.vis_encoder(images) # [B, embed_dim] vis_feat self.vis_proj(vis_feat) vis_feat F.normalize(vis_feat, dim-1) text_feat self.text_encoder(input_idsinput_ids, attention_maskattention_mask).pooler_output text_feat self.text_proj(text_feat) text_feat F.normalize(text_feat, dim-1) return vis_feat, text_feat def compute_contrastive_loss(self, images, input_ids, attention_mask): vis_feat, text_feat self.forward(images, input_ids, attention_mask) logit_scale self.logit_scale.exp() logits logit_scale * vis_feat text_feat.t() # [B, B] labels torch.arange(vis_feat.size(0)).to(images.device) loss_i F.cross_entropy(logits, labels) loss_t F.cross_entropy(logits.t(), labels) return (loss_i loss_t) / 2几个写代码时容易踩的点视觉特征是图像塔的最终输出我直接用num_classesembed_dim让timm帮我把分类头换成指定维度这样省事但不够灵活。如果你想用ViT的[CLS] token就需要手动改forward逻辑取self.vis_encoder.forward_features(images)[:, 0]再过自己的投影头。logit_scale初始值建议按照CLIP论文来即log(1/0.07)≈2.659训练时让它自己学不要固定。对比损失的标签就是对角线上的indices因为正样本对永远是vis_feat[i]对应text_feat[i]。这个最简版本没有加hard negative训练效果会差一些但用来理解整个对比学习流程已经够了。4.3 最简单流模型代码实现单流模型稍微复杂一点关键是把视觉patch embedding和文本embedding拼成同一个序列。import torch import torch.nn as nn from torchvision import transforms from transformers import AutoTokenizer, BertConfig, BertModel import timm class SingleStreamModel(nn.Module): def __init__(self, vis_encoder_namevit_base_patch32_224, text_backbonebert-base-uncased): super().__init__() text_config BertConfig.from_pretrained(text_backbone) self.text_encoder BertModel(text_config, add_pooling_layerFalse) self.tokenizer AutoTokenizer.from_pretrained(text_backbone) # 用timm的ViT作为patch embedding去掉分类头 self.vit timm.create_model(vis_encoder_name, pretrainedTrue, num_classes0) vit_hidden self.vit.embed_dim # 通常是768 self.text_proj nn.Linear(text_config.hidden_size, 768) self.vit_proj nn.Linear(vit_hidden, 768) self.dropout nn.Dropout(0.1) # 可学习的模态类型向量 self.modality_type nn.Embedding(2, 768) self.itm_head nn.Linear(768, 2) def forward(self, images, input_ids, attention_mask, token_type_idsNone): # 1. 文本编码 text_out self.text_encoder(input_idsinput_ids, attention_maskattention_mask).last_hidden_state text_feat self.text_proj(text_out) # [B, T, 768] # 2. 图像patch编码 vis_feat self.vit.forward_features(images) # [B, num_patches1, vit_hidden] vis_feat self.vit_proj(vis_feat) # [B, P1, 768] # 3. 拼接成单序列 # 注意vit的forward_features第一个token是cls我们保留它 # 为简化去掉视觉cls只保留patch token避免和文本cls混淆 vis_feat vis_feat[:, 1:, :] # [B, P, 768] # 给序列加模态类型向量 text_modal self.modality_type(torch.zeros(text_feat.size()[:2], dtypetorch.long, deviceimages.device)) vis_modal self.modality_type(torch.ones(vis_feat.size()[:2], dtypetorch.long, deviceimages.device)) text_feat text_feat text_modal vis_feat vis_feat vis_modal # 拼一个CLS token batch_size images.size(0) cls_token self.dropout(torch.zeros(batch_size, 1, 768, deviceimages.device)) # 也可以用learnable cls embedding这里先占位 concat_feat torch.cat([cls_token, text_feat, vis_feat], dim1) # [B, 1TP, 768] # 4. 过Bert模型用BertModel的encoder部分 extended_attention_mask torch.ones(concat_feat.size()[:2], deviceimages.device) out self.text_encoder.encoder( concat_feat, attention_maskextended_attention_mask, output_hidden_statesFalse ).last_hidden_state itm_logits self.itm_head(out[:, 0]) # CLS位置输出用于ITM return itm_logits这段代码有一个偷懒的地方我直接用了BertModel的encoder部分来跑拼接后的序列所以文本模型和单流Transformer共享了一部分参数不算完全标准的单流实现。真正标准的单流模型比如ViLT会建一个新的Transformer来接收拼接序列文本编码器和视觉编码器在融合阶段统一处理。如果从零实现完整的ViLT你需要一个独立的patch embedding层把224x224x3的图像变成196个patch向量。一个独立的文本embedding层。一个统一的Transformer encoder接收上面两类向量拼接后的序列。上面我为了减少代码量复用了Bert的encoder和embedding但理解概念时不要把这种“复用”当真它只是demo。实际训练的时候单流模型更吃显存。我建议你从小batch开始比如16先确认前向反向都不报错再逐步加大。4.4 训练脚本中最容易出错的地方跑这两个模型的过程中我总结了一些特别容易让人崩溃的问题位置编码的序列长度对不上。ViT输出的patch数量是固定的但文本token数量不固定拼接后的序列长度会随文本长度变化。要么把所有文本pad到同一长度要么用attention mask屏蔽掉pad部分否则位置编码和注意力计算都会出错。两个encoder的learning rate可以分开设。视觉backbone如果是从预训练加载的建议用一个较小lr如1e-5新加的head用大一点的lr如3e-4。混合精度训练时注意loss是否能正常回传。图像增强策略对比学习里图像增强方式会显著影响效果。随机裁剪、水平翻转、颜色抖动是标配。我当时偷懒只用resize和归一化结果Flickr30K上的retrieval recall1直接从60掉到了45加回增强之后才恢复正常。5. 训练和部署中踩过的坑5.1 损失函数配比多任务模型容易“偏科”单流模型和混合模型通常会同时用多个损失最典型的是ALBEF的三件套ITC、ITM、MLM。损失配比如果不当模型会走偏。我自己的实验记录当ITC权重压到0.2以下时模型学会了用MLM“背答案”图像基本不看当ITM权重太小时模型又不太会判别图文是否匹配retrieval指标掉得很厉害。ALBEF论文里大概的比例是ITC:ITM:MLM 1:1:1但我实测下来把ITM权重提到1.5在某些数据集上效果更好特别是图文匹配负样本比较难的数据集。如果你用的是HuggingFace的Trainer建议把每个loss单独记录到log里每几百步看一眼避免出现某个loss异常增大覆盖掉其他loss的现象。5.2 对比学习的负样本困境CLIP式的对比学习非常依赖负样本的质量和数量。有几次我们为了省显存batch size调到64以下结果模型训练了几天retrieval指标始终不涨后来才发现是负样本太少。解决方案有两种梯度累积把一个大的逻辑batch拆成多个小batch累积梯度后再更新。注意对比学习的logits是在当前batch内算的梯度累积仍然在同一个逻辑batch内计算不会出问题。基于队列的负样本方法类似MoCo。维护一个存储历史特征向量的队列每次训练从队列里取负样本计算损失。这个方案能用很小的显存获得大量负样本缺点是队列里的特征可能是旧模型参数算出来的存在“陈旧”问题需要用动量更新缓解。5.3 图文弱相关的数据和清洗策略公开的图文数据集尤其CC3M这类自动采集的很多图文对根本不是“严格匹配”的。一句caption可能只描述了图片里很小的一部分或者图片里有多个人物/物体caption只提到其中一个。这种弱相关数据会给对比学习带来巨大噪声。我常用的几招用CLIP给每个图文对打个相似度分低于0.25的直接丢弃或降权。用BLIP这类模型给caption做改写生成更贴近图片内容的文本。把过长的caption截断很多时候后面半句话在胡说。同一张图片配多个captions时要控制同一个batch里不要出现太多近似重复的文本否则模型会把这些相似文本误当成正样本来拉近。数据清洗花的时间永远是值得的我见过太多项目模型结构没问题、数据稀烂导致指标上不去的案例。5.4 推理部署单流和双流的工程差异部署阶段两者的差别比训练阶段还明显。双流模型非常适合做召回/粗排图像库是静态的可以离线把图像全部过一遍图像塔把向量存到faiss或milvus里线上来一个文本query过一遍文本塔然后向量检索Top-K。整个链路延迟可以控制在几十毫秒以内吞吐量也很高。单流模型做不了这种“预计算”因为你必须实时把文本token和图像token拼在一起过一遍完整的Transformer才能得到相似度。但它的优势在于可以做生成式任务比如图像描述、视觉对话。这时候你输出的是整个token序列而不是一个向量。工业界常见的选择是混合部署用双流模型从几百万图库里召回几百张候选图再用单流模型在这几百张上精排。我参与的一个电商视频检索项目就是这么干的粗排用CLIP向量召回精排用一个轻量级单流模型做细粒度匹配整体效果比单纯用CLIP直接从全库检索高了十几个点的准确率。6. 项目选型手头任务到底该用哪种架构6.1 场景自查清单我根据实际项目经验把常见任务分成了几类直接对号入座即可任务类型推荐架构理由文本搜图、图搜文本、向量召回双流CLIP/SigLIP可预计算向量、延迟低、适合海量索引图像打标、图文相似度判断双流或轻量混合只需全局匹配不需要逐token交互视觉问答、引用表达式理解单流或带融合编码器的混合需要细粒度局部对齐图像描述生成、视觉对话多模态大模型混合范式生成式任务天然需要单流式条件建模细粒度检索如“红色上衣的女生”双流召回单流精排兼顾效率和精度视频-文本检索双流视频双塔视频帧多双流可预抽取特征6.2 成本和效果怎么权衡选型的时候我给你几组经验值参考数据量小于10万对双流模型比较容易训起来单流要小心过拟合建议加预训练权重和强正则。数据量百万级两条路线都能出效果但双流的训练成本明显更低因为不需要做逐token的交互计算。显存资源有限单卡24G以下优先考虑双流或轻量混合模型尽量别碰大尺度单流。需要低延迟线上推理P99小于100ms双流几乎是唯一选择单流在图片数量大时根本扛不住。这些经验值不是绝对真理但作为初始参考很够用。我做项目的时候通常会先跑一个CLIP双塔baseline把召回指标摸清楚如果baseline已经能满足业务需求就不折腾单流精排了。6.3 几条实战建议最后说几个我在实际项目中反复验证过的经验第一双流baseline永远是最值得先跑的东西。CLIP架构简单、训练稳定、指标天花板高哪怕你最终方案是单流先把双流结果跑出来也能给你一个“最小可接受效果”的参照。很多团队一上来就追多模态大模型结果项目周期拉长了好几倍不如先用双流把pipeline跑通。第二单流模型微调时尽量用更小的学习率和更多的warmup步骤。因为单流要同时微调视觉和文本的交互部分学习率稍大训练loss就会疯涨。我一般把峰值学习率设在2e-5到5e-5之间并配合线性warmupcosine decay。第三如果你要复现论文千万别只看模型代码损失函数和训练策略往往比模型结构更关键。比如ALBEF的动量蒸馏、BLIP的CapFilt这些“辅助模块”对最终效果的贡献可能占一半以上。只抄主干结构、不抄训练策略的复现十有八九达不到论文指标。第四数据质量永远优先于模型结构。给模型换一个更复杂的融合模块效果提升可能只有1-2个点把弱相关的脏数据清掉、补一批高质量图文对指标直接上浮5个点以上。做多模态项目多花时间在数据上是绝对不会亏的。第五多模态大模型不是万能的。它确实在生成类任务上碾压传统单流/双流但在纯检索场景一个训练得当的CLIP双塔往往更快、更省、更可控。选型的时候先问自己任务需要生成还是需要召回需要细粒度对齐还是全局匹配把这两个问题想清楚架构选择基本就定了。 单流与双流多模态模型：架构对比与工程选型指南
上次组会聊多模态大模型有个同学突然问我“为什么有的模型把图片和文字直接拼在一起送进Transformer有的却要走两套编码器”这个问题其实问到了多模态架构设计最核心的一道分叉口——单流模型和双流模型。不管你是准备复现多模态论文、给Agent接视觉能力还是自己在做图文检索、视觉问答都绕不开这两个概念。简单说单流模型把图像和文本当作“同一份序列”来处理双流模型则让它们先各走各的路、最后再融合。这两种路线各自长出了一大片技术家族CLIP是双流的代表作ViLT、Florence-2这类是单流的主力ALBEF、BLIP则属于两边都沾的混合流派。这篇文章我会从概念拆起把两个流派的设计逻辑、代表模型、训练细节、复现代码、部署选型全部过一遍。重点不是让你背结构图而是让你看完之后自己能判断手头的任务到底该用哪种架构以及真上手训练和部署时会在什么地方栽跟头。1. 先把概念对齐单流和双流到底在争什么1.1 单流模型的基本结构单流模型的做法很直接把图像切成一块块的patch经过embedding变成视觉token把文本按BPE或WordPiece切成词token然后两类token拼成一个序列一起送进同一个Transformer编码器。以ViLT为例输入序列大概是这样的[CLS] 这是一只坐在草地上的猫 [SEP] [IMG_PATCH_1] [IMG_PATCH_2] ... [IMG_PATCH_196]Transformer每一层的self-attention都会让文本token看到所有视觉token视觉token也能看到文本token。也就是说模态间的交互不是等到最后才做而是从第一层就开始。文本里“猫”这个词在第二层就能和图像里对应区域的patch做注意力交互这种细粒度的对齐能力是单流最大的本钱。代表模型包括VisualBERT、Uniter、Oscar、VinVL、ViLT以及后来偏生成式的Florence-2、Unified-IO。它们的设计哲学是我不需要专门设计一个融合模块Transformer自带的self-attention天然就是模态交互的场所。1.2 双流模型的基本结构双流模型的做法则是彻底分开图像走图像编码器文本走文本编码器前期完全互不干涉只在最后设计一个交互点。最典型的就是CLIP的双塔结构。图像塔通常是一个ViT或ResNet文本塔是一个Transformer编码器。图像经过编码器得到[CLS]向量文本经过编码器得到[EOS]向量然后把这两个向量做点积用对比学习拉近匹配图文对的距离、推开不匹配的图文对。训练完成后图像和文本各自落在一个共享语义空间里你可以把几十万张图片全部提前过一遍图像塔把向量存进数据库来了一个新文本query只需要过一遍文本塔得到向量然后去向量库做最近邻检索。这种“两边可以分头预计算”的特性让双流模型在检索场景里有巨大的工程优势。代表模型有CLIP、ALIGN、FILIP、SigLIP视频领域还有VideoCLIP这类双塔结构。1.3 为什么不能简单说谁更好很多人第一次接触这个知识点都会下意识问一句那到底哪个厉害说实话这俩没有绝对的优劣关键看你拿它干什么。单流模型交互发生在每一层对“文字和图像局部区域到底怎么对应”这种细粒度问题特别敏感所以视觉问答、图像描述、引用表达式理解这类任务上单流明显更强。但缺点是序列太长了图像patch数量动辄196个、256个甚至更多再拼上文本tokenself-attention的复杂度是平方级往上涨训练和推理都很吃显存。双流模型前期的隔离设计让计算效率高很多而且对比学习目标非常适合大规模弱监督数据——反正只需要判断整个图片和整句描述是否匹配不用做像素级对齐。但缺点是细粒度对齐能力弱你问模型“图片左上角那只狗是什么颜色”双流模型往往答不上来因为它压根没有让视觉token和文本token做过局部交互。所以更准确的说法是单流和双流不是好坏之分而是“交互深度和计算效率”这个天平上的两个极端绝大多数落地项目最终都落在中间某个位置。2. 设计思路拆解为什么同一个问题会长出两条技术路线2.1 单流的底层逻辑把对齐这件事完全交给注意力单流模型有个很硬气的假设只要信息都在同一个序列里Transformer就能自己学会模态对齐。这句话听着简单背后是有道理的。self-attention的每一个头都可以看作一个“软对齐”机制头A可能专门负责文本词和图像物体区域的对应头B可能负责跨模态的共指消解头C可能负责全局语境整合。你不需要像传统方法那样手工设计对齐模块也不用提前检测出图像里的物体再和文本里的词做匹配一切都在端到端训练里自动涌现。我在实际跑ViLT的时候观察过一个有趣现象训练好的模型某些attention头确实会对齐到“猫”这个词和图像里猫的轮廓区域。这种对齐不是有人教它的而是模型为了完成掩码语言建模和图文匹配这两个任务自己摸索出来的捷径。单流的代价也很明显。第一是序列长度的平方级复杂度图像Token和文本Token拼在一起之后序列长度轻松超过两百训练效率被拖累。第二是模态干扰问题有些任务里文本本身的语法信息就足够做预测了视觉信号反而成了噪声模型会学成“忽略图像只靠文本蒙答案”。2.2 双流的底层逻辑先压缩再对比双流模型的出发点完全不一样。它的核心思路是图像和文本各自被压缩成一个向量然后用这个向量是否匹配来做训练信号。这里面的关键在对比学习。假设一个batch里有N个图文对每张图和它对应的文本是正样本和batch里其他N-1个文本都是负样本。模型要学的就是让正样本对的相似度远高于负样本对。目标函数是InfoNCE公式大概长这样L -log( exp(sim(i,t)/tau) / sum_j exp(sim(i,t_j)/tau) )其中sim是余弦相似度tau是温度系数。分母上要遍历batch里所有负样本所以双流对比学习的质量和batch size高度相关——batch越大负样本越丰富学到的语义空间越均匀。CLIP原论文用了几万的大batch普通人根本复现不了后面很多工作都在想办法用更小的batch获得更好的效果。双流的另一个天然优势是可索引性。因为图像和文本经过各自编码器后得到的是独立向量图像库可以被预先编码成向量库线上推理只需要编码query文本然后做近邻检索。这正好是搜索引擎和推荐系统最喜欢的模式。换句话说双流模型把多模态问题转化成了向量检索问题工程上非常好落地。2.3 混合流派人类最终走向了“双流编码、交叉融合”如果你只盯住单流和双流的争论会漏掉一个更重要的趋势真实世界中最能打的模型几乎都是混合架构。以ALBEF为例它有两个单模态编码器图像和文本各自过一遍得到特征然后还有一个多模态融合编码器把图像特征和文本特征一起喂进去做交叉注意力融合。训练时同时用对比损失拉近图文表征和掩码语言建模损失做细粒度理解。这种设计既享受双流编码器的高效预训练又能拿到单流级别的交互能力。BLIP更进了一步在融合编码器上同时又加了生成损失。Flamingo、LLaVA这些多模态大模型表面上看是“把图像特征送进LLM”实际也属于混合思路——视觉编码器把图像压成token序列然后通过projector或cross-attention把视觉信息注入到语言模型里。你会发现面对复杂任务大家还是选择用融合模块来保证交互深度但又不放弃双流带来的计算效率和预训练便利。这就是我给所有刚入门同学的第一条忠告别被“单流vs双流”这个二元对立框住真实的技术演进方向是混合。3. 核心细节拆解几个代表模型是怎么把思想落地的3.1 ViLT把视觉也变成“词”的最简实现ViLT是我建议所有新手复现的第一个单流模型因为它的结构足够简洁。之前的单流模型比如VisualBERT、Uniter视觉特征都要靠一个预训练好的目标检测模型Faster R-CNN来提取每一张图要先检测出几十个物体框再对每个框做特征提取。这个流程又慢又重。ViLT做了一个关键创新直接用线性投影把图像patch映射成embedding跟文本token一样进入Transformer。图像被切成固定大小的patch比如32x32一张224x224的图片被切成7x749个patch再过卷积或线性层变成向量。整个视觉分支只有一个patch embedding层没有CNN backbone没有目标检测器结构极其干净。ViLT-B/32在4张2080Ti上就能训起来用ImageNet做MAE预训练或者直接在COCO等数据集上做下游微调门槛很低。我当时复现的时候整个模型代码加数据管道写了不到三百行就能跑通。从这个项目入手理解单流效率远高于啃VisualBERT这种带检测器的古董结构。如果你打算自己写ViLT有几个细节别搞错位置编码要区分模态视觉token和文本token可以共享一个位置编码表也可以用不同的表ViLT选择在embedding后面直接拼接一个可学习的模态类型向量。损失用ITM图文匹配MLM掩码语言建模ITM的数据要构建难负样本不能只拿随机不匹配的图文对否则模型很快就学废了。推理时如果只做图文匹配直接取[CLS]位置的输出过一个二分类头就行。3.2 CLIP双塔对比学习的教科书CLIP的成功某种程度上是“大力出奇迹”的典范。4亿图文对每个batch一万多靠对比学习硬生生拉出了一个通用的图文语义空间。它的结构简单到不需要过多解释一个图像编码器ViT-L/14一个文本编码器Transformer各自输出一个归一化向量做点积算相似度。有两个细节非常关键值得展开说。第一个是温度系数。CLIP里的温度参数不是固定值而是一个可学习的logit scale初始值大约0.07。为什么要可学习因为温度决定了相似度分布的锐利程度温度越低logits分布越尖锐模型对正负样本的区分越严格温度越高分布越平缓梯度信号越弱。固定温度在很多数据集上不是最优的放开让它自己学模型会自动找到当前数据下的最好尺度。第二个是batch size。我在自己机器上试过把batch从256降到64CLIP的zero-shot效果肉眼可见地变差。原因是对比学习的负样本全都来自batch内部batch小了负样本数量就不够模型很容易学到一些偷懒的短路特征。如果显存不够常见的补救手段是加大梯度累积步数或者用MoCo那种动量队列来保存历史特征当负样本。CLIP的局限我也想多说一句它的图像塔只输出一个全局向量没有保留局部patch级别的特征所以做VQA、引用分割这类需要细粒度理解的场景会力不从心。Layer-wise的冻结训练也让CLIP在不少下游任务上的迁移表现需要额外微调。3.3 ALBEF与BLIP晚期融合的标准答案如果你在工业界做多模态项目大概率会接触到ALBEF和BLIP这条技术线。这两个模型奠定了“双流编码器融合编码器”的混合范式后面很多工作包括部分多模态大模型都沿用了这套结构。ALBEF的完整链路是图像过一个ViT得到patch特征序列文本过一个Bert得到token特征序列把两组特征拼起来或通过交叉注意力方式送入融合编码器。训练时用了三项损失ITC对比损失拉近图文全局表征。MLM掩码语言建模损失让模型学会用视觉上下文预测被掩码的词。ITM图文匹配损失二分类判断图文对是否匹配配合难负样本挖掘。ALBEF还引入了动量蒸馏也就是用模型的指数移动平均版本生成伪标签帮助缓解图文对噪声问题。很多公开数据集里的图文对质量其实不高caption和图像经常弱相关动量蒸馏能有效平滑这些噪声。BLIP进一步迭代把融合编码器升级成了统一的多模态混合编码器-解码器结构并且用CapFilt方法用模型自己生成干净caption来扩充训练数据。如果你在做图文生成、数据清洗相关的工作BLIP这套做法非常值得借鉴。实操层面ALBEF的代码结构其实比ViLT复杂不少主要复杂在动量蒸馏和三个损失头的配合上。新手想复现的话我建议先把ITC和ITM训练通再加MLM最后加动量蒸馏一步一步来不要一上来就全量怼。3.4 多模态大模型时代的架构变体现在最热的多模态大模型LLaVA、Qwen-VL、InternVL它们到底算单流还是双流这个问题没有标准答案但你可以用前面两节的框架来分析。LLaVA走的是“视觉tokenizer LLM”的路线视觉编码器把图像变成token序列过一个可学习的projector最常见是MLP映射到语言模型的embedding空间然后和文本token拼接在一起送给LLM。从模态交互方式来看这很像单流——视觉token和文本token确实在同一个Transformer序列里。但从编码器参数来看视觉编码器是单独预训练好的并不参与文本建模这又有点像双流。Qwen-VL、InternVL这些更复杂一点有的在LLM前面加了专门的视觉-语言适配器有的会在LLM层内部插入交叉注意力模块比如Flamingo。Flamingo的做法是在冻结的LLM层之间插入GATED CROSS-ATTENTION层让语言模型每几层就能“看一眼”视觉特征这本质上又回到了交叉融合的混合范式。所以我个人更愿意把多模态大模型看作是以双流预训练为基础、以单流式token拼接或交叉注意力为交互手段的综合体。理解单流和双流是拆解这些复杂大模型的底层能力。4. 实操上手从零搭一个最简版多模态模型4.1 环境准备和数据集选型动手跑代码之前先把环境和数据准备好。这一节我基于PyTorch和HuggingFace生态代码量不大核心思想是“先跑通、再调优”。环境建议Python 3.9PyTorch 2.0CUDA 11.8及以上transformers、datasets、accelerate这几个库尽量升级到最新如果你要训练视觉模型建议再装timm库加载ViT更方便数据集方面新手追求的是“迭代速度快”所以不要一开始就上CC3M这种百万级数据集。我建议先用Flickr30K或COCO的Karpathy split做训练几万张图足够验证你的模型能不能收敛。等模型结构确定没问题了再考虑CC3M、SBU Captions这些更大规模的数据集。数据预处理的几个坑图片resize到固定尺寸224x224别用随机尺寸。文本统一用小写过滤掉过长的caption。如果数据里有明显的噪声对比如图片是纯色背景但caption是一段完整的文章这种对模型训练没有帮助最好在预处理阶段过滤掉。4.2 最简双流模型代码实现先写双流因为结构更直观。import torch import torch.nn as nn import torch.nn.functional as F from transformers import AutoModel, AutoTokenizer from timm import create_model class DualEncoder(nn.Module): def __init__(self, vis_backbonevit_base_patch32_224, text_backbonebert-base-uncased, embed_dim256): super().__init__() self.vis_encoder create_model(vis_backbone, pretrainedTrue, num_classesembed_dim) self.text_encoder AutoModel.from_pretrained(text_backbone) self.text_proj nn.Linear(self.text_encoder.config.hidden_size, embed_dim) self.vis_proj nn.Linear(embed_dim, embed_dim) self.logit_scale nn.Parameter(torch.ones([]) * 2.6592) # 对应exp(2.6592)≈14.28约等于CLIP初始温度反比 def forward(self, images, input_ids, attention_mask): vis_feat self.vis_encoder(images) # [B, embed_dim] vis_feat self.vis_proj(vis_feat) vis_feat F.normalize(vis_feat, dim-1) text_feat self.text_encoder(input_idsinput_ids, attention_maskattention_mask).pooler_output text_feat self.text_proj(text_feat) text_feat F.normalize(text_feat, dim-1) return vis_feat, text_feat def compute_contrastive_loss(self, images, input_ids, attention_mask): vis_feat, text_feat self.forward(images, input_ids, attention_mask) logit_scale self.logit_scale.exp() logits logit_scale * vis_feat text_feat.t() # [B, B] labels torch.arange(vis_feat.size(0)).to(images.device) loss_i F.cross_entropy(logits, labels) loss_t F.cross_entropy(logits.t(), labels) return (loss_i loss_t) / 2几个写代码时容易踩的点视觉特征是图像塔的最终输出我直接用num_classesembed_dim让timm帮我把分类头换成指定维度这样省事但不够灵活。如果你想用ViT的[CLS] token就需要手动改forward逻辑取self.vis_encoder.forward_features(images)[:, 0]再过自己的投影头。logit_scale初始值建议按照CLIP论文来即log(1/0.07)≈2.659训练时让它自己学不要固定。对比损失的标签就是对角线上的indices因为正样本对永远是vis_feat[i]对应text_feat[i]。这个最简版本没有加hard negative训练效果会差一些但用来理解整个对比学习流程已经够了。4.3 最简单流模型代码实现单流模型稍微复杂一点关键是把视觉patch embedding和文本embedding拼成同一个序列。import torch import torch.nn as nn from torchvision import transforms from transformers import AutoTokenizer, BertConfig, BertModel import timm class SingleStreamModel(nn.Module): def __init__(self, vis_encoder_namevit_base_patch32_224, text_backbonebert-base-uncased): super().__init__() text_config BertConfig.from_pretrained(text_backbone) self.text_encoder BertModel(text_config, add_pooling_layerFalse) self.tokenizer AutoTokenizer.from_pretrained(text_backbone) # 用timm的ViT作为patch embedding去掉分类头 self.vit timm.create_model(vis_encoder_name, pretrainedTrue, num_classes0) vit_hidden self.vit.embed_dim # 通常是768 self.text_proj nn.Linear(text_config.hidden_size, 768) self.vit_proj nn.Linear(vit_hidden, 768) self.dropout nn.Dropout(0.1) # 可学习的模态类型向量 self.modality_type nn.Embedding(2, 768) self.itm_head nn.Linear(768, 2) def forward(self, images, input_ids, attention_mask, token_type_idsNone): # 1. 文本编码 text_out self.text_encoder(input_idsinput_ids, attention_maskattention_mask).last_hidden_state text_feat self.text_proj(text_out) # [B, T, 768] # 2. 图像patch编码 vis_feat self.vit.forward_features(images) # [B, num_patches1, vit_hidden] vis_feat self.vit_proj(vis_feat) # [B, P1, 768] # 3. 拼接成单序列 # 注意vit的forward_features第一个token是cls我们保留它 # 为简化去掉视觉cls只保留patch token避免和文本cls混淆 vis_feat vis_feat[:, 1:, :] # [B, P, 768] # 给序列加模态类型向量 text_modal self.modality_type(torch.zeros(text_feat.size()[:2], dtypetorch.long, deviceimages.device)) vis_modal self.modality_type(torch.ones(vis_feat.size()[:2], dtypetorch.long, deviceimages.device)) text_feat text_feat text_modal vis_feat vis_feat vis_modal # 拼一个CLS token batch_size images.size(0) cls_token self.dropout(torch.zeros(batch_size, 1, 768, deviceimages.device)) # 也可以用learnable cls embedding这里先占位 concat_feat torch.cat([cls_token, text_feat, vis_feat], dim1) # [B, 1TP, 768] # 4. 过Bert模型用BertModel的encoder部分 extended_attention_mask torch.ones(concat_feat.size()[:2], deviceimages.device) out self.text_encoder.encoder( concat_feat, attention_maskextended_attention_mask, output_hidden_statesFalse ).last_hidden_state itm_logits self.itm_head(out[:, 0]) # CLS位置输出用于ITM return itm_logits这段代码有一个偷懒的地方我直接用了BertModel的encoder部分来跑拼接后的序列所以文本模型和单流Transformer共享了一部分参数不算完全标准的单流实现。真正标准的单流模型比如ViLT会建一个新的Transformer来接收拼接序列文本编码器和视觉编码器在融合阶段统一处理。如果从零实现完整的ViLT你需要一个独立的patch embedding层把224x224x3的图像变成196个patch向量。一个独立的文本embedding层。一个统一的Transformer encoder接收上面两类向量拼接后的序列。上面我为了减少代码量复用了Bert的encoder和embedding但理解概念时不要把这种“复用”当真它只是demo。实际训练的时候单流模型更吃显存。我建议你从小batch开始比如16先确认前向反向都不报错再逐步加大。4.4 训练脚本中最容易出错的地方跑这两个模型的过程中我总结了一些特别容易让人崩溃的问题位置编码的序列长度对不上。ViT输出的patch数量是固定的但文本token数量不固定拼接后的序列长度会随文本长度变化。要么把所有文本pad到同一长度要么用attention mask屏蔽掉pad部分否则位置编码和注意力计算都会出错。两个encoder的learning rate可以分开设。视觉backbone如果是从预训练加载的建议用一个较小lr如1e-5新加的head用大一点的lr如3e-4。混合精度训练时注意loss是否能正常回传。图像增强策略对比学习里图像增强方式会显著影响效果。随机裁剪、水平翻转、颜色抖动是标配。我当时偷懒只用resize和归一化结果Flickr30K上的retrieval recall1直接从60掉到了45加回增强之后才恢复正常。5. 训练和部署中踩过的坑5.1 损失函数配比多任务模型容易“偏科”单流模型和混合模型通常会同时用多个损失最典型的是ALBEF的三件套ITC、ITM、MLM。损失配比如果不当模型会走偏。我自己的实验记录当ITC权重压到0.2以下时模型学会了用MLM“背答案”图像基本不看当ITM权重太小时模型又不太会判别图文是否匹配retrieval指标掉得很厉害。ALBEF论文里大概的比例是ITC:ITM:MLM 1:1:1但我实测下来把ITM权重提到1.5在某些数据集上效果更好特别是图文匹配负样本比较难的数据集。如果你用的是HuggingFace的Trainer建议把每个loss单独记录到log里每几百步看一眼避免出现某个loss异常增大覆盖掉其他loss的现象。5.2 对比学习的负样本困境CLIP式的对比学习非常依赖负样本的质量和数量。有几次我们为了省显存batch size调到64以下结果模型训练了几天retrieval指标始终不涨后来才发现是负样本太少。解决方案有两种梯度累积把一个大的逻辑batch拆成多个小batch累积梯度后再更新。注意对比学习的logits是在当前batch内算的梯度累积仍然在同一个逻辑batch内计算不会出问题。基于队列的负样本方法类似MoCo。维护一个存储历史特征向量的队列每次训练从队列里取负样本计算损失。这个方案能用很小的显存获得大量负样本缺点是队列里的特征可能是旧模型参数算出来的存在“陈旧”问题需要用动量更新缓解。5.3 图文弱相关的数据和清洗策略公开的图文数据集尤其CC3M这类自动采集的很多图文对根本不是“严格匹配”的。一句caption可能只描述了图片里很小的一部分或者图片里有多个人物/物体caption只提到其中一个。这种弱相关数据会给对比学习带来巨大噪声。我常用的几招用CLIP给每个图文对打个相似度分低于0.25的直接丢弃或降权。用BLIP这类模型给caption做改写生成更贴近图片内容的文本。把过长的caption截断很多时候后面半句话在胡说。同一张图片配多个captions时要控制同一个batch里不要出现太多近似重复的文本否则模型会把这些相似文本误当成正样本来拉近。数据清洗花的时间永远是值得的我见过太多项目模型结构没问题、数据稀烂导致指标上不去的案例。5.4 推理部署单流和双流的工程差异部署阶段两者的差别比训练阶段还明显。双流模型非常适合做召回/粗排图像库是静态的可以离线把图像全部过一遍图像塔把向量存到faiss或milvus里线上来一个文本query过一遍文本塔然后向量检索Top-K。整个链路延迟可以控制在几十毫秒以内吞吐量也很高。单流模型做不了这种“预计算”因为你必须实时把文本token和图像token拼在一起过一遍完整的Transformer才能得到相似度。但它的优势在于可以做生成式任务比如图像描述、视觉对话。这时候你输出的是整个token序列而不是一个向量。工业界常见的选择是混合部署用双流模型从几百万图库里召回几百张候选图再用单流模型在这几百张上精排。我参与的一个电商视频检索项目就是这么干的粗排用CLIP向量召回精排用一个轻量级单流模型做细粒度匹配整体效果比单纯用CLIP直接从全库检索高了十几个点的准确率。6. 项目选型手头任务到底该用哪种架构6.1 场景自查清单我根据实际项目经验把常见任务分成了几类直接对号入座即可任务类型推荐架构理由文本搜图、图搜文本、向量召回双流CLIP/SigLIP可预计算向量、延迟低、适合海量索引图像打标、图文相似度判断双流或轻量混合只需全局匹配不需要逐token交互视觉问答、引用表达式理解单流或带融合编码器的混合需要细粒度局部对齐图像描述生成、视觉对话多模态大模型混合范式生成式任务天然需要单流式条件建模细粒度检索如“红色上衣的女生”双流召回单流精排兼顾效率和精度视频-文本检索双流视频双塔视频帧多双流可预抽取特征6.2 成本和效果怎么权衡选型的时候我给你几组经验值参考数据量小于10万对双流模型比较容易训起来单流要小心过拟合建议加预训练权重和强正则。数据量百万级两条路线都能出效果但双流的训练成本明显更低因为不需要做逐token的交互计算。显存资源有限单卡24G以下优先考虑双流或轻量混合模型尽量别碰大尺度单流。需要低延迟线上推理P99小于100ms双流几乎是唯一选择单流在图片数量大时根本扛不住。这些经验值不是绝对真理但作为初始参考很够用。我做项目的时候通常会先跑一个CLIP双塔baseline把召回指标摸清楚如果baseline已经能满足业务需求就不折腾单流精排了。6.3 几条实战建议最后说几个我在实际项目中反复验证过的经验第一双流baseline永远是最值得先跑的东西。CLIP架构简单、训练稳定、指标天花板高哪怕你最终方案是单流先把双流结果跑出来也能给你一个“最小可接受效果”的参照。很多团队一上来就追多模态大模型结果项目周期拉长了好几倍不如先用双流把pipeline跑通。第二单流模型微调时尽量用更小的学习率和更多的warmup步骤。因为单流要同时微调视觉和文本的交互部分学习率稍大训练loss就会疯涨。我一般把峰值学习率设在2e-5到5e-5之间并配合线性warmupcosine decay。第三如果你要复现论文千万别只看模型代码损失函数和训练策略往往比模型结构更关键。比如ALBEF的动量蒸馏、BLIP的CapFilt这些“辅助模块”对最终效果的贡献可能占一半以上。只抄主干结构、不抄训练策略的复现十有八九达不到论文指标。第四数据质量永远优先于模型结构。给模型换一个更复杂的融合模块效果提升可能只有1-2个点把弱相关的脏数据清掉、补一批高质量图文对指标直接上浮5个点以上。做多模态项目多花时间在数据上是绝对不会亏的。第五多模态大模型不是万能的。它确实在生成类任务上碾压传统单流/双流但在纯检索场景一个训练得当的CLIP双塔往往更快、更省、更可控。选型的时候先问自己任务需要生成还是需要召回需要细粒度对齐还是全局匹配把这两个问题想清楚架构选择基本就定了。