读书是学习,使用也是学习,而且是更重要的学习。—— 毛泽东

FreeLLMAPI:把分散的免费模型额度,汇成一个统一的本地 API 入口

免费大语言模型服务并不少。

不同平台提供不同的免费额度,不同模型拥有不同的能力边界,不同接口又各自带着不同的认证方式、调用格式、速率限制与失败状态。单独看,它们像是一座座规模不大的岛屿。每一座岛都能提供一些资源,但开发者若想真正使用起来,就需要在不同 SDK、不同密钥、不同接口与不同规则之间反复穿梭。

FreeLLMAPI 试图把这些分散的入口汇聚起来。

它聚合多个提供商的免费层级,也支持自定义的 OpenAI 兼容聊天、嵌入、图像与音频端点,并将它们统一放在一个 /v1 API 之下。项目描述中给出了一个清晰的规模:每月约 74 亿 Token,覆盖 34 个免费大语言模型提供商与 635 个免费模型端点。

项目地址:https://github.com/tashfeenahmed/freellmapi

不再面对一长串彼此分离的模型入口

免费模型资源的真正难点,往往不是没有选择,而是选择太多。

一个提供商有自己的 SDK。

另一个提供商有不同的认证流程。

某个模型有自己的速率限制。

另一个模型又可能在请求时出现失败。

当这些服务被逐一接入时,开发者面对的并不只是模型能力本身,还包括大量重复的连接、配置与容错工作。

FreeLLMAPI 将这种分散感收拢为一个统一入口。

它把多个免费提供商的模型能力接入同一个 OpenAI 兼容 API,并允许用户通过一把统一的 API Key 发起请求。应用侧不必为每个上游服务分别保存调用逻辑,而可以面向 FreeLLMAPI 的统一接口进行连接。

这并不意味着上游模型失去了差异。

相反,模型、提供商、额度与速率限制仍然存在,只是这些复杂细节被放到路由器背后处理。请求从一个入口进入,再由路由器根据当前状态寻找适合的模型与密钥。

对于调用方来说,原本零散的模型世界,开始有了一个更集中的门厅。

34 个免费提供商与 635 个模型端点

FreeLLMAPI 的 README 将免费资源的聚合描述为一项核心能力。

项目当前追踪 34 个提供商、474 个模型家族与 635 个免费提供商模型端点。其中包含 584 个聊天端点、41 个嵌入端点、7 个转录端点与 3 个视频端点,并汇总出每月约 74 亿 Token 的免费层级容量。

这些数字并不是为了制造抽象的规模感。

它们描述的是一个现实:不同服务各自提供有限的免费额度,但当这些额度被集中管理、统一接入并通过路由能力协调后,开发者可以在一个本地运行的系统里管理更广泛的模型资源。

README 中列出的提供商包括:

  • Google
  • Groq
  • Cerebras
  • OpenCode
  • Mistral
  • OpenRouter
  • Cloudflare
  • Cohere
  • Z.ai
  • NVIDIA
  • HuggingFace
  • ModelScope

此外,还有更多免费提供商被纳入支持范围。

FreeLLMAPI 也支持自定义提供商。用户可以将聊天、嵌入、图像或音频模型指向任意兼容 OpenAI 的端点,包括本地或远程运行的兼容服务。

这让它不只是一个面向公共免费层级的聚合器,也可以成为连接自有兼容端点的统一网关。

一个请求进入,路由器负责寻找下一步

FreeLLMAPI 的核心角色,是路由器。

当请求进入后,路由器会在可用模型与密钥之间进行选择。它会寻找优先级更高、密钥健康、并且没有触及对应速率限制的模型。随后,密钥会在内存中被解密,并用于请求上游提供商。

如果上游请求出现 429 或 5xx 错误,路由器可以自动尝试备用模型。

这套过程包含了多个关键环节:

  • 根据速度、能力与可靠性评分排列模型链路
  • 在请求失败时尝试后备模型
  • 为模型设置冷却时间
  • 在可用密钥之间轮换
  • 跟踪每个密钥在不同平台与模型组合下的速率限制
  • 学习提供商报告的额度上限
  • 尽量让路由保持在各项限制之下

README 将这一能力称为智能路由,并提供六种路由策略。

模型并不是被简单地随机选择。

路由器会根据实时评分与健康状态来安排请求去向。速度、能力与可靠性共同参与模型链的排序,而速率限制则像一道持续存在的边界,提醒路由器不要把请求推向已经接近上限的位置。

在这样的设计里,路由不再只是转发。

