多模态大模型现阶段主流有哪些

你在做选型，需求里写着「要能看图、能听语音、最好还能说话」，可一打开模型列表，几十个名字全写着多模态，根本不知道差别在哪。这篇不给你拍板选谁，而是给一套从拆模态、定边界到跑小样本自测的动作顺序，让你能把候选从几十个收敛到两三个，并且知道什么情况下这套方法不适用。

你在做选型，需求里写着「要能看图、能听语音、最好还能说话」，可一打开模型列表，几十个名字全写着多模态，根本不知道差别在哪。这篇不给你拍板选谁，而是给一套从拆模态、定边界到跑小样本自测的动作顺序，让你能把候选从几十个收敛到两三个，并且知道什么情况下这套方法不适用。

先说清边界：下面所有判断标准都是给「要自己动手接 API 或做私有化」的技术选型者用的。如果你只是想知道哪个模型聊天更聪明，那这篇帮不上；如果你已经在考虑授权、并发和回退通道，那顺序照着走基本不会跑偏。

第一步：先把「多模态」拆成你要的那几个模态

很多人一上来就搜「最好的多模态模型」，这一步就错了。你真正要回答的是：我的项目吃进去什么、吐出来什么。把输入和输出各画一列，横轴是图像、音频、视频、文本，逐格标必须、可选、不需要。必须的格子才是筛选条件，可选的那些不配进第一轮。

填完你会发现自己需求没那么「全模态」。再往下拆一层：识别和生成是两条完全不同的路线。能读懂图里的表格，不代表能画出一张合格的商品图；反过来也一样。供应商喜欢把这两件事放在一句宣传语里，你得自己分开记。

• 语音要再拆三类：转写（把语音变文字）、合成（把文字变语音）、端到端实时对话（边说边想边回）
• 转写看的是准不准、带不带时间戳；合成看的是像不像人；实时对话看的是能不能被打断
• 把这三类混成一个「语音模型」去比，比出来的结论没有意义
• 落地动作：用一张四行表格把项目输入输出填满，填不满的格子说明需求还没想清，先别选型

看清厂商标「多模态」时的几条真实界线

同一句「支持多模态」，背后可能是两种完全不同的工程实现。一种是原生统一架构，从训练阶段就让不同模态共享表示；另一种是把视觉编码器接到已有的语言模型上，属于后挂。后者在简单任务上够用，一旦要做跨模态推理，比如「对比两张图并解释差异」，掉链子的概率明显更高。

第二道界线是上下文成本。图片塞进上下文会吃掉大量 token，一张高清图折算下来往往相当于一大段文字。长文档加图片的组合最先撞墙，不是因为模型读不懂，而是因为窗口被图片占满了。这意味着多模态请求的成本结构跟纯文本完全不同，不能拿纯文本的单价去估。

音频这条路要单独看几个参数：采样率、是否支持流式返回、能否打断。这几个参数决定它能不能进真实通话场景。离线转写和实时对话，对模型的要求几乎不是一个量级，别用离线场景的测试结论去推实时场景。

语音模型对比要盯的四条轴

语音模型对比最容易犯的错，是拿一个总分去排名次。其实真实选型里，四条轴比总分有用得多，而且每条轴都必须用你自己的素材测，公开 demo 上的漂亮例子说明不了什么。

延迟

是不是流式返回、首字多久出来，直接决定能不能做实时对话；离线转写对这条不敏感

语种与口音

中文方言、中英混说、专业名词的识别率，必须用你自己的音频测，别人的榜单不算

可控性

音色克隆、情绪、语速这些能不能调，决定了产品听起来像不像人，也决定合规边界

计费口径

按分钟还是按字符、是否区分输入输出，同一段音频在不同口径下差很多

这四条里，计费口径最容易被忽略。同一个语音任务，按音频时长计费和按字符数计费，在语速快慢不同的场景下账完全不一样。具体当前规格和计费方式，去站内语音模型页面核对当时的数字，别用记忆里的旧口径做预算。

这四条轴不适用的情况也要说清：如果你只做单向播报、不需要用户打断，那延迟这条可以直接降权；如果你只处理标准普通话录音棚素材，口音覆盖这条也不用花太多精力。

