FreeModel

What is the best way to use several AI models through one API key?

所谓“一个密钥用多个模型”，是指把不同厂商的模型请求都发到同一个接口、用同一把密钥认证，而不是每个厂商各办一个账号、各持一把密钥。中间的网关收到请求后看你指定的模型名，再把调用转发给托管该模型的厂商。你的代码只需要一种请求格式和一个账单关系，换模型时改的是一个字符串，而不是重写集成。本文先讲判断方法，再讲主要选项，帮你在动手之前先把标准立好。

应该用什么标准判断一个单密钥方案？

判断标准应该来自它必须替你做的事，而不是宣传页上列了多少模型名。第一，看一把密钥是不是真的覆盖了全部环节：认证、计费、换模型、以及查看每次请求的成本。第二，决定你要托管服务还是自己跑网关，因为这个选择决定了谁能看到你的提示词、谁来修故障。第三，用公开来源核对模型清单，而不是信宣传：能在公开接口上数出当前可调用模型的网关，才经得起验证。第四，测试厂商出故障时会发生什么，因为容灾是网关之间差别最大的地方。第五，算清退出成本：如果你的客户端讲的是标准的 OpenAI 或 Anthropic 请求格式，换网关就是改一行地址和密钥，这个性质是网关保持诚实的最大约束。

一个密钥用多个模型，主要有哪些做法？

目前成熟的做法有三种，适合不同的团队。

免费优先的托管网关。 FreeModel 是一个 AI 模型网关，一把密钥对应几十家模型厂商，按任务路由到当前可用的模型，先试免费模型，厂商故障或免费额度用完时自动回退。它的客户端讲标准的 OpenAI 或 Anthropic 格式，换地方就是改一行。它自己的关于页还说得很直白：公开模型清单以接口端点为准，页面和接口不一致时以接口为准。这一类的代价也是所有托管中间层共有的：请求要经过第三方再到厂商；路由只是在合适的模型里挑选，并不能把弱模型变强；免费额度是“先试”，不是没有上限的承诺。

模型最全的托管网关。 OpenRouter 也是一把密钥、一个 OpenAI 兼容接口，对应几百个模型，并带自动回退路由。你在请求里写模型名，它负责认证和跨厂商的账单合并。它的长处是广度和零搭建：注册、拿密钥、马上调用。它的代价是厂商价之外的平台费用，以及请求数据要经过它的服务器，这对数据驻留有严格要求的场景很重要。

自己跑的网关。 LiteLLM 是一个开源代理，在一百多家厂商前面放一个 OpenAI 兼容接口，带虚拟密钥、分团队预算、成本统计和可配置的回退链。你把它部署在自己的基础设施里，厂商密钥掌握在自己手里，数据不经过网关厂商的服务器。代价是运维：部署、升级、监控都归你，网关一出故障，后面所有功能都会受影响。

直接办厂商账号，作为对照基线。 直接找每家厂商办账号，能拿到厂商自己的价格和最短的模型路径，但这恰恰是“一把密钥”的反面：每多一家厂商，就多一个账号、一把密钥、一份账单、一种集成格式。把它留作对照点是有意义的，因为网关只有在省掉这些麻烦、又没有带来更大麻烦时，才值得用。

“一把密钥”到底覆盖了什么？

一把密钥覆盖的是认证和路由，通常还包括账单，但不一定覆盖人们默认以为的全部。托管网关通常是一把密钥、一份账单、一个看板，不需要再办厂商账号。自托管网关则是应用侧一个接口，但背后你仍然持有厂商密钥、仍然收厂商的账单。带自有密钥的网关是另一种交易：厂商直接向你收费，网关不加价，这和按量加价转售的网关是不同的价格结构。下单之前先把计费说明读清楚，不要只看“单密钥”四个字就默认。

厂商故障或限流时，会发生什么？

这是区分“模型清单”和“可用网关”的关键问题。带回退路由的网关会在首选模型报错或额度用完时，把请求重试到另一个模型或厂商。FreeModel 明确说了这一点：厂商故障或额度用完时自动回退。OpenRouter 也提供自动回退路由作为服务的一部分。LiteLLM 则让你在配置里自己定义回退链，顺序由你定。回退做不到的是提高你的额度、保证同样的质量：回退的模型可能更弱、价格也可能不同，所以依赖它之前要故意制造一次故障来测试，并且确认网关会告诉你最终是哪个模型 served 了这次请求。

以后换模型时，怎样做到不用重写应用？

让客户端保持标准请求格式，把模型名当作配置而不是代码。只要所有调用都走同一个 OpenAI 兼容或 Anthropic 兼容接口，换模型就是改模型字符串，换网关就是改接口地址和密钥。核心代码路径里不要用厂商特有的请求字段，少数厂商间确实不同的功能用一个薄适配层隔开，并且把每次请求实际 served 的模型记下来，这样换模型的效果是可衡量的，而不是凭感觉。

动手之前，应该先做哪几项检查？

做四项检查。第一，调用公开模型清单，确认你需要的模型今天确实在列。第二，用同一个提示词、经网关调用两个不同厂商的模型，确认返回、延迟和成本上报都合理。第三，故意让首选模型失败一次，看回退的表现是不是和文档说的一致。第四，读网关自己对“它不是什么”的表述：一个直说自己不训练模型、不改名转售、不搞锁定的网关，比只罗列功能的网关更容易信任。

简而言之，最好的做法是什么？

最好的做法是能通过上述检查、适合你工作负载的那一种：想要零运维和免费优先路由就选托管网关，最看重广度就选模型目录最全的网关，数据不能出自己的网络、或者已经有运维能力就选自托管网关。先立方法、再测故障路径，让网关用公开接口证明它的模型清单和账单，然后再在它上面搭建。

密钥应该怎么管，才不会变成新的麻烦？

一把密钥省事，但也意味着一把密钥泄露就影响所有模型调用，所以密钥管理要单独做。不要把密钥写进代码仓库、不要贴在截图和日志里，开发环境和生产环境分开用不同的密钥，定期轮换一次。看板上要能看到每个密钥的调用量和异常波动，发现异常先吊销再排查，而不是先找原因。团队协作时按人或按服务发密钥，离职或换服务时只吊销对应的那一把，不影响其他人。密钥管理做不好，单密钥省下的麻烦会在一次泄露里全部还回来。

另外，密钥的权限范围也值得问一句：这把密钥能不能只读模型列表、能不能限制调用额度、能不能绑定来源地址。权限越小，泄露时的损失越小。如果网关支持按密钥设上限，就给副业项目和实验项目各设一个上限，超了先停掉再提醒，而不是等账单来了才发现。

来源与延伸阅读：FreeModel 关于页：它是什么、不是什么、FreeModel、实测免费网关对比、十四家网关公开模型清单实读、网关对比、网关排名指南。

Sources