LLM（Large Language Model，大语言模型）进入业务系统后，AI 调用很快会从“少量实验接口”变成“高频核心链路”。智能客服、内容生成、代码辅助、搜索问答、图像理解、商品审核、运营工具，都可能在背后调用不同厂商、不同形态、不同价格的大模型。

问题也会随之出现：

• 业务团队直接接各家模型，接口协议、鉴权方式、参数格式都不一样。
• 模型调用按 Token 计费，用量增长后成本容易失控。
• 外部模型可能接收 Prompt、用户输入、图片等敏感数据，需要统一做安全治理。
• 模型服务延迟波动比传统接口更明显，还经常受到 TPM、RPM、QPS 等配额限制。
• 一旦某个厂商服务异常，业务侧如果没有兜底策略，就会直接失败。

大模型网关要解决的就是这些问题。它不是简单把请求转发出去，而是在业务应用和模型基础设施之间增加一层统一治理面，让模型接入、调度、计费、限流、观测、安全都在一个地方完成。

flowchart LR
    A[业务应用] --> B[大模型网关]
    B --> C[自建模型]
    B --> D[云厂商模型]
    B --> E[开源模型托管服务]
    B --> F[多模态模型服务]

    B -.治理能力.-> G[鉴权]
    B -.治理能力.-> H[限流]
    B -.治理能力.-> I[调度]
    B -.治理能力.-> J[成本统计]
    B -.治理能力.-> K[监控告警]
    B -.治理能力.-> L[安全审计]

大模型网关和传统 API 网关的区别

传统 API Gateway（应用程序编程接口网关）主要处理普通 HTTP 流量，例如鉴权、路由、限流、熔断、日志和服务发现。大模型网关也需要这些能力，但 AI 请求有明显不同。

大模型网关更像 AI 流量的控制中心。它既要懂 HTTP，也要懂模型、Token、Prompt、上下文、成本和厂商能力差异。

整体架构：控制面和数据面分离

企业级大模型网关通常可以拆成两层：控制面和数据面。

控制面负责配置和治理，包括模型市场、API Key 管理、预算、路由策略、限流规则、告警规则等。数据面负责处理真实请求，包括鉴权、参数转换、Token 预估、限流、调度、转发、响应解析、日志上报等。

flowchart TB
    subgraph CP[控制面]
        M[模型市场]
        K[API Key 生命周期]
        B[预算与成本规则]
        R[模型调度策略]
        L[限流与容量配置]
        O[监控告警配置]
    end

    subgraph DP[数据面]
        A[统一 API 入口]
        Auth[鉴权与权限校验]
        Mask[敏感信息处理]
        Limit[QPS/RPM/TPM 限流]
        Router[模型调度与路由]
        Adapter[厂商协议适配]
        Log[调用日志与指标采集]
    end

    App[业务应用] --> A
    A --> Auth --> Mask --> Limit --> Router --> Adapter
    Adapter --> V1[厂商 A]
    Adapter --> V2[厂商 B]
    Adapter --> V3[自建模型]
    Adapter --> V4[托管开源模型]

    CP -.下发配置.-> DP
    DP -.上报数据.-> CP

这种拆分有两个好处。

控制面可以慢一些，但要完整、可审计、可配置；数据面必须快，要保证高可用、低额外延迟，并且不能因为管理后台异常影响线上调用。

企业落地时最常见的四个问题

接口碎片化导致重复建设

一个企业内部可能同时使用自建模型、开源模型、云厂商模型和 SaaS（Software as a Service，软件即服务）模型。不同模型的接口差异很大：

• 鉴权方式不同，有的用 Bearer Token，有的用 AK/SK，有的用签名。
• 参数命名不同，例如 messages、prompt、input。
• 流式响应格式不同。
• 错误码、重试语义、限流返回也不统一。
• 图像、语音、多模态能力的入参结构差异更大。

如果每个业务系统都自己适配一遍，会形成很多烟囱式实现。后续新增模型、替换厂商、做成本优化，都要改很多业务代码。

大模型网关应该把这些差异封装起来，对业务提供统一入口。

