AI 推理网关：不要让业务服务直接追着模型跑

AI 应用早期经常把模型调用直接写进业务服务里：订单服务调一次模型，客服服务调一次模型，运营后台也调一次模型。短期很快，长期会散。模型切换、超时、重试、额度、审计和安全策略都散在各个服务里，最后谁也说不清一次生成到底发生了什么。

我更建议在业务服务和模型供应商之间放一层推理网关。它不需要一开始很重，但要把模型调用的通用问题收回来。基础设施的价值，就是让业务不用追着每个模型变化跑。

一、推理网关解决的是治理问题

推理网关不是简单的 HTTP 转发。它至少要处理鉴权、路由、超时、重试、限流、日志、模型版本和用量统计。业务服务只表达“我要完成什么任务”，网关负责选择合适模型并执行策略。

flowchart TD
  A[业务服务] --> B[推理网关]
  B --> C[鉴权与额度]
  B --> D[模型路由]
  B --> E[安全策略]
  B --> F[观测日志]
  D --> G[模型服务 A]
  D --> H[模型服务 B]

这样做的直接收益，是所有模型调用都有同一套入口。出了问题能查，成本能算，模型能灰度，策略能统一。

二、请求模型要结构化

业务服务不应该直接拼 Prompt 文本。它可以传任务类型、用户输入、上下文引用和输出格式。网关根据任务选择模板和模型。

type InferenceRequest struct {
    TenantID   string            `json:"tenant_id"`
    Task       string            `json:"task"`
    Input      string            `json:"input"`
    Variables  map[string]string `json:"variables"`
    ModelHint  string            `json:"model_hint,omitempty"`
    TraceID    string            `json:"trace_id"`
}

type InferenceResponse struct {
    Text       string `json:"text"`
    Model      string `json:"model"`
    TokensIn   int    `json:"tokens_in"`
    TokensOut  int    `json:"tokens_out"`
    LatencyMs  int64  `json:"latency_ms"`
}

结构化请求让网关可以做策略判断。比如同一个 summary 任务，低风险租户走便宜模型，高质量任务走强模型，超长输入先走压缩流程。

三、超时和重试要按任务分级

不是所有模型调用都值得重试。实时聊天超时后重试可能让用户等更久；离线摘要可以重试；支付或风控相关任务则要更谨慎。

inference_policy:
  chat_reply:
    timeout_ms: 12000
    retries: 0
  document_summary:
    timeout_ms: 60000
    retries: 2
  title_generation:
    timeout_ms: 15000
    retries: 1

这类配置应由网关统一管理。业务服务不要自己猜模型该等多久。策略统一后，容量规划和事故复盘才有基础。

四、观测要覆盖成本和质量

推理网关的日志不能只记状态码。要记录任务、模型、token、延迟、错误类型、重试次数和是否命中降级。对于 RAG 或 Agent 任务，还要记录检索耗时和工具调用次数。

如果成本异常上涨，网关能告诉你是哪类任务、哪个租户、哪个模型导致的。如果 TP99 抖动，网关能拆出排队、模型调用和下游超时。基础设施的意义，就是在坏事发生时让系统有证据。

五、总结

AI 推理网关的价值不是多一层服务，而是把模型调用治理收口。鉴权、路由、超时、重试、成本、日志和灰度都应在统一入口处理。

业务服务只关心任务，推理网关负责托底。这样模型再怎么变，应用架构也不会被拖着到处跑。