Google Gemini 对任何不超过 384 × 384 px 的图像收取 258 个 token。如果图像超过该尺寸，Gemini 会为每个 768 × 768 px 的切片（tile）额外收取 258 个 token。因此，一张 500 × 500 px 的图片与 384 × 384 px 的图片成本相同，而一个 1920 × 1080 px 的画面则跨越六个切片，消耗 1,548 个 token。对于按 token 付费的开发者来说，跨越 768 像素的边界可能会导致成本波动 75%。
Gemini 的图像计费方式
Gemini 将图片视为视觉补丁（patches）组成的网格。一个 384 像素的正方形会被分解为 256 个补丁；另外两个额外的 token 用于标记视觉序列的开始和结束，从而得出 258 个 token 的固定价格。任何更大的图像都会触发切片步骤：系统将图像切割成 768 像素的切片，独立评估每个切片，并按每个切片 258 个 token 进行计费。
Token 数量随切片数量增加，而非原始像素。一张 1280 × 720 px 的照片占用两个切片（258 × 2 = 516 个 token）。一个 3840 × 2160 px 的 4K 画面覆盖 15 个切片，成本为 3,870 个 token。规则很简单——计算图像占用的 768 像素正方形数量，乘以 258，即可得出 token 账单。
为什么这条规则很重要
Gemini 的 token 模型直接转化为 API 费用。
缩减账单的实用方法
- 保持在切片限制之内。 一张 800 × 800 px 的图像会分成四个 768 像素的切片，消耗 1,032 个 token——是 768 × 768 px 图片价格的四倍。调整尺寸至精确的切片边界，可节省 75% 的成本。
- 裁剪空白区域。 巨大的白色边距仍会生成计入 token 总数的补丁。裁剪这些边距可以减少三分之二的成本。
- 注意 OCR 可读性。 只有当字符高度约为 15–20 px 时，Gemini 才能读取文本。如果将文档缩小到该阈值以下，模型会漏掉单词，迫使开发者回退到可能更昂贵的文本输入方式。
- 应用“每行高度”规则。 对于纯文本文档，目标是将图像总高度设定为行数乘以 25 px。这个“黄金公式”可以在保持行间距可读性的同时，将图像维持在单个切片内。
- 对于密集数据，优先使用图像。 大型电子表格或 LaTeX 方程的截图，其每个 token 承载的信息量通常比输入相同的文本数据更多。当信息密度很高时，图像 258 个 token 的成本可能比等效的文本负载更便宜。
图像优于文本的场景
在以下几种内容场景中，token 经济学会向图像倾斜：
- 非拉丁语系文字。 印地语、中文、阿拉伯语及类似文字需要大量字符来表达一个简短的概念；在文本模式下，每个字符仍会占用一个 token，而同样的视觉内容只需一个图像切片即可。
- 复杂的数学符号。 LaTeX 公式会导致 token 数量激增。公式的渲染图像可以保持在一个切片内，成本通常低于原始 LaTeX 字符串。
- 大型 UI 布局或表格。 将全屏 UI 原型或多页表格渲染为图像，可以避免用文字描述每个元素，从而将信息压缩到少数几个切片中。
权衡取舍
不加区别地缩小图像尺寸可能会适得其反。如果字符缩小到低于 15 像素的最小值，Gemini 的 OCR 就会失效，开发者必须回退到发送原始文本——这可能会增加 token 账单。过度激进的裁剪也可能切断模型正确回答所需的上下文。理想的平衡点是进行适度的缩放，在尊重切片边界的同时保持清晰度。
总结
理解 Gemini 的图像 token 计算逻辑，可以将隐藏成本转变为可控变量。将图像保持在 768 px 或以下，裁剪不必要的空白，并确保文本保持可读，从而在每次请求中节省数十或数百个 token。对于数据密集型内容（非拉丁文字、数学、表格），图像通常能以极低的 token 成本提供相同的洞察。智能的预处理，而非盲目的缩小尺寸，才是实现高效 Gemini 集成的关键。
来源：dev.to/kushaagr