AI网关成本优化实战：从模型路由到Token治理的省钱策略

1. 为什么AI网关会成为成本中心

1.1 直连模式下的隐性浪费

做AI工程化，很多人踩过的第一个坑就是"先不搞网关，直接调接口"。业务少的时候没问题，但模型一旦铺开，直连模式的账根本算不过来。

我见过一个团队，内部四个业务线分别接了大模型API，每个业务线各自实现了一套鉴权、重试、日志逻辑。表面上每个模块都正常，实际上同一个prompt在不同业务线被重复请求了三次，三份token账单，三份超时重试成本。这就是典型的"隐性浪费"——不是某一次调用特别贵，而是大量重复的调用在无人统一管理的情况下持续产生费用。

更麻烦的是，直连模式下每次模型升级、换供应商、调整配额，都要改每个业务方的代码。工程返工成本不直接体现在云账单上，但会占用人力，最终同样算进项目总成本里。网关的价值就在这里：把模型调用收口，让上游只关心业务请求，让下游的模型切换、降级、路由策略全部收敛到一层。

从这个角度看，Java网关不是"多一层转发开销"，而是成本治理的抓手。转发的网络开销通常在毫秒级，但省下来的token和运维成本往往是数量级的差距。前期投入一个网关，后续每个业务方接入都能复用同一套成本策略，这才是AI工程化里"工程"二字的含义。

1.2 网关成本构成的四张账单

在讨论优化之前，先把成本拆清楚。我按自己的经验把AI网关的支出分成四张账单：

这个拆法不是绝对的，但能帮你看清楚优化的优先级。模型调用费永远是大头，所以后面所有策略里，凡是能降低token消耗的手段都值得优先做。基础设施费要盯住"实例数×单实例资源"，很多团队喜欢横向扩容，结果机器开了一堆，CPU和内存利用率却不达标。观测日志费容易被忽略，网关流量一大，全量请求日志的存储成本非常惊人，必须引入采样。

我自己的习惯是每个季度做一次成本归因：把账单数据拉出来，按模型、按业务方、按时间段三个维度透视。哪个业务方的prompt特别长、哪个模型被无差别地用于所有请求、哪个时段的重试率异常高，一眼就能看出来。没有这一步，后边的优化都是盲目的。

2. 模型路由与降级策略：把请求打到最合适的模型上

2.1 分级模型池的设计

成本优化的第一刀，永远砍在模型选择上。同一个能力，不同模型档位的单价差距可以是几倍到几十倍。如果所有请求都走顶配模型，那就是在给供应商送钱。

我在网关里做的是分级模型池：把可用模型按能力和价格分成三档——Premium、Standard、Lite。网关内部维护一个路由配置，类似于这样：

public class ModelRoute { private final String routeName; // 路由名，例如 "chat-common" private final ModelTier primary; // 首选档位 private final List<ModelTier> 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); Optional<CompletionResponse> 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计算里剔除。第二个是采样参数不一致。同一个prompt，temperature一会儿是0.7一会儿是0.9，Key就分叉了。我的做法是，缓存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到400，keep-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加到6G，GC频率反而更高了，因为堆变大后回收时间变长，暂停时间暴涨。

实例数量不是越多越好。我见过一个团队为了满足可用性，把网关从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数 × 输出单价) / 请求总数

但这个平均指标掩盖了方差，所以要配合多维度的透视。我按以下维度做聚合：

埋点可以直接打在网关的响应拦截器里，每次调用把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调优——都不难，真正难的是持续盯住数据，让成本指标像业务指标一样被认真对待。