最近半年我集中帮几家公司搭企业级 AI 服务层几乎每一次都被同样的问题卡住模型调用已经散落到各个业务应用里研发团队张口就是“我直接用 OpenAI 不行吗”成本和安全却没人说得清。直到我认真研究了 TrueFoundry 这套平台在企业 AI 落地上的 Gateway 设计思路才意识到企业 AI 要的网关和传统后端接口的网关根本不是一回事——它需要把“接入”“模型路由”“策略治理”这三个层次拆开设计也就是所谓的三层 Gateway 治理。这篇文章我会结合真实落地场景和 TrueFoundry 这类平台带给我的启发把三层 Gateway 各自该管什么、不该管什么、怎么联动、落地时有哪些常见坑逐层拆开讲透。如果你是做 AI 平台基建、后端架构演进或者正在纠结“到底上不上网关、上几层网关”的团队负责人这篇应该能帮你省掉不少试错时间。1. 先看一个反面案例AI 平台迅猛上线之后的网关失控1.1 失控的信号账单、故障与审计需求同时爆发我说的那家公司是典型的电商场景半年内 50 多个业务方接入了 AI 能力从商品文案生成、客服摘要到智能推荐全都要调大模型。当时为了“快”每个业务团队各自拿了一套模型供应商的 API KeyOpenAI、Anthropic、国内闭源模型、本地私有化部署模型全都有。表面上看业务确实跑起来了但问题在第二个月集中爆发。首先是成本财务拿到账单之后整个人是懵的好几张卡都在扣费哪个部门花的、哪个应用花的、调的是哪个模型完全对不上账。然后是故障某一家的限流策略突然收紧结果十几个业务方同时报错因为大家都直连同一个供应商谁也没有兜底。最后安全团队介入要求给出“谁能调模型、调到哪个模型、数据去了哪里”的完整证据链这一下直接卡住了整个项目的投产验收。这个过程的本质是业务扩张速度跑赢了基础设施治理速度。AI 能力一旦被业务引用起来调用方会指数级增长而网关如果还停留在“每个业务自己接”的阶段后面补账、补权限、补监控的成本会非常高。1.2 一次供应商限流引发的“全网大堵车”让我把故障链路再说细一点因为这类故障特别典型。那天下午某模型供应商对某个 Key 的并发做限流正常情况下限流只会影响调用它的那一个业务。但问题是当时所有业务方都拿着各自的 Key 直连同一个供应商的同一个模型限流一触发失败请求开始在应用层疯狂重试。重试又占满了供应商侧本来就紧张的配额于是更多请求触发限流形成循环。更麻烦的是排查时没有一个统一的入口可以看到“当前到底哪些服务在调模型、全局 QPS 是多少、哪些 Key 已经到量”。各个团队只能翻自己的日志最后花了三个多小时才定位到是供应商侧的配额问题而不是代码 Bug。这起事件之后我帮他们做了第一次收敛把模型调用的南北向流量全部收口到一个统一的接入层。但很快我又发现只有接入层还不够后面模型路由和策略治理的问题会跟着浮出来。1.3 反面案例给我们的三个启示复盘下来我觉得有三个启示是可复用的几乎适用于所有准备认真做企业 AI 基础设施的团队第一模型供应商的鉴权信息和访问入口必须收敛不能让每个业务自己保存 Key。否则权限、配额、成本全都散落在外等于把大门钥匙复制给了所有人。第二模型调用不能和业务代码强绑定。业务方只应该面向一个内部稳定的接口编程至于底层是 OpenAI 还是本地私有化模型应该由网关层动态决定而不是写死在代码里。第三安全、成本、合规这些治理规则必须是一层独立的东西不能靠“大家自觉遵守”。谁有权限用商业模型、哪些数据能不能出域这类规则如果散落在各个业务团队里最终结果一定是失控。2. 第一层 Gateway把“谁能进、从哪进、进来多少”管明白的接入层2.1 接入层管什么以及它和传统 API 网关的关系三层 Gateway 里的第一层我习惯叫它“接入层”。它的职责非常明确统一 AI 服务对外暴露的入口解决“谁能进、从哪进、进来多少”这三个问题。这里的“谁能进”指的是用户的身份认证和应用的身份认证“从哪进”指的是只允许通过统一入口调用 AI不允许业务绕过网关直连模型供应商“进来多少”则是全局的流量控制与初步限流。很多团队会问这一层和我们现有的 API 网关比如 Nginx、Kong、APISIX、Spring Cloud Gateway是不是重复了我的答案是不要重复造轮子首选方案是复用现有 API 网关能力把 AI 模型服务作为其中一类路由暴露出去。比如你公司已经有一套基于 Kong 的南北向网关那就直接在它上面新加一个llm-gateway的服务路由负责接收所有模型调用请求。这套网关既完成了 TLS 终结、OIDC 认证、API Key 校验这些基础工作也让你不需要额外引入一套新系统。在 TrueFoundry 的设计里这类平台通常会把网关组件直接嵌在 Kubernetes 集群内对外暴露统一的 LoadBalancer 类型服务然后配合现有云厂商的负载均衡器或 Ingress Controller 一起工作。你既可以用平台默认网关也可以把它挂在你已有网关的后端关键原则是流量必须经过至少一道统一入口。2.2 接入层最容易忽略的两件事身份透传与原始请求留痕如果只看功能列表接入层和普通 API 网关几乎一样。但实际落地时有两件小事特别容易被忽略一旦忽略后面两层 Gateway 就变成了“瞎子”。第一件是身份透传。接入层完成用户认证之后不能只在网关这层验证一下就丢弃身份信息必须把用户 ID、应用 ID、租户 ID、部门归属这些信息通过标准请求头例如X-User-Id、X-App-Id、X-Tenant-Id透传给下游的第二层和第三层。为什么因为第二层的模型路由策略、第三层的权限与配额判断都依赖这些身份维度。第二件是原始请求留痕。接入层应该对每一次“谁在什么时候调用了哪个模型、传入的 prompt 大概是什么量级、返回了多大响应”做全量结构化日志。这里不需要保存完整 prompt 正文可能会涉及隐私和存储成本但必须保存元数据请求 ID、用户、应用、模型名、Token 数、响应状态、耗时。这类日志在故障排查和审计上的价值是巨大的。我见过不少事故最后能快速定位靠的就是接入层的这一份“日志交通记录”。反过来如果少了这层留痕后面第二层、第三层再怎么治理排查问题都只能靠猜。2.3 一个最小可用的接入层配置长什么样如果你从头开始搭我建议你在接入层围绕四条规则来设计不复杂但非常有效。只暴露一个或少数几个模型接入端点比如POST /v1/chat/completions业务方只面对这一个内部契约。所有请求必须携带内部 API Key 或通过 OAuth2 网关认证不带身份直接拒绝。开启全局基础限流比如按应用维度限制每分钟最大请求数防止某个业务方异常流量拖垮全局。把请求 ID 透传到下游并记录全量访问日志。这里我用一段简单的思路伪代码来说明接入层路由的逻辑它不是某个具体产品的配置而是这一类系统普遍要表达的意图POST /v1/chat/completions - 接入层 - 认证鉴权校验 API Key / OAuth2 Token - 解析身份上下文User / App / Tenant - 基础限流App 维度 QPS 阈值 ? reject : pass - 记录访问日志请求ID、用户、模型、Token数、状态 - 转发给下一层带上身份透传请求头我一直强调一个原则接入层只管“这一层该管的”不要去写模型路由逻辑也不要去判断某个模型能不能被某个部门使用。把这些逻辑下沉到后面两层接入层才能保持稳定和简单。3. 第二层 Gateway模型路由与容错这才是 AI 网关真正不同的地方3.1 为什么说模型网关不是“代理”第二层是整个三层框架的核心也是与传统 API 网关差异最大的地方。我习惯叫它“模型层网关”或者直接用 Model Gateway 这个词。普通的反向代理核心能力是 URL 转发、负载均衡、超时重试它不关心你传过去的报文到底是什么语义。但模型网关面对的不是普通 JSON 报文而是带上下文、带 Token 计费、带流式响应的大模型调用协议。这里有一个关键认知转变模型网关本质上是一个“协议转换层 路由决策层 容错层”。协议转换的含义是业务方不需要关心上游是 OpenAI 的接口格式、Anthropic 的 Messages 格式还是本地 vLLM 部署模型的 OpenAI 兼容格式。模型网关会把内部统一请求格式转换成对应供应商的格式再把响应统一包装返回。这样业务代码里就永远不会出现某个模型供应商特有的字段。路由决策层则意味着网关需要根据预设策略来决定当前这个请求应该发给哪个模型。这里我用一个表格给你看传统 API 网关和模型网关的差异这样对比更直观维度传统 API Gateway模型网关Model Gateway路由粒度URL / Service模型名称 / 供应商 / 模型版本鉴权粒度应用级、用户级应用级、用户级、模型级、租户级限流单位QPS、并发连接Token 消耗、上下文长度、并发请求数容错手段超时重试、熔断模型级故障转移、降级、语义兜底缓存HTTP 缓存URL 粒度语义缓存向量相似度匹配可观测性HTTP 状态码、耗时Token 消耗、成本金额、模型质量指标看完这张表你会发现模型网关关心的不只是“这个请求能不能通”还包括“这个请求花了多少钱、结果质量够不够好、上游挂了能不能优雅降级”。3.2 模型网关的核心能力拆解我把模型网关拆成五个必须打磨的能力每一项都是我在实际项目中反复踩坑后总结出来的。第一个能力是供应商适配。这是基础中的基础。网关内部定义一个统一的 chat completion 结构由适配器层负责把结构转换成 OpenAI、Anthropic、AWS Bedrock、本地私有化模型的真实请求。这样业务方、策略层、可观测系统都只认一种格式所有差异化都被隔离在适配器里。第二个能力是动态路由策略。网关要支持按规则把不同请求分发到不同模型。最常见的路由维度包括按用户或部门比如 A 团队只能用成本较低的模型、按请求类型比如分析类任务走更强的模型闲聊类走轻量模型、按成本优先级当预算吃紧时自动把非核心流量切到便宜模型。TrueFoundry 这类平台在模型注册表里会把模型按名称、版本、供应商、支持的业务标签录入路由规则就可以直接引用这些元数据不需要在代码里硬编码。第三个能力是 Fallback 容错链。这个能力在真正生产环境里比想象中重要。你必须能配置一条容错链比如主用模型是 GPT-4o如果它限流或超时自动切换到 ClaudeClaude 也失败再降级到本地部署的 Qwen。这条容错链要支持每跳的超时时间、重试次数和退避策略。我记得在电商公司的案例里他们后来给客服摘要场景配的就是“商业模型为主、开源模型为兜底”的策略结果某次商业模型供应商故障网关自动把所有流量切到私有化模型业务几乎没有感知。这就是 Fallback 的价值——它不是锦上添花是生产刚需。第四个能力是语义缓存。大模型调用成本高、耗时长很多重复性请求其实可以命中缓存。语义缓存和传统缓存的区别在于它不要求 prompt 完全一致而是通过 embedding 向量计算相似度当相似度超过阈值时直接返回缓存中的历史结果。这在客服问答、文档问答这类场景里效果非常明显缓存命中率能到百分之二三十成本直接就降下来了。但要注意动态类内容、有时间敏感性的请求要跳过缓存否则回答会显得很“旧”。第五个能力是 Token 级配额与并发控制。传统网关限流是按 QPS但 AI 调用成本的核心变量是 Token。模型网关要支持按用户、部门、应用维度设置月度 Token 配额以及单请求的最大 Token 上限、单并发数上限。否则很容易出现“一个异常循环程序在半天内把整个月的预算烧光”的极端事件。3.3 TrueFoundry 在这一层的设计思路给我的启发我在看 TrueFoundry 的架构时印象最深的一点是它把“模型部署”和“模型接入”做了很好的解耦。很多团队自己搭模型网关时会把 “路由规则” 和 “具体服务实例” 强耦合网关里写死了上游地址。而 TrueFoundry 的思路是通过所谓 Connection 来管理模型供应商密钥通过 Gateway Routes 来声明式地描述“哪个模型、哪个版本、通过哪个供应商提供服务”。这样带来的好处是上游地址变迁、模型版本升级、密钥轮换都可以通过配置变更完成不需要改代码。在 TrueFoundry 的控制台上模型注册表和网关配置是分开的你可以先把同一种模型注册多个供应商来源然后在路由规则里按权重或优先级引用它们。如果你是自己动手用开源组件搭模型网关我非常建议参考这个思路把“模型目录”有哪些模型可用和“路由规则”怎么把流量分给这些模型彻底拆开。这两者的生命周期完全不同——模型目录跟着供应商和部署走路由规则跟着业务需求走混在一起只会让变更越来越难。4. 第三层 Gateway面向安全、成本与合规的策略治理面4.1 为什么必须有一层独立的策略治理聊到第三层很多架构师会问接入层已经做了认证和限流模型层已经做了路由和成本控制为什么还要单独一层策略治理是不是多此一举答案在于前两层解决的是“技术可行性”第三层解决的是“组织治理”。举个例子。接入层能确认“张三通过了认证”但认证通过不等于张三有权调用 GPT-4也不等于张三可以在这里传输用户手机号。这个“允许做什么、不允许做什么”的评价必须由一个独立于技术路由的治理层来执行。用生活化的类比来说接入层是小区门卫确认你刷了卡模型层是楼栋管家帮你安排电梯、楼层的落点而策略治理层是物业公司的规章制度——你刷了卡也不代表你能进每一栋楼更不代表你可以在小区里随便做什么事。如果策略治理逻辑写在接入层网关会被各种业务规则塞满每一个规则变更都要动路由配置风险极高。如果写在模型层会导致模型路由逻辑无法专注一改模型策略就影响全链路。所以独立分层不只是为了“好看”而是为了降低每个层次的复杂度和变更频率。4.2 策略治理层要重点落地的四类规则我在真实项目里一般会把第三层要管的规则归成四类你可以直接照着这个框架去梳理自己企业内部的治理需求。第一类模型访问权限矩阵。明确什么人、什么部门、什么应用可以调用哪些模型。比如普通客服人员只能用内部微调过的 7B 模型算法团队才可以用商业强模型涉及未上线商品数据的请求只允许走私有化部署模型。这张矩阵不是技术路由它是企业级的授权结果通常由安全团队和业务负责人共同制定。第二类数据出域与脱敏检测。外部模型调用意味着数据会离开企业边界治理层必须对出域内容做检查。具体做法是在请求进入模型网关之前用规则或模型检测敏感字段身份证号、手机号、银行卡、密钥 token、源代码片段等命中规则后可以拒绝出域也可以先脱敏再放行。这一块在金融、医疗、零售行业尤其重要。第三类提示注入与输出合规检测。大模型输入输出本身存在安全风险比如恶意 prompt 可能诱导模型越权输出不当内容。策略治理层可以在请求进入上游模型前做一次输入检查判断是否存在提示注入模式在返回结果给调用方前做一次输出合规检查过滤有害内容。这两道检查是模型层难以独立完成的因为在技术上它们不属于“路由”问题属于“内容安全”问题。第四类成本归属与预算报告。模型网关负责记账但记账之后如何分摊成本、如何设置预算警戒线是治理层的事。 你应该能做到每个月自动生成一份“各部门、各应用模型调用成本报表”某个部门预算快用尽时自动降级其模型等级或发出告警。没有第三层成本数据只是一堆日志有了第三层成本数据才能变成管理动作。4.3 三层协同的完整调用链路长什么样到这里三层 Gateway 各自的职责就清楚了但更重要的是它们如何串联成一条完整的调用链。我给你梳理一下一个典型请求经过三层网关的完整路径方便你对照自己架构去检查遗漏业务应用发起请求到达接入层。接入层完成认证、基础限流解析出用户、应用、租户身份生成全局唯一的请求 ID。请求带着身份上下文进入第三层策略治理层。治理层先查权限矩阵判断这个用户能不能使用目标模型然后执行数据出域检查必要时脱敏或拦截再检查预算配额确认该部门还有额度。通过治理层之后请求进入第二层模型网关层。模型层按路由策略选择最优模型做适配器转换把请求发给选中的上游模型。如果上游失败按 Fallback 链自动切换。上游模型返回结果后再次经过第三层做输出内容合规检查同时把 Token 消耗和成本金额记录到该部门账下。最终响应回到接入层接入层把完整调用链路的日志写入审计存储然后把结果返回给业务应用。这条链路我建议你用一张大图贴在研发团队墙上因为几乎所有排查都会沿着这条链路逐段定位问题。哪一段没实现哪一段就是漏洞。5. 三层 Gateway 落地常见误区与一条可执行的路线5.1 误区一把三层当成三个独立系统来建设我见过不少团队在理解了分层架构之后立刻开始三个独立项目的招标接入层用 APISIX、模型层自研、治理层买一套安全系统最后发现集成成本比建设成本还高。三层 Gateway 首先是一种职责边界的划分不一定要是三个物理系统。在 TrueFoundry 这类平台上它通过一个统一控制面管理 Gateway三层能力是在同一个网关组件内部的不同阶段实现的。你自己动手做也一样可以先在一套程序里划分三个模块接入认证模块、模型路由模块、策略执行模块。先把边界定义清楚再决定哪些能力需要独立的服务。我推荐的做法是逻辑上严格分层物理部署可以先合并。等某一层的性能瓶颈或团队分工明确之后再把它独立拆出去。过早拆分只会让你同时面对分布式系统的所有复杂度。5.2 误区二把全部策略做完再放量结果遥遥无期企业 AI 平台最容易拖延的模式是安全团队梳理了 100 多条治理规则要求全部落地才允许上线。结果平台迟迟无法交付业务方等不及绕道自建治理彻底失效。正确的姿势是分阶段渐进式上线。第一批只需要两条治理规则模型访问权限矩阵和月度成本配额。先保证模型调用“可管、可控、可计量”再逐步加入脱敏、提示注入检测、输出合规等更复杂的能力。这样做的好处是几个星期就能让业务方用起来治理层也能够在真实流量的压力下迭代完善。5.3 可执行的落地路线从第一层和第二层开始如果你想在自己的团队落地这套架构我建议按三个检查项去看落地路径。第一个检查项你的模型调用入口是否已经统一如果还没有优先把接入层搭建起来让所有业务方都通过网关调用大模型。这一阶段不做复杂路由能够统一鉴权和留痕就足够。第二个检查项你是否已经做到模型切换不影响业务代码如果做不到说明模型网关层还没落地。你需要尽快把模型注册表和路由规则建起来至少支持“把一个模型从主用降级到备用”这种动作在配置端完成而不是改代码。第三个检查项你的财务、安全、合规是否都建立在元数据之上如果成本报表还是要从各个供应商控制台手工下载说明治理层还没做功。你需要从模型网关的 Token 计费数据出发生成第一版按部门分摊的成本报告。为了让你更直观地判断当前进展我建议用这个表做个自检当前阶段核心问题可以接受的标志阶段 1我们有多少应用在调模型所有模型流量都经过接入层日志可查阶段 2模型切换能不能不改代码路由规则在配置面完成Fallback 生效阶段 3每个部门的模型成本是多少成本报表按部门自动生成权限矩阵在线可查阶段 4数据出域是否受控敏感内容脱敏和提示注入检测已在治理层生效每家公司进入 AI 规模化的时点不同但几乎都会落到这四步上。早一步识别自己处在哪个阶段就能少走不少弯路。5.4 最后一层提醒别让“治理”变成“制肘”三层 Gateway 治理确实会引入一些执行开销这是必要的成本但要警惕把接入流程弄到让研发团队无法接受。一个应用接入 AI 能力如果从申请 Key 到拿到可用环境要两三周治理就变成了变相的阻断。我自己的经验是给研发提供“自助式接入”在治理层界面上自己申请应用凭证、自己选择可用模型范围、配额默认给出一档基础值超过再走审批。把治理做成基础设施的一部分而不是一个办事窗口。好的治理应该让 90% 的常规请求无感放行只在 10% 的异常和敏感场景里发挥拦截作用。落到这一层之后你会发现企业 AI 平台的三层 Gateway 其实没有想象中那么神它就是一套把“入口、路由、规矩”分清楚的工程实践。越早按这个框架收口后面越不用为散落的 Key、失控的账单和说不清的数据流向熬夜救火。
企业AI落地必备：三层Gateway治理实战指南
最近半年我集中帮几家公司搭企业级 AI 服务层几乎每一次都被同样的问题卡住模型调用已经散落到各个业务应用里研发团队张口就是“我直接用 OpenAI 不行吗”成本和安全却没人说得清。直到我认真研究了 TrueFoundry 这套平台在企业 AI 落地上的 Gateway 设计思路才意识到企业 AI 要的网关和传统后端接口的网关根本不是一回事——它需要把“接入”“模型路由”“策略治理”这三个层次拆开设计也就是所谓的三层 Gateway 治理。这篇文章我会结合真实落地场景和 TrueFoundry 这类平台带给我的启发把三层 Gateway 各自该管什么、不该管什么、怎么联动、落地时有哪些常见坑逐层拆开讲透。如果你是做 AI 平台基建、后端架构演进或者正在纠结“到底上不上网关、上几层网关”的团队负责人这篇应该能帮你省掉不少试错时间。1. 先看一个反面案例AI 平台迅猛上线之后的网关失控1.1 失控的信号账单、故障与审计需求同时爆发我说的那家公司是典型的电商场景半年内 50 多个业务方接入了 AI 能力从商品文案生成、客服摘要到智能推荐全都要调大模型。当时为了“快”每个业务团队各自拿了一套模型供应商的 API KeyOpenAI、Anthropic、国内闭源模型、本地私有化部署模型全都有。表面上看业务确实跑起来了但问题在第二个月集中爆发。首先是成本财务拿到账单之后整个人是懵的好几张卡都在扣费哪个部门花的、哪个应用花的、调的是哪个模型完全对不上账。然后是故障某一家的限流策略突然收紧结果十几个业务方同时报错因为大家都直连同一个供应商谁也没有兜底。最后安全团队介入要求给出“谁能调模型、调到哪个模型、数据去了哪里”的完整证据链这一下直接卡住了整个项目的投产验收。这个过程的本质是业务扩张速度跑赢了基础设施治理速度。AI 能力一旦被业务引用起来调用方会指数级增长而网关如果还停留在“每个业务自己接”的阶段后面补账、补权限、补监控的成本会非常高。1.2 一次供应商限流引发的“全网大堵车”让我把故障链路再说细一点因为这类故障特别典型。那天下午某模型供应商对某个 Key 的并发做限流正常情况下限流只会影响调用它的那一个业务。但问题是当时所有业务方都拿着各自的 Key 直连同一个供应商的同一个模型限流一触发失败请求开始在应用层疯狂重试。重试又占满了供应商侧本来就紧张的配额于是更多请求触发限流形成循环。更麻烦的是排查时没有一个统一的入口可以看到“当前到底哪些服务在调模型、全局 QPS 是多少、哪些 Key 已经到量”。各个团队只能翻自己的日志最后花了三个多小时才定位到是供应商侧的配额问题而不是代码 Bug。这起事件之后我帮他们做了第一次收敛把模型调用的南北向流量全部收口到一个统一的接入层。但很快我又发现只有接入层还不够后面模型路由和策略治理的问题会跟着浮出来。1.3 反面案例给我们的三个启示复盘下来我觉得有三个启示是可复用的几乎适用于所有准备认真做企业 AI 基础设施的团队第一模型供应商的鉴权信息和访问入口必须收敛不能让每个业务自己保存 Key。否则权限、配额、成本全都散落在外等于把大门钥匙复制给了所有人。第二模型调用不能和业务代码强绑定。业务方只应该面向一个内部稳定的接口编程至于底层是 OpenAI 还是本地私有化模型应该由网关层动态决定而不是写死在代码里。第三安全、成本、合规这些治理规则必须是一层独立的东西不能靠“大家自觉遵守”。谁有权限用商业模型、哪些数据能不能出域这类规则如果散落在各个业务团队里最终结果一定是失控。2. 第一层 Gateway把“谁能进、从哪进、进来多少”管明白的接入层2.1 接入层管什么以及它和传统 API 网关的关系三层 Gateway 里的第一层我习惯叫它“接入层”。它的职责非常明确统一 AI 服务对外暴露的入口解决“谁能进、从哪进、进来多少”这三个问题。这里的“谁能进”指的是用户的身份认证和应用的身份认证“从哪进”指的是只允许通过统一入口调用 AI不允许业务绕过网关直连模型供应商“进来多少”则是全局的流量控制与初步限流。很多团队会问这一层和我们现有的 API 网关比如 Nginx、Kong、APISIX、Spring Cloud Gateway是不是重复了我的答案是不要重复造轮子首选方案是复用现有 API 网关能力把 AI 模型服务作为其中一类路由暴露出去。比如你公司已经有一套基于 Kong 的南北向网关那就直接在它上面新加一个llm-gateway的服务路由负责接收所有模型调用请求。这套网关既完成了 TLS 终结、OIDC 认证、API Key 校验这些基础工作也让你不需要额外引入一套新系统。在 TrueFoundry 的设计里这类平台通常会把网关组件直接嵌在 Kubernetes 集群内对外暴露统一的 LoadBalancer 类型服务然后配合现有云厂商的负载均衡器或 Ingress Controller 一起工作。你既可以用平台默认网关也可以把它挂在你已有网关的后端关键原则是流量必须经过至少一道统一入口。2.2 接入层最容易忽略的两件事身份透传与原始请求留痕如果只看功能列表接入层和普通 API 网关几乎一样。但实际落地时有两件小事特别容易被忽略一旦忽略后面两层 Gateway 就变成了“瞎子”。第一件是身份透传。接入层完成用户认证之后不能只在网关这层验证一下就丢弃身份信息必须把用户 ID、应用 ID、租户 ID、部门归属这些信息通过标准请求头例如X-User-Id、X-App-Id、X-Tenant-Id透传给下游的第二层和第三层。为什么因为第二层的模型路由策略、第三层的权限与配额判断都依赖这些身份维度。第二件是原始请求留痕。接入层应该对每一次“谁在什么时候调用了哪个模型、传入的 prompt 大概是什么量级、返回了多大响应”做全量结构化日志。这里不需要保存完整 prompt 正文可能会涉及隐私和存储成本但必须保存元数据请求 ID、用户、应用、模型名、Token 数、响应状态、耗时。这类日志在故障排查和审计上的价值是巨大的。我见过不少事故最后能快速定位靠的就是接入层的这一份“日志交通记录”。反过来如果少了这层留痕后面第二层、第三层再怎么治理排查问题都只能靠猜。2.3 一个最小可用的接入层配置长什么样如果你从头开始搭我建议你在接入层围绕四条规则来设计不复杂但非常有效。只暴露一个或少数几个模型接入端点比如POST /v1/chat/completions业务方只面对这一个内部契约。所有请求必须携带内部 API Key 或通过 OAuth2 网关认证不带身份直接拒绝。开启全局基础限流比如按应用维度限制每分钟最大请求数防止某个业务方异常流量拖垮全局。把请求 ID 透传到下游并记录全量访问日志。这里我用一段简单的思路伪代码来说明接入层路由的逻辑它不是某个具体产品的配置而是这一类系统普遍要表达的意图POST /v1/chat/completions - 接入层 - 认证鉴权校验 API Key / OAuth2 Token - 解析身份上下文User / App / Tenant - 基础限流App 维度 QPS 阈值 ? reject : pass - 记录访问日志请求ID、用户、模型、Token数、状态 - 转发给下一层带上身份透传请求头我一直强调一个原则接入层只管“这一层该管的”不要去写模型路由逻辑也不要去判断某个模型能不能被某个部门使用。把这些逻辑下沉到后面两层接入层才能保持稳定和简单。3. 第二层 Gateway模型路由与容错这才是 AI 网关真正不同的地方3.1 为什么说模型网关不是“代理”第二层是整个三层框架的核心也是与传统 API 网关差异最大的地方。我习惯叫它“模型层网关”或者直接用 Model Gateway 这个词。普通的反向代理核心能力是 URL 转发、负载均衡、超时重试它不关心你传过去的报文到底是什么语义。但模型网关面对的不是普通 JSON 报文而是带上下文、带 Token 计费、带流式响应的大模型调用协议。这里有一个关键认知转变模型网关本质上是一个“协议转换层 路由决策层 容错层”。协议转换的含义是业务方不需要关心上游是 OpenAI 的接口格式、Anthropic 的 Messages 格式还是本地 vLLM 部署模型的 OpenAI 兼容格式。模型网关会把内部统一请求格式转换成对应供应商的格式再把响应统一包装返回。这样业务代码里就永远不会出现某个模型供应商特有的字段。路由决策层则意味着网关需要根据预设策略来决定当前这个请求应该发给哪个模型。这里我用一个表格给你看传统 API 网关和模型网关的差异这样对比更直观维度传统 API Gateway模型网关Model Gateway路由粒度URL / Service模型名称 / 供应商 / 模型版本鉴权粒度应用级、用户级应用级、用户级、模型级、租户级限流单位QPS、并发连接Token 消耗、上下文长度、并发请求数容错手段超时重试、熔断模型级故障转移、降级、语义兜底缓存HTTP 缓存URL 粒度语义缓存向量相似度匹配可观测性HTTP 状态码、耗时Token 消耗、成本金额、模型质量指标看完这张表你会发现模型网关关心的不只是“这个请求能不能通”还包括“这个请求花了多少钱、结果质量够不够好、上游挂了能不能优雅降级”。3.2 模型网关的核心能力拆解我把模型网关拆成五个必须打磨的能力每一项都是我在实际项目中反复踩坑后总结出来的。第一个能力是供应商适配。这是基础中的基础。网关内部定义一个统一的 chat completion 结构由适配器层负责把结构转换成 OpenAI、Anthropic、AWS Bedrock、本地私有化模型的真实请求。这样业务方、策略层、可观测系统都只认一种格式所有差异化都被隔离在适配器里。第二个能力是动态路由策略。网关要支持按规则把不同请求分发到不同模型。最常见的路由维度包括按用户或部门比如 A 团队只能用成本较低的模型、按请求类型比如分析类任务走更强的模型闲聊类走轻量模型、按成本优先级当预算吃紧时自动把非核心流量切到便宜模型。TrueFoundry 这类平台在模型注册表里会把模型按名称、版本、供应商、支持的业务标签录入路由规则就可以直接引用这些元数据不需要在代码里硬编码。第三个能力是 Fallback 容错链。这个能力在真正生产环境里比想象中重要。你必须能配置一条容错链比如主用模型是 GPT-4o如果它限流或超时自动切换到 ClaudeClaude 也失败再降级到本地部署的 Qwen。这条容错链要支持每跳的超时时间、重试次数和退避策略。我记得在电商公司的案例里他们后来给客服摘要场景配的就是“商业模型为主、开源模型为兜底”的策略结果某次商业模型供应商故障网关自动把所有流量切到私有化模型业务几乎没有感知。这就是 Fallback 的价值——它不是锦上添花是生产刚需。第四个能力是语义缓存。大模型调用成本高、耗时长很多重复性请求其实可以命中缓存。语义缓存和传统缓存的区别在于它不要求 prompt 完全一致而是通过 embedding 向量计算相似度当相似度超过阈值时直接返回缓存中的历史结果。这在客服问答、文档问答这类场景里效果非常明显缓存命中率能到百分之二三十成本直接就降下来了。但要注意动态类内容、有时间敏感性的请求要跳过缓存否则回答会显得很“旧”。第五个能力是 Token 级配额与并发控制。传统网关限流是按 QPS但 AI 调用成本的核心变量是 Token。模型网关要支持按用户、部门、应用维度设置月度 Token 配额以及单请求的最大 Token 上限、单并发数上限。否则很容易出现“一个异常循环程序在半天内把整个月的预算烧光”的极端事件。3.3 TrueFoundry 在这一层的设计思路给我的启发我在看 TrueFoundry 的架构时印象最深的一点是它把“模型部署”和“模型接入”做了很好的解耦。很多团队自己搭模型网关时会把 “路由规则” 和 “具体服务实例” 强耦合网关里写死了上游地址。而 TrueFoundry 的思路是通过所谓 Connection 来管理模型供应商密钥通过 Gateway Routes 来声明式地描述“哪个模型、哪个版本、通过哪个供应商提供服务”。这样带来的好处是上游地址变迁、模型版本升级、密钥轮换都可以通过配置变更完成不需要改代码。在 TrueFoundry 的控制台上模型注册表和网关配置是分开的你可以先把同一种模型注册多个供应商来源然后在路由规则里按权重或优先级引用它们。如果你是自己动手用开源组件搭模型网关我非常建议参考这个思路把“模型目录”有哪些模型可用和“路由规则”怎么把流量分给这些模型彻底拆开。这两者的生命周期完全不同——模型目录跟着供应商和部署走路由规则跟着业务需求走混在一起只会让变更越来越难。4. 第三层 Gateway面向安全、成本与合规的策略治理面4.1 为什么必须有一层独立的策略治理聊到第三层很多架构师会问接入层已经做了认证和限流模型层已经做了路由和成本控制为什么还要单独一层策略治理是不是多此一举答案在于前两层解决的是“技术可行性”第三层解决的是“组织治理”。举个例子。接入层能确认“张三通过了认证”但认证通过不等于张三有权调用 GPT-4也不等于张三可以在这里传输用户手机号。这个“允许做什么、不允许做什么”的评价必须由一个独立于技术路由的治理层来执行。用生活化的类比来说接入层是小区门卫确认你刷了卡模型层是楼栋管家帮你安排电梯、楼层的落点而策略治理层是物业公司的规章制度——你刷了卡也不代表你能进每一栋楼更不代表你可以在小区里随便做什么事。如果策略治理逻辑写在接入层网关会被各种业务规则塞满每一个规则变更都要动路由配置风险极高。如果写在模型层会导致模型路由逻辑无法专注一改模型策略就影响全链路。所以独立分层不只是为了“好看”而是为了降低每个层次的复杂度和变更频率。4.2 策略治理层要重点落地的四类规则我在真实项目里一般会把第三层要管的规则归成四类你可以直接照着这个框架去梳理自己企业内部的治理需求。第一类模型访问权限矩阵。明确什么人、什么部门、什么应用可以调用哪些模型。比如普通客服人员只能用内部微调过的 7B 模型算法团队才可以用商业强模型涉及未上线商品数据的请求只允许走私有化部署模型。这张矩阵不是技术路由它是企业级的授权结果通常由安全团队和业务负责人共同制定。第二类数据出域与脱敏检测。外部模型调用意味着数据会离开企业边界治理层必须对出域内容做检查。具体做法是在请求进入模型网关之前用规则或模型检测敏感字段身份证号、手机号、银行卡、密钥 token、源代码片段等命中规则后可以拒绝出域也可以先脱敏再放行。这一块在金融、医疗、零售行业尤其重要。第三类提示注入与输出合规检测。大模型输入输出本身存在安全风险比如恶意 prompt 可能诱导模型越权输出不当内容。策略治理层可以在请求进入上游模型前做一次输入检查判断是否存在提示注入模式在返回结果给调用方前做一次输出合规检查过滤有害内容。这两道检查是模型层难以独立完成的因为在技术上它们不属于“路由”问题属于“内容安全”问题。第四类成本归属与预算报告。模型网关负责记账但记账之后如何分摊成本、如何设置预算警戒线是治理层的事。 你应该能做到每个月自动生成一份“各部门、各应用模型调用成本报表”某个部门预算快用尽时自动降级其模型等级或发出告警。没有第三层成本数据只是一堆日志有了第三层成本数据才能变成管理动作。4.3 三层协同的完整调用链路长什么样到这里三层 Gateway 各自的职责就清楚了但更重要的是它们如何串联成一条完整的调用链。我给你梳理一下一个典型请求经过三层网关的完整路径方便你对照自己架构去检查遗漏业务应用发起请求到达接入层。接入层完成认证、基础限流解析出用户、应用、租户身份生成全局唯一的请求 ID。请求带着身份上下文进入第三层策略治理层。治理层先查权限矩阵判断这个用户能不能使用目标模型然后执行数据出域检查必要时脱敏或拦截再检查预算配额确认该部门还有额度。通过治理层之后请求进入第二层模型网关层。模型层按路由策略选择最优模型做适配器转换把请求发给选中的上游模型。如果上游失败按 Fallback 链自动切换。上游模型返回结果后再次经过第三层做输出内容合规检查同时把 Token 消耗和成本金额记录到该部门账下。最终响应回到接入层接入层把完整调用链路的日志写入审计存储然后把结果返回给业务应用。这条链路我建议你用一张大图贴在研发团队墙上因为几乎所有排查都会沿着这条链路逐段定位问题。哪一段没实现哪一段就是漏洞。5. 三层 Gateway 落地常见误区与一条可执行的路线5.1 误区一把三层当成三个独立系统来建设我见过不少团队在理解了分层架构之后立刻开始三个独立项目的招标接入层用 APISIX、模型层自研、治理层买一套安全系统最后发现集成成本比建设成本还高。三层 Gateway 首先是一种职责边界的划分不一定要是三个物理系统。在 TrueFoundry 这类平台上它通过一个统一控制面管理 Gateway三层能力是在同一个网关组件内部的不同阶段实现的。你自己动手做也一样可以先在一套程序里划分三个模块接入认证模块、模型路由模块、策略执行模块。先把边界定义清楚再决定哪些能力需要独立的服务。我推荐的做法是逻辑上严格分层物理部署可以先合并。等某一层的性能瓶颈或团队分工明确之后再把它独立拆出去。过早拆分只会让你同时面对分布式系统的所有复杂度。5.2 误区二把全部策略做完再放量结果遥遥无期企业 AI 平台最容易拖延的模式是安全团队梳理了 100 多条治理规则要求全部落地才允许上线。结果平台迟迟无法交付业务方等不及绕道自建治理彻底失效。正确的姿势是分阶段渐进式上线。第一批只需要两条治理规则模型访问权限矩阵和月度成本配额。先保证模型调用“可管、可控、可计量”再逐步加入脱敏、提示注入检测、输出合规等更复杂的能力。这样做的好处是几个星期就能让业务方用起来治理层也能够在真实流量的压力下迭代完善。5.3 可执行的落地路线从第一层和第二层开始如果你想在自己的团队落地这套架构我建议按三个检查项去看落地路径。第一个检查项你的模型调用入口是否已经统一如果还没有优先把接入层搭建起来让所有业务方都通过网关调用大模型。这一阶段不做复杂路由能够统一鉴权和留痕就足够。第二个检查项你是否已经做到模型切换不影响业务代码如果做不到说明模型网关层还没落地。你需要尽快把模型注册表和路由规则建起来至少支持“把一个模型从主用降级到备用”这种动作在配置端完成而不是改代码。第三个检查项你的财务、安全、合规是否都建立在元数据之上如果成本报表还是要从各个供应商控制台手工下载说明治理层还没做功。你需要从模型网关的 Token 计费数据出发生成第一版按部门分摊的成本报告。为了让你更直观地判断当前进展我建议用这个表做个自检当前阶段核心问题可以接受的标志阶段 1我们有多少应用在调模型所有模型流量都经过接入层日志可查阶段 2模型切换能不能不改代码路由规则在配置面完成Fallback 生效阶段 3每个部门的模型成本是多少成本报表按部门自动生成权限矩阵在线可查阶段 4数据出域是否受控敏感内容脱敏和提示注入检测已在治理层生效每家公司进入 AI 规模化的时点不同但几乎都会落到这四步上。早一步识别自己处在哪个阶段就能少走不少弯路。5.4 最后一层提醒别让“治理”变成“制肘”三层 Gateway 治理确实会引入一些执行开销这是必要的成本但要警惕把接入流程弄到让研发团队无法接受。一个应用接入 AI 能力如果从申请 Key 到拿到可用环境要两三周治理就变成了变相的阻断。我自己的经验是给研发提供“自助式接入”在治理层界面上自己申请应用凭证、自己选择可用模型范围、配额默认给出一档基础值超过再走审批。把治理做成基础设施的一部分而不是一个办事窗口。好的治理应该让 90% 的常规请求无感放行只在 10% 的异常和敏感场景里发挥拦截作用。落到这一层之后你会发现企业 AI 平台的三层 Gateway 其实没有想象中那么神它就是一套把“入口、路由、规矩”分清楚的工程实践。越早按这个框架收口后面越不用为散落的 Key、失控的账单和说不清的数据流向熬夜救火。
