Gemini CLI 走 Vertex AI 划算吗？Express Mode 那 90 天和单位切换要先搞清楚
Gemini CLI 的授权方式里，除了 Google 登录和 API Key，还有一条 Vertex AI。
这条路跟前面几档最大的区别不在于贵不贵，而在于它换了一套计量方式。没搞清楚这一点就切过去，你会发现自己突然不知道该怎么估成本了。
一、官方给出的信息
按官方额度与定价页，关于 Vertex AI 的信息不多，但每一条都关键：
- Vertex AI（Express Mode）：官方写的是 “90 days”，之后需要启用付费
- Vertex AI 和 Gemini API Key 都支持按实际使用的模型和 token 数量付费
- 具体价格该页没给，需要查各自的定价页
就这三条。本文不会给任何单价数字——核对日那天官方额度页上确实没有，而定价这种东西编不得。
二、那 90 天是什么性质
它是一段有期限的体验，不是一个长期免费档。
这个区别很重要，因为前面几档（Google 登录 1000 次/天、API Key 250 次/天）是持续有效的免费额度——只要你不超，可以一直用下去。
而 Express Mode 的 90 天是一次性的。到期之后要启用付费才能继续。
所以「先用 Express Mode 白嫖」这个想法要打个折扣：你确实能免费用三个月，但三个月之后要么付费、要么迁回别的授权方式。而迁移是有成本的——配置要改、习惯要换、可能还要重新处理登录问题。
更实际的用法是把这 90 天当成评估期：用它来测清楚自己的真实 token 消耗，为要不要长期走这条路提供数据。
三、单位切换：你的经验全部作废
这是这条路最容易踩的坑。
前面几档的额度单位是 model request（请求次数）：
| 授权方式 | 每日 | 每分钟 |
|---|---|---|
| Google 登录 | 1000 次请求 | 60 次 |
| API Key（未付费） | 250 次请求 | 10 次 |
| Code Assist 标准版 | 1500 次请求 | 120 次 |
| Code Assist 企业版 | 2000 次请求 | 120 次 |
而 Vertex AI 这条路是按 token 计费的。
这意味着：
「我一天大概用多少次」这个经验，完全没法换算成成本。 因为每次请求消耗的 token 数差别巨大——读一个大文件的请求和问一句话的请求，token 数可能差几十倍。
你的成本结构变了。 在请求制下，多读几个大文件不影响额度消耗（还是一次请求）；在 token 制下，读大文件是实打实的成本。
优化方向也变了：
- 请求制下，你要优化的是请求次数——少来回几轮
- token 制下，你要优化的是上下文大小——少带无关内容
这两个优化方向有时候是矛盾的。 比如一次性把足够的上下文给够、让它一轮搞定，在请求制下是好策略（省请求次数）；在 token 制下可能反而更贵（每轮都带着那一大堆上下文）。
四、切过去之前该做的一件事
既然经验不通用，那切过去之前唯一有意义的准备是：先摸清楚自己的 token 消耗量级。
做法：
- 在 Express Mode 的 90 天里，先按平时的方式用一周，别刻意优化
- 看这一周消耗了多少 token
- 按这个速度推算月消耗
- 拿这个数字去官方定价页算钱
第 4 步必须用官方定价页当时的价格。本文和任何二手文章给的价格都不能用来做这个计算——模型定价变动频繁，而且不同模型的单价差别很大。
这四步的价值在于：它把「贵不贵」这个模糊问题，变成了一个你能自己算出答案的算术题。
五、什么情况下值得走这条路
不给结论，只给判断依据：
值得考虑的情况：
- 用量非常不规则——有时候完全不用，有时候爆发式使用。按量付费不用为闲置的额度买单
- 已经在用 Google Cloud，团队的账单、权限、合规都在那套体系里，多一条 Vertex 反而是统一而不是分裂
- 前面几档的请求次数限制成了瓶颈，而你不想被固定上限卡住
- 需要 Google Cloud 那套东西（区域、合规、企业管控等）——不过这方面官方额度页没有展开，需要查 Vertex 自己的文档
不太值得的情况：
- 用量稳定且不大——固定档位好预算，免费档可能就够
- 只是个人用，不想碰云平台的账单体系——按量付费意味着你要盯着账单
- 纯粹为了「免费 90 天」——三个月后的迁移成本可能超过省下的钱
六、别忽略的两个相邻问题
第一，登录方式会影响额度。 如果你是因为登录报错才考虑换 Vertex 的，先确认那个报错是不是有解。
比如「必须是组织订阅的具名用户」那条，官方说明的成因是环境里有 GOOGLE_CLOUD_PROJECT 或 GOOGLE_CLOUD_PROJECT_ID 变量，触发了组织订阅校验——个人用户清掉这两个变量就好。
为了绕开一个有官方解法的报错而切换整套计费模式，代价太大了。
第二，注意 GCP 账号的一个特殊情况。 官方 troubleshooting 里提到，Workspace 账号或者与 Gmail 关联的 GCP 账号可能激活不了免费档（报 Request contains an invalid argument）。官方给的绕法之一恰恰是把 GOOGLE_CLOUD_PROJECT 设成你的项目 ID。
注意这跟上一条的方向正好相反——一个是要清掉这个变量，一个是要设上它。所以动手前一定要先看清自己撞的是哪条报错。
七、三条路的定位小结
把 Gemini CLI 的几条路放在一起：
| 路径 | 计量单位 | 特点 |
|---|---|---|
| Google 登录 | 请求次数（1000/天、60/分） | 免费档里额度最宽的，日常首选 |
| 免费 API Key | 请求次数（250/天、10/分） | 额度只有前者的四分之一、频率六分之一 |
| Code Assist 付费档 | 请求次数（1500 或 2000/天、120/分） | 固定上限，好预算；价格官方额度页未给 |
| Vertex AI / API 按量 | token | 弹性，但经验不通用，要重新估 |
前三条是同一套计量体系，可以互相比较；第四条不是。
八、token 制下的两个成本陷阱
如果你确实切到了按 token 付费这条路，有两个在请求制下无关紧要、在 token 制下会明显影响账单的地方。
第一个：上下文是重复付费的。
对话越长，每一轮要带的历史越多。在请求制下，第 20 轮和第 1 轮都只算一次请求；在 token 制下，第 20 轮要为前面 19 轮的内容重新付一次费。
这带来一个反直觉的结论：长会话在 token 制下比在请求制下贵得多。 同样的工作量，分成五个短会话可能比一个长会话便宜不少。
第二个：粘贴大内容的代价被放大了。
你贴一个大文件进对话，在请求制下就是一次请求；在 token 制下，那个文件的全部内容都要计费，而且此后每一轮都跟着它一起重新计费一次。
对策还是那条通用建议：按路径让它去读，别粘贴。 这条建议在请求制下只是「更整洁」，在 token 制下是直接省钱。
这两条合起来是一个习惯：在 token 制下，要把「上下文卫生」当成成本管理来做，而不只是当成使用技巧。定期开新会话、别贴大块内容、把用不上的东西清掉——这些动作在账单上是看得见的。
九、总结
- Express Mode 的 90 天是有期限的体验，不是长期免费档——到期要启用付费。
- 最实际的用法是把这 90 天当评估期，用来测清楚自己的真实 token 消耗。
- 单位从「请求次数」换成了 token，你在前面几档积累的经验全部作废，要重新估。
- 优化方向也变了：请求制下省的是来回次数，token 制下省的是上下文大小——这两个方向有时候是矛盾的。
- 算钱要用官方定价页当时的价格，别用任何二手数字（包括本文——本文没有给价格）。
- 别为了绕开一个有官方解法的登录报错而切换整套计费模式。
- 注意
GOOGLE_CLOUD_PROJECT这个变量在两条不同报错里的处理方向相反，动手前先看清报错原文。
本文数字来自 Gemini CLI 官方额度与定价页，报错说明来自该仓库自带的 troubleshooting 文档，核对日 2026-08-08。Vertex AI 与 Gemini API 的具体单价该页未给出，本文不提供，请查各自的官方定价页。