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

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 混用时，怎么公平对比质量与成本？