1. 项目背景AI工程化之后网关先“崩”了我接手这个项目的时候团队刚把第一版AI应用推到生产环境。表面上看接口通了、对话能回了、agent也能跑几个简单任务了但运维同学甩到我桌上一张账单截图一个月的大模型API费用比我们整个微服务集群的服务器开销还高三倍。这还不算完网关层的CPU和内存曲线像心电图一样来回跳高峰期偶尔还会超时。说白了AI工程化落地之后最明显的痛感不在模型本身而在入口处的那层网关。因为网关是所有请求的必经之路也是所有成本汇聚的十字路口。这里说的成本不只是钱——还有延迟、算力、带宽以及你排查问题时要搭进去的工程师时间。这项目的核心目标就是把我负责的Java网关做一轮彻底的成本优化。重点方向有三块一是降低大模型API的调用量和token消耗二是压降网关自身的资源开销让同样一台机器能扛更多流量三是把不稳定因素在网关层掐掉减少上游无效请求和下游重试带来的账单膨胀。Java、网关、AI这三个词放在一起听起来像是三座大山。但干完之后回头看这里面的大部分问题其实都是工程问题是有章法可循的。这篇文章就把我踩过的坑、拆过的账、写过的代码和调过的参数按照实操顺序完整捋一遍给正在做同样事情的人一个可直接参考的样本。2. 成本拆解AI网关的钱到底烧在了哪里2.1 大模型API账单的四个黑洞先说钱的部分。我们把一个月的账单拉出来逐项核对之后发现API费用主要消耗在四个地方顺序按占比排第一是重复请求。用户点了一次“重新生成”前端就会重新发一次完全一样的请求。一次两次还好但如果某个高并发时段有大量用户同时点了重试后端模型就要把同样的输入重新推理一遍每一遍都是真金白银的token计费。这类账单占比能到30%以上属于纯浪费。第二是超长上下文。我们很多agent场景会把历史对话、工具返回结果、文档片段全部拼进system prompt一次请求动辄几万token。实测下来有一类请求的输入token接近4万但真正对最终答案有影响的核心指令只有不到2千。这些“搬运工”token消耗了绝大部分成本。第三是无效调用。网关层面没有做好前置校验比如用户没登录、参数不合法、内容命中敏感词——这些请求本应该在网关直接拒绝结果一路穿透到了大模型那边模型白白推理一次返回一个“我无法回答”的结果钱也没了。第四是上游重试风暴。下游模型服务偶尔报错或者超时我们的微服务默认会重试三次每次重试都是完整费用。更糟糕的是如果调用方不是一个服务而是好几个服务同时重试对模型服务的压力会呈指数级上升账单也跟着翻倍。2.2 网关自身资源的隐性开销除了API账单网关自身的资源消耗也是成本大头。我们当时的网关实例是8C16G的Pod高峰期CPU能跑到85%平均响应延迟从正常的60ms被拖到了接近300ms。排查下来有几个问题很明显一是HTTP客户端连接池配置不合理。网关转发到大模型服务的连接默认空闲超时只有60秒而模型推理经常超过这个时间导致连接频繁被断掉重建TCP握手开销和TLS握手开销占了网关CPU的15%以上。二是JSON序列化过度。每次转发请求时我们把整个请求体解析成对象再序列化成JSON传给上游中间还有大量字段是我们根本不需要的。这些无意义的序列化操作直接吃掉了不少CPU时间片。三是Health Check和指标上报太频繁。网关每隔几秒就全量请求一次后端健康状态日志和Metrics每请求一条Prometheus那边再一扒网关自身产生的流量比业务流量还高。2.3 成本优化目标设定拆完账之后我们定了三个量化目标方便后面验证效果大模型API月费用下降50%以上且不影响核心功能的效果指标网关单实例的CPU使用率高峰从85%降到50%以下P99延迟从300ms降回100ms以内由于网关导致的错误率超时、连接失败、重试耗尽降到0.1%以下。这三个目标分别对应钱、性能和稳定性后面所有优化动作都围绕它们展开。3. 方案选型为什么坚持用Java写网关3.1 换不换Go这是一个问题在立项讨论的时候有人提议直接把网关用Go重写一遍理由是Go的并发模型更适合做高吞吐网关。这个方案确实有它的道理但我们最终没有采纳原因是现实约束太多。第一我们的网关不是一个独立的转发层它还承担了鉴权、路由、限流、灰度、日志埋点、审计等大量业务逻辑这些逻辑全部是用Java写的和内部十几套微服务共享一套工具链和配置中心。要全部重写相当于重新开发一遍网关工期至少两个月起步期间还得保证业务不中断。第二Java并非不能做高性能网关。Netty、Vert.x、WebFlux这些框架在高并发下表现不差关键在于你怎么用。我们的问题不是Java不行而是代码写得不够精细——连接池乱配、线程池滥用、JSON反复序列化这些都是工程问题不是语言问题。第三团队的技术栈就是Java让团队在现有栈上去优化远比从零学Go、踩一遍Go生态的坑要稳妥得多。工程化不是比谁的语言更酷而是比谁能在最短时间内稳定地把成本降下来。所以我们的结论是不换语言改架构。在Java生态里把网关的每一层做精做透。这本身就是一种成本优化——省掉了重写的研发成本和风险成本。3.2 整体架构调整网关层需要“三明治”结构优化后的网关逻辑划分为三层我用一个生活化的类比来理解外层是“门卫”。负责所有非业务性的前置动作——鉴权、白名单、限流、幂等判断、缓存命中检查。这些动作必须快耗时尽量控制在1ms以内能在这里拦下的请求绝不放进去。中间层是“调度台”。负责路由和策略——决定把请求转发给哪个模型服务是GPT还是自研小模型是走快速通道还是走批量管道要不要做流式转发需不需要降级。这一层的核心是“判断”尽量减少无效的计算和等待。内层是“翻译官”。负责和上游各类模型服务打交道——HTTP连接管理、协议适配、流式响应解析、超时控制、错误码归一化。这一层做得越稳上游就越不容易被打挂重试风暴的概率就越低。三层各司其职互不干扰。这个结构最大的好处是任何一层的改动都不会影响另外两层后面每拆一个优化点都可以独立验证、独立上线。4. 核心落地五类成本优化手段实战4.1 缓存优化用Semantic Cache打掉重复请求缓存是这次优化里收益最大、见效最快的一招。传统的缓存是精确匹配同一个key命中同一个value。但在AI场景下用户的输入不可能每次都一模一样但意思可能是相同的。比如“帮我总结一下今天的日报”和“总结今天的日报”字面不同语义一样如果只做精确匹配这两个请求还是会重复打到模型上。我们采用的是语义缓存方案。思路是请求进来时先把用户输入做一次向量化然后用向量相似度去缓存里找近似答案。相似度超过阈值的直接返回缓存结果不再调用模型。向量化本身可以由一个轻量的embedding模型完成成本远低于完整推理。具体实现上我没有从头写向量检索而是用了Redis的Search模块配合一个本地维护的向量索引。每个请求进来先用文本向量化接口生成向量再去Redis里做KNN搜索取相似度最高的一条如果达到阈值就把缓存结果返回。这里有几个细节需要注意一是阈值不能设太低否则会答非所问二是缓存不仅缓存最终回复还要缓存token消耗信息方便财务核算三是缓存必须有TTL避免AI效果更新后还一直在用旧内容误导用户。另外一个容易被忽略的点是所有走缓存命中的请求都要跳过log到模型账单的逻辑否则账单那边会重复计费。4.2 请求合并把多个小请求拼成一个批次请求AI场景里有个很常见的操作agent在执行任务时会同时调用多个工具每个工具返回结果后都要单独调一次模型做总结。如果网关能把多个同类请求打包成一个大请求成本就能大幅下降——因为批量请求的token计价通常比单发便宜而且减少了HTTP往返次数。我们实现的是一个批量聚合器。核心逻辑是在网关层维护一个待发送队列当Request数量达到N我们实测N8效果最好或者在时间窗口T我们设的是25ms内没有新请求进来就把队列里的所有请求打包成一个批量请求发给上游。这个方案有一个前提条件上游模型服务得支持批量接口。如果不支持就需要网关自己做“伪批量”——把多个问题的文本拼到一个prompt里用分隔符隔开然后让模型一次性回答再在网关层做文本切割。这样做虽然不能保证模型效果和单次调用完全一致但在一些摘要、分类、信息抽取类任务上效果损失非常小成本却可以省到30%到50%。我们最终只对两类请求启用了批量聚合一类是短文本分类另一类是结构化数据抽取。对话生成类没有启用因为延迟太敏感批量聚合会拖慢首字响应时间。4.3 模型路由低成本的请求走低成本模型大模型API的定价差异很大旗舰模型的成本可能是轻量模型的十倍以上在大部分普通任务上轻量模型的输出质量已经足够好。我们的网关原本把10%的请求打给了旗舰模型但实际核对后发现其中至少一半根本没用到旗舰模型的能力。所以我在网关里加了一个模型路由模块。它的判断逻辑很简单先看请求类型。如果请求是简单问答、意图识别、文本转写这类通用任务直接路由到轻量模型只有代码生成、复杂推理、长文档理解这类高难度任务才发给旗舰模型。其次看prompt复杂度。如果prompt长度超过一个阈值并且任务标识是“分析”“推理”类才允许使用旗舰模型否则一律走轻量模型。这样可以有效控制长prompt在旗舰模型上的token消耗。最后增加“动态降级”能力。如果上游旗舰模型出现高延迟或高错误率网关会自动把原本要发给旗舰模型的请求降级到轻量模型保证用户体验不中断。实测下来动态降级对业务的影响很小但关键时刻能避免一次大规模故障。4.4 协议瘦身减少无意义的传输开销网关转发时默认会带上完整的HTTP Header包括User-Agent、Accept、Accept-Encoding等一堆信息这些对模型服务完全无用。我们做了一个Header白名单机制只放行Router匹配所需的几个Header其余全部剥离。更重要的一个动作是压缩请求体。对于超过4KB的prompt我们会在网关层用gzip压缩后再发给上游。上游模型服务需要支持解压我们自己的服务是支持的配合起来没遇到什么问题。带宽成本和上游解压的CPU开销形成对冲在长文本场景下压缩后的请求体体积能减小80%左右传输时间明显下降。另外我们把原来对请求体进行全量Jackson解析再转发改成了流式拷贝。意思是不再在内存里构建完整的业务对象而是直接操作原始字节流只做必要的字段校验和重写。这样做的收益有两个一是GC压力下降二是大报文场景的内存峰值从原来的256MB降到了128MB以内。4.5 重试与限流给“意外”设置成本护栏模型服务再稳定也可能偶尔抽风但我们的成本经不起无上限重试。我把重试策略从头到尾重做了一遍第一只在特定错误码下重试。上游返回429限流、502网关错误、503服务不可用时可以重试而像400参数错误、401鉴权失败这类确定性错误坚决不重试重试一万次也白搭。第二重试次数上限从3次降到1次且必须开启指数退避。首重试间隔是500ms每次翻倍最多等待2秒。实测下来因为绝大多数原子失败在第一次重试后就能成功下调重试次数对成功率影响很小但避免了一大半的重试成本。第三网关层加了一层“重试熔断”机制。如果某个上游IP在10秒内连续失败超过5次网关会把它拉黑30秒此后所有指向该IP的请求直接返回错误不再发起重试。这样可以防止慢服务拖垮整个网关。限流方面按用户维度加了token消耗的配额控制。一个用户每分钟最多消耗多少token、每天最多消耗多少token全部在网关层记录和判断。超过配额的请求网关直接返回“额度已用完”的提示不会转发给模型。这一步看起来是对体验做减法但其实是对成本做加法——把不可控的消耗关进笼子里。5. 压测与收益验证用数据说话5.1 压测环境与工具准备优化做完了不能凭感觉说“效果好”必须用压测数据来验证。我们选了两个压测场景一个是模拟用户高频对话另一个是模拟agent高频工具调用。压测工具用的wrk和阿里云的PTS前者适合做连接数和QPS的极限测试后者适合做全链路多并发模拟。压测环境完全复刻了生产配置网关是同样的8C16G规格模型服务用Mock实现按真实延迟分布模拟。这样测出来的结果才不是“压测特供版”。5.2 压测数据对比先看网关自身的资源表现。在2000并发连接下优化前后的数据对比优化前CPU峰值是92%优化后降到46%内存从优化前的1200MB稳定在780MBP99延迟从305ms降到了88ms网关自身的错误率从1.2%降到了0.08%。这组数据说明协议瘦身、连接池调优和流式拷贝起了很大的作用网关不再是整个链路的瓶颈了。再看API成本收益。用一个典型的业务量级来测算假设每天有10万次请求其中5万次是重复或近似重复的。语义缓存命中率按60%计算就能节省3万次完整模型调用批量聚合再把另外2万次合并成2500个批次又省了一轮模型路由把30%的请求从旗舰模型降级到轻量模型成本再砍一截。三者叠加月账单降幅保守估计在40%到60%之间和我们的目标基本吻合。5.3 收益与风险平衡的复盘成本降了效果有没有变差这是所有人都会问的问题。我们把优化前后的模型效果过了一遍语义缓存的回答质量没有明显下降因为阈值卡得严不确定的请求都会放行到模型批量聚合在分类和抽取类任务上准确率下降了不到1个百分点在可接受范围内模型路由降级后部分复杂推理任务的回答质量略有波动但因为路由规则里对“高难度任务”的判断比较保守整体影响不大。还有一个容易被忽视的风险是缓存命中会让同类问题永远拿到同一个答案一旦模型效果更新用户短期内还看到旧答案。我们的解决方案是给缓存设置24小时TTL同时提供一个手动清除缓存的管理接口运营同学可以随时一键刷新。6. 常见踩坑与排查经验6.1 语义缓存的阈值陷阱把相似度阈值设在0.95以上缓存命中率很低等于白做设在0.80以下又会出现答非所问的误命中。我踩过最狠的一次是阈值设成0.82结果“怎么预约体检”和“怎么预约疫苗”被当成同一条问题用户看到回答当场就懵了。建议的做法是分场景调阈值。简单FAQ类的阈值可以放宽到0.88左右因为答案是标准化的开放式问答和创作类的阈值必须拉高到0.95以上宁可多花钱调模型也不能给用户错误答案。这个数值不是拍脑袋定的最好在测试集上把不同阈值的准确率和命中率画成曲线找到两个指标的最佳平衡点。6.2 连接池参数不是越大越好一开始我以为连接池大小设置得越大网关吞吐就越高。于是把maxTotal从50调到了500结果压测一跑CPU没降反而飙升到了80%以上。后来分析才发现连接池过大导致大量TCP连接处于半开状态内核维护连接的成本远超复用连接带来的收益。正确的做法是连接池大小要参考上游模型服务的处理能力通常设置为“单实例核心数乘以1.5”左右。我们8C的实例配了16个连接实测效果最好。同时要设置合理的idleTimeout和keepAlive让空闲连接及时回收避免大量TIME_WAIT状态的连接堆积。6.3 流式响应的超时判断AI网关要支持SSE流式输出但这个场景下的超时判断特别容易写错。如果只是简单设置一个全局的readTimeout当模型首字延迟高时就会误判超时如果不设超时遇到上游无响应连接会一直挂在那里占着网关的线程资源不释放。我们的解法是分两段处理第一段是从发出请求到收到首字设置5秒的超时第二段是从收到首字到流结束每帧间隔超过60秒才算超时。这样既照顾了模型“思考时间”又能及时止损。6.4 重试风暴的连锁反应有一次线上故障核心模型服务因为一个异常SQL导致性能劣化网关错误率上升微服务客户端开始疯狂重试。重试请求本身又占用了模型服务的线程池导致模型恢复变得更慢最终演变成了全链路雪崩。排查方式是看链路追踪里的重试日志你会发现同一笔请求被三个不同的服务各重试了三次最终打到模型服务上的次数是原始请求的十几倍。修复方案就是前面说的网关层做重试熔断限制单条链路的有效重试次数在网关入口统一拦截绝不依赖下游服务的自觉。6.5 指标数据千万别丢了在做成本优化前要确认网关的Metrics埋点覆盖到位。没有埋点就没有数据没有数据就无法证明哪一项优化真的有效。我建议至少覆盖这几个指标请求总量、缓存命中数、token消耗量、重试次数、上游调用失败数、网关自身CPU/内存/P99延迟。这些数据既是优化前拆解问题的依据也是优化后验证收益的依据。我们当时把Metrics从Prometheus迁到了VictoriaMetrics主要原因是Prometheus在长期存储和聚合查询上性能不够而网关的高频Metrics数据量又特别大。迁移之后查询一个月内的数据基本秒出排查问题时省了很多等待时间。7. 另一个灵活选项服务网格与云原生网关的混合路线这个项目做完大概三个月后我们团队又接触到了一个备选方案把网关周边的一部分通用能力比如限流、熔断、可观测性下沉到服务网格Istio和云原生网关比如Higress、APISIX里Java网关只保留最核心的AI适配逻辑。这个思路我现在的感受是它确实可以进一步降低开发和运维成本因为服务网格里已经内置了大量经过大规模验证的流量治理能力不需要自己造轮子。但引入它也有代价——运维复杂度会上升团队需要学习一套新体系排查链路的难度也会增加。如果是中小团队或者现有Java网关在成本上还有优化空间我建议先把网关本身的优化吃透再考虑上服务网格。不要为了架构而架构。如果你已经在用云原生网关估价下可以做的优化是把所有非业务逻辑鉴权外的限流、跨域、请求日志全部下沉到网关规则和插件里Java服务只处理纯业务转发和语义缓存这样Java侧的资源开销会进一步下降同时云原生网关的按量付费模式也能把闲置资源省掉。算是一个“双轨并行”的降本思路。8. 自查清单与优化要点速查表为了方便你直接落地我把这次优化的核心动作整理成一个检查清单。每个动作都标注了收益方向你可以按图索骥去排查自己的网关系统。优化方向具体动作主要收益缓存语义缓存 精确缓存 TTL降低模型调用量与token消耗请求合并批量聚合 伪批量减少HTTP往返与模型调用次数模型路由按任务难度分流到不同模型降低高成本模型的使用比例协议瘦身Header白名单、gzip压缩、流式拷贝降低带宽与网关CPU/内存连接池动态调节池大小、合理超时降低网关自身延迟与资源占用重试控制错误码白名单、指数退避、熔断防止重试风暴带来的账本膨胀限流配额按用户维度token消耗控制防止恶意/异常请求打爆账单观测体系全量Metrics 链路追踪支撑成本归因与优化验证这里的每一项除了技术本身还有两个共通的点值得强调一是所有优化动作都必须有数据指标支撑哪怕是预估的收益也要写进方案二是所有优化上线时尽量做开关控制方便出问题时一键回退而不是手忙脚乱地重新发版。9. 一些上了生产之后才明白的经验项目做完了账单也降下来了我最后想聊聊几个在代码之外获得的心得希望对你有些参考价值。第一个心得是成本优化永远是一个“权衡游戏”。你以为自己在优化技术指标实际上是在用户体验、稳定性、资金投入和研发人力之间找平衡。每一项优化都不是无脑做的都需要先问“这个优化会影响什么”再决定“值不值得做”。第二个心得是缓存和路由类优化最容易在“测试环境效果好、生产环境出问题”。因为测试环境的数据规模小、请求模式单纯你很难模拟出生产环境那种长尾请求和突发流量。所以如果可能尽量在生产环境做小流量灰度比如先用1%的请求去验证缓存命中率和误伤率确认没问题再逐步放量。第三个心得是和财务同学对账。优化上线后让财务或BI团队每月拉一次账单用token消耗量和费用两个维度对账。这样你才能真正知道自己省了多少而不是靠估算自我感动。我们有一次就因为计量口径不一致以为自己省了60%实际只省了35%后来统一了口径才算清楚。第四个心得是网关的优化不是终点而是起点。成本治理是要持续做的模型价格在变业务形态在变用户行为在变下个月你可能就需要新的路由规则、新的缓存策略。把这次沉淀的Metrics、监控大盘和复盘文档保持下来让后来者能站在你的肩膀上继续优化这个价值往往比一次性的降本数字更值钱。这些经验里最让我自己受用的还是那句话先让成本可以度量再谈成本优化。没有透明的账单和指标所有的优化都可能是在盲人摸象。希望这篇实践记录能帮你在AI工程化的路上少走几个弯路把网关这层“过路费”真正降下来。