业界模型网关演进调研报告

调研目的：梳理业界模型网关（AI Gateway / LLM Gateway / Model Gateway）的演进脉络，覆盖国内外头部云厂商与主流开源项目，明确其细分类型、能力边界与核心功能，为企业内部建设模型网关提供借鉴。 初次调研时间：2026-08-14 ｜ 版本：v5.5（再审议最终定稿，第 3 轮终审通过、终稿差异经 Codex 最终复核） ｜ 更新日期：2026-10-17 本文正文（〇–八章）与附录仅陈述终态结论；版本演变与历次审查的过程记录统一收录于第十一章。外部产品与协议事实的核验时点以 9.1 各条标注为准，本版复核截至 2026-10-17。

〇、术语与范围界定（工作定义） #

本报告所称"模型网关"（AI Gateway / LLM Gateway）采用如下工作定义：位于应用/客户端与多个模型提供方之间的统一中间层——提供方既可以是外部模型 API 供应商，也可以是企业内部的模型服务与算力池（与〇.1 的形态 A/B 对齐），以策略、可观测、成本治理为一等公民，将散落在业务代码、零散配置、人工流程中的 AI 调用治理能力收敛到标准化入口。

以下属相关生态，不在本报告"模型网关"范围内（列出是为避免概念滑移，不含贬义）：

• 模型训练/微调与 Agent 业务编排逻辑（属上层编排框架，如 LangChain/LlamaIndex）；
• 纯客户端 SDK 抽象（无代理跳转，如 OpenAI SDK / Vercel AI SDK）；
• 单纯聚合计费平台（如 OpenRouter 的纯计费功能）；
• 云厂商模型推理平台本体（如 Bedrock 的模型托管本身，仅其网关治理层属本报告范围）。

上述形态与本报告"模型网关"存在交集但不等同；网关与路由器、网关与编排层的边界仍在演进（见 4.2），本报告的"必建"建议仅针对上述精确定义。

〇.1 两类部署形态的区分 #

企业实践中存在两类部署形态，二者的能力重心差异显著，混用会导致选型与设计错配。阅读本报告时须先确定自身属于哪一类；两者是分析轴而非互斥分类，企业同时使用自有算力池与外部 API 时，应按下游分别适用对应一列：

适用性声明：第一至七章的演进脉络、分类体系与能力清单对两类形态共同适用；第八章 8.1–8.4 的建议以形态 A 为默认语境，其在形态 B 下的完整适用性修订见 8.5.1（覆盖契约、成本、故障转移、缓存、合规、限流准入与韧性七项）；5.9 的计量/定价/额度三层模型对两类形态均适用，但定价层的单位须重新选择并明确口径——可以是货币成本、原始 token 或运营积分；私有化并不禁止货币计价，只是外部单价不再自动等于内部成本（可选方案见 8.5.4，等效算力单位为可选项而非唯一答案）。

一、摘要 #

执行摘要（一页纸） #

五条结论（详版七条见下；简版按主题重组，不与详版逐条对应：① 对应详版总述与第 3 条，② 对应第 5 条，③ 对应第 3、5 条，④ 对应第 6 条，⑤ 对应第 7 条；详版第 1、2、4 条的协议、边界与开源格局不在简版单列）：① 模型网关已从"直连"演进为"AI 原生网关 + MCP/Agent 治理"的独立基础设施层；② 建设应以"统一契约入口 + 确定性路由 + 计量采集"为一期底座，content-aware 智能路由与 MCP 工具治理按需二期接入；③ 安全是前提——语义缓存需租户隔离、网关自身是集中化高价值目标、MCP 存在设计级风险；④ 计量·定价·额度是三层而非一件事，业界已有成熟范式与开源实现可直接借鉴，难点在并发一致性而非计费算式（见 5.9）；⑤ 私有化多算力池场景（形态 B）与多供应商 API 场景（形态 A）的能力重心显著不同——稀缺的主要是物理算力而非预算，路由在选模型/选池之外新增"选副本"一层（非替代），共享池接近容量时须启用准入与优先级队列（见〇.1、8.5–8.7）。

四项必做：统一契约入口（一期以 OpenAI 兼容为过渡基线并预留中立契约抽象，终态为多协议双向适配，见 8.2 决策点 2；不焊死单一厂商形状）；计量采集 + 预算/配额前置；网关自身韧性（高可用/密钥外部化/降级预案）；额度扣减的原子性与预扣—结算机制（否则预算只是纸面数字）。

四项风险：语义缓存跨租户泄露；集中化单点放大；OpenAI 契约漂移；MCP 工具滥用。

报告状态与证据边界

本报告定位为行业调研与受控 POC 的研究输入（本版为再审议最终定稿：第 3 轮终审已按原有通过门槛判为通过，此后仅收口其少数意见并经终稿差异复核，结论不变）。产品能力与许可信息受所列版本与核验时点限制；文中工程机制为设计建议与实施条件，非已验证的实现方案。截至本次修订，未取得 8.8 中 T01–T16 的任何执行证据，因此额度一致性、调度公平性、缓存收益与计价回算四类结论目前没有运行验证支撑。实施须在版本、责任角色、阈值与故障语义确定后推进；生产上线以相应验证证据为准，不得以本报告作为能力已验证的证明。

（以下为详版结论）

模型网关已经历了从"应用代码直连单一模型 API"到"统一代理层"再到"AI 原生网关 + MCP/Agent 治理层"的三阶段演进。2025 年起，部分主流云厂商与网关厂商的产品从单一的模型代理，扩展为同时治理 模型（LLM）、工具（MCP）、智能体（Agent） 的 AI 应用入口（具体产品与能力状态见 6.1、6.3，各产品进度不一）。

关键结论：

1. 协议归一化是地基，但地基在漂移（详见 2.2、5.1、8.2 决策点 2）：OpenAI 的 Chat Completions 是当前最广泛实现的交互形状（2023.03 GPT-3.5-turbo 起，几乎被所有厂商和开源网关作为统一出口），但它是 de facto（事实）而非 de jure（法理）标准——无标准组织、无 RFC；且 OpenAI 已于 2025.03 发布 Responses API 作为面向 Agent 场景的新一代交互形状，并将新能力优先落地于此。Chat Completions 未设弃用时间表，当前官方迁移指南的表述为“仍受支持，新项目推荐使用 Responses”；但能力已开始分化——官方指南写明自 GPT-5.4 起，Chat Completions 在 reasoning_effort 取 none 以外的值时不支持工具调用。Assistants API 已于 2026-08-26 正式下线。统一出口仍应建立在"中立契约抽象层"之上，而非焊死在单一厂商形状上。
2. 能力边界在收窄并分层（详见 3.2、4.4）：AI 网关（管"如何安全合规地调"）与模型路由器（管"调哪个模型最好"）正在解耦；网关与上层编排（Agent 框架）的治理边界仍需企业内部自行厘清。
3. 新一代方向是 MCP/Agent 网关（详见 7.1、7.2、7.5）：2025 年起，MCP 网关逐渐成为独立品类（AWS Bedrock AgentCore Gateway、Kong、agentgateway、LiteLLM 等）。企业级"网关 + 注册表"已有公开案例（如 Uber 于 2026-10-01 披露其 MCP Gateway 采用 Registry 控制面 + Proxy Gateway 数据面），但这是趋势性判断，不是已确立的标准。MCP 的安全风险须以分层防护为前提：OX Security 将 STDIO 配置信任边界定性为设计级风险；据 OX 转述，Anthropic 认为该执行模型属预期行为、不认同这一定性（见 7.4）。管理面也已出现 MCP 入口，风险随之扩大（见 7.5）。
4. 开源项目百花齐放（详见 6.3、6.4）：LiteLLM（提供商覆盖面广，且已具语义缓存与 MCP 网关）、Portkey（预算/RBAC/审计等治理功能较完整，开源 core 与企业版的能力划分按拟用版本核对，见 8.3）、Higress（阿里开源，CNCF Sandbox）、One API / New API（国内社区使用较多）、Kong/APISIX（传统网关 AI 化）、Agent Router（原 Envoy AI Gateway，2026-09 更名并成为 AAIF 独立项目）各有定位；计费/额度平面另有独立品类（OpenMeter——Kong 于 2025-09 宣布收购、Lago），不必由网关自研，但实时硬限额能力须按版本另行验证（见 6.4）。
5. 对企业自建的核心借鉴（详见第 8 章）：以"统一契约入口 + 多模型路由 + 虚拟密钥/成本治理 + 可观测 + 安全护栏 + 网关自身韧性"为必建底座；二期补齐语义缓存（含租户隔离）、MCP 注册表与工具级授权；三期再做完整 Agent 生命周期治理。
6. 计量·定价·额度是三层而非一件事（详见 5.9、6.4、8.2 决策点 9）：业界已收敛出三条实现路线——网关内置"倍率+余额"（One API/New API 系；New API 当前版本另提供带周期重置的订阅套餐）、网关内置"成本预算+周期重置"（LiteLLM/Portkey/Bifrost）、网关只执行限额而额度外置（Higress/Kong/Agent Router + OpenMeter/Lago）。真正的工程难点不在计费算式，而在并发一致性：预扣—结算、原子扣减与幂等是必需品，业界已有 TOCTOU 透支与预算误杀的公开缺陷记录可鉴。
7. 私有化多算力池场景需另立一套打法（详见〇.1、8.5–8.7）：下游是自有推理集群时，已有容量在短期是既定投入（电力等可变成本仍然存在，租赁、维护、折旧与扩容属长期成本），因此额度的作用从省钱转为分配稀缺算力与引导用量结构，计价口径须另行定义；路由在"选模型/选池"之外新增一层"选副本"（按 KV/前缀缓存亲和与队列压力；GIE InferencePool+EPP、llm-d、Dynamo 是该层可评估的规范与实现，非既成互换标准，且 GIE 自带 EPP 仅为一致性测试参考实现）；在共享算力池且负载接近容量时，准入与优先级队列（GIE Flow Control、llm-d 准入/调度分离）是必要能力；治理网关与推理网关应做逻辑职责分层，并以锁定版本的治理上下文契约解耦（契约覆盖请求头与请求体扩展字段，由可信层统一重建）；配额计价单位须重新定义（等效算力单位为可选方案之一，须定期标定，且不能替代瞬时容量准入）。配额运营上，策略定义在 Portal、策略执行在网关；治理控制面 Portal 不进入逐请求同步路径，专用的额度/鉴权/策略服务可按需同步依赖，但须独立设计其 SLA 与降级语义。

二、模型网关的定义与演进历程 #

2.1 什么是模型网关 #

模型网关是位于应用/客户端与多个模型提供方之间（外部模型 API 供应商或企业内部模型服务与算力池，见〇章工作定义）的统一中间层（智能反向代理），将散落在业务代码、零散配置、人工流程中的 AI 调用治理能力收敛到一个标准化入口。它解决的典型问题包括：多供应商协议差异大、API Key 分散难管理、调用成本不可控、权限边界模糊、日志审计缺失、单点故障引发业务雪崩等。

2.2 演进时间线 #

注：下表"意义"栏为报告基于公开信息的归纳判断（非厂商官方定性），带引号的表述为厂商营销话术，仅作语境引用。

2.3 演进三阶段 #

说明：三阶段是本报告的解释框架，用于归纳演进方向，不代表行业统一历程；各阶段所列能力缺口指当时的常见情形，不对每个产品逐一断言。

第一阶段（2023 为主）— 直接集成：应用代码直接集成 OpenAI SDK，API Key 硬编码或简单环境变量管理。单模型、单提供商、零治理。注：2023 下半年 LiteLLM、Portkey 已出现统一代理雏形（第二阶段萌芽），但当年主流实践仍是直接集成，两阶段在 2023 年存在重叠。

第二阶段（2024）— 统一代理：LiteLLM、One API 等提供 OpenAI 兼容的统一代理层，屏蔽多提供商差异，解决"多模型接入"。常见短板是治理能力弱（如 YAML 配置难大规模管理、管理界面与组织级策略不完善），具体产品差异较大。

