freellmapi
读书是学习,使用也是学习,而且是更重要的学习。—— 毛泽东
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 中列出的提供商包括:
- 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_format、seed 与 logprobs 等能力。
当某些提供商以纯文本形式表达工具调用时,路由器还可以将其恢复为实际的 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 | setup-claude |
每个生成器都支持 --dry-run。
生成器会合并到已有配置中,而不是直接覆盖原文件。对于已经存在的配置文件,它会先创建带时间戳的备份。--dry-run 则会先输出准确的差异,而不写入文件。
另外,launch 与 launch-codex 命令不会把凭据写入磁盘。它们只会在当前运行中,将凭据注入子进程环境。
这让编码代理的接入不必从零开始手工调整每一项配置。统一网关准备好之后,不同客户端可以通过对应生成器获得适合自己的连接方式。
桌面应用与自托管运行
FreeLLMAPI 提供原生菜单栏应用。
桌面应用会在本地运行整个路由器与仪表盘,并在系统托盘中提供显示实时请求统计的玻璃质感弹出界面。README 中说明,macOS 的 .dmg 与 Windows 的 .exe 安装程序会随发布版本提供。
对于自托管场景,项目支持 Docker,并提供一行安装方式:
1 | curl -fsSL https://freellmapi.co/install.sh | bash |
这条命令会创建 ~/freellmapi,生成加密密钥,拉取镜像并启动容器。
完成启动后,用户可以在本地仪表盘中添加提供商密钥,调整后备链顺序,并获取统一 API Key。
项目也支持本地开发。
1 | npm install |
这会启动运行在 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 出现时尝试后备路径。
它会在本地仪表盘中展示模型、密钥、请求与分析数据。
它也会通过签名模型目录,持续跟进免费模型世界的变化。
这不是一条通往无限模型资源的捷径。
它更像一个精心搭建的本地路由站:把原本散落在各处的免费模型入口接入其中,让请求、密钥、模型与后备链拥有更清晰的秩序。
