AI惊叹号 | 自建AI中转站：技术选型指南

01先决策：自建还是托管

动手之前，先算账。

上一篇讲到OpenRouter被Stripe洽购，估值100亿美元。它确实好用——一个Key，500个模型，格式统一。但三个现实问题摆在面前：你的prompt要过它的服务器；每笔调用抽成5%左右；国内访问，网络和支付都是坎。

什么时候该自己搭？先看判断表。

你的情况	建议
数据不能出内网（金融、医疗、政企）	自建
团队有专职运维或SRE	自建
峰值并发高，要精细限流	自建
要给多租户/多部门计费	自建
原型验证，要求两周上线	托管
一两个人维护，无运维经验	托管

自建省钱，但不是免费。网关软件开源不要钱，运维要钱。隐性成本清单：

流式连接维护——SSE长连接的超时、断连、重试，都要自己处理
上游Key管理——轮换、过期、配额监控
协议跟进——上游API改版，网关要跟着升级
告警与重试逻辑——上游限流是常态，降级预案要写进配置
服务器本身——哪怕只是一台云主机，也有续费和安全补丁

省下5%抽成，花的是工程时间。人手够，这笔账划算；人手不够，托管费其实是买保险。

02网关的八项核心能力

选型前先建坐标系——知道标准，再看工具。

协议归一：对外暴露统一的OpenAI格式。换模型只改一个字符串，不改业务代码。
虚拟密钥：应用持网关发的虚拟Key，真实上游Key锁在网关里。泄漏了，吊销虚拟Key就行，不用去各家上游改密钥。
预算控制：每把Key设消费上限，到额即停。Key泄漏不破产，这个功能模型厂商大多不提供。
限流配额：按应用设RPM（每分钟请求数）、TPM（每分钟Token数）。防止一个应用吃光整个团队的配额。
负载均衡与故障切换：同一模型后挂多家供应商。一家限流，自动切下一家。
缓存：精确匹配缓存起步（相同请求直接返回）；语义缓存是进阶项（意思相近的请求也命中）。
安全护栏：PII脱敏（身份证号、手机号先遮再发）、提示注入检测。
可观测性：调用日志、成本归因（哪个团队花了多少钱）、延迟监控。

提醒：没有项目八项全能。先列出你最看重的前三项，再去对号入座。

03应用层网关：五个开源项目

这是自建中转站的主力选手。

项目	语言	定位	适合谁
One-API	Go	国内老牌，国产模型支持全，社区中文文档多	中文团队起步首选
New API	Go	One-API的活跃分支，界面和计费功能更细	要做内部计费的平台团队
LiteLLM	Python+Rust	140+供应商，SDK与Proxy双形态，生态最大（来源：官方文档）	要快速接全量模型的工程团队
Bifrost	Go	主打低延迟，官方口径5000 RPS（项目方数据，建议自行压测）	高并发低延迟场景
BricksLLM	Go	多租户Key治理，审计细	SaaS与平台方

接入有多简单？看代码。

# 业务代码只改两行：base_url 和 api_key
from openai import OpenAI

client = OpenAI(
    base_url="http://your-gateway:4000/v1",
    api_key="sk-virtual-xxx"   # 网关发的虚拟Key
)

resp = client.chat.completions.create(
    model="gpt-5",              # 网关里配什么名，就调什么名
    messages=[{"role": "user", "content": "你好"}]
)

标准OpenAI SDK，不改一行业务逻辑。这就是"协议归一"的价值——今天路由到GPT，明天切DeepSeek，改的是网关配置，不是代码。

04参考架构：从最小可用到生产级

两条路：半小时上线，或者认真盖楼。

最小可用（半小时）

一台服务器，Docker跑起来，SQLite存数据。旧笔记本都行。

docker run -d --name new-api \
  -p 3000:3000 \
  -v /home/user/data:/data \
  calciumion/new-api:latest

起来之后打开网页后台：添加上游渠道（填真实Key），创建虚拟Key发给应用。完事。个人用、小团队内部用，这套够跑很久。SQLite在单机低并发下没有瓶颈。

生产标配

组件	说明
网关本体	容器化部署，至少2副本，前置负载均衡
MySQL / PostgreSQL	渠道配置、Key信息、账单流水持久化。SQLite换掉
Redis	限流计数、缓存、多副本间的共享状态
观测层	Langfuse（开源）看调用明细与成本，或OTEL接Prometheus/Grafana
密钥管理	环境变量起步；规模上来换Secrets Manager或Vault，密钥不落盘

抄官方作业：LiteLLM Terraform蓝本

LiteLLM官方维护了Terraform部署蓝本（来源：官方文档），两条云路线：

AWS：ECS Fargate跑网关 + Aurora存数据 + ElastiCache做缓存 + Secrets Manager管密钥
GCP：Cloud Run跑网关 + Cloud SQL存数据 + Memorystore做缓存

特点：网关、数据库、缓存三服务拆分，密钥全程托管，副本数在配置文件里改。适合不想自己拼架构的团队，直接terraform apply。

请求链路

环节	动作
1. 应用请求	持虚拟Key访问网关
2. 鉴权	验证Key、检查余额与限流
3. 缓存检查	命中直接返回，不走上游
4. 路由决策	按配置选模型与供应商，故障自动切换
5. 上游调用	真实Key在网关侧注入，应用不可见
6. 计量记账	Token用量、成本、延迟落库

05场景速查表

对号入座。

场景	方案
个人尝鲜，一台旧电脑/NAS	New API + SQLite，Docker一行起
原型验证，两周上线	LiteLLM Proxy + config.yaml
数据不出内网	自建网关 + 私有化模型或厂商专线
团队内部用，要算部门账	New API 多租户计费
供应商多，要全量接入	LiteLLM（140+供应商）
高并发，延迟敏感	Bifrost（Go，先压测再上）
要看调用明细与成本	LiteLLM + Langfuse
国产模型为主	One-API / New API

06两条底线

架构可以简单，底线不能破。

第一条：真实上游Key只存在网关侧。应用持虚拟Key，日志里只见虚拟Key，代码仓库里没有真Key。泄漏的应该是可吊销的虚拟Key，不是能刷爆账单的那种。

第二条：别单一依赖。同一个模型至少配两家供应商，降级预案写进配置。上游限流不是意外，是常态。

上一篇结尾说，收费站可以自己修。这篇就是修路图。自己修的收费站，路权在自己手里——数据不出内网，成本自己算，Key自己管。这是监管鼓励的那条路，也是工程上最踏实的那条。

至于修完的路能通多远——看你要接多少模型了。