它更像是一位守在多个模型入口前的调度者,观察哪些资源可用,哪些密钥健康,哪些路径需要暂时让开,然后把请求送向下一条合适的通道。

统一模型与命名配置

同一个模型可能会由不同提供商提供。

面对这种情况,FreeLLMAPI 可以将多个提供商上的同一模型收拢为一个统一条目,并在这一组内部进行严格的故障转移。

这让应用层不必总是面对大量相似却来源不同的模型名称。模型可以以更统一的形式出现在路由器中,而提供商差异则在内部的健康状态、配额与故障转移逻辑中继续发挥作用。

除此之外,FreeLLMAPI 还支持命名的后备链配置。

用户可以建立不同用途的模型链,例如面向编程的链路,或面向视觉任务的链路。应用调用时,可以让路由器自动选择,也可以指定相应的路由策略、配置文件或具体模型标识。

这种方式让模型选择不必只有两种极端。

不是只能完全手动指定每一个模型。

也不是必须把所有决定都交给自动选择。

用户可以为不同类型的工作组织不同的后备链,再让路由器在这条预先设定的路径中进行调度。

从聊天到图像、视频与语音

FreeLLMAPI 提供的并不只是聊天补全入口。

README 列出了多种 OpenAI 风格接口,包括聊天补全、响应接口、文本补全、图像生成、视频生成、音频语音等能力。它还支持 Anthropic Messages API 的线协议,并提供 Gemini 与 Ollama 相关接口表面。

其中,/v1/chat/completions 面向聊天补全。

/v1/responses 面向需要该接口形式的客户端。

/v1/completions 面向编辑器幽灵文本补全场景。

图像、视频与语音生成请求,则可以路由到提供相应媒体模型的上游提供商。

这使得统一 API 的含义不只限于文本对话。

聊天、嵌入、图像、视频、音频与转录等不同类型的模型能力,都可以进入同一个路由器的管理范围。对于应用来说,调用形式可以保持更一致,而具体请求由哪些上游资源承接,则由路由器结合当前模型与密钥状态处理。

工具调用与结构化输出也在路由范围内

现代模型调用经常不止要求返回一段文本。

应用可能需要模型输出结构化内容,也可能需要发起工具调用。FreeLLMAPI 支持 OpenAI 风格的 tools 往返调用,也支持 response_formatseedlogprobs 等能力。

当某些提供商以纯文本形式表达工具调用时,路由器还可以将其恢复为实际的 tool_calls

这让不同提供商之间的接口差异,不必完全暴露给应用层。

应用仍可以以统一的 OpenAI 风格调用工具相关能力,而路由器则承担一部分协议与表达形式上的协调工作。

Fusion:让多个模型共同参与一次回答

FreeLLMAPI 提供了名为 fusion 的虚拟模型。

当请求目标指定为 fusion 时,路由器会将提示词并行发送给一组不同的免费模型,再由一个评审模型将结果综合为一个答案。

这是一种多模型合成方式。

它不是把模型简单地排成前后顺序,而是让多个模型针对同一个请求并行给出结果,再由后续模型完成综合。对于路由器来说,这让一次请求不再只能依赖单一模型的输出,也可以组织多个模型共同参与回答过程。

对话可以保持黏性,也可以在切换时交接上下文

当一次对话持续进行时,频繁更换模型可能会让上下文体验变得不连贯。

FreeLLMAPI 为此提供了黏性会话能力。会话会在 30 分钟内尽量保持在同一个模型上。

如果对话中途确实发生模型切换,还可以启用紧凑的交接说明,以帮助后续模型保持对当前线程的理解。

这种机制让路由器不只是关注单个请求是否成功,也开始关注连续对话中的上下文延续。

模型切换有时是必要的。

额度可能耗尽。

上游可能失败。

某个模型可能进入冷却状态。

但切换并不意味着此前对话必须突然断裂。通过会话黏性与上下文交接,路由器可以在模型资源持续变化的环境中,尽量保持对话的连续性。

可选的提示词压缩

长上下文带来的压力并不只存在于模型侧,也会影响请求的体积与路由过程。

FreeLLMAPI 提供可选的提示词压缩能力。它位于共享请求管线之中,可以对提示词进行去重,过滤工具输出,压缩重复 JSON,并裁剪陈旧上下文。

这项能力采用故障开放方式。

也就是说,压缩流程并不应成为请求继续执行的硬性阻碍。它可以在缓存查找与路由之前参与请求处理,但整体设计仍然保留了请求继续向前的空间。

