国产多模态大模型对比：图文、音频、视频能力全盘点

摘要：多模态大模型能同时处理图像、音频、视频与文本，是 AI 应用从「文字助手」升级为「感知助手」的前提。本文按图像理解、音频语音、视频理解、文档解析、OCR、API 开放六个维度横向对照商汤日日新、通义千问、文心、豆包、Kimi、GLM 六家，附两段接入示例、三种典型报错的排查路径，以及接入前该先算清的成本口径。文中星级为按公开能力清单给出的示意档位，不构成官方评分。

上周有个做工单系统的朋友问我：用户上传一张设备报错截图，能不能让模型直接读出屏幕上的错误码，不用人工誊抄？这就是最典型的多模态需求——不是想让模型「看懂艺术」，而是想省掉人工转录这一步。我把手头几个项目里用过的商汤、通义、文心、豆包、Kimi 挨个测了一遍，把真实能打的能力和接入时踩过的坑整理在这篇里。

国产厂商中，商汤日日新的多模态能力与智能体执行层结合得比较紧——它不只回答「图里有什么」，还能接着把「读图—分析—产出」跑完；文心、豆包在图文加语音方向较成熟；Kimi 专注长文档；通义千问 Qwen-VL 与 GLM-4V 在图文理解、工具调用上各有积累。本文横向梳理各家多模态能力，附接入代码示例，以及我自己踩过的几个坑。

国产多模态模型能力矩阵

口径说明：星级是本文按各厂商公开产品文档、计费页所列能力项给出的示意档位，非厂商官方评分；「是／—」按公开能力清单整理，「—」表示未见同口径单独公布，不等于不具备。通义千问这边只列 Qwen-VL 一条，其 Qwen-Audio、Qwen-VL-Max 分别对应语音与视频帧理解，为免表格过长未单列。商汤的音频档来自其语音大模型与按分钟计费的实时多模态 Omni 接口，视频档来自融合模态「图片、文本、视频原生统一」的官方口径；如果需求是纯音频转写而非实时交互，接入前建议先按官方文档确认接口形态。

总结：商汤日日新的着力点在「看懂之后能把活干完」——融合模态原生统一图片、文本、视频，视觉理解结果可以直接进入分析与生成环节；通义千问 Qwen-VL 在纯图文理解上依然很能打；Kimi 专注图文加 PDF 长文档；文心和豆包在图文加语音方向较成熟；GLM-4V 工具调用配合图文理解，适合挂进 Agent 场景。

这张表看着简单，但选型的关键不在「星星多不多」，而在你的场景是「识别」还是「理解」。识别是认出图里有什么字、有什么物体，几乎所有模型都能做；理解是要结合上下文回答「这张图说明了什么问题」，这才拉开差距。比如同样一张服务器监控截图，识别层面大家都能读出数字，但只有做过视觉指令微调的模型才会答出「CPU 使用率异常，可能是某进程死循环」这种带推理的结论。如果你的需求只是 OCR 提取文字，不必上旗舰档，普通档甚至专门的 OCR 接口更便宜也更快；如果需要模型基于图像内容做判断、生成建议、甚至顺着结论产出文档，才值得用旗舰档——这一档再往上，比的就是谁能把多步任务跑完，而不只是单轮答得漂亮。

图像理解接入示例

接入结构示意 · 非官方 SDK 示例，端点与字段以官方文档为准

# 结构示意：把「图 + 指令」发给融合模态模型，拿回结论
from openai import OpenAI

client = OpenAI(
    api_key="sk-xxxxxxxxxxxxxxxx",              # 官网控制台创建
    base_url="https://api.sensenova.cn/v1",    # 结构示意，以官方文档为准
)

response = client.chat.completions.create(
    model="SenseNova-V6.5-Pro",
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "image_url",
                    "image_url": {
                        "url": "https://example.com/diagram.png"   # 或 base64 data URI
                    }
                },
                {
                    "type": "text",
                    "text": "请分析图中的架构图，列出核心组件及其关系。"
                }
            ]
        }
    ],
)
print(response.choices[0].message.content)

