## 01、痛点
我是老李。最近我们团队把问答服务从单模型升级成了能查资料、能调工具、能分步推理的智能体应用。上线跑了一周，看监控面板，延迟和错误率都挺好看，P95 也没破线。但月底账单一出来，模型费用涨了快六倍，财务和研发差点在群里吵起来。更尴尬的是，我们说不清到底哪个环节把成本抬高了：是嵌入阶段？是检索后的长上下文？还是工具调用反复把结果塞回模型？

这类问题不是个例。很多团队对 AI 系统的观测仍然停留在传统服务的思维里，只关注延迟、错误率、吞吐。AI 系统一旦变成多步骤调用，单次用户请求内部可能串起多次模型调用、多次嵌入计算、若干次工具调用和评估步骤。传统监控看不到 Token 消耗、模型费用、嵌入成本和工具成本。就像开了一家餐厅，只看翻台率和投诉率，却不知道每桌客人点了多少和牛。

Spring AI 2.0.1 对 Chat 和 Embedding 的用量统一处理，正好给了我们一个把隐性成本翻到台面上的机会。现在讲这个，不是因为它新，而是因为越来越多团队正在从“能不能调通模型”进入“能不能长期跑得起”。

## 02、是什么
Spring AI 2.0.1 在响应元数据里提供了更统一的用量获取方式。聊天补全返回的 ChatResponse 中可以通过 Metadata 拿到 Usage，里面包含 prompt tokens、completion tokens 和 total tokens。嵌入调用同样不再只是返回向量，还能拿到本次嵌入消耗的 token 数。不同模型提供商的字段差异被框架吸收，上层代码只需要面向统一的 Usage 结构读取。

这套能力解决的不是“能不能调到模型”，而是“调用之后怎么准确记账”。使用它之后，我们可以在同一出口拿到每次模型调用的输入 token、输出 token、模型名称、耗时，再结合价格表估算费用。注意，一个系统中往往不只有聊天模型，嵌入模型同样在烧钱。过去嵌入成本容易被忽略，因为嵌入调用看起来便宜，但请求量通常很大。一次检索可能只需要几百 token，但一个文档库冷启动时可能要嵌入几百万篇文本，成本会非常可观。

统一的意义还在于，不只是账目好看。它让编码阶段更容易把用量记录做成标准动作。你不必为不同厂商各写一套解析，也不必每接一个新模型就重新找字段。只要在模型调用后取一次 Usage，就能形成统一日志。日志里除了 Token，还要带上传入场景、调用步骤、是否命中缓存、是否发生工具调用等上下文信息，否则后面只能看到一堆数字，却无法定位是哪类业务在推高费用。

## 03、为什么
为什么非要把成本当成一等指标？因为现在一次智能体请求的成本结构变了。过去很多人脑子里是一个等式：一次请求 = 一次模型 API 调用。按这个等式，算成本很简单，一次输入加一次输出就完了。可今天的请求链路完全不是这样。

一次请求可能先做问题改写，再做检索，检索前要调用嵌入模型，检索后要把若干文档拼进上下文，再调用大模型生成答案。如果系统需要调用外部工具，模型还要多轮判断工具参数、执行工具、把工具结果再次传回模型。最后可能还有评估步骤，用一个模型给结果打分。也就是说，一次用户请求背后可能是多轮模型调用、多次嵌入、多次工具调用和评估模型的叠加。每一段都有 Token 和耗时，工具本身还可能有搜索、数据库或第三方 API 的费用。

如果只看延迟和错误率，这些内部消耗不会显示出来。延迟可能还在可接受范围内，错误率也不高，但成本已经被多轮调用悄悄推高。更麻烦的是，团队里没人能回答“为什么这个功能这么贵”。没有成本拆分，优化就无从入手。你能知道整体慢了，但不知道慢在推理还是检索；你能知道整体贵了，但不知道贵在旗舰模型乱用，还是上下文塞得太满。

所以必须把成本拆开，把每个步骤的用量、耗时、模型价格记录清楚。这不是财务视角，而是架构视角。只有在架构指标中纳入成本，才能判断一个设计是好是坏。

