1. 为什么AI网关会成为成本中心1.1 直连模式下的隐性浪费做AI工程化很多人踩过的第一个坑就是先不搞网关直接调接口。业务少的时候没问题但模型一旦铺开直连模式的账根本算不过来。我见过一个团队内部四个业务线分别接了大模型API每个业务线各自实现了一套鉴权、重试、日志逻辑。表面上每个模块都正常实际上同一个prompt在不同业务线被重复请求了三次三份token账单三份超时重试成本。这就是典型的隐性浪费——不是某一次调用特别贵而是大量重复的调用在无人统一管理的情况下持续产生费用。更麻烦的是直连模式下每次模型升级、换供应商、调整配额都要改每个业务方的代码。工程返工成本不直接体现在云账单上但会占用人力最终同样算进项目总成本里。网关的价值就在这里把模型调用收口让上游只关心业务请求让下游的模型切换、降级、路由策略全部收敛到一层。从这个角度看Java网关不是多一层转发开销而是成本治理的抓手。转发的网络开销通常在毫秒级但省下来的token和运维成本往往是数量级的差距。前期投入一个网关后续每个业务方接入都能复用同一套成本策略这才是AI工程化里工程二字的含义。1.2 网关成本构成的四张账单在讨论优化之前先把成本拆清楚。我按自己的经验把AI网关的支出分成四张账单成本类型主要来源常见占比可控性模型调用费token消耗、API单价最高通常60%以上高路由/缓存/压缩基础设施费网关实例、JVM内存、带宽约20%中实例数/JVM调优工程返工费联调、排障、改接口约10%高统一抽象观测与日志费日志采集、指标存储约10%中采样策略这个拆法不是绝对的但能帮你看清楚优化的优先级。模型调用费永远是大头所以后面所有策略里凡是能降低token消耗的手段都值得优先做。基础设施费要盯住实例数×单实例资源很多团队喜欢横向扩容结果机器开了一堆CPU和内存利用率却不达标。观测日志费容易被忽略网关流量一大全量请求日志的存储成本非常惊人必须引入采样。我自己的习惯是每个季度做一次成本归因把账单数据拉出来按模型、按业务方、按时间段三个维度透视。哪个业务方的prompt特别长、哪个模型被无差别地用于所有请求、哪个时段的重试率异常高一眼就能看出来。没有这一步后边的优化都是盲目的。2. 模型路由与降级策略把请求打到最合适的模型上2.1 分级模型池的设计成本优化的第一刀永远砍在模型选择上。同一个能力不同模型档位的单价差距可以是几倍到几十倍。如果所有请求都走顶配模型那就是在给供应商送钱。我在网关里做的是分级模型池把可用模型按能力和价格分成三档——Premium、Standard、Lite。网关内部维护一个路由配置类似于这样public class ModelRoute { private final String routeName; // 路由名例如 chat-common private final ModelTier primary; // 首选档位 private final ListModelTier fallbacks; // 降级链 private final int maxInputTokens; // 该路由允许的最大输入token private final int budgetCents; // 单次请求预算上限 }路由配置用YAML或配置中心下发业务方接入时只需要指定routeName具体打哪个模型由网关决定。比如chat-common默认打到Standard档当Standard的延迟超阈值或配额不足时自动降级到Lite档。而需要深度推理的场景比如代码审查、复杂数据分析才显式指定Premium档。这套设计的关键不是分档本身而是让业务方没有绕过网关的理由。如果业务代码里还能随意指定model参数分档就是摆设。所以网关侧要做强制校验请求里的model字段要么为空走路由要么在允许名单内否则直接拒绝。我在实际落地时还加了一个路由白名单审批流程新增模型档位必须经过成本评估避免某个贪大求全的开发直接绕过路由写死顶配模型。2.2 动态路由的四个决策因子静态分档只是第一步真正有价值的动态路由要考虑四个因子意图类型通过请求的接口路径或提示词分类判断是简单问答、文档总结还是复杂推理上下文长度输入token越多单价越高长上下文请求可以优先考虑能效比高的模型预算上限每个调用方有月度或日度预算网关在额度快用尽时自动把流量切到低价档延迟容忍度同步交互场景对延迟敏感优先速度快的模型异步批处理场景可以接受较慢但便宜的模型。这四个因子在网关里合成一个路由决策结果。我推荐用一个轻量的打分函数而不是复杂的规则引擎否则规则多了以后自己都改不动。每个因子按0到1打分乘以权重求和按得分排序选择目标模型档位。权重可以放在配置中心里动态调比如大促期间把预算上限的权重调高平时把意图类型的权重调高。这里要强调一点动态路由一定要有可解释性。每次路由决策都要记录为什么选了这一档否则一旦线上出问题你根本不知道请求为什么被降级了。我在路由结果里会附带决策原因编码比如REASON_BUDGET_EXHAUSTED、REASON_MAX_INPUT_EXCEEDED排障时非常有价值。每个决策都会写进结构化日志配合链路追踪可以完整还原一次请求的模型路径。2.3 降级与重试的正确姿势网关里的重试和降级是两个经常被混为一谈的东西。重试是指同一个模型再试一次降级是换一个模型。两者的成本含义完全不同重试可能让费用翻倍降级是让单价降低。我的经验是网络错误和限流错误可以重试但需要退避而内容错误比如模型返回格式异常、拒绝回答不要重试直接走降级链。因为内容错误重试大概率还是同样结果白白多花一次token。这个判断我最早也做反过线上有一阵重试率陡增排查了半天发现是某个模型对特定prompt稳定返回空内容网关还在傻乎乎地重试三遍费用翻了几倍。public CompletionResponse invokeWithFallback(GatewayRequest req) { ModelRoute route routeRegistry.resolve(req.getRouteName()); for (ModelTier tier : route.getFallbackChain()) { try { return modelClient.invoke(tier, req); } catch (RateLimitException e) { int retryAfter e.getRetryAfterSeconds(); if (tier.equals(route.getPrimary()) retryAfter 10) { sleepWithJitter(retryAfter); return modelClient.invoke(tier, req); } } catch (ModelReturnedErrorException e) { // 内容错误不重试直接换档 continue; } } throw new GatewayFallbackExhaustedException(route.getRouteName()); }重试时要加抖动jitter避免多个请求同时重试打爆限流。我习惯用指数退避随机抖动初始300ms最多重试3次。降级链的长度一般控制在两跳以内超过两跳说明路由配置有问题应该回到配置排查而不是继续往下试。降级链的每一跳都要记录耗时和结果否则你只能看到最终异常看不到中间哪一跳浪费了最多时间。3. 缓存层设计把重复的钱彻底省下来3.1 精确缓存与语义缓存的边界缓存是token成本优化里见效最快的手段但也最容易做坏。我先说结论网关里至少要做两层缓存——精确缓存和语义缓存它们的适用场景完全不同。精确缓存就是完全相同的请求直接返回旧结果。适用场景是低风险、稳定性要求高的调用比如数据查询类的自然语言转SQL、固定的运营文案生成。Key是请求参数的规范化拼接比如归一化之后的prompt、模型档位、采样参数的组合。命中时直接从Redis返回不调用模型成本为零。语义缓存是意思相同但表述不同的请求用历史结果返回。比如某业务方上午问上个月订单量是多少下午问上个月的订单数有多少精确缓存永远命中不了但语义上完全一致。实现方式是给请求文本做embedding然后在向量库里做相似度检索超过阈值我常用0.92到0.95就复用缓存结果。这里要划清边界精确缓存可以在所有请求上开启语义缓存只适合确定性场景。凡是结果需要强时效性比如股价、天气或者内容需要多样性的场景比如营销文案、头脑风暴语义缓存一律关掉否则用户会看到一个老是被重复答案的机器人体验反而崩了。我见过一个团队把语义缓存用在了新闻摘要接口上结果所有用户拿到的都是同一篇历史摘要差点酿成事故。3.2 网关里的缓存写入与失效策略缓存写入放在哪一层很多人会搞错。不要在业务方写缓存也不要在模型响应之后单独做一层事后缓存而是要在网关转发之前先查、转发成功之后再写。我的实现是标准Cache Aside模式public CompletionResponse handle(GatewayRequest req) { String cacheKey cacheKeyBuilder.build(req); OptionalCompletionResponse cached cache.get(cacheKey); if (cached.isPresent()) { metricRecorder.recordCacheHit(req.getRouteName(), cacheKey); return cached.get(); } CompletionResponse resp invoker.invokeWithFallback(req); if (resp.isSuccess() !resp.isTruncated()) { cache.set(cacheKey, resp, route.getCacheTtlSeconds()); } return resp; }有两点需要注意。第一只有完整的、没有触发截断的响应才应该写入缓存如果响应因为max_tokens不够被截断了写入缓存会把不完整的内容反复发给用户。第二TTL不要拍脑袋定要根据业务场景设置。对于数据报表类请求我通常设300秒对于静态知识型问答可以到24小时对于实时性高的场景就不写缓存。我还在缓存里存了写入时间和模型版本模型升级时可以把对应版本的缓存批量失效掉避免新旧模型结果混着返回。3.3 缓存命中率上不去的原因排查如果你的精确缓存命中率低于预期先别急着怀疑缓存框架大概率是Key设计的问题。最常见的坑有三个。第一个是提示词里的无关变量。很多请求文本里带了当前时间、随机数、用户ID等字段导致Key永远不一样。排查方法是把请求参数打散看哪些字段的高基数是异常的然后把它们从Key计算里剔除。第二个是采样参数不一致。同一个prompttemperature一会儿是0.7一会儿是0.9Key就分叉了。我的做法是缓存Key只考虑temperature为0或低采样场景高采样场景默认不参与精确缓存。第三个是字符串空白和全角半角差异。提示词里多了个换行、全角括号变成半角Key就变了所以Key构建前要做字符串归一化去首尾空白、统一换行符、统一全半角。语义缓存命中率低的原因则一般是相似度阈值设得太高。阈值高精度高但召回少。我建议先从0.90开始压测观察线上误命中比例如果用户反馈答非所问的比例可以接受再逐步降到0.85。宁可少命中一点也不能让不相关的内容以高相似度复用到别的请求上。语义缓存的向量本身也要考虑维度大小256维和768维的存储成本差很多在满足效果的前提下选低维方案。4. Token治理请求入口的消费控制4.1 系统提示词的成本审计模型调用的账单由输入token和输出token共同决定而输入token里最被忽视的就是系统提示词。很多团队的提示词是从业务方那里拼出来的越叠越长动辄两三千token而且每个请求都带上费用呈线性放大。我做了一次审计之后发现业务系统里一条普通的知识问答请求系统提示词占了整个输入token的70%以上。把提示词压缩掉一半同等业务量下模型调用费直接降了两成。压缩手段并不玄乎去掉形容词、合并重复的指令、把冗长的few-shot例子换成更精简的版本、公共约束抽到网关层统一维护而不是每个业务方各写一份。网关里还应该做一道硬校验提示词长度上限。超过阈值的请求要么拒绝要么强制走摘要预处理链路先用便宜的小模型把长文本压缩成固定长度的摘要再送给大模型。这个先小后大的模式在文档分析、长对话场景里非常好用整体成本能降30%到50%。我第一次给一个合同审核业务上线这个链路时对方一开始担心小模型摘要会丢信息后来我把摘要长度调到刚好覆盖关键条款后对接方就接受了。4.2 上下文窗口裁剪的两种常用策略多轮对话是最容易烧token的场景。每轮都把完整历史记录传进去上下文越来越长成本越来越高而且模型还可能被早期闲聊信息干扰。网关需要在把请求发给模型之前对上下文做一个瘦身。我实践过三种裁剪策略排个优先级滑动窗口只保留最近N轮对话适合闲聊型和客服型场景N通常取10到20轮。实现简单是性价比最高的起点。摘要层每满M轮就把之前的对话交给小模型生成一版摘要后续请求用摘要加最近几轮原文适合需要长程记忆的场景成本和控制力的平衡最好。语义筛选给每轮对话打embedding计算与当前问题的相关性只保留相关性高的轮次效果最好但计算成本最高适合对质量要求极苛刻的场景。三种策略我在网关里做成了可配置的Pipeline每个路由可以声明自己的上下文处理方式。对于混合场景我建议是组合式方案滑动窗口兜底摘要层兜底早期信息最后做语义筛选做精修。不要一上来就上最复杂的那套先跑通前两种观察语义漂移情况再决定。我见过一个团队直接上语义筛选结果每轮对话都要做embedding向量服务的成本比省下的token还多。还要说一个输出token的控制。max_tokens直接限制输出成本很多业务方不设置这个参数模型就会把整个输出窗口答满。网关层应该给每个路由设置默认的max_tokens上限并且把输出截断的信号记录到日志里如果大量请求触顶说明这个路由的max_tokens配置过小需要单独调大而不是全局放宽。我习惯在响应里额外回传一个usage包含promptTokens、completionTokens和truncated标志方便做成本核算和质量监控。5. JVM与基础设施层面的省钱空间5.1 连接池与HTTP客户端的调优网关的转发延迟和吞吐很大程度取决于HTTP客户端配置。默认情况下每创建一个连接都要经历TCP握手和TLS握手在AI请求这种高延迟交互里连接开销会直接影响网关实例的资源利用率。我用的是OkHttp两个关键参数是连接池大小和keep-alive时间。连接池太小会导致频繁建连太大又可能空占文件描述符。以4核8G的实例为例我建议连接池per-host控制在200到400keep-alive设置为300秒空闲连接超过60秒就回收。JVM自带的HttpClient也可以做但配置项更底层普通团队没必要在这个层面折腾除非你有非常明确的性能瓶颈证据。还有一个容易忽略的点HTTP客户端超时时间和模型接口的超时时间要匹配。如果client端超时比模型平均响应时间短网关会大量超时重试费用翻倍如果设得太长用户感知的延迟会很难看。我一般把连接超时设为3秒读取超时设为模型P99延迟的1.5倍并按模型档位分别配置。比如Standard档P99是4秒读取超时就设6秒Premium档P99是8秒读取超时就设12秒。5.2 内存占用、GC与网关实例数Java网关在AI场景下最大的基础设施成本其实是内存。JVM默认的堆配置不针对网关这种短请求、多线程的负载做优化很容易出现堆内存使用率低但GC频繁的现象。我的调优建议堆内存不要超过物理内存的一半留足给堆外内存、线程栈和Metaspace。4核8G的实例堆设3G到4G就够不要贪大。GC选择上如果JDK 17以上ZGC在高吞吐网关场景的表现不错但需要测试验证不想折腾就用G1把暂停时间目标设为50ms到100ms。关键动作是做一次压测记录GC暂停时间和吞吐率再根据结果调整。我见过一个团队把堆内存从4G加到6GGC频率反而更高了因为堆变大后回收时间变长暂停时间暴涨。实例数量不是越多越好。我见过一个团队为了满足可用性把网关从2个实例扩到8个结果QPS并没有翻四倍因为瓶颈在模型接口的限流而不是网关本身。网关的容量规划必须以后端模型通道的并发上限为基准而不是以网关能接多少QPS为基准。模型通道允许多少并发网关就维持多少并发实例多余的都是纯浪费。所以我在做容量规划时会先跟模型供应商确认并发上限或者用压测打探出通道的真实瓶颈再反推实例数。5.3 异步化与线程模型的收益网关的每次AI调用都是秒级响应如果每个请求占用一个线程等模型返回线程数很快就会打满然后被迫扩容。Java生态里解决这个问题的标准方案有两种响应式编程和虚拟线程。如果项目是Spring Boot 3.2以上我强烈建议直接试虚拟线程。配置非常简单把Tomcat的executor换成虚拟线程即可代码几乎不用改。虚拟线程在等待I/O时不占用平台线程网关实例可以用很小的线程资源支撑几百个并发AI调用实例数可以直接减半。我在一个老项目上测试过同样是2个实例虚拟线程方案能扛住的并发A I请求数是平台线程方案的4倍多代价只是极轻微的CPU占用上升。这里要提醒一句虚拟线程不是万能药。如果代码里有大量的CPU密集计算比如每次都做全量向量距离计算虚拟线程的优势会被抵消因为CPU资源还是有限的。网关里的CPU密集任务应该抽到专门的线程池或者放到独立的计算服务里保持I/O密集型主链路的轻盈。像语义缓存里的向量相似度计算我就单独放到一个检索增强模块里异步执行不让它阻塞主请求链路。6. 成本观测与回归验证6.1 成本指标的埋点设计没有观测的优化都是盲目的。我比较推崇在网关里建立一套单位请求成本Cost Per Request, CPR指标把它当成网关的北极星指标。CPR的计算公式很简单CPR (输入token数 × 输入单价 输出token数 × 输出单价) / 请求总数但这个平均指标掩盖了方差所以要配合多维度的透视。我按以下维度做聚合维度作用路由名发现哪些路由最烧钱模型档位验证降级是否真的省了钱业务方找出prompt体量异常的调用方时间段配合流量峰值判断是否存在浪费缓存命中率判断缓存策略是否健康埋点可以直接打在网关的响应拦截器里每次调用把model、inputTokens、outputTokens、costCents、routeName、cacheHit等字段写进Prometheus的Counter或Histogram然后接Grafana出图。日志系统里也同步打一条结构化日志方便做追溯分析但日志量建议抽样比如全量日志只保留1%到5%其余只保留聚合指标避免观测成本反过来侵蚀成本优化的收益。6.2 一次真实的优化复盘说一个我自己做过的案例给各位一个直观感受。我们的知识库问答网关做优化前CPR约为0.35美元每千次请求模型调用费占总支出的72%。第一步上线分级模型路由把简单事实性问题从Premium档切到Standard档CPR降到0.27。第二步上精确缓存问答场景的缓存命中率做到38%CPR降到0.19。第三步压缩系统提示词并加上下文滑动窗口CPR降到0.15。最后把网关实例从6个减到4个并切换虚拟线程基础设施成本直接减半。整个链路优化下来月度总成本下降了大约55%。收益的关键在于每一步都先用数据确认了优化空间而不是上来就重构。第一版路由上线前我花了三天把历史请求按意图复杂度和模型档位做了离线回放确认有40%的请求可以用低价档覆盖才敢动代码。后来上缓存之前我又跑了一周的缓存命中率模拟确认至少30%的请求是重复的才把缓存方案确定下来。6.3 持续防退化机制成本优化不是一次性的工作最大的敌人是回归。业务方会逐渐往提示词里塞需求、调用频率会悄悄上升、模型供应商会调整价格表这些都是成本退化的来源。我建议在网关里跑两条防退化机制。第一条是成本护栏按路由设置每日预算告警达到阈值80%时通知负责人100%时自动把流量切到更低档位并发出高优警报。第二条是周度成本报告每周拉一次CPR趋势和上周对比凡是有超过10%增量的路由自动触发定位流程。这两条机制不需要很重的开发量但能确保成本优化成果不被时间侵蚀。我现在还会在季度例行巡检里做一次降级有效性验证故意把模拟请求打到某个高优模型通道上观察网关是否正确降级到低价档以及降级后的响应质量是否达标。验证通过后我才会在周报里确认成本策略没有退化。这个习惯帮我抓出过一次问题——某个新版本上线时路由表配置漏了一条降级链直接断掉高优请求打到低价模型后质量明显下滑要不是验证机制跑得早线上用户早就开始骂了。最后再分享一个体会成本优化的核心不是抠门而是让每一分钱都产生对应的业务价值。Java网关做成本优化的每个环节——路由、缓存、Token治理、JVM调优——都不难真正难的是持续盯住数据让成本指标像业务指标一样被认真对待。