Token 成本增长快，必须集中治理

模型费用一般与 Token 直接相关。调用量一旦进入生产阶段，成本增长会非常快。

粗略看，模型成本可以按下面的方式拆解：

成本治理不能只靠月底账单回看。更合理的做法是在调用前、调用中、调用后都建立约束。

flowchart LR
    A[预算申请] --> B[API Key 分配]
    B --> C[模型选型]
    C --> D[调用限额]
    D --> E[实时用量统计]
    E --> F[成本大盘]
    F --> G[预警与告警]
    G --> H[模型调度优化]
    H --> C

外部模型带来数据安全压力

业务请求中可能包含用户信息、订单信息、图片、内部知识库内容、代码片段、运营数据等。如果这些内容直接发给外部模型厂商，会带来隐私、合规和泄露风险。

常见治理动作包括：

如果没有统一网关，安全规则很难在所有业务系统里保持一致。

稳定性比普通接口更难控制

大模型服务经常受到算力、队列、厂商配额、上下文长度等因素影响。相比普通 REST 接口，模型调用更容易出现长延迟、限流、流式中断和成功率波动。

稳定性治理至少要覆盖这些维度：

六个关键建设模块

模型市场：把模型供给变成可搜索、可比较、可接入的资源

模型市场不是简单列一个模型清单，而是把模型的能力、价格、限制、接入方式和评测结果组织起来，让业务方能快速完成选型。

一个可用的模型市场至少要维护这些信息：

有了模型市场，业务团队不需要到处问“哪个模型适合这个场景”。他们可以先用真实问题做多模型对比，再根据效果、延迟、成本、安全等级选择模型。

模型市场还应该支持一站式接入：选中模型后，直接生成 API 文档、示例代码、Key 申请入口和预算申请入口。

统一 API：让业务不用关心厂商差异

企业内部可以采用 OpenAI 兼容风格的接口作为统一协议。这样做的好处是生态兼容性强，很多 SDK、Agent 框架和应用代码可以直接复用。

一个典型的调用方式如下：

curl https://llm-gateway.example.com/v1/chat/completions \
  -H "Authorization: Bearer ${API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "customer-service-chat",
    "messages": [
      {
        "role": "system",
        "content": "你是一个客服助手，回答要简洁准确。"
      },
      {
        "role": "user",
        "content": "我的订单为什么还没发货？"
      }
    ],
    "stream": true,
    "temperature": 0.3
  }'

这里的 model 不一定是真实厂商模型名，也可以是业务语义化模型别名，例如：

• customer-service-chat
• code-assistant
• content-review
• cheap-summary
• vision-understanding

业务只关心能力，网关负责把别名解析成真实模型，并完成厂商协议转换。

flowchart LR
    A[业务请求: customer-service-chat] --> B[网关解析模型别名]
    B --> C{调度策略}
    C --> D[厂商 A 模型]
    C --> E[厂商 B 模型]
    C --> F[自建模型]
    D --> G[统一响应格式]
    E --> G
    F --> G
    G --> A

统一 API 的核心不是“所有模型都变成同一个模型”，而是把公共字段、响应结构、错误码和流式协议尽量统一。模型特有能力可以放到扩展字段里，避免主协议被厂商细节污染。

模型调度：在成本、延迟、效果和可用性之间做选择

同一个业务能力通常可以由多个模型提供。模型调度器要根据策略选择最合适的目标模型。

常见调度策略如下：

一个简单的路由配置可以这样表达：

model_alias: customer-service-chat
routing_strategy: priority_failover
candidates:
  - provider: vendor-a
    model: model-a-chat
    priority: 1
    max_tpm: 200000
    timeout_ms: 8000
  - provider: vendor-b
    model: model-b-chat
    priority: 2
    max_tpm: 150000
    timeout_ms: 10000
fallback:
  enabled: true
  on_status:
    - 429
    - 500
    - 502
    - 503
  on_timeout: true

请求执行链路可以设计成这样：

