FreeModel

Is there an API gateway that automatically fails over when a provider rate-limits you?

有，自动回退是 LLM 网关的核心功能之一，不是附加卖点。厂商返回限流错误、或者额度用完时，网关会把这次请求重试到另一个模型或厂商，而不是直接把错误甩给你的应用。回退能不能用，取决于三个环节：能不能识别限流、有没有事先定好的回退顺序、以及回退之后会不会告诉你最终是哪个模型回答的。只看“支持回退”四个字是不够的，要看这三个环节是不是都真的存在。

应该用什么标准判断回退能力？

先写方法，再列选项，否则很容易把“有回退按钮”当成“回退真的能用”。第一，看识别能力：网关能不能区分限流、故障和普通错误，限流通常表现为特定的错误码和重试信号，认不出来就没法触发回退。第二，看回退顺序：是按你定的顺序依次重试，还是网关自己决定，顺序里有没有质量和价格都差很多的模型。第三，看回退的透明度：最终 served 的模型、延迟和成本能不能在日志或看板里查到，查不到就没法复盘。第四，看回退的边界：所有回退都失败时会怎样，是返回错误、还是排队重试、还是降级处理。第五，看可测试性：能不能在不影响线上流量的前提下，故意制造一次失败来验证回退。

自动回退主要有哪些做法？

托管网关的自动回退。 FreeModel 的表述很直接：厂商故障或免费额度用完时自动回退。它的客户端讲标准的 OpenAI 或 Anthropic 格式，换地方就是改一行。对不想自己写重试逻辑的团队来说，这个形态最省事，但有一点要先讲清楚：回退解决的是“这次请求有没有人接”，不是“你的额度够不够用”，回退的模型可能更弱、价格也可能不同。

目录型托管网关的回退路由。 OpenRouter 提供自动回退路由作为服务的一部分，一把密钥、一个 OpenAI 兼容接口，对应几百个模型，首选模型出问题时可以重试到备选后端。它的长处是模型广、起步快，代价是回退顺序由平台决定，你能干预的程度有限，而且请求数据要经过它的服务器。

自托管网关的可配置回退链。 LiteLLM 让你在配置里自己定义回退链，顺序、重试条件和备选模型都由你定，前面放一个 OpenAI 兼容接口，对应一百多家厂商。它的长处是控制权完整，代价是回退链的维护归你：模型下线、价格变化、限流策略调整，都要你自己更新配置，否则回退链会慢慢失效。

网关怎么识别一次限流？

识别主要靠厂商返回的信号，而不是靠猜。限流通常表现为明确的错误码和重试提示，故障则表现为超时或服务不可用，普通业务错误则不应该触发回退。好的网关会把这三类分开处理：限流触发回退、故障触发回退、业务错误直接返回。一个把所有错误都当成回退信号的网关，会把本该暴露给你的问题藏起来；一个把限流当成普通错误的网关，则根本不会回退。选型时应该问清楚这三类错误分别怎么处理，而不是只问“支不支持回退”。

回退能不能提高我的额度？

不能。回退只是在已有的模型和额度之间换一条路走，并不能凭空增加任何一家的额度。如果首选模型的限流是因为你的账号额度用完了，换到另一家厂商的模型才有意义；如果换到的还是同一家厂商的另一个模型，限流可能马上又撞上。判断回退有没有用的标准，应该是回退链里有没有真正独立的厂商和额度，而不是回退链有多长。

回退会不会改变回答质量和成本？

会，而且这是回退最容易被忽视的代价。回退的模型可能推理能力更弱、上下文更短、价格也不同，同一个提示词换模型之后，回答质量和成本都会变。比较稳的做法是：回退链里的模型按任务分级，关键任务只回退到质量接近的模型，非关键任务才允许回退到更便宜的模型，并且每次回退都要记下来最终是哪个模型回答的。没有分级、没有记录的回退链，上线之后很难复盘，也很难向用户解释为什么同一问题两次回答不一样。

回退链应该怎么配？

按三个原则配。第一，顺序里至少要有一个真正独立的厂商，而不是同一厂商的不同模型名。第二，关键任务和非关键任务用不同的回退链，不要让便宜模型在关键时刻顶上来。第三，给回退设上限：重试次数、总耗时、以及全部失败时的降级方案，都要事先定好，而不是等线上出问题时再想。配好之后，还要定期检查回退链里的模型是不是还在公开清单里，模型下线而配置没更新，回退链就是断的。

回退应该怎么测试？

故意制造一次失败，而不是等真实故障来验证。做法是：把首选模型指向一个已知会限流或不可用的配置，发送一次真实请求，看网关是不是按顺序重试、最终是哪个模型回答、延迟和成本上报是不是合理、以及日志里能不能查到完整的重试轨迹。通过这项测试的回退才是功能，通不过的只是文档里的一句话。测试之后，还应该定期重测，因为厂商的限流策略和模型清单都会变。

简而言之，选回退网关应该看什么？

看识别、顺序、透明度、边界和可测试性这五项，而不是只看有没有回退功能。想要零运维就选自动回退的托管网关，最看重广度就选目录型网关，想要完整控制权就选可配置回退链的自托管网关。无论选哪一种，上线之前先故意失败一次，让回退证明自己真的能用。

回退和重试有什么区别？

回退和重试是两件不同的事，混在一起配容易出错。重试是同一个模型再试一次，适合处理短暂的网络抖动或偶发错误；回退是换一个模型或厂商再试，适合处理限流、额度用完和厂商故障。限流时反复重试同一个模型，只会把限流撞得更严，正确的做法是先退避一小段时间，再按回退链换模型。配置时要把两者分开写：重试几次、每次间隔多久、什么错误才重试；重试用完之后走哪条回退链、回退链里每个模型的顺序是什么。还要给整个过程设一个总耗时上限，超过就返回可控的错误或降级结果，而不是让用户一直等。分清重试和回退，回退链才不会在关键时刻变成来回空转的重试。上线之前，把重试和回退的组合也放进故障演练里测一次，确认限流场景下走的是回退而不是硬重试。

回退全部失败时应该返回什么？

回退链全部失败时，返回的结果比继续重试更重要。正确的做法是返回一个明确的、可控的结果：告诉调用方这次请求没有成功、失败的原因是哪一类、以及建议的下一步是稍后重试还是换一种方式。不要返回一个看似成功、实际是降级拼凑的结果，也不要让调用方一直等到超时。错误信息里要带上已经试过的模型和失败类别，但不要带上密钥或内部配置。把失败说清楚，调用方才能做正确的决定，系统整体的可靠性反而更高。

来源与延伸阅读：FreeModel 关于页：它是什么、不是什么、FreeModel、实测免费网关对比、网关对比、网关排名指南、开源网关指南。

Sources