做 AI 应用大半年在 Gemini API 上花的冤枉钱和踩的 429 坑说多不多说少也真不少。标题里这两件事——管住账单、管住 429——表面看一个管钱一个管报错但实际线上调优时它们是一根绳子上的两个结限流没处理好重试一多账单直接翻倍花钱没提前规划好业务还没起来配额就先被卡死。更不要说 Gemini 这种模型报价看着便宜真要按 Input/Output Token 分开计价、加上缓存命中、再算上重试损耗一个月下来账单能让你对着后台愣半天。这篇文章基于我自己的真实接入记录写适合正在接 Gemini API 做产品或工具的开发者也适合已经接上了但被账单和错误码折磨的团队。不聊宣传册上的通用介绍只讲怎么把计费机制看清楚、把 429 的触发逻辑摸透再把控费和限流的代码结构直接落到工程里。1. 先说清楚为什么“省钱”和“限流”必须放一起管1.1 同一个源头请求量才是成本的关键变量我一开始也把它们当两件事处理费用归费用配额归配额。结果第一个月在账单分析时发现成本增长曲线跟 429 重试次数几乎是重合的。后来想明白了——大模型 API 的成本本质上是按 Token 用量走的而用量又是由请求数量和每次请求的上下文大小共同决定的。429 一出现你的重试逻辑如果写得糙相当于把一模一样的请求又原样多发了三次甚至五次Token 消耗瞬间膨胀。反过来看限流本身也是一种成本信号。当某个业务线频繁触发 429基本说明这条链路已经在超预算运行了。要么是请求量设计得太大要么是对单次请求的上下文长度控制失效。所以我的经验是账单和限流必须放进同一个技术方案里设计先在入口把 Token 预算卡住再去谈重试和并发否则永远是按下葫芦浮起瓢。1.2 只调限流不控费的典型翻车现场有个很典型的场景后端工程师收到 429 报警第一反应是把重试次数从 1 调到 3再把退避时间缩短。短期看不报错了但成本马上上来。因为 429 往往是 TPM每分钟 Token 数超限而不是 RPM每分钟请求数超限多发的几次重试继续把 TPM 撑在峰值等于一直在悬崖边跑步一有突发流量就再次崩溃。又比如有些团队喜欢在每个请求里塞进完整的产品文档、历史对话、商品信息觉得“反正 API 便宜多给点上下文模型效果更稳”。结果上下文一大TPM 消耗速度快得吓人免费额度几个小时就烧完甚至直接把付费账号的每日限额顶穿。这就是典型的“没搞清计费单位”的代价。1.3 这篇内容适合谁来参考如果你是个人开发者在做一个翻译小工具、一个 AI 客服插件或者一个自动化流程脚本这篇文章能帮你把 Gemini API 的接入方式从“能跑就行”提升到“稳且可控”。如果你是团队负责人或者后端开发后面对可观测性和工程化拆解的部分能直接用在你现有的 API 网关设计里。我的目标是让读完之后你能自己说清楚“每个请求大概花多少钱”“什么情况下会触发 429”“重试策略凭什么这么设计”这三件事。2. Gemini API 计费到底怎么算从量、到价、到账单拆分2.1 按 Token 计价但输入输出是两套价Gemini 和其他主流大模型一样按 Token 数量计费但输入 Token 和输出 Token 不是一个价格。一般来说输出价格是输入的 34 倍这是一个非常关键的优化点你花在压缩提示词上的每一分钟省下的都是真金白银。举个例子假设某个模型输入价格是 100 万 Token 10 美元输出价格是 100 万 Token 40 美元。你做一个单轮问答用户问题加上系统提示词一共 2000 Token模型回复 500 Token那这次调用成本大约是 0.00002 0.00002 0.00004 美元看着便宜到可以忽略。但当你有 10 万日活、每人每天 5 次调用再用上 3 次重试和两倍的历史上下文月账单就完全不是可以忽略的量级了。所以我把每条业务线都做了“平均单次请求成本”的估算用的公式很简单单次成本 (输入 Token 数 × 输入单价 输出 Token 数 × 输出单价) / 1000000把这三个参数做成配置项每次调用前先估算超预算就不发。这个动作机制比事后看账单靠谱得多。2.2 上下文缓存和短上下文两个容易忽略的省钱点Gemini API 有上下文缓存特性同一段前缀内容反复作为输入时命中缓存的部分会按更低的单价计费。这个特性对“固定系统提示词 用户提问”这种场景特别有用。比如你做一个文档问答机器人产品手册有 5 万 Token每个用户提问前都要先塞进去没有缓存的话这 5 万 Token 每次都要全额计费。开通缓存之后首次计费略高后续命中缓存的 Token 单价可能降到原来的四分之一甚至更低长期跑下来能省出一台服务器钱。再说短上下文。不少场景其实根本不需要把历史对话全部塞进去。我踩过坑为了“保持连贯性”把几天前的完整对话全部带着结果 Token 消耗呈指数增长而模型效果并没有明显变好。后来我把对话窗口改成最近三轮、每轮截断到 1000 Token并加上关键信息抽取摘要效果几乎没差成本掉了百分之四五十。这属于典型的“上下文越短越省钱”但需要你真正理解业务里哪些信息是模型必须的。2.3 配额层级免费层和付费层的差距不是一点点Gemini API 的配额分免费额度Free Tier和付费额度Paid Tier另外还有按“每分钟请求数”“每分钟 Token 数”“每日 Token 数”三种维度。免费层适合写 demo、做验证但千万别把它当生产环境的地基。我看到过有人拿免费 Key 直接上线第二天就因为 RPD每天请求数超限整个服务瘫痪还找不到原因。付费层同样有配额上限只不过数字大一些。你需要做的是在官方配额页面把你账号的 RPM、TPM、RPD 上限查清楚然后把这些数字作为你代码里限流的基准参数。不要等报了 429 再去查那是事后补救不是事前设计。我自己的习惯是做一个配置文件把每个模型的 RPM、TPM、RPD 上限、预估成本都写进去每次发版前先对一遍保证代码里的限流阈值不会超过账号配额。我整理了一个简单的配额对照表以我实际用过的模型为例具体数值请以官方账号后台为准模型系列免费层 RPM免费层 TPM付费层 RPD备注Flash-Lite 类较低通常个位数到十几几万级数万到数十万级适合快速验证Flash 类十几到几十几十万级数十万到百万级性价比高生产常用Pro 类个位数到十级别数万级相对更紧能力更强务必做路由控制注意这里的“付费层 RPD”并不是说你可以无限跑。只是它比免费层宽得多但一旦超过照样是 429。到了这一步你就会明白API 的计费和限流根本不是两个系统它们共享同一个配额池只是从不同维度对外表现。2.4 把成本分摊到业务线的三个维度单看总账单你没法定位到底是哪个功能吃掉了大部分费用。我推荐至少从三个维度做分摊按时段分摊、按业务线分摊、按错误状态分摊。按时段分摊最简单看高峰低谷。很多 AI 功能集中在白天使用账单曲线应该是潮汐式的如果出现凌晨的异常凸起多半有定时任务在发多余请求。按业务线分摊核心做法是在调用 API 的时候附加一个业务标识字段比如把 metadata 里的 business 字段设成 chat、translate、summary后面在账单导出或者日志系统里按这个字段聚合。按错误状态分摊是为了看清楚“重试带来的额外成本”。如果你的账单里很大一部分是 status ! 200 的请求产生的说明你的重试策略在“烧钱”这时优先优化的节奏是先降重试再降单价。3. 限流机制解剖429 不是你改改代码就能绕过的3.1 429 是怎么产生的三种限流维度很多人以为 429 就是“请求发太快了”其实不准确。Gemini API 至少从三个维度做限制任何一个维度超了都会返回 429第一是 RPM每分钟请求数。这个最容易理解就是你每秒能发起多少次请求算法层面会基于滑动窗口统计。第二是 TPM每分钟 Token 数。它统计的是这 1 分钟内你所有并发请求里包含的总输入加输出 Token 数。这两个维度在实际使用中最容易相互影响一次 5000 Token 的请求比一次 500 Token 的请求更容易先把 TPM 打满。第三是 RPD每天请求数按自然日统计。我见过最典型的情况是团队把 RPM 当成了唯一指标代码里做了每秒 10 次的限制自信满满地上线。结果用户一多TPM 先爆了因为每个请求都带着超长历史。所以设计限流方案时必须同时把 RPM 和 TPM 都做进客户端分别估算、分别控制。3.2 “看起来没超限但还是被限了”的几个隐藏原因排查 429 的时候你会遇到不少“明明我看不到超限但服务还是报 429”的情况。这里有三个隐藏原因全是我实际踩过的。第一个隐藏原因是配额是账号维度的而你用了多把 Key。团队里每个人拿自己的 Key 测试或者微服务里多个模块各自申请了 Key看起来单个 Key 没超但同一个账号的总配额你根本没统计过。第二个隐藏原因是并发突刺。RPM 是每分钟的平均值你在前 50 秒只发了 5 次请求最后 10 秒突然放进来 30 个并发看起来“1 分钟总共没超 35 次”但边缘突发已经把桶打穿了。第三个隐藏原因是多模型共享配额。Gemini 的不同模型某些配额指标可能共用一个池子你在 Flash 模型上的高负荷会把共享配额耗尽导致 Pro 模型的调用也莫名其妙地报 429。3.3 优先级Priority对限流的影响Gemini API 的流量还有一个“请求优先级”的概念简单说就是在配额紧张时系统优先保证高优先级请求的吞吐低优先级请求会被延迟或者拒绝。默认情况下Interactive 类请求的优先级最高适合用户实时交互场景。Batch 类请求优先级更低适合离线任务。实际操作里我建议把所有实时交互请求都标记为正常优先级而把定时任务、数据清洗、批量生成这类请求显式放到 Batch 模式下跑。这样设计的好处是大流量批处理任务不会把你的实时业务配额挤爆。我第一次上线时没分优先级一个日志总结定时任务每天上午十点启动直接导致同时间段的用户对话请求大量 429排查了半天才发现是批处理任务在抢配额。分开之后整个系统稳定度提升非常明显。4. 实战接入把费用控制装进代码里4.1 Token 预算池请求发出前先算一遍账成本控制最关键的一个习惯就是“先算账再发起”。我会在 API 调用封装层里加一个简单的 Token 预算池本质上是把整个项目的每分钟/每小时/每日预算存进一个计数器每次调用前都做预估。# 预算池核心逻辑初始化预算请求前检查请求后扣减 class TokenBudget: def __init__(self, daily_budget_tokens, minutely_max_tokens): self.daily_used 0 self.minutely_used 0 self.daily_budget daily_budget_tokens self.minutely_max minutely_max_tokens def can_spend(self, estimated_tokens): return (self.daily_used estimated_tokens self.daily_budget and self.minutely_used estimated_tokens self.minutely_max) def spend(self, actual_tokens): self.daily_used actual_tokens self.minutely_used actual_tokens这里要特别注意一个点预估的 Token 数不是实际数。你可以用一个简单的统计函数按字符数除以 3 或者 4 来粗估模型实际情况会有偏差。所以我建议预算池按“预估数检查、实际数扣减”的方式运作并且把每次调用的实际 Token 用量从响应元数据里读出来回写保证池子长期来看是准确的。4.2 模型路由贵模型只做关键任务模型路由是我在成本控制上投入产出比最高的一笔改造。思路很简单并不是所有请求都需要最强的模型。我把业务请求分成三个等级用 Gemini 系列的不同模型去承接。第一等级是核心能力需求比如复杂推理、合同理解、代码生成用能力最强的模型但严格控制调用量。第二等级是日常对话、结构化抽取、翻译润色用性价比较高的 Flash 类模型。第三等级是分类、关键词提取、标题生成之类的高频任务用更小的模型甚至可以被规则引擎替代。def route_model(request): # 按业务等级决定模型返回模型名和是否允许降级 if request.business_level high: return gemini-pro, False if request.business_level medium: return gemini-flash, True # 低优先级任务在高峰时段直接降级为本地规则回答 return gemini-flash-lite, True实际运行时第三等级的任务在预算池紧张时可以直接降级成模板话术用户感知不到太明显的差异但成本会大幅下降。这个方案我强烈建议每一个做 AI 产品的人都试一下远比你去抠单次调用价格划算。4.3 缓存层结果缓存与上下文缓存都要做我前面说的是 Gemini API 自带的上下文缓存那是服务端计费层面的。在应用层你还可以做一层结果缓存如果同一个问题以前回答过直接返回历史答案不必再调 API。很多团队担心“模型回答不够稳定缓存了会不会让用户看到旧答案”我觉得要分场景。对于知识库问答、商品介绍、规章制度查询这类答案相对稳定的内容结果缓存完全可取还可以加个 TTL半小时一小时过期一次。问题缓存的粒度也要注意最好是“规范化后的问题摘要”作为 Key比如先把问题里的标点、大小写、空白字符剔除再取 MD5这样能大幅提高命中率。上下文缓存和结果缓存是两个不同层次的事前者省的是输入的 Token 费后者省的是整次的调用费。两个都做成本控制才算完整。4.4 统一 API 调用封装计费、限流、路由的汇合点我强烈建议所有 Gemini API 调用都从同一个封装函数出去不要在各个业务代码里散着直接调用 SDK。这个封装函数要负责四件事路由选模型、预算池检查、限流等待、异常重试。统一之后你改一个限流策略、调一个预算阈值全项目生效不用到处打补丁。async def gemini_request(prompt, business_levelmedium): # 1. 路由选模型 model, allow_fallback route_model(business_level) # 2. 预算检查 estimated estimate_tokens(prompt) if not budget.can_spend(estimated): if allow_fallback: model gemini-flash-lite else: raise BudgetExceededError() # 3. 限流等待内部用令牌桶控制 RPM 和 TPM await limiter.acquire(model, estimated) # 4. 调用 异常重试细节见下一章 resp await call_with_retry(model, prompt) # 5. 回写实际 Token更新预算 budget.spend(resp.usage_metadata[total_token_count]) return resp当然这只是一个示意结构。真实项目里还要考虑认证信息管理、日志采集、错误码映射等。但核心原则不变把 API 调用当成一个基础设施来设计而不是在业务代码里随手调用。5. 实战限流从退避重试到并发控制的完整策略5.1 指数退避与抖动别把自己变成“恶意攻击者”429 出现后最无脑的错误处理方式是立刻重试。官方文档也会建议你使用指数退避但退避不是简单 sleep 一下再发有几个细节必须注意。第一个细节是初始等待时间不能太短。很多人从 200ms 开始但如果配额已经打满200ms 后照样是 429白白多打一次。我建议从 1 秒开始以 2 倍增长到最大 30 秒或 60 秒。第二个细节是必须加随机抖动。如果多个并发请求同时收到 429然后按同样的退避公式计算等待时间它们会在同一瞬间同时重试造成“惊群效应”。正确做法是在退避公式里加一个 0 到 1 秒的随机偏移让重试时间错开。第三个细节是控制最大重试次数。我通常设置最多 34 次超过之后不再重试直接进入降级逻辑。无限重试只会无限烧钱。import random import asyncio async def call_with_retry(coro_factory, max_retries4, base_delay1.0): for attempt in range(max_retries): try: return await coro_factory() except TooManyRequestsError: if attempt max_retries - 1: raise delay base_delay * (2 ** attempt) random.uniform(0, 1) await asyncio.sleep(delay) raise RuntimeError(unreachable)5.2 并发控制令牌桶还是信号量接口层配合客户端的主动限流是最文明的使用方式。我更喜欢用令牌桶来做 RPM 控制因为令牌桶天然支持“突发”且长期均值可控。也就是说你允许在一个很短的时间窗口内稍微冲破平均速率只要不长期超限。这符合大多数业务形态白天流量平稳但偶尔会有促销或推文带来的小峰值。实现上可以用 Python 的 asyncio 信号量做并发上限再加一个独立的任务去按速率发放令牌。比如你的账号允许每分钟 60 个请求那就设计成每 1 秒发放 1 个令牌到池子里请求进来必须先拿令牌再发。如果池子里没令牌等待而非直接报错。注意等待时间要设上限超过 10 秒就不等了走降级避免请求排队把用户体验拖垮。这里真正难的地方是同时控制 RPM 和 TPM。一个请求的 Token 数是动态的所以你不能只按请求数发令牌。我的方案是每秒统计当前 TPM 消耗的滑动窗口请求加入前计算“预测增量”如果窗口累计值加上本次增量会超限就让这个请求延迟到下个窗口。这个逻辑看起来复杂但把它封装到限流器后业务代码完全无感知。5.3 降级与兜底大模型挂了业务不能挂做 AI 产品最怕的不是模型报错而是模型报错后整个业务流程中断。我强烈建议每个调用点都设计降级策略至少分三个级别本地规则兜底针对的是分类、抽取、关键词这类结构化任务。可以准备一套关键词规则和模板模型超时或被限流时先用规则结果顶着。模型降级即从 Pro 降到 Flash从 Flash 降到 Flash-Lite再不行就返回缓存结果。最终兜底返回一个友好的可读提示记录日志并通知告警系统至少保证用户端看到的是“服务暂时繁忙”而不是空洞的五百页面。我在实际项目中遇到过一次配额耗尽因为忘记续订套餐。当时系统自动切到降级链路中等优先级任务从 Flash 降级到 Flash-Lite低优先级任务直接走模板答案。用户侧完全没有感知到故障只有监控后台在报警。这套链路上线之后我再也不用半夜爬起来处理“大模型接口挂了”的紧急事故了。6. 可观测性、告警与团队规范别等账单和报错来找你6.1 关键指标计费、配额、错误码没有监控的成本控制等于没有控制。我把指标分成三类计费指标包括每次请求的 Token 输入输出数、单次成本估算、小时累计成本配额指标包括当前 RPM、TPM、RPD 的使用百分比以及估算的点位照这个速度还有多久会撞到配额错误码指标重点追踪 429、400、403、500 各自出现的频次和占比。这些指标可以通过 Prometheus 或者 CloudWatch 之类的方式收集。最简单的做法是在统一封装函数里埋点把每次调用的模型名、业务标签、Token 数、错误码、耗时推送到监控系统。初期不需要太豪华的链路追踪先把核心指标跑起来比什么 Advanced Observability 都管用。6.2 费用告警和限流告警的阈值设计告警阈值设置得当可以减少很多不必要的心惊肉跳。费用告警方面我建议设置三级日预算使用 60% 提醒80% 告警100% 熔断直接停掉非核心业务线。限流告警方面429 的错误率超过总请求数的 1% 就要告警因为你还有重试机制兜底超过 5% 就需要紧急处理这时大概率是配额设计不合理或者模型路由配错了。额外说一个容易踩的坑429 和 5xx 要区分告警。429 表示你撞到了自己的配额或者账号配额优先检查代码逻辑5xx 表示服务端故障优先检查官方状态页和重试策略。之前我把它们混在一个报警规则里每次报警都把所有字段翻一遍浪费了很多时间。6.3 团队规范Key 管理、评审与变更流程最后但非常重要的是团队层面的规范。第一API Key 统一由一个人或一个小组管理不要每个人都在测试代码里塞自己的 Key。所有 Key 放在密钥管理服务里通过环境变量或者配置中心下发。第二每次改模型路由、改缓存策略、改重试参数都要写清楚理由和预期收益。我做了一个简单的“成本变更评审表”包含变更原因、预估的 Token 变化、测试数据、上线后的监控对比看起来繁琐但意外效果很好很多拍脑袋的“优化”在这一步就被拦下来了。第三定期做账单复盘每周看一次按业务线聚合的费用曲线月度做一次配额和费用的匹配分析看有没有业务线在“花钱买 429”。这些规矩听起来不酷但恰恰是把 AI 成本控制从“个人技巧”变成“团队能力”的唯一路径。最后聊点实操体会写到这里我回想自己第一次上线 Gemini API 的场景代码能跑、对话能回就觉得完事了。直到第二个月账单出来又复盘那些深夜收到的 429 报警才意识到所有的结构性问题——没有预算池、没有模型路由、没有缓存、重试逻辑粗糙——都是运气好才没有造成重大事故。现在我接任何一家大模型 API第一件事永远是做配额清单和成本模型再谈功能开发。这其实不是什么高大上的工程能力纯粹是被账单和报警教育出来的。如果你打算在自己的项目里接入 Gemini API我的建议很直接先花一个下午把官方计费页、配额页、429 错误文档读一遍再用文章里的预算池和限流器思路搭一个最小的骨架哪怕第一版只覆盖一个业务线都好。等你把“请求前预估、请求后回写”这个循环跑顺了账单和报警都会肉眼可见地变得平稳。踩过的坑攒成文档后面接手的人会发自内心地感谢你。