LLM 多模型路由与生产级灰度架构：从单一 GPT 到多模型编排的最后一公里

一、为什么 PoC 调一次 API 不等于生产可用

几乎所有 LLM 应用都从这样一个 PoC 开始：openai.chat.completions.create(...) 调一次 GPT-4，输出符合预期，Demo 给老板看，老板说"上生产吧"。然后团队就会撞上一堵墙——生产环境的复杂度是 PoC 的 100 倍。上游模型限流、多模型并存、Prompt 改一行全网崩溃、Token 成本失控、A/B 实验无法做、突发流量扛不住……每一个问题都在 PoC 中不存在，进了生产全部出现。

从架构视角看，LLM 应用从 PoC 到生产必须建立四个独立但相互依赖的体系：多模型路由、Prompt 版本管理、灰度发布、降级容灾。它们不是工具的堆砌，而是质量工程的完整闭环。把这套体系做扎实，LLM 应用才能从"能跑"走到"扛得住"。

graph TB
    subgraph PoC 阶段
        A[业务代码] -->|直接调用| B[GPT-4]
    end

    subgraph 生产阶段
        C[业务代码] --> D[LLM Gateway]
        D --> E[GPT-4]
        D --> F[Claude]
        D --> G[自研模型]
        D --> H[缓存层]
        D --> I[降级层]
        D --> J[审计日志]
    end

二、多模型路由网关的整体架构

多模型路由网关是 LLM 应用的"前置流量调度层"。它把业务代码与底层模型解耦，让业务只关心"我要调用 LLM 完成什么任务"，不关心"具体走哪个模型"。这是 LLM 应用从单模型到多模型的关键基础设施。

graph TB
    subgraph 业务侧
        APP1[业务 App A] --> G[LLM Gateway]
        APP2[业务 App B] --> G
        APP3[业务 App C] --> G
    end

    subgraph Gateway 内部
        G --> AUTH[鉴权/限流]
        AUTH --> ROUTER[路由引擎]
        ROUTER --> CACHE[语义缓存]
        ROUTER --> POLICY[策略引擎]
        POLICY --> OBS[埋点上报]
    end

    subgraph 模型侧
        POLICY --> M1[OpenAI GPT-4]
        POLICY --> M2[Anthropic Claude]
        POLICY --> M3[通义千问]
        POLICY --> M4[自研模型]
        POLICY --> M5[降级小模型]
    end

    OBS --> K[Kafka]
    K --> D[数据仓库]

2.1 Gateway 的核心职责

Gateway 必须承担六个职责：（1）鉴权与限流——多租户配额、Token 速率控制；（2）路由决策——按业务标签选择模型；（3）协议适配——统一 OpenAI/Anthropic/自研模型的请求协议；（4）缓存——语义缓存、Prompt 缓存；（5）降级——上游故障时切到备用模型；（6）审计——所有请求的输入输出留痕。

2.2 协议统一层

不同模型的 API 协议差异巨大——OpenAI 用 messages 数组，Anthropic 用 system 分开处理，Google 用 contents 字段。Gateway 必须做协议适配层，把所有模型统一为 OpenAI 兼容协议。这样业务方只写 OpenAI SDK 就能调用所有模型，切换模型零成本。

2.3 异步化设计

LLM 推理是 IO 密集型操作，单次请求 1-10 秒。同步调用会迅速打满业务线程池，必须异步化：Gateway 接收请求后立即返回 Future/TaskID，模型推理完成后回调通知。配合 Streaming SSE 协议，可以把首 token 延迟压到 200ms 内。

三、模型路由策略：从硬编码到智能调度

模型路由策略决定了"哪个请求走哪个模型"。从硬编码到智能调度，经历了三个演进阶段。

graph LR
    A[阶段一·硬编码] -->|配置化| B[阶段二·规则路由]
    B -->|机器学习| C[阶段三·智能调度]

3.1 阶段一：硬编码路由

最初所有业务代码都直接写死模型名称：openai.ChatCompletion.create(model='gpt-4', ...)。切换模型要改业务代码、重新发布，一周内多模型并存根本不可能。第一个月就翻车——某个业务偷偷切到 GPT-4 Turbo，成本翻 3 倍。

3.2 阶段二：基于规则的路由

把模型选择抽到配置中心，业务代码只指定"业务标签"（如 translation/summary/coding），Gateway 根据规则表匹配模型。
优势：切换模型改配置即可，无需发版；
劣势：无法根据上下文动态选择——简单问题用 GPT-4 浪费，复杂问题用小模型质量差。

3.3 阶段三：智能路由

引入"问题难度评估器"——先用小模型（GPT-3.5/Claude Haiku）评估问题难度，简单问题走小模型，复杂问题走大模型。成本直降 60%，质量反而提升（大模型专注处理难题）。我们还引入"成本约束"维度：业务方可以声明"这条请求不超过 $0.01"，Gateway 自动选择性价比最高的模型。

