💡 本节一句话：当你不再只用一家大模型，而是把 OpenAI、Anthropic、DeepSeek、Qwen、自研模型混着用的时候，LLM 网关（也叫 token 中转站）就成了那个帮你统一调度、记账、兜底的"机场塔台"。

一、为什么需要 LLM 网关？从一个真实痛点讲起

🤔 假设你的产品上线 3 个月，已经接入了 4 家模型：GPT-4o（英文客服）、Claude Sonnet（长文档摘要）、DeepSeek（中文代码助手）、Qwen-VL（图像识别）。一个月后老板问你："这个月各家模型分别花了多少钱？哪些请求超时了？上周那次 P0 事故是因为哪一家挂了？"

如果每个模型都是直接调用官方 SDK 接入的，你会瞬间面对这些问题：

• 4 套 API Key散落在 6 个微服务里，谁也说不清哪把钥匙归谁管
• 4 套计费规则（按 token、按字符、按次）写在不同地方的代码里，改一次要全量回归
• 没有统一日志，出问题只能一家家翻控制台
• 无法快速切换，比如 GPT-4o 涨价 20%，你想让一半流量去 Claude，几乎要重新发版
• 没有限流和兜底，一个模型挂了，整个产品跟着挂

✅ 结论：当模型数量 ≥ 2、或者要服务正式用户、或者涉及成本治理时，直接调用每家 API 已经不是最优解。你需要一个中间层——这就是 LLM 网关。

二、什么是 LLM 网关？一个生活化类比

图 1：LLM 网关在系统中的位置（应用层 / 网关层 / 模型层）

<whiteboard token="TP6kwChkHhfdlbbBOlpcscyVnue"></whiteboard>

图 1：LLM 网关在系统中的位置

1. 先打个比方：机场的塔台

LLM 网关就是 AI 应用的"塔台"。你的应用不再直接对着 OpenAI / Anthropic / DeepSeek 一家家喊话，而是统一向网关发请求，由网关去选择、调度、监控、兜底。

2. 更精确的定义

LLM Gateway（大模型网关 / token 中转站）是一个位于应用层和多家模型供应商 API之间的中间代理服务。它对外提供统一的 OpenAI 兼容接口，对内负责路由、重试、计费、鉴权、缓存、日志等横切关注点。

3. 网关帮你解决的 5 件事

📌 记住：网关不是必须的。一个玩具 demo、一个内部小工具，直接调 API 完全没问题。当你开始问"谁在花我的钱 / 谁挂了 / 怎么切"的时候，网关就该上场了。

三、三种姿态：直接 API vs 托管网关 vs 自托管网关

图 2：三种接入姿态对比（直连 / 托管 / 自托管）

<whiteboard token="La2JwH6UmhLcMebfTgBcXxxonhk"></whiteboard>

在工程上，接入大模型通常有三种姿态，分别适合不同的团队阶段。

1. 姿态一：直接调用（Direct API）

类比：你亲自去每家餐厅点菜，吃完还要自己结账、记录发票。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

from openai import OpenAI
from anthropic import Anthropic

openai_client = OpenAI(api_key="sk-...")
claude_client  = Anthropic(api_key="sk-ant-...")

# 业务代码里要写两份
def chat(prompt: str, prefer: str = "openai"):
    if prefer == "openai":
        r = openai_client.chat.completions.create(...)
    else:
        r = claude_client.messages.create(...)

优点：延迟最低（少一跳）、最灵活、完全可控。

缺点：多模型时重复劳动大；治理、限流、计费全靠自己堆代码；出问题只能各家切来切去。

适合：1 个模型、PoC / Demo、个人项目。

2. 姿态二：托管网关（Hosted Gateway）

类比：美团 / 滴滴——你只管叫外卖叫车，背后哪家餐厅哪个司机你不用管。

代表产品：OpenRouter、Portkey

特点：你注册一个账号，拿一个 API Key，就能在同一个接口下用上 GPT、Claude、Llama、Qwen 等几十家模型。

1
2
3

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -d {"model": "anthropic/claude-4.6-sonnet", "messages": [...]}"

优点：开箱即用、按用量付费、统一账单、自带 dashboard、统一日志、内置路由和 fallback。

缺点：请求/响应要走第三方（合规审查需谨慎）、单价通常略高于直连、深度定制受限。

适合：中小团队、希望"明天就要用上多模型"、不想自己运维基础设施。

3. 姿态三：自托管网关（Self-Hosted Gateway）

