AI 工程化做了两年多我接手的最头疼的一块不是模型推理本身而是网关层。Java 网关在 AI 流量进来之后成本膨胀速度远超你预期。今年初我们花了几周专门做 Java 网关成本优化把资源开销压缩了近四成延迟反而稳了一点。这篇就把整个优化过程完整复盘一遍包括为什么要从 JVM 下手、IO 模型怎么改、弹性伸缩怎么做、依赖和镜像瘦身怎么落地以及最后怎么把“省钱”这件事变成可持续的工程机制。如果你也在用 Java 做 AI 场景的 API 网关或者正准备接大模型业务这篇内容可以直接当作参考这里面的思路、参数、指标、排错过程都是我拿真实环境验证过的。1. AI 流量涌入之后Java 网关为什么先“贵”起来先看一个现象AI 能力接入业务线之后网关节点的成本往往不是线性增长而是跳变式增长。原因不是网关代码变复杂而是流量特征变了。1.1 AI 网关不再只是转发请求过去我们做 API 网关核心工作就是路由、鉴权、限流、灰度、日志。这些功能对资源消耗相对可控一个请求从入到出可能只有几十毫秒连接短、吞吐稳定。但 AI 场景下Java 网关的职责多了一大截模型路由同一个网关后面可能挂了多个模型服务甚至同一模型的多个版本需要按业务线、按用户、按上下文做路由。上下文管理与缓存为了让模型连续对话网关层要做会话上下文汇总、缓存、裁剪这增加了内存和存储压力。流式响应中转大模型接口普遍走 SSE 或流式返回网关需要把上游的流一点一点转发给客户端单个连接持续时间从几百毫秒变成几十秒甚至几分钟。多租户隔离和计费AI 能力通常按 token 或按调用次数计费网关要实时聚合数据往计费系统写指标。内容安全与过滤输入输出都要过一遍过滤和审核逻辑这属于额外 CPU 开销。这些新职责意味着每一条请求的“生命周期”变长了。原来一个线程几十毫秒就能释放现在要hold住几十秒。连接数、内存占用、CPU 峰值一起往上走成本自然失控。1.2 成本构成拆开看钱到底花在哪我把网关成本拆成四块成本项来源为什么 AI 场景下陡增计算资源CPU加解密、限流、过滤、流式转发、序列化流式转发的每一个 chunk 都要消耗 CPU长连接下总 CPU 消耗远高于短请求内存资源堆内堆外JVM 堆、反射缓存、Netty 缓冲、线程栈长连接高并发导致线程数增长堆外 DirectMemory 被大量占用网络与带宽网关到模型服务、网关到客户端流式响应让网关承担了大量中转流量带宽成本被忽略了固定成本容器、Pod 空转、监控、日志存储为了保持低延迟很多团队习惯长期多开几个副本空闲时也在烧钱很多团队看到成本报表时只盯着 CPU 使用率忽略了内存和带宽。尤其是 Java 服务JVM 默认配置往往和容器资源完全脱节等于钱花了不少资源利用率却很低。1.3 一个典型的 AI 网关请求链路画一条最常见的链路你就明白问题了客户端 - Java网关上鉴权、限流、路由 - 模型服务推理 客户端 - Java网关上SSE流式转发 - 模型服务流式输出这条链路的特征是模型推理时间越长网关上占用资源越久。模型服务是 IO 密集型的往往还带 GPU但你在网关上顶着的是一整个 Java 线程池。如果用的是默认的 Tomcat 阻塞线程池200 个并发流式请求就是 200 个线程被长时间占用每个线程默认栈大小 1MB光线程内存就是 200MB再加上上下文切换和 GC 压力成本想低都难。所以Java 网关成本优化本质上是三件事让每一份内存、每一核 CPU 都真正处理请求而不是空转让资源能跟着流量峰谷走而不是永远按峰值备着把每一项优化收益量化出来让成本不再是“感觉贵”而是“账本上看得见地降”。下面我开始讲实际动手的过程。2. 先从 JVM 下手内存、GC 和线程的省钱空间动任何代码之前先想清楚一件事Java 网关的很多成本浪费其实不是业务代码造成的而是 JVM 默认配置和业务特征不匹配。AI 网关这种典型的长连接、高并发、延迟敏感场景只要把 JVM 层面对齐收益立竿见影。2.1 先看监控数据再决定动哪里我的习惯是没有任何监控数据之前不做任何调优。盲调 JVM 参数大概率会把系统调坏。需要看的关键指标堆内存使用趋势包括 Eden、Survivor、Old 区占用GC 频率与暂停时间重点关注 Full GC 和 Young GC 的平均/最大耗时线程数活跃线程数、Tomcat 线程池使用率、等待队列长度堆外内存Netty 分配的直接内存、反射类元数据占用。我是用 JDK 自带的 JFR 加 Grafana 看的。开启 JFR 的代价很低比提前瞎猜靠谱多了。注意很多 Spring Boot 项目默认开启了 actuator但只暴露了基础指标最好把 JFR 的关键事件和 micrometer 的 JVM 指标全部接出来至少观察 3-5 天的业务高峰期再做判断。2.2 三个常见的隐形内存开销看监控数据时最容易被忽略的三个地方也是我这次优化的主要切入点。堆内存设置和容器内存脱节很多人的 Java 网关部署在容器里-Xmx却还是默认值或者干脆没设置。一个 4G 内存的容器JVM 默认可能只用了 1/4 的堆剩下的全被操作系统缓存或空余浪费。更常见的是反过来容器内存只有 4G-Xmx却写 4G加上 Metaspace、线程栈、堆外内存容器直接 OOM Killer 干掉。我的做法是先把堆内存和容器内存的关系理顺。比如容器内存 4G我会把堆控制在 2G 左右Metaspace 256M线程栈统一 512K堆外预留一部分给 Netty。这样既保证 JVM 不 OOM又不会过度浪费内存配额。线程栈大小Java 每个线程默认栈大小和平台相关Linux x64 下通常是 1MB。网关一旦有几百个并发流式连接线程数很容易到几百甚至上千光线程栈就要吃掉几 GB 虚拟内存而且这些内存不是“用了才算”是线程创建时就会分配。优化方式-Xss512k从 1MB 降到 512k线程内存直接减半。如果你的线程数常年上千这个参数比任何业务优化都管用。但这个参数不能无脑降递归深的业务代码可能栈溢出建议先做一轮压测再定。堆外 DirectMemoryAI 网关做流式转发Netty 的堆外内存池是很大的开销来源。默认情况下Netty 会根据 JVM 最大堆内存计算可用 DirectMemory但如果你用了-XX:MaxDirectMemorySize或者没设置行为会不一样。我踩过的一个坑是上传下载和流式响应混在一起堆外内存被瞬间打满然后开始频繁 GC 甚至 OOM。解决办法是给 Netty 设置合理的-Dio.netty.maxDirectMemory同时配合-XX:MaxDirectMemorySize控制总量。这类参数不是越大越好够用就行。我的经验是DirectMemory 设为堆内存的 1/4 到 1/2再通过监控观察是否触顶。2.3 GC 调优从 CMS/G1 到 ZGC 的取舍Java 网关在高并发、低延迟场景下GC 停顿直接影响请求毛刺。我们的网关从 JDK 11 升级到了 JDK 17开始使用 ZGC 前先用 G1 跑了一阵。两种 GC 在网关场景下的对比指标G1ZGC平均 GC 停顿10-50ms1-5ms吞吐量高略低于 G1但 AI 网关更看重延迟大堆场景可能需要调 Region 大小适合几十 GB 堆适配度通用稳定长连接低延迟场景更友好最终我们选了 ZGC配合下面的参数java -XX:UseZGC \ -Xms2G -Xmx2G \ -XX:MetaspaceSize256m -XX:MaxMetaspaceSize256m \ -Xss512k \ -XX:MaxDirectMemorySize1g \ -jar ai-gateway.jar最关键的一点是-Xms和-Xmx设置一致避免 JVM 动态扩堆造成的性能抖动。ZGC 在高并发长连接场景下的表现确实稳最大停顿时间从原来的 50ms 左右降到了 5ms 以内。当然不是所有项目都适合无脑上 ZGC。如果你的网关堆很小、GC 本来就没什么压力上 ZGC 反而可能因为额外开销导致吞吐下降。一切以监控数据为准。3. IO 模型改造用异步替代阻塞把资源占用打下来JVM 调优是第一步真正的结构性优化其实是 IO 模型。Java 网关原来的问题不是代码写得差而是阻塞式线程模型根本承接不住 AI 流式流量。3.1 阻塞式处理在 AI 网关场景的代价传统的 Spring MVC Tomcat 是“一个请求一个线程”模型。短请求没问题但 AI 网关每条请求持续时间很长尤其是 SSE 流式响应线程要一直占着等上游 chunk再转发给客户端。假设单条请求平均持有线程 20 秒QPS 是 500那至少需要 10000 个线程才能稳定支撑。线程多了之后内存暴涨线程栈CPU 大量消耗在线程上下文切换上线程池队列积压延迟飙升Tomcat 默认最大线程数 200稍微一压测就拒绝连接。所以阻塞模型在 AI 网关场景里既费钱又不够用。3.2 迁移到异步非阻塞的关键动作异步非阻塞改造有两条主流路线路线一Spring WebFlux Netty全面响应式路线二保持 Spring MVC 风格内部用 JDK 21 虚拟线程替代平台线程。两条路我都试过。WebFlux 收益上限高但改造范围大网关里的每个中间件、每个 HTTP 调用都要跟着响应式化很多老库不支持。虚拟线程则简单得多代码不用大改只要把容器线程池换成虚拟线程池就能明显降低线程开销。我的建议是如果团队没有响应式经验优先考虑虚拟线程。在 JDK 21 下Spring Boot 3.2 支持直接开启虚拟线程。spring.threads.virtual.enabledtrue这个配置一行就能生效。Tomcat 的阻塞连接器在虚拟线程下每个连接不再占一个平台线程而是挂在一个轻量级虚拟线程上线程栈内存从 1MB 降到几十 KB线程数上限也大幅提升。如果走 WebFlux 路线核心是禁止在请求链路里出现阻塞调用比如// 不要这么写同步调用模型服务 RestTemplate restTemplate new RestTemplate(); String result restTemplate.getForObject(http://model-server/invoke, String.class);// 改成这样用 WebClient 异步调用 WebClient webClient WebClient.builder().build(); MonoString result webClient.get() .uri(http://model-server/invoke) .retrieve() .bodyToMono(String.class);WebFlux 的核心价值是线程数恒定默认 CPU 核数×2不需要为每个请求分配一个线程靠事件驱动就把海量连接处理掉了。这对流式转发特别友好。3.3 收益和坑改造完之后的效果我记录过一组数据网关线程数从平均 800 降到 40 左右CPU 使用率在相同 QPS 下下降约 20%长连接支撑能力从 200 并发左右提升到 2000垃圾回收频率因为线程栈和对象分配大幅减少Young GC 频率明显下降。但是有几个坑必须提醒坑一ThreadLocal 失效。异步线程模型下请求会在线程间切换直接用 ThreadLocal 存业务上下文会丢。当时我们一堆过滤器里存了用户 ID改造后读出来全是 null。解决方案是使用 Reactor Context 或者把上下文显式传递。坑二JDBC 等阻塞调用会堵死响应式线程。异步模型最忌讳在响应式链里混入同步 JDBC 访问一旦一个连接慢整个事件循环都可能被拖住。AI 网关联的 Redis 和 MySQL 都有专门的非阻塞客户端尽量用那些。坑三背压处理。流式响应必须考虑下游比上游慢的情况。如果客户端消费速度跟不上就得丢弃、缓存或断开连接否则内存会爆。Netty 的 TCP 窗口和响应式背压机制要配合起来这个不能靠默认配置。我的经验是IO 模型改造宁可做慢一点也别一次全量切换。先在网关的一组节点上跑一两周对比延迟和资源曲线觉得稳了再全局切。4. 弹性伸缩与流量治理把每一核 CPU 用在真正的流量峰值上网关成本优化的另一半在“流量治理”。AI 业务流量有明显的潮汐效应白天工作时段高峰凌晨可能只有十分之一的量。如果网关副本长期按高峰期固定部署那低谷期每一份资源都是纯浪费。4.1 成本优化的本质是削峰填谷我见过不少团队为了保可用性网关副本数常年按“历史上最大的流量峰值”来配。这种做法能保证不挂但成本会高得离谱。正确的思路是让副本数跟着实时流量走高峰期多用资源低谷期释放资源。这需要弹性伸缩能力而弹性伸缩的前提是“流量治理做得好”——如果限流熔断不靠谱你根本不敢缩容因为一旦有个流量尖峰系统就崩。所以我把流量治理和弹性伸缩放在一起讲。它们是同一个硬币的两面。4.2 结合网关指标自动扩缩容Kubernetes 环境下弹性伸缩标准做法是 HPA。但对 Java 网关来说直接用 CPU 作为 HPA 指标不够准。网关是 IO 密集长连接场景CPU 使用率低不代表没压力连接数和排队延迟才是关键。我给网关设计了一套自定义指标全是从 Prometheus 拉出来的活动连接数Active Connections请求平均处理时间请求延迟排队中的请求数队列积压GC 暂停时间P99 GC pauseCPU 使用率作为辅助指标。HPA 配置大致长这样apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: ai-gateway-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: ai-gateway minReplicas: 3 maxReplicas: 20 metrics: - type: Pods pods: metric: name: gateway_active_connections target: type: AverageValue averageValue: 500 - type: Pods pods: metric: name: gateway_request_latency_p99 target: type: AverageValue averageValue: 300注意一点AI 网关扩容要留一点缓冲不要等延迟真的涨到 300ms 才扩。我们用的是“延迟超过阈值 2 分钟且趋势不降”才触发扩容避免瞬时毛刺造成抖动。4.3 阈值设计和缩容防抖缩容比扩容更难。缩容太激进流量稍微反弹就把系统打爆缩容太慢又起不到省钱效果。我的经验是扩容阈值放低一点只要活动连接数连续 1 分钟超过阈值的 70%就扩容缩容阈值拉长观察窗口连续 15 分钟低于缩容阈值才缩容设置最小副本数不要缩到 0否则冷启动延迟会把第一批请求拖垮加一个缩容保护如果最近 5 分钟内有扩容动作则暂不缩容。HPA 自带的--horizontal-pod-autoscaler-cpu-initialization-period、--horizontal-pod-autoscaler-sync-period这些参数也要配合调默认值在长连接场景下不够敏感。实践下来AI 网关缩容到 3 个副本比保持 10 个副本每月能省下的 Pod 成本差不多是原来的 60%。前提是限流熔断指标要特别可靠缩容后一旦出现流量毛刺限流会把超出的请求挡住而不是让整个网关雪崩。4.4 冷启动与预热缩容省的每一分钱扩容时可能都得还回去缩容省了资源但每次扩容的冷启动成本会被很多人忽略。Java 应用启动要经过 JVM 初始化、Spring 容器加载、连接池初始化耗时可长可短。如果扩容后要 30 秒才就绪这 30 秒里新 Pod 既扛不住流量还白占资源。所以我们在网关里加了预热逻辑启动阶段先加载基础路由和鉴权规则再打开流量入口K8s 的readinessProbe配合一个内部/ready接口使用startupProbe让新 Pod 在 JVM 完全拉起之前不要被杀掉。startupProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 10 periodSeconds: 5 failureThreshold: 30这个看起来是小细节但对成本和稳定性都很有价值。5. 依赖、镜像和发布链路固定成本的流水线式瘦身除了运行时的弹性伸缩和 JVM 调优Java 网关还有一块容易被忽视的固定成本依赖、镜像、启动时间、发布链路。它们不会因为流量低就自动减少属于“躺着也在烧钱”的部分。5.1 Java 网关里常见的不必要开销我拿到网关代码后做了一次依赖审计。结果发现引入了几个很大的通用工具包但真正用到的类不到 5%同一个功能有多个库实现比如 JSON 解析同时用了 Jackson 和 GsonSpring Boot 自动配置扫描了一堆不需要的组件为了兼容老接口保留了过时的序列化依赖。这些依赖不只让镜像变大还让启动变慢并增加内存占用。启动时 Spring 要扫描的 Class 越多JVM 要加载的元数据越多Metaspace 占用越高。我用 Maven 插件做了依赖分析mvn dependency:analyze重点看Used undeclared dependencies和Unused declared dependencies这两类报告把未使用的依赖一个一个清掉。注意自动配置类的依赖不能只看编译期是否用到还要看运行时有没有通过 SPI 机制被加载。建议清一个依赖就做一轮压测。5.2 基础镜像与分层缓存Java 网关的 Docker 镜像以前用的是openjdk:11-jre-slimJava 基础镜像体积大分层缓存也不理想。后来我们换成了eclipse-temurin:17-jre-alpine再用 jlink 做一个自定义 JRE。用 jlink 可以只保留运行时真正用到的模块jlink \ --add-modules java.base,java.logging,java.naming,java.security.jgss,java.sql,java.management \ --strip-debug \ --no-man-pages \ --no-header-files \ --vmserver \ --output /opt/jre-minimal打完精简 JRE 之后镜像从原来的 400MB 左右降到了 150MB 左右启动时间也少了好几秒。Dockerfile 建议采用多阶段构建FROM maven:3.8-eclipse-temurin-17 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests FROM eclipse-temurin:17-jre-alpine RUN apk add --no-cache tzdata COPY --frombuilder /app/target/ai-gateway.jar /app/ai-gateway.jar COPY --frombuild /opt/jre-minimal /opt/jre-minimal ENV JAVA_HOME/opt/jre-minimal ENV PATH$JAVA_HOME/bin:$PATH EXPOSE 8080 ENTRYPOINT [java, -jar, /app/ai-gateway.jar]这样构建缓存也能用起来只要pom.xml不变mvn dependency:go-offline这一层就不会重新执行CI 时间和成本都能降。5.3 启动时间与发布链路成本你可能觉得启动时间跟成本没关系。但 AI 服务发布频繁每次发布都涉及构建、镜像推送、拉取、启动、就绪检测模块越多流程越长CI 资源消耗越大。尤其是发布窗口叠加流量高峰启动慢还容易造成容量缺口。我们优化之后网关平均启动时间从 35 秒降到 18 秒左右。这对动态扩缩容非常重要冷启动快你才敢在低谷期大胆缩容因为即使流量突然上来扩容也能在几十秒内完成。除了镜像日志链路也要关注。AI 网关的请求日志可能包含上下文中大量文本随便打一条 debug 日志就是几 KB在请求量大的时候日志存储成本比容器成本还高。我们给网关加了结构化日志和采样开关生产环境只记录核心字段和错误堆栈。6. 成本量化与持续优化机制让每次省钱都能被度量成本优化做得再多如果不量化领导不认可团队也无法判断方向对不对。所以最后一部分是我最看重的把成本变成可度量、可对比、可持续跟踪的工程指标。6.1 建立单位请求成本模型我定义了一个核心指标单请求成本。单请求成本 网关总成本Pod 费用 内存追加 带宽费用 日志存储 / 有效请求总数实际操作中把成本拆成两块固定成本按 Pod 数、实例规格、运行时长估算变动成本按带宽流量、日志量、GPU 或外部 API 调用量估算。在 Prometheus 里我们把总成本按时间维度打到了指标上// 用 Micrometer 注册一个自定义指标按 Pod 和部署周期统计 MeterRegistry registry new SimpleMeterRegistry(); Counter.builder(gateway.cost.estimated) .description(Estimate gateway cost by requests) .register(registry);监控面板上就可以看到每天的有效请求总数网关资源总成本单请求成本曲线优化前后的成本对比。有了这个模型团队里的每个人都能说清楚“这次优化到底省了多少钱”。6.2 用灰度 A/B 验证每一次优化任何成本优化都不能直接一刀切上生产。我的做法是准备两套网关集群一套保留旧配置一套跑新参数流量按比例灰度。验证指标包括请求成功率延迟P50/P95/P99CPU 和内存使用率单请求成本容器重启次数。比如验证 JVM 参数优化时我们对比了 ZGC 和 G1 两组的 P99 延迟ZGC 组明显更稳。而验证响应式改造时我们特意用流量高峰期对比效果才显著。A/B 验证的关键是优化前后至少压测一轮同规模流量的数据别拿日常流量的低负载数据来对比那样看不出差异。6.3 把成本预算写进 CI/CD 流水线成本优化最怕回退。可能某天一个人改了个依赖或者调了个线程池参数成本就偷偷涨回去了。所以我把成本检查变成了 CI 的一部分。在构建流水线里检查 Docker 镜像大小超过阈值直接告警检查 JVM 启动参数禁止缺失-Xmx、-Xss等关键配置每次发布前生成一份依赖清单对比上一版本是否有明显膨胀每周生成一次成本趋势报表异常波动自动发到团队群。另外我在代码仓库里维护了一份cost-review.md记录每次优化前后的成本数字和操作原因。新同学来了之后不用问“之前为什么这么配”直接看这个文件就能理解。这种机制比任何一次“大优化”都重要。成本优化不是一次性的手术而是长期维护的习惯。你不可能每季度都做一次大改造但你可以每季度都看清数字只允许成本小幅波动不允许无理由暴涨。最后再分享两个实操心得第一不要一上来就追所谓“最佳实践”。很多文章吹 ZGC、吹 WebFlux、吹 jlink 多神但真正决定效果的是你对自身业务的流量特征理解。我们一开始也差点全量切 WebFlux后来发现虚拟线程的改动成本更低、收益也更直接。适合自己团队的方案才是最好的方案。第二成本优化和技术改造要分步走。我这次优化的顺序是先 JVM 调优零代码改动再依赖瘦身和镜像优化基本零风险然后才是 IO 模型改造有风险最后做弹性伸缩和成本量化需要平台配合。每一步都有独立的收益和回滚方式即使中间某一步出问题也不会影响整体进度。Java 网关在 AI 工程化里的位置会越来越重成本优化这件事值得认真对待。希望这篇复盘能给你一些可落地的思路也欢迎你把自己实际操作中遇到的坑和效果分享出来一起补全这份“网关省钱手册”。