第三阶段（2025-2026）— AI 原生网关成熟：Kong AI Gateway、Bifrost、Portkey、Higress 等将 API 网关的成熟治理体系与 AI 特定能力（Token 感知、语义缓存、Prompt 安全、模型路由、MCP 托管）深度融合，形成独立的基础设施层。

三、细分类型（分类体系） #

业界对模型网关存在多套分类视角，综合如下：

3.1 网关及相关生态：按部署形态与出身划分 #

口径说明：3.1–3.3 是可以交叉的分类维度，不是互斥类别，更不构成成熟度排名。同一产品可同时落入多个格子（例如既是自托管开源网关，也提供托管 SaaS）；3.3 的分组沿用社区习惯说法，仅表示常见归类，不代表优劣次序或成熟度。

3.2 按功能角色划分（网关 / 路由器 / 聚合器） #

• 聚合器（Aggregator）：一套 API + 统一计费接入海量模型，如 OpenRouter、Eden AI。
• 代理网关（Proxy Gateway）：OpenAI 兼容代理 + 治理，如 LiteLLM、Portkey、Cloudflare AI Gateway。
• 智能路由器（Smart Router）：按质量/成本/延迟自动选择模型，如 Martian、Not Diamond、Unify。
• API 网关（API Gateway）：传统网关 AI 化，如 Kong、APISIX；基于 Envoy 的 Agent Router（原 Envoy AI Gateway，2026-09 更名并成为 AAIF 独立项目，见 6.3）同属基础设施网关一类。

关键认知：网关与路由器解耦是成熟企业的常见组合——底层用基础设施网关统一策略与可观测，上层叠智能路由层做按质量/成本/延迟的模型选择。网关管"如何安全合规地调"，路由器管"调哪个模型最好"。

3.3 国内社区常见的分组 #

• 第一组（纯网关，OpenAI 兼容）：One API、New API、Portkey、LiteLLM。
• 第二组（应用开发平台，相关生态，不属本报告网关范围）：Dify、FastGPT、LobeChat 等，常被社区与网关并列讨论，但属〇章排除的编排/应用层。
• 第三组（商业产品中的网关治理层）：Cloudflare AI Gateway、Apigee（Google）、Azure API Management AI Gateway tier、AWS Bedrock AgentCore Gateway。

四、能力边界 #

4.1 AI 网关 vs 传统 API 网关 #

传统 API 网关管理的是"固定端点 + 预定义请求模式"的 Web 流量；AI 网关面向模型与智能体服务，额外提供：语义缓存、Token 级成本归因、Prompt 生命周期管理、护栏（guardrails）、多供应商故障转移。核心差异还体现在：

• 计量单位从"请求次数"转为"Token"：成本与资源消耗取决于输入/输出 Token 数，而非请求数。
• 数据流从"请求-响应"转为"流式（SSE）"：需实时转发增量响应，对并发与传输效率要求更高。
• 性能与稳定性：推理计算密集、响应时间长，需智能流量控制与异常检测。
• 安全合规增强：细粒度访问控制、数据加密、敏感信息过滤、多认证与审计机制。

4.2 网关 vs 编排层（争议边界） #

行业报道在讨论 Azure AI Gateway tier 时提出过一个开放问题（据 InfoQ 2026-08 报道，此处的归纳属作者判断）："治理 AI 流量"与"治理完整生命周期"是两回事。当一个 Agent 运行未干净收尾时，其产出是否保留以供审计、是否由网关兜底重试，这涉及"Agent 输出所能改变之物的授权边界"应放在网关还是上层编排层——业界尚无定论。一个可操作的初步划分：以流量治理（鉴权/限流/计量/审计）为主 → 网关；以 Agent 生命周期（状态/重试/编排/收尾）为主 → 编排层；重叠区按"谁先触发、谁兜底"划分，企业内部据此明确而非笼统"自行厘清"。

4.3 网关候选能力清单 #

本表是候选能力全集，不是"公认应有"的共识清单；哪些属一期基线、哪些按需建设，以 8.1 的分期为准，具体产品能力随版本而定。

4.4 动态路由与计量的层位归属（路由 / 计量 / 网关的边界） #

结论（存在两种范式，非统一共识）：业界对"路由与计量应否内聚网关"存在两派——内聚派（LiteLLM、Portkey、Bifrost 等网关厂商，路由 + 计量皆做在网关内）与外置派（Not Diamond、Martian 等路由厂商，主张智能路由独立于网关、架在网关前）。两派立场与其商业定位相关，企业应结合自身取舍，而非视为"已收敛的统一范式"。

判断准则——区分「决策 vs 记录」、区分「确定性决策 vs 学习型决策」：

为什么计量采集通常在网关：网关是请求必经的 choke point，是采集 token 用量与归属（谁）最自然的点位；业界主流（New API 三层倍率 配额消耗 = (输入 token + 输出 token × 补全倍率) × 模型倍率 × 分组倍率、LiteLLM 的 input/output_cost_per_token + max_budget + virtual key/team）确在网关内实现。但这不等于计量只能内聚——"网关采集 + 独立计费数据湖结算"（chargeback 系统、BI、Stripe Billing）是同样合法且常见的范式，尤其适用于复杂对账/多级结算。关键是区分「采集（ingest）」与「结算（settle）」两层。

为什么路由分两档：

• 确定性路由（按组织/用户/标签、繁忙度、规则式复杂度、fallback）多在网关内实现：按组织/用户/标签 → virtual key/team 的 model allowlist；按繁忙度 → LiteLLM usage-based-routing-v2（路由到 least-utilized 副本）；按任务复杂度（规则式）→ LiteLLM auto_router/complexity_router（SIMPLE/MEDIUM/COMPLEX/REASONING 分档；官方博客称 v1.94.x 起的 Auto Router v2 把复杂度、语义与自适应路由合并到同一入口，并可选 LLM 分类器——启用后即属学习型决策，应按下一档评估）。其优势在于治理上下文与路由决策同处一条请求路径（延迟低、一致性强），但这并非逻辑必然——若治理上下文由外部 IAM/策略系统（如 OPA、自建权限中心）提供，确定性路由同样可外置；内聚是工程权衡而非定义使然。
• content-aware 智能路由（Not Diamond、Martian、RouteLLM）外置为独立决策层：这是 ML + 数据问题（模型格局每月变化、需持续重训、有 per-request 决策开销需专门评估），与网关的治理/可观测职责不同质。注意：Not Diamond 主张"路由应独立、架在网关前"是其作为路由厂商的自我定位，含商业立场，采信时需独立评估。

对企业自建的借鉴（详见第 8 章）：一期网关内聚「计量采集 + 确定性路由 + 虚拟密钥」、计费结算可按需外置；content-aware 智能路由按需二期外置接入。取舍原则：计量采集留网关、结算可外置；学习型路由不焊进网关。

本节为层位归属的判断框架，其工程实现形态（倍率如何定义、套餐与重置如何落地、采集与结算如何切分）见 5.9；该节亦提供了"采集在网关、结算在独立计费平面"这一范式的具体开源证据（含 Kong 于 2025-09 宣布收购开源计量计费平台 OpenMeter，见 6.4；该事实只证明产品组合关系，不证明二者的集成架构）。

4.5 安全威胁模型（收敛） #

网关建设的安全风险在正文各处有散点论述，此处收敛为一张威胁清单，便于系统性评估：

已知反面教训：LiteLLM 2026.03 PyPI 供应链攻击；OX Security 2026.04 对 MCP STDIO 配置信任边界的风险披露（定性存在分歧，见 7.4）；LiteLLM 2026-09-30、2026-10-01 两项管理面安全公告（低权限用户提权至代理管理员、凭证字段别名导致本地文件读取，见 7.5）。这些都是集中化网关/协议生态的典型风险事件，选型与建设时须纳入上述威胁模型。

五、核心功能详解 #

本章 5.1–5.8 为核心功能逐项说明，5.9 为计量·定价·额度治理专题；私有化场景的能力差异见 8.5–8.8。

5.1 统一接入与协议归一化 #

以 OpenAI Chat Completions 为当前主流交互形状（非稳定法理标准，见摘要结论 1），将 Anthropic（messages 接口）、Gemini（generateContent）、各国内厂商的差异在网关内部转换。典型差异点：system 消息位置、工具调用（tool_use vs tool_calls）、多模态（parts.inline_data）、流式事件增量结构。需正视能力取舍：Anthropic 扩展思考、Gemini 原生多模态、o 系列推理 token 等无法映射进 OpenAI 形状的能力，应提供"原生协议透传 + 强制治理"——保留原生负载形状，但仍经过强制鉴权、限额与审计；网关无法解析的字段须显式限制或拒绝，而非默认放行。

5.2 智能路由与高可用 #

按模型名直达、按成本/延迟/质量动态选路、供应商故障自动降级与重试、负载均衡。跨供应商故障转移不是纯可用性动作：切换前须重新校验目标模型对该主体的授权、数据驻留与敏感数据外发条件，不满足时按契约拒绝或降级，不得为保可用而越过数据边界。

5.3 虚拟密钥与访问控制 #

中心化管理供应商密钥，向不同团队/应用分发独立虚拟密钥，实现精准策略控制，缩小供应商主密钥泄露爆炸半径。注意其边界：虚拟密钥本身泄露仍授予攻击者以该租户配额/策略下的模型访问，其安全性依赖网关自身的认证授权与密钥存储；须配套短期凭证、调用方身份绑定与异常调用检测，而非把虚拟密钥当作认证终点。

5.4 Token 级成本治理 #

每请求记录 Token 用量，按团队/应用/用例打标签，支持内部结算（chargeback）与超支告警。

5.5 缓存（三类须分别设计） #

须区分三类缓存：① 精确响应缓存（哈希匹配，复用完整答案）；② 语义响应缓存（向量相似度匹配，复用"相近问题"的答案）；③ 前缀 KV 缓存（推理引擎层复用 prefill 中间状态，如 vLLM APC）。三者的正确性条件、隔离要求、失效规则与收益计算完全不同，不可合并设计或合并计算收益：响应缓存的键除租户外还须绑定授权域、模型与版本、提示模板版本、检索知识/工具数据版本、影响输出的生成参数，否则会出现同租户内跨权限命中与陈旧知识命中；前缀 KV 缓存不直接复用历史答案，但不能据此推出其安全：仍须按信任域设计缓存隔离、缓存身份组成与哈希安全，并评估时序侧信道——vLLM 官方为此提供 cache_salt（使缓存共享限定在显式约定同一 salt 的信任组内，并"防止攻击者通过观察延迟差异推断缓存内容"的时序攻击），同时提示使用非密码学安全哈希会增加碰撞风险、在多租户环境下"甚至可能泄露隐私信息"。若采用盐隔离，信任域映射必须由可信网关/调度层决定，不得允许调用方通过伪造共享标识加入他人缓存域（见 8.8 T09）。其收益仅作用于 prefill。以下讨论的是①②（网关层）：精确哈希匹配 + 向量相似度匹配（LiteLLM、Bifrost 等均提供语义缓存，见 6.3），命中时可省去一次完整的上游调用，收益取决于实际命中率——个性化流量高的场景命中率可能很低；本报告不引用未经同条件实测的加速倍数或默认阈值。安全约束（必备前置）：缓存键必须包含租户/用户标识并按租户物理分区，默认不跨租户共享；建立缓存准入策略（不缓存含 PII/凭据/个性化字段的响应）；设定 freshness 窗口与失效触发并监控误命中率——否则"语义相似即复用答案"构成跨租户泄露通道（该通道的存在属机制推论，本报告不引用任何未溯源的量化比例）与缓存投毒风险（学术界已给出量化证据：CacheAttack 黑盒碰撞攻击在 LLM 响应劫持上达到 86% 命中率，见 9.1 #39）。可参照的开源实现：LiteLLM 的语义缓存原生提供 semantic_cache_scope 隔离维度（默认 key，可选 end_user），即"缓存键含租户标识"在主流网关中已是可直接复用的能力，而非只能自研（见 5.9）。

