免费大模型API额度收紧下的多模型路由与降级架构实践-育师

1. 免费额度收紧背后，开发者真正该关心什么

早上打开常逛的几个开发者群，发现讨论最热烈的话题不是新模型发布，而是"免费额度又缩水了"。有人贴出截图说某个模型调用直接返回配额不足，有人抱怨昨天还能跑的脚本今天全线报错。这类消息每隔一段时间就会来一轮，但这次波及面确实比以往大一些——多个原本可以白嫖的模型入口同时出现限制，不少依赖免费额度做原型验证的小团队和个人开发者一下子被打乱了节奏。

先把话说清楚：这篇文章不讨论任何具体平台的访问方式，也不涉及任何网络工具的使用。我想聊的是，当"免费大模型API"这个变量突然变得不稳定时，一个务实的开发者应该怎么调整自己的技术栈和调用策略。关键词里的Gemini、Claude、API、TPU、Antigravity这些词，本质上都指向同一个问题——当外部依赖不可控时，你的系统还有多少自主性。

适合读这篇的人大概有三类：一是正在用免费额度做副业项目或课程作业的学生开发者；二是小团队里负责技术选型、需要控制成本的后端同学；三是单纯对LLM应用架构感兴趣、想搞清楚"多模型路由"到底怎么落地的人。不管你是哪一类，接下来的内容都会围绕一个核心展开：把鸡蛋放在不同篮子里，并且让篮子可以随时替换。

我自己的项目从去年开始就陆续踩过好几次"额度突然没了"的坑，最惨的一次是周五晚上演示，下午三点主力模型开始限流，临时切备用模型又发现接口格式不兼容，硬是熬到凌晨改代码。从那以后我就下定决心，把所有模型调用都抽象成统一层，任何一个provider挂掉，改一行配置就能切换。这套东西不复杂，但确实救过我好几次。

2. 多模型路由层的设计思路与核心抽象

2.1 为什么不能直接在业务代码里调SDK

很多人的第一版代码是这样的：业务逻辑里直接import openai或者import google.generativeai，然后client.chat.completions.create(...)一把梭。这种写法在只有一个模型、一个供应商的时候没问题，但一旦你要支持多个provider，问题就来了。

首先是接口签名不统一。OpenAI系的接口是messages数组加role字段，Gemini的接口结构又不太一样，Claude的system参数是单独传的。你如果每个地方都写if-else判断用哪个provider，代码会迅速变成一坨。其次是错误处理逻辑重复。限流、超时、鉴权失败这些异常，每个SDK抛出的类型都不同，你不可能在每个调用点都写一遍重试逻辑。最后是配置散落。API key、base_url、模型名这些信息如果散落在各个文件里，换一个provider就要全局搜索替换，极易漏改。

所以第一件事就是做一层抽象。我习惯定义一个LLMProvider接口，核心方法就一个：

from abc import ABC, abstractmethod from dataclasses import dataclass from typing import Optional @dataclass class LLMResponse: content: str model: str provider: str usage: Optional[dict] = None class LLMProvider(ABC): @abstractmethod def chat(self, messages: list, system: str = "", **kwargs) -> LLMResponse: ... @abstractmethod def is_available(self) -> bool: ...

每个具体provider实现这个接口，把各自SDK的差异封装在内部。业务代码只依赖LLMProvider，完全不关心底层是谁。

2.2 路由策略：优先级、权重与降级

有了统一接口之后，下一步是决定"这次调用走哪个provider"。我实践下来比较稳的策略是优先级加降级，而不是简单的轮询。

具体做法是给每个provider配一个优先级数字，数字越小越优先。调用时按优先级排序，依次尝试，第一个成功的就返回。如果高优先级的provider返回限流或超时，自动降级到下一个。这个逻辑用一个Router类实现：

class LLMRouter: def __init__(self, providers: list): # providers 是 (priority, provider_instance) 的列表 self.providers = sorted(providers, key=lambda x: x[0]) def chat(self, messages, system="", **kwargs): last_error = None for priority, provider in self.providers: if not provider.is_available(): continue try: return provider.chat(messages, system, **kwargs) except RateLimitError as e: last_error = e continue except Exception as e: last_error = e continue raise AllProvidersFailed(last_error)

这里有个细节值得展开：降级不是无脑往下走。如果某个provider是因为鉴权失败（key过期或无效）而报错，那它短时间内重试也没用，应该把它标记为"冷却中"，比如5分钟内不再尝试。我一般用一个简单的内存字典记录每个provider的失败时间和冷却时长，is_available()里检查一下就行。

提示：冷却时间不要设太长。免费额度类的provider有时候是分钟级限流，冷却5分钟足够；如果是日额度耗尽，那当天基本没戏，这种情况更适合人工介入而不是自动重试。

2.3 统一消息格式的转换陷阱

抽象层最容易被低估的部分是消息格式转换。不同provider对多轮对话、系统提示、图片输入的支持程度差异很大，如果不处理好，会出现"切换provider后回答质量骤降"的问题。