类比：自己开中央厨房，所有餐厅加盟进来。麻烦但完全自主。

代表产品：LiteLLM（最流行，开源）、One API（国产开源）、Portkey（自部署版）、Envoy AI Gateway。

1
2
3
4
5

pip install litellm
litellm --model openai/gpt-4o \
         --model anthropic/claude-3-5-sonnet-20241022 \
         --model deepseek/deepseek-chat \
         --api_key your_master_key

优点：数据不出内网（合规友好）、可深度定制（自定义路由、缓存、过滤器）、长期看单价可控、可对接私有模型。

缺点：需要运维（高可用、扩缩容、监控）、自己处理各家 Key 的采购和续费、初期投入不小。

适合：中大型企业、有合规要求、模型用量大、有运维团队。

一张表看清楚

❗ 记住这条经验法则：

• PoC 阶段 → 直接 API，先跑起来再说

• 产品上线 / 小团队 → 托管网关，省心

• 进入企业级 / 合规收紧 → 自托管网关 或 混合

四、核心能力一：模型路由（Model Routing）

图 3：智能路由流程（请求→规则→选择模型→响应）

<whiteboard token="CpVNwZO2IhXJvPbR1ghcshkbnic"></whiteboard>

💡 一句话：把"用哪个模型"这件事从业务代码里抽出来，变成网关的配置。业务只关心"我要生成一段文本"，网关决定该派给 GPT-4o、Claude 还是本地 Llama。

1. 为什么需要路由？

同一类任务，不同模型在质量 / 速度 / 成本上差异巨大：

如果不路由，要么全用最贵的（烧钱），要么全用最便宜的（用户嫌笨）。

2. 常见的 5 种路由策略

1. 按规则路由（Rule-based）：根据 prompt 关键词、用户标签、租户 ID 硬编码——"含 代码 字样的发给 DeepSeek"
2. 按成本路由（Cost-based）：同质量下选最便宜的；比如 OpenRouter 的 :floor 后缀会挑当下最低价
3. 按延迟路由（Latency-based）：对响应时间敏感的实时对话，挑当下 P95 最低的
4. 按质量路由（Quality-based）：先让小模型回答，让大模型评分，不满意再升级到强模型
5. 按上下文路由（Context-based）：长上下文丢给 Claude / Gemini ，短上下文丢给小模型

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

routes:
  - name: cheap
    when: { task: "summary", length: "< 2000" }
    target: deepseek/deepseek-4-flash
  - name: smart
    when: { task: "code_generation" }
    target: anthropic/claude-4-5-sonnet
  - name: local
    when: { tenant: "internal" }
    target: ollama/qwen3-7b
```text
# 五、核心能力二：可靠性与故障转移（Reliability & Failover）

图 4：故障转移决策图（重试 → Failover → Fallback → 熔断）

<whiteboard token="AHtZw8ftLhMABsbvxY5crnAon0c"></whiteboard>

<blockquote class="callout callout-note">
<p><span class='callout-emoji'>💡</span> <strong>一句话：</strong>模型供应商也会挂。任何"直接调一家 API"的架构，都把整个产品的可用性<strong>押注在一家公司的健康度上</strong>。网关让你可以优雅地"打太极"——主模型挂了，自动切备用，用户无感。</p>
</blockquote>

## 1. 真实世界的失败长什么样？

OpenRouter 团队总结过生产环境里最常见的失败模式：

- **5xx 服务端错误**：供应商机房故障，比例不高但每次都很痛
- **429 限流**：突发流量打爆了你的配额
- **超时（Timeout）**：模型生成特别慢（尤其是长输出）
- **内容安全拒绝（400 / 403）**：供应商策略收紧或风控误伤
- **网络抖动 / DNS 污染**：跨境调用常见

## 2. 类比：发电厂的"双回路供电"

医院、机场、数据中心都不接一条电缆，一定是**主备双回路 + 柴油发电机**。LLM 网关给你的模型调用提供同样的"双回路"：

| 机制 | 作用 |
|-|-|
| **重试 Retry** | 遇到 5xx / 超时再试一次 |
| **故障转移 Failover** | 主模型失败 → 切到备用模型 |
| **降级 Fallback** | 智能模型失败 → 用更便宜的简单模型 |
| **熔断 Circuit Breaker** | 连续失败 N 次 → 暂停调用一段时间 |
| **负载均衡 Load Balance** | 把请求分散到多供应商 |

## 3. 一段典型的网关配置

```yaml
targets:
  - model: anthropic/claude-3.5-sonnet   # 主：质量最好
    weight: 70
  - model: openai/gpt-4o                 # 备：性能接近
    weight: 25
  - model: deepseek/deepseek-chat        # 兜底：便宜量大
    weight: 5