5.6 安全护栏 #

PII/DLP 脱敏、Prompt 注入检测、内容分类与审核、schema 校验。策略应优先在模型推理回路之外强制执行（AWS 用 Cedar、开源用 OPA/WASM），使约束成为硬限制而非提示词建议；但需区分"硬约束（策略引擎强制）"与"软提示（heuristic 插件，如内容审核/提示词装饰）"两级——开源网关的硬约束需额外工程投入，并非开箱即用。

5.7 全链路可观测 #

聚合所有供应商的日志、Token 计量、延迟、错误率，支持审计留痕与合规。

5.8 MCP/工具治理（新） #

MCP 服务器托管、OpenAPI→MCP 自动转换、按工具粒度的授权与审计、凭证代管（网关持有上游凭证，模型/用户不直接接触明文）。

5.9 计量、定价与额度治理：Token 套餐 / 模型倍率 / 重置规则 #

本节是 4.4「计量的层位归属」判断框架的实现层下沉。核心结论：这三件事在业界不是一个功能，而是三层，各家差异主要在于"三层分别放在哪"。

5.9.1 概念模型：先把三层拆开 #

flowchart LR
    subgraph GW["网关（请求必经点）"]
        M["计量 Metering<br/>input/output/cache token<br/>+ 归属(who)"]
        E["执行 Enforcement<br/>准入检查 / 拒绝<br/>预扣 + 结算"]
    end
    subgraph PR["定价 Pricing"]
        P1["倍率制<br/>模型×补全×分组"]
        P2["价目表制<br/>per-token 单价"]
    end
    subgraph EN["额度 Entitlement"]
        Q1["预付余额/钱包"]
        Q2["周期预算+重置"]
        Q3["Grant+优先级+结转"]
    end
    M --> PR --> EN --> E

关键认知：治理入口负责主体级策略执行（身份、权限、额度准入），计量可由网关与推理引擎协同采集，容量准入由 L2/推理层负责；但定价与额度既可内聚网关、也可外置——这正是下述三条路线的分岔点，也印证了 4.4「采集（ingest）与结算（settle）应分层」的判断。

5.9.2 三条主流实现路线 #

路线 A：网关内置"倍率 + 余额"（国内社区常见做法）

代表实现 One API（Go/MIT，维护状态待核）→ New API（Go，AGPL-3.0），三层倍率齐备，有较多二次开发 fork 沿用（须区分"独立实现同类设计"与"复用其代码、文档等受保护内容"两种情形；后者按目标版本与实际使用、部署、分发方式逐案审查，本报告不提供许可结论）：

官方计费公式：配额消耗 = (输入Token + 输出Token × 补全倍率) × 模型倍率 × 分组倍率；固定价格模型为 模型固定价格 × 分组倍率 × 配额单位(500,000)。额度单位为内部"配额点"，锚定 1 USD = 500,000 配额点；倍率优先级为"用户个人倍率 > 分组倍率 > 系统默认 1.0"。

One API 的"套餐"并非一等对象，而由三个原语组合而成：余额（配额点）+ 兑换码（等价于售卖套餐包）+ 分组（等价于套餐等级），本质是预付余额制，不带周期性重置，"包月 N token、每月 1 号重置"需自行加定时任务。New API 当前版本已补上这一缺口：官方《钱包与订阅》文档列出订阅套餐，重置周期可配置为不重置、每日、每周、每月或自定义，到达重置时间后清零已用额度并开始新周期，到期前不再设置越过订阅结束时间的重置。仍须按目标版本核对重置的执行方式、与余额的扣减顺序及并发语义——文档与源码存在不等于运行正确（见 5.9.5）。

路线 B：网关内置"成本预算 + 周期重置"（国际主流）

LiteLLM 有两条易踩的规则（官方《Budgets, Rate Limits》，2026-10-17 核对）：① key 归属 team 时只强制 team 与 team-member 预算，key 所有者的个人预算不生效；文档记载 v1.94.0 曾短暂对 team key 同时强制个人预算，v1.95.0 已撤回。② 未配置数据库时，全局 max_budget 检查 fail-open（仅启动时告警、请求不被拦截），key/team/user 预算则完全无法执行。

路线 C：网关只执行限额，定价与额度外置

一个值得注意的等价关系：Agent Router 的 CEL 表达式（如 input_tokens * 0.5 + output_tokens * 1.5）与 New API 的"补全倍率"在数学上等价——一个写在限流配置里，一个存在倍率表里。这说明"倍率"并非国内特有发明，而是 token 异质计价的通用解法。

5.9.3 模型倍率：两种定价范式 #

建议：企业自建取两者叠加——底层存真实单价（用于成本对账与 FinOps），上层加一层倍率/折扣系数（用于内部分摊与套餐分层）。只做倍率会丧失与供应商账单对账的能力；只做单价则难以表达"研发团队 8 折、试用团队 2 倍"这类内部治理诉求。缓存 token（cache read/write）须作为独立计价项，不可并入 input——主流供应商已单独定价。

5.9.4 重置规则：四种语义不可混用 #

三个必须在开工前定义清楚的边界条件（多数自建项目在此翻车）：

1. 时区：UTC 还是本地？LiteLLM 预算按配置时区午夜重置、多窗口 budget_limits 按 UTC 对齐（按作用域与版本核对，见 5.9.2），Portkey 硬编码 UTC——跨国团队不显式约定，"月底"会差 8 小时。
2. 结转：清零、全结转还是封顶结转？建议直接采用 OpenMeter 的统一公式表达，而非 if-else 堆叠：重置后余额 = MIN(maxRollover, MAX(重置前余额, minRollover))。
3. 多份额度并存时的消耗顺序：赠送额度、月度套餐、加油包同时存在时先扣谁？必须显式定义优先级（OpenMeter：priority 取 0–255，数值越小优先级越高、越先扣，同级近过期先扣；Stripe credit grants 同样以 priority 排序，实现时须核对其数值方向）。此规则一旦上线极难变更。

5.9.5 工程难点：难在并发与一致性，不在算式 #

① 承诺逐请求硬额度的方案，预扣—结算是必需品而非优化项：token 数只有响应结束才知道，因此 New API 采用"请求前按预估值预扣 → 响应后按实际 token 结算 → 差额多退少补"三步。若要承诺硬额度而不做预扣，高并发下额度就是纸面数字；只做事后计费与 showback 的方案不受此约束。

sequenceDiagram
    autonumber
    participant C as 客户端
    participant G as 网关
    participant R as 权威账本/额度服务
    participant P as 上游（供应商或引擎）
    Note over C,P: 本图仅示意「非流式正常路径」；流式与异常见 8.6.4 图与 T05
    C->>G: 请求
    G->>R: 预留（按最大可计费消耗，非乐观估算）
    alt 预留不足
        G-->>C: 拒绝（或按契约进入降级分支）
    else 预留成功
        G->>P: 转发（强制对应输出上限）
        P-->>G: 响应（含 usage）
        G->>R: 提交结算（权威账本；差额释放）
        G-->>C: 响应
    end
    Note over G,R: usage 缺失时记为 unknown，保留预留待核对，不得直接释放

② TOCTOU 竞态可致额度"无限透支"：one-api / new-api 均有公开 issue 记录——PreConsumeTokenQuota 的"读快照→检查→扣减"三步无互斥，并发请求可同时通过检查；启用 Redis 时实扣被放入后台 goroutine 异步执行、主流程立即返回，进一步放大竞态窗口；批量更新模式下进程崩溃还会永久丢失扣费记录。社区给出的修复方向为：Redis Lua 原子脚本、SQL 下界约束（quota >= 0）、数据库事务、退出前 flush 队列。但须明确其能力边界——见下方 ⑤，这些手段解决的是"单点竞态"，不构成系统级一致性保证。

③ 特定版本中预算强制可能读到陈旧计数而误杀（目标版本待核）：LiteLLM 有公开 issue 记录预算检查读取 Redis 预留计数器与 DB 实际 spend 背离，出现"实花 $30.45 / 上限 $35 却报 330 次 BudgetExceededError"，后续版本提供 disable_budget_reservation 缓解；另有"重置后 Redis 计数未失效导致继续超限""1mo 在 user 与 team member 上行为不一致"等记录。启示：硬上限与软告警必须分开设计，硬上限路径走原子计数器、不走缓存快照。

④ 流式与 usage 缺失：new-api 有公开 issue 记录流式 /v1/responses 在 response.incomplete 时丢弃 usage，导致该请求计费为 0。自建须覆盖三种异常：客户端中断、上游超时、供应商不返回 usage（应以本地 tokenizer 估算兜底，并标记为"估算、待对账"，不可默认 0，也不可冒充真实消耗，见下方 ⑤ 第 7 条）。

⑤ 原子操作解决什么、不解决什么（本节最关键的一段）

"Lua 原子脚本 + SQL 约束 + 事务 + 退出 flush"常被并列为额度正确性的解决方案，但它们不构成系统级一致性保证。逐条界定：

必须一并承认的逻辑缺口（非实测，属协议层反例）：设余额 100、10 个并发请求各预扣 10 全部通过，若实际各消耗 30，则最终需结算 300——原子预扣全程正确，仍产生 200 缺口。须注意：仅限制单请求输出上限并不足够——10 个请求各预留 10、即使每个被限制最多消耗 30，总消耗仍可达 300；输出有上限只提供了可计算的边界，并不自动把该边界绑定到账户已提交的预留。因此硬上限的成立条件应表述为：

硬上限要求：所有获准执行请求的最大可计费消耗，都被已提交的预留所覆盖，并由引擎或可信执行路径强制约束。 可采用「按最大输入及输出等费用预留 + 强制对应上限」，或「在新增消耗发生前完成分段追加预留，并界定不可取消的在途消耗」。不能被覆盖的部分必须纳入显式、有界的透支，并不再声称零超支；计量覆盖不到的请求类型不提供精确硬上限保证。

由此产生的设计要求清单（研究报告只列条件，具体方案由实施阶段选定并经 8.8 验收）：

1. 指定权威账本与提交点：Redis 是准入加速层还是记账权威？二者不一致时以谁为准、如何重建？
2. 区分预留（reserve）/提交（commit）/释放（release）/未知（unknown）四种状态，并定义预留超时的处置——预留超时不等于"推理未执行"，需与推理侧执行记录对账后才能释放。
3. 事件与标识分层，且事件 ID 唯一不足以保证幂等：业务调用 ID、执行 attempt ID、reservation ID、事件 ID/事件类型须分开；仅用"请求 ID 作幂等键"无法表达同一请求上的预扣、结算、退款三类事件，也无法表达重试导致的多次真实推理。须特别注意：若超时重试时重新生成 event ID，同一笔提交仍会入账两次——因此要求为：同一业务操作的重试复用稳定幂等键；除 event ID 去重外，权威账本必须约束 reservation 的合法状态迁移（同一 reservation 不得重复提交，也不得同时提交与释放；多次合法调整须使用独立的调整操作 ID）。
   • unknown 的含义须写死：它表示"执行结果/结算情况待核对"，不是可以释放余额的另一种终态；unknown 请求应保留其关联的有效预留，待恢复后由权威核对流程决定提交或释放（见 8.8 T02）。
4. 跨周期归属：跨月的结算与退款必须归属原额度周期，不可直接加回当前余额，否则等于凭空增发新周期额度。
5. 计价可重算：历史重算需固定价目表版本、倍率版本、标定版本与舍入规则，仅有"生效时间"不足。
6. fail-open 的诚实表述：对核心业务在额度服务不可用时放行，等价于允许有界应急透支，必须定义每主体/每实例的应急额度、有效期、并发上限与全局敞口，以及恢复后的补扣与补扣失败处理；不能同时宣称"超支归零"。全局敞口要真正有界，应急份额必须预先分配、不可重复领取：若每个实例启动时都可领取一份应急额度，扩容与反复重启会让总敞口随实例数和重启次数无界增长。因此须记录份额的发放与归还，恢复后先对账，并对已失联的旧实例做 fencing——旧实例失去新增执行与修改权威状态的权限；其迟到上报的用量不直接入账，也不被丢弃，而是作为待核证据交由当前权威对账流程核对后入账；未确认的在途敞口不得回收再发。具体方案与阈值留待 POC（8.8 T14）。
7. 流式与取消闭环：SSE 场景下"完整响应→结算"的时序图是简化表示。需补：流开始、首字节、终帧 usage、客户端断连后的取消传播与取消确认；客户端断连不等于上游停止计算；网关侧 tokenizer 估算看不到未送达输出与部分推理 token，估算值必须标记为待对账而不能冒充真实消耗；私有化场景应优先从推理引擎补取真实 usage。

