当前位置：

社区首页

电脑数码

软件应用

服务软件

文章详情

如何借助请求日志和 Token 用量，把 AI 应用成本降下来

很多团队做 AI 应用时，最先注意到的往往是云厂商账单：这个月花了多少钱、调用了多少次、消耗了多少 Token。问题是，账单只能告诉你“钱花出去了”，却很难解释清楚“为什么花这么多”“到底是谁花的”“这些钱花得值不值”。

真正能长期跑下去的大模型应用，成本优化不能只靠换一个更便宜的模型，或者简单压缩一下 Prompt。更稳妥的做法，是建立一套从请求日志、Token 用量统计，到成本归因、异常定位，再到优化验证的闭环。

简单说，就是：

先记录请求日志，再统计 Token，然后计算成本、定位异常、制定优化动作，最后验证到底省了多少。

这篇文章主要聊一种不依赖具体平台的方法：怎么用请求级日志和 Token 用量统计，把 AI 应用成本从一张看不懂的“黑盒账单”，变成一个可以分析、可以归因、也能持续优化的工程系统。

为什么 AI 应用成本不能只盯着账单看

传统 Web 应用的成本，大多来自服务器、数据库、存储和带宽。通常看 QPS、CPU、内存这些指标，就能大致估算成本变化。

但大模型应用不太一样。同样是一次用户请求，成本可能因为很多因素一下子差出好几倍。比如：

用户输入特别长，输入 Token 自然就上去了；
系统 Prompt、历史对话或者 RAG 上下文塞得太多；
模型输出太长，生成 Token 增加；
Agent 反复规划、反思、调用工具，导致调用次数变多；
失败请求、超时重试也会产生无效消耗；
不同模型的输入、输出、推理 Token 单价并不一样；
缓存有没有命中，也会影响真实成本。

所以，只看总账单，你很难知道到底是哪个功能最烧钱，哪个用户用量异常，哪个模型性价比不高，也没法判断一次优化到底真的省了多少钱。

要做好大模型应用的成本优化，第一步不是马上问“换哪个模型更便宜”，而是先把下面几个问题弄清楚：

每一次用户请求，背后到底触发了多少次模型调用？
每次调用分别消耗了多少输入 Token、输出 Token、推理 Token？
这些成本应该算到哪个用户、租户、功能、会话或者业务结果上？
哪些请求属于高成本但低价值？
成本下降之后，准确率、满意度、转化率有没有被影响？

Token 成本到底由哪些部分组成

不少团队统计 Token 用量时，只记录一个 total_tokens。这看起来简单，但很容易算不准成本。原因也很直接：输入 Token、输出 Token、推理 Token、缓存 Token 往往不是同一个价格口径。尤其是 RAG 和 Agent 这类应用，成本结构会更复杂。

一个更完整的请求成本，大致可以这样理解：

请求成本 = 输入 Token × 输入单价 + 输出 Token × 输出单价 + 推理 Token × 推理单价 + 缓存读写成本 + 工具/API 调用成本 + 向量检索与重排成本 + 失败与重试带来的额外成本

这里有几个地方特别容易被忽略。

首先，输入和输出最好分开算。输出 Token 通常更贵，只看总 Token 很容易把真正的问题盖住。

其次，成本要按用户请求聚合，而不是只看单次模型调用。因为一次用户请求背后，可能会触发多次 LLM Call。

另外，RAG 会明显放大输入 Token。检索片段越多、chunk 越长，塞进上下文里的内容就越多，成本也会跟着涨。

Agent 应用也一样，它容易把调用次数放大。一次任务可能包含规划、工具调用、总结、校验等多个步骤，每一步都有可能产生费用。

还有一点，失败请求也不一定免费。超时、参数错误、重复重试，都可能造成实打实的无效成本。

最后，模型价格不要写死在代码里。模型价格变化很快，更合理的方式是维护一张可配置的价格表，并且以服务商最新说明为准。

请求日志应该记录哪些字段

想靠日志分析成本，前提是字段足够细。只记录“调用成功了没有、用了多少 Token”显然不够。比较实用的做法，是至少把下面这些字段记录下来。

