Gemini 3.1 Pro 传了一小时视频进去，结果有点意外
Google 反复说 Gemini 3.1 Pro 是"原生多模态"模型——图片、音频、视频、PDF 都能一起处理。这个说法从 Gemini 1.0 就开始用了，到 Gemini 3.1 Pro 已经是第四代了。
但 Gemini 3.1 Pro 的多模态能力具体能处理到什么程度？上限在哪？哪些类型的多模态任务做得好、哪些做不好？这些信息散落在 Vertex AI 技术文档和 Model Card 的不同章节里。我花时间整理了一份 Gemini 3.1 Pro 比较完整的多模态能力边界图。
视频处理：有声和无声上限不同
这是最容易踩坑的一个区别。
无音频视频： 最长约 1 小时。每个 prompt 最多 10 个视频。 带音频视频： 最长约 45 分钟。
为什么带音频的视频上限更短？因为音频流额外占 token。视频本身按帧采样（默认每帧 70 个 token），音频流还要再算一份。同样长度的视频，带音频的 token 消耗大约是无音频版本的 1.5 到 2 倍。100 万 token 的上下文窗口总量不变，音频多吃了 token，视频长度就得缩短。
如果你有一段 55 分钟的带声会议录屏要分析，有两个绕过方案：一是先把音频剥离再传视频（这样可以用 1 小时的上限），二是把视频分成两段分别传。
视频格式支持： MP4、WebM、QuickTime（MOV）、FLV、MPEG、WMV、3GPP。基本上主流格式都覆盖了。
帧采样机制： 视频不是逐帧分析的，而是按一定间隔抽帧。默认每帧按 70 个 token 计算。对于一段 30fps 的 10 分钟视频（共 18000 帧），模型实际看到的帧数远少于 18000。具体抽帧间隔 Google 没有在文档里公布，但从 token 消耗来看大概是每 1-2 秒抽一帧。
这意味着快速变化的场景（比如体育比赛的关键瞬间、监控视频里一闪而过的人影）可能被抽帧漏掉。需要精确到帧级别的分析任务，Gemini 3.1 Pro 目前做不了。
音频处理：8.4 小时
音频的上限比视频宽得多：每个 prompt 最长约 8.4 小时（或 100 万 token）。但有一个限制——每个 prompt 只能放一个音频文件。如果你需要分析多段音频，要么合并成一个文件，要么分开发送多次请求。
支持格式： AAC、FLAC、MP3、M4A、MPEG、OGG、PCM、WAV、WebM。
能力范围： 官方文档明确列了三项——音频摘要、转录、翻译。也就是说模型不只能"听到"音频内容，还能直接做语音转文字。对于会议录音、播客内容、电话录音的批量处理场景比较有用。
一个 8.4 小时音频的处理成本：按 100 万 token 输入计算是 $2，加上推理和输出可能到 $2.5-3。和专门的语音转写服务（比如 Google Speech-to-Text 或 Whisper API）比，价格差不多，但 Gemini 3.1 Pro 可以在转写的同时做摘要和分析，这是纯转写服务做不到的。
图片处理：3000 张
每个 prompt 最多 3000 张图片。默认每张按 1120 个 token 计算。
上传限制：
- 通过 API 或 AI Studio 控制台直接上传：每张最大 7MB
- 通过 Google Cloud Storage 传入：每张最大 30MB
格式： PNG、JPEG、WebP、HEIC、HEIF。
3000 张图片 × 1120 token/张 = 336 万 token，超过了 100 万 token 的上下文窗口。所以实际能塞进去的图片数量取决于你的其他输入（prompt 文本、system prompt 等）占了多少 token。如果只传图片不带文字，大约能放 890 张左右。
一个常见的使用场景是电商图片分类——传入大量商品图，让模型做分类或者生成描述。这类任务如果图片量很大，建议分批处理，每批控制在 500 张以内，避免逼近 token 上限后影响理解质量。
PDF 处理：3000 页
PDF 最多 3000 页，每个 prompt 最多 3000 个 PDF 文件。每页默认 560 token。
文件大小限制：
- 直接上传：每个文件 7MB
- API 或 Cloud Storage：每个文件 50MB
OCR 的问题： 默认不做 OCR。这意味着如果你传的是扫描版 PDF（图片形式的，不是可选择文字的），模型会把每一页当成图片来"看"，而不是把文字提取出来"读"。扫描件的处理效果比文字版 PDF 差一截，特别是扫描质量不好、或者有手写内容的情况下。
如果你的 PDF 是扫描件，建议先用 OCR 工具（比如 Tesseract 或者 Google Cloud Vision OCR）预处理成文字版，再传给 Gemini。
"原生多模态"到底意味着什么
这个概念被反复提到但很少被解释清楚。技术上的区别是这样的：
拼接式多模态（大多数竞品的做法）： 视觉部分有一个单独的视觉编码器（比如 ViT），音频部分有一个单独的音频编码器（比如 Whisper 的编码器），各个编码器把自己模态的内容处理成 embedding，再拼接到文本 transformer 的输入序列里。不同模态之间的"理解"是在 transformer 层面完成的，而编码阶段是独立的。
原生多模态（Gemini 的做法）： 所有模态直接进入同一个 transformer，不经过独立的编码器。这样做的好处是模态之间的交叉理解可以在更早的层级发生。
实际区别在哪？举一个例子：你传一段会议视频（带音频），同时传入会议议程的文字版。在原生多模态架构下，模型可以把"视频里第 23 分钟有人站起来在白板上画了一个图"和"议程里第三项讨论架构设计"关联起来。拼接式架构不是做不到这件事，但关联的精度可能不如原生架构。
不过这些是理论上的优势。实际表现还是得看基准数据。
Gemini 3.1 Pro 多模态基准数据：理解能力并没有进步
这是我觉得这次升级里最值得说的一个点。
MMMU-Pro（多模态理解推理基准）：Gemini 3.1 Pro 80.5%，Gemini 3 Pro 81.0%。
下降了 0.5%。虽然在统计误差范围内，但至少说明 3.1 Pro 这次升级没有在多模态理解上做任何改进。升级的重心全在文字推理（ARC-AGI-2 从 31.1% 跳到 77.1%）。
和竞品比：GPT-5.2 79.5%，Claude Opus 4.6 73.9%。Gemini 3.1 Pro 在多模态理解上仍然领先，但这个领先是继承自 Gemini 3 Pro 的，不是 3.1 Pro 新带来的。
实际能做什么、做不了什么
能做的：
会议视频分析——传一段 45 分钟的带音频会议录屏，让模型提取关键决策、待办事项、行动项。不用事先做转写，直接传视频。对于没有会议纪要系统的团队来说很实用。
技术文档批量处理——一次传几百页包含图表和公式的 PDF，做跨文档摘要或数据提取。对需要处理大量技术报告的研究人员和分析师有帮助。
多格式混合分析——同时传文字说明、架构图截图和录制的讲解音频，让模型做综合分析。比分三次传入再手动拼合高效。
产品图片分类和描述——批量传入商品图片，生成分类标签和文字描述。电商场景常见。
做不了或做不好的：
逐帧视频分析——抽帧机制会漏掉帧间的快速变化。安防监控、体育赛事回放这类需要精确到帧的任务不适合。
视频时间戳精确定位——"视频第 14 分 32 秒说了什么"这类问题，模型可能给出近似答案但不保证精确。
扫描件 PDF 的精确文字提取——默认不做 OCR，扫描质量差的文档效果有限。
大批量图片的精细分析——超过 500-600 张图片时，接近 token 上限，模型对后面图片的理解质量可能下降（类似"迷失在中间"的问题，只不过是多模态版本）。
参考资料
- Gemini 3.1 Pro Vertex AI 技术文档（视频/音频/图片/PDF 规格），Google Cloud：https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/3-1-pro
- Gemini 3.1 Pro Model Card（MMMU-Pro 数据），Google DeepMind：https://deepmind.google/models/model-cards/gemini-3-1-pro/
- Gemini 多模态能力示例，Google Developers Blog：https://developers.googleblog.com/en/7-examples-of-geminis-multimodal-capabilities-in-action
- Gemini 3.1 Pro 功能与基准分析，CometAPI：https://www.cometapi.com/gemini-3-1-pro-feature-benchmark-performance-and-price-analysis/
- How to Use Gemini 3.1 Pro API（多模态示例），CometAPI：https://www.cometapi.com/how-to-use-gemini-3-1-pro-api/