Gemini PDF 与图片怎么计费

Gemini 的 PDF 每页按 258 tokens 计，Gemini 3 起页按 IMAGE 模态计费、PDF 原生文本不另计；图片按 768×768 切块，每块 258 tokens。（核验 2026-11-05，F45、F47、F48）

一、Gemini PDF 与图片怎么计费：问题在单位，PDF 按页、图片按块

把一份 PDF 丢给模型，然后去账单里找 DOCUMENT 这一项——找不到。很多人到这一步会以为「PDF 不计费」或者「账单延迟了」，其实都不是：Gemini 3 起，PDF 的页面按 IMAGE 模态计费，不再单列文档模态（F47）。

计费单位也不是「文件」，是页。每页折合 258 tokens（F45），一份二十页的合同就是二十份这个数。图片同理，但不是按张，而是按块：小图整张算一份 258，大图按 768×768 切成若干块，每块各算一份（F48）。

理解了「按页 / 按块」这两个单位，预算表才立得住。按文件数估算，遇到厚 PDF 会低估一个数量级。

二、每页 258 tokens 的估算：最小可运行示例

下面这段把两个单位写进函数，顺便验证「页数线性、图片按块」这两条。

## EXPECT: PDF 每页 258 tokens（按 IMAGE 模态计） | 小图 258 | 大图按 768 见方切块，每块 258 | 20 页 = 20 × 258
TOKENS_PER_UNIT = 258   # 一页 PDF、一张小图、一个 768 见方的块，都折算成这个数
TILE_SIZE = 768         # 切块边长（像素），与 token 数不是一回事

def pdf_tokens(pages):
    return pages * TOKENS_PER_UNIT

