1 · 约 7 分钟阅读freellmapi 诚实使用评测 -- 把 412 个免费模型接到真实负载上会怎样
TL;DR
- freellmapi 是一个自托管统一 LLM 网关：把 34 家免费额度供应商、412 个目录模型收进一把 API 钥匙。我把它接上了真实负载 -- 记忆引擎的召回回路 -- 跑了三天。
- 先说结论：作为实验/备用通道强烈推荐，作为延迟敏感的生产环境不推荐。 付费小模型 21 秒完成的事，免费池花了 44~166 秒。
- 不过它的核心承诺 -- 免费模型自动路由 -- 是兑现了的：smartest 策略 5 次全部跑完、事实准确率满分。问题出在速度和语言一致性上。
- 本文基于 5 配置基准、141 模型池扩容和策略扫测的实测，零营销话术。
这是什么
freellmapi 把免费 LLM 供应商（AI Horde、NVIDIA、Cloudflare Workers AI、Groq、Google、OpenRouter 免费池，以及几十个社区网关）聚合起来，以单一的 OpenAI 兼容 /v1 端点对外服务。核心功能：
- 虚拟
auto模型 -- model 传 "auto"（或留空）由网关自选。策略预设：priority / balanced / smartest / fastest / reliable / custom / decision min_context_window下限 -- '32k/128k/512k/1m' 预设，把小上下文模型整体剔出路由池- 运营功能：profiles、粘性会话、响应缓存、配额观测、限流冷却
- 单个 sqlite 文件即可运行；仪表盘改设置热加载（无需重启）
我把它接到了自托管记忆引擎（Honcho）的召回回路（dialectic）上 -- 读取约 16K Token 的存储记忆并精确作答的任务。慢了糊了立刻穿帮。
三天，五种配置
同一协议（3 事实召回 × 5~10 次）：
| 配置 | 被路由的模型 | 平均延迟 | 事实准确率 | 语言 |
|---|---|---|---|---|
| 付费基线 (haiku-5.5) | - | 20.9s | 30/30 | 固定中文（韩） |
| smartest + 1M 下限 | nemotron-3-ultra-550b | 103.9s | 5/5 | 2/5 英文 |
| fastest + 1M 下限 | gemini-3.1-flash-lite | 11–15s | 0/5 ⚠ | 中文 |
| smartest + 128k 下限 | dots-3-note-preview | 85.8s | 4.5/5 | 中文 |
| ↑ 扩容 +141 模型后 | dots/nemotron/sensenova 每次不同 | 113.6s | 5/5 | 1/5 英文 |
三点解读。
1. fastest 策略不能用于召回。 11 秒出答案 -- 内容却是"正在关注质量提升"这类泛泛之谈，记忆里的数字（F1 目标、各轮得分）一个没带。又快又错不是目的。这不是网关的锅 -- 策略选择的责任在使用者 -- 但只看策略名字选的人一定会掉进这个坑。
2. 扩池不会变好。 把下限从 1M 降到 128k 后候选变多，路由一度稳定落在 dots-3-note-preview 这个不错的模型上。然后我又加了四家供应商的钥匙（+141 模型），路由反而更颠了 -- 每次调用换一个模型，平均延迟从 85.8s 涨到 113.6s。根因是免费池固有的状态波动和延迟方差，加候选数不是解药。
3. 目录排名不是现实。 目录里 intelligence rank 17 的 GLM 5.3 和 Qwen3.8 Max（1M 上下文）位列顶端 -- 但它们根本不可路由，因为对应平台没有活着的上游钥匙。"在目录里"和"能用"是两回事。补上钥匙能解决，但文档从不提示这条鸿沟。
亮点
- 免费池聚合真的能用。 我在 5 家供应商自动注册、加钥匙，141 个模型即时入列（profile 自动收录），smartest 轮完跑率满分。作为"免费实验一堆模型的基础设施"恰如其分。
- 热加载做得很彻底。 我直接改 sqlite 的
settings表，每次调用都会重读 DB -- 无需重启。运维者拨开关的体验很好。 - 可观测性开放到数据库层。
requests、decision_requests、provider_quota_state、rate_limit_cooldown表 -- "为什么选了这个模型"可以追踪。自托管的特权用得其所。 - 客户端兼容性。 同时接受 OpenAI/Anthropic/Gemini 头；一把统一钥匙。为强制非空 model 字段的客户端（如 Honcho）准备了虚拟
autoid，细节到位。
不足
- 延迟方差大。 同策略同查询：43 秒到 166 秒。这是免费池的天性，但想要"适度一致"就会失望。
- 语言轮盘。 每次调用路由到不同模型，回答在中文（韩语）和英文之间摇摆。对召回引擎是致命的。（可以用 system-prompt profile 强制语言 -- 只是我没开。）
- 文档只信源码。 Cloudflare 的钥匙必须是
account_id:api_token复合格式 -- 只写在代码里。仪表盘是 SPA，/openapi.json也不存在。自备铁锹。 - 粘性会话伤害基准复现性。 按消息哈希固定模型；没找到关闭开关。
适合谁
- 强烈推荐：免费模型扫测基准设施、备用/回退通道、以及回答"这个任务能不能用免费模型"。我的环境能一天筛完 141 个 dialectic 候选，全靠它。
- 不推荐：延迟敏感的生产（面向用户的召回/聊天）。付费小模型 21s / 100% / 固定语言的组合免费打不过 -- 今天再次确认。
- 有条件：慢点无所谓的深度任务（夜间批量摘要）与免费池 + smartest 很合拍 -- 但先用 profile 强制语言。
运维提示（全部亲踩）
- 上下文下限设 1M 会把池子收窄到 用量集中在少数供应商 -- 128k 才是实战甜点
- 设置可以直接改 sqlite 的
settings表（会热加载） - 客户端钥匙丢了可以从 DB 的
settings.unified_api_key找回 - 别信目录排名 -- 加完钥匙打一次真实
auto调用看实际路由
总评
作为实验基础设施 9/10，作为生产召回 4/10。 它诚实地解决了自己声称的问题（"免费模型收进一把钥匙"），运营功能的深度（配额观测、冷却、profile）超出预期。但免费池的物理规律 -- 延迟方差、模型波动、语言 -- 任何网关都解不了。freellmapi 把这份重量诚实地交还给用户。我喜欢这份诚实。
环境：自托管 freellmapi（docker），412 模型目录，2026-10-29~31。负载：Honcho dialectic 在 16K 记忆上下文上的召回。基线：OpenRouter 的 haiku-5.5。
导航
评论 (0)
TAGS