之前写过一张图片是怎么变成 AI Token 的:一张 JPEG 或 PNG,并不是直接被塞进 Transformer,而是先经过视觉编码,变成一组模型能计算的数字表示,也就是视觉 Token。
那视频呢?一分钟的视频,可能有上千帧画面,还有声音、字幕,还有最重要的东西:时间。难道模型真的要把这一分钟里的每一帧都完整变成 Token,再一股脑塞进去?
我把 OpenAI、Google、Anthropic 和 DeepSeek 目前公开的官方文档放在一起看,结果发现,这次和图片完全不是一个格局。
图片的处理,四家的具体视觉编码方式虽然不同,但最终都落到了一个相近的 Token 量级。到了视频,四家根本不在同一条起跑线上:只有 Google 已经把"直接输入视频"做成了完整的官方 API 能力;OpenAI、Anthropic 和 DeepSeek 虽然都具备图像理解能力,但目前公开的 API 都没有把视频作为独立的原生输入模态。要让它们分析视频,基本都需要先在模型外部把视频转换成图片帧,再交给视觉模型处理。
这里先说明一个容易混淆的地方:“Agent 能读取视频"和"模型原生支持视频输入"不是一回事。Codex、Claude Code 等工具现在确实可以处理视频,但它们背后可能经过了文件解析、抽帧、转码或其他工具链;本文讨论的是模型 API 本身到底把什么交给了模型。
说明:本文基于公开文档、官方博客与开源社区信息核实整理,重点解释设计思路和现状差异;具体接口能力、计费规则可能随时间推移调整,请以你使用时各家的官方文档为准。
视频,其实是在图片上多了一个维度:时间
先看一个具体场景。假设你给模型一段 1 分钟的视频:
00:00 一个人走进厨房
00:02 打开冰箱
00:04 拿出鸡蛋
00:06 把鸡蛋打进碗里
00:08 打开炉子
00:10 开始煎蛋
如果这是一张图片,它描述的只是一个瞬间,比如"一个人站在厨房里,桌上放着几个鸡蛋”。模型把这张图片转换成视觉 Token,再和文字一起交给 Transformer,事情就结束了。
但视频不是一个瞬间,而是一连串不断变化的画面。模型真正需要理解的,已经不再是"这一帧里有什么",关键变成了"前后发生了什么"。一个人拿着鸡蛋,和鸡蛋被打进碗里,是两张完全不同的图片,只有把它们按时间顺序排起来,模型才能理解"这个人在煎蛋"。
这就是视频相比图片,真正增加的核心维度:时间。
那时间具体是怎么进到模型里的?靠的是两件事:一是抽样本身,决定"多久留一帧、多久留一段声音",这个采样节奏就是时间分辨率;二是位置信息,每一帧、每一段声音要么被贴上具体的时间戳(模型能精确知道"这是第几秒"),要么只是按先后顺序排列(模型只能推断相对前后关系,不一定知道间隔多久)。时间通常不会单独形成一条像"画面"“声音"那样独立的输入模态,而是通过采样节奏和位置编码的方式嵌入到整个 token 序列里。具体是走时间戳这条精确路线,还是只靠顺序做粗略推断,取决于模型架构的设计。 视频的处理流程大致是这样:
视频文件进来后,画面和声音是两条并行处理的支线,不是谁等谁:画面这条先抽帧采样(决定每秒留几帧,这是图片完全不需要考虑的新环节),抽出一批帧、每一帧当成一张图片走视觉编码,再汇总成这段视频的视觉 Token;音频这条单独处理(可能编码成 Token,也可能转录成文字,甚至被直接忽略,这一点在四家之间的差异并不比画面部分小)。两条支线各自出结果后,才会和文字 Token 一起融合成同一个多模态上下文,交给模型推理。
从理解视频 Token 的角度,可以先把它粗略理解成:在图片 Token 化的基础上,再解决时间怎么采样、怎么排序的问题。理解视频 Token,绕不开先理解图片 Token。如果你还没看过图片那篇,建议先读完那篇再往下看。
视频拆成很多张图片,但 Token 和细节要二选一
顺着煎蛋这个例子往下想,最直接的处理方式就是抽帧:按一定频率取出代表性画面,每一张再按上一篇讲过的方法转换成视觉 Token,这也是目前多数"视频理解"方案最基本的底层思路。
问题马上出现:视频实在太长了。 1 分钟的视频,哪怕每秒只取一帧,也有 60 张图;每张图再产生几百个视觉 Token,一段视频很快就能堆到几万 Token。抽帧频率一旦提高,Token 数量还会继续膨胀。
而抽帧太稀也有代价:如果 2 秒才抽一帧,“打开冰箱"这个动作如果恰好卡在两次抽样之间,模型可能压根没看见冰箱门开过,只看到"人在冰箱前"和"人拿着鸡蛋"两张图,中间发生了什么,全靠猜。
所以视频理解真正要解决的,是这样一个问题:
怎么用有限的 Token,把一段视频里"发生了什么变化"尽可能完整地留住?
这道题,四家公司给出的答案,分野很大。
Gemini:先把视频变成时空信息,再让模型自己决定看哪里
先区分两个概念:Gemini 的原生多模态能力,和它处理视频时采用的具体方式,并不是一回事。
Google 从第一代 Gemini 开始,就把文本、图像、音频和视频作为同一个多模态模型体系的一部分。也就是说,视频并不是先经过一个独立的视频理解模型,再转换成文字交给语言模型;但当一段视频真正通过 API 进入 Gemini 时,模型仍然需要面对一个很现实的问题:这么长的一段连续画面,到底应该以什么方式送进模型?
默认模式:固定节奏采样
Gemini 可以直接接收 MP4、MOV、WebM 等常见视频格式,开发者不需要自己写代码去抽帧、单独处理音频。默认的 static 模式,会按照固定的采样规则从视频中提取画面帧,同时单独处理视频里的音频轨道。
最直观地理解,就是把一段视频变成这样一串带有时间位置的视觉信息:
00:00 一个人走进厨房
00:01 打开冰箱
00:02 拿出鸡蛋
00:03 把鸡蛋打进碗里
00:04 打开炉子
...
如果视频是一分钟,按照每秒一帧的采样方式,就意味着模型至少要处理 60 个时间点的画面;视频越长、每帧的视觉信息越多,需要处理的 Token 也就越多。
这其实已经和"把视频当成一张图片"完全不同了:模型面对的不只是画面里有什么,还包括这些画面在时间上的排列。
但 static 模式仍然有一个明显的限制:采样规则是预先确定的。
假设一段两个小时的视频里,只有第 47 分钟出现了一件真正重要的事情,而你想问模型:“这个人第一次打开冰箱是什么时候?”
如果整段视频都按照固定频率采样,模型需要先处理大量和问题无关的画面;如果采样得太稀,又可能恰好把那个关键瞬间跳过去。
于是问题就变成了:能不能别让模型从头到尾平均地看,而是让它自己决定哪里值得仔细看?
更进一步:让模型自己决定看哪里
2026 年 9 月,Google 又公布了 Agentic Video Understanding(主动视频理解)。它没有改变 Gemini 的多模态底层架构,改变的是视频进入模型之后的处理方式。
开启 processing: "agentic" 后,模型可以先对长视频进行粗略浏览,然后根据当前问题主动定位可能相关的时间段,再进一步获取这些片段的画面、音频或字幕信息;如果某个瞬间值得仔细检查,还可以提高这一段的采样密度和视觉细节。
于是,原来的流程更像:
整段视频 → 固定抽帧 → 全部交给模型 → 模型寻找答案
而 Agentic 模式变成:
整段视频 → 粗略浏览 → 定位相关片段 → 精细查看 → 回答问题
Google 在 LongVideoBench 的一个案例中给出的数据显示,Agentic 模式把一次查询的 Token 消耗从约 39.8 万降低到约 4.8 万,减少约 88%,同时该案例的准确率从 87.5% 提升到了 88.5%。不过这是官方给出的具体测试案例,并不意味着所有视频都会获得同样幅度的收益。
官方文档:Video understanding
官方文档:Introducing agentic video in Gemini
省了多少 Token 还是次要的,这件事真正有意思的地方在于一个方向上的转变:以前是想办法让模型"吃下整个视频”,现在开始变成让模型自己决定"应该看哪里”。Gemini 从设计第一天起就把图片、文字、音频、视频看作同一个多模态体系的一部分,这条原生多模态路线,是它现在能在视频理解上继续往前走一步的基础。
OpenAI:方向是把所有模态放进同一个模型里一起学,但产品接口还没跟上
OpenAI 的多模态路线,其实经历过一次明显的转变。
早期的 GPT 系列主要还是以语言模型为核心,再逐步增加视觉、语音等能力;到了 GPT-4o,这条路线才明显转向"原生多模态"。OpenAI 将 GPT-4o 定义为一个端到端训练的 omni 模型,让文字、图像、声音等输入可以由同一个神经网络处理,而不是先经过一套独立的模态转换管线。
这和 Google 从 Gemini 第一代开始强调的路线有所不同。Google 当时就明确把 Gemini 定义为 “从底层开始就是多模态的”,并把文本、音频、图像和视频放进同一个模型体系。
这种能力的价值,举个例子就很直观:视频里一个杯子从桌上掉下来,画面显示"杯子在下落",同时声音传来"啪"的一声,下一帧杯子已经碎了。模型最终理解的是"杯子掉下来,摔碎了",不是画面、声音、动作三条孤立的信息。统一模型可以直接学到这种画面和声音之间的关联,不需要另外拼接。
不过这里要说清楚一件容易被混淆的事:模型架构层面具备原生多模态能力,不等于产品 API 会直接把一个 MP4 文件当成某种"视频 Token"接收进去。目前 OpenAI 的 Responses API 不接受任何视频格式作为文件输入:支持的文件类型里没有 mp4、mov,只有 PDF、文档、代码文本这些。GitHub 上 openai-node 仓库里有一条官方仓库的功能请求 issue,明确要求"给 Responses API 加原生视频输入,对齐 Gemini",目前仍未实现。
官方 Cookbook 里有一篇《用 GPT 的视觉能力处理和讲解视频》,给出的做法是:用 OpenCV 把视频逐帧提取出来,按固定间隔取一部分关键帧(示例代码里是每 25 帧取 1 帧),把这批帧当成一组图片,直接走图片的 32×32 patch Token 公式。抽帧间隔怎么定、留多少帧、总共花多少 Token,全部交给开发者自己判断,官方没有给出"处理一分钟视频大概多少 Token"这样的参考数字。
这篇教程虽然还停留在 GPT-4.1-mini,但截至 GPT-5.6,OpenAI 也没有发布过更新的视频处理教程。视频这条产品线,确实没跟上模型迭代的节奏。
更值得注意的是,这篇官方教程完全没有处理音频轨道,OpenCV 抽出来的只是画面帧,声音直接被丢在了一边。教程原文写得很直接:“GPT-4.1-mini doesn’t take videos as input directly, we can use vision … to describe the static frames of a whole video at once”,通篇没有出现 Whisper 或任何语音转录环节。照着这份官方方案做出来的"视频理解",本质上是一个只会看、不会听的模型。如果煎蛋视频里有人在旁白讲解步骤,这套方案会完全漏掉这部分信息。要接上音频,得开发者自己另外调用语音转文字接口,把转录文本当成普通文字 Token 拼进 Prompt,这已经完全在官方教程范围之外了。
官方文档:Processing and narrating a video with GPT's visual capabilities
Claude:模型没有直接处理视频,工程上换一种办法
Anthropic 的 Messages API 里没有 video 这种 content block,只有 image 和 document 两类输入;连 GIF 动图都只取第一帧当静态图处理,官方文档原文写的是"Animations are unsupported, and only the first frame is used"。从 API 层面看,Claude 目前没有视频专用的 Token 规则。
但这不代表 Claude 完全没法参与视频理解,只是这件事被挪到了工程层面,用另一种办法拼出来:抽取关键帧、提取字幕、转录音频,再把这些证据组织成一份多模态上下文,交给 Claude 推理。比如煎蛋这段视频,可以先被处理成这样再喂给模型:
00:04 [画面:手伸向冰箱把手]
00:05 [画面:冰箱门打开]
00:06 "先把鸡蛋从冷藏室拿出来"
00:08 [画面:鸡蛋被打进碗里]
模型不需要直接接收原始视频文件,只需要拿到足够好的证据,就能在这些画面和文字之间做跨时间的推理。
音频在这条路径里不是被当成单独一种"视频 Token"计费,而是先被 Whisper 转成普通文字,再当成文字 Token 混进同一轮对话。比起 OpenAI 官方教程完全跳过音频,这至少把声音信息留住了,只是换了个身份,变成了文字。
目前官方并没有提供一套"把视频直接交给 Claude 分析"的 API 教程;反而是社区已经出现了不少补齐这条链路的插件和工具。它们做的事情其实很朴素:先用 FFmpeg、Whisper 等工具把视频拆成画面和文字,再把这些结果交给 Claude。相关项目作者自己的说法也很直白:没有解锁什么新模态,只是把 Claude 已有的视觉和文本能力,喂给它一份"形状正确"的数据。
所以这里的关键区别是:这是客户端/插件层面拼出来的工作流,不是 Anthropic 在 API 层面新增的原生视频输入能力。
官方文档:Vision · Claude Code Changelog
“让模型看视频"和"让模型理解视频”,不是同一个问题:前者是媒体处理问题,后者才是模型推理问题。
DeepSeek:视觉能力已经升级,但视频还没成为 API 输入
DeepSeek 在 2026 年 9 月发布的 V4.1-Flash 已经明确采用 native multimodal visual understanding,图片可以直接作为模型输入。
但视频是另一回事。目前 DeepSeek 官方 API 文档仍然只提供图片输入,没有 video 这种原生输入类型;Responses API 也明确不支持 file inputs。
所以如果要让 DeepSeek 理解一段视频,仍然需要先在模型外部把视频拆成图片帧,再把这些图片交给模型。
模型的多模态能力已经升级,不代表 API 的输入模态也跟着扩展到了视频。
官方文档:Vision
视频理解真正难的地方,其实是"时间"
回过头看一张图片和一段视频的区别:
图片: 空间 → 视觉 Token → 模型 → 描述
视频: 空间 + 时间 + 声音 + 文字 → 大量多模态表示 → 模型 → 事件与关系
视频不是简单的"图片 × 很多张",它多了一个关键的东西:变化。模型必须知道什么东西出现了、消失了、移动了,谁先做了什么,后面又发生了什么,甚至还要把声音、字幕和画面对应起来。比如:
00:10 人拿起手机
00:12 手机响了
00:13 人开始说话
00:15 屏幕出现一条消息
真正理解这段视频,需要模型把画面、动作、声音、时间这四种信息联系到一起,而不是分别识别出"手机"“响铃声"“说话"这几个孤立标签。
把四家摆在一起看,与其说是"四种方案”,不如说是同一件事上的四个不同阶段:
Gemini 已经把原生视频理解做成官方能力,现在又往"主动决定看哪里"迈了一步;OpenAI 在模型架构层面追求统一多模态,但视频这条产品线目前还停留在"官方教你自己抽帧”;Claude 官方还没表态,社区已经拼出了能用的方案;DeepSeek 已经把原生视觉理解推进到图片输入,但视频还没有成为公开 API 的原生输入模态。
这和图片那篇的结论正好相反。图片那篇的结论是"算法路线差别很大,但落地的 Token 数其实是同一个量级":四家殊途同归。视频这条线,目前压根没有"殊途同归",只有一条已经走通、并且还在往前走的路,和三条程度不同的、临时拼凑出来的替代路径。
下一步:从"看更多",到"主动去看"
最早的思路很简单:把更多视频转换成更多 Token,于是模型需要更大的上下文、更强的算力、更高效的压缩。但视频越来越长,这条路迟早会撞上成本的天花板。
Gemini 的 agentic video understanding 提供了另一种答案:为什么一定要让模型把整个视频都看一遍?人看两个小时的视频,也不会把每一帧都认真看一遍。如果有人问"这个视频里什么时候第一次出现汽车",我们会先快速浏览时间轴,找到可能的位置,再回头仔细看。让模型学会这套"先定位、再精读"的策略,某种程度上是在让它更接近人类理解现实世界的方式:不是把看到的一切都记下来,而是在需要的时候,知道去哪里看。
图片那篇最后说,四家公司回答的其实是同一个问题:怎么用尽量少的 Token,把这个世界看清楚。视频理解正在出现一个新的分水岭:过去的问题是怎么把更多视频压缩进模型,现在的问题开始变成:模型能不能自己决定,什么时候该看、看多细、该听什么。
关于
关注我获取更多资讯
