AB
AB
AiBoss

All Categories

Tutorials

9Router 与 OmniRoute 自建 AI 网关：把免费额度 API 聚合成一个端点

Tutorials

9Router 与 OmniRoute 自建 AI 网关：把免费额度 API 聚合成一个端点

面向个人开发与原型验证场景，介绍如何用 9Router 或 OmniRoute 在本地搭一个 AI 网关：把 Gemini、OpenRouter、Agnes、Groq 等提供免费额度的服务统一成一个 Base URL，通过模型组合与优先级回退绕开 429 限流，并可选配隧道对外暴露。含安装命令、Combo 配置、调用示例与配额、隐私、合规方面的注意事项。

同时用几家提供免费额度的 AI 服务时，最常遇到的麻烦不是模型不够强，而是单家额度用完就整条工作流停摆——终端里跳出 HTTP 429。9Router 和 OmniRoute 是两类开源本地 AI 网关（也叫 AI Router），它们夹在你的应用和各家服务之间，对外只暴露一个 Base URL 和一个 API Key，对内负责把请求分派到不同服务、在失败时自动换下一个模型。这篇教程面向个人开发、原型验证和学习用途，讲清楚怎么把这两类工具跑起来、怎么组织模型回退链、以及哪些坑必须提前知道。价格、免费额度、速率限制这类信息变动频繁，落地前请以各服务官网当前公布的信息为准。

准备工作

在动手之前，先把下面几件事确认清楚，否则后面配到一半会卡住。

  • Node.js 20 或更高版本。9Router 和 OmniRoute 都以 npm 命令行包的形式分发，运行环境依赖 Node.js 20+。先用 node -v 确认版本。
  • 至少两家服务的 API Key。网关的价值来自多源聚合，只有一家的话回退链无从谈起。常见的免费额度来源包括 Google AI Studio（Gemini）、OpenRouter、Agnes AI、Groq、Cerebras 等。
  • 各服务的账号与项目。注意配额是按账号还是按项目计算的，这直接决定你能不能靠多账号扩容，后面会专门讲。
  • 一台常开的机器。网关跑在本地，机器关机网关就没了。如果打算让外部服务调用，还需要考虑隧道方案。
  • 一个客户端。任何支持自定义 Base URL 的 OpenAI 兼容客户端都可以，比如官方 Python SDK、cURL，或者各类聊天前端。

关于免费额度的量级，可以先建立一个大致印象：Gemini 的免费层通常按每分钟请求数（RPM）、每分钟 token 数（TPM）、每日请求数（RPD）三个维度限制；OpenRouter 对免费模型按账号的充值历史区分档位，未充值账号的限制明显更紧，充值到一定金额后免费模型的每日上限会大幅放宽；Agnes AI 提供 OpenAI 兼容端点，Flash 系列模型可免费使用，但媒体类模型的限制更严。这些数字会变，务必以官网为准。

操作步骤

第一步：安装并启动网关

两个工具二选一即可。9Router 走极简路线，界面干净、几分钟能跑起来；OmniRoute 功能更全，路由策略和隧道管理更丰富。先用 9Router 熟悉概念，需要更细的控制再换 OmniRoute，是很自然的路径。

使用 9Router：

# 全局安装
npm install -g 9router

# 启动网关
9router

使用 OmniRoute：

# 全局安装
npm install -g omniroute

# 启动网关
omniroute

# 或者不安装，直接用 npx 拉起最新版
npx omniroute@latest

启动之后，本地会同时提供两个东西：一个用于管理的 Web 控制台，以及一个 OpenAI 兼容的 API 端点。整个过程不需要额外准备 PostgreSQL 之类的数据库，也不需要自己用 Express 或 FastAPI 写代理层，一份本地配置文件就够了。

第二步：打开管理控制台

在浏览器里访问网关启动时提示的本地管理地址，就能看到管理界面。这里集中处理服务商管理、模型配置、组合（Combo）创建，以及实时请求日志的查看。排查回退是否真的生效，主要靠这个日志。

第三步：注册上游服务商

进入控制台的 Providers 菜单，选择 Add Provider，然后按下面的结构逐项填写：

