你有没有想过一个很基础、但很少有人认真想过的问题:你随手截了一张图,扔给 AI,它秒懂里面的按钮在哪、Bug 在哪行、表格里哪一列是营收。看起来,它好像真的"看见"了。
但 AI 的底层世界里,压根没有"看见"这回事。Transformer 唯一认识的东西,叫 Token。
文字能拆成 Token,这个大家都习惯了。可一张几百万像素的照片,要怎么变成 Token? 先说一个容易被忽略的误解:模型不会把图片当文字读。一张普通的 1024×1024 PNG 编码成 Base64,大概是 140 万个字符,按文字的分词方式硬拆,能拆出三十几万个 Token——随便一个模型的上下文窗口都会被直接挤爆。
但实际处理这张图,各家模型花的 Token 数都是几百到一千出头。这两三个数量级的差距说明,图片走的是完全独立的一条路:不是文字的一种特殊写法,而是被单独拦下来,变成一批和文字 Token 排在一起、不是文字的"视觉 Token"。
真正值得记住的,不是某个模型今天怎么计费,而是这个事实:
视觉 Token 的本质,不是"图片被当成字拆开了",而是"图像被压缩成一组可供 Transformer 计算的高维表示"。
这也是为什么不同模型会用不同方法:按面积、按 patch、按格子、按上限、按统一多模态主干。它们虽然实现不同,但目标相同——在尽量少的 Token 中,保住最关键的信息。
说明:本文基于公开文档、模型说明与行业共识整理,重点解释设计思路和成本规律;具体计费和 Token 数可能随模型迭代更新,最终以官方文档和实际 API 结果为准。
图片变成 Token,基本上要经过这些步骤
一张图片,要变成 Transformer 能处理的视觉 Token,大致要经历这样一个过程:
接收 — JPEG、PNG、WebP 等图片数据进入模型
解码 — 图片被还原成像素数据,也就是 RGB 等数值,而不是把 Base64 字符串当成文字去分词;
视觉预处理 — 模型根据自己的视觉架构,对图片进行缩放、裁剪、分块或其他尺寸处理;
视觉编码 — 视觉编码器把像素转换成一组高维向量。模型还可能对这些视觉表示进行压缩、投影或其他处理,最终形成模型所使用的视觉 Token;
融合 — 视觉 Token 与文字 Token 一起进入后续的 Transformer,让模型能够同时处理"你说了什么"和"图片里有什么"。
这里有个很多人会误解的地方:
Token 从来就不等于"一个词"。
Token 只是模型处理信息的基本单位。文字有文字 Token,图片有视觉 Token,音频、视频同理。
也就是说,AI"看图"这件事,本质上不是把画面塞进大脑,而是先把这个世界翻译成一堆数字,再拿这堆数字去推理。
麻烦马上就来了:到底切多细?
切得太粗,细节全丢了。比如一张网页截图,里面有一行很小的字,如果压缩得太狠,模型可能根本看不清那行字写了什么。
但切得太细呢?Token 数量直接爆炸。 而 Transformer 最怕的,恰恰就是输入长度无限膨胀——算力、速度、成本全部跟着遭殃。
所以多模态模型真正要解决的问题,不是:
“怎么让 AI 看见图片?”
而是:
“怎么用尽量少的 Token,把图片里最关键的信息保下来?”
这道选择题,几家公司走出了完全不同的路,下面逐个拆开看。
DeepSeek:直接给图片设一个统一上限
早期的 DeepSeek 不支持多模态,2026 年 9 月,DeepSeek-V4.1-Flash 开始提供原生多模态视觉理解。API 中现在通过 deepseek-flash 调用,DeepSeek 的思路简单直接:DeepSeek-Flash 模型不按分辨率精细计算 Token,而是先把每张图片都缩放到差不多同一个尺寸,再统一计数。
推理前,图片会被自动缩放:总像素低于约 544×544 的会被放大,更大的则被缩小,目标是让缩放后的总像素接近 1300×1300。因此不管你丢进去的是 2000×2000 还是 5000×5000,原始分辨率对 Token 数的影响会被大幅压平，最终 Token 数最高为 1024 个。
也就是说,DeepSeek 选择了一条"先封顶、再够用就好"的路:图片本身的分辨率信息在早期就被拉平了,模型不需要处理"这张图到底有多大"这个变量,Token 数从一开始就是可预测的。
官方文档:图像理解 · Token 用量计算
Claude:图片本质上是一笔"Token 账"
Anthropic 的思路则更加"直接"。
在 Claude 的文档里,图片会被切成一个个 28×28 像素的方块,每块算一个"视觉 Token",一张图的 Token 数就是:
Token 数 = ⌈宽 ÷ 28⌉ × ⌈高 ÷ 28⌉
不同模型能接受的分辨率还分成两档:Claude 4.7 及以后的模型是"高分辨率档",长边上限 2576px、单图 Token 上限 4784;更早的模型是"标准档",长边上限 1568px、单图 Token 上限 1568。超过上限的图会先被等比缩小,再按公式计算。
举个例子,一张 1000×1000 像素的图,两档都不用缩放,直接算出 36×36=1296 个 Token;但换成一张 3840×2160 的 4K 图,标准档会先被压缩到 1456×819 再计算,大概花 1560 个 Token,高分辨率档完全不用缩放,直接算出 4784 个 Token——同一张图,仅仅因为用的模型不同,Token 开销能差到三倍左右。
官方文档:Vision
这个细节其实戳破了一个我们平时容易忽略的事实:
我们习惯说"给模型看一张图",但从模型计算的角度,更准确的说法是:
“往上下文里塞进了一批视觉 Token。”
换句话说,你上传的每一张图,都在实打实地消耗这次对话的"容量预算"。图越大、分辨率越高,占用通常也越多(但不同模型会通过缩放、分块或预算上限把这种增长控制在不同范围内)。这也是为什么,同一段对话里,文字聊得好好的,一张高清大图丢进去,可用的上下文一下子就紧张了。
这套规则本身也在持续调整——DeepSeek 从早期 DeepSeek-VL2 的动态切分方案,换成了现在的统一封顶;Claude 也把估算公式从"宽×高÷750"换成了精确的 28×28 patch 计数,外加一个高分辨率档。没有哪家的方案是一次定型、之后再也不变的。
所以这篇文章里的每一个具体数字,都只是写作这一刻的快照。如果你在读到这篇文章的时候想知道准确数字,最可靠的做法永远是查一下对应厂商当前的官方文档,而不是把这里的表格当成长期有效的参考答案。
OpenAI:一套"数格子"的算法
OpenAI 的图片 Token 计算走的是"数格子"的思路:用 32×32 像素的方块把图片覆盖一遍,数出 patch 总数,再乘以一个固定倍数、向上取整,就是最终的图片 Token 数。
Token 数 = ⌈patch 数 × 1.2⌉
一张 1024×1024 的图,刚好数出 32×32=1024 个 patch,乘 1.2 取整是 1229 个 Token。
不同细节档(low/high/original/auto,不设置时默认是 auto)对图片的处理方式不一样:high 会把图片限制在更小的视觉处理预算内;而 original/auto 则尽量保留原始尺寸,因此大图可能产生更多 Token。
官方文档:Images and vision
Google:干脆不把图片当"外挂"
轮到 Google,和其他家就不太相同了。Gemini 从设计之初就强调一个词:原生多模态(native multimodal)。
它不是先做出一个只会处理文字的模型,再把看图能力简单接上去,而是从一开始就把文字、图片、音频、视频等不同模态纳入同一个多模态体系。
具体到一张图片,Gemini 依然需要把像素转换成模型能够处理的视觉表示,但它对图片的处理和 Token 计数,有自己的一套规则。
切格——较小的图片可以直接按固定规则计算,更大的图片则按照官方的分块规则处理。
编码——图片经过视觉处理后,形成模型使用的视觉表示。对于 Gemini 的图像理解 API,官方文档以视觉 tile 为单位计算 Token,每个 tile 对应 258 个 Token。
融合——视觉信息和文字信息最终进入同一个上下文,由多模态模型共同处理。
这套流程比前面几家少了一步"先训练文字模型、再嫁接视觉模块"的历史包袱——Gemini 的图片处理从设计第一天起就是这套统一逻辑的一部分。
官方文档:Image understanding · Media resolution
具体到计费,Gemini 的图像理解走的是另一套分格逻辑:
长宽都不超过 384 像素的小图,固定算 258 个 Token。
更大的图,会被切成 768×768 的格子,每格同样算 258 个 Token。
拿前面反复用的 1024×1024 图举例,两个维度都要切成 2 格,一共 4 格,算下来是 4×258=1032 个 Token。
官方文档给出的具体切格公式其实基于图片较短边计算,和"768"这个数字本身没有直接对应关系,这里只取一个直观说法。
Gemini 3 系列还加了一个 media_resolution 参数,可以为每张图片或视频单独设置 low/medium/high/ultra_high 档位,本质上是在这套默认规则之上设一个 Token 预算上限,在细节精度和成本之间做取舍。
而 Gemini 的原生多模态路线并不只针对图片,文本、图像、音频和视频都可以作为同一多模态体系中的输入,这也是它后来继续向视频理解和生成扩展的基础。
算法差别很大,但常见尺寸下,落地的 Token 数其实是同一个量级
把前面几家的规则放在同一张 1024×1024 的图上,对比一下:
| 模型 | 大致 Token 数 | 算法 |
|---|---|---|
| Claude | ≈ 1369 | ⌈宽/28⌉×⌈高/28⌉,按所用模型分两档上限 |
| OpenAI(GPT-5.6) | ≈ 1229 | 32×32 patch 数 × 1.2,取整 |
| Gemini(图像理解) | ≈ 1032 | 768px 一格,每格 258 |
| DeepSeek | ≈ 652 | 官方计算器给出的结果,最高1024 |
以上数字来自各家官方计算器/文档给出的公式,实际处理时换算得到的 Token 数量可能存在一定误差,请以接口返回的用量为准。
算法路线差别很大——有的按面积线性算,有的数格子取整,有的先缩放再估算——但换算成实际 Token 开销,四家在这张常见尺寸的图上最终都落在几百到一千出头这个区间,没有谁贵出一个数量级。
不过这个"同一量级"的结论,只在 1024×1024 这类常见分辨率下成立。换成一张分辨率极高的图,情况会不一样:Claude、Gemini、DeepSeek 都有各自的缩放、分块或 Token 预算机制,因此图片变大之后,并不一定按照原始像素无限线性增长。但 OpenAI 在 auto/original 档下没有对应的封顶——只要 32×32 的 patch 数不超过 3 万,就按原始尺寸计算,一张足够大的图,Token 数理论上能逼近 3.6 万,比另外三家高出不止一个数量级。
真正的分野,不是"谁更贵",而是"怎么决定该花多少"。
对普通使用者来说,这意味着什么
知道了这些公式,实际能落地的建议其实不多,但都挺实在:
- 大图先降分辨率再传,尤其只是想让模型看个大概的时候——反正模型内部也会缩放,你主动降,省下来的是真金白银和等待时间。
- 平台给了细节档位就按需选,比如 OpenAI 现在的
detail参数(low/high/original/auto),读文档、看大概布局用低档就够,抠小字、认坐标才需要original这种高保真档。 - 换模型不等于换了个"更好的眼睛",同一张截图在 Claude、GPT、Gemini、DeepSeek 上"看"的方式、花的 Token、能保留的细节都不一样,遇到"这模型怎么看漏了"或者"怎么突然更贵了",先想想是不是换了套图像编码逻辑。
说到底,不管是按面积算、数 patch、数格子,还是干脆设一个上限,四家公司回答的其实是同一个问题:怎么用尽量少的 Token,把这个世界看清楚。下次再看到"这个模型支持读图"这种说法,你会知道它背后到底做了什么。
关于
关注我获取更多资讯
