大模型推理网关的四个控制平面：流量、模型、成本与安全

企业在生产环境中接入大模型时，最容易低估的是“推理调用”本身的复杂度。早期系统通常从一个 OpenAI-compatible proxy 开始：统一 API Key、转发请求、记录日志、处理少量重试。这个形态可以支撑原型验证，却很难支撑多租户、多模型、多区域、多合规要求的长期运行。原因在于，大模型推理不是普通 HTTP API 调用。它有长连接、流式返回、输入输出 token 波动、上下文长度差异、供应商限流、模型能力差异、提示词泄漏风险、审计追溯要求，以及随业务量放大的成本不确定性。

因此，企业推理网关不应被设计为一个简单代理，而应被设计为一个位于应用与模型后端之间的 L2 LLM Gateway。它承接 L1 ingress 之后的模型特定治理能力，把“请求能否进来”与“请求应该由哪个模型、以什么预算、在什么安全策略下执行”分离。本文从工程实践角度，将企业推理网关拆解为四个控制平面：流量控制面、模型控制面、成本控制面与安全控制面。

1. L1 Ingress 与 L2 LLM Gateway 的边界

在企业架构中，API Gateway、Ingress Controller、Service Mesh 已经承担了大量通用流量治理工作，例如 TLS 终止、身份认证、WAF、IP 白名单、基础限流、负载均衡与可观测性。它们是 L1 ingress。L1 的职责是保护平台入口，确保调用者身份可信、网络路径可控、服务端不会被通用流量打垮。

但大模型推理需要另一层控制。一个请求通过了 L1 ingress，并不意味着它适合直接发送给某个模型供应商。网关还需要判断：这是在线交互还是离线批处理？用户是否处于免费额度、团队预算或企业合同范围内？请求是否包含敏感字段？是否需要使用 BYOK？当前云模型是否超时或降级？长上下文任务是否应该路由到自托管 vLLM/SGLang 集群？语义缓存是否可以直接命中？这些决策都不是通用 ingress 能稳定表达的。

合理的分层如下：

L2 LLM Gateway 的关键价值在于将推理调用从“点对点依赖”升级为“受策略治理的资源调度”。应用不再直接绑定某个模型名称、供应商 API 或 GPU 集群，而是声明任务意图、SLA、数据等级和质量要求。网关再根据当前策略、实时负载、成本预算和安全约束做出执行决策。

2. 流量控制面：把推理当作受 SLA 约束的队列系统

传统 Web API 的流量治理重点是 QPS、并发数和错误率。推理流量更复杂，因为一次调用消耗的资源与输入 token、输出 token、上下文长度、是否流式返回、是否启用工具调用和模型类型高度相关。两个 HTTP 请求看起来相同，实际 GPU 占用可能相差一个数量级。

流量控制面首先要建立推理负载的标准化指标。常见指标包括 request rate、input tokens per second、output tokens per second、time to first token、end-to-end latency、queue time、provider throttle rate、fallback rate、cache hit rate。对于在线交互，TTFT 通常比总耗时更敏感；对于离线总结或批处理，总吞吐和成本优先级更高。

生产级网关应至少支持三类队列：

• 交互队列：面向用户实时对话、Copilot、客服辅助，强调 TTFT 和尾延迟；
• 工作流队列：面向 Agent、多步任务、RAG 组合调用，需要稳定性和可追踪性；
• 批处理队列：面向文档处理、离线标注、批量摘要，可接受排队，强调吞吐与成本。

队列不是简单排队容器，而是 SLA 表达方式。网关可以根据租户等级、业务场景和请求优先级设置不同的并发上限、超时阈值、最大上下文长度和 fallback 策略。例如，客服实时辅助可以被限制最大输出长度以保护 TTFT；离线文档总结可以被迁移到低成本模型或夜间自托管集群；内部实验环境则可以被限制在较低优先级池中。

