One API 实战：自建大模型 API 网关聚合多模型

在接入大模型的过程中，你迟早会遇到”模型太多、接口太乱”的问题：OpenAI、通义千问、DeepSeek、本地 vLLM 各有各的 base_url 与鉴权方式。One API 作为一款开源的大模型 API 网关，能把这些模型聚合到同一个 OpenAI 兼容接口后面，再统一发放令牌、做配额与记账，让上层应用只对接一套 API。

一、为什么需要自建大模型 API 网关

1.1 多模型调用的真实痛点

当你同时在用 OpenAI 的 GPT 系列、阿里的通义千问、DeepSeek 以及自托管的 vLLM/SGLang，每个服务都有独立的 base_url、API Key 格式和请求字段差异。应用层如果直接对接，每换一个模型就要改代码、改环境变量，还容易把密钥散落在代码仓库和各个开发同学的本地配置里，既难管理又易泄漏。

1.2 One API 解决什么

One API 在你和各家模型之间加了一层网关：对外只暴露一套 OpenAI 兼容接口，对内把不同厂商的差异屏蔽掉。你在网关上配置”渠道”（每个渠道对应一个上游模型服务），再为应用签发”令牌”（API Key）。上层应用永远只调用网关地址，换模型、限流、记账都在网关完成，业务代码一行都不用动。

二、One API 是什么

2.1 三个核心概念

渠道（Channel）是上游模型的接入点，记录厂商类型、base_url、密钥与模型映射；令牌（Token）是下发给应用的访问凭证，可绑定额度、RPM/TPM 与过期时间；用户（User）对应后台账号，支持多用户隔离与分组。理清这三者的关系，就能玩转整个网关。

三、用 Docker 快速部署 One API

最省事的方式是用官方镜像起一个容器。下面用 docker-compose 把服务和数据卷固定下来，避免容器重启后丢失渠道与令牌配置。如果你还不熟悉容器化部署，可以先看 Docker 容器化部署实战 打底。

version: "3"
services:
  one-api:
    image: justsong/one-api:latest
    container_name: one-api
    restart: always
    ports:
      - "3000:3000"
    volumes:
      - ./one-api-data:/data
    environment:
      - TZ=Asia/Shanghai
      - SESSION_SECRET=请改成随机长字符串
      - SQLITE_PATH=/data/one-api.db

启动后用浏览器访问 http://服务器IP:3000，首次会自动进入初始化页创建管理员账号；初始化完成后务必修改默认密码并停止访问 /init 路径。数据文件落在 ./one-api-data/one-api.db，备份它即可完整备份网关配置。

四、配置第一个渠道与令牌

4.1 添加上游渠道

在后台”渠道”页添加一条，类型选对应厂商（OpenAI / 通义 / DeepSeek / 自定义 OpenAI 兼容等），填入上游 Key 与 base_url，并在”模型”框里声明该渠道能提供的模型名。一个渠道可以映射多个模型名，例如把 gpt-4o 和 my-gpt 都指到同一个上游。

4.2 签发令牌并用 curl 验证

curl http://localhost:3000/v1/chat/completions \
  -H "Authorization: Bearer 你的网关令牌" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role":"user","content":"用一句话解释什么是 API 网关"}]
  }'

返回结构与 OpenAI 官方完全一致（含 choices、usage 字段），说明网关已打通。任何兼容 OpenAI 的 SDK 都可以用同一套请求格式访问。

五、把 One API 接入下游模型

5.1 对接自托管推理 vLLM / SGLang

如果你用 vLLM 或 SGLang 在自有算力上跑模型（参考 vLLM 部署实战），只需把它们的 OpenAI 兼容地址填进 One API 渠道的 base_url，网关就能把流量转发过去，相当于用一台网关统一纳管所有自托管推理服务，还能在上层做统一限流与记账。

5.2 对接云端模型与本地 DeepSeek

云端模型（通义、DeepSeek 官方、OpenAI）同理填密钥即可。若你已经在本地用 Ollama 部署了 DeepSeek（参考 DeepSeek 本地部署实战），也可以把它作为一个 OpenAI 兼容渠道接进来，做到”云端 + 本地”混合调度——高峰期走本地、合规场景走云端，全在网关一处切换。

from openai import OpenAI

# 只需把 base_url 指向 One API，业务代码完全不用改
client = OpenAI(
    base_url="http://网关地址:3000/v1",
    api_key="你的网关令牌",
)

resp = client.chat.completions.create(
    model="gpt-4o",          # 换成任意在网关登记过的模型名
    messages=[{"role":"user","content":"你好"}],
)
print(resp.choices[0].message.content)

六、用 Nginx 反代并安全暴露

生产环境不要把 One API 的 3000 端口直接暴露公网。用 Nginx 做反向代理（见 Nginx 反向代理实战），把服务收在域名后面，强制 HTTPS 并加上速率限制，避免令牌被刷。

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

    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;
        client_max_body_size 32m;   # 大模型请求体可能较大
    }

    # 简单限流，保护令牌
    limit_req_zone $binary_remote_addr zone=oneapi:10m rate=20r/s;
    location /v1/ {
        limit_req zone=oneapi burst=40 nodelay;
        proxy_pass http://127.0.0.1:3000;
    }
}

七、让上层应用统一消费

最关键的好处是”应用零改动切换模型”。以 Dify 为例，把它的模型供应商 base_url 指向 One API、密钥用网关令牌即可（Dify+Ollama 实战 里也强调过统一接入的思路）。任何兼容 OpenAI SDK 的框架——LangChain、LlamaIndex、自研 FastAPI 服务——只需改一行 base_url 就能全部切到网关，模型替换对业务完全透明。

# 环境变量方式，一行切换即可
export OPENAI_API_BASE="https://api.yourdomain.com/v1"
export OPENAI_API_KEY="你的网关令牌"

八、配额、记账与多用户

网关的价值不止转发。在令牌上设置额度（总点数 / RPM / TPM），就能给不同团队或客户分配不同上限；后台的”日志”与”令牌”页能看清每次调用的模型、耗时与消耗。对需要成本核算的团队，这比把厂商 Key 直接发给所有人安全得多。

九、生产环境注意事项

上线前有几件事必须做：一是修改默认管理员密码并关闭 /init；二是定期备份 one-api.db 数据文件（渠道与令牌全在里面）；三是把网关与上游模型都放进内网或走 VPN，敏感渠道不要直连公网；四是配合监控观察异常调用。与 LiteLLM 实战 这类方案相比，One API 的中文后台与多用户体系对国内团队更友好，而 LiteLLM 在路由策略与成本分析上更细，可按团队偏好选择。

• 修改默认管理员密码，初始化后关闭 /init 路由
• 定时备份 SQLite/MySQL 数据文件，渠道令牌全靠它
• 网关与上游模型尽量走内网，公网只暴露 Nginx 反代
• 为服务端调用的令牌配置 IP 白名单与合理 RPM/TPM
• 开启访问日志，定期审计异常高频调用

十、小结

One API 用一层轻量网关把”多模型、多密钥、多账单”收敛成一套接口，是个人或团队落地大模型的性价比之选。从 Docker 一键部署，到渠道/令牌配置，再到 Nginx 暴露与上层接入，整套流程半天即可跑通，后续模型替换对业务完全透明。