## 04、架构
要落地用量采集，需要一个轻量的架构。以 Spring AI 作为模型访问层，所有聊天补全和嵌入都通过统一入口走。可以在模型调用前后设置拦截或切面，记录开始时间和结束时间。调用返回后，从响应元数据中取出 Usage，然后和请求场景、步骤类型、模型名称、耗时一起写入事件。

建议的数据结构可以包含：请求 ID、步骤 ID、场景类型、模型名称、输入 token、输出 token、总 token、耗时毫秒、估算费用、时间戳。场景类型要区分普通问答、检索增强、智能体编排。步骤类型可以区分改写、检索、生成、工具调用、评估。这样后续报表可以按场景和步骤聚合，而不是一锅粥。

价格配置需要独立管理。每个模型的输入 token 单价、输出 token 单价不同，嵌入模型的单价也不同。工具调用如果走外部 API，还需要配置工具单次成本。估算费用时，输入 token 和输出 token 分开算，嵌入成本按 token 计，工具成本按次计。不要混在一起。

架构上，采集动作要尽量无侵入。可以让业务代码只关心调用模型，用量采集放到框架层完成。即使某次调用异常，也要记录已产生的 Token。很多服务在模型返回前就超时，但提供方仍可能已经计费。这种损耗如果不记录，账目永远不平。

最后要有一个聚合视图。把用量日志打到监控系统或数据仓库，做出每请求成本、每场景成本、每模型成本、每日成本趋势，以及成本占比最高的步骤排行。这样才能从架构层面回答：系统到底贵在哪。

## 05、实战
假设我们有一个应用需要同时支持普通问答、检索增强和智能体模式。用 Spring AI 2.0.1 写用量采集并不复杂。聊天调用返回后可以这样取：

ChatResponse response = chatClient.prompt(...).call().chatResponse();
Usage usage = response.getMetadata().getUsage();

嵌入调用类似：

EmbeddingResponse er = embeddingClient.embedForResponse(texts);
Usage usage = er.getMetadata().getUsage();

然后写一个 CostCalculator，将 usage.getPromptTokens() 和 usage.getCompletionTokens() 分别乘以价格，得到费用。

运行一周后，可以比较三种模式：

- 普通问答：单次聊天调用，平均输入 1.1k token，输出 280 token，耗时约 0.8 秒，估算成本约 0.003 元/次。
- 检索增强：先嵌入约 400 token，检索后把 Top 5 文档片段拼进上下文，再聊天调用，平均输入 6.5k token，输出 350 token，耗时约 1.6 秒，估算成本约 0.014 元/次。
- 智能体模式：一次请求可能先规划、再调工具、再总结，还要评估。平均 6 次模型调用，总输入 22k token，总输出 2.4k token，嵌入 1.2k token，工具调用 4 次，耗时约 7 秒，估算成本约 0.09 元/次。

三种模式的成本差异不是百分之几十，而是数量级。如果团队把智能体模式当成普通问答去监控，只看到延迟从 0.8 秒变 7 秒，却看不到单次成本涨了几十倍。再加上高频用户，一天几十万次请求，账单会非常恐怖。用统一用量日志把三种模式分开统计后，我们才发现，智能体模式里最贵的不是最终生成，而是多轮工具调用中反复把巨型上下文回传模型。

## 06、洞见
效果最好的模型不一定适合所有步骤。这件事很多团队理性上认同，做起来却容易偷懒：既然已经在用旗舰模型，干脆所有步骤都用它。结果小任务也付大价格。

不同步骤对模型能力的要求差距很大。意图识别、格式转换、简单分类、工具参数提取，这些任务用小模型通常就能做好。深度推理、复杂多跳问答、长文档综合分析，才需要能力更强的模型。全链路都用最强的模型，一方面浪费 Token 成本，另一方面也拖慢响应。强模型往往更慢、单位 token 更贵，有时上下文窗口更大，但普通任务根本用不上这些优势。

路由模式是生产环境里很有价值的一种优化方式。先让一个轻量模型判断请求难度，简单问题直接用小模型处理，复杂问题再升级到强模型。也可以按步骤拆分：检索前的查询改写用小模型，检索后的综合生成用强模型，工具结果的格式整理用小模型。这样既保住质量，又降低成本。判断标准可以是问题长度、工具是否需要、检索结果置信度、历史对话复杂度等。关键是要有成本意识，把“最强模型”从默认选项变成按需选项。

