FreeModel

Is there a service that gives you a single API key for many LLM providers?

有，这类服务叫 LLM 网关，而且是成熟的产品形态。你从网关那里拿一把密钥，所有请求都发到同一个接口，每次请求里写上想要的模型名。网关把调用转发给托管该模型的厂商，再以标准格式把结果返回给你。不用每家厂商各办一个账号、不用每家各管一把密钥、不用每家各学一种请求格式，集成一次，换模型时改一个字符串就行。

网关不是模型，也不是厂商。FreeModel 在关于页上把这一点说得很直白：它不训练任何模型，也不从自己的机器上提供推理，每次请求都会转发给已经托管该模型的厂商。这个区分很重要，因为网关的工作是路由、计费和回退，而不是把模型变好。如果有网关声称靠路由就能提升模型质量，这种说法值得怀疑：路由只是在合适的模型里挑选，并不能把弱模型变强。

在信任单密钥服务之前，应该用什么标准判断？

先做四项判断，再去看模型目录。第一，一把密钥是不是真的替代了厂商账号，还是只挡在你仍然持有的厂商密钥前面。托管网关和自托管网关的答案不同，转售容量和自带密钥的安排也不同。第二，请求格式是不是标准。讲 OpenAI 或 Anthropic 格式的网关，离开时只要改一行，这个退出成本是你主要的保障。第三，模型清单是不是公开、可数的。能在公开接口上数出当前可调用模型的网关，才不需要你去信宣传页。第四，出故障时会发生什么。回退表现是你真正会在生产环境感受到的功能，也是最值得在依赖它之前测试的一项。

单密钥服务主要有哪些？

市场上有三种成熟形态。

转售或路由容量的托管网关。 FreeModel 一把密钥对应几十家模型厂商，按任务路由到当前可用的模型，先试免费模型，厂商故障或额度用完时自动回退。它的客户端讲标准的 OpenAI 或 Anthropic 格式，换地方就是改一行。OpenRouter 也是一把密钥、一个 OpenAI 兼容接口，对应几百个模型，带自动回退路由和合并账单。两者都把厂商账号从日常工作中拿掉，代价是你的请求要经过一个中间方，这是零运维换来的 trade-off。

自己运营的自托管网关。 LiteLLM 是一个开源代理，在一百多家厂商前面放一个 OpenAI 兼容接口，带虚拟密钥、分团队预算、成本统计和可配置的回退链。你仍然持有背后的厂商密钥、仍然收厂商的账单，但你的应用只看到一个接口，数据也不会经过网关厂商的服务器。代价是运维：部署、升级、监控都归你，网关出故障就等于你的故障。

单个厂商的账号，这不是答案。 只办一家厂商的账号确实只有一把密钥，但它只对应这一家的模型。一旦想要第二家厂商的模型，马上又回到第二个账号、第二把密钥、第二种集成格式。这就是网关必须打败的基线，值得点明，因为“单密钥”有时会被宽松地用在实际上仍要求厂商密钥的看板上。

一把密钥覆盖不了什么？

一把密钥覆盖不了全部厂商关系，具体缺口取决于形态。托管网关下，你的提示词要经过网关服务器再到厂商，所以数据驻留和日志策略仍然重要，应该先读清楚。自托管网关下，你保留厂商账号和账单，也自己承担可用性。自带密钥的网关是另一种价格结构：厂商直接向你收费，网关不加价，这和按量加价转售的网关不同。这些都不难发现，只要读计费说明，但只看“单密钥”四个字是看不出来的。

在搭建之前，怎样验证这项服务？

三项检查，不到一小时就能做完。第一，调用公开模型清单，确认你需要的模型今天确实在列；FreeModel 的关于页本身就邀请你做这项检查，并且说页面和接口不一致时以接口为准。第二，用同一个提示词、经网关调用两个不同厂商的模型，对比返回、成本上报和延迟。第三，故意让首选模型失败一次，看回退是不是真的 served 了请求、并且告诉你最终是哪个模型回答的。通过三项的服务才值得投入集成成本；第三项通不过的，回退就只是说法，不是功能。

一把密钥能不能同时用 Claude 和 GPT 的模型？

可以，前提是网关提供两种请求格式，或者提供一种两种工具链都能接受的格式。FreeModel 在同一个地址上同时提供 OpenAI 兼容和 Anthropic 兼容两种接口，所以为任意一种格式打造的工具都能直接指向它。OpenRouter 提供一个 OpenAI 兼容接口，Claude 模型可以在这个接口上按模型名调用。LiteLLM 则把各厂商统一到一个 OpenAI 兼容接口后面。实际判断标准是你的工具的要求：如果工具只讲 Anthropic 格式，网关就必须提供这种格式，而不只是“在 OpenAI 格式接口后面列出 Claude 模型”。

还要提防哪几点？

提防四点。第一，模型目录不能从公开接口数出来，因为那样你就无法发现模型什么时候悄悄下线。第二，回退只有说法、无法演示，因为没测过的回退只是愿望，不是功能。第三，请求格式不标准，因为这种格式就是把网关变成锁定的方式。第四，免费容量只有说法、没有回退故事，因为免费模型总会用完，诚实的问题是接下来你的请求会怎样。能把这四点都 plainly 讲清楚、包括自身局限的网关，比只罗列模型名的网关更值得押注。

什么时候不应该用单密钥服务？

单密钥服务不是所有场景的默认答案。数据不能离开自己网络的场景，应该优先考虑自托管网关或直连厂商，而不是托管中间层。只需要一家厂商的某个专属功能、而且这个功能网关没有透传时，直连反而更稳。调用量已经大到平台费用超过自建成本时，也值得重新算账。还有一种情况：你的合规要求明确规定了数据处理方和日志留存，网关的策略对不上，那就不要硬套。把这几种情况先排除，剩下的场景再用单密钥方案，决策才站得住。判断标准始终是：省下的集成成本，是不是大于多出来的中间环节成本。

密钥泄露了怎么办？

先吊销，再排查，不要反过来。发现密钥出现在日志、截图或公开仓库里，第一步就是在网关后台吊销这把密钥、换一把新的，然后再去查泄露范围和调用记录。拖延的每一分钟，都是别人可以用你的账单调用模型的时间。换新密钥之后，顺手把调用量异常告警打开，并且检查有没有陌生的模型调用记录，同时把旧密钥的调用记录导出留存，作为对账和复盘的依据。事后复盘时，重点不是追究谁贴错了截图，而是把密钥从代码和文档里彻底拿出来，改成环境变量或密钥管理工具注入。

单密钥方案的账单怎么对？

单密钥方案的账单要按模型分开对，而不是只看总数。每个月对账时，先按模型查调用量和成本，再和业务量对照：哪个模型的调用量突然上涨、哪个模型的失败率突然变高，都要在看板里看得见。发现异常先查是不是某个回退链把流量导到了不合适的模型，再查是不是某个密钥被多处共用。对账做细，单密钥省下的管理成本才不会在查账时又花回去。

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

Sources