上述 ②③④ 均引自项目公开 issue，反映的是特定版本下的已知缺陷，用于提示自建设计要点，不代表这些项目当前仍存在该问题；若作为选型依据须按目标版本复核修复状态（见 9.1 #33–#36）。⑤ 中的 Redis 一致性边界引自 Redis 官方复制文档（9.1 #61）；其余为协议层推演与设计要求，非实测结论。

六、国内外头部厂商与开源项目对比 #

6.1 国际云厂商 #

6.2 国内云厂商 #

证据边界：本表以二手资料为主（9.1 #20），最后核验时点为 2026-08，本版未逐项复核。除阿里云外，各行描述的是模型/应用平台自带的治理能力，属相关生态；"定位与特色"列只描述厂商宣称的能力入口，不构成认证范围或合规效果的证明。

国内现状（社区观察，无抽样调查支撑，不代表市场份额）：国内较常见的一种组合是"平台 API + One API/New API 私有化"，把多家云合在一张内部 OpenAI 协议入口之后，再加一层内部治理（成本、审批、数据分级）。需注意：这一组合本身只覆盖接入与计费，一期必建的安全基线（身份与权限、数据分级、最小留存、访问审计，见 8.1）以及二期的 MCP 工具治理与语义层检测，须按目标版本逐项核对；New API 的 README 未声明 MCP 与 Guardrails（未声明不等于不存在），One API 的维护状态待核。这些缺口是自建/选型要补齐的，而非已达标的终态。

6.3 开源项目对比 #

开源安全备注（2026 年）：LiteLLM 曾发生 PyPI 供应链攻击（2026.03），其官方安全公告所述事后处置（签名、第三方审计与公开复盘）公开透明度相对较高；但"善后做得好"不等于前置安全性高——2026-09/10 又有两项管理面安全公告（见 7.5），选型仍应独立核验其供应链与管理面防护。Bifrost/Portkey/Helicone 的签名与 SBOM 发布情况本报告未检索核实，选型时按目标版本自行查证，不以本报告作为其"有或无"的依据。

许可评估口径：AGPL-3.0 的义务取决于是否修改、如何部署、是否对外分发或以网络服务形式提供三项事实；其第 13 条以"修改版本"与"通过网络与用户远程交互"为触发条件，因此"内部使用"不是当然豁免——内部员工经网络使用修改版本时同样需要评估。企业内部私有化部署与对外 SaaS 的义务差异很大，须由法务按实际形态判定，不能仅凭许可名称排除或接纳。本报告涉及的 AGPL 项目包括 New API 与 Lago。此外，开源版与商业版能力须分列：本表中 Kong/APISIX/Portkey 等行混合了开源版与企业版能力，用企业版能力为开源方案打分会高估其可用性，选型时须按拟采用的版本重新核对。

6.4 计量计费与额度平面（外置结算的开源/商业实现） #

若采用 5.9 路线 C（网关只做计量采集与限额执行、套餐与结算外置），下列项目是业界现成可复用的"结算平面"。其额度语义的完整度显著高于各网关自带的预算功能，自建时其概念模型可供借鉴（不等于可直接照搬实现）：

一条与 4.4 相关的产品组合信号（弱证据）：Kong 既有 AI 网关（ai-rate-limiting-advanced 做 token 限额执行），又于 2025-09-03 宣布收购开源计量计费平台 OpenMeter，公告称将为 Kong Konnect 带来按量计费能力。这只证明同一厂商同时拥有两条产品线，不能证明部署时二者分层——厂商同样可能把计量并入网关控制面；公告中的集成计划也不是完成证明。因此它只作为 4.4「采集与结算可分离」判断的佐证之一，不单独作为论据。

七、演进趋势：MCP/Agent 网关（2025-2026） #

7.1 MCP 采用规模快速扩大 #

• MCP 采用规模快速扩大：Anthropic 官方（2025-12-09，捐赠 MCP 至 LF 的公告）称公开 MCP 服务器超 1 万个、月度 SDK 下载量 9700 万+（97M+，Python + TypeScript 合计）。这是 2025-12 的厂商口径快照，本版未取得更新的官方数字（详见附录来源分级）。
• 2026-07-28 规范版本的重大变更（依官方 Key Changes 逐条列出；该版本的候选版于 2026-05-21 冻结，正式版于 2026-07-28 发布）：
  • 无状态化：移除协议级会话与 Mcp-Session-Id 头；移除 initialize/initialized 握手，协议版本与客户端能力改由每请求的 _meta 携带；新增 server/discover（服务端 MUST 实现）用于版本与能力协商。
  • Tasks 从核心移出、进入官方扩展 io.modelcontextprotocol/tasks：以 tasks/get 轮询替代阻塞式 tasks/result，新增 tasks/update，移除 tasks/list。
  • MRTR（Multi Round-Trip Requests） 取代服务端发起请求（roots/list、sampling/createMessage、elicitation/create）：服务端返回 resultType: "input_required" 与 inputRequests，客户端以重试原请求并携带 inputResponses 的方式作答；所有结果新增必需字段 resultType。
  • 移除 SSE 流可恢复性与消息重发（Last-Event-ID 与 SSE event ID）：响应流中断即丢失在途请求，客户端 MUST 以新的 request ID 重新发起。
  • 其他：以 subscriptions/listen 取代 HTTP GET 端点与 resources/subscribe；移除 ping/logging/setLevel；tools/list 等结果新增 ttlMs 与 cacheScope（public/private）缓存语义；Streamable HTTP 的 POST 请求须携带 Mcp-Method/Mcp-Name 标准头；Roots、Sampling、Logging 三项特性进入弃用窗口，动态客户端注册（RFC 7591）弃用、改推 Client ID Metadata Documents；新增特性生命周期与弃用政策（最短 12 个月窗口）。
  • 授权加固：客户端 MUST 校验授权响应中的 iss（RFC 9207），客户端凭证与签发它的授权服务器绑定，不得跨授权服务器复用。
  • 对网关的直接影响（不止是"扩展性收益"）：① 无状态核心确实降低了 MCP 托管的水平扩展成本；② 但会话级上下文的归属需分类处理——鉴权上下文属网关、服务端任务状态属服务端句柄、工具业务状态属业务系统，不可一概说"由网关自行维护"；③ 流中断不再可恢复 + MRTR 以"重试原请求"作答，意味着同一有副作用的业务操作存在被重复执行的风险，网关与工具侧必须各自具备业务级幂等（请求 ID 变化不能作为幂等依据）；④ cacheScope 的 public/private 语义须被网关侧缓存严格遵守，否则构成跨主体泄露通道；⑤ 新旧版本将长期共存：server/discover 可作为向后兼容探测，网关须分别对客户端侧与上游侧做版本协商，不能因规范发布就推定现有产品已采用新语义——已有产品开始跟进（如 Kong AI Gateway 2.1 于 2026-09-24 声明支持该版本并处理 ttlMs/cacheScope 缓存提示），但支持范围限于其声明的版本。

需注意：采用规模 ≠ 协议安全性或最优性——MCP 仍存在设计级安全风险（见 7.4），选型应独立评估，不因采用规模而默认其安全。

7.2 网关从"代理"到"Agent 控制平面" #

当 MCP 工具数量与调用团队规模增长到一定程度（业界有"三个服务器即触发网关需求"的说法，属非实证经验阈值），MCP 网关需解决四个 CISO 核心问题：谁能调哪个工具、每次调用记录在哪、如何限流、如何避免在推理时把用户级凭证交给模型。"网关 + 注册表"是已有公开案例的趋势方向，尚不能称为企业级主流架构：网关执行认证、授权、策略、审计，注册表管理元数据与服务发现。代表案例为 Uber（2026-10-01 工程博客）：MCP Registry 作控制面、Proxy Gateway 作数据面，把 MCP 调用转换为对内部服务的 HTTP/gRPC 等调用；新注册的服务器与工具默认禁用，经所属团队审核后启用；Uber 自述托管 800+ 个 MCP 服务器、5000+ 个工具。单一案例的规模与做法不能外推为行业普遍情况。

7.3 三阶段路线图（2024-2027+） #

说明：本路线图为一种可能的演进猜想（综合多家厂商/网关产品的路线图投射），非确定性行业共识；各阶段时间点为趋势性估计，供规划参考而非立项依据。

1. Sidecar 模式（2024-2025）：保留现有 API 网关，独立 AI 网关并行部署，安全隔离但存在逻辑重复与策略漂移。
2. 智能 API 网关（2025-2026）：OpenAPI→MCP 自动转换、语义缓存、上下文感知限流、Agent 统一身份认证，趋于收敛。
3. Agentic Mesh（2027+）：网关成为"能力市场"，管理能力注册表、意图匹配、跨团队发现、组合编排，引入信任与声誉体系。

7.4 风险提示 #

• 安全：2026-04-15 OX Security 发布研究，认为 STDIO 传输的配置信任边界存在设计级风险，被污染的配置可导致执行任意命令。这是研究方的风险定性：据 OX 转述，Anthropic 认为 STDIO 执行模型属预期行为、输入净化是开发者责任，双方对责任归属有分歧。OX 原文给出三个口径不同的数字，均未公开统计方法：① 150M+ 下载——受影响供应链的下载量，统计窗口与包范围未说明，不能与 7.1 的 97M 月下载量比较或换算；② 7000+ 台公网可访问服务器；③ 最多 20 万个潜在受影响实例（上限估计）。三者都不是已确认的受害数。企业必须构建分层防护，不能默认 MCP 服务器可信：工具级授权之外，还须有启动命令白名单、进程隔离与出口约束，并遵守 MCP 授权规范的令牌受众绑定与禁止透传要求。
• A2A 兴起：开源网关 LiteLLM 自 v1.80.8（2025-12）起提供 A2A Agent Gateway，Kong v3.14（2026.04）也已支持 Agent-to-Agent 协议。跨 Agent 协作的治理正在成为下一竞争点；A2A 协议本身的治理归属与版本本报告未展开核验。

7.5 2026 年 9 月以来的新进展（截至 2026-10-17） #

以下仅收录主持人已核到一手来源的事项（来源见 9.1 #70–#95）；"趋势判断"一列为本报告归纳，不是厂商结论。计划中、封闭测试或厂商自述的事项已单独注明。

未纳入本节的候选（检索或核验不足）：OTel GenAI 语义约定稳定化（截至本版仍未见官方标记 stable）、Azure AI Gateway tier 的区域扩展与 GA（截至 2026-10-17 未发生）、国内云厂商 2026 年 9 月以来的网关层发布（本版未检索到可核验的一手材料）。

八、对企业内部建设模型网关的借鉴建议 #

8.1 建设定位：分阶段落地 #

建与不建的门槛（报告作者基于本次调研公开案例归纳的经验判断，非统计意义上的行业阈值）：若企业满足以下多数情形，自建网关收益明显——接入模型 ≥3 个、调用团队 ≥3 个、月 Token 消耗达规模量级、有成本归因/合规审计诉求。反之（单一模型、单一团队、用量小、无治理诉求），直接使用云厂商托管网关或纯 SDK 即可，自建网关属过度工程。

投入量级（定性）：一期中、二期较高、三期高；人力与工期因团队规模差异大，此处仅给相对量级，不设具体人月。

