国产多模态大模型对比：图文、音频、视频能力全盘点
上周有个做工单系统的朋友问我：客服上传一张设备报错截图，能不能让模型直接读出屏幕上的错误码，不用人工誊抄？这就是最典型的多模态需求——不是想让模型”看懂艺术”，而是想省掉人工转录这一步。我把手头几个项目里用过的通义、文心、豆包、Kimi 挨个测了一遍，把真实能打的能力和接入时踩过的坑整理在这篇里。
多模态大模型可同时理解图像、音频、视频与文本，是 AI 应用从”文字助手”升级到”感知助手”的关键能力。国产厂商中，通义千问多模态矩阵最完整，文心、豆包、Kimi 各有侧重。本文横向梳理各厂商多模态能力，附接入代码示例，以及我自己踩过的几个坑。
国产多模态模型能力矩阵
| 厂商/模型 | 图像理解 | 音频/语音 | 视频理解 | 文档解析（PDF） | OCR | API 开放 |
|---|---|---|---|---|---|---|
| 通义千问 Qwen-VL | ★★★★★ | — | — | 是 | 是 | 是 |
| 通义千问 Qwen-Audio | — | ★★★★★ | — | — | — | 是 |
| 通义千问 Qwen-VL-Max（视频） | ★★★★ | — | ★★★★ | 是 | 是 | 是（内测） |
| 文心 ERNIE 4.5 | ★★★★ | ★★★ | — | 是 | 是 | 是 |
| 豆包 Doubao-VL | ★★★★ | ★★★ | — | 是 | 是 | 是 |
| Kimi（moonshot-v1） | ★★★★ | — | — | ★★★★★ | 是 | 是 |
| GLM-4V | ★★★★ | — | — | 是 | 是 | 是 |
总结：通义千问覆盖图/文/音/视频四模态，矩阵最全；Kimi 专注图文+PDF 文档理解；文心和豆包在图文+语音方向较成熟；GLM-4V 工具调用配合图文理解适合 Agent 场景。
这张表看着简单，但选型的关键不在”星星多不多”，而在你的场景是”识别”还是”理解”。识别是认出图里有什么字、有什么物体，几乎所有模型都能做；理解是要结合上下文回答”这张图说明了什么问题”，这才拉开差距。比如同样一张服务器监控截图，识别层面大家都能读出数字，但只有真正做过多模态指令微调的模型（Qwen-VL-Max、GLM-4V）能答出”CPU 使用率异常，可能是某进程死循环”这种带推理的结论。如果你的需求只是 OCR 提取文字，不需要上旗舰档，普通档甚至专门的 OCR 接口更便宜也更快；如果需要模型基于图像内容做判断或生成建议，才值得用视觉旗舰模型。
图像理解接入示例（通义千问 Qwen-VL）
from openai import OpenAI
client = OpenAI(
api_key="sk-xxxxxxxxxxxxxxxx", # 阿里云 DashScope API Key
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)
response = client.chat.completions.create(
model="qwen-vl-max",
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。两种方式各有代价，我列个对比方便你选：
| 方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| URL 引用 | 请求体小、不占本地内存、便于批量处理 | 图片必须公网可访问，内网图片要先上传到对象存储 | 图片本来就有公网地址（如用户上传到 OSS 的头像、商品图） |
| Base64 内嵌 | 不依赖外部可访问性，本地文件直接转 | 请求体膨胀（体积约放大 33%），大图容易撞 payload 上限 | 本地临时文件、截图、不方便公网暴露的敏感图片 |
实践中我踩过一个坑：把一张 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。
音频理解接入示例（通义千问 Qwen-Audio）
response = client.chat.completions.create(
model="qwen-audio-turbo",
messages=[
{
"role": "user",
"content": [
{
"type": "input_audio",
"input_audio": {
"data": "<base64_encoded_audio>",
"format": "wav" # 支持 mp3/wav/m4a 等
}
},
{
"type": "text",
"text": "请转录并翻译这段音频内容。"
}
]
}
],
)
音频这块我提醒你三件事，都是真实踩过的坑：
第一，format 字段一定要跟文件实际编码一致，不是跟文件后缀一致。我遇到过一个诡异的报错：明明文件叫 voice.wav，接口却返回 解码失败，请检查音频格式。后来发现是同事用某些录音软件导出的”wav”其实内部是 ADPCM 压缩编码，不是标准 PCM，模型侧解码器识别不出来。排查这类问题最快的办法是本地先用 ffprobe input.wav 看一眼实际编码格式，确认是 PCM/AAC 这些主流编码，不对就用 ffmpeg -i input.wav -ar 16000 -ac 1 output.wav 转成标准单声道 16kHz PCM 再传。
第二，音频文件大小和时长有隐性上限，官方文档写的”支持 xx 分钟”经常是理想情况，实际网络环境下如果你用 Base64 传超过 5 分钟的音频，请求经常会在传输阶段就超时，报的还是通用的 timeout 而不是明确的大小超限提示，容易误判成网络问题。稳妥做法是长音频先切片（比如按 60 秒一段），分段调用后再把转录结果拼接，顺带还能做流式展示，用户体验也更好。
第三，语音识别类任务不要迷信”模型能听懂方言/口音”，各厂商在这块的实际水平差异很大，普通话标准的场景大家都能打 90 分以上，遇到方言浓重或专业术语密集（比如医疗、法律录音）建议先用小样本测一遍准确率，别直接上生产。
各厂商多模态 API 端点速查
| 厂商 | base_url | 图像模型名 |
|---|---|---|
| 通义千问 | https://dashscope.aliyuncs.com/compatible-mode/v1 | qwen-vl-max / qwen-vl-plus |
| 文心一言 | https://qianfan.baidubce.com/v2 | ernie-4.5-vl-8k（参考官方） |
| 豆包 | https://ark.cn-beijing.volces.com/api/v3 | doubao-vision-pro-32k（参考官方） |
| Kimi | https://api.moonshot.cn/v1 | moonshot-v1-8k（含图文） |
| 智谱 GLM | https://open.bigmodel.cn/api/paas/v4 | glm-4v |
模型名以各厂商最新文档为准，版本迭代频繁，接入前请确认当前可用模型列表。
价格说明
截至 2026-06，以官方公示为准：多模态模型通常比纯文本旗舰档贵 10–30%，图像/音频按”张数”或”秒数”叠加文本 token 计费；视频理解（帧抽取）成本更高，建议按需开启。可用 价格对比表 横向比较。
估算成本时不要只看”每张图多少钱”这种官方宣传口径，实际花费取决于你传的图片分辨率和调用频次。举个例子帮你建立量级感：假设单张图片折算成 5001000 token（具体数值以官方文档为准，不同分辨率差异很大），一次调用再加上几百字的 prompt 和回复，单次请求的图像部分成本大致是纯文本请求的 35 倍。如果你的业务是高频调用（比如客服系统每天几万次截图分析），这笔账要提前打好，尤其要评估是否所有图片都需要上旗舰模型识别，还是可以先用一个轻量分类模型筛出确实需要模型介入的部分，只把这部分转给大模型处理——能省下不少钱。
接入避坑：多模态特有的几个报错
多模态接口比纯文本接口多了几种独有的错误场景，我把遇到过的几个记下来，方便你排查时对号入座：
报错现象：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 消耗和延迟。
视频理解目前国产哪家最成熟？ 通义千问 Qwen-VL-Max 系列支持视频帧理解，但整体视频模态接口仍在内测迭代；短视频（<5 分钟）理解可用，超长视频建议先抽关键帧再分析。
多模态模型能做 OCR 提取表格数据吗？ 可以，Qwen-VL 和 GLM-4V 对表格截图的 OCR + 结构化提取表现较好。复杂表格（合并单元格、多列）建议在 Prompt 中明确要求输出 JSON 或 Markdown 表格格式。实际测试下来，表格越规整（无合并单元格）提取准确率越高，接近 95% 以上；一旦出现合并单元格或者手写体混排，准确率会明显下滑，建议对提取结果做一遍人工校验环节，别直接入库。
多模态和纯文本模型能不能混用同一套 Key？
同一厂商下通常可以，比如通义千问的 DashScope Key 既能调 qwen-max 纯文本模型，也能调 qwen-vl-max 图像模型，计费分开算但账号体系是通的，不需要单独申请。如果你是多厂商混合使用（比如文本用 DeepSeek、图像用通义），那就得分别管理两套 Key 和 base_url，建议在项目配置里按”能力类型”而不是”厂商”来组织环境变量，比如 TEXT_MODEL_KEY 和 VISION_MODEL_KEY 分开命名，后续换厂商时改动量更小。
该怎么验证自己接入对了？ 最简单的自检方法：拿一张内容确定的图（比如一张写着具体文字的截图）发过去，人工核对返回内容是否准确覆盖了图里的关键信息，而不是泛泛地说”这是一张截图”。如果返回内容对图里细节视而不见，大概率是分辨率压得太狠，或者选错了模型档位（普通档打不过旗舰档的细粒度识别能力），调整参数重试即可。
相关阅读：国产大模型 API 全景指南 · 国产长文本模型对比 · 通义千问 API Key 获取
分类导航：国产模型专题
实用工具：价格对比表