你在做技术选型或方案评审时，常会遇到这样的场景：供应商把一套多模态能力说成「通用助手」，但你拿真实任务一试，发现它在某个模态上明显是拼装的，换个输入格式就崩。这篇不讲榜单名次，而是从架构演进的角度把「专家模型、对齐拼接、原生统一」几代做法拆开，给你一张能对照自己业务输入输出的判断表，以及查模型规格、算部署开销的具体路径。
做技术选型和方案评审时,常碰到这种场面:供应商把一套多模态能力包装成「通用助手」,PPT 上什么模态都能画两笔。可你拿真实任务一试,换个输入格式就崩,或者图像输入其实只是被转成一段文字描述,再走纯文本链路。这不是模型不行,是它的架构代际和你以为的不一样。
下面不讲谁排第几,而是从架构演进的角度,把「专家模型、对齐拼接、原生统一」几代做法拆开,给一张对照自己业务输入输出的判断表,以及查模型规格、算部署开销的具体路径。看数字请到站内模型库和价格追踪页核对当时的数值,这里只给判断方法。
三代做法:专家模型、对齐拼接、原生统一
专家模型阶段,每种模态单独训一个编码器加一个任务头,检测归检测、OCR 归 OCR、语音归语音。能力做得深,但接口碎,换一个任务基本就是换一个模型,服务编排层要维护一堆端点。这类方案的边界非常清晰,也最容易压测。
对齐拼接阶段是目前最常见的工程形态:一个视觉编码器接投影层,把图像特征对齐到语言模型的 token 空间,本质是给语言模型「外挂一双眼睛」。落地快、生态好,但跨模态推理偏弱,遇到需要反复看图、看图算数、多图对比的任务,容易掉链子。原生统一阶段从预训练就把多模态 token 混在一起,指令跟随和跨模态迁移更自然,代价是训练数据和算力门槛陡增,推理侧的开销也明显更高。
| 代际 | 典型结构 | 强项 | 要小心的地方 |
|---|---|---|---|
| 专家模型 | 分模态编码器 + 任务头 | 单任务稳定、可压测 | 接口碎、跨任务复用差 |
| 对齐拼接 | 视觉编码器 + 投影层 + 语言模型 | 工程落地快、工具链成熟 | 跨模态推理弱、多轮看图易漂 |
| 原生统一 | 多模态 token 混合预训练 | 指令跟随自然、迁移好 | 显存与延迟高、微调门槛高 |
- 先看接口:一个模型要覆盖多种模态,还是一个模态一个端点
- 再看训练形态:描述里提不提「联合预训练」「统一 token」这类关键词
- 然后看推理行为:能不能在一轮对话里同时引用图和文,而不是先出描述再问答
- 最后看退化场景:换分辨率、加图数量、混排版,看它在哪里开始丢信息
什么时候专家模型反而更划算
不是所有场景都该上通用助手。输入格式固定、批量大、准确率可测的任务,比如固定版式的票据识别、固定字段的证照抽取,专用小模型在成本和稳定性上常优于通用助手。通用助手的真正优势在任务边界模糊、需要自然语言交互和多轮修正的地方,而不是在单一指标上碾压。
判断标准可以拆成三项:输入形态是否收敛、是否需要跨模态推理、错误代价有多高。三项都偏保守,就选专家线;有两项偏开放,通用助手更容易覆盖后续需求变更。反过来说,如果任务会持续演化、需求方自己都说不清输入格式,那专家模型的维护成本会迅速反超,这时候硬守专家线并不划算。
- 先收敛输入把近三个月的真实输入抽样出来,统计格式种类和分辨率分布。种类少、分布窄,专家线可行。
- 再评估跨模态需求列出必须同时看图看文才能完成的问题。数量多,通用助手的收益明显。
- 算错误代价错误是人工复核能兜住,还是会直接影响结算或合规。代价高就优先稳定性,而不是模型声量。
- 留一条回退无论选哪条线,都保留另一条的最小可用链路,方便后续按任务类型分流。
拿到一个多模态模型,先核这几项
模态覆盖要拆成「能输入」和「能对齐推理」两层。很多模型所谓支持图像,只是把图转成一段描述文本,再走纯文本链路,视觉信息在这一步就丢了细节。核规格的时候,去站内模型库的规格页看它的输入形态和上下文结构,别只看宣传页的勾选框。
分辨率和切图策略决定小字、长图、多栏排版的成败,这一项在多数宣传材料上不会写。输出侧同样要确认:是纯文字、结构化字段,还是直接出图。输出模态决定了它能不能直接接进你的下游流程,以及要不要额外加一层解析。
- 模态覆盖
- 分输入支持和推理对齐两层看,别把「能传图」当成「懂图」
- 分辨率与切图
- 影响小字和长图表现,通常在规格页而非宣传页
- 输出形态
- 文字、结构体还是图像,决定下游要不要加解析层
- 上下文结构
- 图像以什么形式占 token,直接影响显存和可处理的图数量
落到部署:显存、并发和许可证
多模态模型的视觉编码器和图像 token 会额外吃显存,按纯文本参数量估出来的配置通常不够用。做法是到站内部署测算相关页面,把图像输入按真实比例再算一遍,而不是沿用纯文本的估算。图像越多、分辨率越高,这一块的差距越明显。
并发上要区分「文本吞吐」和「含图请求吞吐」,后者常常是前者的几分之一。压测时务必混入真实比例的图文请求,否则线上会出现文本很流畅、一上图就排队的情况。许可证也要单独看视觉模块和权重条款,有些模型文本部分宽松、图像部分限制商用,这类差异在选型早期就该确认。
- 按纯文本估的显存配置,拿到图文混合负载下再校一遍
- 压测流量按真实图文比例混入,不要只压文本
- 量化档位对图像精度的影响比纯文本明显,小字识别任务别直接用最激进的档
- 许可证分模块看,文本和视觉部分可能条款不同
- 关注图像 token 占比,它决定长对话里能带多少张图
先算清含图请求的真实开销,再谈这个通用助手能不能长期跑在你的预算里。
换代与迁移:先定回退线
升到更强的通用助手之前,先用历史 badcase 做一次回放,重点看原来靠专用模型兜住的那部分有没有退化。保留旧链路至少一个迭代周期,按任务类型分流,而不是整体切换。记录每次换模型前后的输入形态、延迟和人工复核率,这三项比任何总分都更能说明是否真的变好。
不迁移的情况也要写清楚:当任务输入高度固定、现有方案已经满足验收标准时,迁移的收益往往覆盖不了回归成本。换代的前提是你有明确的收益点,比如要支持新模态、要接自然语言交互,而不是单纯因为新模型声量大。
| 要记录项 | 怎么记 | 看什么 |
|---|---|---|
| 输入形态 | 按任务分类抽样 | 换模型后是否出现新的失败形态 |
| 延迟 | 分纯文本和含图两档 | 是否在高峰期恶化 |
| 人工复核率 | 按周统计 | 是否比迁移前上升 |
| 回退触发条件 | 提前写进发布流程 | 达到阈值就切回旧链路 |
常见问题
通用助手是不是迟早会取代所有专家模型？
在开放任务上趋势明显，但在输入格式高度固定、延迟和成本被卡死的场景里，专用模型仍有位置。判断方法不是看谁更聪明，而是看你的任务是否真的需要跨模态推理和自然语言交互；不需要的话，专用线的稳定性和可测性反而更省心。
怎么快速判断一个模型是真多模态还是拼装的？
给它一个必须同时看图内文字和整体布局才能答对的问题，再给一个只改图不改文字的对照题。真对齐的模型两题表现一致，拼装式的往往只在文字描述层面作答。也可以去模型库和测评榜单看它的输入规格与任务覆盖说明。
多模态模型的部署成本怎么估才不翻车？
别按纯文本参数量套。先把图像分辨率和切图数换算成图像 token，再叠加文本长度，用部署测算页按含图请求重算显存和并发；同时确认量化档位是否影响视觉模块精度。压测时按真实图文比例混流量，避免只跑文本得出偏乐观的结论。