安全分期的一条硬约束：把日志/Prompt 采集放在一期、而把脱敏与内容安全放在二期，会形成"先采集、后保护"的危险窗口。正确口径为：一期必须先落身份认证、权限边界、数据分级、最小必要留存与访问审计；默认只记录经字段白名单控制的元数据；摘要与全文按数据级别与用途逐项启用（注意语义摘要仍可能包含敏感原文，摘要不等于脱敏）。凡需采集或外发敏感内容，相应的脱敏或保护控制必须与采集能力同期就绪，不得后置。可后置的是语义层检测增强（注入检测模型、内容分类器调优），不是安全基础本身。相应地，5.1 的"原生协议透传 + 强制治理"指的是保留原生负载形状，不等于绕开强制鉴权、限额与审计；网关无法解析的字段应显式限制或拒绝，而非默认放行。日志回放默认只用于隔离评测环境，禁止默认重放带副作用的真实工具调用。

待填假设表（用于把"投入量级"变成可估算项）：以下参数缺一不可，全部标注为预算假设而非承诺——模型与引擎组合及版本 / 硬件型号与卡数 / 上下文与输出长度分布 / 峰值并发与日均请求 / 分级 SLO 目标 / 日志与账本留存量及周期 / 可复用的既有基础设施（IAM、配置中心、数仓、告警）/ 版本升级频率。填表后再分别估算研发、推理运维、安全、计量运营四类投入。

责任归属：至少为权限、额度账本、调度与容量、计价、业务质量五项各指定一名 accountable 角色，并写明交付物与验收责任；8.4 风险登记册中"平台/架构"这类模糊归属须在立项时落到具体角色。

8.2 关键决策点 #

优先级标注：P0 = 必须现在定（影响架构地基）；P1 = 尽快定；P2 = 可后定。

决策点 1 的选型逻辑（自研/开源 vs 托管 vs 商业）：

flowchart TD
    Q0{已确定的隔离/驻留/审计控制要求} --> Q1
    Q1{需深度定制或数据须留在自有边界?} -->|是| R1[自托管/开源二次开发<br/>候选：LiteLLM / Portkey / Higress<br/>目标版本待核]
    Q1 -->|否| Q2{已确定必须离线或强隔离部署?}
    Q2 -->|是| R2[自托管 + 离线/气隙架构<br/>候选须满足已确定的控制要求]
    Q2 -->|否| Q3{团队小 需快速落地?}
    Q3 -->|是| R3[托管 SaaS / 云厂商网关<br/>数据经第三方，须先判断是否可接受]
    Q3 -->|否| R1

1.【P0】自研 vs 开源 vs 商业：先按 8.2 决策点 6 确定隔离、数据驻留与审计等控制要求，再选能满足这些要求的部署方式——行业标签（如"金融/医疗"）与产品品牌都不是部署结论的充分条件。有较强工程能力且需深度定制、数据须留在自有边界 → 基于 LiteLLM/Portkey/Higress 二次开发（目标版本待核）；需快速落地且团队小 → 托管 SaaS 或云厂商网关（须先判断数据经第三方是否可接受）；已确定必须离线/强隔离部署时 → 自托管 + 离线架构，候选方案须逐项核验是否满足已确定的控制要求。 2.【P0】统一协议出口（契约抽象层而非单一厂商形状）：以 OpenAI Chat Completions 兼容作为过渡基线（当前生态最广、迁移成本最低），以中立契约抽象层为终态目标（因其 de facto、无治理，且 OpenAI 的新能力正优先落地 Responses API；Chat Completions 仍受支持，但官方已推荐新项目使用 Responses，且 GPT-5.4 起的部分推理模式下 Chat Completions 不支持工具调用，见摘要结论 1）。网关内部以中立语义模型表示请求，双向适配 Chat Completions / Responses / Anthropic / Gemini，将原生协议转换能力从"可选"提升为必建（参考 New API 的双向转换）。当上游 Responses API 采用度显著上升、所需模型能力只能经 Responses 获得，或自身多协议需求明确时，由过渡基线迁至终态。分级口径：一期 MVP 只要求"OpenAI 兼容入口 + 中立契约抽象的预留"，四协议双向适配是终态目标，二者不矛盾。需正视能力取舍：Anthropic 扩展思考、Gemini 原生多模态、o 系列推理 token 等差异化能力应提供"原生协议透传 + 强制治理"（保留原生负载形状但不绕开鉴权、限额与审计，见 5.1），避免归一化即丢失能力。 3.【P0】成本治理前置：不要等发生超支事故后再补限流与花费追踪，应把预算/配额/花费上限作为网关的一等能力，提供"一个控制平面"而非"每个应用各自打补丁"。 4.【P1】安全策略外置：鉴权、策略、脱敏、审计应在模型推理回路之外强制执行（参考 AWS Cedar、Kong 声明式插件、OPA），使约束成为硬限制而非提示词建议。 5.【P1】厘清网关与编排边界：明确"AI 流量治理"（网关职责）与"Agent 完整生命周期治理"（编排层职责）的边界，避免重复建设与责任真空。 6.【P0】国产合规（适用范围须先行判断）：不能笼统地说"生产环境模型调用需符合《生成式人工智能服务管理暂行办法》"。该办法第二条明确：适用对象是"利用生成式人工智能技术向中华人民共和国境内公众提供生成文本、图片、音频、视频等内容的服务"；并明确"行业组织、企业、教育和科研机构、公共文化机构、有关专业机构等研发、应用生成式人工智能技术，未向境内公众提供生成式人工智能服务的，不适用本办法的规定"。因此纯企业内部使用、不向境内公众提供服务的私有化部署（形态 B 的典型情形），通常不落入该办法的适用范围。

• 但"不适用某一部规章"绝不等于没有法律义务：网络安全法、数据安全法、个人信息保护法、等级保护与行业监管要求（金融、医疗、政务等）以及劳动者个人信息处理规则仍须分别判断并履行各自适用的义务（不得由某一部规章的例外反推其余规则一概适用或一概免除）；一旦服务面向企业外部公众（含对外产品嵌入生成式能力、对外开放试用），适用性判断即发生变化。
• 正确的判断顺序：① 是否向境内公众提供服务（而非仅内部使用）→ ② 处理何种数据类型（是否含个人信息、敏感个人信息、重要数据）→ ③ 实际服务提供主体是谁（自研自用 / 转售 / 嵌入对外产品）→ ④ 部署与外联路径（是否有出境、是否经第三方）。四项逐一判定后再确定义务清单，不得以部署地点或供应商资质替代适用性分析。
• 在仍需对外提供服务的场景下，以下判断仍成立（配置 + 路径 + 备案的组合，而非"走有资质云厂商即自动合规"）：(a) 数据驻留由部署区域与转发策略保证、需可验证，厂商资质本身不自动等于数据不出域；(b) 自托管、气隙与云网关都只是部署选项，不是"合规路径"：应先按服务对象、数据类型、服务主体与外联路径确定适用义务，再核验相应技术控制及必要手续；部署方式与供应商资质均不能替代该判断，安全评估、算法备案与行政许可分别按各自适用条件判断；(c) 企业内部网关调用第三方 API 可能触发服务提供者义务与算法备案要求，须独立评估，不由网关路由自动免除。注：法规以施行文本为准——修改后的《网络安全法》自 2026-01-01 起施行，新增人工智能安全与发展条款；《人工智能生成合成内容标识办法》自 2025-09-01 起施行，对向公众提供生成内容的服务设定标识义务，内部使用场景按第一步判断其适用性。本报告合规部分仅覆盖境内场景；若业务涉及出海或欧洲用户，需另行评估 GDPR、EU AI Act（如高风险 AI 系统的自动化决策留痕、数据主体访问权）对网关层的要求。 7.【P1】可观测统一：采用 OpenTelemetry GenAI 语义约定，避免各供应商观测数据割裂。但需注意其成熟度——该约定已迁移至独立的 GenAI 语义约定仓库维护、官方口径为"处于积极开发阶段"，本报告复核未能确认其已达 stable；因此应"锁定版本 + 自有扩展字段集中定义"，并把升级迁移纳入计划，而非假定字段永久稳定（见 8.7 口径提醒）。 8.【P0】网关自身韧性（威胁模型）：集中化网关是新的单点故障与高价值攻击目标，须补齐：网关高可用（多可用区、无状态化）、密钥外部化（HSM/KMS，网关不落地明文；注意外部化不等于网关运行时被控后无法滥用凭证——运行时仍可调用解密或代签，须配合最小权限、短期凭证、按用途分离密钥与调用审计）、审计日志防篡改（WORM）、以及"网关被控"降级预案（按租户熔断、本地策略缓存）。当团队数/网关流量规模超阈值时，应评估"联邦式网关"（每团队/每域轻量网关 + 中央策略/计量聚合）作为集中式之外的替代，避免单一集中点放大风险。 9.【P1】计量分层与额度语义前置定义（详见 5.9）：① 架构上区分「计量采集（网关）/ 额度执行（网关）/ 定价与结算（可外置）」三段，不把财务逻辑焊进数据面；② 定价采用"真实单价 + 倍率系数"双层，缓存 token 独立计价；③ 三项额度语义必须在开工前写进设计文档——重置时区、结转规则、多份额度的消耗优先级，这三项上线后极难变更；④ 额度正确性按 5.9.5 ⑤ 的权威账本与硬上限条件设计（预留覆盖最大可计费消耗、稳定幂等键、状态迁移约束），硬上限与软告警分开设计；不把某一种技术组合（如 Redis Lua + DB 约束）写成统一必选方案——它解决单点竞态，不构成跨存储一致性或硬上限证明。 10.【P0·仅形态 B】网关分层与饱和治理（详见 8.5、8.6）：① 治理与调度应做逻辑职责分离——治理侧（身份/额度/策略/审计）与调度侧（负载与 KV 缓存感知选点、容量准入）职责分开，通过锁定版本的治理上下文契约（优先级、公平域、缓存域等，载体可能是请求头，也可能是请求体扩展字段，见 8.6.2 第 12 项）解耦；二者可以由同一产品模块实现，也可以拆成物理上的 L1/L2，是否双跳取决于既有组件、性能与故障域，本报告不主张单一架构；调度侧优先评估复用 GIE / llm-d 等既有实现而非自研；② 共享池接近容量时须启用准入与排队（并发、速率与容量约束可以并存，准入不替代限速），并公示"保 TPOT 牺牲 TTFT"的取舍口径；③ 额度计价单位须重新定义（等效算力单位为可选方案，须定期回归标定，且长期配额不能替代瞬时容量准入，见 8.5.4）；④ 降级优先于拒绝，任何拒绝都要给出自助解决路径，否则业务将绕过网关（影子 AI），失去的是全部治理能力；⑤ 区分成熟度：GIE 的 InferencePool 自 v1.0.0 起为 v1/GA，InferenceObjective 仍为 alpha（v1alpha2）、官方明示可能破坏性变更，后者不宜过早深度绑定。

8.3 推荐参考组合 #

• 基础设施底座：LiteLLM（提供商覆盖面广、扩展点多）或 Higress（MCP 能力强、国内生态集成度高）或 Kong/APISIX（已有网关体系可复用；注意 Kong 的 advanced 系列属企业版，APISIX 与其能力不应合并评价）。
• 可选智能路由层：Not Diamond / Martian 等，做按质量/成本/延迟的模型优选。
• 治理增强：Portkey 企业版等商业治理产品（强监管场景；须按目标版本核验）。
• 供应链安全门槛（选型硬约束）：仅选用提供 SBOM、镜像签名（Cosign/Sigstore）、依赖扫描的构件，并校验签名者身份、构建来源（provenance）与部署制品摘要——合法流水线也可能签出恶意制品，仅"有签名"不够。LiteLLM 2026.03 供应链攻击表明网关是"高价值集中目标"；按最坏情形推演，依赖链被控可能连带泄露网关持有的供应商密钥、虚拟密钥、PII 与审计日志（这是推演，不是该事件的实际影响范围）。