提示词压缩并不是默认强加给所有请求的步骤,而是一项可以选择启用的能力。它面向的是那些希望在上下文、工具输出与重复结构不断增长时,对请求内容进行整理的场景。

密钥只在本地保存,并在请求时于内存中使用

FreeLLMAPI 的设计强调本地优先与单用户使用。

提供商密钥保存在本地 SQLite 数据库中,并使用 AES-256-GCM 加密。请求到来时,密钥在内存中解密并用于调用上游服务。应用侧看到的,则是一把统一的 freellmapi-… Bearer Token。

这形成了一种清晰的分工。

应用只需要连接统一网关。

网关保存用户配置的提供商密钥。

请求从用户机器发往用户启用的上游提供商。

路由器承担密钥、模型、速率限制与故障转移的处理工作。

对于桌面应用而言,系统不需要额外设置密码。仪表盘通过隐藏的本地账户完成登录。对于服务器安装,如果忘记密码,可以通过登录页的找回入口获取一次性代码,该代码会输出到服务器日志中。

FreeLLMAPI 也明确说明,它是本地优先、面向单用户的设计。用户的提供商密钥保留在本地 SQLite 数据库中并以静态加密方式保存。

一块管理模型、密钥与请求状态的仪表盘

FreeLLMAPI 提供 React 管理界面。

在仪表盘中,用户可以管理提供商密钥,调整后备链顺序,使用 Playground 发起请求,并查看分析数据。界面支持深色与浅色主题,并提供 60 种语言。

模型页面用于选择路由策略,并观察跨多个提供商的月度 Token 预算。每个模型会展示实时可靠性、速度与智能评分,模型列表的顺序对应请求链路中的优先级。

密钥页面用于管理提供商凭据与统一 API Key。每把密钥会显示状态标识,并展示最近一次健康检查时间。

Playground 可以发送聊天补全请求,并在消息上显示实际服务请求的提供商、模型标识与延迟信息。它支持通过按钮、拖放或粘贴方式附加文件,包括图片、PDF、代码与文本。

分析页面则展示请求量、成功率、输入输出 Token、平均延迟,以及按提供商划分的数据。时间范围可以覆盖 24 小时、7 天、30 天与 90 天。

路由器在后台安排模型,仪表盘则把这些安排变成可观察的信息。

模型正在如何排序。

密钥是否健康。

请求由谁处理。

延迟处于什么状态。

不同提供商承担了多少请求。

这些原本隐藏在调用流程中的细节,可以在本地界面中被集中查看。

模型目录会自行更新

免费模型生态并不静止。

新模型会出现。

额度会调整。

提供商可能修改兼容细节。

某些接口也可能发生变化。

FreeLLMAPI 通过签名目录来跟踪这些变化。路由器会从目录源同步模型信息,并更新本地数据库中的新模型、额度变更与提供商兼容性修复。

下载内容会使用固定的 Ed25519 密钥进行验证。

用户自己的启用与禁用选择,以及自定义提供商配置,不会被目录更新覆盖。

免费安装使用月度快照。模型进入实时目录后,会在 30 天后加入免费版本使用的快照。README 说明,免费版本当前比实时目录少约 303 个模型,但功能不会因为这一差异而到期或被限制,只是新目录内容到达得更晚。

项目还提供实时目录服务。实时目录会持续同步到用户运行的路由器中,使新模型、额度变化与提供商兼容性修复能够更快抵达本地环境。

无论使用哪一种目录节奏,路由器都保持自托管状态。目录服务器不会看到用户的提示词、补全文本或提供商密钥。

面向编码代理与多种客户端的配置方式

FreeLLMAPI 可以被支持 OpenAI 兼容基础地址的客户端使用。

README 列出了多个兼容的命令行工具、编码代理与应用,包括:

  • Claude Code
  • Codex CLI
  • Gemini CLI
  • Aider
  • Cline
  • Roo Code
  • Continue
  • OpenCode
  • Goose
  • Qwen Code
  • Kilo Code
  • Crush
  • Cursor
  • Zed
  • JetBrains AI
  • DeepSeek Harness

此外,任何 OpenAI 兼容客户端、Anthropic SDK、Gemini SDK 或支持 Ollama 的应用,也都可以成为连接对象。

项目提供了一组配置生成命令。它们可以读取当前服务器实际提供的模型,并写入对应工具所需要的配置文件。

例如,配置 Claude Code 的形式为:

1
npx freellmapi setup-claude --url http://localhost:3001 --api-key <unified-key>