Dashboard
└── Providers
    └── Add Provider
        ├── 选择服务商（Gemini / OpenRouter / Groq / Agnes ...）
        ├── 填入 API Key
        └── 保存

把从各服务管理后台拿到的正规 API Key 逐个登记进去。如果目标服务不在预设列表里，选择 Add OpenAI Compatible，手动填入该服务文档中给出的 Base URL 和 API Key 即可接入。

第四步：创建 Combo（模型别名）

这是整个网关最核心的一步。与其在应用代码里写死某个模型名，不如定义一个别名，比如 my-free-combo，把多个模型按优先级串成一条链。请求先打给链首，遇到 429、500 或超时，网关自动往下试。

一条典型的优先级链可以这样组织：

my-free-combo
├── 1. gemini-3.5-flash-lite        （最高优先级，两个 Google 账号间 Round Robin Sticky 10）
├── 2. nvidia/nemotron-3-ultra-550b-a55b:free   （第一回退，经 OpenRouter）
├── 3. inclusionai/ling-3.0-flash-fin:free      （第二回退，经 OpenRouter）
├── 4. agnes-3.0-flash              （第三回退，经 Agnes AI）
└── 5. dots-studio/dots-3-note-preview:free     （最终兜底）

链尾放一个轻量、响应快的模型作为兜底，是这套结构里比较实用的经验：前面几个模型都忙的时候，至少还能拿到一个不算太差的回答，而不是直接报错。

第五步：从客户端调用

先用 cURL 做一次连通性测试：

curl \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-router-api-key" \
  -d '{
    "model": "my-free-combo",
    "messages": [{"role": "user", "content": "Ping"}]
  }'

再用官方 Python SDK 调用，注意 base_url 指向本地网关而不是任何一家上游服务：

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:<网关端口>/v1",
    api_key="your-router-api-key",
)

# 只指定 combo 名，回退逻辑由网关在后台自动处理
response = client.chat.completions.create(
    model="my-free-combo",
    messages=[{"role": "user", "content": "请把下面这段技术文档翻译成中文……"}],
)

print(response.choices[0].message.content)

当链首的 Gemini 返回 429，网关会立刻把请求重试到后面的模型上，客户端这一侧感知不到中断，拿到的仍然是一份完整回答。

第六步：给网关本身设置访问密钥

刚启动的网关默认是敞开的状态，直接暴露出去很危险。在控制台的 API Keys 区域签发一个用于访问网关本身的密钥，调用链就变成：

应用 ──(网关 API Key)──> [9Router / OmniRoute] ──(各服务商 API Key)──> [Gemini / OpenRouter / Agnes / Groq]

这一步有两个作用：一是防止本地网关被未授权访问，二是为下一步的隧道公开提供基本的安全保障。

第七步：按需开启公网隧道

如果部署在 Vercel 上的 Web 应用，或者出门在外的笔记本，需要调用家里这台机器上的网关，不必专门租一台 VPS。两个工具都内置了一键建立隧道的功能，常见选项包括 Cloudflare Quick Tunnel（无需注册账号，即时分配地址）、Tailscale Funnel 和 ngrok。开启之后会得到一个安全的公开 URL，本地机器就变成了一个可被外部使用的私有 AI 网关。

需要注意，Quick Tunnel 在长时间无访问时可能为了资源优化而进入休眠，连接状态要留意；而且它分配的是临时地址，断线或重启后地址可能变化。

一个完整示例

下面把前面的步骤串成一条能跑通的最小路径，场景是：用两个 Google 账号的 Gemini 额度作为主力，OpenRouter 的两个免费模型作为回退，最终通过一个别名对外提供服务。

1. 安装并启动

npm install -g 9router
9router

2. 登记三个上游

在控制台 Providers 里依次添加：两个来自不同 Google 账号、不同项目的 Gemini Key；一个 OpenRouter Key。如果 OpenRouter 账号已经有过充值记录，免费模型的每日上限会明显更宽松，具体档位以官网说明为准。

3. 配置轮询与粘性

