为什么选「故障转移路由」这个角度
大多数聚合网关/中转站的免费额度都有三个共同特征：额度小、限速严、有效期短。单站硬撑必然断供。但如果你把 3–5 个站点的免费 Key 放进同一个路由层，按「主—备—兜底」编排，任何一家限流或赠额耗尽时自动切走，日常调用就几乎感觉不到断点。
这不是「多注册几个账号」的堆量思路，而是工程化的可用性设计：把免费额度当成不稳定上游，用路由层吸收抖动。
前置条件
- 一个可自托管的统一网关（如 One API / New API 这类开源网关，或 LiteLLM Proxy），支持多上游、权重、重试与故障转移。
- 2 个以上聚合网关/中转站的免费 Key（各家注册赠送额度，通常为小额试用金，具体数额以站点公告为准）。
- 一台能常驻的机器（本地 NAS、云上最小规格实例均可）。
操作步骤
第一步：给每个上游打「能力标签」
在网关里为每个聚合站建立独立渠道，并标注：
- 支持哪些模型（是否覆盖你常用的对话/Embedding 模型）
- 免费额度的性质（一次性试用金 / 每日刷新 / 限时活动）
- 限速档位（RPM、TPM 大致区间，用「约」估算即可）
这一步决定了路由顺序：把额度大、限速松的放主路，额度小、限速紧的放备路。
第二步：配置三层路由
- 主路：免费额度最大、模型覆盖最全的聚合站，权重设最高。
- 备路：额度中等但稳定性好的站点，主路 429/5xx 时自动接管。
- 兜底：额度最小但极少限流的站点，或你自己的本地 Ollama 小模型，保证「永远有响应」。
关键配置项：开启「失败重试 + 渠道自动禁用」，设置重试次数 2–3 次，失败后临时禁用该渠道若干分钟再恢复探测。
第三步：按模型做路由映射
不要把全部模型都指向同一渠道。做法是：
- 高频轻量模型（小参数对话模型）→ 优先走免费额度最耐用的站点；
- 大参数模型 → 只在主路可用时调用，主路不可用则降级到小模型，而不是强行切到备路烧额度。
第四步：加一层「额度哨兵」
写一个定时脚本（cron 即可），每 10–30 分钟调用各站点的余额/用量接口（多数聚合站控制台提供），把剩余额度写入网关的渠道权重：额度低于阈值就自动降权或禁用。这样你不需要手动盯盘。
第五步：本地兜底
在主备都不可用时，让网关回落到本地 Ollama（qwen 小参数版或 llama 小模型）。响应质量会下降，但工作流不断。
注意事项
- 合规边界：只用各站点公开提供的免费额度与自有 Key，不要用共享/转售 Key，也不要绕过站点限速。多数聚合站的服务条款禁止自动化批量注册与额度套利，违反会被封号。
- 有效期差异：一次性试用金通常有到期日，每日刷新额度则按天重置。路由权重应随有效期动态调整，快过期的渠道优先消耗。
- 模型名不一致：不同聚合站对同一模型的命名可能不同，需在网关里做别名映射，否则故障转移会因「模型不存在」而失败。
- 日志与成本可见性：开启网关的请求日志，定期核对各渠道实际消耗，避免某一渠道被悄悄打爆。
- 不要指望长期稳定：免费额度本质是营销成本，站点随时可能调整规则。路由层要设计成「可快速替换上游」，而不是深度绑定某一家。
适用场景
- 个人开发者做原型、跑 Agent 工作流、批量文本处理，预算为零但要求「基本不断供」。
- 小团队内部工具，需要在不采购商业额度的前提下维持可用。
- 作为正式付费额度上线前的过渡方案：先用路由层跑通业务，再逐步替换为稳定上游。
一句话总结
免费 Token 的稳定性不来自「哪家给得多」，而来自「你是否有能力在它断掉时无缝切走」。故障转移路由就是这套能力的工程实现。