OmniRoute 免费供应商排行榜的用量可靠性：24 小时真实成功率如何补上 ELO 排序的盲区

OmniRoute 免费供应商排行榜的用量可靠性24 小时真实成功率如何补上 ELO 排序的盲区【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute本篇指南围绕 OmniRoute 的 Free Provider Rankings免费供应商排行榜功能展开重点讲解 #11546 引入的用量可靠性usage reliability维度排行榜不再只看 Arena ELO 模型质量分而是叠加展示每个供应商过去 24 小时实际处理的请求数与成功率。读完本文你将理解该功能的完整数据链路——从 API 参数、call_logs聚合 SQL到小样本返回破折号的判定规则与前端展示逻辑并能据此做出更可靠的免费供应商接入决策。一、背景ELO 单维排序的盲区OmniRoute 注册了数百个供应商其中 150 余个目录条目标记为免费/免鉴权no-auth、免费档 OAuth 或免费档 API key。免费供应商的模型质量差异极大因此 OmniRoute 用Arena AILMArena 风格ELO 分对免费供应商的模型质量打分并在仪表盘的 Free Provider Rankings 页展示排名。但仅凭 ELO 排序存在一个致命盲区一个对所有请求都返回错误的供应商只要它的模型 ELO 高依然会排在第一位。连接状态connection state描述的是此刻的凭证与限流看不到这个供应商是否真的在成功服务流量。#11546 的修复思路是用量数据usage data此前已经由 API 提供但前端从未主动请求。现在排行榜页显式请求并在表格中展示每个供应商在最近 24 小时窗口内实际服务的请求量与成功率样本太小的供应商显示破折号—而不是一个没有统计意义的数字。二、数据来源三个真实信源的 Join排行榜的分数体系由三个真实来源计算而成详见 Free Provider Rankings 文档免费供应商清单NOAUTH_PROVIDERS加上标记hasFree的OAUTH_PROVIDERS/APIKEY_PROVIDERS条目定义于 src/shared/constants/providers.ts。模型目录来自 provider registryopen-sse/config/providerRegistry.ts并合并运营者手工添加的自定义模型src/lib/freeProviderRankings.ts 中的mergeProviderModels注册表条目在 ID 冲突时优先。ELO 派生的任务适配分由 Arena ELO 同步引擎src/lib/arenaEloSync.ts写入model_intelligence表source arena_elo。Join 逻辑位于 src/lib/freeProviderRankings.ts 的computeFreeProviderRankings对每个免费供应商的每个模型做三级模糊匹配findMatchingIntelligence精确匹配 → 去除尾部版本后缀如kimi-k2.6 → kimi-k2→ 前缀匹配然后取最高分模型作为Top Model、全体已评分模型的均值作为Avg Score供应商按 Top Model 分数降序、再按平均分排序。ELO 分数按榜单归一化到任务适配区间[0.4, 0.98]taskFit 0.4 0.58 * ((elo - minElo) / (maxElo - minElo))前端把分数渲染为人类可读标签Elite / Excellent / Very Good / Good / Average / Below Average因为它是相对排名质量而非百分比。三、API 层withUsage与usageRange参数排行榜页由公开只读端点 src/app/api/free-provider-rankings/route.ts 支撑查询参数经 Zod 校验GET /api/free-provider-rankings GET /api/free-provider-rankings?categorycodinglimit20 GET /api/free-provider-rankings?configuredOnly1withUsage1usageRange24h参数类型默认值说明categorystring无default、coding、review、documentation、debugging之一省略返回综合排名limitnumber50钳制到1–100非法值回退为 50configuredOnlybooleanfalse只保留至少配置了 1 条激活连接的供应商availableOnlybooleanfalse只保留至少 1 条未耗尽、未限流的连接隐含 configuredOnlywithUsagebooleanfalse追加每个供应商在窗口内实际服务的统计reliability.usageusageRangestring24h可选1h、24h、7d、30d拼写错误会被 400 拒绝而非静默改写窗口两个值得注意的实现细节布尔参数宽容解析、严格拒绝布尔参数会把1/true/yes统一转换为true路由文件中的boolParam而usageRange采用z.enum注释明确写道拒绝而非静默转换一个拼写错误不能悄悄返回与调用方要求不同的窗口。withUsage是纯增量、默认关闭因为它要付出一次对call_logs的聚合查询代价只关心排名的调用方不必为此买单。同时withUsage会连带加载连接快照——源码注释指出过去单独开withUsage会静默返回没有reliability的排名现在needsConnectionSnapshot会自动触发快照加载。响应形如{ rankings: [ { id: provider-id, name: provider name, category: noauth | oauth | apikey, topModel: { modelId: registry model id, modelName: model display name, score: 0.0, eloRaw: 0, confidence: high | medium | low }, averageScore: 0.0, modelCount: 0, reliability: { state: healthy | degraded | down, connections: [{ testStatus: null, rateLimitedUntil: null, state: healthy }], usage: { requests: 0, successes: 0, successRate: null, avgLatencyMs: null, lastRequestAt: null, windowHours: 24 } } } ] }四、用量统计的 SQL 层getProviderUsageSincewithUsage打开后引擎调用 src/lib/db/callLogStats.ts 中的getProviderUsageSince(since)在call_logs上做单窗口聚合SELECT c.provider, COUNT(*) as requests, SUM(CASE WHEN c.status 200 AND c.status 400 THEN 1 ELSE 0 END) as successes, ROUND(AVG(c.duration)) as avgLatencyMs, MAX(c.timestamp) as lastRequestAt FROM call_logs c WHERE c.provider IS NOT NULL AND c.provider ! - AND c.timestamp since AND EXISTS ( SELECT 1 FROM provider_connections pc WHERE pc.provider c.provider ) GROUP BY c.provider从源码结构看这条查询是有意不直接复用同文件的getProviderMetrics()后者带两个关联子查询而call_logs仅按timestamp建索引关联扫描会主导成本这里只保留排名真正需要的四列单次有界GROUP BY即可走idx_cl_timestamp。成功率的定义与邻居查询保持一致——2xx/3xx 计为成功EXISTS子句则保证已删除连接的供应商不会因历史日志残留为幽灵节点对应 #10714。窗口时长由usageRange决定复用健康矩阵RANGE_MS默认24h即 changelog 中过去 24 小时的由来。五、小样本规则为什么不足 5 次请求就显示破折号聚合结果经 src/lib/freeProviderRankings.ts 中的attachProviderUsage挂到每个排名的reliability.usage上其中核心判定是successRate: row.requests MIN_USAGE_REQUESTS ? row.successes / row.requests : null常量MIN_USAGE_REQUESTS 5约 L279源码注释解释得很直白2 次里挂 1 次不等于坏了一半没人调用过的供应商也不是0% 健康。样本量低于 5 时successRate置为null把没有把握下结论与成功率为 0区分开。展示侧由纯函数formatUsageReliabilitysrc/lib/freeProviderRankingsUsage.ts刻意零依赖、可被客户端组件直接引用把用量归为三种展示形态kind触发条件展示ratesuccessRate ! null窗口内 ≥ 5 次请求百分比数字如97%insufficientsuccessRate null且requests 00–4 次请求破折号—none窗口内无流量或未请求 usage破折号—百分比还按阈值着色good≥ 95%绿、fair≥ 80%黄、poor 80%橙破折号场景显示为中性色且三种形态都有各自的 tooltip 文案完整样本数、请求过少、无流量即 changelog 所说too small a sample shows a dash, not a number。六、前端排行榜页如何消费用量数据仪表盘页面位于 src/app/(dashboard)/dashboard/free-provider-rankings/page.tsx/dashboard/free-provider-rankings/page.tsx)入口为Costs → Free Provider Rankings或直接访问/dashboard/free-provider-rankings。页面包含Top-3 领奖台前三名免费供应商卡片完整排名表列为 Rank / Provider / Top Model / Score / Avg Score /Reliability/ Models / Type其中 Reliability 列就是 #11546 新增的 24 小时成功率列类别过滤按钮All Categories / Default / Coding / Review / Documentation / Debugging、可用性开关Configured only / Available only、Type 过滤与按 Type 分组排序客户端派生不触发重新请求。关键改动在请求构造处// Always: an ELO-only ranking describes a provider that errors on every // call as healthy. usageRange matches the health matrix default. params.set(withUsage, 1); params.set(usageRange, 24h);也就是说页面现在无条件附带withUsage1与usageRange24h——这正是 changelog 所说用量数据早已由 API 提供但此前从未被请求的落点修复不是新增数据能力而是把已有能力接进默认视图。Reliability 列与state连接当前状态互补state读的是连接此刻的样子看不见每次调用都报错的供应商只有调用日志能看见。七、ELO 分数体系的支撑机制用量维度建立在 ELO 分数体系之上理解以下机制有助于解读页面数据完整说明见 docs/guides/FREE_PROVIDER_RANKINGS.md数据源Arena AI 排行榜 API 的text与code两个榜单text映射到default/review/documentation/debugging类别code映射到coding。置信度按 Arena 投票数分档——high≥ 5,000 票、medium≥ 1,000、low 1,000。新鲜度条目写入model_intelligence表后7 天过期停止同步的供应商会自然掉出排名而不是提供陈旧数据。同步开关同步引擎默认开启服务启动时运行一次并周期执行非阻塞、永不致命上游拉取失败时排行榜展示最后一次有效数据或空态。两个环境变量见 ENVIRONMENT.md变量默认值用途ARENA_ELO_SYNC_ENABLEDtrue设为false可关闭出站同步ARENA_ELO_SYNC_INTERVAL8640024h同步间隔秒手动运维管理端点 src/app/api/intelligence/sync/route.ts需管理鉴权GET查看同步状态、POST触发手动同步body 可传{dryRun: true}预览、DELETE清除全部arena_elo条目。排行榜页为空时手动POST或重启服务即可重新填充。八、连接状态过滤与可靠性三态configuredOnly/availableOnly过滤与reliability标注复用同一份连接快照零额外查询。单条连接按健康矩阵同一词汇分类classifyConnectiontestStatus ∈ {credits_exhausted, banned, expired}→down终态不会自愈rateLimitedUntil仍在未来 →degraded限流冷却惰性恢复其余 →healthy。供应商级聚合规则为所有连接down则down任一非healthy则degraded否则healthy。需要留意的是availableOnly会直接丢弃无健康连接的供应商因此在该过滤下state不会出现down——down只在单独使用configuredOnly时可见。九、测试覆盖该功能的纯函数层均有独立单测可在仓库中直接查看验证tests/unit/freeProviderRankings-usage-display.test.ts覆盖formatUsageReliability的none/insufficient/rate分支与色调判定tests/unit/freeProviderRankings-filters.test.ts覆盖configuredOnly/availableOnly过滤与可靠性标注的纯函数行为。由于过滤、标注、展示判定都被拆成完全同步、无副作用的纯函数filterFreeProviderRankings、attachProviderReliability、attachProviderUsage、formatUsageReliability测试无需数据库即可断言全部边界。十、实战建议如何组合 ELO 与用量可靠性选供应商先看类别再看双维度代码任务用 Coding 过滤通用对话用 Default/All。同一供应商在不同类别排名可能不同其 Top Model 随榜单变化。Reliability 列优先于 ELO 分数做排除一个97%绿色成功率 Elite 分数的供应商是最佳接入目标ELO 高但成功率 80%橙色的供应商说明模型质量与实际交付存在落差应谨慎或等冷却结束后复看。破折号不是坏信号是未知信号—表示窗口内无流量或请求少于 5 次不构成失败证据可以先小额试用再评估。连接多个 Top 供应商交给 Auto-Combo 决策同一份 Arena ELO 数据也驱动 Auto-Combo 评分引擎的任务适配因子open-sse/services/autoCombo/taskFitness.ts解析顺序user_override → arena_elo → models_dev_tier → static table。接入头部免费供应商后以model: auto如auto/coding发请求即可按请求质量偏好自动路由完整 15 因子说明见 Auto-Combo 文档。接入凭证参考NOAUTH供应商无需凭证最快接入OAUTH/APIKEY免费档需要简单注册但常暴露更强的模型具体步骤见 Free Tiers Guide完整免费目录见 FREE_TIERS.md。小结#11546 的核心价值在于把模型理论上有多强ELO与实际交付是否可靠24 小时调用日志成功率放到同一张表里并以严格的样本量门槛≥ 5 次请求才给出百分比否则显示破折号避免小样本误导。整条链路——Zod 参数校验route.ts、有界窗口聚合 SQLcallLogStats.ts、小样本置空freeProviderRankings.ts、展示形态判定freeProviderRankingsUsage.ts——均可在仓库中按上述路径逐一核对。【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考