用三张清单把候选收敛到两三个

候选收敛的顺序很重要：先用准入砍到十个以内，再算成本，最后才聊效果。反过来做，先看谁效果好，你会带着一堆不符合硬性门槛的候选反复比较，越看越乱。三张清单分别管三件事。

• 准入清单：模态覆盖、语言、许可证、上下文长度是否满足硬性门槛，不满足直接划掉，不留情面
• 成本清单：按你自己的日调用量估算，而不是看单价绝对值——短请求多和长请求多的账完全不同
• 风险清单：是否有稳定的托管通道、是否只此一家、换模型要改多少代码，单一供应源要提前想好退路

成本这一项特别提醒：单价高低不能直接横向比。长请求多的场景里，单位调用成本会被输入长度放大；短请求多的场景里，固定开销占比更高。正确的做法是拿你自己的真实请求分布去估一个月总量，看总账而不是看单价。当时各家计费口径到站内价格追踪页面核对。

风险清单里最值得花时间的是「换模型要改多少代码」。如果模型名、参数、返回格式散落在业务代码各处，换一次的成本会比省下的调用费高得多。提前把适配层抽出来，是唯一能让退路真正可用的办法。

自测怎么做才有区分度

自测最常见的失败，是拿公开 demo 里的漂亮例子去测，测出来每家都好看，区分度为负。真正有区分度的自测，必须用你自己的真实样本，而且只打能判对错的项。

1. 准备样本每类任务准备十到二十条你自己的真实样本，覆盖正常、边界、脏数据三种情况；别用公开例子
2. 定义打分只打能判对错的项：字段抽对没有、时间戳偏多少、图里的数字读没读对；主观打分不算
3. 归档失败把失败样本单独存下来，看错的是同一类问题还是随机抖动；同类错说明能力边界就在那
4. 隔周复跑同一批样本隔一周再跑一次，输出波动大的模型不适合做需要稳定的生产环节

这套方法不适用的情况：如果你做的是探索性原型，样本还没稳定下来，那别急着建回归集，先把需求跑通。自测的投入应该跟项目阶段匹配，过早建评测集也是浪费。

上线前补的两件事：授权与部署形态

开源权重不等于随便商用。要看许可证对调用量、二次分发和署名有没有要求，边界不清就先按不能商用准备，别等上线前才发现要换。这一条不区分模型大小，小模型翻车的案例一样多。

想走私有化就得算显存和并发。多模态模型的显存占用通常比同参数纯文本模型高，因为视觉或音频编码器要额外吃一块。去站内部署测算页面按你自己的卡算一遍，比拍脑袋估靠谱。托管和本地混合部署是常见折中：日常流量走托管，敏感数据走本地小模型，代价是要维护两套提示词和评测集。

同样有不适用的场景：如果只是内部试用或做原型验证，先别纠结授权和私有化，跑通效果再回来补这两件事，顺序颠倒会拖慢整个进度。

换模型时的迁移与回退清单

选型结论不是终点，换模型才是常态。所有跟具体模型绑定的写法——模型名、参数名、特殊提示词格式、返回结构解析——都要抽出来做成一层薄适配，别散落在业务代码里。这是唯一能让「换一家试试」变成低成本动作的做法。

• 建立回归集：换之前跑一遍，记录哪些任务变好哪些变差，只接受整体可接受的交换
• 抽适配层：把模型绑定写法集中到一处，业务代码只调统一接口
• 保留旧通道：至少留一个版本周期的回退能力，出现大面积质量下滑能立刻切回去
• 记录决策：每次换模型写下原因和对比结果，方便下次复核

这里的不适用情况是：如果你的调用量极小、任务也简单，建回归集和适配层的投入可能超过收益，那就老老实实用一家，把精力放在业务上。

一页纸的决策流：从需求到选型结论

把前面几节压成一页纸的流程，选型的时候照着走，每一步都留下记录，结论要能被别人复核，而不是「感觉这个好用」。下面这张表是每一步要产出的东西。

最后提醒一句：模型列表和计费口径一直在变，这篇给的只是动作顺序，不是名单。具体有哪些主流多模态和语音模型、当时的规格与数字，到站内多模态模型和语音模型页面看当时的清单。数字会过时，方法不会。