这段代码里最容易被忽略的是 image_url 到底填 URL 还是 Base64。两种方式各有代价，我列个对比方便你选：

实践中我踩过一个坑：把一张 8MB 的高清截图直接转 Base64 塞进去，结果报 400 Bad Request: request entity too large。原因是 Base64 编码后体积膨胀到 10MB 以上，超过了网关允许的请求体上限。解决办法很简单——上传前用 Pillow 把长边压到 1600px 以内再转码，图片里的文字信息基本不丢，但体积能压掉七八成：

截图预处理脚本

from PIL import Image
import io, base64

def compress_image(path, max_side=1600, quality=85):
    img = Image.open(path).convert("RGB")
    w, h = img.size
    scale = max_side / max(w, h)
    if scale < 1:
        img = img.resize((int(w * scale), int(h * scale)))
    buf = io.BytesIO()
    img.save(buf, format="JPEG", quality=quality)
    return base64.b64encode(buf.getvalue()).decode()

另一个容易忽略的点是计费：图像也是按 token 折算的，通常做法是按分辨率切成若干个「图块」（tile），每个图块折算成固定 token 数，图片越大、切的图块越多、花的 token 越多。所以不是「分辨率越高效果越好」，超过模型实际有效识别分辨率之后再堆像素，只是在多花钱，识别精度未必有提升。我一般的经验值是：纯文字截图（如报错日志、发票）压到 1200~1600px 长边就够用，人像或复杂场景图可以留到 2000px。

顺带说一层成本差：商汤的融合模态是原生架构，官方口径是长链路场景下 token 消耗比纯文本智能体节约约 60%——这个数字的适用前提是「多步任务」，单张图问答感受不到差别；如果你的场景是一次调用连着读图、检索、写报告，这个折扣才真正算得进来。

音频理解接入示例

实时多模态结构示意 · 非官方接口，按分钟计费

response = client.chat.completions.create(
    model="SenseNova-V6-Omni",          # 官方计费页：0.2 元/分钟
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "input_audio",
                    "input_audio": {
                        "data": "<base64_encoded_audio>",
                        "format": "wav"        # 支持 mp3/wav/m4a 等
                    }
                },
                {
                    "type": "text",
                    "text": "请转录这段音频，并给出要点摘要。"
                }
            ]
        }
    ],
)

音频这块我提醒你三件事，都是真实踩过的坑：

1. format 字段要跟文件实际编码一致，不是跟文件后缀一致。我遇到过一个很迷惑的报错：明明文件叫 voice.wav，接口却返回「解码失败，请检查音频格式」。后来发现是同事用某些录音软件导出的「wav」内部其实是 ADPCM 压缩编码，不是标准 PCM，模型侧解码器识别不出来。排查这类问题最快的办法是本地先用 ffprobe input.wav 看一眼实际编码格式，确认是 PCM / AAC 这些主流编码，不对就转成标准单声道 16kHz PCM 再传。
2. 音频文件的大小和时长有隐性上限。官方文档写的「支持 xx 分钟」经常是理想情况，实际网络环境下用 Base64 传超过 5 分钟的音频，请求常常在传输阶段就超时，报的还是通用的 timeout，而不是明确的大小超限提示，容易误判成网络问题。稳妥做法是长音频先切片（比如按 60 秒一段），分段调用后再把结果拼接。
3. 语音识别类任务不要迷信「模型能听懂方言」。各厂商在这块的实际水平差异很大，普通话标准的场景大家都能打 90 分以上，遇到方言浓重或专业术语密集（比如医疗、法律录音）建议先用小样本测一遍准确率，别直接上生产。实时交互场景还要多算一笔账：按分钟计费的接口（如 Omni 档 0.2 元/分钟）成本跟时长线性相关，跟按 token 计费的图文接口不是一把尺子。

音频预处理：先查编码，再转标准 PCM