流量控制面还必须处理供应商限流。云模型常见限制包括 RPM、TPM、并发连接数和区域级额度。自托管集群则受 GPU 显存、KV cache、batching 策略和模型副本数量限制。网关需要将这些限制抽象为统一的 capacity model，并在请求进入后端前完成 admission control。否则，系统会在 provider 侧暴露大量 429、超时和不稳定重试，最终放大为雪崩。

3. 模型控制面：从静态模型名到策略化路由

模型控制面的目标不是“把 gpt-4o 换成另一个模型”，而是将模型选择变成可解释、可回放、可演进的策略决策。企业环境中的模型后端通常包括闭源云模型、开源自托管模型、专用 embedding/rerank 模型、代码模型、视觉模型和行业微调模型。不同后端在能力、成本、延迟、上下文长度、数据边界和可用性上都有差异。

一个成熟的模型路由策略通常包含以下维度：

路由策略不应硬编码在业务应用中。应用应传入结构化元数据，例如 tenant_id、workload_type、data_classification、latency_budget_ms、quality_tier、max_cost、streaming_required。网关根据这些信息匹配策略，并在审计日志中记录决策依据。

典型路由流程如下：

1. 解析请求元数据，识别租户、任务类型、数据等级和 SLA；
2. 执行安全策略，排除不允许的模型和区域；
3. 根据能力要求生成候选模型集合；
4. 根据实时健康、队列长度、限流状态和预算排序；
5. 选择主模型，并生成 fallback 链；
6. 记录 policy version、routing reason、candidate set 与最终选择。

Fallback 是模型控制面的核心能力之一，但它不能被简化为“失败就换模型”。大模型请求存在非幂等输出、流式半返回、上下文窗口差异、函数调用格式差异和安全策略差异。工程上应区分几类 fallback：

• 连接前 fallback：后端健康检查失败、额度耗尽、队列超限，尚未发送请求，可以安全切换；
• 首 token 前 fallback：已发送但未产生输出，超时后可切换，但需记录重复消耗风险；
• 流式中断 fallback：已经返回部分内容，通常只能向上层报告降级，不能无痕切换；
• 质量 fallback：模型返回格式不合规或置信度不足，可触发二次修复或升级模型。

这要求网关维护模型能力注册表，而不仅是 endpoint 列表。能力注册表应描述上下文长度、支持的输入模态、工具调用格式、JSON mode、流式能力、区域、数据保留策略、价格、最大并发、健康状态和兼容 API。没有能力注册表，路由只能依赖静态配置，难以稳定扩展。

4. 成本控制面：从账单归因到预算执行

推理成本的难点不在于“知道模型单价”，而在于成本发生在请求路径上，且高度动态。一次长上下文请求可能消耗大量输入 token；一次 Agent 工作流可能连续调用多个模型；一次失败重试可能产生双倍费用；语义缓存命中则可能让成本接近零。企业如果只在月末查看供应商账单，就已经失去了治理窗口。

成本控制面需要在请求执行前、执行中和执行后分别工作。

执行前，网关应根据模型价格、输入 token 估算、最大输出 token、候选模型和缓存命中概率计算成本上限，并检查租户预算、项目预算和用户额度。对于超出预算的请求，可以拒绝、降级、要求人工确认，或切换到低成本模型。

执行中，网关应监控输出 token、流式持续时间和 provider 错误。当输出过长、模型偏离任务或达到预算阈值时，可以截断、停止生成或要求上层重新确认。对于长上下文和批处理，执行中预算控制尤其重要。

执行后，网关要将实际 token、模型、供应商、缓存状态、重试次数、fallback 链、延迟和成本写入用量账本。账本粒度应至少覆盖 tenant、project、user、application、workload_type 和 model。只有具备这样的归因能力，平台团队才能回答“哪个功能导致本周成本上升”“哪个租户触发了高价模型”“fallback 是否造成重复计费”等问题。