选型利益声明：上述推荐基于公开资料的能力匹配，不代表任何厂商赞助或背书。其中 LiteLLM、Higress、Not Diamond 因本报告引用其官方说法较多，特说明其对外结论对自身产品有推广立场，采纳时请独立核验。亦可关注同属可选的方案（APISIX ai-* 插件、Agent Router（原 Envoy AI Gateway）、agentgateway、Bifrost、自研轻量网关）以对冲确认偏误，其中前四者已列入下方选型决策表。

场景 → 推荐映射：

• Python 技术栈、需快速扩展生态 → LiteLLM
• 需国内生态集成与 MCP 能力、CNCF 治理 → Higress 列为候选（能力与版本仍须核验；不以产品名替代 8.2 决策点 6 的适用性判断）
• 已有 Kong 网关体系 → Kong AI 插件（注意 *-advanced 系列属企业版）；已有 APISIX 体系 → APISIX ai-* 插件（开源，但无语义缓存与虚拟密钥预算）
• 已确定需强隔离与企业级治理审计 → Portkey 企业版等商业治理产品列为候选（须核验其满足已确定的控制要求）
• 纯托管、团队小、可接受数据经第三方 → OpenRouter / Cloudflare AI Gateway（底层运维由厂商承担，策略与密钥仍需自理）
• 需"倍率 + 套餐 + 兑换码"式内部分发计费 → New API 的倍率、账本与订阅套餐模型（当前版本已提供周期重置；重置执行与并发语义须按目标版本验证，见 5.9.2；注意 AGPL-3.0 义务评估）
• 需对外售卖 token 套餐（含结转、加油包、消耗优先级）→ 套餐生命周期与结转语义可借鉴/复用 OpenMeter / Lago；逐请求实时硬限额须按目标版本单独验证其并发 reserve/commit/release 保证，未通过验证前另设实时额度组件（见 6.4）

MVP（最小可行清单）：最小集必须覆盖网关高可用、身份与数据分级、恢复期对账，以及形态 B 的准入与取消传播——任何少于下表的清单都不足以支撑一期上线。按两类形态分列：

上线前置条件（非可选项）：以上每格都需有明确的失败语义与责任人；未完成 8.8 中对应用例者，只能进入受控 POC，不进入生产承载。

若自建额度体系，建议的最小数据模型（五类核心实体的示意表，详见 5.9）：

成本结构维度（定性，不设具体金额）：自建成本 = 人力（开发/运维/安全）+ 基础设施（计算/存储/数据库/缓存）+ 许可（商业版）+ 持续维护（协议适配、模型接入迭代）；托管 SaaS 成本 = 平台费/流量费，无自建运维但数据流经第三方。

选型决策表（定性能力矩阵，强/中/弱）：

使用说明：本表为功能与条件对照，非量化评分。性能一律标为未实测，任何性能取舍须由 8.8 T12 的同硬件、同负载、同治理功能、同流式条件对比给出；厂商自测数字见第六章及其来源与测试条件限制，不并入本表。未能定位到具体版本的能力标注为"目标版本待核"，不得用企业版能力为开源方案打分。"部署与数据控制条件"仅描述可核验的部署事实，不构成合规结论——适用义务须按 8.2 决策点 6 的四步判断。

8.4 成功度量与风险登记 #

成功度量 KPI（示例，需按企业目标定制）：

• 成本：单请求平均成本较直连下降；未经授权的额度突破为零，应急透支不超过约定敞口并单列统计（不与"零超支"混同）；
• 可用性：供应商切换 RTO 分钟级、网关自身可用性 ≥ 99.9%；
• 治理：100% 调用可计量归属、密钥泄露爆炸半径缩小；账本与供应商账单月度对账差异率 ≤ 0.5%（口径需自定，此处为示例量级）；
• 安全：注入/越权拦截率（须同时定义攻击样本集与误报率，否则不构成安全保证）、审计日志完整率。

KPI 口径要求（没有口径的 KPI 会被优化成假象）：① 状态须拆成三个正交维度，不可混为同一组分母（否则会重复统计或错误相加）——请求生命周期：已拒绝 / 已接纳在途 / 已完成 / 已失败 / 已取消 / 结果未知；计量质量：引擎实测 / 网关估算 / 缺失；结算状态：未结算 / 已结算 / 待调整。三维各自定义分母、窗口与数据来源，三者之间不得直接相加（例如"已完成"与"估算"完全可能同时成立）。具体枚举值在实施设计阶段冻结即可。只看"成功请求的延迟"可以靠拒绝长请求把指标做好看，因此延迟必须与接纳率同屏报告。② 延迟口径：TTFT 须声明起点（客户端到达 / 网关接纳 / 转发上游）以及是否包含网关排队时间；TPOT 须区分服务端生成 token 与网络流块。③ 分位数聚合：多实例须先聚合直方图再算分位数，不可对各实例 P99 取平均。④ 不可同单位相加：token、计价单位（WTU）、GPU 利用率分别统计，"对账差异率"只在同一口径的两份记录之间计算（如网关账本 vs 推理侧执行记录），不可用不同量纲的数据相除。⑤ 高基数控制：用户/请求 ID 留在日志与分析存储，不要作为时序指标标签无限展开。⑥ 质量不能只看成本：单纯"低成本模型调用占比上升"可能掩盖业务质量下降，须与采纳率/返工率等业务指标同屏对照。

建设风险登记册（示例）：

8.5 私有化多算力池场景：能力差异与架构分层 #

适用语境：网关下游为企业自有推理集群（多模型 + 多 GPU 算力池），不涉及公有云模型服务（形态 B，见〇.1）。本节只讲相对 8.1–8.4 默认语境的差异，未提及处沿用前文结论。

8.5.1 前八章结论在本场景下的适用性修订 #

8.5.2 差异一：路由从"选供应商"下沉为"选副本"——算力感知路由 #

业界正在形成治理与调度的职责分层：上层治理网关（本报告主体）+ 下层推理调度层（inference gateway / router）。需要强调的是，这一层目前是可评估的生态规范与若干实现，而非一组可互换的既成标准。评估时建议按四层分别锁定版本：Gateway API / GIE 资源规范 → 代理实现 → 生产级 EPP / 调度器 → 推理引擎，并记录 CRD 版本、特性开关与兼容组合。

• Gateway API Inference Extension（GIE，Kubernetes SIG 项目）——注意它首先是"规范"而非"生产实现"：官方自述目标是"定义规范以构建兼容的生态"。核心 API 为 InferencePool（自 v1.0.0 起为 v1/GA；一组模型服务端点，用 selector 匹配 Pod、targetPorts 指定端口、endpointPickerRef 引用 EPP——官方文档记载该字段在 v1.5.0 之前为必填、现为可选；failureMode: FailOpen 时 EPP 故障则回落由网关自行选点）。关键澄清：项目自带的 Endpoint Picker 被官方明确描述为"用于一致性测试的轻量参考实现"，并明示"生产部署应实现自有 EPP 或采用既有实现（如 llm-d-router，组件现行名称以 llm-d 官方仓库为准）"——因此不可把它当作开箱即用的生产调度器。EPP 这一角色本身负责"根据模型服务上报的指标与能力做出最优端点决策"，支持按模型名路由、LoRA 适配器路由、前缀缓存状态等因素，并提供 serving priority（在线推理优先于容错批量任务）。InferenceObjective（alpha，通过 x-gateway-inference-objective 请求头关联）承载 Priority，官方明示未来将扩展 SLO attainment 等字段且可能有破坏性变更——须按锁定版本描述与集成，不宜过早深度绑定。
• llm-d（截至 2026-10-17 尚未发布 1.0，1.0 计划于 2026-10-19 发布，见 7.5；评估须锁定具体版本）：Router = Proxy（符合 GIE 标准的 L7 代理，经 ext-proc 咨询 EPP）+ EPP（按实时指标、KV 缓存亲和与策略为 Pod 打分）。提供前缀缓存感知路由、事件驱动的 KV 缓存索引、KV 分层卸载（CPU/SSD）、P/D 分离（prefill 与 decode 交由不同 worker，Router 编排 KV 传输）、Workload Variant Autoscaler（跨 variant/池放置副本，在满足延迟目标下最小化成本）。
• NVIDIA Dynamo（当前正式版 v1.5.1，评估须锁定版本）：前端 tokenize 后基于 worker 上报的 KV 缓存事件评分选点（--router-mode kv），亦可以 GIE EPP 形态接入；另在请求体 nvext.agent_hints 中接收优先级等 Agent 提示（v1.5.1 文档已列，后端支持不一，见 7.5），由此带来的信任边界问题见 8.6.2 第 12 项。

结论：形态 B 下"智能路由"（5.2）增加了一层新含义——在"选模型/选池"之外，还需"按 KV/前缀缓存亲和 + 队列压力选副本"；但选副本不替代选模型，二者是串联而非替代关系。关于收益幅度须避免无条件断言：前缀缓存命中免去的是 prefill 计算，vLLM 官方明确其"只减少处理查询（prefill）阶段的时间，不减少生成新 token 的时间"，因此在长输出、低前缀共享率的负载上收益可能很小。是否构成主要杠杆，取决于实际负载的前缀共享率与输入/输出长度比，须以自有流量实测判定（见 8.8 T09/T12），本报告不作普适性结论。

flowchart TB
    APP["业务应用 / Agent"]
    subgraph L1["L1 治理网关（本报告主体·控制治理面）"]
        A1["身份与主体解析<br/>虚拟密钥→用户/项目/任务"]
        A2["模型准入校验<br/>allowlist / 上下文上限"]
        A3["配额预扣 + 优先级判定"]
        A4["协议归一化 / 护栏 / 审计"]
    end
    subgraph L2["L2 推理网关（GIE / llm-d / Dynamo·算力面）"]
        B1["Flow Control<br/>准入与优先级队列"]
        B2["EPP 选点<br/>负载 + KV/前缀缓存亲和"]
        B3["P/D 分离编排 / LoRA 路由"]
    end
    subgraph POOL["算力池（多模型 × 多副本）"]
        C1["池 A：70B 主力"]
        C2["池 B：7B 降级/批处理"]
        C3["池 C：多模态 / 长上下文"]
    end
    OPS["计量 + 观测 + 管理 Portal"]
    APP --> L1
    L1 -->|"注入 priority 与 fairness-id"| L2
    L2 --> POOL
    L1 -.->|"用量账本 / 观测信号"| OPS
    L2 -.->|"vLLM 指标：队列深度 / KV 水位"| OPS

边界纪律（逻辑职责，而非强制的物理部署）：治理侧负责主体级策略（身份、权限、额度、审计），调度侧负责容量准入与副本选点；二者通过锁定版本的治理上下文契约解耦（GIE 的 x-gateway-inference-* 请求头是其中一种载体，跨实现互通须按所选版本确认）——治理侧把"这是谁、什么优先级、属于哪个公平域"写进请求（并剥离调用方自带的同类字段，无论在请求头还是请求体，见 8.6.2 第 12 项），调度侧据此排队与选点并校验来源可信。是否拆成两个物理网关，取决于既有组件复用、性能预算与故障域划分；单体实现同样可以满足该职责分离。

8.5.3 差异二：共享池接近容量时，准入控制与优先级队列成为必要能力 #

外部 API 场景下限流主要为了"别超支"；私有化场景下物理算力有限，共享池接近容量时会出现饱和，此时需要在限速之外增加准入（admission）——两类约束并存而非互相替代。GIE 的 Flow Control 指南给出了一套可借鉴的机制模型（实际可用性取决于所选 EPP/调度器实现与锁定版本）：

• 要解决的三个问题：嘈杂邻居（单用户长提示独占队列与 KV 缓存）、调度遗憾（请求过早锁定到次优端点无法改派）、优先级反转（模型服务器按序列长度/到达时间批处理，不理解业务优先级）。
• 核心取舍：饱和时"保护 TPOT 而牺牲 TTFT"——让请求在网关队列中等，换取已接纳请求稳定的生成速度。这条取舍值得在企业内部作为明确的 SLO 约定写进服务协议。
• 关键机制：FlowKey = Fairness ID（x-gateway-inference-fairness-id，可取租户/用户等级）+ Priority（整数，负值表示后台/低优先级）；严格优先级（高优先级队列服务完才轮到低优先级）；同一优先级内工作保守型公平（有闲置容量就不人为节流，仅争用时激活公平分配）；容量与生命周期由 maxBytes（待处理请求聚合体积上限）、按优先级的独立容量上限与 defaultRequestTTL（超时丢弃）控制；饱和检测器综合 KV 缓存利用率与本地队列深度评估池健康度。