def image_tokens(width, height):
    cols = max(1, -(-width // TILE_SIZE))     # 向上取整，不是四舍五入
    rows = max(1, -(-height // TILE_SIZE))
    return cols * rows * TOKENS_PER_UNIT

assert pdf_tokens(2) == 2 * TOKENS_PER_UNIT
assert image_tokens(TILE_SIZE, TILE_SIZE) == TOKENS_PER_UNIT            # 恰好一块
assert image_tokens(TILE_SIZE * 2, TILE_SIZE) == 2 * TOKENS_PER_UNIT    # 两倍宽 = 两块
print(f"PDF 每页 {TOKENS_PER_UNIT} tokens（按 IMAGE 模态计） | 小图 {TOKENS_PER_UNIT} | "
      f"大图按 {TILE_SIZE} 见方切块，每块 {TOKENS_PER_UNIT} | 20 页 = 20 × {TOKENS_PER_UNIT}")

这里有两个容易混的量：TOKENS_PER_UNIT 是钱（token 数），TILE_SIZE 是长度（像素），两者数值不一样、含义更不一样，别因为都出现在同一个公式里就当成一件事。

切块用的是向上取整：边长恰好 768 算一块，多一个像素就算两块。这一点在估算里最容易被漏掉——一张 200×200 的缩略图和一张 768×768 的图，token 数是一样的，因为都只算一块。

三、解释与边界：四个会算错的地方

第一，页会被缩放，费用不随缩放变。 官方对页的处理有大页缩到 3072×3072、小页放大到 768×768 的口径，并明确低分辨率页面不带来费用减免（F46）。也就是说，扫描得很糊的一页和印刷清晰的一页，花的钱一样，但识别质量差很多。这条对「扫描件 OCR」类应用是硬伤：省不了钱，还得多做一次质量校验。

第二，PDF 里的原生文本不另计。 页面按 IMAGE 模态计，PDF 中原本可提取的文字不再单独收一份（F47）。所以不必为了「先用工具把 PDF 转成纯文本再上传」做额外优化——转文本省不下这笔钱，反而可能丢掉版面信息。

第三，图片按块，不按像素。 每块以 768×768 为界，各算 258 tokens（F48）。一张边长两倍于 768 的图是四块，一份三十页的扫描 PDF 是三十份——两者在同一量级上并不等价。做批量处理时，用「页数 + 总块数」估，比用「文件大小」估准得多。

第四，上限是两条，取先撞上的那条。 单个 PDF 上限是 50 MB 或 1000 页（F45），体积和页数任意一条超了都不行。这也解释了为什么「压缩一下再传」有时不管用——页数没变，压缩只解决体积那一条。

一页到底被看成什么，官方也给了口径。 大页会被缩到 3072×3072 以内，小页会被放大到 768×768（F46）。这对成本没有影响（都按页计），但对识别质量有影响——一张原本就很小的截图，放大后并不会变清楚。所以「这份扫描件能不能用」取决于原件的实际清晰度，不取决于你传的时候配了什么参数。

批量估算分三步。 先统计页数分布（平均页数乘文件数只是起点，长尾才决定账单），再按 258 乘出总量，最后加上附件图片按块折算的部分。第三步最容易被忘——很多人只算了 PDF，忘了工单里还挂着几张截图。

三条立刻见效的优化。 去掉空白页（扫描件里常有）；把附件图片先缩到 768 以内再传，超过这条线就开始按块翻倍；同一份文档别在多个请求里重复传，能复用就复用。前两条改预处理，第三条改架构。

一条真实工单的成本长什么样。 设想一条工单带一份十页 PDF 加两张截图：PDF 按十页折算，两张截图各算一份，总量是一个能手算出来的固定值。这类请求的成本结构非常稳定——不随内容多少变化，只随页数与附件数变化。所以优化点也就两个：减页数，或减附件，没有第三种。

真正让账单失控的是长尾。 常规工单十页，偶尔来一份两百页的扫描件，按每页等比折算就是二十份的量——这是按页数线性外推得到的示意，不是官方结论，但足以说明长尾的杀伤力。这类长尾占比不高时，均值看起来没事，月底却总是超。做法是给长尾单独设一条通道：超过某个页数的文档走异步批处理（见 10.3），而不是挤在同步请求里。把长尾单独统计一次，你会发现「平均数」这个指标在这类业务里几乎没有决策价值——它把两种完全不同的负载混成了一个数字。

页数分布比总页数更有用。 只记「这个月处理了多少页」看不出问题，记下「多少份文档、每份多少页」才能看出长尾占比。样本量不大时，一条简单的分位数就够了——它比平均值更能解释账单的波动。

边界。 本节只管 PDF 与图片。音视频按帧与秒计，口径不同，见 8.3；文件该内联还是上传，见 8.1。本节也不讨论识别质量怎么调（比如扫描件要不要预处理）——那属于输入质量，不属于计费。

四、预期输出与异常分支

真跑输出：

PDF 每页 258 tokens（按 IMAGE 模态计） | 小图 258 | 大图按 768 见方切块，每块 258 | 20 页 = 20 × 258

六类分支。在账单里找 DOCUMENT 项：找不到是正常的，PDF 页归入 IMAGE 模态（F47）。按文件数估成本：厚 PDF 会低估几十倍，按页算才对。以为低分辨率页更便宜：没有减免，一样按页计（F46），差别只在识别质量。图片按像素估：应该按块，边长两倍于 768 的图是四块不是一块（F48）。PDF 页数踩线：上限是 50 MB 与 1000 页两条（F45），压体积救不了页数。把 PDF 转成纯文本想省钱：原生文本本来就不另计（F47），转了不省，还可能丢版面。

五、判据卡：账单里找不到 DOCUMENT 模态怎么办

六、来源与核验

• https://aistudio.google.com/docs/document-processing.md（核验 2026-11-05，F45、F46、F47）
• https://aistudio.google.com/docs/tokens.md（核验 2026-11-05，F48）

每页 tokens 与模态归属属于「价格」档事实，复核周期一个月，见 1.3。若官方调整每页 tokens 或模态口径，本节的估算函数要整段重算。

七、动手试

1. 把 pdf_tokens 的入参从 2 改成 20，重跑。预期结果里的乘法式变成二十份；验收标准是算出「一份二十页 PDF 与二十张单页图，token 数是否相同」，并说明为什么。
2. 把 image_tokens 里的向上取整改成 round()，重跑。预期「恰好一块」那条断言失败（768 见方算成了零块）；验收标准是你能说清「为什么这里必须向上取整，四舍五入会漏算一整块」。
3. 打开你项目里处理 PDF 的代码，看它有没有统计页数。验收标准：能给出「一份典型 PDF 的页数分布」；给不出来，说明预算还是按文件数拍的。