自建 AI Gateway 实现统一 LLM 访问

3392 字约 11 分钟

2026-02-24

引言

作为一个重度 AI 用户，我每天通过各类 coding agent 与十几个 AI 平台打交道：Germanna、CodeX、GitLab Copilot、智谱 AI、MiniMax、千问、火山方舟等等。每个平台都提供 API 额度，但分散管理成了噩梦。

问题不在于总额度不够——而在于分配不均。我经常在任务中途遇到某个平台的 rate limit，而其他平台的额度却没怎么用。在不同设备之间切换不同的 base URL、API key 和认证方式既繁琐又容易出错。

我的解决方案？自建 LLM Gateway 统一管理所有 API key，通过 Tailscale 暴露给所有设备，实现智能路由、负载均衡和资源池化。

为什么选择 New API？

我花了相当多时间评估不同的 gateway 方案。以下是我的考虑：

方案	特点	为什么不选
LiteLLM	Python 方案，功能全面	相对重，需要 Python 环境
one-api	Go 方案，功能最完整	商业功能多，对个人来说复杂
uni-api	轻量级，纯配置文件	功能相对简单
New API	one-api 二次开发，现代化 UI	✅ 适合个人 + 轻量商业需求

LiteLLM 对于 Python 重度用户来说很优秀，提供商支持广泛。但它需要管理 Python 环境，对于我的使用场景来说感觉有点重。

one-api 是功能最完整的方案，代码库成熟。但它包含很多面向商业的功能，对我来说用不上，导致 UI 对个人用户来说显得杂乱。

uni-api 采取极简主义方式，纯配置文件无 UI。虽然优雅，但缺乏我想要的 token 使用可视化分析功能。

New API 取得了最佳平衡。它基于 one-api 二次开发，界面更现代化，支持 Midjourney 等额外服务，提供完整的 token 统计和费用分析——同时保持简单的 Docker 部署。

核心收益

智能路由

Gateway 的智能路由对我来说是杀手级功能。当某个平台 rate limit 时，gateway 自动切换到备用 provider，coding agent 无感知，不中断工作流。

实际工作原理：我为同一个逻辑模型配置多个 channel（provider 连接）。当我发送请求到 claude-sonnet 时，gateway 在配置的 channel 之间路由——智谱 AI、MiniMax、千问等。如果智谱返回 rate limit 错误，gateway 在几毫秒内自动用 MiniMax 重试。

这一切都是透明的。我的 coding agent 完全感知不到区别——它只看到一个成功的响应。

负载均衡

除了故障转移，gateway 还使用加权随机选择在多个平台之间分配并发请求。这避免了单点限流导致任务卡住。

权重是可配置的。我给额度更大或价格更优的 provider 分配更高权重，确保资源最优利用。

资源池化

这才是真正的魔法所在。所有平台的 quota 变成一个"大池子"，不再浪费任何一家的剩余额度。

之前：每家都"差点意思"，经常这家用完那家还剩很多。我不停地监控仪表板，在某个平台接近限额时手动切换 provider。

之后：所有额度一起用，哪个便宜/有额度就走哪个。gateway 把我所有的 API key 当作一个资源池，"榨干每一个 token"。

成本优化效果显著。我可以针对给定模型通过最优惠价格的 provider 路由流量，gateway 会处理其余的事情。

New API 仪表板展示了请求量、token 使用量与模型消费分布，便于观察资源池化后的整体使用情况。

统一访问

从客户端角度来看，一切都简单得令人愉悦：一个 base URL。Claude Code、Cursor、Cline——每个工具都指向 http://100.100.1.100:3000/v1（我 gateway 的 Tailscale IP）。在后台，我可以随意切换 model provider、调整路由权重或添加新平台，而无需触碰客户端配置。

通过 Tailscale，所有设备都能无缝访问同一个 gateway。我的 MacBook、PC 和手机都使用同一个 endpoint，无论它们身在何处。

架构设计

系统架构概览

架构由三层组成：客户端、gateway 和 provider。

客户端层：我所有的 coding agent 和 AI 应用——MacBook 上的 Claude Code、Cursor、Cline/Roo Code；PC 上的 VS Code + Copilot、Germanna；手机上的 Cherry Studio 和其他 AI 应用。

Gateway 层：New API 服务器处理路由、负载均衡和分析。PostgreSQL/SQLite 存储使用数据，Redis 提供低延迟路由决策的缓存。

Provider 层：10+ AI 平台，包括智谱、MiniMax、千问、火山方舟、Germanna、CodeX、GitLab Copilot 等。

请求处理流程

了解请求如何在系统中流动有助于理解背后发生的魔法：

客户端请求：你的 coding agent 发送标准 OpenAI 格式请求到 gateway。
路由：路由器根据权重、可用性和重试逻辑选择 channel。
转换：转换器将请求转换为 provider 期望的格式。
转发：请求发送到实际的 provider API。
响应标准化：响应被转换回 OpenAI 格式。
返回：你的 agent 收到响应，完全不知道背后的复杂性。

智能路由策略

路由策略结合了加权随机选择和自动故障转移：

当 claude-sonnet 请求到达时，它进入包含三个 provider 的 channel 池。路由器执行加权随机选择——MiniMax 获得 40% 的流量，智谱和千问各获得 30%。如果选中的 channel 因 rate limit 失败，路由器自动重试下一个可用 channel。

参数转换原理

不同的 LLM provider 使用不同的参数名称和格式。gateway 透明地处理这些转换：

常见参数映射：