字段用途request_id串起一次用户请求和背后的多次模型调用trace_id / span_id分析 RAG、Agent、工具调用等完整链路user_id / tenant_id按用户、租户或客户归因成本scene / feature判断哪个业务场景或功能最烧钱model_provider / model_name对比不同供应商、不同模型的成本prompt_tokens统计输入 Token 成本completion_tokens统计输出 Token 成本reasoning_tokens统计深度思考类模型的推理消耗cached_tokens评估缓存命中和节省效果total_tokens查看整体 Token 用量tool_call_count识别 Agent 工具调用是否膨胀retrieved_chunk_count判断 RAG 检索片段是不是太多prompt_length_chars辅助发现 Prompt 或上下文过长的问题latency_ms同时观察成本和响应体验status_code / error_code识别失败请求和异常消耗retry_count发现重试带来的成本放大business_result判断这次调用有没有产生有效业务结果

如果是企业多租户应用，还建议记录套餐、额度、订单、部门等信息。后面做客户账单、成本分摊、异常限流时，这些字段会非常有用。

如何用日志统计 Token 用量

有了请求级日志之后，就可以建立一套相对稳定的 Token 统计口径。下面这些 SQL 都是伪 SQL，字段名和表名可以根据自己的数据仓库做调整。

按天看整体成本趋势

SELECT DATE(created_at) AS dt, COUNT(DISTINCT request_id) AS request_count, SUM(prompt_tokens) AS input_tokens, SUM(completion_tokens) AS output_tokens, SUM(total_cost) AS total_cost, AVG(total_cost) AS avg_cost_per_request FROM llm_request_logs GROUP BY DATE(created_at) ORDER BY dt;

这个指标主要用来看成本趋势有没有失控，适合放在总览看板里。

按模型拆分成本

SELECT model_provider, model_name, COUNT(*) AS call_count, SUM(prompt_tokens) AS input_tokens, SUM(completion_tokens) AS output_tokens, SUM(total_cost) AS cost FROM llm_request_logs GROUP BY model_provider, model_name ORDER BY cost DESC;

这个查询可以帮你发现一个常见问题：是不是少数昂贵模型，承担了大量其实很简单的任务。

按功能统计 Token 和成本

SELECT scene, feature, COUNT(DISTINCT request_id) AS requests, SUM(total_tokens) AS tokens, SUM(total_cost) AS cost, SUM(total_cost) / COUNT(DISTINCT request_id) AS cost_per_request FROM llm_request_logs GROUP BY scene, feature ORDER BY cost DESC;

这一步很关键。成本最终要回到业务功能上，而不是停留在模型账单里。只有知道哪个功能花钱最多，才知道应该优先优化哪里。

找出 P99 高成本请求

SELECT request_id, user_id, tenant_id, feature, model_name, total_tokens, total_cost, latency_ms, status_code FROM llm_request_logs WHERE total_cost >= ( SELECT PERCENTILE_CONT(0.99) WITHIN GROUP (ORDER BY total_cost) FROM llm_request_logs ) ORDER BY total_cost DESC;

平均值很容易掩盖异常。真正要定位长尾成本，P95、P99 以及 Top 请求通常更有参考价值。

统计失败请求浪费了多少钱

SELECT error_code, COUNT(*) AS failed_calls, SUM(total_cost) AS wasted_cost, AVG(retry_count) AS avg_retry FROM llm_request_logs WHERE status_code != 200 GROUP BY error_code ORDER BY wasted_cost DESC;

如果失败请求的成本占比很高，那么它的优化优先级往往比 Prompt 压缩还高。因为这部分成本基本就是纯浪费。

如何从日志里发现成本异常

Token 用量统计不只是为了做报表，更重要的是及时发现异常。比较实用的告警规则，可以从这些方向入手。

异常现象建议告警规则单请求 Token 过高单请求 Token 超过近 7 天 P99，或超过固定阈值用户成本突然升高某用户 1 小时成本超过历史均值 3 倍以上租户成本异常单租户日成本超过套餐额度或预算阈值输出过长completion_tokens / prompt_tokens 持续异常升高失败消耗过高失败请求成本占比超过设定比例重试成本过高retry_count > 0 的请求成本占比明显上升Agent 步骤膨胀单任务 LLM 调用次数或工具调用次数超过阈值RAG 上下文过长retrieved_chunk_count 或上下文 Token 超过阈值

