你有没有想过一个很基础、但很少有人认真想过的问题:你随手截了一张图,扔给 AI,它秒懂里面的按钮在哪、Bug 在哪行、表格里哪一列是营收。看起来,它好像真的"看见"了。
但 AI 的底层世界里,压根没有"看见"这回事。Transformer 唯一认识的东西,叫 Token(严格说是 Token 对应的向量,但接下来我们统一按行业惯例叫它 Token)。
文字能拆成 Token,这个大家都习惯了。可一张几百万像素的照片,要怎么变成 Token? 先说一个容易被忽略的误解:模型不会把图片当文字读。一张普通的 1024×1024 PNG 编码成 Base64,大概是 140 万个字符,按文字的分词方式硬拆,能拆出三十几万个 Token——随便一个模型的上下文窗口都会被直接挤爆。但实际处理这张图,各家模型花的 Token 数都是几百到一千出头。这两三个数量级的差距说明,图片走的是完全独立的一条路:不是文字的一种特殊写法,而是被单独拦下来,变成一批和文字 Token 排在一起、但从来不是文字的"视觉 Token"。
而这条独立的路,几家头部 AI 公司走法完全不同,同一张图算出来的 Token 数,能差出好几倍。
图片变成 Token,基本上要经过这些步骤
一张图片，要变成 Transformer 能处理的视觉 Token，大致要经历这样一个过程：
接收 — JPEG、PNG、WebP 等图片数据进入模型
解码 — 图片被还原成像素数据，也就是 RGB 等数值，而不是把 Base64 字符串当成文字去分词；
视觉预处理 — 模型根据自己的视觉架构，对图片进行缩放、裁剪、分块或其他尺寸处理；
视觉编码 — 视觉编码器把像素转换成一组高维向量。模型还可能对这些视觉表示进行压缩、投影或其他处理，最终形成模型所使用的视觉 Token；
融合 — 视觉 Token 与文字 Token 一起进入后续的 Transformer，让模型能够同时处理“你说了什么”和“图片里有什么”。
这里有个很多人会误解的地方:
Token 从来就不等于"一个词"。
Token 只是模型处理信息的基本单位。文字有文字 Token，图片有视觉 Token，音频、视频同理。
也就是说,AI"看图"这件事,本质上不是把画面塞进大脑,而是先把这个世界翻译成一堆数字,再拿这堆数字去推理。
麻烦马上就来了:到底切多细?
切得太粗,细节全丢了。比如一张网页截图,里面有一行很小的字,如果压缩得太狠,模型可能根本看不清那行字写了什么。
但切得太细呢?Token 数量直接爆炸。 而 Transformer 最怕的,恰恰就是输入长度无限膨胀——算力、速度、成本全部跟着遭殃。
所以多模态模型真正要解决的问题,不是:
“怎么让 AI 看见图片?”
而是:
“怎么用尽量少的 Token,把图片里最关键的信息保下来?”
这道选择题,几家公司走出了完全不同的路,下面逐个拆开看。
DeepSeek：切得再细，也不代表“指得准”
在独立的视觉语言模型这条线上，DeepSeek 其实尝试过几种不同的思路。
2024 年发布的 DeepSeek-VL2，采用了一套叫 Dynamic Tiling（动态切分）的方案：模型会根据图片的尺寸和比例，从一组预设分辨率中选择合适的尺寸，再把图片切成多个 384×384 的局部分块，同时保留一张全局缩略图。这样一来，图片的尺寸和内容复杂程度不同，就可以使用不同数量的视觉 Token，而不是所有图片都必须占用固定的 Token 数量。
它背后的想法其实很简单：图片该花多少 Token，不应该是一个固定数字，而应该由图片本身决定。
但视觉理解还有一个容易被忽略的问题：模型看得越清楚，并不意味着它在后续推理中就一定能够“指得准”。
比如让模型统计一张挤满人的照片里到底有多少人，问题可能并不出在它没有看见这些人，而是在连续推理的过程中，“左边那个”“第三排那个”这样的语言指代很容易逐渐漂移，最后甚至无法确定自己前面说的到底是哪一个对象。也就是说，模型解决了“看见什么”的问题，却不一定解决了“我现在说的是谁”的问题。
这也是后来 DeepSeek 的 《Thinking with Visual Primitives》 所关注的问题。论文把这种现象称为 Reference Gap（指代鸿沟），用来区别于更传统的 Perception Gap（感知鸿沟）：前者关注的是模型能不能在推理过程中准确地指向某个视觉对象，而不只是能不能把这个对象看清楚。
它提出的思路也很有意思，与其让模型始终依赖自然语言去描述空间关系，不如直接让“指向某个东西”成为模型推理过程中的一种原语。论文中类似 <ref>、<box> 的特殊标记，可以直接出现在推理过程中，让模型在思考时不仅描述“那里有一个人”，还能够明确指出这个人对应的图像区域。
换句话说，视觉 Token 在这里承担的已经不只是“把图片送进模型”的作用，而开始参与模型的推理过程：模型不仅要知道图像里有什么，还要能够在自己的推理过程中持续指向它正在讨论的那个东西。
这其实代表了视觉 Token 一个很有意思的变化。最初的问题是“怎么把一张巨大的图片压缩成模型能处理的 Token”；再往后，则变成了“这些 Token 能不能携带足够精确的空间信息，让模型在复杂推理中始终知道自己指的是哪里”。
而到了真正面向用户提供服务的产品层面，DeepSeek 的路线又发生了变化。2026 年 8 月的 DeepSeek-V4-Flash-Vision-Exp 曾经采用过“一张图片最多按 384 个 Token 计算”的方案，但这个实验版已经在 9 月 10 日随着 V4.1-Flash 的发布退役。现在的 deepseek-flash 已经把视觉理解直接纳入基础模型，并不再单独提供一个 Vision 实验版。
两年时间里，DeepSeek 在视觉 Token 这件事上换了不止一次思路:
这也意味着，前面那些关于“视觉 Token 应该动态分配多少”“如何让视觉表示参与空间指代”的研究探索，和最终产品采用什么具体的 Token 化方案，并不能简单画上等号。论文解决的是视觉理解可以怎样做得更好，产品则还要考虑推理成本、速度、上下文和工程实现，最终采用的方案可能完全不同。
Claude:图片本质上是一笔"Token 账"
Anthropic 的思路则更加"直接"。
在 Claude 的文档里,图片同样会计入输入 Token,并且给出了一个明确的换算公式:
Token 数 ≈ 图片宽度(px) × 高度(px) ÷ 750
举个例子,一张 1000×1000 像素的图,大概会换算成 1334 个 Token 左右。如果图片长边超过 1568 像素,或者总像素超过约 115 万(大致相当于 1.15 megapixel),Claude 会先按上限自动缩放,再拿去处理,单张图的 Token 数上限大约在 1600 左右。
这个细节其实戳破了一个我们平时容易忽略的事实:
我们习惯说"给模型看一张图",但从模型计算的角度,更准确的说法是:
“往上下文里塞进了一批视觉 Token。”
换句话说,你上传的每一张图,都在实打实地消耗这次对话的"容量预算"。图越大、分辨率越高,占用通常也越多。这也是为什么,同一段对话里,文字聊得好好的,一张高清大图丢进去,可用的上下文一下子就紧张了。
OpenAI:一套"数格子"的算法,还在持续换代
OpenAI 的视觉模型思路上和前面两家没有本质区别:图片最终都要变成模型可处理的视觉表示。 具体怎么切、怎么算,公司自己也在不断换代,但目前最新一代(GPT-5.6 系列,Sol / Terra / Luna 三档)给出的是公开、可核对的公式:
按 32×32 像素的"patch"数格子,数出来的 patch 总数再乘以 1.2 的固定倍数,向上取整,就是最终的图片 Token 数:
Token 数 = ⌈patch 数 × 1.2⌉
一张 1024×1024 的图,刚好数出 32×32=1024 个 patch,乘 1.2 取整是 1229 个 Token。这一代还有个变化:只要用的是 auto 或 original 细节档(GPT-5.5 之后,不设置时默认就是 auto),就不再像早期版本那样给 patch 数设硬上限,只有单张图 patch 数超过 3 万才会被直接拒绝,而不是自动缩放。不过要注意的是,有开发者在官方社区反馈过实测计费和文档公式偶尔对不上,说明这类内部实现细节本身也在持续调整,别把任何一版公式当成永久不变的标准。
这说明一件很重要的事:
“图片 Token"从来不是一个所有模型通用的统一标准——甚至同一家公司,换一代模型就换一套算法。
所以下次再看到"这个模型支持读图"这种说法时,其实信息量非常有限。真正值得追问的是:它到底是怎么处理这张图的?
Google:干脆不把图片当"外挂”
轮到 Google,故事就更激进了一点。Gemini 从设计之初就在强调一个词:原生多模态(native multimodal)——文字、图片、音频、视频,从模型架构层面就活在同一个体系里,而不是先训练一个纯文字模型,再给它"外挂"一个视觉编码器。
具体到计费,Gemini 的图像理解走的是另一套分格逻辑:长和宽都不超过 384 像素的小图,固定算 258 个 Token;更大的图会被切成 768×768 的格子,每格同样算 258 个 Token。 拿前面反复用的 1024×1024 图举例,两个维度都要切成 2 格,一共 4 格,算下来是 4×258=1032 个 Token。
这套"原生多模态"的思路,在 2026 年被 Google 推得更远——5 月的 I/O 大会上发布、6 月底上线的 Gemini Omni Flash,直接把文本、图像、音频、视频都列为原生输入模态,一次提示词里可以同时塞进这四种信息,输出一段带角色一致性的视频。它目前的重心是视频生成,不是常规的读图问答,但方向上和"原生多模态"是一脈相承的:与其让语言模型"学会看图",不如让模型从一开始就活在一个不只有文字的世界里。
同一张图,几家公司算出的 Token 能差近 4 倍
把前面几家的公式放在同一张 1024×1024 的图上,核对一遍数字:
| 模型 | 大致 Token 数 | 算法 |
|---|---|---|
| Claude | ≈ 1398 | 宽 × 高 ÷ 750 |
| OpenAI(GPT-5.6) | ≈ 1229 | 32×32 patch 数 × 1.2,取整 |
| Gemini(图像理解) | ≈ 1032 | 768px 一格,每格 258 |
| DeepSeek V4.1-Flash | 固定 384 | 不看分辨率,统一封顶 |
同一张图,最多和最少能差出将近 4 倍。这不是哪家算错了,而是每家对"多少信息才算够"给出了不同答案——DeepSeek 的产品化路线选择了"先封顶、再够用就好",Claude 和 Gemini 按面积/格数走一套相对线性的账,OpenAI 换代快、公式也跟着换。
图片 Token 到底是什么?
绕了一大圈,可以回到最初的问题了。前面七步管道是共通的骨架,但"视觉编码"这一步,不同公司给出了完全不同的答案:
- 有的强调切块(Patch),再看要不要往下压缩;
- 有的做动态切分,按图片形状"因材施教";
- 有的直接给你算清楚一张图要花多少 Token,按面积或格数计费;
- 有的干脆定个死杠——不管图多大,一律封顶;
- 有的从模型设计层面,取消文字和图像的边界。
所以真正值得关心的问题,已经不是:
“AI 能不能看图?”
这件事现在已经没什么悬念了。真正的问题是:
AI 到底用什么方式,把这个世界压缩成它能理解的形式?
对普通使用者来说,这意味着什么
知道了这些公式,实际能落地的建议其实不多,但都挺实在:
- 大图先降分辨率再传,尤其只是想让模型看个大概的时候——反正模型内部也会缩放,你主动降,省下来的是真金白银和等待时间。
- 平台给了细节档位就按需选,比如 OpenAI 现在的
detail参数(low/high/original/auto),读文档、看大概布局用低档就够,抠小字、认坐标才需要original这种高保真档。 - 换模型不等于换了个"更好的眼睛",同一张截图在 Claude、GPT、Gemini、DeepSeek 上"看"的方式、花的 Token、能保留的细节都不一样,遇到"这模型怎么看漏了"或者"怎么突然更贵了",先想想是不是换了套图像编码逻辑。
- 需要"指哪里说哪里"的任务(比如让 AI 标出界面上某个按钮的坐标),DeepSeek 把"指代"做进 Token 本身的思路值得关注,单纯堆分辨率解决不了指代漂移的问题。
图片,只是一个开始
如果把这个问题继续往前推一步,会发现图片只是多模态世界的一个入口。
文字是一种信息,图片是一种信息,视频是连续的视觉信息,音频是连续的声音信息——而屏幕,同时包含了文字、图像、界面结构和动态变化,是最复杂的那一种。
对于正在被寄予厚望的 AI Agent 来说,这个问题尤其关键。一个想要真正操作电脑的 Agent,不能只理解"打开浏览器"这句指令,它还得知道:
浏览器现在是什么状态?按钮在屏幕的哪个位置?网页加载完了没有?程序是不是报错了?屏幕上这张图到底在表达什么?
于是整条链路会变成:
文字 / 图片 / 音频 / 视频 / 屏幕 / 文档
↓
各种视觉 / 语言 / 音频表示
↓
多模态模型
↓
理解
↓
行动
到了这一步,视觉 Token 早就不只是一个模型内部的技术细节了——它正在变成 AI 理解真实世界的一种基础接口。
写在最后
我们过去很长一段时间,都在教 AI"读文字"。
而现在真正在发生的事情完全不同:我们在想办法,把整个世界翻译成 AI 能处理的 Token。
一张照片是怎么变成 Token 的?一段视频呢?一段声音呢?一整个屏幕呢?甚至,一个真实的物理世界呢?
这可能才是多模态这件事,真正有意思的地方。
因为下一代 AI 要回答的问题,可能已经不再是:
“它能读多少文字?”
而是:
“它究竟能理解多少种形式的现实?”
📬 关注我获取更多资讯
