大模型推理网关：不要让业务服务直接碰模型供应商

一、网关的价值是把不稳定性收口

业务系统接入大模型时，第一版常常是某个服务直接调用模型 API。这样能快速验证功能，但一旦业务多起来，就会遇到模型切换困难、调用成本不可控、超时策略不统一、日志分散和安全策略重复实现等问题。大模型不是一个普通工具函数，它是高延迟、高成本、强不确定性的外部依赖。

推理网关的职责，是把这些不稳定性收口到统一层。业务服务只提交任务类型、上下文和约束，网关负责鉴权、路由、限流、脱敏、重试、降级、成本统计和审计。核心链路要稳，就不能让每个业务服务各自写一套模型调用逻辑。

二、架构链路：业务和模型之间要有治理层

flowchart TD
    A[业务服务] --> B[推理网关]
    B --> C[鉴权与租户策略]
    C --> D[Prompt 模板]
    D --> E[模型路由]
    E --> F[供应商 A]
    E --> G[供应商 B]
    B --> H[成本与审计日志]

模型路由不能只按模型名称转发。它应该结合任务类型、租户等级、延迟要求、成本预算和供应商健康状态做选择。比如客服摘要可以走便宜模型，合同分析走高质量模型，供应商异常时切换备选模型。路由策略要配置化，不能写死在业务代码里。

Prompt 模板也要放在网关或配置中心统一管理。业务方传入结构化字段，网关渲染模板。这样模板版本、灰度比例和安全约束都能被审计。让业务服务自由拼 Prompt，后面排查问题会很痛苦。

三、接口示例：请求必须结构化

下面是一个简化请求格式。它比直接传一段 prompt 更适合治理。

{
  "tenant_id": "t_1001",
  "task_type": "ticket_summary",
  "latency_level": "interactive",
  "input": {
    "ticket_id": "TK20260702001",
    "messages": ["用户反馈同步失败", "客服已确认账号正常"]
  },
  "constraints": {
    "max_tokens": 512,
    "need_audit": true
  }
}

结构化请求的好处是可控。网关可以根据 task_type 找模板，根据 latency_level 选择超时和模型，根据 tenant_id 扣减预算。后续做统计时，也能知道哪些业务在消耗 token，而不是只看到一堆文本。

返回值也要结构化，至少包含结果、模型版本、token 消耗、是否降级和请求 ID。业务服务拿到结果后，可以记录请求 ID，后续排障能回到网关日志。

四、稳定性设计：超时和降级必须前置

推理网关必须有明确超时。在线请求不能无限等模型返回。超时后可以返回简化模板、排队异步处理或提示稍后重试，取决于业务场景。没有降级策略的 AI 功能，迟早会把主链路拖慢。

限流也要按 token 和并发双维度设计。单次长上下文请求可能比几十个短请求更贵。网关应支持租户预算、接口预算、任务优先级和供应商额度保护。否则一次批量任务就可能吃掉当天预算。

最后要做供应商健康检查。模型接口错误率上升、延迟升高或限流频繁时，网关要自动降低流量或切换备选策略。AI 能力可以不稳定，但后端系统不能跟着裸奔。

还要保留影子调用能力。新模型上线前，可以只对少量请求复制一份影子流量，不把结果返回给用户，只记录质量、延迟和成本。等影子对比通过后，再进入正式灰度。模型迁移不能只看供应商宣传参数，要看自己业务里的真实表现。

五、总结

大模型推理网关的核心价值，是把模型调用的鉴权、路由、限流、成本、超时和审计统一治理。业务服务不应直接碰供应商 API。把不确定能力收口到确定边界内，才是后端架构应有的地基。