1.1 开源AI网关的定义、边界与核心价值
我第一次认真琢磨“开源AI网关”这个词，是去年帮一家做在线教育的朋友收拾烂摊子。他们团队三个月里接了四家模型厂商的API，代码里到处都是硬编码的key和if-else判断。每次换模型，开发就得改一遍业务代码，运维还得跟着调防火墙规则。当时我就想，这东西缺的其实就是一层网关——夹在业务和模型之间，把脏活累活全兜住。
说直白点，开源AI网关就是一个统一的流量入口。业务方不用再关心背后接的是OpenAI、Claude还是某个私有化部署的Qwen，所有请求先打到网关，由它做鉴权、路由、限流、日志记录这些事。它跟传统API网关的区别在于，它懂“模型”这件事。传统网关只管HTTP转发，AI网关得理解token消耗、模型版本、流式响应、多模态输入这些特殊语义。边界上我认为它不该去抢业务逻辑的活，比如Prompt工程、业务规则校验这些应该留在业务层，网关只负责“把请求安全、高效、可观测地送到正确的模型那里”。
核心价值这块我感受特别深。第一是解耦，业务代码和模型供应商彻底分开，换模型像换插座一样简单。第二是成本可控，网关层能做token级别的计量和配额，哪个部门用了多少、哪个应用烧钱最快，一目了然。第三是安全兜底，敏感词过滤、内容审核、密钥托管全在网关做，比每个业务团队各自为战靠谱得多。我见过太多公司把API key直接写在前端代码里，这种事故网关层一挡就没事了。
1.2 关键能力全景：模型路由、鉴权、限流、观测与治理
模型路由是网关最核心的能力，没有之一。我自己的实践经验是，路由策略至少要支持三种粒度：按模型名路由、按请求内容路由、按成本或延迟路由。比如同一个翻译请求，普通文本走便宜的模型，遇到法律合同这类高精度需求自动切到贵的那档。还有一种场景是A/B测试，新模型上线先切5%的流量过去，网关层改个权重就行，业务方完全无感。
鉴权和限流得放在一起说，因为这俩在企业里经常打架。网关要支持多租户，每个租户有自己的API key、配额和权限范围。限流不能只做简单的QPS限制，得看token速率——大模型请求一个prompt可能就几千token，光数请求次数没意义。我踩过的坑是早期只限QPS，结果一个用户发超长文档直接把月度预算干爆了。观测能力这块，日志要记录完整的请求响应链路，指标要覆盖延迟、错误率、token消耗，追踪要能串起一次请求经过的所有模型调用。治理则是更高层的抽象，包括模型版本管理、灰度发布、内容安全策略、审计日志这些。
这些能力听着多，落地时要有优先级。我的建议是先做鉴权、限流和基础日志，这三样是生产环境的底线。路由和观测紧随其后，治理能力可以随着规模增长逐步补。别一上来就追求大而全，网关本身也是要迭代的。
1.3 开源AI网关选型框架与技术生态对比
选型这件事我见过太多人上来就问“哪个最好”，这问题本身就有问题。我一般会先问三个问题：你的部署环境是纯云、混合云还是私有化？你的团队有没有Kubernetes运维能力？你对模型厂商的锁定容忍度有多高？这三个答案基本能筛掉一半选项。
技术生态上目前大致分几类。一类是云厂商开源的网关项目，跟自家云服务集成度高，上手快，代价是绑定性比较强。另一类是社区驱动的独立项目，比如围绕Envoy或Nginx做的AI插件方案，灵活度高但需要自己攒。还有一类是专门为LLM场景设计的网关，路由和计量能力做得细，生态相对年轻。我个人的选型框架是这样的：先看协议适配能力，支不支持OpenAI兼容格式、支不支持流式、支不支持多模态；再看扩展性，能不能写自定义插件做业务逻辑；然后看社区活跃度和版本迭代节奏，一个半年不更新的项目在企业环境里是定时炸弹；最后看运维复杂度，别选一个需要专职团队伺候的网关，除非你真有那个编制。
对比的时候别只看功能列表。我吃过亏，某个网关功能写得天花乱坠，实际部署时发现文档缺失、issue没人回、升级还带崩过两次。现在我选型一定会做两件事：一是拉一个最小可用环境跑一周，用真实流量压一压；二是去GitHub看最近三个月的commit频率和issue响应速度，这比任何评测文章都真实。
1.4 文章主线说明：多模型API统一接入与企业级部署方案
这篇长文的主线我想提前交代清楚，免得读者跟着跟着迷路。整篇内容围绕两件事展开：多模型API怎么统一接进来，企业级环境怎么稳稳当当地跑起来。上半部分偏集成和治理，讲协议适配、路由回退、鉴权计费、可观测性这些能力怎么设计和落地。下半部分偏部署和运维，讲Kubernetes怎么编排、高可用怎么做、安全合规怎么过、成本怎么控。
我的写作视角会比较“实战”，尽量少堆概念，多讲我实际见过或踩过的场景。比如多模型回退策略，我会拿一个真实故障案例来说：某次主力模型厂商区域故障，网关自动切到备用模型，业务方只感知到延迟高了200毫秒，没出用户投诉。这种细节比列一堆功能点有用得多。
读者对象我假定是有一定后端或运维经验的技术决策者，也可能是正在评估AI基础设施的架构师。如果你刚开始接触这块，建议先读第1章建立全景认知，再按需跳到具体章节。每章尽量独立成篇，但章节之间会有交叉引用，方便你按自己的节奏读。整篇内容会持续更新，开源生态变化快，今天的最佳实践明天可能就过时了，我会尽量标注时间背景。
2.1 多模型API统一接入的架构模型与协议适配
我印象最深的一次多模型接入翻车，是帮一家做跨境电商的朋友搭比价系统。他们同时用了GPT-4o做商品描述生成、Claude做评论摘要、还有本地部署的Qwen做实时翻译。三个厂商三家接口规范，流式响应的格式都不一样，前端拿到的数据解析代码写了快两千行。更崩溃的是OpenAI那边突然把响应字段名从delta改成了token，一晚上整个管道全断。那件事之后我彻底想明白一个道理：网关的协议适配层，本质上是在给业务层面做“脏活隔离” 。你不能指望每个业务团队都去维护三四套SDK，那不现实。网关要做的事，是把所有厂商的API都“翻译”成一套统一的OpenAI兼容格式，业务侧看到的永远是那个熟悉的/v1/chat/completions。
架构上我习惯把接入层拆成四块：接入适配、协议转换、路由决策、治理执行。接入适配负责跟各家厂商的SDK或REST接口打交道，维护好连接池和重试逻辑。协议转换是核心，把OpenAI格式、Anthropic格式、各家云厂商的自定义格式统一成内部规范。路由决策和治理执行后面几节细说。这里有个坑我踩了好几次——流式响应的协议适配千万别想着“一把梭” 。OpenAI的SSE流是data: {...}拼接，Anthropic的流式事件结构完全不同，有些私有化模型的流式甚至走的是WebSocket。网关层要做的不光是格式转换，还得处理心跳、断流重连、超时截断这些边界情况。我现在写适配代码，第一件事就是把流式和非流式两条路径分开设计，别偷懒合并。
协议适配的深度也值得聊两句。浅层适配只转换请求响应格式，深层适配要理解模型能力差异。比如有些模型不支持function calling，有些模型的多模态输入格式特殊，还有些模型的system prompt在API里是独立字段而在另一些模型里得拼进user message。我见过一些网关项目号称“全兼容”，实际用起来发现传个图片参数就报错。真正的适配是把模型能力的“方言”也翻译掉，让业务方按一套标准写法提交请求，网关根据目标模型做能力降级或参数重写。这件事没有捷径，只能一个个厂商对着文档啃，啃完还得拿真实请求压测验证。
2.2 模型路由、回退策略与多模型协同调用
路由策略这块，我的经验是别一上来就搞智能路由，先把静态路由做稳。所谓静态路由就是按模型名和权重分发，听着简单，但企业里80%的场景用这个就够了。比如内部知识库问答固定走某个私有模型，对外客服走GPT-4o mini，代码补全走另一个。配置里写清楚“哪个应用走哪个模型”，出了问题好排查。我见过一个团队刚开始就上语义路由，结果用户问“今天天气怎么样”，路由模型判断这属于“闲聊”类别，走了最便宜的模型，回答质量稀烂，投诉电话被打爆。后来老老实实退回静态路由加规则兜底，世界清净了。
智能路由和回退策略是进阶能力，但它们的价值在故障场景下才真正体现。去年双十一前夜，某头部云厂商的API区域故障，我朋友的公司正好赶上大促。他们网关配了三层回退：主力模型超时超过3秒切备用模型，备用模型错误率超过5%切第三备，第三备也不行了就降级到最便宜的兜底模型并返回一个延迟提示。业务方只感知到响应慢了200毫秒，订单转化率几乎没波动。回退策略的工程细节特别多——重试次数和熔断阈值要一起调，光配重试不配熔断，上游一挂你的网关直接被重试流量打垮。我现在标配是：单请求最多重试1次，连续5次失败触发熔断，熔断窗口30秒，半开状态放5%流量探活。这套参数不一定最优，但至少不会把自己玩死。
多模型协同调用是另一个维度。有些任务天然适合“模型接力”，比如先用便宜模型做意图分类，根据分类结果再决定走哪个贵模型做深度处理。还有并行调用——同一个prompt同时发给三个模型，取最先返回的那个，或者在网关层做结果投票。这听着很酷，但成本要算清楚。并行调用意味着token消耗翻倍，除非你的场景对延迟极度敏感，否则老老实实串行加回退更划算。我见过最实用的协同模式是“小模型兜底、大模型救场”：普通请求全走小模型，小模型置信度低于阈值时，网关自动把原始请求转发给大模型重做一次。这种“按需升级”的玩法成本可控，效果提升明显。
2.3 统一鉴权、配额、计费与内容安全治理
多租户鉴权这件事，吃过亏的人都知道疼。早期我用简单的API key做鉴权，每个租户一个key，结果有个外包团队把key泄露到了GitHub上，三天烧了两万块。后来改成两级鉴权体系：租户级key只用来申请临时token，真正调模型必须用短时效token，网关侧做IP白名单加请求签名校验。这套流程麻烦是麻烦点，但安全性上了一个台阶。租户模型也得做细——每个租户绑定自己的模型白名单、速率配额和预算上限。我习惯给每个租户建一个“能力画像”，记录它能访问哪些模型、单次请求token上限多少、日累计消耗不能超过多少。网关收到请求先查画像，超了就403，别等到月底账单出来再哭。
配额和计费要放在一起设计。单纯的QPS限制在大模型场景下基本没用，因为一个请求可能几十个token也可能几十万个token。我现在配的是三层配额：请求速率（RPM）、token速率（TPM）、预算配额（按日/月）。token速率的桶要按模型分开算，贵模型的TPM配低一点，便宜模型配高一点。计费模块更不能马虎，每个请求完成后要根据实际消耗的input/output token数折算成本，记到租户和应用两个维度上。有个细节容易被忽略——流式响应的token计量。流式返回时你得等最后一个chunk到了才能确定总token数，这期间配额怎么扣？我的做法是请求进来先预扣一个估算值，流结束后按实际值多退少补。预扣值按prompt长度和max_tokens估算，偏保守一点，防止超额。
内容安全治理我强烈建议放在网关层做，别指望每个业务团队自己实现。基础的是敏感词过滤，但大模型场景下光靠敏感词不够——模型可能生成看似无害但实际违规的内容。我的方案是三阶段检查：输入侧做prompt安全扫描，拦截明显的注入攻击和敏感请求；输出侧做流式内容审核，每隔几个chunk送一次审核接口，命中违规立即断流；最后落地存储前再做一次全量审核作为兜底。审核接口可以接第三方服务，也可以自己在网关里挂一个小分类模型。三阶段都要配开关和黑白名单，某些内部应用可以放宽，对外应用从严。治理策略得版本化，每次调整记录操作人和时间，出事了能回溯。
2.4 可观测性与效果评估：日志、指标、追踪与评测
可观测性这块我踩过的最大坑是日志记太少、指标配太多。早期版本网关只记了请求时间戳和状态码，结果线上出现“偶发空响应”，查了三天没头绪，最后靠临时加日志才定位到是某个厂商在特定参数组合下返回了空body。从那以后我定了个规矩：每个请求必须记录完整的入参出参摘要（敏感信息脱敏）、模型名称、token消耗、延迟分阶段（接入延迟、首token延迟、生成总时长）、回退链路、错误详情。流式请求额外记录首chunk时间和chunk间隔的统计量。这些日志按租户和模型双维度切分，写进ES里，排查问题的时候直接按trace_id串起来看。
指标方面我砍掉了大半。现在只留四个核心面板：请求成功率和错误码分布、各模型P95和P99延迟、token消耗速率与预算水位、回退触发次数与原因。告警就绑这几个面板，别搞太多花里胡哨的。追踪能力必须支持OpenTelemetry，网关作为span的一环把trace_id透传给下游模型调用，这样一次请求经过路由、鉴权、模型调用、审核、存储的全链路都能串起来。我见过一些网关项目自己造轮子做追踪，用起来跟主流APM工具对接费劲，不如直接拥抱标准协议。
效果评估是另一个容易糊弄的环节。网关层做评估有个天然优势——你手里有全量的请求和响应数据。我的做法是定期跑离线评测集：从生产日志里抽样真实请求，拿新模型和老模型各跑一遍，用人工标注或自动打分对比效果。灰度发布阶段更要靠这个——新模型先切5%流量，网关把灰度组的日志打上标记，一周后拉出来跟对照组比。这里有个小技巧：网关层别自己实现打分逻辑，挂个webhook把评估任务推给外部的评测平台，网关只负责采样和标记。不然网关会越来越臃肿，违背了“轻量管道”的设计初衷。
2.5 典型场景与最佳实践：跨云多模型、私有模型与混合推理
跨云多模型接入是我最近半年做得最多的场景。客户通常AWS上一套、阿里云上一套，还有一两个模型跑在自建机房。网关在这种场景下要解决的核心问题是网络路径和凭据管理。我的方案是网关部署在中心云上，通过专线或VPN打通各云环境，每个云上的模型端点配独立的连接器和凭据轮换策略。路由策略按网络延迟和成本双权重来配——同云请求优先走同云模型，跨云请求先测延迟，超过阈值自动降级到本地兜底模型。有个细节：不同云的出口IP不一样，有些模型厂商对源IP有白名单限制，网关得维护一套IP映射表，切换时自动带上对应的源IP标签。
私有模型混合推理的场景更有意思。不少公司既有自研微调的小模型跑在内部GPU集群，又用着公有云的大模型API。这种混合架构下，网关要做的是能力分层：简单意图识别和实体抽取走私有小模型，复杂推理和长文本生成走公有云大模型。我通常会在网关里配一个轻量分类器，根据请求的复杂度和敏感级别决定走哪条路。敏感数据不出内网这条红线要靠网关的策略引擎来守——检测到请求里含身份证号、手机号这类PII，直接强制路由到私有模型，同时把原始请求脱敏后再转发。这套策略我一般用OPA（Open Policy Agent）来写，跟网关解耦，策略变更不用重启网关。
还有一个场景是模型版本灰度与A/B测试。新模型上线别一上来就全量切，网关层配权重先放5%流量。灰度期间日志打标，跟对照组分开统计。评估指标别只看延迟和成功率，业务指标要拉进来一起看——比如客服场景看首次解决率，营销文案场景看点击率。我见过一个团队灰度新模型，技术指标全部绿油油，结果业务侧发现新模型生成的回答太啰嗦，用户满意度掉了8个点。后来他们在网关层加了个“回答长度”的监控指标，灰度期间长度超过阈值的请求自动回切老模型，问题才算控住。灰度周期我建议至少一周，覆盖工作日和周末两个流量周期，别三天就急着全量。
最后说一个最佳实践——网关配置要当代码管。路由规则、配额策略、回退链路这些配置全部走Git仓库，每次变更走MR评审，CI流水线自动做配置校验和预发环境验证。我见过太多团队在控制台里手点配置，点错一个权重把全部流量切到了最贵的模型上，一晚上烧掉半个月预算。配置代码化之后这种事故基本绝迹，而且回滚就是一次Git revert，比翻控制台快得多。
3.1 企业级部署形态：Kubernetes、私有化、混合云与边缘
去年帮一家银行做网关选型，对方架构评审会上第一句话就问我：“你们这套东西能不能不进DMZ区？”我一下就懂了——金融客户的模型调用可能涉及账户信息，流量压根不允许出内网。这件事让我彻底调整了部署方案的设计思路。网关的部署形态不能是单选题，得做成一套可拆装的组合，同一份代码换个打包方式就能适配不同环境。现在我的标准做法是提供四种交付物：Helm Chart用于Kubernetes集群，离线安装包用于纯私有化物理机，混合云模式配一套专门的路由控制器，边缘场景给一个轻量二进制。
Kubernetes部署是大头。我一般推荐用Helm管理网关的部署，把配置、密钥、路由策略全部做成ConfigMap和Secret挂载。但有个坑我踩过——别把网关的所有实例都塞进同一个Deployment。控制面和数据面要分开，路由规则下发、策略配置、租户管理这些走控制面组件，实际转发模型请求的数据面单独部署。数据面用DaemonSet或者带HPA的Deployment，控制面单独跑一套小的StatefulSet。这么拆的好处是升级策略可以分开做，数据面滚动升级不影响控制面的配置管理。还有个细节，网关的Pod要配反亲和性，别让所有副本挤在一个节点上，节点一挂全完。
私有化部署的客户通常环境很“干净”，没K8s、没容器运行时、连Docker都不一定装。我的经验是私有化包必须自带运行时和依赖，别指望客户去装这装那。打包时用静态编译的二进制，配置文件用YAML，依赖的数据库只要求MySQL或PostgreSQL其中一种，缓存用内置的或者可选的Redis。安装脚本要能自动检测端口冲突、自动生成自签证书、自动初始化表结构。我见过一个团队交付私有化版本，客户装到一半发现缺个glibc版本不对，折腾了两天。后来我们改成全静态编译加容器化双轨交付，客户爱用哪种用哪种，投诉率直线下降。
混合云部署的复杂度在于网络和凭据。客户通常生产环境在私有云，一些模型跑在公有云上，网关要跨环境转发请求。我的方案是在每个环境部署一个轻量网关节点，节点之间通过控制面同步路由规则和租户配置，请求按“就近处理”原则路由到最近的数据面。凭据管理用一套中心化的密钥服务，各节点定期拉取并缓存，密钥轮换时通过控制面推送通知。边缘部署的场景更极端，有些客户的门店或者工厂网络不稳定，网关得能在断网状态下用本地缓存的模型和策略做降级推理。这种场景下我把策略引擎做成本地文件加载，模型调用超时直接走本地小模型兜底，等网络恢复了再异步补报日志。
3.2 高可用架构、性能优化与弹性扩缩容
高可用这件事，我的观点是别追求四个九，先想清楚你的故障域在哪。网关本身可以做多副本、多可用区，但真正的故障往往来自上游模型API和下游的鉴权服务。我给一个电商客户做压测时发现，网关本身扛住了8000 QPS，结果鉴权服务那边一个Redis节点挂了，整个链路雪崩。从那以后我在架构图上一定标出所有外部依赖，逐个评估故障影响。网关对鉴权服务要做本地缓存加熔断，缓存TTL配短一点，30秒到1分钟，鉴权服务挂了还能用缓存撑几分钟，给修复争取时间。
性能优化的重点在连接管理和协议处理。网关到上游模型的连接池要按模型端点分开管理，每个端点的最大连接数、空闲超时、请求超时都要单独配。HTTP客户端的参数我调过很多次，最后稳定下来的配置是：最大空闲连接数按实例数乘以30来算，空闲超时90秒，TCP keep-alive打开。流式请求和非流式请求的连接池最好隔离，流式请求占用连接时间长，跟短请求混在一起容易把池子打满。还有个容易忽略的点——JSON序列化和反序列化的开销。大模型请求的body动辄几十KB，用标准库序列化在高并发下CPU占用很高。我后来换成了性能更好的JSON库，单实例吞吐提升了大概两成。
弹性扩缩容的关键是指标选对。用CPU做扩缩容指标在大模型网关场景下经常不灵，因为瓶颈往往在等待上游响应，CPU并不高，但请求排队已经很长了。我现在标配的扩缩容指标是：单实例的并发请求数、P99延迟、队列长度。HPA配置里把并发请求数作为主指标，设一个阈值比如单实例超过200并发就扩容，扩容步长设大一点，比如一次加50%。缩容要慢，冷却时间给够，别流量刚降下来就急着缩，容易来回震荡。压测数据得提前准备好，每个实例在什么并发下延迟开始劣化，这个拐点值就是扩容阈值的依据。
3.3 安全合规、多租户治理与审计体系
安全合规这块，我总结的经验是把合规要求翻译成技术配置，别停留在文档里。等保三级要求日志留存六个月，那就得在日志管道里配好TTL和冷热分层，热存储留30天方便查，冷存储归档到对象存储留半年。数据加密要求传输加密和存储加密，那就把TLS证书管理做成自动化的，密钥轮换周期写进配置。我见过一些团队合规文档写得漂漂亮亮，真去查日志发现只留了七天，审计的时候抓瞎。现在我的做法是合规要求逐条对应到网关的配置项清单，上线前逐项打勾。
多租户治理的深度决定了这套网关能不能在企业里规模化用起来。早期版本我只做了租户隔离的鉴权和配额，后来客户提了个需求：不同部门之间的模型调用日志要互相不可见。这就涉及到数据面的租户隔离了。我的方案是在日志和指标里都打上租户标签，查询接口按租户过滤，存储层用逻辑隔离加行级权限控制。租户的模型白名单要支持继承和覆盖，集团级配一个基础白名单，子公司可以在自己范围内追加，但不能突破集团的上限。这种层级化的权限模型比扁平的多租户配置好用很多，客户的组织架构怎么变都能映射过来。
审计体系不能只是记录谁在什么时候调了什么模型。真正的审计要能回答三个问题：这个请求为什么走了这个模型、这个配置是谁在什么时候改的、这次变更影响了哪些租户。我的做法是把配置变更和请求日志用同一个trace体系串起来。配置每次变更生成一个版本号，请求日志里记录当时生效的配置版本。出了问题回溯的时候，先查请求日志找到版本号，再查配置变更记录定位到操作人和变更内容。审计日志要单独存储，跟业务日志物理隔离，访问权限只给安全团队。还有个细节，审计日志本身要防篡改，我一般用追加写加哈希链的方式，每条日志带上一条的哈希值，改一条全链对不上。
3.4 CI/CD、版本升级与运维监控体系
网关这类基础设施组件的CI/CD，我的原则是配置变更和代码变更走同一条流水线，但发布节奏分开。代码变更意味着二进制更新，风险高，要走完整的测试、预发、灰度、全量流程。配置变更比如调整路由权重、修改限流阈值，风险相对低但频率高，可以走快速通道，但必须保留审批和回滚能力。我现在的流水线设计是：代码合并触发构建和单元测试，镜像推送到仓库后自动部署到集成环境跑端到端测试，通过后手动触发预发发布。配置变更走另一个入口，提交MR后自动做schema校验和策略冲突检测，合并后由配置同步组件推送到各环境。
版本升级最怕的是不兼容。网关作为流量入口，升级期间任何抖动都会被放大。我的经验是数据面和控制面必须能独立升级，而且数据面要支持热重启。新版本的数据面实例先启动，健康检查通过后逐步把流量切过去，老实例等连接排空后再下线。控制面升级期间数据面继续用本地缓存的配置工作，控制面恢复后自动同步。数据库 schema 变更要向前兼容，新版本能读老数据，老版本遇到新字段能忽略。我们做过一次统计，按这套流程升级，平均每个版本的全量发布时间从原来的两个小时压缩到二十分钟，故障回滚次数也少了很多。
运维监控体系我砍掉了很多花哨的东西，只保留最核心的。监控大盘分三层：全局健康度看总QPS、成功率、P99延迟、错误预算消耗；租户维度看各租户的配额水位和异常请求；实例维度看单节点的资源使用和连接数。告警规则我坚持一个原则——每条告警都必须有对应的处理手册，没写手册的告警不许上。以前配过一条“错误率超过1%告警”，结果半夜被叫起来发现是某个客户在压测，白白折腾一晚上。后来所有告警都加了抑制条件和分级，P0级别的才打电话，P1发消息，P2进工单。告警收敛也做了，同一类问题五分钟内只发一次。
3.5 成本优化、容量规划与规模化运营
大模型网关的成本结构跟传统网关完全不一样。传统网关的成本大头在带宽和机器，大模型网关的成本大头在token消耗。我见过一个团队月账单三十万，其中二十八万是模型调用费，网关本身的机器成本只占零头。所以成本优化的主战场不在基础设施层，在路由和配额策略。我一般会给客户算一笔账：把简单分类任务从大模型切到小模型，成本能降一个数量级。网关层配好意图识别和路由规则，让便宜的模型处理大部分请求，贵的模型只处理真正需要的那部分。有个客户按这个思路调整了路由策略，月账单从二十多万降到八万多，效果几乎没变。
容量规划要区分两个维度：网关自身的容量和上游模型的配额。网关自身的容量靠压测数据来推算，单实例在目标延迟下的最大并发数乘以实例数，再留30%的余量。上游模型的配额要按模型分别算，每个模型的TPM限制、RPM限制、并发连接限制都要摸清楚，在网关层做配额分配和排队策略。配额分配要留缓冲池，别把所有配额都分给租户，留10%到15%给突发流量和内部调用。我一般会做一个配额使用率的热力图，按租户和模型两个维度展示，哪家租户快超限了一眼就能看出来，提前做扩容或者限流。
规模化运营的难点在租户增长后的管理复杂度。租户从十个涨到一百个，配置管理、配额分配、故障排查的工作量不是线性增长的。我的做法是把租户按业务线和模型使用模式分组，同组的租户共享一套基础策略模板，个别差异用覆盖配置。运营层面要有一套自助服务能力，租户可以自己查用量、自己申请配额调整、自己看调用日志，网关团队只做审批和兜底。这套自助门户上线后，网关团队的日常工单量降了大概六成，大部分精力可以放在架构优化上。
3.6 企业落地路线图与常见风险规避
企业落地这件事，我见过太多团队想一步到位。上来就要做多租户、智能路由、全链路追踪、自动扩缩容，做了半年还没上线。我的建议是分三期走，每期都有能跑起来的闭环。第一期做最小可用版本：单集群部署、静态路由、基础鉴权、日志和核心指标，目标是让第一个业务团队用起来。第二期补企业级能力：多租户、配额计费、回退策略、配置代码化，目标是支撑多个业务线同时接入。第三期做规模化运营：混合云部署、自动扩缩容、成本优化、自助门户，目标是让网关成为公司级的AI基础设施。每期上线后扎实跑一个月，收集反馈再进入下一期。
第一期最容易踩的坑是需求蔓延。业务方会提各种“顺便也支持一下”的需求，比如能不能做模型效果对比、能不能自动生成调用报告。这些需求本身合理，但放在第一期会拖慢上线节奏。我的做法是维护一个需求池，第一期只做P0，其他全部排到后续期。有个客户第一期硬塞了二十多个需求，做了四个月还没上线，最后业务团队等不及自己搭了个直接调API的临时方案，网关项目差点被砍掉。后来砍到八个核心需求，三周上线，跑起来之后再慢慢迭代，反而推进得顺利。
第二期的风险在组织协同。多租户能力涉及到财务（计费）、安全（审计）、各业务线（配额申请），跨部门协调比写代码难多了。我一般会提前拉一个虚拟项目组，把各方的接口人和决策人拉进来，每两周开一次对齐会。计费规则要跟财务提前对齐，别等系统快上线了发现财务那边的成本核算口径对不上。审计要求要提前跟安全团队确认，别做完之后安全说缺字段再返工。组织协同这件事没有技术捷径，就是提前拉齐、定期同步、把决策记录写下来。
第三期的风险是过度优化。规模化运营阶段容易陷入指标驱动的陷阱，天天盯着成本降了几个点、延迟优化了几毫秒，忽略了系统稳定性。我见过一个团队为了降成本把网关的副本数压到最低，结果一次流量高峰直接打挂，故障损失的金额比省下来的成本多几十倍。规模和稳定之间要有明确的红线，成本优化可以慢一点，稳定性不能打折。我现在给客户做方案，容量规划一律按峰值流量的1.5倍留余量，宁可多花点机器钱，也别在关键时刻掉链子。
