如何搭建自己的中转站点：用 New API、One API 和 LiteLLM 管理 AI API

中转站到底是什么

很多人搜索“搭建中转站”，心里想的是“让各种 AI 工具都能用同一个接口”。这个理解没错，但还不完整。

一个合规的 AI API 中转站，更像你自己的模型服务前台：上游接入 OpenAI、Anthropic、Google、DeepSeek、通义千问、本地模型或其他你合法持有访问权限的服务；下游给自己的应用、脚本、自动化工作流、聊天前端或团队成员提供统一入口。

它解决的不是“有没有模型”，而是“怎么管理模型”：

• 多个上游服务的 API Key 不再散落在每个客户端里。
• 下游工具只需要记住一个 Base URL 和一个下游令牌。
• 管理员可以看到谁在调用、用了哪个模型、花了多少 token。
• 当某个渠道失败或成本过高时，可以切换、降级或限制。

如果把每个模型供应商看成一条水管，中转站就是一个水电总闸：统一入口、统一计量、统一权限、统一日志。

flowchart LR
    App["应用 / 脚本 / 工作流"] --> Relay["自用中转站"]
    Relay --> Auth["认证与权限"]
    Relay --> Log["日志与用量"]
    Relay --> Route["模型路由"]
    Route --> A["模型服务 A"]
    Route --> B["模型服务 B"]
    Route --> C["本地模型 / 私有模型"]

什么时候值得自己搭

如果你只是偶尔在网页里聊天，没有必要上来就搭中转站。它真正适合这几类场景：

1. 你有多个 AI 工具，都要填 OpenAI-compatible API。
2. 你同时使用多个模型供应商，希望统一入口和用量统计。
3. 你不想把上游原始 Key 填到每个客户端里。
4. 你需要给不同工具或成员分配额度、模型白名单和过期时间。
5. 你要把 Open WebUI、编程助手、自动化脚本或内部系统接到同一套模型后端。
6. 你希望便宜模型处理简单任务，强模型处理复杂任务，本地模型处理隐私资料。

不适合搭的情况也很明确：你没有基本运维能力、不会保护后台、没有合法上游来源、准备公开售卖不明模型额度，或者无法承担数据安全和合规责任。

核心价值：统一、降本、安全

第一是统一访问。 你不需要在每个工具里分别填写不同厂商的 API Key，也不需要在 OpenAI、Anthropic、Google、国内模型平台之间反复切换。下游只记住一个入口，后面的模型选择、渠道切换和权限控制交给中转站。

第二是降本增效。 中转站可以把摘要、分类、改写这类简单任务分配给低成本模型，把长文档、复杂推理、代码分析交给更强模型。团队使用时，还能知道钱花在谁身上、花在哪些模型上。

第三是安全可控。 真实上游 Key 不再散落在 Cursor、Open WebUI、脚本、插件和临时 Demo 里，而是只放在后台。下游工具拿到的是你分发出来的令牌。出了问题，可以禁用令牌、限制 IP、查看日志、追踪调用记录。

中转站不是为了“藏起来”，而是为了“管起来”。

技术架构：三层就够理解

一个成熟的 AI API 中转站，通常可以拆成三层。

协议转换层。 不同厂商的原生 API 不完全一样，路径、参数、流式输出、工具调用格式和错误返回都会有差异。中转站会尽量把它们转换成统一的 OpenAI-compatible 接口，方便客户端只对接一个标准。

模型路由层。 它会根据渠道优先级、权重、模型类型、分组权限、额度、健康状态和失败重试，把请求分配给合适的后端服务。更工程化的网关还会做 fallback、预算限制、缓存和告警。

安全管理层。 它负责认证、授权、限流、审计、密钥隔离、访问控制和日志记录。没有这一层，中转站只是一个转发器；有了这一层，它才像一个可管理的 AI 网关。

