有一段时间我所在的项目组把大模型推理服务从原来的业务集群里拆出来独立部署紧接着就遇到了一连串之前没想过的麻烦。客户端直连模型服务地址散落得到处都是某个版本升级想灰度后端一换地址前端就要跟着改高峰期并发一上来模型服务直接被部分慢请求占满快请求也进不来月底对账的时候各个业务方报的Token消耗数还和模型侧日志对不上。折腾了快两个月我们终于意识到大模型推理场景需要的不再是传统的微服务网关而是一个懂模型语义、懂流式协议、懂成本计量的AI网关。这篇文章就是基于那段实践做的复盘从定位、职责、架构演进三个层面展开适合正在建设AI推理基础设施的后端团队、平台工程师以及准备把大模型能力开放给内部业务的同学参考。我会尽量讲清楚每个设计背后的“为什么”也会把踩过的坑和排查思路一并放出来。1. 场景定位大模型推理为什么需要独立的AI网关1.1 传统API网关在大模型场景下的天然短板很多团队一开始的想法是“我们已经有API网关/K8s Ingress了直接用不就行了”。实践下来会发现传统网关和LLM推理流量的匹配度很低不是配置问题而是模型假设不同。传统API网关是为短连接、请求-响应式微服务设计的。客户端发一个HTTP请求网关转发后端几百毫秒内返回连接即释放。网关只需要看HTTP头不需要理解报文内容。负载均衡也是按“请求数”来做的一个请求被转发到某个实例之后这个请求占用的后端资源在毫秒级就释放了。但大模型推理是完全不同的流量模型。一次生成请求可能持续几秒甚至几十秒响应是SSE流式返回整个过程中连接一直挂着。更关键的是后端每个实例的资源占用不是“处理完一个请求就释放”那么简单——GPU显存、算力、KV Cache都是长期共享资源。传统网关按QPS做均衡结果就是慢请求、快请求混在一起资源分配完全失控。我打个比方传统网关像写字楼的访客登记台来一个人登记一下见完就走访客和会议室没有长绑定关系。LLM网关更像医院的分诊台每个病人在诊室待很长时间占用医生的精力和设备资源而且有的病人要半小时有的要三分钟你不能只按“来一个叫一个”的方式处理。1.2 成本视角推理请求的昂贵属性改变了网关的职责边界另一个被低估的点是成本。一次普通API请求的成本可以忽略不计但一次大模型推理请求要消耗GPU时间长文本、长输出的对话请求成本更高。如果网关还像传统网关一样“转发就算完事”那流量控制、配额管理、成本分摊就全都失控了。我们当时遇到过这样的情况某个业务方写了个低效的循环调用在摘要场景里反复请求同一个模型单日成本直接翻了几倍。传统网关的限流是按请求数做的对这种“单请求很贵但数量不多”的消耗方式几乎没有感知。AI网关必须有能力从模型语义层面感知成本——一个请求的输入Token数是多少、输出Token数预计多少、这个模型和这个参数的单价是多少。把这些信息纳入网关的决策逻辑才能做到真正的预算保护。这一点是我理解“AI网关定位”最重要的入口它不只是流量的入口更是成本的控制点。1.3 AI网关的三种基本角色经过一段时间的梳理我习惯把AI网关的定位拆成三个角色。第一个角色是“模型流量的统一入口”。所有内部业务方不直接感知后端模型服务地址只和网关约定的模型名、版本号打交道后端扩缩容、迁移、切换都不影响调用方。第二个角色是“策略执行点”。路由、灰度、限流、排队、优先级、熔断这些策略统一收口到网关而不是散落在各个业务代码里。第三个角色是“计量审计点”。每次调用消耗多少Token、花费多少钱、是哪个租户哪个业务发起的网关留痕便于成本核算和问题回溯。这三个角色并不是并列关系而是一个递进关系。先做到统一入口才能谈策略执行先把策略执行做到位计量审计才有意义——因为你只有在入口做了限流和配额计量出来的数据才是受控的、可信的。2. 职责拆解AI网关到底要做哪些事2.1 模型路由与版本灰度让调用方不感知后端变化模型路由是AI网关最基本的职责但做起来比预想中复杂。网关对外暴露的是一个“逻辑模型名”比如summary-v1内部维护一张路由表把逻辑名映射到真实的模型服务地址和版本号。这里有个容易忽略的点模型升级不是简单的换一个地址而是要处理Prompt兼容性。我们当时升级某个模型版本时发现新版对一些特殊指令的响应格式有变化业务方解析出来的结果直接报错。如果网关不做灰度直接把流量切过去就是线上事故。所以网关对于路由层的设计至少要支持同一逻辑名下多个版本并存按权重分配流量按请求特征做分流比如特定API Key走新版本支持一键回滚路由配置修改后立即生效。在做这个功能时我体会到路由表不能做成静态配置必须动态下发。我们的做法是配置存到配置中心网关监听变更秒级生效。灰度过程中要能够观察对比不同版本的成功率、延迟、Token消耗分布所以网关还需要把“模型版本”作为标签打进日志和指标里否则灰度数据根本没法对比。2.2 流控、排队与优先级QPS不是关键指标传统限流看QPS比如每秒最多100个请求。但在大模型场景看QPS会误导因为每个请求的耗时差异巨大。一个只生成几十个Token的请求和一个生成上千Token的请求对后端资源的影响完全不同。更准确的指标是当前正在并发处理的请求数、每个请求的已耗时时长、以及后端实例的吞吐上限。我倾向于把网关的流控做成“并发控制 排队 优先级”的组合。具体来说网关设定模型服务允许的最大并发数比如8超过并发上限的新请求进入排队队列而不是直接放行队列内部按优先级排序重要业务的请求插队到前面当请求在队列里等待超过阈值时直接拒绝或返回一个提示让客户端稍后重试。我们还有一个实际场景某个模型服务被内部批量任务大量占用正常用户请求一直处于饥饿状态。后来在网关里做了优先级队列把实时交互请求放在高优先级把离线批量任务放在低优先级问题才解决。没有这层控制后端的扩容和优化都是徒劳。2.3 流式响应的代理与Token计量边转发边统计这是AI网关和传统网关差异最明显的地方。大模型API普遍使用SSEServer-Sent Events流式返回结果客户端会收到一段一段的数据每段包含若干Token。网关在中间要做的不只是字节转发而是要解析流式数据、做计量。为什么要解析而不是盲目转发因为只有解析了SSE数据帧网关才能知道当前流已经产出了多少个Token、请求是否正常结束、是否发生了中断。Token计量功能需要在网关内部统计整个流式过程中的Token总数在流结束时输出准确的用量记录。否则就会出现我们遇到过的尴尬局面客户端明明收到了一半响应就断了但模型侧日志显示完整生成了网关却什么都说不出来。流式代理还有一个容易踩坑的点客户端断连。用户可能因为网络原因中途断开但上游模型服务还在继续生成如果不做处理GPU资源白白浪费。网关要能够感知下游断开并主动向上游发送停止信号尽快释放连接。这块做不好高峰期会出现大量“客户端已经走了但模型还在烧钱”的情况。2.4 面向模型语义的可观测性与审计传统网关的监控指标是QPS、延迟、错误率、5xx占比。AI网关还需要加入模型特有的指标TTFT首Token时间即从发出请求到收到第一个Token的时间这是用户感知延迟的最核心指标生成吞吐用Tokens/s衡量反映后端实例的实际处理能力每次请求的输入Token数、输出Token数、总Token数排队等待时间反映网关流控是否健康按租户、按业务方的Token消耗和成本预估。审计方面网关要记录每一次调用的完整链路谁调的、调的哪个模型、用的什么参数、消耗多少Token、耗时多久、返回状态如何。这些日志既用于对账也用于问题回溯。我们遇到过业务方反馈“我明明没调用这么多次”查了网关日志才发现是有个定时任务在夜间批量重试。如果没有网关这层审计数据这种问题基本无解。3. 架构演进从直连时代到网关的演进路径3.1 早期直连时代功能散落、策略失控我们早期是完全没有网关的业务方通过模型服务暴露的CLI或HTTP接口直接调用。这个阶段的架构最简单扩展性最差。每个业务方都要自己管理服务地址自己处理超时重试自己实现限流自己记录Token用量。结果就是所有策略都在业务代码里各自为政有的团队做了缓存有的没有有的团队重试三次有的重试十次出了故障大家都在群里互相推诿。这个阶段最痛的还不是功能缺失而是“变更成本”。模型服务一旦迁移或升级版本所有调用方都要跟着改代码有些人改了有些人没改线上就出现新旧版本混用。所以直连模式只适合早期Demo和实验阶段一旦有多个业务方接入就必须引入统一的网关层。3.2 统一代理时代数据面先行第二阶段是独立部署一个代理服务所有模型调用统一走代理。这个阶段做的事情主要是统一服务入口对外暴露固定地址实现基础的路由转发支持按模型名转发到不同后端加一套基础的限流和鉴权统一记录访问日志。在这个阶段架构上其实就一个“胖网关”配置是静态的路由也好、限流也好都是网关本地文件。好处是立竿见影——调用方不再感知后端变化网关有了全局流量视图。坏处也明显每次改限流策略、加一个新模型都要改网关配置并重启操作风险高数据面和控制面耦合在一起策略的调整不够灵活。我们在这个阶段挨过一次教训某个版本升级需要调整限流阈值结果改配置的时候不小心把并发上限写错重启后直接把线上流量全部拒绝。那次事故之后我们下定决心把控制逻辑从网关进程里拆出去。3.3 控制面与数据面分离AI网关走向平台化第三阶段是控制面与数据面分离。数据面仍然负责转发流量但路由、限流、灰度、配额这些策略统一放到控制面管理。控制面负责解析配置、处理策略变更并通过下发机制同步到数据面数据面无需重启即可生效。这个架构的好处是策略调整变得安全、快速不需要动数据面进程多个网关实例之间配置一致不会出现“A实例限流100B实例限流1000”的诡异情况灰度、切换、配额变更可以做成操作界面而不仅仅是改配置文件。对平台团队来说控制面和数据面分离也是“网关平台化”的关键一步因为你可以开始对网关做权限管理、变更审计、批量操作了。需要注意的是控制面下发配置时要考虑一致性问题。网关实例在运行过程中可能会短暂使用旧配置这就需要在设计时明确策略版本号和下发节奏。我们遇到过限流配置已经改了但因为某些网关实例没拉取到新配置导致限流失效的情况。所以控制面不仅要下发配置还要有配置有效性的检查机制。3.4 可编程网关与Agent化演进的下一个方向现在比较新的演进方向是让网关具备更强的可编程能力——不只是“配置驱动”而是“策略即代码”。网关暴露插件机制开发人员可以写自定义逻辑来处理请求比如按业务自定义的规则改写Prompt前缀、按对话上下文动态选择模型、与外部系统联动做更复杂的计量配额。更进一步有些网关产品开始引入Agent化思路网关不只是被动等待流量而是主动感知后端模型集群的状态——比如某个模型服务排队过长网关主动把流量切换到备用模型某个实例返回了减速信号网关自动拉低流量权重。这个方向本质上是把原来的“人肉运维决策”逐步自动化。从演进路径来看核心驱动力就一句话调用方越来越关注模型语义而基础设施必须跟上。从直连到统一代理是解决连通性问题从代理到控制面分离是解决运维问题从配置驱动到可编程是解决灵活性问题。每一步都在往“让模型调用像内部基础设施一样可管可控”这个目标靠拢。4. 工具选型与落地实践开源方案和自研如何权衡4.1 开源网关项目还是自研先看边界再看成本现在市面上已经有不少开源的AI网关项目也有云厂商托管的网关服务。我的建议是不要一上来就自研先把边界想清楚。如果你只需要统一入口、基础限流、Token计量和日志开源方案大概率够用如果你有强烈的定制需求比如独特的排队策略、与内部框架深度集成的鉴权逻辑、基于内部计费系统的配额联动那开源自研的改造工作量会很大这时候考虑自研或深度二次开发。我们当时评估了很久最终选了一部分自研一部分复用开源组件的方式HTTP转发、SSE处理这些通用能力用成熟组件路由策略、成本计量、灰度控制这些偏业务的能力自己写。切割的标准是“是否和内部系统强耦合”。只要需要对接内部现有系统的就自己写纯技术能力能复用就复用。4.2 部署拓扑网关放在哪个位置部署拓扑上我推荐把AI网关放到业务入口和模型服务之间形成“客户端 → 接入层 → AI网关 → 模型服务”的链路。接入层负责常规的HTTP鉴权、跨域、防攻击等通用能力AI网关专注于模型语义相关的策略。两者职责分离互不干扰。有没有必要把AI网关再往前面挪直接对外暴露我的看法是除非是面向外部合作伙伴开放模型能力否则没必要。内部团队直接把AI网关当作统一入口使用鉴权逻辑仍放上一层这样模型服务的暴露面最小安全风险最低。还有个实践细节AI网关实例要和模型服务尽量近减少网络跳数带来的延迟。我们最初把网关放在另一套集群里跨网络访问模型服务TTFT硬生生高了几十毫秒。后来调整到与模型服务同区部署延迟才降下来。对于首Token延迟敏感的场景网络路径上的每一毫秒都值得抠。4.3 落地路线建议控制面先行、数据面逐步收口落地节奏上我建议分三步走。第一步先接流量统一入口。不管后端是什么形态先把AI网关部署起来把模型服务的地址全部收口到网关业务方改为通过网关调用。这一步只做转发和日志不急着上线复杂的限流和灰度目的是让链路跑通、数据沉淀下来。第二步上策略。有了流量数据之后开始配置路由、限流、配额、灰度策略。这个时候做决策就有据可依了不再是闭着眼睛拍阈值。第三步做计量和平台化。把Token计量、成本核算、审计报表做起来再逐步把控制面独立出去形成可管理、可审计的网关平台。这个顺序是刻意的。如果第一天上线就开全功能出问题根本没法排查如果先做计量再做路由业务方可能已经因为直连模式形成了路径依赖。先收口流量再逐步加策略是风险最小的路径。5. 常见问题与排查技巧实录5.1 SSE流中断导致模型侧超额计费现象客户端上报的Token消耗远小于模型侧日志记录的消耗而且高峰时段特别明显。排查发现网关对SSE流没有做中断处理当客户端断开连接后网关仍然维持上游连接模型继续生成到完整结束Token照常计费。修复方案网关需要监听下游连接状态一旦感知到客户端断连立即向上游发送取消信号。另外在网关层要对TTFT和总耗时设置合理超时避免上游“死等”成僵局。这个问题的本质是网关不能只当中转要有连接生命周期管理能力。5.2 并发控制失效限流阈值设了但没生效现象明明在网关里设置了并发上限模型服务的负载还是很高。排查发现多个网关实例是独立计数的每个实例都允许8个并发三个实例加起来就是24个并发远高于预期。修复方案如果是并发级别的控制必须使用分布式计数器把所有网关实例的并发统计汇总到同一个存储比如Redis才能做到全局精确限流。如果只是做单实例的粗粒度限制那要明确告诉业务方这个阈值是按实例生效的不具全局意义。这个坑提醒我们部署架构会直接影响控制逻辑的有效性。5.3 灰度流量分布不均权重配置正确但实际偏斜现象设置了5%的流量到新版本但实际观察新版本的请求占比经常超过10%。排查发现灰度分流逻辑是按请求的哈希值取模来定的如果请求ID的哈希分布本身不够均匀小比例分流就会偏差很大。修复方案要么改用一致性哈希并且扩大桶数量要么在灰度比例较小的情况下用专门的流量复制或按特定调用方白名单的方式验证。如果只是临时验证新版本用指定API Key或指定参数走新版本的方案比按百分比灰度更精准。5.4 健康检查“假阳性”端口活着但模型已经不可用现象网关的健康检查一切正常但转发过去的请求大量超时。排查发现健康检查只做了TCP或HTTP端口探测但模型服务因为显存溢出已经处于半死不活状态进程还在端口还开着就是不响应推理请求。修复方案健康检查要包含“就绪态”检查即通过一个轻量级推理请求或内部状态接口来确认模型真正可用。同时网关要具备熔断能力当某个后端实例连续超时超过阈值自动摘除流量不再往这个实例上打。5.5 客户端重试引发的重复计费现象业务方报障称某个请求只发了一次但网关日志显示同一请求被转发到了后端两次计费也算了两次。排查发现是客户端把请求超时时间设置得太短首Token延迟稍高就触发了客户端重试而网关和模型侧没有幂等能力。修复方案在网关层支持请求去重基于请求ID判断是否已经转发过同时协调客户端合理设置超时时间避免首Token延迟的正常抖动直接诱发重试。这个问题的本质是AI请求的耗时天然不稳定超时策略必须比普通API更宽容。问题现象核心原因解决方案方向客户端和模型侧Token对不上SSE流中断未处理网关感知断连主动取消上游连接限流阈值形同虚设多实例独立计数用分布式计数实现全局并发控制灰度比例偏斜哈希分布不均改白名单或一致性哈希方案后端假死仍被转发流量健康检查不够深入增加就绪态检查配置熔断重试导致重复计费客户端超时过短无幂等网关层按请求ID去重踩过几次坑之后我的体会是AI网关本质上不是在“转发请求”而是在管理一种昂贵、长连接、流式返回的特殊资源。过去我们习惯的网关思维很多假设都需要重新审视。如果这篇复盘能帮你少走几步弯路那就值了。后面如果你们团队也在建设类似的网关能力欢迎一起交流踩坑心得。