我踩过的一个典型坑是system prompt的处理。OpenAI系把system作为messages里的一条，Claude是单独的system参数，而有些模型压根不支持system角色，只能把系统提示拼到第一条user消息前面。如果你的抽象层不做归一化，切换provider时行为会不一致。

我的做法是在抽象层内部统一用(system, messages)的二元组表示，每个provider的chat方法自己负责把它转成自家格式。对于不支持system的provider，就在内部把system内容前置拼接到第一条user消息，并加一个分隔标记。这样业务层永远只写一种格式。

另一个坑是token计数。不同provider的tokenizer不一样，同样一段文本算出来的token数可能差20%以上。如果你在业务层做上下文长度裁剪，用A模型的计数去裁剪B模型的输入，很容易裁多了浪费或者裁少了报错。我的建议是：裁剪逻辑放在provider内部，用该provider自己的计数方法；抽象层只负责传递完整的messages，不做过早优化。

3. 从Gemini到Claude：不同provider的适配实操

3.1 Gemini系接口的适配要点

Gemini的接口设计和其他家有个明显区别：它的多轮对话是用Content对象列表表示的，每个Content有role和parts两个字段，parts是个数组，可以放文本也可以放其他类型。这个结构比OpenAI的messages更灵活，但转换起来也更容易出错。

适配的时候要注意几点。第一，Gemini的role只有user和model两种，没有system和assistant。所以你的抽象层里如果有assistant角色，转过去要映射成model；system提示要么用专门的系统指令参数，要么拼到第一条user里。第二，parts是数组意味着一条消息可以包含多个片段，纯文本场景下你只放一个{"text": "..."}就行，但解析响应时要注意它返回的也是数组，得把所有text片段拼起来。

def _to_gemini_contents(self, messages): contents = [] for msg in messages: role = "model" if msg["role"] == "assistant" else "user" contents.append({ "role": role, "parts": [{"text": msg["content"]}] }) return contents

第三，Gemini的流式响应格式和OpenAI的SSE不太一样，如果你要做打字机效果，解析逻辑得单独写。我一般建议流式和非流式用两套解析代码，不要强行统一，否则容易出边界bug。

3.2 Claude系接口的适配要点

Claude的接口相对规范，messages数组加独立的system参数，和OpenAI的差异主要在细节上。最需要注意的是messages必须以user开头、user和assistant交替出现。如果你的对话历史里有连续两条user消息（比如工具调用返回后），Claude会直接报错。

处理办法是在转换时做一次合并：遇到连续同角色的消息，把后一条的内容用换行拼到前一条上。这个逻辑看起来简单，但如果不做，切换provider时就会莫名其妙失败。

def _normalize_alternating(self, messages): normalized = [] for msg in messages: if normalized and normalized[-1]["role"] == msg["role"]: normalized[-1]["content"] += "\n" + msg["content"] else: normalized.append(dict(msg)) return normalized

另外Claude对max_tokens是必填的，而OpenAI是可选的。抽象层里最好给一个默认值，比如4096，避免切换过去忘记传导致报错。还有一点，Claude的响应里content是个数组，可能包含多个block，纯文本场景取第一个type == "text"的block就行，但要做防御性判断。

3.3 本地模型与自建服务的兜底价值

聊到这里必须提一句：免费额度再香，也不如自己手里有一个能兜底的选项。我现在的项目里，除了几个云端provider，还挂了一个本地部署的小模型作为最后一道防线。它可能能力弱一些，但胜在永远在线、永远不限额。

本地模型的适配和云端没本质区别，只要它提供OpenAI兼容接口，直接复用同一套provider实现，改个base_url就行。现在很多推理框架都支持OpenAI兼容的API格式，这让本地兜底的成本大大降低。我的配置里本地模型优先级最低，只有所有云端provider都不可用时才会走到它。实测下来，虽然回答质量有差距，但至少保证服务不中断，用户体验不会断崖式下跌。

注意：本地模型的上下文长度通常比云端小很多，做兜底时要在provider内部做更激进的裁剪，避免超长输入直接OOM。我一般把本地兜底的上下文限制在云端的一半左右。

4. 额度监控、告警与自动切换的落地细节

4.1 怎么知道额度快用完了

免费额度最坑的地方在于它不会提前通知你。很多provider的限流是硬性的，到了阈值直接返回错误，你才知道用完了。所以主动监控很有必要。

我的做法是在每次调用成功后，从响应里提取usage信息（如果有的话），累加到一个计数器里，按天或按小时统计。对于不返回usage的provider，就用本地tokenizer估算。这个计数器不需要很精确，能反映趋势就行。当某个provider的用量达到预估额度的80%时，发一条告警——我用的是最简单的方案，写到一个日志文件，配合一个定时脚本检查，超过阈值就发邮件或消息通知。