3.4 路由策略的工程实现

路由决策不能每次重新评估——会引入 50-200ms 延迟。我们采用规则 + 缓存 + 降级三层架构：先按业务标签查规则（O(1)），规则命中直接返回；规则未命中时启动问题难度评估（缓存评估结果 1 小时）；评估失败降级到默认模型。

四、Prompt 版本管理：避免"改一行崩全网"

Prompt 是 LLM 应用的"代码"。改一行 Prompt 可能让所有输出变化，但 Prompt 又不像代码那样有版本控制、灰度发布、回滚机制。这是 LLM 工程化最痛的点。

graph TB
    A[Prompt 仓库] --> B[版本控制]
    B --> C[环境隔离]
    C --> D[灰度发布]
    D --> E[效果监控]
    E --> F{效果达标?}
    F -->|是| G[全量发布]
    F -->|否| H[回滚]

4.1 Prompt 即代码

我们把 Prompt 当作代码管理——Git 仓库、PR 流程、Code Review、CI/CD。所有 Prompt 修改必须走 PR，必须经过效果测试（golden dataset），必须经过架构师 review。没有这个机制，工程师随手改 Prompt 上线是常态，全网崩溃也成了常态。

4.2 Prompt 版本号与发布

每个 Prompt 必须有版本号（v1.0.0），与代码版本同步发布。
关键设计：Prompt 版本与代码版本绑定——代码 v2.3.1 必须用 Prompt v2.3.1，不能跨版本混用。
实现方式：把 Prompt 文件编译进 Docker 镜像，业务容器启动时按版本加载。回滚代码版本自动回滚 Prompt 版本。

4.3 效果评估：Golden Dataset

Prompt 改动必须用 Golden Dataset 评估。Golden Dataset 是 200-500 个精心设计的"标准问答对"，覆盖核心场景。每次 Prompt 改动自动跑 Golden Dataset，效果下降超过 5% 不允许发布。这是防止"改一行崩全网"的关键防线。

五、灰度发布：金丝雀与流量分配

LLM 应用的灰度比传统服务更难——效果评估延迟长、需要 A/B 对比、人工反馈循环。我们的灰度策略分为三个层级。

graph TB
    A[新版本 Prompt/模型] --> B[1% 灰度]
    B -->|观察 24h| C[10% 灰度]
    C -->|观察 24h| D[50% 灰度]
    D -->|观察 24h| E[全量发布]
    B -.监控.-> M[效果指标]
    C -.监控.-> M
    D -.监控.-> M

5.1 基于用户分桶的灰度

用 UserID 哈希分桶，确保同一用户始终走同一版本——避免同一用户前后体验不一致。1% 灰度 = 1% 用户走新版本，99% 用户走旧版本。观察 24 小时的效果指标：满意度、跳出率、对话轮次、人工评分。

5.2 基于流量比例的灰度

某些场景不适合按用户分桶（用户量大、效果差异需要对比）。改用随机流量比例：每次请求有 1% 概率走新版本。但要做好去重——同一 Session 内必须走同一版本，否则用户体验割裂。

5.3 灰度的效果评估

灰度期间必须监控三个核心指标：用户满意度（点赞率）、任务完成率、平均对话轮次。新版本满意度下降超过 2% 立即回滚。我们的经验：LLM 灰度效果需要 24-48 小时才能稳定——刚发布时用户不适应，指标会暂时下降，不能立即回滚。

六、降级与容灾：上游限流的工程对策

LLM 上游服务（OpenAI、Anthropic）经常限流、故障、维护。一次 OpenAI 限流就能让你的整个产品停摆。生产级 LLM 应用必须有完整的降级容灾体系。

graph TB
    A[请求] --> B{GPT-4 可用?}
    B -->|是| C[走 GPT-4]
    B -->|否| D{Claude 可用?}
    D -->|是| E[走 Claude]
    D -->|否| F{本地小模型可用?}
    F -->|是| G[走本地模型]
    F -->|否| H[返回静态兜底]

6.1 熔断器模式

借鉴传统微服务的熔断器：每个上游模型维护一个熔断器。30 秒内错误率超 50% 自动熔断，不再向该模型发请求，5 分钟后半开探测。熔断期间流量自动切到备用模型。这是 LLM Gateway 最核心的容灾机制。

6.2 多模型冗余

关键业务必须配置至少 2 个备用模型，且来自不同厂商——避免单一厂商故障连累所有路径。我们的标配：主用 OpenAI GPT-4，备用 Anthropic Claude，第三备用自研小模型，本地缓存兜底。

6.3 静态兜底答案

