27届大模型面试准备（八十四）：大模型统一 API 网关与多模型接入工程——路由、降级、计费与多供应商容灾

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 框架）开箱可用，业务侧零改造。

# 适配层：把不同后端统一为同一接口
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），网关映射到具体厂商与版本。这样换厂商时业务完全无感。

三、路由策略

路由是网关的灵魂，常见维度：

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
│ └─ 全挂 ─> 小模型兜底 / 缓存兜底 / 明确报错
└─ 成本超预算 ─> 降级到便宜档模型

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 次，避免雪崩）、降级可感知（响应头里告知实际用了哪个模型，便于排查）。

五、计量、配额与成本归因

网关是做成本治理的最佳位置，因为所有调用都经过它：

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 时。

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 计量，按团队/应用设日/月配额与预算，达阈值告警或降级，成本归因出账单。

高频追问清单