class UsageTracker: def __init__(self, daily_limit: int): self.daily_limit = daily_limit self.used = 0 self.date = today() def record(self, tokens: int): if today() != self.date: self.used = 0 self.date = today() self.used += tokens if self.used > self.daily_limit * 0.8: self.alert()

这个逻辑可以挂在provider的chat方法里，调用成功后自动记录。注意要处理跨天重置，否则第二天额度恢复了你的计数器还停在昨天的值，会误报。

4.2 自动切换的触发条件设计

自动切换的触发条件不能太敏感，也不能太迟钝。我的经验是分三档：

触发条件	处理动作	冷却时长
单次超时（>30s）	重试一次，仍失败则降级	30秒
限流错误（429）	立即降级	5分钟
鉴权失败（401/403）	立即降级并告警	1小时
连续3次失败	降级并告警	30分钟

这张表是我踩坑之后总结出来的。早期我把所有错误都设成5分钟冷却，结果鉴权失败这种需要人工处理的问题也被反复重试，浪费了大量时间。后来区分开之后，告警能及时发出来，人工介入也更有针对性。

还有一个细节：降级后要不要自动恢复。我的做法是冷却时间到了之后，把provider重新标记为可用，但优先级临时降低，观察几次调用是否正常，正常了再恢复原优先级。这样避免provider刚恢复就被大量请求打挂。

4.3 日志与可观测性

多provider系统如果没有好的日志，出问题时会非常难排查。我要求每次调用都记录：时间戳、provider名、模型名、输入token数、输出token数、耗时、是否成功、失败原因。这些字段写到结构化日志里，方便后续分析。

import logging, json, time def log_call(provider, model, in_tokens, out_tokens, elapsed, success, error=None): logging.info(json.dumps({ "ts": time.time(), "provider": provider, "model": model, "in_tokens": in_tokens, "out_tokens": out_tokens, "elapsed_ms": int(elapsed * 1000), "success": success, "error": str(error) if error else None }))

有了这些日志，你可以很清楚地看到哪个provider最稳定、哪个最慢、哪个经常限流。我每个月会看一次这些数据，据此调整优先级配置。比如某个provider虽然免费但延迟很高，那它的优先级就该往后放，哪怕它额度还没用完。

5. 成本与稳定性的平衡：我的实际配置方案

5.1 分层配置：主力、备用、兜底

经过大半年的迭代，我现在的配置分三层：

主力层是两个相对稳定的provider，承担90%以上的日常调用。这两个的优先级最高，配置了较长的超时时间（60秒），因为主力层追求的是质量而不是速度。

备用层是两到三个免费额度类provider，优先级中等。它们的额度有限，所以只在主力层不可用时才启用。超时设短一些（20秒），因为备用层追求的是快速响应，慢一点就换下一个。

兜底层是本地模型，优先级最低，超时设最长（120秒），因为本地推理本来就慢，给它足够时间总比直接失败好。

这个分层的好处是成本可控。主力层如果是付费的，日常调用都走它，费用可预测；备用层只在故障时启用，不会产生意外开销；兜底层零成本，永远可用。

5.2 配置文件的组织方式

所有provider的配置我放在一个YAML文件里，代码启动时加载。这样改配置不用动代码，重启服务即可生效。

providers: - name: primary_a type: openai_compatible priority: 10 base_url: ${PRIMARY_A_URL} api_key: ${PRIMARY_A_KEY} model: some-model timeout: 60 daily_limit: 1000000 - name: backup_a type: gemini priority: 50 api_key: ${BACKUP_A_KEY} model: some-gemini-model timeout: 20 daily_limit: 50000 - name: local_fallback type: openai_compatible priority: 99 base_url: http://localhost:8000/v1 api_key: dummy model: local-model timeout: 120 daily_limit: 999999999

敏感信息用环境变量注入，不写死在文件里。这个习惯很重要，尤其是项目要开源或者多人协作的时候。

5.3 实测中的意外情况与处理

说几个我实际遇到过的、文档里不会写的情况。

第一个是"假成功"。有些provider在额度耗尽时不会返回错误码，而是返回一个空响应或者一段固定的提示文本。这种情况你的重试逻辑完全失效，因为从HTTP状态码看它是成功的。我的处理办法是在provider内部加一个响应校验：如果返回内容为空、或者长度异常短、或者包含特定的错误关键词，就当作失败处理，触发降级。

第二个是"慢速限流"。有些provider不直接拒绝，而是把你的请求排队，导致响应时间从2秒变成30秒。这种最恶心，因为你的超时设置如果太长，用户就一直等；太短又会误杀正常请求。我的做法是给每个provider设一个动态超时：前10次调用记录平均耗时，超时阈值设为平均值的3倍。这样能自适应不同provider的正常延迟水平。

第三个是"额度重置时间不确定"。有的provider按自然日重置，有的是滚动24小时，有的甚至是按周。这个只能靠观察。我一般会在额度耗尽后，每隔一段时间发一个探测请求，记录什么时候恢复，几次之后就能摸清规律，写进配置里。