语义缓存是成本控制面中最容易被误用的能力。它不是普通 HTTP cache，不能只按 prompt 字符串命中。企业场景中，缓存键通常要考虑系统提示词版本、用户问题、检索语料版本、模型族、输出格式、权限范围和数据等级。相似度命中还需要阈值、任务类型白名单和安全过滤。适合缓存的请求包括公共知识问答、重复文档摘要、模板化解释和稳定分类；不适合缓存的请求包括包含个人信息的回答、强时效内容、权限敏感检索和需要严格可追溯的新生成内容。

自托管 vLLM/SGLang 与云模型的混合部署，是成本控制面的另一个重要策略。云模型适合弹性、快速接入和高能力任务；自托管适合高频、稳定、可预测、数据边界明确的工作负载。vLLM 通常以高吞吐、PagedAttention、OpenAI-compatible serving 和成熟生态见长；SGLang 更强调结构化生成、复杂推理工作流、RadixAttention、前缀复用和 agentic workloads 的执行效率。企业不必把两者视为二选一，而应让网关按任务画像选择后端。

例如，客服 FAQ、内部知识库问答、批量摘要可以优先进入自托管池；高风险推理、复杂代码生成、跨模态任务和峰值溢出则进入云模型。混合策略的前提是成本模型真实反映 GPU 折旧、利用率、运维人力、模型升级、空闲容量和峰值冗余。自托管只有在利用率足够稳定、负载可预测、团队具备运维能力时才会体现优势。

5. 安全控制面：把模型调用纳入企业安全边界

推理网关的安全控制面需要覆盖身份、数据、密钥、输出和审计。它不是在 prompt 前加一句“不要泄漏信息”，而是在请求生命周期中建立可执行的安全策略。

首先是身份与租户隔离。每个请求应携带经过 L1 验证的主体身份，并在 L2 转换为推理上下文中的租户、项目、用户和应用标识。网关不应接受应用随意伪造的 tenant_id，而应从可信 token、mTLS、服务身份或内部签名中派生。配额、预算、安全策略和审计都应绑定这个身份。

其次是数据分类。请求进入模型前，网关可以根据来源系统、字段标签、DLP 检测或应用声明识别数据等级。不同等级对应不同后端边界：公开数据可以使用普通云模型；内部数据可以使用签署企业协议的云模型；机密数据可能只能使用私有区域、BYOK 云服务或自托管模型；受监管数据还需要额外审计和保留策略。

BYOK 是企业推理网关常见需求，但其含义需要澄清。BYOK 不只是“供应商支持客户密钥加密静态数据”，还涉及密钥生命周期、区域限制、访问审计、撤销语义和供应商日志保留。网关应在路由时知道哪些模型后端满足 BYOK 或私钥托管要求，并将密钥策略纳入模型候选过滤。对于高敏感请求，网关还应禁止发送到不满足数据保留或训练豁免要求的供应商。

第三是提示词和输出安全。企业网关应支持敏感字段脱敏、PII 检测、secret scanning、提示词注入风险标记、工具调用参数过滤和输出合规检查。但这些检查要与业务场景结合，避免把网关变成不可维护的正则集合。更可行的做法是将安全策略分层：基础层处理密钥、身份证号、访问令牌等明确风险；业务层处理行业规则；高风险任务则引入人工审批或专用安全模型。

第四是审计与可回放。每个推理请求至少应记录 request_id、tenant、application、policy_version、model_selected、fallback_chain、token usage、cost、latency、cache status、safety flags 和错误原因。对于敏感场景，可以保存脱敏后的 prompt 摘要、输出摘要、检索文档 ID 和工具调用轨迹。审计日志要支持回答三个问题：为什么选择这个模型？这次调用花了多少钱？是否违反了数据或安全策略？

安全控制面还要处理跨供应商密钥管理。应用不应直接持有 provider API key。密钥应由网关托管，按后端、租户、区域和策略动态选择。这样可以避免 key 在多个业务系统中扩散，也便于统一轮换、吊销和最小权限控制。

6. 策略执行架构：Policy Decision 与 Policy Enforcement 分离

为了让四个控制平面可维护，网关内部应区分策略决策点（PDP）与策略执行点（PEP）。PEP 位于请求路径上，负责解析请求、调用 PDP、执行限流、路由、缓存、转发、记录日志。PDP 负责根据策略仓库、模型注册表、预算账本、实时指标和安全规则做出决策。