flowchart TB
    Client["客户端 / 工具"] --> API["统一 API 入口"]
    API --> Auth["安全管理层：认证、授权、限流、审计"]
    Auth --> Convert["协议转换层：OpenAI-compatible 格式"]
    Convert --> Route["模型路由层：优先级、权重、健康检查"]
    Route --> M1["模型服务 A"]
    Route --> M2["模型服务 B"]
    Route --> M3["本地模型 / 私有模型"]

个人自用不一定需要一次做得很复杂，但至少要有：下游令牌、用量统计、日志、额度限制、HTTPS、备份和后台访问控制。

开源方案怎么选

当前常见选择可以分成五类。

[New API](https://github.com/QuantumNous/new-api)：适合长期自用或小团队。 它基于 One API 思路演进，界面更现代，渠道、令牌、模型限制、用量统计、分组和多供应商管理都比较完整。它更像一个现成的后台系统，适合不想写太多配置的人。

[One API](https://github.com/songquanpeng/one-api)：适合快速理解中转站最小闭环。 它更老牌、更轻量，定位直接：用标准接口访问多个模型，做 Key 管理和接口分发。适合先跑起来，理解“渠道、令牌、日志、统一 Base URL”这套基本逻辑。

[LiteLLM Proxy](https://github.com/BerriAI/litellm)：适合开发者和内部工程集成。 它更像配置化 LLM 网关，可以用 config.yaml 做模型映射、fallback、预算、团队管理和统一代理。学习成本更高，但适合接到代码、自动化工作流和内部系统里。

[Open WebUI](https://github.com/open-webui/open-webui)：不是中转站本身，而是前端体验层。 它可以连接 OpenAI-compatible API，让普通用户通过聊天界面使用后端模型。你可以把 Open WebUI 接到 New API 或 LiteLLM 后面，形成一个自用 AI 平台。

[sub2api](https://github.com/Wei-Shaw/sub2api)：只建议个人研究和自用测试。 它更偏向把部分订阅类 AI 产品能力整理成 API 风格入口，对某些工具链很顺手，但边界敏感。不要把它用于公开运营、共享售卖或绕过平台规则。

选择时可以这么判断：

• 想最快有后台：优先 New API。
• 想理解基础逻辑：One API。
• 想做工程化路由和 fallback：LiteLLM Proxy。
• 想给团队聊天界面：Open WebUI + New API 或 LiteLLM。
• 想研究订阅入口兼容性：只在低风险、自用环境看 sub2api。

推荐路线：从 New API 开始

如果只推荐一条更稳妥的个人或小团队路线，我会从 New API 开始。

原因很简单：它有后台、有渠道、有令牌、有模型限制、有日志和用量统计。你不用一上来写配置文件，也不用自己做用户系统。先跑通，再慢慢补安全和运维。

1. 准备服务器和域名

自用测试，一台 1 核 2G 的云服务器或内网机器就能跑基础服务。小团队建议从 2 核 4G 起步，并考虑独立数据库、备份和反向代理。

最低准备清单：

• 一台 Linux 服务器或内网主机。
• Docker 和 Docker Compose。
• 一个域名或固定访问地址。
• 至少一个合法可用的上游模型 API Key。
• 反向代理和 HTTPS 证书。
• 一个只给管理员使用的后台访问入口。

2. 用 Docker 启动 New API

New API 的 Docker 镜像可以直接启动，先用本地数据目录持久化配置：

docker run --name new-api -d --restart always \
  -p 3000:3000 \
  -e TZ=Asia/Shanghai \
  -v ./data:/data \
  calciumion/new-api:latest

启动后访问：

http://服务器IP:3000

第一件事不是开放给别人，而是完成三个动作：

1. 修改默认管理员密码。
2. 添加你自己合法持有的上游渠道 Key。
3. 在“令牌”里生成给下游工具使用的新 Key。

3. 绑定域名和 HTTPS

生产环境不要长期使用裸 IP 和明文 HTTP。可以用 Nginx 做反向代理：

server {
  listen 443 ssl;
  server_name api.example.com;

  ssl_certificate /path/to/cert.pem;
  ssl_certificate_key /path/to/key.pem;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

如果只是自用，后台最好再加一层保护：IP 白名单、VPN、Cloudflare Access、Basic Auth 或内网访问。管理后台不应该裸奔在公网。

4. 配置渠道

渠道负责连接上游模型服务。你需要填写渠道类型、Base URL、上游 API Key、模型列表、优先级、权重和分组可用性。

刚开始不要把所有渠道都塞进去。更稳的顺序是：

1. 先接一个你确定稳定的上游服务。
2. 用后台测试确认连通。
3. 跑一次真实请求。
4. 看日志和消耗是否正常。
5. 再接第二个渠道，测试 fallback 或权重。

渠道配置最重要的不是“数量多”，而是“来源清楚、可用稳定、计费透明”。

5. 创建下游令牌

下游工具不要直接拿上游 Key，而是拿 New API 生成的令牌。令牌可以按用途拆开：

• chat-webui：给 Open WebUI 使用。
• coding-assistant：给编程工具使用。
• workflow-bot：给自动化脚本使用。
• test-demo：给临时测试使用。

每个令牌最好设置：

• 额度上限。
• 过期时间。
• 模型白名单。
• IP 白名单。
• 备注用途。

这样一旦某个工具异常消耗，直接禁用对应令牌即可，不需要去每个客户端追着改上游 Key。

6. 下游工具怎么填

对 OpenAI-compatible 工具来说，一般只需要两项：

Base URL: https://api.example.com/v1
API Key: sk-你在中转站生成的下游令牌

测试请求可以这样写：

curl https://api.example.com/v1/chat/completions \
  -H "Authorization: Bearer sk-xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [
      { "role": "user", "content": "用一句话解释 API 中转站" }
    ]
  }'

如果工具不走 OpenAI-compatible 协议，例如某些 Anthropic 风格客户端，要确认你的中转站是否做了对应协议适配。很多“Key 明明对，但请求失败”的问题，本质是路径或协议不匹配。

One API：轻量方案

One API 更适合快速理解中转站基本闭环。典型 Docker 启动方式类似：

docker run --name one-api -d --restart always \
  -p 3000:3000 \
  -e TZ=Asia/Shanghai \
  -v /home/ubuntu/data/one-api:/data \
  justsong/one-api

登录后通常也是三步：

1. 修改默认密码。
2. 在“渠道”里添加上游模型服务。
3. 在“令牌”里生成下游访问 Key。

One API 的优势是轻量、教程多、概念清楚。它适合个人学习、自用小规模转发、理解中转站最小闭环。缺点是现代化体验和细粒度管理能力通常不如 New API 丰富。

LiteLLM：工程化网关

LiteLLM 更适合开发者。它的核心思路是用配置文件把不同模型映射成统一名字，然后暴露 OpenAI-compatible Proxy。

一个简化配置可以是：

model_list:
  - model_name: cheap-summary
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: strong-reasoning
    litellm_params:
      model: openai/gpt-4.1
      api_key: os.environ/OPENAI_API_KEY

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

启动：

docker run -d --name litellm \
  -p 4000:4000 \
  -e OPENAI_API_KEY="你的上游Key" \
  -e LITELLM_MASTER_KEY="给下游用的主Key" \
  -v $(pwd)/config.yaml:/app/config.yaml \
  docker.litellm.ai/berriai/litellm:main-latest \
  --config /app/config.yaml

下游应用可以指向：

http://你的服务器:4000/v1

LiteLLM 适合把“摘要走便宜模型、复杂推理走强模型、失败时切备用模型、某团队每月预算多少”这类策略写进配置里。它不一定适合完全不想碰配置的人，但很适合工程团队。

Open WebUI：把中转站变成可用产品

中转站解决的是 API 管理，Open WebUI 解决的是用户体验。

一个常见组合是：

flowchart LR
    User["用户"] --> WebUI["Open WebUI"]
    WebUI --> Gateway["New API / LiteLLM"]
    Gateway --> Cheap["便宜模型：摘要、分类"]
    Gateway --> Strong["强模型：长文档、复杂推理"]
    Gateway --> Local["本地模型：隐私资料"]

这样普通用户面对的是聊天界面，管理员管理的是模型、令牌、渠道和预算。个人自用也可以这么搭，体验会比直接把 API URL 填进各种客户端更统一。

安全清单：上线前必须做

搭中转站最怕两件事：后台暴露和 Key 泄露。上线前至少检查这些事项：

• 管理员默认密码已经修改。
• 管理后台没有裸露公网，或已加 IP 白名单/VPN/访问控制。
• 生产环境启用 HTTPS。
• 上游原始 API Key 只由管理员配置。
• 下游工具只使用中转站分发的令牌。
• 每个令牌有用途备注、额度、过期时间和模型限制。
• 日志能看到用户、模型、token、响应时间、来源 IP。
• 敏感请求不进入不可信上游或第三方中转。
• 数据目录定期备份。
• 版本升级前先备份，再灰度验证。

如果你要给团队使用，还要增加：

• 分组权限。
• 成员离职后的令牌回收。
• 异常消耗告警。
• 每周或每月成本复盘。
• 管理员操作审计。

API 网关安全资料反复强调认证、授权、限流、加密、日志和监控。AI 中转站也一样，只是后端换成了模型服务。

合规边界：不要把自建变成灰产

自建中转站不等于可以公开运营。尤其是面向不特定公众提供生成式 AI 服务、收费分发模型能力、转售账号额度或处理用户数据时，可能涉及平台服务条款、内容安全、数据合规、备案和支付合规问题。

更稳妥的原则是：

• 只接入你有合法授权的上游模型服务。
• 只服务自己、内部团队或明确授权用户。
• 不包装“无限额度”“低价共享”“绕限制”。
• 不保存不必要的敏感请求内容。
• 对团队成员明确数据使用边界。
• 涉及客户资料、代码仓库、合同、财务、医疗等内容时，优先走官方 API、企业合规方案或本地模型。

中转站长期能不能用，取决于稳定、合规和可信，而不是短期便宜。

常见问题

自建中转站是不是一定更便宜？

不一定。软件本身可能是开源的，但真实成本包括服务器、上游模型调用、维护时间、安全配置和故障处理。它的价值首先是统一管理，其次才是成本优化。

可以把中转站开放给别人用吗？

技术上可以，风险上要非常谨慎。公开服务会带来合规、滥用、支付、内容安全、数据保护和上游条款风险。个人和小团队更建议先做自用或内部工具。

New API、One API 和 LiteLLM 选哪个？

不想写配置、想要后台体验，优先 New API。想轻量学习基础闭环，看 One API。想工程化路由、预算和 fallback，看 LiteLLM。

中转站会不会偷看数据？

如果是你自己部署、自己控制日志和数据库，风险取决于你的配置和上游服务。如果使用第三方中转，请求内容理论上会经过对方平台，敏感数据不要发给不可信中转。

为什么下游工具填了 Key 还是报错？

常见原因是 Base URL 路径不对、协议不匹配、模型名不在白名单、渠道不可用、令牌额度用完，或者上游 Key 本身失效。先看中转站日志，再看客户端错误。

写在最后

“如何搭建自己的中转站点”表面是技术教程，真正核心是管理。你不是在搭一条秘密通道，而是在给自己的 AI 调用加一个可控入口。

个人使用，目标是少改代码、少泄露 Key、看得见用量。团队使用，目标是权限清楚、成本可控、日志可查。涉及公开服务，就要把法律、备案、数据安全和平台条款放在技术之前。

能跑起来只是第一步。能长期合规、安全、稳定地跑，才是真正有价值的中转站点。

资料来源

• New API Docker 镜像
• New API GitHub
• One API GitHub
• LiteLLM GitHub
• LiteLLM Proxy 文档
• Open WebUI 文档：连接 OpenAI-compatible API
• Open WebUI GitHub
• sub2api GitHub
• MuleSoft：API Gateway Security Best Practices
• AWS：Security best practices in Amazon API Gateway

延伸阅读

• API Relay / API 中转站
• API Key / 密钥
• AI Gateway / AI 网关
• AI 中转站避坑指南