大模型API网关配置：从零搭建统一入口与密钥管理

如果你手上有多个大模型服务（比如 OpenAI、通义千问、DeepSeek 等），每个服务都有自己的 API 地址和密钥，调用起来很麻烦，还容易把密钥散落在代码里。
大模型 API 网关配置的核心目标，就是把这些服务统一到一个入口后面，由网关负责鉴权、转发、限流和日志记录。
下面按零基础也能照做的顺序，用 Nginx 加开源网关 LiteLLM 演示一套可落地的配置方法。

先确认你的环境和前置条件

这套方案适合有一台 Linux 服务器（本文以 Ubuntu 22.04 为例）、能通过命令行操作、并且已经拿到至少一个大模型 API Key 的读者。
你需要准备：

• 一台可公网访问的服务器，开放 80 或 443 端口（如果走 HTTPS 还需要域名和证书）。
• 已安装 Docker 和 Docker Compose。没有的话，先执行 sudo apt update && sudo apt install -y docker.io docker-compose-plugin，然后 sudo systemctl enable --now docker。
• 至少一个模型服务的 API Key，例如 sk-xxxx 格式的密钥。

网关本身不生产模型能力，它只做请求转发和策略控制。
所以不要把网关当成模型服务来理解，它更像一个“统一前台”。

用 Docker 启动 LiteLLM 网关

LiteLLM 是一个支持多种大模型协议的开源网关，配置简单，适合作为起步方案。
先创建配置目录和配置文件：

mkdir -p /opt/llm-gateway && cd /opt/llm-gateway

新建 config.yaml，内容如下（注意把 your-api-key 换成你真实的密钥）：

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

  - model_name: qwen-turbo
    litellm_params:
      model: dashscope/qwen-turbo
      api_key: os.environ/DASHSCOPE_API_KEY

litellm_settings:
  drop_params: true

再新建 .env 文件存放密钥（不要写进 config.yaml）：

OPENAI_API_KEY=sk-你的OpenAI密钥
DASHSCOPE_API_KEY=sk-你的通义密钥

然后启动容器：

docker run -d --name llm-gateway \
  -p 4000:4000 \
  --env-file /opt/llm-gateway/.env \
  -v /opt/llm-gateway/config.yaml:/app/config.yaml \
  ghcr.io/berriai/litellm:main-latest \
  --config /app/config.yaml --port 4000

启动后检查容器状态：docker ps | grep llm-gateway。
如果状态是 Up，说明网关进程已经跑起来了。
接着用 curl 验证模型列表：

curl http://127.0.0.1:4000/v1/models

正常会返回一个 JSON，包含你配置的 gpt-4o-mini 和 qwen-turbo。
如果返回连接拒绝，先看 docker logs llm-gateway 里的报错，常见原因是配置文件路径不对或密钥环境变量没加载。

用 Nginx 做统一入口和访问控制

LiteLLM 默认监听 4000 端口，直接暴露公网不安全。
建议在前面加一层 Nginx，统一走 443 端口，并加上基础认证或 IP 白名单。
安装 Nginx 后，新建站点配置：

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

    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;

    location /v1/ {
        proxy_pass http://127.0.0.1:4000/v1/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Authorization $http_authorization;
        proxy_read_timeout 120s;
    }
}

保存后执行 sudo nginx -t 检查语法，通过后 sudo systemctl reload nginx。
这样外部调用统一走 https://api.example.com/v1/chat/completions，由 Nginx 转发到内部网关。

注意：proxy_set_header Authorization $http_authorization; 这一行不能省，否则网关收不到客户端传来的密钥，会返回 401。
如果你的网关本身还要做密钥校验，可以在 LiteLLM 配置里启用 general_settings.master_key，让网关自己验证请求头。

密钥管理和限流别踩这些坑

大模型 API 网关配置最容易出问题的地方不是转发，而是密钥和配额。

• 不要把真实密钥写进代码仓库。用 .env 或环境变量注入，并把 .env 加入 .gitignore。
• 网关侧建议设置总限额。LiteLLM 支持在配置中加 general_settings: master_key: os.environ/MASTER_KEY，客户端必须带这个主密钥才能访问，避免网关被随意调用。
• 按模型设置超时和重试。大模型响应慢，Nginx 的 proxy_read_timeout 不要低于 60 秒，否则长回答会被截断。
• 限流放在 Nginx 层更简单。在 http 块里定义 limit_req_zone $binary_remote_addr zone=llm:10m rate=5r/s;，然后在 location 里加 limit_req zone=llm burst=10 nodelay;，防止单个 IP 刷爆配额。

改完 Nginx 配置后同样先 nginx -t 再 reload，不要直接重启，避免配置错误导致服务中断。

验证网关是否真正生效

配置完成后，用一条真实请求验证整条链路：

curl https://api.example.com/v1/chat/completions \
  -H "Authorization: Bearer 你的主密钥" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"你好"}]}'

如果返回包含 choices 的 JSON，说明网关转发成功。
如果返回 401，检查 Authorization 头是否被 Nginx 正确传递；
返回 502，检查 LiteLLM 容器是否在运行、端口是否对应；
返回 429，说明限流生效或模型侧配额不足。

最后建议在网关日志里观察请求记录：docker logs -f llm-gateway 可以看到每次调用的模型和状态码。
确认无误后，再把业务代码里的模型地址统一替换成网关地址，后续换模型或加密钥只需要改网关配置，不用动业务代码。

如果你还在用多个 API 地址分别调用，不妨先按本文把网关跑通，再根据实际流量调整限流和超时参数。
遇到异常时优先检查 Nginx 转发头和容器日志，大部分问题都能快速定位。