这类架构的优点是策略可以版本化、测试和回滚。企业可以在影子模式下评估新路由规则：真实请求仍按旧策略执行，但网关同时计算新策略会选择什么模型、预计成本和风险差异。经过一段时间观察后，再逐步切流。对于模型升级、供应商切换、价格变化和安全事件，这种能力非常关键。

策略语言不一定需要一开始就复杂。早期可以使用结构化 YAML 或数据库配置表达租户、任务类型和模型候选；中期再引入规则引擎或策略即代码。关键是避免策略散落在各业务应用中，否则平台团队无法统一治理，也无法在供应商故障或合规变化时快速响应。

7. 生产落地建议

第一阶段，企业可以先建立统一接入层：规范 OpenAI-compatible API、统一认证、集中密钥、基础日志、模型注册表和供应商健康检查。这个阶段的目标不是复杂路由，而是消除应用直连 provider 的状态。

第二阶段，引入模型路由和预算账本。应用开始传递 workload_type、quality_tier、data_classification 等元数据。网关记录 token 与成本，并支持按租户、项目和应用聚合。此时就可以做简单策略：低风险任务走低成本模型，高风险任务走强模型，超预算任务降级或拒绝。

第三阶段，建设 SLA 队列、语义缓存和 fallback。实时任务、Agent 工作流和批处理任务使用不同队列；缓存只在可控任务类型中启用；fallback 规则区分连接前、首 token 前和流式中断。此阶段需要完善可观测性，尤其是 TTFT、queue time、provider 429 和 fallback 成本。

第四阶段，接入自托管 vLLM/SGLang。不要为了“自托管”而自托管，应先从高频稳定任务开始。网关要能同时理解云模型价格和 GPU 池容量，把自托管后端作为路由候选而不是独立系统。对于 vLLM/SGLang，建议以 workload benchmark 驱动选择：长上下文、前缀复用、结构化输出、并发模式、KV cache 命中率和运维复杂度都应纳入评估。

第五阶段，完善安全审计与合规治理。引入数据分类、BYOK 策略、密钥托管、敏感字段脱敏、审计查询和策略版本回放。对于受监管行业，应明确日志保留周期、脱敏规则、访问权限和事件响应流程。

8. 常见反模式

一个常见反模式是把推理网关做成“更大的 proxy”。它提供统一 endpoint，但模型选择仍写在业务代码里，成本只依赖月底账单，安全只依赖供应商承诺。这种架构表面统一，实际上没有治理能力。

第二个反模式是过早引入复杂智能路由。没有稳定指标、成本账本和模型注册表时，所谓智能路由往往不可解释，也无法排查。企业应先建立确定性策略，再逐步引入基于实时指标的动态优化。

第三个反模式是把 fallback 当作可靠性万能药。不同模型之间能力、格式、上下文长度和安全边界不同。盲目 fallback 可能导致输出不一致、重复计费、审计困难，甚至把敏感数据发送到不合规后端。

第四个反模式是将自托管视为必然省钱。GPU 集群只有在利用率、批处理、模型稳定性和团队运维能力都满足条件时才可能降低单位成本。否则，自托管会把供应商账单转换为硬件折旧、容量冗余和运维复杂度。

9. 结语

企业推理网关的核心不是协议转换，而是控制面建设。L1 ingress 解决通用入口治理，L2 LLM Gateway 解决模型特定治理。流量控制面保障 SLA，模型控制面决定能力与可用性，成本控制面约束预算与资源效率，安全控制面确保数据、密钥和审计边界。

当大模型从单点应用进入企业平台层，推理请求就不再是一次简单 API 调用，而是一项需要策略、账本、审计和调度共同参与的基础设施操作。一个成熟的推理网关，应让应用声明意图，让平台执行策略，让每一次模型调用都能被解释、被计量、被追踪，并在故障、预算和合规压力下保持可控。