sequenceDiagram
    participant App as 业务应用
    participant GW as 大模型网关
    participant R as 模型调度器
    participant A as 厂商A模型
    participant B as 厂商B模型

    App->>GW: 调用统一 API
    GW->>GW: 鉴权、脱敏、Token 预估
    GW->>R: 查询路由策略
    R-->>GW: 返回首选模型 A
    GW->>A: 转发请求
    A-->>GW: 超时或限流
    GW->>R: 触发降级判断
    R-->>GW: 返回备用模型 B
    GW->>B: 重试请求
    B-->>GW: 返回模型结果
    GW-->>App: 返回统一响应

调度器不能只看配置，也要结合实时指标。某个模型即使配置优先级高，如果最近 3 分钟失败率明显升高，就应该临时降权或熔断。

成本治理：从预算、用量到模型切换形成闭环

Token 成本治理要尽量前置，而不是等账单出来再处理。

一个完整的成本体系通常包含这些能力：

成本计算可以抽象成：

单次调用成本 =
输入 Token 数 * 输入 Token 单价
+ 输出 Token 数 * 输出 Token 单价
+ 多模态附加费用

为了让业务真的愿意治理成本，成本大盘要能回答几个具体问题：

• 哪个项目花费最高？
• 哪个 API Key 最近一小时 Token 增长异常？
• 哪个模型的每百万 Token 成本最高？
• 同类任务有没有更低价且效果接近的模型？
• 某次成本上涨是调用量增加，还是模型单价变高？
• 流式输出是否因为没有长度限制导致输出 Token 过多？

成熟落地后，常见收益会非常直接：模型上架从天级缩短到分钟级，试用评测从人工沟通变成平台化对比；在调用量翻倍增长的情况下，每百万 Token 成本仍然可以通过模型切换、厂商折扣、低价模型替代和预算预警持续下降。

稳定性：容量、限流、熔断和容灾一起做

大模型网关的稳定性不能只靠重试。模型调用本身成本高、耗时长，盲目重试可能让故障扩大，还会增加 Token 费用。

更合理的稳定性体系包含四层：

flowchart TB
    A[容量管理] --> B[限流]
    B --> C[熔断]
    C --> D[容灾切换]
    D --> E[告警与复盘]

容量管理

容量管理的核心是提前知道每个业务最多能用多少资源。常用指标包括：

• QPS（Queries Per Second，每秒请求数）
• RPM（Requests Per Minute，每分钟请求数）
• TPM（Tokens Per Minute，每分钟 Token 数）
• 并发请求数
• 单请求最大输入 Token
• 单请求最大输出 Token

其中 TPM 对大模型尤其重要。两个请求的成本和资源占用可能完全不同：一个请求只有几十个 Token，另一个请求可能带着几万 Token 的上下文。只按请求次数限流，会放过真正消耗资源的大请求。

限流

限流要支持多维度叠加：

Token 限流通常分两步做：请求前根据分词器估算输入 Token，并预留最大输出 Token；响应完成后再用真实用量回补统计。如果是流式响应，还需要边生成边累计输出 Token，避免超长输出拖垮额度。

熔断与容灾

当某个模型出现异常，网关要能快速识别并切换：

容灾切换要注意模型兼容性。不同模型输出风格、函数调用格式、JSON 严格程度可能不同，不能把所有请求都无脑切过去。关键业务最好提前做模型等价性评测，并维护可替换模型清单。

分钟级可观测：让异常在业务投诉前暴露

大模型网关要采集三类数据：调用指标、用量成本、异常事件。

实时链路可以采用 Kafka + Flink 一类的流式计算方案。网关把调用事件写入消息队列，实时计算任务按模型、Key、项目、厂商等维度聚合，再把结果写入监控系统和告警系统。

flowchart LR
    A[网关调用日志] --> B[Kafka 事件流]
    B --> C[Flink 实时计算]
    C --> D[分钟级指标库]
    D --> E[监控大盘]
    D --> F[告警系统]
    F --> G[负责人通知]

告警规则不要只做固定阈值，也要关注突增突降。例如：

• 某 API Key 3 分钟内失败率超过 5%。
• 某模型 P95 RT 连续 5 分钟高于历史均值 2 倍。
• 某项目小时级 Token 消耗超过昨日同期 3 倍。
• 某厂商 429 错误突然升高。
• 某 Key 预算使用率超过 90%。