retry:
  max_attempts: 3
  on_status: [429, 500, 502, 503, 504]
  backoff: exponential

circuit_breaker:
  failure_threshold: 5
  cool_down_seconds: 60

上面这段配置的语义："70% 流量走 Claude，遇到 5xx/429 重试 3 次仍失败时，按 GPT-4o → DeepSeek 顺序兜底；如果某供应商 1 分钟内连续 5 次失败，自动把它从可用池里摘掉 60 秒"。

✅ 一个数字帮你记住：成熟的网关配置能把单供应商故障的"用户感知中断时间"从 30+ 分钟压到 < 1 分钟。这就是为什么 Stripe、Notion 这些公司的 AI 功能极少出现"AI 挂了"。

六、核心能力三：AI 治理（AI Governance）

图 5：AI 治理全景图（6 项治理能力 + 1 个统一入口）

<whiteboard token="S2TXwV6lkhpwzRbc1VncAfhTnVg"></whiteboard>

💡 一句话：当公司里几十个团队都在用大模型，CEO、CFO、法务、IT 都开始问问题——"花了多少钱""数据去哪了""谁在调、什么时候调的"——这就是AI 治理的范畴，而网关是治理落地的唯一抓手。

1. 一个治理清单（AI Governance Checklist）

参考 OpenRouter 给出的治理 checklist，企业级 LLM 网关至少要回答这些问题：

• [ ] 可观测（Observability）：每次请求记录了 prompt、completion、模型、延迟、token 数、cost、用户 ID

• [ ] 可计量（Metering）：按团队 / 项目 / 功能模块 / 用户维度统计花费

• [ ] 可限制（Quota / Rate Limit）：每个团队每月不超过 ¥xx，超额熔断或通知

• [ ] 可审计（Audit）：敏感行业的对话要可回溯，用于合规审查

• [ ] 可控制访问（Auth / RBAC）：谁能调哪个模型、能不能上传图片、能不能用 vision

• [ ] 可保护隐私（PII Redaction）：自动识别并脱敏身份证、手机号、银行卡

• [ ] 可防止滥用（Guardrails）：注入检测、违规输出拦截、批量滥用识别

• [ ] 可评估（Evaluation）：定期跑 eval 集监控质量漂移

2. 网关在治理链条里的位置

📌 类比：网关就像公司大门 + 前台 + 监控室的三合一。所有流量都得从这一道门进出，所以这里就是最适合装闸机、装监控、装警报的地方。如果每条业务线自己直连各家 API，"治理"就变成"事后诸葛亮"。

3. 治理不是为了"管死"，而是为了"用好"

很多工程师一听"治理"就担心变慢、变卡。事实恰恰相反：

• 缓存（同 prompt 直接命中）可以降低 30%+ 成本
• PII 脱敏可以避免公司因数据泄露被罚几百万
• 配额能让一个新业务在失控前被及时发现，而不是月底财务突然来质问
• 审计日志是出事后能溯源、能复盘的"黑匣子"

七、Token 中转站：个人开发者的"流量加油包"

对于个人开发者或预算紧的小团队，经常会听到 "token 中转站" 这个说法。它的本质就是共享池化的 API Key 转发服务。

1. 它和"企业网关"是什么关系？

2. 怎么看市面上良莠不齐的"中转站"？

💡 风险提示：

• 合规：你的 prompt 和数据会经过第三方，不要用于生产敏感数据

• 稳定：中转站可能因上游封号一夜消失，建议永远保留直连 API 的备用通道

• 价格：便宜过头的要警惕，可能在用"套壳 + 限速"伪装低价

• 服务：出问题基本无 SLA，无人对接

个人使用建议：用它做日常开发、学习、跑脚本没问题；如果你的产品开始对用户开放，要么迁移到直连 + 自托管网关，要么选择有 SLA 保障的托管网关。

八、企业级实践建议（重磅）

图 6：企业落地三阶段路径（PoC → 小流量 → 全面生产）

<whiteboard token="FIwsw7phhhUnwtbKd1gcIMrcnHc"></whiteboard>

图 7：LLM 网关选型决策树

