Spring AI生产实践:Token成本、延迟与稳定性的效率博弈

做后端十年，Spring Boot 生态里进进出出的组件我用过不少，但第一次把 Spring AI 接进生产项目的时候，我明显感觉到这个框架跟以往所有“确定性”的后端组件都不一样。模型输出内容不可控、Token 账单不可控、响应耗时不可控，三个不可控摞在一起，过去那套高可用三板斧——超时、重试、熔断——全都变了味道：重试可能烧更多钱，超时可能让用户什么都拿不到。Spring AI 作为 Spring 生态里专门把大模型能力收编进 Java 工程的框架，核心要解决的就是这一件事：怎么在不可控的大模型外面，包一层可控的工程壳子。

我这么说的底气来自一个真实生产项目。去年我们在一套业务系统里落地三个 AI 场景：智能客服、文档问答、合同摘要，团队从零调研，最终选定 Spring AI 作为统一接入层，中间经历了模型切换、Token 成本失控、流式接口内存溢出、结构化输出反复解析失败等一系列问题。这篇文章就把效率博弈这条主线抽出来：Token 怎么省、延迟怎么降、稳定性怎么保、出问题怎么查。适合已经有一段时间后端经验、准备把大模型能力接进 Spring Boot 项目的开发者，也欢迎架构师一起探讨方案取舍。

1. 先想明白：Spring AI 在工程里到底承担什么角色

1.1 它帮你省掉的不是“写代码”，而是“对接成本”

没有 Spring AI 之前，Java 后端要接一个大模型，常规路径是这样的：先翻模型服务方提供的 SDK 文档，然后自己封装 HTTP 客户端，处理鉴权、请求格式、流式响应、错误码，再写一堆 DTO 做序列化。做完这些只是第一步，等产品经理说“换一家模型服务方”，你准备把刚才那些代码全部推倒重来。

Spring AI 做的事情，是把这一层对接成本收编成标准接口。你面对的是ChatModel、ChatClient、Message、Prompt、AiResponse这几个核心抽象，底层接哪家模型服务方、走什么协议、怎么解析返回，框架替你包住了。换模型方的时候，多数场景只需要改配置，业务代码可以原样保留。这一点在“效率”的语境下极其重要——效率不只是接口响应快，还包括团队交付速度快。一次接入、多处复用，这是工程效率的第一个杠杆。

1.2 核心抽象的最小认知模型

我建议团队里每个写 AI 代码的人都先理解这五个接口的分工：

第一版代码最容易犯的错，是把ChatClient当成工具类到处 new，散落在 Service、Controller 各个角落。正确做法是项目里只有一个ChatClientBean，通过构造器注入到需要的地方，这样中间件逻辑（日志、限流、缓存）才有统一挂载的位置。我们在项目中踩过这个坑，前期散落调用导致后续加监控时改得焦头烂额，重构之后才真正体会到门面模式在 AI 场景的价值。

2. 效率博弈的第一战场：Token 成本控制

2.1 先看懂 Token 是怎么被花掉的

大模型的计费单位是 Token，简单理解就是模型把文本切成的片段，英文大概一个单词对应一到两个 Token，中文通常一个字对应一到两个 Token。系统提示词里的每一句话、用户问题里的每一个字、模型回答里的每一个词，都在烧钱。而且模型会把整个对话上下文都当成输入重新计算一遍，所以对话越长，单次请求的输入费用就越高。

我们项目刚上线时，有个客服场景的 prompt 写得像写作文一样，把业务背景、话术要求、示例对话全部塞进 system 消息，结果单次请求的平均输入 Token 冲到了 6000 以上。一个月跑下来，账单数字让负责人直接坐不住了。后来把 prompt 做了精简，只保留必要的业务规则和三条例句，平均输入 Token 降到 1800 左右，成本直接砍掉三分之二。所以在写任何 AI 功能之前，先问自己一句：这段提示词，删掉一半会不会影响输出质量？

2.2 Prompt 压缩是投入产出比最高的优化

做 Prompt 压缩，我总结出三个可复用的原则。

第一，system 消息里只放“规则”，不放“背景论文”。模型不需要了解你们公司的组织架构和项目起源，它只需要知道“你是客服助手，回答必须基于知识库内容，不确定时明确说不知道”。把规则提炼成动词开头的短句，效果远好于长篇背景描述。

第二，示例对话最多三条，每条只保留最能体现边界情况的。示例的作用是给模型划定输出风格的锚点，不是让它背诵话术。给多了反而容易让模型在回答时夹带示例里的无关信息。

第三，动态内容按需注入。用户问题和知识库检索结果是变化的，但那些固定的话术模板不应该拼接在每次请求里。Spring AI 的 Prompt Template 支持把模板和参数分离，固定模板只加载一次，运行时只替换变量部分。这样既省 Token，又避免模板在字符串拼接过程中出现格式错乱。

2.3 缓存与语义复用的组合拳

对重复性高的请求，缓存是第二道省钱防线。Spring 生态里做缓存很顺手，直接在方法上标注@Cacheable即可。但这里要特别注意：大模型场景里的“重复”分两种。