• 适用性限定（就近说明）：本节描述的是 GIE 定义的能力模型；实际可用性取决于所选 EPP/调度器实现与锁定版本（GIE 自带 EPP 仅为一致性测试参考实现，见 8.5.2 的四层版本组合要求），不可假定"照文档即可复用"。

llm-d 的工程补充：准入与调度分离（"admission 决定何时可推进，scheduling 决定去哪跑"）；同一优先级带内按租户轮询，避免单租户突发独占调度机会。须澄清一处常见误读：同级轮询只保证该优先级内部的公平，并不能推出"低优先级不会饿死"——在严格优先级下，只要高优先级持续占满容量，低优先级就可能长期得不到调度；且请求数轮询也不等于 token 或 GPU 时间公平（长请求占用远大于短请求）。因此企业必须在两条路线中显式选择并写入服务承诺：(a) 接受低优先级可饿死，但以 TTL 超时 + 明确的失败语义兜底；(b) 设保底份额、老化提升（等待越久优先级越高）或限制高优先级总负载。同时须定义队列取消、TTL 到期后的额度释放、多实例容量聚合口径，以及调度元数据陈旧时的行为；分级 SLO 实践（高优先级维持亚秒级 TTFT，批处理档吸收排队延迟）；并强调 dispatcher ceiling、队列上限等参数必须针对具体模型、vLLM 配置、GPU 容量与流量组合实测校准，无通用默认值。

与批处理调度的分工（易混淆，须写清）：

两者作用于同一组 GPU 但处在不同调度层次，不可互相替代：只有 Kueue 无法解决在线请求的队头阻塞，只有网关 flow control 无法防止训练/批量作业把卡占满。

8.5.4 差异三：额度单位必须与算力占用挂钩 #

问题：相同数量的 token，其实际资源占用受上下文长度、模型、引擎实现与当时负载影响而不同（具体差异须本地实测，本报告不给量级结论）；若照搬公有云"美元/千 token"做内部额度，可能系统性地鼓励错误行为（例如放任超长上下文、惩罚善用缓存的用户）。

建议的分层——先把三件事分开，再决定是否引入加权单位：

在此基础上，可选采用等效算力单位（WTU, Weighted Token Unit）作为运营计价单位。须先承认它的性质：WTU 同时混合了资源权重与优先级价格，因此它是一个运营积分，不能宣称精确等于物理算力。初期更稳妥的做法是先用"原始 token + 模型系数"试点，待计量与对账闭环后再考虑加权：

WTU = (prefill_tokens × w_p + decode_tokens × w_d) × 模型系数 × 优先级系数 − 缓存命中折减

五条纪律：

1. 权重需定期回归标定——引擎升级、量化方式变更、P/D 分离开关都会改变实际算力占用；
2. 账本须同时记录原始 token 与计价单位（5.9 的 ledger 表），否则日后无法换算口径、也无法向用户解释扣费；
3. 警惕重复计价：若 w_p/w_d 已在目标模型上标定，再乘"模型系数"可能对同一差异计价两次；计价式中的各项必须互不重叠，并逐项标明哪些可直接采集、哪些为估算、哪些当前不支持（如多模态内部用量常不可见）；
4. 上式为线性示意，并未表达"长上下文加价"——若要体现长上下文的非线性成本，需显式增加上下文档位项，而非依赖读者脑补；缓存命中折减还须定义计量单位、折减下界与所属计价版本；
5. 计价单位不能替代运行时准入：WTU 余额是长期配额约束，而 GPU 显存、KV 缓存水位、队列深度是瞬时容量约束，二者不同类。余额充足不代表此刻有容量，余额耗尽也不该成为绕开容量判断的理由——运行准入必须继续以并发、KV 水位、队列与容量反馈为准（8.5.3）。

若启用加权计价，5.9 数据模型的映射关系为：模型系数与优先级系数落在 ratio 表，标定版本与价目版本落在 price_book，且须随每条账本事件固化（见 8.3 ledger 的"不可变计价版本"字段）。

8.6 Token 配额运营：网关与管理 Portal 的能力划分与交互 #

需求语境：按用户、任务等差异分配不同能力的模型，管理 token 套餐额度，驱动合理使用、体现价值导向。

8.6.1 设计目标：约束、引导、度量 #

价值导向的配额体系不止于"别超用"，而是让**"用对模型、写好 prompt、错峰跑批"成为对用户最有利的选择**。三个目标依次是：约束（谁能用什么、用多少）、引导（差异化定价让正确行为更划算）、度量（让每一份算力消耗可归因到业务价值）。缺任一环，配额就退化为单纯的行政限制，最终被业务绕过。

8.6.2 网关侧（数据面）能力清单 #

一条架构纪律：网关只执行策略，不定义策略，也不持有策略的唯一真相。所有策略的权威来源在 Portal/配置中心；网关持有的是带版本号的副本。违反这条纪律的直接后果是：策略无法审计、无法回滚、多实例间行为漂移。

8.6.3 管理 Portal 侧（控制面）能力清单 #

8.6.4 交互机制：控制面与数据面的四条链路 #

flowchart LR
    subgraph CP["控制面 · 管理 Portal"]
        P1["策略/套餐/模型目录"]
        P2["审批流"]
        P3["报表与看板"]
    end
    subgraph STORE["共享存储层"]
        D1["配置中心<br/>（策略 + 版本号）"]
        D2["权威额度服务/账本<br/>（实现待决，见 5.9.5 ⑤）"]
        D3["分析/观测存储<br/>数仓·BI（非权威账本）"]
    end
    subgraph DP["数据面 · 模型网关"]
        G1["策略本地缓存"]
        G2["原子预扣/结算"]
        G3["观测/分析事件发布"]
    end
    P1 -->|"①策略下发<br/>版本化·灰度·回滚"| D1
    D1 -->|"监听/轮询 + 本地快照"| G1
    G2 <-->|"②reserve / commit / release<br/>幂等与状态迁移约束"| D2
    P2 -->|"额度发放（写）"| D2
    G3 -->|"③用量回流（分析用途）<br/>异步批量 + 事件 ID 去重"| D3
    D2 -.->|"权威结算结果（对账基准）"| D3
    D3 --> P3
    P1 -.->|"④控制指令：熔断/限速/强制降级<br/>低频高危·二次确认·可撤销"| G1

四条链路的工程契约：

一条常见的设计错误：把 Portal 做成请求路径上的同步依赖（例如每次调用都去 Portal 查配额）。正确做法是治理控制面 Portal 不成为逐请求同步依赖；确有需要时，请求路径可同步访问专用的额度、鉴权或策略服务，但这些服务须独立设计其 SLA、容量与降级语义——这不等于禁止请求路径上的一切同步依赖，而是禁止把面向人使用的管理控制台放进请求链路。

sequenceDiagram
    autonumber
    participant U as 用户/应用
    participant G as 治理网关(L1)
    participant Q as 额度服务(权威账本)
    participant I as 推理调度层(L2)
    participant M as 算力池
    participant A as 分析/观测存储
    U->>G: 请求（携带密钥/任务类型/降级契约）
    G->>G: 主体解析 + 模型准入 + 剥离并重建治理控制字段（请求头与请求体）
    G->>Q: 预留（所选计价单位；WTU 仅为其中一种取值）
    alt 预留不足
        Q-->>G: 拒绝
        G->>G: 判断调用方契约是否允许降级
        alt 契约不允许降级
            G-->>U: 拒绝并终止本次请求（附自助解决路径）
        else 允许降级
            G->>G: 重新授权（目标模型/上下文变换）
            alt 重新授权不通过
                G-->>U: 拒绝并终止本次请求
            else 重新授权通过
                G->>Q: 按降级目标重新预留
                alt 重新预留失败
                    G-->>U: 拒绝并终止本次请求（附自助解决路径）
                else 重新预留成功
                    Note over G,Q: 持有有效预留，进入执行段
                end
            end
        end
    end
    opt 授权通过且持有有效预留（原请求或契约内降级）
        G->>I: 转发（注入可信治理上下文：priority / fairness-id 等，头与请求体扩展字段）
        I->>I: 饱和检测 → 按已选定的优先级/公平策略准入排队
        I->>M: 选点（负载 + KV 前缀缓存亲和）
        M-->>I: 响应增量
        I-->>G: 响应增量
        G-->>U: 持续转发增量（流式）
        G->>Q: 终止后提交结算；usage 缺失则记 unknown 保留预留待核对
        G->>A: 发布观测/分析事件（分析副本，非权威账本）
    end
    Note over G,A: 任何拒绝或未持有有效预留的路径均不进入转发；故障与异常分支见 8.8 T02 / T05 / T06

8.6.5 "驱动合理使用"的机制设计 #

反模式警示（最重要的一条）：一刀切的硬限额会把业务逼向"绕过网关"——自建直连、共用私人密钥、影子部署，最终失去的是全部治理能力而不只是那点额度。因此三条底线建议写入设计原则：降级优先于拒绝；申请通道永远畅通且有 SLA；任何拒绝都必须返回可自助解决的路径（如何申请、降级到哪个模型、何时恢复）。

但"降级优先于拒绝"必须受契约约束：自动换小模型、缩短上下文、转异步批处理都改变了调用契约，不能由网关单方面静默执行。要求：① 由调用方显式声明可接受的替代模型集合、质量下限、允许的上下文变换、以及是否接受同步转异步；② 降级后须重新走权限校验与额度预留再执行并结算（8.6.4 时序图的降级分支即按此规则绘制：重新授权或重新预留任一失败即终止本次请求，不进入转发）；③ 流已开始输出后不得透明拼接另一模型的续写；④ 余额为零时降级到小模型仍然消耗算力，因此必须另设应急额度，不能用"降级"绕开额度或权限拒绝；⑤ 涉及有副作用的工具调用时，降级与重试都需业务级幂等保障（与 7.1 中 MCP 移除流恢复后的重发风险同源）。

8.7 运维监控与运营管理能力清单（超出标准观测与按需内容留存） #

说明：OTel 标准观测信号上报与按需启用的内容留存（默认仅字段白名单内的元数据，见 8.6.2 第 8 项）只是基线，不是全部。以下按八个域给出需要额外开立的能力，标注"必备/增强"。形态 B 特有项已单独标注。

关键指标清单（建议最小集）

两点口径提醒：① 上表 vLLM 指标名按其 latest 版《Metrics 设计》文档（V1 引擎口径，2026-10-17 核对）列出；旧版的 gpu_cache_usage_perc、gpu_prefix_cache_hit_rate 等名称已改名或弃用。指标名随版本演进，落地时须锁定一个 vLLM 版本，以实际部署版本的 /metrics 为准；② OpenTelemetry GenAI 语义约定仍在演进——该约定已迁移至独立的 GenAI 语义约定仓库维护，官方表述为"正在被使用且处于积极开发阶段"，截至本报告核验时点（2026-10-17）未见官方将其标记为 stable，多份二手资料称其属性仍为 Development 状态。因此建议：以 OTel GenAI 约定为主干字段，企业自有维度（任务类型、优先级档、WTU、降级标记）作为扩展字段并集中定义，同时锁定所采用的约定版本、在升级时统一迁移，避免各系统字段语义漂移。

8.8 POC 验收矩阵与实施前待决项 #

性质声明：以下全部为待执行用例，不是已完成的测试记录。执行前须先锁定版本、配置、负载画像与判定阈值，执行后归档原始证据。本报告的任何结论都不能替代这些用例的实测结果；未通过对应用例的能力，只能进入受控 POC，不得进入生产承载。