## 07、行动
要把这件事真正落地，建议建立 Quality / Latency / Cost 三维指标，而不是只加一个成本字段。

质量维度关注端到端成功率、答案准确率、检索命中率、工具调用成功率、评估分数。延迟维度关注首 token 时间、端到端延迟、各步骤耗时、P95/P99。成本维度关注每次请求的 Token 总量、每请求估算成本、每类步骤成本、每日模型费用、嵌入成本和工具成本。三个维度必须放在同一张表里看，不能割裂。比如某个优化让延迟下降 30%，但成本上升 80%，这个方案是否值得，需要结合质量来判断。

落地顺序可以分五步。第一步，基于 Spring AI 2.0.1 的 Usage 做统一采集，确保所有模型调用都经过埋点。第二步，维护模型价格表，至少包含输入单价、输出单价、嵌入单价、工具单次成本。第三步，把日志接入监控系统，设置成本预算和告警，避免月底才发现超支。第四步，按场景和步骤打标，输出普通问答、检索增强、智能体模式的分组报表。第五步，每周复盘成本分布，找出高成本步骤，做路由优化、上下文压缩、缓存或提示词精简。质量、延迟、成本一起看，才能避免按下葫芦浮起瓢。

## 08、小结
AI 系统越复杂，越不能只靠延迟和错误率判断健康度。Token、模型费用、嵌入成本、工具调用成本都是架构指标的一部分。Spring AI 2.0.1 对 Chat 和 Embedding 用量的统一处理，降低了记录这些指标的门槛。团队需要从“一次 API 调用多少钱”升级到“一次请求全链路多少钱”，把成本按步骤拆开，把不同难度的任务路由给不同模型。最终不是简单追求效果最好，而是让质量、延迟、成本达成可持续的平衡。

## 09、链接与概念说明
概念说明：
- Spring AI：面向 Java 生态的 AI 应用框架，提供聊天补全、嵌入、向量存储等统一抽象。2.0.1 版本在响应元数据中增强了用量处理。
- Chat Usage：聊天补全返回的 Token 用量，通常包含输入、输出和总量。
- Embedding Usage：嵌入调用返回的 Token 用量，用于统计嵌入成本。
- Token：模型处理文本的基本计量单位，是成本计算的基础。
- 智能体模式：由多次模型调用、工具调用、检索和评估协作完成任务的架构模式。本文用“智能体”代替相关英文术语，避免混淆。
- 三维指标：Quality / Latency / Cost，用于综合评估 AI 应用质量、性能和成本。
参考：Spring AI 官方文档，GitHub spring-projects/spring-ai。

我是老李。最近我们团队把问答服务从单模型升级成了能查资料、能调工具、能分步推理的智能体应用。上线跑了一周，看监控面板，延迟和错误率都挺好看，P95 也没破线。但月底账单一出来，模型费用涨了快六倍，财务和研发差点在群里吵起来。更尴尬的是，我们说不清到底哪个环节把成本抬高了：是嵌入阶段？是检索后的长上下文？还是工具调用反复把结果塞回模型？

《Spring AI 2.0实战》第20招 成本也要进架构

模型请求成本不能只看一次调用。Spring AI 2.0.1 统一 Chat 与 Embedding 用量，结合多步骤链路与三维指标，才能管住智能体应用的隐性开

架构师

编程语言

SpringAI 2.0.1 统一获取 Chat 和 Embedding 用量，解决 AI 应用成本黑盒问题。通过拦截调用采集 Token、耗时和模型费用，按场景拆解普通问答、检索增强和智能体成本，发现智能体模式费用高数十倍。建议建立质量-延迟-成本三维监控，按步骤路由不同模型，平衡性能与费用。

数据仓库

数据结构

数据库

智能体

路由

Java

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring AI 2.0实战》第20招 成本也要进架构-腾讯云开发者社区-腾讯云

《Spring AI 2.0实战》第20招成本也要进架构

《Spring AI 2.0实战》第20招成本也要进架构

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring AI 2.0实战》第20招 成本也要进架构

《Spring AI 2.0实战》第20招 成本也要进架构

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring AI 2.0实战》第20招成本也要进架构

《Spring AI 2.0实战》第20招成本也要进架构