一种是完全相同的请求文本，比如客户反复问“退款什么时候到账”。这种直接用文本 MD5 做 key 命中缓存，简单高效。另一种是语义相似但不完全相同的问法，比如“钱什么时候退我”“退款几天能到”，这种文本级别的缓存永远命中不了，只能靠向量化后做相似度检索。如果业务量还没到需要上向量库的程度，建议先把文本级缓存做好，加上超时过期策略，就能覆盖多数高频问题。缓存的 key 里一定要拼上模型名称和 prompt 模板版本号，否则模型升级后返回的还是旧结果，排查起来非常痛苦。

3. 效率博弈的第二战场：延迟与用户体验

3.1 同步调用与流式调用的真实差异

很多团队第一版做 AI 接口时都用同步调用：用户发一个问题，后端请求模型服务方，等到完整结果生成后再一次性返回。这种方式代码最简单，但体验有硬伤——生成一篇稍长的回答可能要几十秒，用户盯着空白页面干等，超时风险也大。

Spring AI 的流式接口把返回类型设计成Flux<String>，配合 WebFlux 或者 SSE（Server-Sent Events）下发，用户可以一边看文字一边刷出来。我们上线流式之后，客服场景的“首字时间”从 3000 毫秒以上降到了 800 毫秒以内，用户的等待焦虑大幅缓解。这里的核心权衡是：整体完成时间其实没变，但感知延迟变了。效率博弈不只看绝对耗时，还看用户怎么感知耗时，流式是这笔账里最划算的投入。

3.2 并行调用：把串行链路拆开

很多业务场景天然可以拆成多个独立的大模型调用。比如做合同摘要时，需要提取合同主体、金额、时间、违约条款四个维度的信息，如果串行调用，总耗时是四次累加；如果并行调用，总耗时约等于最慢的一次。我们当时用CompletableFuture把四个维度的提取请求同时发出，整体断言时间从 40 秒压到了 12 秒，效果立竿见影。

但并行调用必须算清楚另一个账：模型服务方的 QPS 限制和成本。四个并行请求意味着瞬间消耗四倍于串行的 Token 吞吐，如果服务方有每分钟请求数上限，或者你的账号并发额度不够，并行反而会触发限流。建议先评估模型的并发上限，再决定并行度。实测下来，压到 60% 的额度以内最稳妥，既能提速又不会频繁触发 429。

3.3 合理设置超时参数

大模型的响应时间波动极大，高峰期和低峰期可能差三倍以上。超时设置太短，稍微慢一点就断，用户拿不到结果；太长，资源被长时间占用，连接池容易被打满。我们最终采用的是“双超时”策略：连接超时设为 5 秒，读超时设为 60 秒，流式场景下读超时放宽到 120 秒。同时配合 Spring 的@Async和线程池隔离，把 AI 调用的线程池与业务线程池分开，这样 AI 慢不会拖垮核心业务接口。

4. 效率博弈的第三战场：稳定性与容错设计

4.1 重试不是免费的，烧的是真金白银

传统后端遇到超时，惯例是重试三次。但在大模型场景，一次失败的重试意味着重新计算整段上下文，Token 费用直接翻倍。所以我们的重试策略必须带“歧视性”：连接超时和 5xx 错误可以重试，业务级别的校验错误不重试；单个用户触发的调用最多重试一次，后台离线任务最多重试三次，每次重试间隔按指数退避。

实现上用 Spring Retry 的@Retryable注解非常方便，配置退避策略的代码长这样：

@Retryable( retryFor = modelTimeoutException.class, noRetryFor = invalidRequestException.class, maxAttempts = 2, backoff = @Backoff(delay = 500, multiplier = 2) ) public AiResponse callModel(String prompt) { return chatClient.prompt().user(prompt).call(); }

注意noRetryFor这个配置。如果请求因为提示词格式问题失败，重试一万次也没用，反而浪费 Token。把不适用重试的异常类型提前列出来，是省钱的细节。

4.2 限流与降级：给系统留一条后路

大模型网关不稳定是常态，尤其是高峰期，各家模型服务方都可能出现响应变慢或者拒绝服务。我们当时给 AI 服务设计了三级降级链路：第一级走主模型，失败后切到备选模型（质量差一点但稳定），再失败则落到规则引擎给出预设兜底话术。整个降级链路的切换状态用配置中心动态控制，遇到大促或者模型方异常时，运维可以直接在配置中心调整，不用重新发版。

同时，限流必须做在网关层而不是业务层。因为模型服务方按 Token 和请求数双重计费，只限制 QPS 是不够的，还得限制每个用户单次的输入长度。我们在网关层写了一个过滤器，把用户的输入长度超过上限时直接拦截并提示精简，避免一个长文本请求把单次消耗拉爆。

5. 从“能跑”到“能用”：结构化输出与函数调用进阶

5.1 让模型返回业务对象，而不是一坨 JSON 字符串