实施前待决项登记表：以下事项不需要在研究定稿前解决，但必须在实施启动前逐项定下来并留痕；阈值可先写"POC 开始前确定"，责任角色沿用 8.1 的五类 accountable 角色，不在本报告中虚构姓名或数字。

九、附录：关键事实来源与证据分级 #

本报告关键事实按"优先一手、二手复核"原则逐项追溯，但不构成"全部已核验"的总括保证；表中仍存在待核条目。A/B/C 仅表示来源类型，不表示核验状态或证明力度——三者分列如下。厂商能力断言与运行保证不得仅由产品自述、用户报告或作者推论支撑；逻辑反例可以支持"机制存在局限"这类判断，但不能替代运行实测结论。分级标准如下：

一、来源类型（A/B/C）——只描述来源身份，不含核验状态判断：

• A 级（一手/官方）：厂商或标准组织的官方文档、官方博客、官方新闻稿、官方 GitHub Release/仓库文件、法规发布机关原文。
• B 级（二手，有交叉印证）：权威行业媒体，或多个来源相互印证的二手信息。
• C 级（二手，单一来源）：单一二手来源（技术博客、内容平台转载等）。
• issue（项目公开 issue）：由用户在项目仓库提交的缺陷报告或讨论，位于官方仓库但不代表项目官方结论，单列一类。

二、核验状态：逐条记录在表内"核验结果"列（✅ 确认 / ⚠️ 有限定 / 待核）。来源等级高不等于已核验，也不等于证明力强——例如 A 级的产品自述只能证明"厂商如此声明"。

三、证据性质：表内"证据性质"列按下列取值标注——规范事实（标准、法规、官方 API 定义）、产品自述（厂商文档、博客与公告，含推广立场；能证明"厂商如何描述其能力"，不能单独证明运行保证）、用户报告（公开 issue，仅证明"有人在某版本报告过"）、安全公告（项目方发布的漏洞通告，证明受影响与修复版本的官方认定）、安全研究（安全厂商或研究机构的研究报告，非同行评审，含研究方立场）、学术研究（论文）、二手报道（媒体或二手资料转述）、作者推论（本报告的设计判断与逻辑反例）、待核。

四、核验时点：v5.2 新增或复核的条目在"核验结果"列注明核验日期；未注明日期的 ✅ 为历史版本（v1.x–v5.1，2026-08 至 2026-09-18）的核验记录，本版未逐条重访，不等于截至本版仍然成立。

9.1 关键事实来源分级表 #

编号为历史沿用，其中三项（原 #18、#22、#40）因未能追溯到一手来源已从本表与正文一并移除；#66 自 v5.2 起并入 #48，#70–#95 为 v5.2 新增。处置过程见第十一章。

9.2 少数意见与未采纳意见 #

本节保留第 1–3 轮各席中有依据但未纳入正文、或经核实不成立的意见，供后续修订参考。处置依据见第十一章 11.2.9（第 1 轮）、11.2.10（第 2 轮）与 11.2.11（第 3 轮）。

十、参考资料 #

一手/官方来源（A 级） #

• Amazon Bedrock AgentCore is now generally available（AWS 官方博客）
• Amazon Bedrock AgentCore Release Notes（AWS 官方文档）
• Azure AI Gateway 层级（预览）概述（Microsoft Learn）
• Quickstart: Create an AI Gateway tier (preview) instance（Microsoft Learn）
• Expanding agent governance with Unity AI Gateway（Databricks 官方博客）
• AI Gateway is generally available（Cloudflare 官方博客）
• Linux Foundation Announces the Formation of the Agentic AI Foundation（LF 官方新闻稿）
• Higress（CNCF 官方项目页）
• Higress v1.4.0（GitHub Release）
• F5 Introduces AI Gateway（F5 官方新闻稿）
• Kong Open Sources New AI Gateway（Kong 官方新闻稿）
• Security Update: Suspected Supply Chain Incident（LiteLLM 官方安全公告）
• How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM（Snyk）
• MCP STDIO Design Flaw Enables Systemic AI Supply Chain RCE（CSA 官方研究笔记）
• Donating the Model Context Protocol and establishing the Agentic AI Foundation（Anthropic 官方新闻稿）
• Zenlayer 发布 AI 网关产品（Zenlayer 官方新闻稿；链接格式沿用原版，可访问）
• Kong Gateway 3.14 发布（Kong 官方博客）
• New tools for building agents（OpenAI 官方）
• Higress Joins CNCF: Delivering an enterprise-grade AI gateway（CNCF 官方博客，2026-03-25）

计量·定价·额度治理专题一手来源（A 级） #

• 倍率设置（New API 官方文档）
• Budgets, Rate Limits（LiteLLM 官方文档）
• Budget Reset Times and Timezones（LiteLLM 官方文档）
• Semantic Caching（LiteLLM 官方文档）
• MCP Overview（LiteLLM 官方文档）
• MCP Permission Management（LiteLLM 官方文档）
• Enforce Budget Limits and Rate Limits for Your API Keys（Portkey 官方文档）
• Budget and Limits（Bifrost 官方文档）
• AI Quota Management（Higress 官方插件文档）
• AI Rate Limiting Advanced（Kong 官方插件文档）
• Usage-based Rate Limiting（Agent Router 官方文档）
• Envoy AI Gateway is becoming Agent Router（Agent Router 官方公告）
• Agent Router（AAIF 官方项目页）
• Grant（OpenMeter 官方文档）
• Wallets and prepaid credits（Lago 官方文档）
• Set up billing credits（Stripe 官方实现指南）
• mcp-bridge（Apache APISIX 官方插件文档，已标记 deprecated）
• MCP Specification 2026-07-28 Key Changes（MCP 官方变更日志）
• From Similarity to Vulnerability: Key Collision Attack on LLM Semantic Caching（arXiv 2601.23088）
• new-api #5690 配额扣减 TOCTOU 竞态（项目公开 issue）
• one-api #2440 Quota consumption TOCTOU race（项目公开 issue）
• litellm #27735 虚拟密钥预算 stale spend（项目公开 issue）
• litellm #29576（项目公开 issue，见 9.1 #33）
• litellm #25432（项目公开 issue，见 9.1 #33）
• new-api #7241 流式 responses 丢失 usage（项目公开 issue）

产品事实与法规核验一手来源（A 级） #

• New API LICENSE（AGPL-3.0，官方仓库）
• agentgateway Introduction（官方文档）
• 《生成式人工智能服务管理暂行办法》（国家网信办官网原文）
• MCP 2026-07-28 Key Changes（官方变更说明）
• Automatic Prefix Caching（vLLM 官方文档，含 Limits）
• Redis Replication（官方文档，一致性边界）

私有化算力池与推理调度专题一手来源（A 级） #

• Gateway API Inference Extension 项目主页（Kubernetes SIG 官方）
• InferencePool API（Kubernetes SIG 官方）
• InferenceObjective API（alpha，Kubernetes SIG 官方）
• Flow Control 指南（Kubernetes SIG 官方）
• llm-d Architecture（项目官方文档）
• llm-d flow control: Priority queuing for shared GPU inference（Red Hat 开发者博客，项目贡献方）
• Master KV cache aware routing with llm-d（Red Hat 开发者博客）
• KV Cache Aware Routing / Router Guide（NVIDIA Dynamo 官方文档）
• Disaggregated Serving（NVIDIA Dynamo 官方文档）
• Production Metrics（vLLM 官方文档，v0.6.x 口径）
• Metrics 设计（vLLM 官方文档，latest）
• Cluster Queue 概念（Kueue 官方文档）
• Inside the LLM Call: GenAI Observability with OpenTelemetry（OTel 官方博客）
• OpenTelemetry GenAI 语义约定仓库（迁移后维护地）

v5.2 新增与复核的一手来源（A 级，2026-10-17 访问） #

• Assistants migration guide（OpenAI 官方，含 2026-08-26 下线说明）
• Migrate to the Responses API（OpenAI 官方）
• OpenAI API（OpenAI 官方博客，2020-06-11）
• Alphabet 2026 Q2 Earnings Call Transcript（Alphabet IR，2026-07-22）
• v1.80.8-stable - Introducing A2A Agent Gateway（LiteLLM 官方发布记录）
• GHSA-7hp6-4w63-5g45（LiteLLM 官方安全公告，2026-09-30）
• GHSA-g5ff-637f-6q2m（LiteLLM 官方安全公告，2026-10-01）
• Introducing LiteAdmin MCP（LiteLLM 官方博客，2026-09-23）
• Auto Router（LiteLLM 官方文档）
• Kong Acquires OpenMeter（Kong 官方新闻稿，2025-09-03）
• Kong AI Gateway Changelog（Kong 官方文档）
• Kong AI Gateway 2.2 公告（Kong 官方新闻稿，2026-09-30）
• Agent Router joins AAIF（AAIF 官方博客，2026-09-09）
• agentgateway CHARTER（项目章程）
• Wallet and Subscriptions（New API 官方文档）
• MCP 2026-07-28 Release Candidate（MCP 官方博客，2026-05-21）
• MCP Authorization，2025-06-18（MCP 官方规范）
• The Mother of All AI Supply Chains（OX Security 官方博客，2026-04-15）
• Monetization Gateway closed beta（Cloudflare 官方 changelog，2026-09-30）
• Designing MCP Gateway（Uber 工程博客，2026-10-01）
• Agentic Inference（NVIDIA Dynamo 开发版文档）
• Agent Hints（NVIDIA Dynamo v1.5.1 官方文档，v5.3 补核）
• Full-Stack Optimizations for Agentic Inference with NVIDIA Dynamo（NVIDIA 技术博客，2026-04-17，v5.3 补核）
• Unity Gateway release notes（Databricks 官方文档，v5.3 补核）
• llm-d 1.0 Release Tracking #2619（llm-d 官方仓库）
• Metrics 设计（vLLM 官方文档，latest，V1 指标口径）
• InferencePool（GIE 官方 API 文档，v1）
• Migrate GKE Inference Gateway from v1alpha2 to v1（Google Cloud 官方文档）
• Lago（官方仓库，AGPL-3.0）
• Portkey AI Gateway（官方仓库，MIT）
• GNU Affero General Public License v3

二手来源（B/C 级，已用于交叉参考） #

• 新华鲜报｜引导AI发展！网络安全法完成修改（新华网，2025-10-28）

• 《人工智能生成合成内容标识办法》发布（新华网，2025-03-14）

• Kong OSS container/docker image release for 3.10.0（Kong GitHub Discussions，社区讨论，待核）

• OpenTelemetry GenAI Semantic Conventions Explained（Dash0，2026-09-14 更新）

• Azure API Management Adds Dedicated AI Gateway Tier（InfoQ）

• AI Gateway:从API网关到AI应用核心中间件的演进与实践（CSDN）

• GenAI网关平台发展驶入快车道（CSDN）

• 企业级 AI 网关全景图（CSDN）

• AI 网关（Newton Wiki）

• Best Open Source AI Gateway in 2026（dev.to）

• AI Gateways Explained（Zooz Engineering）

• The LLM Gateway & Router Index (2026)（DEV Community 内容的第三方镜像域名，非原站）

• AI网关简单介绍（博客园）

• Best 7 Open Source AI Gateways in 2026（Future AGI）

• 大模型基础设施工程：大模型网关（掘金）

• Higress AI 网关（官网）

• Scaling MCP: From a Proxy to an Agent Gateway（agentgateway）

• MCP Gateway（exploreagentic.ai）

• Best Agent Gateways for Tool Calling at Scale（MintMCP）

• MCP vs API Gateways: 3-Phase Roadmap（LinkedIn）

• AWS AgentCore + Databricks Integration（ChatForest）

• 大模型服务网关架构深度解析（CSDN）

• 深入解析 AI Gateway（Jimmy Song）

• LLM Gateway Architecture（ai-solutions.wiki）

• API 网关十五年演进（今日头条）

• Amazon Bedrock AgentCore: Production AI Agents Made Simple（AWS Builder Center）