告警阈值一开始不要设得太死。更稳妥的方式，是先根据历史 P95、P99 建一个动态基线，再结合业务预算设置硬阈值。这样既能减少误报，也能尽早发现真正的问题。

根据日志结果选择优化策略

降本不是一上来就压缩所有东西，而是先看日志里暴露了什么问题，再选择对应动作。

日志现象优先优化动作输入 Token 占比高压缩系统 Prompt、减少历史消息、优化 RAG chunk 和 TopK输出 Token 占比高设置 max_tokens、约束回答格式、使用摘要式输出高成本集中在少数功能评估是否真的需要大模型，或者做模型分层高成本集中在少数用户增加额度控制、限流、套餐管理和异常告警失败请求成本高优化参数校验、超时设置、重试和熔断策略Agent 调用次数高限制最大步骤数、缓存工具结果、合并工具调用RAG 上下文过长调整 chunk 大小、TopK、重排和去重策略简单任务调用大模型增加小模型路由、规则引擎或 FAQ 兜底相似问题重复调用增加语义缓存、答案缓存和 Prompt 缓存

不同类型的 AI 应用，关注点也不太一样。

AI 客服：重点看单会话成本、FAQ 命中率、转人工率，以及重复问题缓存效果。
RAG 知识库：重点看检索 chunk 数、上下文 Token，以及答案准确率和成本之间的平衡。
Agent 应用：重点看每次任务的 LLM 调用次数、工具调用次数，以及失败重试成本。
内容生成：重点看输出 Token、生成长度、改写次数和废稿率。
代码助手：重点看长上下文输入、文件数量、补全频率和缓存命中率。
企业多租户应用：重点看租户级成本、额度、账单和异常用量。

一个完整的成本优化闭环示例

假设一个企业知识库问答应用，最近成本突然上涨。账单只能告诉你总费用变高了，但请求日志可以把原因一步步拆出来。

先按功能统计，发现成本主要集中在“知识库问答”。再看 P99 请求，会发现高成本请求大多携带了大量历史消息。接着查看 RAG 字段，发现 retrieved_chunk_count 从 5 增加到了 12。继续分析 Token 占比，又发现输入 Token 占了大头。最后抽样检查具体请求，发现部分 chunk 内容重复，而且系统 Prompt 里还有很多不必要的说明。

这时候可以采取的优化动作就很清楚了：

把 RAG TopK 从较高值调低，同时引入重排和去重；
历史对话只保留最近几轮，或者先做摘要压缩；
精简系统 Prompt，删掉重复规则和无效说明；
对重复问题增加语义缓存；
低风险问题优先使用低成本模型，高风险问题再升级模型；
设置输出长度上限，避免回答过度展开。

优化完成以后，不能只看 Token 有没有下降，还要一起观察这些指标：

单请求平均成本；
P95/P99 成本；
平均延迟；
答案满意度；
命中率或准确率；
转人工率或人工返工率。

如果成本确实降了，但准确率明显下滑，甚至导致人工处理量增加，那很可能只是把模型成本转移成了人工成本，并不算真正优化。

成本看板与告警建议

一个实用的 AI 应用成本看板，可以分成四类来看。

总览看板

这里主要关注整体情况，比如今日成本、请求量、总 Token、平均单请求成本、P95/P99 单请求成本，以及成本环比变化。

归因看板

归因看板要回答“钱花到哪里去了”。可以按模型、用户、租户、功能、场景、版本和业务结果来拆分成本。

异常看板

异常看板主要用来快速定位问题，比如高 Token 请求 Top N、高成本失败请求、重试成本排行、突增用户或租户、Agent 高步骤任务，以及 RAG 上下文过长请求。

优化效果看板

这一类看板用来验证优化是否真的有效。可以对比优化前后的单请求成本、Prompt 压缩节省、缓存命中节省、模型路由节省、失败请求成本下降，以及成本和质量指标之间的变化。

工具层面，可以用自建日志系统、数据仓库和 BI 看板，也可以结合 OpenTelemetry、Prometheus、LangSmith、云厂商监控产品等来实现。如果使用第三方 Claude API 兼容接入服务，比如 ClaudeAPI，也建议基于自己的日志记录实际调用成本、延迟、错误和业务结果。至于具体模型、价格、额度和服务能力，仍然要以平台最新说明为准。