27届大模型面试准备（八十四）：大模型统一 API 网关与多模型接入工程------路由、降级、计费与多供应商容灾
引言
本文是系列第 84 篇，也是本批（A83/A84）的收尾。前面各篇讲的都是"怎么把单个模型服务好"，这一篇讲它上面那层：当一个组织里同时用着自研模型、几家云厂商 API、开源自建服务，怎么给业务方提供一个稳定、统一、可控的入口。这就是大模型统一网关（LLM Gateway）。
这是企业落地大模型几乎必然要建的一层：没有它，每个业务各自接 API，密钥满天飞、成本失控、某家厂商一挂全线崩、想换模型要改所有代码。面试官问"你们怎么管理多个模型的调用"时，网关是标准答案。
统一网关架构
==================================================
业务方（多团队 / 多应用）
│ 统一 OpenAI 兼容协议
▼
┌──────────────────────────────────┐
│ 统一 API 网关 │
│ ┌────────┬────────┬───────────┐ │
│ │ 鉴权 │ 路由 │ 限流/配额 │ │
│ ├────────┼────────┼───────────┤ │
│ │ 降级 │ 缓存 │ 计费/计量 │ │
│ ├────────┼────────┼───────────┤ │
│ │ 审计 │ 脱敏 │ 可观测 │ │
│ └────────┴────────┴───────────┘ │
└───────────────┬──────────────────┘
│ 适配层
┌────────────┼────────────┐
▼ ▼ ▼
自研模型 云厂商 A 云厂商 B
(vLLM) (API) (API)一、为什么需要网关
| 痛点 | 无网关 | 有网关 |
|---|---|---|
| 密钥管理 | 各业务散落，泄露风险高 | 集中托管，业务侧无密钥 |
| 换模型 | 改所有业务代码 | 改路由配置 |
| 厂商故障 | 全线不可用 | 自动降级到备用模型 |
| 成本 | 无法归因，无法限制 | 按团队计量、设预算 |
| 合规 | 无法统一审计脱敏 | 统一策略 |
| 限流 | 各业务各自为政 | 全局配额 |
核心价值一句话：把"用哪个模型"这个决策从业务代码里抽出来，变成可运行时调整的治理问题。
二、协议统一：OpenAI 兼容层
事实标准是把所有后端（无论自研 vLLM、各家云 API）统一适配成 OpenAI 兼容的 /v1/chat/completions 协议。好处是生态工具（SDK、LangChain、各类 Agent 框架）开箱可用，业务侧零改造。
python
# 适配层：把不同后端统一为同一接口
class ProviderAdapter:
def __init__(self, name, client, model_map):
self.name, self.client, self.model_map = name, client, model_map
async def chat(self, req):
real_model = self.model_map.get(req.model, req.model)
try:
return await self.client.chat_completions(
model=real_model, messages=req.messages,
temperature=req.temperature, max_tokens=req.max_tokens,
stream=req.stream)
except ProviderError as e:
raise UpstreamError(provider=self.name, cause=e)注意模型名映射 ：业务方用逻辑名（如 gpt-pro、gpt-lite），网关映射到具体厂商与版本。这样换厂商时业务完全无感。
三、路由策略
路由是网关的灵魂，常见维度：
| 策略 | 说明 | 场景 |
|---|---|---|
| 按模型名 | 逻辑名映射 | 基础 |
| 按成本 | 便宜模型优先，超预算降级 | 成本敏感 |
| 按延迟 | 选最快可用后端 | 实时交互 |
| 按内容 | 长上下文/多模态走特定后端 | 能力匹配 |
| 按租户 | 不同租户不同后端（合规隔离） | B 端 |
| 按权重 | 灰度/AB 分流 | 新模型上线 |
python
def route(req, ctx, candidates):
# 1. 硬性约束过滤：上下文长度、多模态能力、合规区域
cands = [c for c in candidates if c.max_ctx >= req.est_tokens
and (not req.has_image or c.supports_vision)
and c.region_allowed(ctx.tenant)]
if not cands:
raise NoAvailableProvider()
# 2. 成本优先 + 延迟约束
cands = [c for c in cands if c.p95_latency_ms <= ctx.sla_ms] or cands
return min(cands, key=lambda c: c.cost_per_1k_tokens)关键工程点：路由必须有硬性约束过滤（能力、合规）在前，成本/延迟优化在后。顺序反了会把多模态请求路由到不支持视觉的廉价模型。
四、降级与多供应商容灾
单供应商故障是必然事件。网关要提供自动降级链：
降级链（示例）
主模型：自研 vLLM 集群
├─ 故障/超时 ─> 云厂商 A 同档模型
│ ├─ 也故障 ─> 云厂商 B
│ └─ 全挂 ─> 小模型兜底 / 缓存兜底 / 明确报错
└─ 成本超预算 ─> 降级到便宜档模型
python
FALLBACK_CHAIN = ["selfhost-70b", "vendorA-pro", "vendorB-pro", "selfhost-7b"]
async def chat_with_fallback(req, ctx):
errors = []
for name in FALLBACK_CHAIN:
if not health_ok(name):
continue
try:
return await PROVIDERS[name].chat(req)
except UpstreamError as e:
errors.append((name, str(e)))
circuit.record_failure(name) # 熔断计数
raise AllProvidersFailed(errors)配套三件事：健康检查/熔断 （连续失败即临时摘除）、超时与重试预算 （重试不超过 1 次，避免雪崩）、降级可感知（响应头里告知实际用了哪个模型，便于排查）。
五、计量、配额与成本归因
网关是做成本治理的最佳位置，因为所有调用都经过它：
| 能力 | 实现 |
|---|---|
| 计量 | 记录 input/output token、模型、租户、应用 |
| 配额 | 按团队/应用设日/月预算，超限拒绝或降级 |
| 归因 | 成本分摊到团队，出账单 |
| 预算告警 | 达 80%/100% 告警 |
python
def bill(resp, provider):
rate = PRICING[provider][resp.model]
cost = (resp.prompt_tokens / 1000 * rate["in"]
+ resp.completion_tokens / 1000 * rate["out"])
metrics.counter("llm_cost", cost, tags={
"tenant": resp.ctx.tenant, "app": resp.ctx.app,
"model": resp.model, "provider": provider})
if budget_exceeded(resp.ctx.tenant):
raise BudgetExceeded()
return cost六、缓存、审计与脱敏
三项目常被忽视但都很关键：
- 缓存：完全相同或语义相近的请求可复用结果。精确缓存（哈希）安全，语义缓存（向量相似）要谨慎------设相似度阈值并限定在幂等场景（如 FAQ），否则容易返回错误答案。
- 审计：记录谁、何时、用了哪个模型、输入输出摘要。合规行业要求可追溯。
- 脱敏：出网前对 PII（手机号、身份证、银行卡）做检测与脱敏，尤其是调用外部厂商 API 时。
python
import re
PII_PATTERNS = {
"phone": re.compile(r"1[3-9]\d{9}"),
"id_card": re.compile(r"\d{17}[\dXx]"),
"bank": re.compile(r"\d{16,19}"),
}
def mask_pii(text):
for name, pat in PII_PATTERNS.items():
text = pat.sub(f"[REDACTED_{name.upper()}]", text)
return text面试速答
问：为什么要建统一网关？
答：把"用哪个模型"从业务代码抽出来变成运行时可治理的问题。收益是集中密钥管理、换模型零改造、供应商故障自动降级、按团队计量与限预算、统一审计脱敏。
问：多供应商故障怎么容灾？
答：降级链 + 熔断。按优先级配置候选后端，健康检查与连续失败熔断摘除，超时与重试预算控制（重试≤1 次防雪崩），响应头告知实际使用的模型便于排查。
问：路由策略怎么设计？
答：先硬性约束过滤（上下文长度、多模态能力、合规区域），再做成本/延迟优化。顺序不能反，否则会把多模态请求路由到不支持视觉的廉价模型。
问：成本怎么治理？
答：网关是最佳位置------所有调用都经过。记录 input/output token 计量，按团队/应用设日/月配额与预算，达阈值告警或降级，成本归因出账单。
高频追问清单
- 语义缓存的相似度阈值怎么定？什么场景绝对不能用？
- 流式响应（SSE）经过网关时，计量和审计怎么做（结束时才知 token 数）？
- 降级到不同能力的模型，输出格式不一致怎么办？
- 熔断的失败阈值与恢复探测怎么设？
- 多家厂商的 token 计数不一致，计费以谁为准？
- 长请求（分钟级）占用网关连接，连接池怎么规划？
- 合规要求"数据不出境"，路由怎么强制约束？
- 网关本身成为单点故障，怎么做高可用？
- 灰度新模型时，怎么保证同一用户稳定命中同一版本？
- 自研模型与云 API 混用时，怎么公平对比质量与成本？