1. Spring AI 中的 Token 成本优化实战在 Spring AI 项目中Token 成本是直接影响项目经济性的关键指标。以 GPT-3.5 为例每 1000 个 Token 的成本约为 $0.002看似微小但在高频调用场景下会快速累积。我在电商客服机器人项目中就曾遇到月均 Token 消耗超 2000 万的情况通过以下优化策略最终降低 37% 的成本。1.1 上下文压缩技术动态上下文管理是降低 Token 消耗的核心手段。传统做法会将完整对话历史作为上下文传递这会导致两个问题重复传输固定指令和随对话轮次线性增长的 Token 消耗。我的解决方案是public class ContextCompressor { private static final int MAX_HISTORY 3; public String compress(ListMessage history) { // 保留系统指令的最新版本 String systemPrompt history.stream() .filter(m - m.role() Role.SYSTEM) .reduce((first, second) - second) .map(Message::content) .orElse(); // 仅保留最近N条用户对话 ListMessage recent history.stream() .filter(m - m.role() ! Role.SYSTEM) .skip(Math.max(0, history.size() - MAX_HISTORY)) .toList(); return systemPrompt \n recent.stream() .map(m - m.role() : m.content()) .collect(Collectors.joining(\n)); } }关键技巧通过 Message 对象的 role 字段区分系统指令和对话内容确保系统提示不会被重复传输。实测显示这种方案在 10 轮以上的长对话中可节省 45-60% 的上下文 Token。1.2 响应长度控制OpenAI 的 max_tokens 参数需要精确计算。我的经验公式是max_tokens 平均响应长度 × 安全系数(1.2~1.5) 特殊需求 tokens在 Spring 中可以通过自定义 HandlerMethodArgumentResolver 实现自动计算public class MaxTokensResolver implements HandlerMethodArgumentResolver { Override public Object resolveArgument(...) { MethodParameter parameter ... AvgLength avg parameter.getMethodAnnotation(AvgLength.class); double factor parameter.getParameterAnnotation(TokenFactor.class) ! null ? parameter.getParameterAnnotation(TokenFactor.class).value() : 1.3; return (int)(avg.value() * factor) calculateSpecialTokens(); } } GetMapping(/ask) public String askQuestion( RequestParam String question, AvgLength(150) TokenFactor(1.2) Integer maxTokens) { // 自动计算出的 maxTokens ≈ 180 }避坑指南避免直接设置固定值如 max_tokens200这会导致短响应浪费配额或长响应被截断。应该基于历史数据分析各接口的典型响应长度。2. Structured Output 实现方案结构化输出能显著提升 AI 响应的可编程性。在订单查询场景中传统自然语言响应需要复杂的正则解析而结构化输出可直接映射为 Java 对象。2.1 响应模式定义使用 Spring AI 的 StructuredOutput 注解定义返回格式Retention(RetentionPolicy.RUNTIME) Target(ElementType.METHOD) public interface StructuredOutput { String schema() default ; Class? value() default Object.class; } // 在Controller中使用 StructuredOutput(value OrderInfo.class, schema { type: object, properties: { orderId: {type: string}, status: {type: string, enum: [pending,shipped,delivered]}, items: { type: array, items: { name: {type: string}, quantity: {type: integer} } } } } ) GetMapping(/order-status) public OrderInfo getOrderStatus(RequestParam String orderNumber) { // 实际会返回符合schema的JSON }2.2 后处理验证通过 Spring AOP 实现自动验证Aspect Component public class OutputValidationAspect { Around(annotation(structuredOutput)) public Object validateOutput(ProceedingJoinPoint joinPoint, StructuredOutput structuredOutput) throws Throwable { Object result joinPoint.proceed(); JsonSchemaFactory factory JsonSchemaFactory.getInstance(VersionFlag.V7); JsonSchema schema factory.getSchema(structuredOutput.schema()); try { schema.validate(new ObjectMapper().valueToTree(result)); } catch (ValidationException e) { throw new ResponseNotValidException(AI响应不符合预定结构, e); } return result; } }实战经验在电商客服系统中结构化输出使订单查询接口的解析代码量减少 82%且错误率从 15% 降至 0.3%。建议对金额、日期等关键字段增加额外的正则校验。3. Token 监控与分析体系建立完整的监控体系才能持续优化成本。我在 Spring Boot 中通过以下组件实现3.1 审计切面设计Aspect Component public class TokenAuditAspect { Autowired private TokenUsageRepository repository; AfterReturning(pointcut within(org.springframework.ai.client.AiClient), returning response) public void auditUsage(AiResponse response) { TokenUsage usage new TokenUsage( response.getUsage().getPromptTokens(), response.getUsage().getCompletionTokens(), LocalDateTime.now(), getCurrentEndpoint() ); repository.save(usage); } private String getCurrentEndpoint() { RequestAttributes attributes RequestContextHolder.getRequestAttributes(); if (attributes instanceof ServletRequestAttributes) { HttpServletRequest request ((ServletRequestAttributes)attributes).getRequest(); return request.getRequestURI(); } return background; } }3.2 成本分析看板使用 Spring Data JPA 实现聚合查询public interface TokenUsageRepository extends JpaRepositoryTokenUsage, Long { Query(SELECT new com.example.TokenCostStat(u.endpoint, SUM(u.promptTokens), SUM(u.completionTokens), COUNT(u), AVG(u.promptTokens u.completionTokens)) FROM TokenUsage u WHERE u.timestamp :start GROUP BY u.endpoint) ListTokenCostStat getCostStats(Param(start) LocalDateTime start); }配合 Thymeleaf 展示数据table classtable tr th:eachstat : ${stats} td th:text${stat.endpoint}/td td th:text${#numbers.formatDecimal(stat.totalTokens/1000, 1, 2)}K/td td th:text${$ #numbers.formatDecimal(stat.totalTokens * 0.002/1000, 1, 2)}/td td th:text${stat.avgTokens}/td /tr /table监控要点特别关注 avgTokens 异常高的接口这通常意味着需要优化提示词设计或启用流式响应。在我的实践中通过监控发现有个查询接口平均消耗 1200 tokens优化后降至 380。4. 高级优化技巧4.1 语义缓存机制对高频问题建立缓存public class SemanticCache { Cacheable(value aiResponses, key #question.hashCode(), unless #result null || #result.length() 500) public String getCachedResponse(String question, AiClient client) { return client.generate(question); } }配合 Spring Cache 和 Redis 实现分布式缓存。关键点使用 question.hashCode() 而非原始文本作为 key 节省空间设置 unless 条件避免缓存过长的响应对时效性强的数据设置短 TTL4.2 流式响应处理使用 Spring WebFlux 实现 Token 级流式响应GetMapping(value /stream, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxString streamResponse(RequestParam String question) { return aiClient.stream(question) .map(Content::text) .timeout(Duration.ofSeconds(30)) .onErrorResume(e - Flux.just([ERROR] e.getMessage())); }性能对比在 3G 网络环境下测试流式响应使感知延迟降低 60%且由于用户可以提前中断实际 Token 消耗平均减少 22%。