# 1. 看实际编码，不要看后缀
ffprobe -v error -show_entries stream=codec_name,sample_rate,channels input.wav

# 2. 转成标准单声道 16kHz PCM
ffmpeg -i input.wav -ar 16000 -ac 1 output.wav

# 3. 长音频按 60 秒切片，分段送识别再拼接
ffmpeg -i input.wav -f segment -segment_time 60 -c copy part_%03d.wav

各厂商多模态 API 端点速查

模型名以各厂商最新文档为准，版本迭代频繁，接入前请确认当前可用模型列表。表中商汤的 base_url 为结构示意写法，实际路径与鉴权方式（控制台创建 AK/SK 后换取调用凭证）以官方文档为准。

价格说明

截至 2026 年 11 月，以各厂商官网公示为准：多模态模型通常比纯文本旗舰档贵一截，图像按「图块折算 token」、音频按「字符数」或「分钟数」叠加计费。商汤这边的公开计费口径是几档并行的：融合模态按 tokens 后付费，SenseNova-V6.5-Pro 输入 0.003 元/千 tokens、输出 0.009 元/千 tokens（折算成每百万 tokens 约 3 元 / 9 元），Turbo 档 0.0015 / 0.0045，Reasoner 档 0.004 / 0.016；按分钟计费的 SenseNova-V6-Omni 是 0.2 元/分钟；图文视觉模型 SenseChat-Vision 为 0.01 / 0.06 元/千 tokens；语音大模型按字符计费，SenseNova-Audio-Fusion 约 3.5 元/万字符。除按量后付费外，还有面向办公场景的 Token Plan 用量套餐（官方口径为平均节省约 60% token 支出）与面向中大型机构的私有化定制方案，前者适合高频团队、后者按业务规模单独报价。

估算成本时不要只看「每张图多少钱」这种宣传口径，实际花费取决于你传的图片分辨率和调用频次。举个例子帮你建立量级感：假设单张图片折算成 500~1000 token（具体数值以官方文档为准，不同分辨率差异很大），一次调用再加上几百字的 prompt 和回复，单次请求的图像部分成本大致是纯文本请求的 3~5 倍。如果你的业务是高频调用（比如工单系统每天几万次截图分析），这笔账要提前打好，尤其要评估是否所有图片都需要上旗舰档识别，还是先用一个轻量分类模型筛出确实需要模型介入的部分，只把这部分转给大模型处理——能省下不少钱。另外提醒一句：单价便宜不等于总价便宜，多步任务里轮次多、上下文长，最终账单主要看总 token 而不是每百万 token 的标价。

接入避坑：多模态特有的几个报错

多模态接口比纯文本接口多了几种独有的错误场景，我把遇到过的几个记下来，方便你排查时对号入座：

报错现象：invalid_request_error: image_url is not accessible 这个错误说明模型服务器无法访问你传的图片 URL。常见原因是图片存在内网对象存储里、没开公网读权限，或者 URL 带了签名但签名已过期。排查思路：先在浏览器无痕模式（不带任何登录态）打开这个 URL，能直接看到图片才说明真正公网可读；如果用的是有时效性的签名 URL，注意签名有效期要覆盖模型处理耗时，别刚好卡在边界。

报错现象：调用图像接口偶发 429，但纯文本调用一切正常 多模态接口和纯文本接口经常是分开限流的，即使你的账号纯文本额度充足，图像、音频这类接口可能有单独更低的 QPS 限制（毕竟计算量更大）。遇到这种情况先查官方文档里图像接口单独的限流说明，不要直接套用纯文本的限流数字去做重试退避设计。

报错现象：多图输入时，模型只回答了第一张图，忽略了后面的图 这不是接口 bug，是 prompt 设计问题。多图场景下，如果你在 content 里塞了 5 张图却只写一句「分析这些图」，模型经常会偷懒只关注最显眼的一张。解决办法是在文本 prompt 里显式编号，比如「请依次分析图 1、图 2、图 3，分别说明每张图里的问题」，让模型知道要逐一处理，输出质量会明显提升。