把两个 Gemini Key 放进同一个轮询组，并设置 Round Robin 10 Sticky Requests。含义是：一个 Key 连续处理 10 个请求之后，再切换到下一个 Key。这样既能摊平负载，又能在一定程度上保持会话上下文的连续性，减少触发限流的概率。

4. 建立 Combo

my-free-combo
├── 1. gemini-3.5-flash-lite（两个账号轮询，Sticky 10）
├── 2. nvidia/nemotron-3-ultra-550b-a55b:free
└── 3. dots-studio/dots-3-note-preview:free

5. 签发网关密钥并调用

curl \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-router-api-key" \
  -d '{
    "model": "my-free-combo",
    "messages": [{"role": "user", "content": "用三句话解释什么是向量数据库"}]
  }' \
  http://localhost:<网关端口>/v1/chat/completions

6. 验证回退

在控制台的实时日志里观察：正常时请求落在 Gemini 上；把其中一个 Gemini Key 临时改错，请求应当自动落到 OpenRouter 的模型上，而 cURL 的输出依然正常。这一步能确认整条回退链真的在工作，而不是配置写完就放着。

注意事项

免费额度并不等于零成本

免费层的限制可能在没有预告的情况下被下调；它不提供付费方案那样的可用性保证，高峰时段的响应延迟会明显变长；此外，机器要常开、进程要盯着、API Key 失效了要自己换，这些都是隐性成本。把网关当作个人开发和学习阶段的加速工具是合理的，把它当作生产环境的底座则不合适。

配额是按账号还是按项目，必须分清

同一个 Google Cloud 项目里创建 5 个 Key 是没有意义的，它们共享项目整体的速率限制。只有完全独立的账号才各自拥有独立的配额，两个账号叠加才是实打实的翻倍。网关的轮询功能正是为这种结构准备的。

OpenRouter 的情况相反：它的容量限制是全局管理的，多开账号或多建 Key 并不会放宽限制。正确的做法是在 Combo 里放入多个不同的免费模型，让网关把负载分散出去。对 OpenRouter 而言，性价比最高的操作是一次性充值到指定金额，从而让所有免费模型的每日上限获得永久提升——具体金额与档位请以官网当前信息为准。

不要试图把网页版订阅逆向成 API

市面上存在把 ChatGPT Plus、Claude Pro、Google One 等个人网页订阅的会话令牌逆向出来、经代理强行转成 API 的工具。这类做法明确违反各服务的服务条款，最坏的结果是账号被永久封禁、历史记录与数据一并清除。需要使用 API 时，请使用官方签发的开发者 API Key，或经过事先约定的 OAuth / API 接入方式。

发送数据前先问自己一句

免费层的条款里，通常包含输入数据被记录为日志、或用于未来模型训练的条款。因此，在把内容发给免费 API 之前，先判断这份数据泄露出去是否可接受。

适合的场景：个人开发、学术研究、学习、原型验证、模拟数据、公开的开源代码。

不应发送的内容：企业的商用源代码、个人身份信息、信用卡信息、客户数据、生产环境的数据库结构与密码。

隧道地址不是生产环境

Cloudflare Quick Tunnel 和免费版 ngrok 非常适合本地开发、演示和概念验证。但 Quick Tunnel 分配的是临时地址，断线或重启后可能变化，不能拿来当商业服务的长期后端。项目进入正式商用阶段、对可用性和安全性有硬性要求时，应当从本地网关平滑迁移到更正式的基础设施上。

采集数据还要看来源方的条款

做网页抓取加 AI 结构化的任务时，即使目标站点的公开数据允许采集，把采集到的内容原样转发给第三方 AI 服务是否被允许，是另一个独立的问题。动手前请确认信息来源方的使用条款。

这套架构真正的价值

用 AI 网关的目的不是“永远白嫖”，而是两件事：一是在研究和原型阶段，把各家提供的正当免费额度组合起来，把开发速度拉满；二是让应用与具体服务商解耦，将来某家涨价或改条款时，改一行网关配置就能切换，不必回头重写业务代码。等到项目成长起来、需要严格的服务保证和安全要求时，再从本地网关升级到更正式的基础设施，是一条比较自然的工程路径。

Back