你大概是在挑模型或者做接口对接时撞上这个问题：有人张口说 mimo v2.5 是多模态，也有人说它只能吃文本。两边都没给出处，你手里的选型表就卡在这一格填不下去。这篇不替你下结论，而是给一套查证路径——从官方页面看什么字段、从接口返回看什么痕迹、本地权重和调用版的口径差在哪，顺带说清「多模态」这个词在不同场地里含义不一样，别拿一句话套到底。
撞上「mimo v2.5 是多模态吗」这个问题，通常不是你想做学术考据，而是选型表上有一格填不下去：有人拍胸脯说能收图，有人翻白眼说它只认文本，两边都没给出处。这种时候最忌讳的是找个人再问一遍，然后拿他的口气当依据。
换个思路：把它当成一次信息核对，而不是一次表态。多模态这个说法本身就松松垮垮，收图、出图、处理音频视频是三件不同的事，官方托管接口和开放权重也可能是两个口径。下面给一套能自己走完的查证顺序，走完之后你自己就能填表，也大概能听出别人那句结论是从哪来的。
为什么同一个问题会有两种答案
先说清楚分歧出在哪，不然你查了半天，发现你和对方根本不在讨论同一件事。「多模态」这个词在实际对话里至少被折叠了三种含义，拆开之后你会发现双方可能都对，只是各自在说不同那一层。
- 把三件事揉成一句：能不能接收图片输入、能不能生成图片输出、能不能处理音频或视频，这三件事的支持情况经常不一样，却都被说成「多模态」
- 口径不同：官方托管接口和开放权重版的能力清单不一定一致，一个拿着接口文档说，一个拿着权重说明说，当然吵不出结果
- 时效不同：模型改名、加后缀、出快照，都可能换一份能力表，旧结论被继续转发就成了「两种答案」
- 问法不同：问「支不支持图片输入」和问「是不是多模态」，大概率会拿到两个不同精度的回答
先去哪儿核对：三个能定位的字段
别一上来就写测试代码，先花几分钟把页面上能落地的字段看一遍。判断依据是那个字段能不能对应到一次真实请求的参数，宣传语不算。本站有几处可以直接对照，路径记好。
- 官方接口页
- 到 /official-api/providers/xiaomi 看官方接口的输入输出口径和计费单位，图片是否单独计费、按什么单位算，往往能侧面反映它到底认不认图
- 模型库
- 到 /models 查具体模型条目里的模态标注和上下文规格，看它列的是纯文本还是带上了图像字段，规格表通常比宣传语诚实
- 多模态分类页
- 到 /multimodal 看本站怎么区分多模态和纯文本模型，至少能知道评判口径是什么，再回头看目标模型归在哪一类
| 核对位置 | 看什么 | 能得出的结论 |
|---|---|---|
| 官方接口页的计费单位 | 是否按图像或像素单独计价 | 倾向支持输入侧图片 |
| 模型条目的模态标注 | 只列文本还是含图像字段 | 文档层面的能力口径 |
| 请求参数字段说明 | 有没有图像相关的入参 | 是真支持还是宣传语 |
| 输出返回字段 | 有无图像文件的返回结构 | 能否判断输出侧能力 |
这张表的用法是：三处都指向同一结论，可信度就高；如果接口页说要图片计费、模型条目却只写文本，那就是口径不一致，得往下走验证那一步。价格和具体数字不要凭记忆，到站内相关页面核对当时的数字。
自己动手验一遍：最小验证动作
文档永远可能落后于接口，所以真正能拍板的还是自己发一次请求。下面这套动作控制在几分钟内，顺序别跳，先文本后图片，先跑通再试边界。
- 先跑纯文本用一段最普通的文本请求确认账号、额度、网络都正常，这一步不通就别往下测，问题不在多模态上。
- 换请求体塞一张小图把请求体里的内容改成带图片的形式，观察返回是正常回答还是参数报错。报错里提到的字段名，基本就是它认不认图的第一手线索。
- 回问刚才那张图换成纯文本提问，让它描述刚才那张图。能顺着答说明图片真进了上下文，答得含糊或硬编说明只是接口层面接受了参数。
- 测输出侧明确要求它生成图片或返回图像文件，看返回结构里有没有对应的文件字段。没有就是只有输入侧，别把输入能力当成全模态。
如果这四步里有任何一步的结果和接口文档对不上，先别下结论，记下请求参数和返回片段，到站内对应的模型条目下核对是不是版本快照不一样。一个反例：有团队在聚合平台上测通了图片输入，就对外说这个模型能出图，结果交付时才发现输出侧压根没有对应字段。
结论怎么落进选型表，什么情况下这条结论作废
验证做完，最容易犯的错是把它压成一个「是」或「否」填进表格。下游同事看到「是」，很可能默认输入输出都行，然后在联调时踩坑。建议拆成两格写。
- 输入侧写清楚支持什么形态：纯文本、图片、音频视频，哪些是确认过的，哪些没测
- 输出侧单独写：能不能出图、出文件，没有就明确写「未验证」而不是「不支持」
- 标注口径来源：是官方接口文档、模型条目，还是你自己实测，可信度不一样
- 写上复核条件：版本快照更新、接口参数调整、换成中转或第三方托管之后，这条结论要重跑
什么情况下这条结论对你没用？如果你的任务从头到尾只处理文本，那多模态支持与否不构成任何选型理由，别为了一个用不上的能力去换模型或者加预算。另外，一旦你的调用不直接走官方而是经过中转或聚合平台，模态支持就取决于对方转发时保留了哪些参数，原先的验证不适用，得在新链路上重测一遍。要判断某条链路值不值得信，可以到 /rankings 和 /price-watch 对照当时的口径和数字。
下一步把目标模型的接口口径、模型条目和实测结果并排放一次，对照本站的多模态分类口径，你能很快判断出那句「是多模态吗」到底指哪一层。→常见问题
只看官方文档里写的模态标注就够了吗？
不够。文档标注是起点，真正要确认的是请求体里能不能放对应类型的输入、返回里有没有对应输出字段。标注有时写的是产品愿景，接口才是能兑现的那部分。稳妥做法是拿一次最小请求跑通，再决定要不要写进选型表。
别人说支持，我说不支持，怎么不吵架地核对？
先对齐问的到底是输入还是输出，很多分歧在这里就消掉了。然后各自说出处：是官方接口页、模型库条目，还是自己实测的请求。出处对不上就以能复现的那次请求为准，其余当待验证。这种对齐比争结论有用。
走中转站调用时，模态能力怎么判断？
中转站转发的是它自己挑的参数，官方支持不代表这条链路也通。判断方法是拿同样的图片请求在中转和官方各跑一次，看返回是否一致；到 /sites 挑站时把这项当验收项写进去。差异大的就别把多模态任务押在它上面。