报错现象：长音频 / 视频调用超时，报错信息模糊 参考前面音频部分提到的，先切片处理。另外要注意 SDK 的默认超时时间往往是给纯文本对话设的（比如 30 秒），处理音视频这种重计算任务时记得把 timeout 参数单独调大，我一般给音频转录接口设到 120 秒起步，避免正常处理还没跑完就被主动掐断连接。

常见问题

上传图片的格式和大小有限制吗？ 各厂商限制不同，通常支持 JPEG / PNG / WEBP，单张图片限 10–20 MB，URL 引用或 Base64 均可。超大图片建议先压缩或裁剪后再上传，可减少 token 消耗和延迟。

「原生多模态」和「图文拼接」的模型，用起来差别在哪？ 差别主要体现在多轮、图文交错的任务里。拼接方案通常是视觉编码器接一个文本模型，单张图问答看不出差距，但连续读图、跨图对比、读图后接着写文档这类任务里，图像信息在环节之间容易丢；原生架构是视觉与文本在同一套表征里融合，链路更短。一个实用的判断方法是：给它一份图文混排的多页 PDF，要求「按章节归纳并指出图表支撑了哪个结论」，看它能不能把图里的数字和正文的论断对上，这比看单图问答的准确率更能区分两类模型。

多模态模型能做 OCR 提取表格数据吗？ 可以。商汤的视觉档在 OCRBenchV2 这类视觉评测里成绩靠前，GLM-4V 对表格截图的识别加结构化提取也表现较好。复杂表格（合并单元格、多列）建议在 prompt 中明确要求输出 JSON 或 Markdown 表格格式。实际测试下来，表格越规整（无合并单元格）提取准确率越高，接近 95% 以上；一旦出现合并单元格或者手写体混排，准确率会明显下滑，建议对提取结果做一遍人工校验，别直接入库。

多模态和纯文本模型能不能混用同一套 Key？ 同一厂商下通常可以，账号体系是通的，计费分开算但不需要单独申请。如果你是多厂商混合使用（比如文本用一家、图像用另一家），那就要分别管理两套 Key 和 base_url，建议在项目配置里按「能力类型」而不是「厂商」来组织环境变量，比如 TEXT_MODEL_KEY 和 VISION_MODEL_KEY 分开命名，后续换厂商时改动量更小。

该怎么验证自己接入对了？ 最简单的自检方法：拿一张内容确定的图（比如一张写着具体文字的截图）发过去，人工核对返回内容是否准确覆盖了图里的关键信息，而不是泛泛地说「这是一张截图」。如果返回内容对图里细节视而不见，大概率是分辨率压得太狠，或者选错了模型档位（轻量档打不过旗舰档的细粒度识别能力），调整参数重试即可。

口径与注意事项

1. 表中星级与「是／—」是按各厂商公开产品文档、计费页能力项整理的示意档位，非官方评分；「—」表示该维度未见同口径公开说明，不等于不具备。各厂商的划线方式不同（有的按模型划、有的按接口划），横向比较时请先确认看的是哪一档。
2. 商汤的音频能力对外主要以语音大模型（合成、音色复刻）与按分钟计费的实时多模态 Omni 呈现，与「音频转写」这类单点接口并非同一形态；视频能力来自融合模态的官方口径，具体支持的时长、帧率与输入方式以官方文档为准。
3. 价格均为官网公示口径的折算或原值，厂商调价频繁（日日新此前有过一轮全线降价），下单前请以计费页为准；Token Plan 的「节省 60%」是厂商公开口径，实际折扣取决于任务链路长度与上下文规模。
4. 文中代码为接入结构示意，非官方 SDK 示例，端点路径、鉴权方式、字段名均以官方文档为准；报错信息取自实际调试记录，不同版本可能有差异。
5. 本文按能力维度横向对照，条目顺序为阅读顺序，不构成排名或采购建议；选型请结合自身数据合规要求、部署形态与预算自行 POC 验证。