vertex 调 gemini 计费 口径

你按官方单价估了一笔钱，月底账单却对不上，翻明细发现多出几个没听过的项——这种卡壳在 Vertex 上调 Gemini 的人多半遇过。这篇不给你单价数字，只讲计费口径：一次请求会被拆成哪几个可计价维度、哪些维度默认不出现在估算里、以及在站内哪几页能看到当时的价格与规格。

你按官方单价估了一笔钱，月底账单却对不上，翻明细发现多出几个没听过的项——这种卡壳在 Vertex 上调 Gemini 的人多半遇过。问题往往不在你算错，而在于「一次请求」在计费系统里并不是一个计数单位，而是被拆成了好几个可计价维度，其中一部分默认不出现在你常用的估算里。

这篇不给你单价数字，只讲计费口径：一次请求会被拆成哪几个维度、哪些维度容易漏、账单对不上时按什么顺序查，以及在站内哪几页能看到当时的价格与规格。所有具体数值都以站内页面当天显示为准。

一次请求被拆成哪几个计价维度

最基础的拆法是输入和输出两个独立计数项。输入侧包含你的提示词、系统指令、附加上下文；输出侧包含模型生成的内容。长上下文场景里两者比例会完全反过来，输入可能远大于输出，所以拿一个平均比例去乘总调用次数，偏差会很大。

多模态输入是第二个容易估错的维度。图片、音频、视频往往先换算成另一种计量单位，再折算成计价单位，不是直接按字符数算。你按文本长度估算的那套方法，套到带图请求上基本失效。

• 输入与输出分别计数，不要合并成一个总数去估
• 多模态输入按各自的换算规则折算，不按字符数
• 思考型输出、工具调用产生的中间内容可能落在输出侧或被单独标记
• 结论：先列出这一次请求会碰到几个维度，再逐个对站内价格页，别用一个平均数通吃

容易被漏掉的几项

缓存类的读写通常各有一套计数规则。命中缓存能省，但命中条件比较苛刻，对提示词结构、前缀重复度都有要求。如果你的请求每次前缀都不一样，缓存基本不会命中，照搬别人的省钱结论没有意义，这种场景就不适用。

失败请求、被限速后重发、超时重试这几类，是否计费要看失败发生在哪一步——是连接阶段就断了，还是模型已经开始生成。前者和后者在计费系统里往往是两种结果。后台批处理任务也是同理，它和实时调用走的是不同口径。

账单对不上的排查顺序

1. 第一步：比对总量把用量日志按维度拆开求和，看总量是否与账单一致。先排除统计口径错位——很多「对不上」其实是自己把输入输出加成了一个数。
2. 第二步：核对单价总量吻合但金额不符，去站内价格页核对当时的单价。价格是会调整的，你脑子里记的那版可能已经过期。
3. 第三步：查隐性调用总量本身不符，重点查重试、失败请求、后台任务这几类不写进主日志的调用。这类调用常常只出现在账单里，不出现在你的业务日志里。
4. 第四步：按项归因再动手把差异按项归因后，再决定是调参数、换调用方式还是换通道。没归因就先改架构，通常是在浪费时间。

这个顺序的价值在于：每一步都在缩小范围，而不是一上来就怀疑供应商算错。大部分差异在前两步就能解释清楚，真正需要动架构的属于少数。

自己去哪核对当时的数字

模型规格与计费入口到 /official-api/providers/google 看，官方口径以那页为准。Vertex 上托管模型的调用口径差异，参照 /official-api/providers/google-vertex。这两页建议一起看，因为同一类调用在两边可能落进不同的计价维度。

• 模型规格与计费入口：/official-api/providers/google
• Vertex 托管模型的调用口径：/official-api/providers/google-vertex
• 把单价换算成「一次对话大概多少钱」：/tools/token-price-calculator
• 价格与规格会调整，本文不写死任何数值，一切以站内页面当天显示为准

计费口径的本质不是单价，而是「一次请求被拆成几个计数单位」——拆错维度，单价背得再熟也对不上账。