<whiteboard token="Vj5Aw2PgJhEmnAbvbBwci8ZKnke"></whiteboard>

🏢 本节是企业最关心的部分：如果你要把大模型从"几个工程师玩玩"推进到"全员生产可用"，下面这套打法是踩过坑的人总结出来的。

1. 一个选型决策树

遇到"我们该选哪种网关"的灵魂拷问，按这个流程判断：

1. 你只有 1 个模型？ → 直接 API，先别上网关
2. 你要试水 2\~3 家模型？ → 托管网关（OpenRouter），10 分钟跑通
3. 你的对话数据合规要求严（如金融、政务、医疗）？ → 自托管 LiteLLM + 私有部署
4. 你的月账单 > 5 万元且团队 ≥ 5 个？ → 自托管网关 + 缓存层，省下的运维钱远大于投入
5. 你既要用 SaaS 也要用私有模型？ → 混合：LiteLLM 作为统一层（优先本地私有模型），前面挂 OpenRouter 做 SaaS 兜底（本地模型扛不住时，全网公有模型底）

2. 三阶段落地路径

💡 重要建议：不要在 PoC 阶段就过度设计！很多团队一上来就部署 LiteLLM + Prometheus + Grafana + RBAC，结果模型都没选好就累死了。先用最简单的方案验证业务，再谈治理。

3. 五个常见踩坑（避坑指南）

❌ 坑 1：把 Key 写死在代码里

不仅是安全问题，更是治理灾难——Key 一旦泄露必须全量替换，而谁用了哪个 Key、调用了多少次都没有记录。

✅ 正确做法：所有 Key 集中在网关的 vault 里，业务代码只持有网关的虚拟 Key。

❌ 坑 2：忽视 token 计费差异

同样是"输入 1000 token"，有的供应商按字符、有的按 BPE、有的把图片单独计价、有的把 tool_calls 单独计费。账单出来后一脸懵。

✅ 正确做法：由网关做统一单位换算，在 dashboard 里只显示"折算后的 token 数和金额"。

❌ 坑 3：没做 PII 脱敏

用户输入的身份证、银行卡、人脸照片全送到了 OpenAI，等于把隐私数据当训练语料（虽然 OpenAI 声明不会训练，但合规要求你做到"最少必要"）。

✅ 正确做法：网关前做正则 + NER 识别 + 替换 + 还原。或者直接用 Microsoft Presidio、AWS Comprehend PII 等。

❌ 坑 4：把 OpenAI SDK 写进业务每个角落

等你想换供应商时，发现 100 个文件都依赖 from openai import OpenAI。

✅ 正确做法：业务层只调自家网关的 OpenAI 兼容接口，换供应商只改网关配置。

❌ 坑 5：缓存策略太激进

有人为了省钱把所有请求都开了语义缓存，结果同一个问题给所有用户返回了同一个答案，引发严重客诉。

✅ 正确做法：缓存按场景分级——只对"无状态、可复用"的查询做缓存（如 FAQ、文档问答），对"个性化对话"严禁缓存。

4. 给老板的"一页纸"建议

📋 如果只能记住 5 句话：

1. 小团队用托管网关省心，大企业用自托管可控

2. 网关的核心是路由 + 兜底 + 治理三件事

3. 先跑通业务，再补治理，避免过度设计

4. 永远留一条直连的备用通道，网关本身也会挂

九、实战 5 分钟：用 OpenRouter 跑通多模型

1. 注册 + 拿 Key

打开 ，注册账号 → 创建 API Key → 充值 \$5（够学习用很久）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

import os, requests

API_KEY = os.environ["OPENROUTER_API_KEY"]
URL = "https://openrouter.ai/api/v1/chat/completions"

MODELS = [
    "openai/gpt-4o-mini",
    "anthropic/claude-3-haiku",
    "deepseek/deepseek-chat",
]

prompt = "用一句话解释什么是 LLM 网关。"

for m in MODELS:
    r = requests.post(URL,
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={"model": m, "messages": [{"role": "user", "content": prompt}]})
    data = r.json()
    print(f"=== {m} ===")
    print(data["choices"][0]["message"]["content"])
    print(f"cost: ${data.get(usage, {}).get(cost, 0):.6f}\n")

🚀 延伸阅读（参考资料）：

• OpenRouter Blog:

• OpenRouter Blog:

• OpenRouter Blog:

• OpenRouter Blog:

• LiteLLM 开源项目：

• Portkey：