所有模型都挂掉时（极端情况），必须有静态兜底答案。例如客服场景返回"当前咨询较多，请稍后再试"；翻译场景返回原文；摘要场景返回文档前 200 字。有兜底的产品叫"降级"，没兜底的产品叫"崩溃"。

6.4 限流防护

业务方不知道上游限流阈值，必须 Gateway 主动防护。我们的策略：每个模型配置 RPM（每分钟请求数）和 TPM（每分钟 Token 数）双维度限流，达到 80% 触发预警，达到 95% 触发排队，超过 100% 直接拒绝。这避免上游超限被封号。

七、成本治理：Token 预算与归因

LLM 应用的运营成本 80% 来自 Token 消耗。没有成本治理的 LLM 应用，一个月就能烧掉百万级预算。我们的成本治理体系分三层。

graph TB
    A[Token 消耗] --> B[预算层]
    B --> C[租户配额]
    B --> D[业务线预算]
    C --> E[实时统计]
    D --> E
    E --> F[归因分析]
    F --> G[成本中心]

7.1 预算管理

每月初为每个业务线设置 Token 预算（按金额或按 Token 数）。实时统计消耗，达到 80% 报警，达到 95% 限制，达到 100% 强制降级到小模型。预算超支的责任直接落到业务负责人，避免"反正公司付钱"的道德风险。

7.2 归因分析

每条 LLM 请求必须打标：业务线、用户、Prompt 版本、模型、Token 数、成本。所有数据进数据仓库，支持任意维度的成本归因——"哪个业务线最烧钱"、"哪个 Prompt 版本最贵"、"哪个用户群成本最高"。

7.3 成本优化技巧

三个最有效的优化手段：
（1）语义缓存——相似问题的回答缓存复用，命中率 30%+ 直接砍掉 30% 成本；
（2）Prompt 压缩——删除冗余指令、合并重复上下文，Prompt 缩短 30% 不影响效果；
（3）分级模型——简单任务用 GPT-3.5，复杂任务用 GPT-4，整体成本降 50%。

八、生产踩坑：GPT-4 限流崩盘实录

2025 年 11 月某个周二下午 3 点，OpenAI 突然宣布 GPT-4 全局限流。我们的核心产品 30 分钟内完全停摆，直接损失订单 800 万。下面是这次事故的完整复盘。

8.1 事故起因

OpenAI 因为基础设施故障，对所有 GPT-4 用户降级到 1/10 配额。我们没有配置备用模型，所有请求直冲 GPT-4，熔断器全开、流量 100% 失败。

8.2 事故放大

更糟的是我们的重试策略——失败立即重试 3 次。OpenAI 已经在限流，我们的重试反而把限流触发的更狠，OpenAI 直接把我们账号加入观察名单，恢复时间延迟 4 小时。

8.3 事故修复

紧急修复花了 90 分钟：（1）熔断器改为失败 5 次熔断 30 秒，避免雪崩；（2）所有业务紧急切到 Claude 和本地小模型；（3）静态兜底答案全量配置；（4）给所有业务方发邮件告知降级方案。这次事故的根因不是 OpenAI，而是我们没有多模型冗余。

8.4 教训提炼

五条铁律：（1）核心业务必须有 2 个以上模型冗余，不能依赖单一厂商；（2）重试必须指数退避，不能立即重试加剧故障；（3）静态兜底是最后防线，必须每个业务配置；（4）熔断器必须实时生效，不能等 5 分钟才发现故障；（5）预案必须演练，故障时手动操作来不及。

九、演进方向：LLM Gateway 标准化

多模型路由架构正在快速标准化。未来 2-3 年，LLM Gateway 会像 API Gateway 一样成为云原生标配，形成统一的协议、监控、成本治理标准。

graph LR
    A[业务应用] --> B[LLM Gateway 标准]
    B --> C[OpenAI]
    B --> D[Anthropic]
    B --> E[Google]
    B --> F[开源模型]
    B --> G[自研模型]

关键技术演进方向：
（1）协议标准化——OpenAI API 已成为事实标准，所有模型厂商都在兼容；
（2）Prompt 即代码——PromptOps 平台化，Prompt 版本管理、灰度、A/B 实验标准化；
（3）智能路由——基于成本、质量、延迟的多目标优化路由成为标配；
（4）可观测性——LLM 专有的监控指标（Token 速率、Prompt 命中率、模型质量分数）形成标准。

另一个重要方向是多模态路由——文本、图像、音频、视频统一路由。当前每个模态走独立通道，未来 Gateway 必须支持多模态联合推理、按模态成本拆分、统一质量评估。

最后是边缘 LLM + 云端 LLM 的协同路由。简单问题走边缘小模型（5ms 响应），复杂问题走云端大模型（2s 响应），这种分层架构会把 LLM 应用的延迟和成本压到新低。提前布局的团队，会在下一代 LLM 应用架构中占据先机。