客户端参数	智谱/MiniMax	Anthropic	Gemini	说明
`max_tokens`	`max_tokens`	`max_tokens`	`maxOutputTokens`	默认值差异大
`temperature`	`temperature`	`temperature`	`temperature`	某些不支持 0
`top_p`	`top_p`	`top_p`	`topP`	广泛支持
`stream`	`stream`	`stream`	不支持	流式协议差异
`tools`	`functions`	`tools`	`tools`	格式不完全兼容

转换自动发生。你发送 OpenAI 格式请求，gateway 负责与每个 provider 通信。

Tailscale Mesh 组网

Tailscale 在所有设备之间创建安全的 mesh 网络，无需复杂的网络设置：

每个设备获得一个 100.100.1.x 范围内的 Tailscale IP。gateway 服务器运行在 100.100.1.100。所有其他设备通过 P2P 直接连接——不需要 exit node。这保持了低延迟和高带宽。

部署步骤

Docker Compose 配置

New API 提供官方 Docker Compose 模板。以下是基础配置：

version: '3'
services:
  new-api:
    image: calciumion/new-api:latest
    container_name: new-api
    restart: always
    environment:
      - SESSION_SECRET=your_session_secret
      - SQL_DSN=/data/new-api.db
      - REDIS_CONN_STRING=redis://redis:6379
    volumes:
      - ./data:/data
    ports:
      - "3000:3000"
    depends_on:
      - redis

  redis:
    image: redis:alpine
    container_name: new-api-redis
    restart: always
    volumes:
      - ./redis-data:/data

关键配置点：

SESSION_SECRET：会话管理必需。生产环境请生成随机字符串。
SQL_DSN：数据库连接。默认使用 SQLite（/data/new-api.db），但多实例部署可切换到 PostgreSQL。
REDIS_CONN_STRING：Redis 用于缓存。提高负载下的路由性能。

部署命令：

docker-compose up -d

Tailscale 配置

设置 Tailscale 很简单：

在所有设备上安装 Tailscale（MacBook、PC、服务器、手机）
所有设备使用同一账号登录
记录 gateway 服务器设备的 Tailscale IP
配置防火墙规则允许 3000 端口（或自定义端口）的入站连接

不需要 exit node，因为我们使用 P2P mesh 组网。Tailscale 自动处理 NAT 穿透。

添加 API Channel

Gateway 运行后：

访问仪表板：导航到 http://<gateway-tailscale-ip>:3000
首次登录时创建管理员账号
导航到 Channels → Add Channel
选择 provider 类型（OpenAI Compatible、Anthropic 等）
为每个 provider 输入 API key 和 base URL
配置模型映射定义每个 channel 提供哪些 upstream 模型

对于模型映射，你可以配置多个 channel 服务同一个逻辑模型。例如，三个 channel（智谱、MiniMax、千问）都可以服务 claude-sonnet，实现前面描述的智能路由。

踩坑与解决方案

Tools / Function Calling 兼容性问题

这是我在设置过程中遇到的最重要问题。

问题场景： 当智能路由将一个模型字段（如 claude-sonnet）映射到多个 provider channel 时，不同 provider 对 tools / function_calling 的支持程度不同，导致 coding agent 的请求在某些 channel 失败。

Cline 和 Roo Code 等 coding agent 严重依赖 function calling 来执行文件操作、终端命令和搜索功能。当 gateway 将带 tools 的请求路由到不支持相同格式的 provider 时，请求失败。

具体表现：

问题类型	描述	示例
格式不兼容	OpenAI `functions` vs Anthropic `tools`	参数结构差异
参数不支持	`tool_choice` 的 `auto`/`required` 选项	某些模型只支持 `none`
响应解析差异	`tool_calls` 返回结构不同	JSON string vs parsed object
默认值差异	`max_tokens` 默认值不同	Ollama 128 vs vLLM 16

解决方案：

对于需要 tool calling 的场景，固定使用单一 provider。配置你的 coding agent 使用专用的模型 endpoint，映射到单一可靠的 provider（比如只用智谱或只用 MiniMax）。
在 New API 中为不同功能配置不同的模型路由规则。创建独立的逻辑模型：
- claude-sonnet-chat → 路由到多个 provider（仅聊天，无 tools）
- claude-sonnet-coding → 路由到单一 provider（支持 tools）
或者：创建独立的"coding"和"chat"路由。这是我最终采用的方案。所有 tool-calling 请求通过"coding"路由到固定 provider，而普通聊天请求使用池化路由。

Tailscale 组网注意事项

有几点需要注意：

使用 P2P mesh 网络直接在设备间通信，不需要 exit node。这保持低延迟。
确保所有设备都能访问 gateway 服务器设备。如果 Tailscale 回退到中继模式（因为直接 P2P 不可行），性能会受影响。
根据需要配置防火墙/端口转发。gateway 服务器需要在其 Tailscale IP 上接受入站连接。

总结

自建 AI Gateway 彻底改变了我管理多个 AI 平台的方式。统一访问、智能路由和资源池化消除了持续的 rate limit 中断和额度浪费。

投资回报立竿见影。第一周内，我就在密集 coding 会话中不再遇到 rate limit。token 分析仪表板显示我哪些 provider 利用不足，让我能够重新平衡支出。不再不停监控额度使用量的安心感？无价。

适合人群：

管理多个平台 API key 的重度 AI 用户
经常被单家 provider rate limit 困扰的开发者
想要集中 token 使用分析的用户
需要在设备间共享 AI 基础设施的团队

可能不需要的人群：

只有单一 provider 的轻度用户
对手动切换 provider 感到舒适的人
没有多设备访问需求的用户

设置需要一些初始投入——一个晚上用于部署和配置——但在工作流可靠性和成本效率上的回报立竿见影。对于任何处在我这种处境（几十个 API key、不停在 provider 之间切换）的人来说，绝对值得。