第一版做文档问答时，我们的做法是让模型返回 JSON 字符串，然后用 Jackson 解析。这个方案最大的痛点是模型偶尔会在 JSON 前后追加解释文字，样例数据里总是出现“好的，我来回答您的问题，以下是 JSON 格式的返回……”这种前缀，解析就直接失败。后来切换到 Spring AI 的结构化输出能力，框架通过显式约束输出格式并处理嵌套解析，把返回内容直接映射成业务对象，解析失败率从 15% 降到了 1% 以内。

record ContractInfo(String contractNo, String partyName, BigDecimal amount) {} ContractInfo info = chatClient.prompt() .system("从合同文本中提取必要信息，严格按字段返回") .user(contractText) .call() .entity(ContractInfo.class);

这里有一个细节：实体类的字段名要起得语义明确，比如amount就比money好识别；字段类型尽量用基础类型，嵌套对象越深，模型出错概率越高。能拆成两次轻量调用分别提取的，不要合成一次超复杂调用，精度和稳定性都更好。

5.2 函数调用：让模型学会“动手查”

智能客服场景最典型的痛点是模型不具备实时数据。用户问“我订单到哪了”，如果只靠训练数据，模型要么瞎编要么答非所问。Spring AI 的函数调用能力允许我们在工具注册表里登记 Java 方法，模型输出“需要调用该工具”的指令，框架再反向执行方法并把结果带回模型生成最终回答。整个链路像给模型装了一只手，需要数据时就伸手去拿。

注册方式很直观，定义一个 Bean 方法并用描述注释标注：

@Bean @Description("根据订单号查询最新物流轨迹") public Function<OrderQuery, LogisticsTrace> queryLogistics() { return orderQuery -> logisticsService.query(orderQuery.orderId()); }

然后在 prompt 里声明启用这个工具：

String answer = chatClient.prompt() .user("帮我查订单 20240315001 的物流") .functions("queryLogistics") .call() .content();

这个功能带来的稳定性收益比想象中大。有了函数调用，模型不再需要“猜”数据，幻觉问题大幅缓解，回答的可信度和业务合规性都上了一个台阶。但也要给函数调用加超时和异常处理，工具本身出了问题，不能在模型链路里无限等待。

5.3 上下文压缩：别让长对话拖垮效率

多轮对话场景里，会话越长，每次请求带着的历史上下文就越长，Token 消耗线性上涨，响应速度还在跟着下降。我们在客服场景做了上下文压缩：当一圈对话超过六轮时，异步生成一个“历史摘要”存入会话记录，后续请求只带摘要和最近两轮完整对话，不再携带全部历史。实测单次请求 Token 消耗下降约 40%，响应速度提升明显，代价是模型对较早细节的记忆会变得模糊，所以涉及订单号的对话必须始终保留原始关键信息，不能只存摘要。

6. 实战复盘：高频问题与排查实录

6.1 一张速查表解决百分之八十的问题

我把项目里遇到的高频问题整理成了对照表，排障时先对照一遍，能省下大量猜测时间：

6.2 三个印象最深的排查案例

第一个案例是流式接口导致的“假内存泄漏”。上线流式能力后，监控发现堆内存缓慢增长。排查到最后发现是业务侧把Flux拿到手后没有及时订阅消费，数据全积压在缓冲里。解决方案很简单：确保调用方走统一封装，订阅后立即消费，问题当天就消失。这个案例提醒我们，响应式编程给效率带来收益的同时，也把“该谁消费”的责任推给了开发者。

第二个案例是模型切换后缓存命中了旧结果。我们某次把主模型从 A 换成 B，结果用户反馈“回答风格没变”。查了一圈才发现缓存 key 里没有包含模型版本，线上一直返回旧模型的缓存。后来在缓存 key 里统一拼上模型名和 prompt 版本号，这类问题再没出现过。

第三个案例是并行调用把模型服务方打爆了。某次大促前我们预判调用量会涨三倍，提前把并行度从 4 调到 8，结果活动刚开始就大量报 429。复盘发现模型服务方的并行额度比预期低，8 路并行直接越过了上限。后来改成“全局信号量控制并发 + 本地线程池双限流”，并行度回到 6，配合退避重试，429 率降到了接近零。效率优化永远要跟服务方的真实配额对齐，不能只盯着自己这一侧的速度。

7. 最后再分享一点个人体会

我在这个项目里最大的收获，不是学会了某个具体 API，而是彻底接受了“模型是概率系统”这个前提。Spring AI 给了我们一套标准化的接入方式，但工程效率的博弈关键还是在设计层：Token 要在写提示词的时候就省，延迟要在选流式和并行的时候就算，稳定性要在做降级和限流的时候就留好。任何单一维度的优化都会在其他维度产生代价，这也是为什么标题里要用“博弈”这个词——它不是一道算术题，而是一组需要持续平衡的约束。

如果你正在用 Spring AI 做生产项目，我建议团队里至少留一张“模型调用成本清单”，每次发版前过一遍提示词长度、缓存命中率、平均响应时长这三个指标，再小的优化在日积月累的量级上都会放大成可观的收益。我们在项目收尾时回头算了一笔账，前前后后做的这些效率调整，把单次请求的平均成本压到了初版的三分之一，响应时间压掉了将近一半。这套思路换到任何一个 AI 工程场景都适用，关键是别等到账单和告警都亮红灯了才回头补课。