多模态模型有哪些主流架构

找多模态模型时，常看到「统一编码」「交叉注意力」「双塔」这类词，但没人说清它们各自解决什么问题、什么时候不适用。这篇按架构类型过一遍：每类是哪种思路、适合什么活、什么样的团队和任务不该选它。最后给一份对照清单，让你在站内模型库里筛模型时知道去看哪几项规格。

找多模态模型的时候，规格页上经常蹦出「统一编码」「交叉注意力」「双塔」这类词，但很少有人讲清它们各自解决什么问题、什么情况下不适用。结果就是照着名词挑模型，选完发现任务对不上。这篇按架构类型过一遍：每类是什么思路、适合干什么活、什么样的团队和任务不该选它。最后给一份对照清单，让你在站内模型库里筛模型时知道该翻哪几项规格。

先把话说在前头：架构分类是帮你缩小候选范围的工具，不是选型的终点。同一个架构类型下不同模型的表现可以差很远，反过来同一类任务也可能被两种架构都覆盖。所以下面的判断标准都带「不适用」的说明，看到符合自己情况的例外，就老老实实去跑样例验证。

先分清：哪些差异算架构差异

比较两个多模态模型时，先别急着看参数量或者名字里的后缀。真正决定架构归类的是三件事：模态编码器怎么接进来、融合发生在哪一层、输出是文本还是图。这三点的组合不同，才算架构不同；其余差异大多属于规模或训练策略的范畴。

编码器怎么接

图像、音频各自有独立编码器，还是直接切成 token 和文本拼在一起进同一个主干

融合发生在哪一层

只在最后对齐，还是主干中间若干层就反复交互，决定了图文关联的粗细

输出形态

只出文本，还是能出图像、坐标框、结构化字段，直接决定能不能接你的下游

• 参数量、训练数据规模、模型版本号不算架构差异，别把它们混进架构对比里
• 同一家厂商不同代的产品可能换过架构，光看名字看不出来，要去模型库翻规格页确认
• 「支持多模态」这种宣传语不算信息，要具体到支持哪几种输入、是否支持交错输入
• 部署侧的差异（是否要额外视觉编码器、显存峰值）也算架构带来的后果，选型时要一起看

三类常见设计：统一编码、交叉注意力融合、双塔对齐

把市面上常见的多模态架构归归类，基本能落到三种设计取向上。它们不是互斥的技术路线，很多模型是混合的，但主取向决定了它擅长什么、贵在哪。理解这三类，主要是为了在筛模型时快速判断「这活它接不接得住」。

判断自家任务该往哪类靠，简单办法是问一句：我要的是「粗对齐」还是「细理解」。粗对齐指的是把图和文匹配上就行，比如搜图、去重、召回；细理解指的是要基于图里的具体内容做推理或定位，比如读图表、看界面截图回答问题。前者优先考虑双塔，后者优先考虑交叉注意力或分辨率支持好的统一编码类。

• 做图文检索、图库去重、以图搜图：优先双塔类，延迟和成本都好控制
• 做文档图表解析、界面截图理解、需要指着某个区域回答：优先交叉注意力或统一编码里分辨率支持好的那类
• 做视频、音频多路输入：先确认模型是否真的支持这些模态，别只看宣传语，去 /multimodal 看现有条目
• 纯文本为主、偶尔配图：别为偶发需求上重型架构，预处理链路和显存成本都不划算

按任务对号：什么活配什么架构

上一节讲的是架构取向，这一节把它翻成任务语言。实际选型时，很少有人是从架构名词出发的，都是从「我要做个什么东西」出发。下面按几类常见任务给出对应关系，同时标出哪些情况下这个对应关系不成立。

这张表是起点不是终点。同一类任务在不同数据分布下可能落到不同架构上，比如你的图表都是极简线条图，可能双塔加后处理就够了；但界面截图里控件密集，就必须上融合更细的架构。所以下一步永远是拿自己的数据跑一遍，而不是拿这张表当结论。

选型前该核对的几项和不该信的东西

架构分类只能帮你缩小范围，真正做决定前还有几件事必须自己动手核。这一节的清单就是让你在候选列表里筛到最后两三个时，知道该查什么、该测什么。

1. 攒验收样本从自己业务里抽二三十条真实图文样例，覆盖你关心的边界情况。跑一遍看错在哪、错得多离谱。这比看任何榜单都直接，因为榜单的任务分布和你不一样。
2. 核规格页的三栏去模型库看每个候选的「输入处理」「融合层次」「输出形态」三栏怎么写的，跟前面架构分类对上号。对不上号就说明规格页信息不全，需要找文档补充。
3. 算部署成本多模态的视觉编码器会额外吃显存，别按纯文本模型的账估。到部署测算页按自己的并发和输入尺寸算一遍，看峰值显存和延迟兜不兜得住。
4. 单独看许可证权重开放不等于可商用，许可证要单独核。开源权重类文章里有边界说明，别默认能随便用。
5. 留回退方案架构不同的模型之间切换，往往要重写预处理代码。选型时就想好如果这个不行，退到哪个、改动量多大。

落地顺序：从任务倒推，而不是从架构名词正推

最后给一个执行顺序。很多人选型的顺序是「看到某个架构很火，找支持它的模型，再想能做什么任务」，这个顺序容易翻车。反过来从任务出发，倒推架构，再筛模型，才是最省返工的路子。

1. 写清输出是什么一段描述、一个位置坐标、还是一张改造后的图？输出形态直接排除掉一批架构。写不清楚就说明任务还没定义好，先别急着选模型。
2. 定延迟和成本上限先划出能接受的延迟区间和成本区间，再看哪些架构兜得住。超出上限的架构再准也先放一边。
3. 在模型库筛候选带着前两步的约束去模型库筛，逐个核规格三栏，跑自建样例。这一步会砍掉大部分候选。
4. 留回退和迁移路径确认如果主选不行，退到哪个、预处理代码改动量多大。架构跨度大的备选要提前评估迁移成本。