CLI 还提供多个面向不同工具的配置命令:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
setup-claude
setup-codex
setup-cline
setup-continue
setup-aider
setup-opencode
setup-goose
setup-qwen
setup-roo
setup-kilo
setup-crush
setup-dsh
setup-mimo
setup-cursor
setup-generic

每个生成器都支持 --dry-run

生成器会合并到已有配置中,而不是直接覆盖原文件。对于已经存在的配置文件,它会先创建带时间戳的备份。--dry-run 则会先输出准确的差异,而不写入文件。

另外,launchlaunch-codex 命令不会把凭据写入磁盘。它们只会在当前运行中,将凭据注入子进程环境。

这让编码代理的接入不必从零开始手工调整每一项配置。统一网关准备好之后,不同客户端可以通过对应生成器获得适合自己的连接方式。

桌面应用与自托管运行

FreeLLMAPI 提供原生菜单栏应用。

桌面应用会在本地运行整个路由器与仪表盘,并在系统托盘中提供显示实时请求统计的玻璃质感弹出界面。README 中说明,macOS 的 .dmg 与 Windows 的 .exe 安装程序会随发布版本提供。

对于自托管场景,项目支持 Docker,并提供一行安装方式:

1
curl -fsSL https://freellmapi.co/install.sh | bash

这条命令会创建 ~/freellmapi,生成加密密钥,拉取镜像并启动容器。

完成启动后,用户可以在本地仪表盘中添加提供商密钥,调整后备链顺序,并获取统一 API Key。

项目也支持本地开发。

1
2
npm install
npm run dev

这会启动运行在 3001 端口的服务端与运行在 5173 端口的仪表盘,并同时启用热模块替换。

FreeLLMAPI 可以运行在 Node.js 20 及以上版本支持的环境中,包括 Windows、macOS、Linux 服务器,以及树莓派等小型 ARM 单板设备。README 给出的空闲内存占用约为 40 MB RSS,并指出它可以运行在 PM2、systemd 或其他进程管理方式之下。

60 种语言的本地化界面

FreeLLMAPI 的仪表盘支持 60 种语言,桌面托盘菜单支持 6 种语言。

首次加载时,界面会自动检测浏览器或系统语言。用户也可以在设置中切换语言,选择会被记住。对于阿拉伯语、希伯来语、波斯语与乌尔都语等从右到左书写的语言,界面会自动翻转整体布局。

语言包加载也遵循按需原则。

只有当前激活语言对应的字典会被加载,其余语言包不会占用用户带宽。

这使多语言支持不只是将文字替换成不同语言,而是将语言选择、方向适配与加载策略一起纳入界面体验中。

免费资源并不等于稳定生产资源

FreeLLMAPI 对自己的定位非常明确。

项目用于个人实验与学习,而不是生产环境。

免费层级适合开发者进行原型验证,但它们并不是稳定且受支持的推理基础设施。README 也直接列出了免费层级叠加后的现实取舍:

  • 没有前沿模型
  • 延迟存在波动
  • 没有服务等级协议
  • 随着高优先级模型在一天后期接近每日额度上限,端点的实际智能水平可能下降

这段说明很重要。

FreeLLMAPI 将大量免费资源聚合在一起,确实让模型调用有了更统一、更灵活的入口。但免费层级本身仍然带着额度、速度、可靠性与上游变化带来的限制。

路由器能够在这些限制之间调度。

它可以选择健康密钥。

它可以跟踪限额。

它可以在失败时切换后备模型。

它可以利用模型目录跟进模型与配额变化。

但它并不会把免费资源变成没有边界的稳定生产服务。

因此,FreeLLMAPI 的舞台更适合个人实验、学习、原型与探索。

结语

FreeLLMAPI 面对的是一个很真实的问题:免费模型并不稀缺,真正稀缺的是把它们组织起来的方式。

当多个提供商、不同模型、不同密钥、不同限额与不同接口被同时摆在面前时,开发者很容易被接入与维护工作拖慢。FreeLLMAPI 则将它们汇入一个本地运行的统一网关,用单一 /v1 API 接住聊天、嵌入、图像、视频、语音与更多模型调用需求。

它会保存加密密钥。

它会跟踪每把密钥的速率限制。

它会根据实时评分与健康状态安排模型。

它会在 429 与 5xx 出现时尝试后备路径。

它会在本地仪表盘中展示模型、密钥、请求与分析数据。

它也会通过签名模型目录,持续跟进免费模型世界的变化。

这不是一条通往无限模型资源的捷径。

它更像一个精心搭建的本地路由站:把原本散落在各处的免费模型入口接入其中,让请求、密钥、模型与后备链拥有更清晰的秩序。