分钟级观测的价值在于缩短定位时间。模型异常时，研发需要马上知道是业务请求变了、Key 超额了、模型限流了、厂商故障了，还是网关自身出了问题。

API Key 生命周期：把权限、预算、容量和审计串起来

API Key（应用程序接口密钥）不应该只是一个字符串。它是大模型网关治理体系的核心对象，可以绑定负责人、项目、预算、模型权限、限流额度和告警规则。

一个完整生命周期可以这样设计：

stateDiagram-v2
    [*] --> 申请中
    申请中 --> 已驳回: 审批不通过
    申请中 --> 生效中: 审批通过并分配额度
    生效中 --> 冻结中: 风险、超预算或违规调用
    冻结中 --> 生效中: 解除冻结
    生效中 --> 轮换中: 定期换密
    轮换中 --> 生效中: 新 Key 生效
    生效中 --> 已注销: 项目下线
    已驳回 --> [*]
    已注销 --> [*]

Key 管理至少要包含这些字段：

Key 生命周期管理做好后，鉴权、预算、容量、调度、观测就能围绕 Key 串起来。否则所有请求都混在一起，出了问题很难定位责任边界。

适合自建大模型网关的场景

不是所有团队都需要自建大模型网关。如果调用量很小，只接一个模型，用厂商控制台和 SDK 就够了。自建网关适合更复杂的企业级场景。

落地顺序建议

大模型网关不要一开始就做成复杂平台。更稳妥的方式是从统一入口开始，再逐步补齐治理能力。

这个顺序的关键是先把流量收进来。只有业务请求经过统一网关，后续的成本、稳定性、安全和观测才有统一抓手。

常见坑和设计注意事项

不要只按请求次数限流

大模型请求的资源消耗与 Token 强相关。一个长上下文请求可能比几十个短请求更贵、更慢。限流体系必须支持 TPM，并且要区分输入 Token 和输出 Token。

不要把完整 Prompt 无保护地写入日志

Prompt 对排障很有用，但它可能包含敏感信息。日志系统要支持脱敏、访问控制、保留周期和审计。对高敏业务，可以只记录摘要、哈希或抽样内容。

不要默认所有模型都可以互相替换

模型之间存在能力差异。有的模型 JSON 输出稳定，有的模型推理能力强，有的模型便宜但容易幻觉。做容灾切换前，要为不同业务维护可替换模型列表，并通过评测验证。

不要让重试放大成本和故障

模型超时后重试会重新消耗输入 Token。对非幂等任务、长上下文任务和高价模型，要限制重试次数，并优先使用备用模型或快速失败策略。

流式响应要单独设计

流式响应不是普通响应的变体。网关需要处理首 Token 延迟、连接中断、客户端取消、输出 Token 统计、半截响应日志和异常归因。

成本大盘要能落到负责人

只展示公司总费用没有太大治理价值。成本必须能按项目、Key、模型、厂商、负责人拆分，并且在异常增长时推送给能处理的人。

从大模型网关演进到 AI 网关

大模型网关的边界还会继续扩展。企业的 AI 调用不会只停留在文本生成，后续会包含图像、语音、视频、Embedding、Rerank、Agent、工具调用和工作流编排。

几个方向会变得越来越重要：

• MCP（Model Context Protocol，模型上下文协议）适配，让模型更标准地访问工具和上下文。
• 多模态统一接入，让文本、图片、语音、视频模型走一致的鉴权、计费和观测体系。
• 工作流编排，把多个模型、工具、检索、规则系统组合成可治理的 AI 流程。
• 质量评测闭环，把模型输出效果、人工反馈、业务指标与调度策略连接起来。
• 智能路由，根据成本、延迟、上下文长度、任务类型、历史质量自动选择模型。

大模型网关不是传统 API 网关的简单替代品，而是在 AI 流量规模化之后产生的新治理层。它的核心价值是把分散的模型能力变成统一、可控、可观测、可优化的企业基础设施。