为什么走「自建网关」这条路

聚合中转站的问题在于：额度规则、模型白名单、封号风险都由别人掌握。自建网关把控制权拿回自己手里——上游仍然是各家官方 Free Tier 或试用金，但你对外只暴露一个 OpenAI 兼容端点，随时可以换上游、加 Key、切模型。

2026 年这套方案已经相当成熟：LiteLLM Proxy、One API / New API、Portkey Gateway 都支持多上游、按权重路由、失败重试。

操作步骤

1. 选一个网关

  • LiteLLM Proxy：Python 生态，配置文件 config.yaml 描述 model_list，原生支持 OpenAI / Anthropic / Gemini / Groq / Mistral 等 100+ 上游，自带 /key/info 用量统计和虚拟 Key。
  • One API / New API：Go 写的单二进制，Docker 一键起，中文界面友好，适合给团队分配子 Key 并做额度上限。
  • Portkey Gateway：更偏可观测性，适合已有一定流量、想看延迟和成本分布的场景。

个人和小团队首选 LiteLLM 或 New API，前者配置化更强，后者面板更直观。

2. 先攒上游 Key，再写配置

关键顺序不能反：先把能合法拿到的免费额度拿齐，再统一接入。常见来源包括：

  • 各厂商官方 Free Tier（通常有 RPM/TPM 限制，额度按日或按月刷新）；
  • 云厂商新用户试用金开通的模型服务（如 Bedrock、Vertex AI 侧）；
  • 开源模型托管平台的免费推理额度（如 Groq、Cerebras 等，通常有速率上限）；
  • 自己本地跑的 Ollama / vLLM 作为兜底。

把每个 Key 记成一行，标注：上游名、模型、速率限制、额度周期、是否允许生产使用。

3. 配置多上游与故障转移

LiteLLM 的典型做法是同一逻辑模型名下列多个 deployment，用 rpm、tpm、weight 描述各自容量，网关自动做负载均衡和重试：

```yaml

model_list:

  • model_name: gpt-4o-mini

litellm_params:

model: openai/gpt-4o-mini

api_key: os.environ/OPENAI_KEY_1

rpm: 3

  • model_name: gpt-4o-mini

litellm_params:

model: groq/llama-3.3-70b

api_key: os.environ/GROQ_KEY_1

rpm: 30

router_settings:

routing_strategy: usage-based-routing-v2

num_retries: 2

fallbacks: [{"gpt-4o-mini": ["local-llama"]}]

```

把 rpm 填成真实值非常重要——填大了会持续触发上游 429，填小一点反而整体吞吐更稳。

4. 用虚拟 Key 隔离调用方

给每个应用或同事发一个虚拟 Key，设置 max_budget 和 rpm_limit。这样即使某个 Key 被滥用，也只影响它自己的额度，不会把上游免费池打穿。

5. 加一层本地缓存和降级

  • 对重复 prompt 用 LiteLLM 的 Redis 缓存或自建语义缓存，能显著省额度；
  • 把本地 vLLM 配成 fallback，上游全部 429 时仍能返回结果，只是质量下降；
  • 开启 /metrics，用 Prometheus 看每个上游的失败率，及时摘掉不稳定的 Key。

注意事项

  • 合规优先：免费额度通常写明「仅限开发测试」。把免费额度接到对外收费产品上，可能违反条款；生产流量请用付费 Key 或自托管模型。
  • 不要多账号刷额度：用脚本批量注册同一平台通常会被判定滥用，导致 IP 或支付方式被封。
  • 速率限制是硬约束：免费层的 RPM/TPM 很低，网关只能帮你平滑流量，不能凭空造出额度。
  • 密钥安全：所有 Key 走环境变量或密钥管理服务，别写进 config.yaml 提交到 Git。
  • 额度会变：各家 Free Tier 的模型白名单和速率经常调整，建议每月核对一次上游可用性。
  • 地域限制：部分上游对某些地区不开放注册或调用，部署前先确认。

适用场景

  • 个人开发者做原型、跑评测、写小工具，调用量不大但需要多个模型对比；
  • 小团队内部工具（客服草稿、文档摘要、代码补全），想把零散额度集中管理；
  • 需要在多个模型间做 A/B 测试，又不想为每个上游单独写适配层；
  • 已有本地 GPU，想把自托管模型作为兜底混进同一个端点。

一个最小可跑的验证流程

  1. pip install 'litellm[proxy]'，写好上面那份 config.yaml；
  2. litellm --config config.yaml --port 4000；
  3. 用 curl 打 /v1/chat/completions，确认返回正常；
  4. 故意把某个上游 Key 改错，验证 fallback 是否生效；
  5. 打开 /ui，看用量面板是否按虚拟 Key 分开统计。

跑通这五步，你就有了一个不依赖任何单一中转站的 Token 管道。