AI 应用的隐形电费：为什么你的应用贵在 Token，而不是模型

写在前面Token 不是一个小数点后的计费细节很多团队第一次做 AI 应用最关心的问题通常是用哪个模型 模型单价是多少 回答质量够不够 上下文窗口有多大这些问题当然重要但真正上线后你很快会发现另一个更现实的问题为什么试用时很便宜 一接入知识库就变贵 一加 Agent 就更贵 一多人使用账单开始不受控原因往往不是“模型突然涨价”而是你没有看见每一次请求背后到底塞了多少 token。一个普通聊天请求看起来只有一句话帮我总结一下这份客户投诉。但系统实际发给模型的内容可能是系统提示词 角色设定 安全规则 工具说明 历史对话 检索出来的文档片段 用户当前问题 输出格式约束 失败重试时的补充上下文。用户看到的是一句话账单看到的是几千、几万甚至几十万 token。所以token 不只是一个计费单位。它更像 AI 应用里的“电表”你每塞一段上下文电表就转一下 你每让 Agent 多走一步电表就再转一下 你每返回一大段日志电表也在转 你每把历史对话完整带上电表还在转。如果一个团队只盯着模型单价而不管理 token那么它做出来的不是 AI 应用而是一个看不见功耗的机器。本文实战口径本文不讲“什么是 token”的教科书定义而是按一个真实 AI 应用的成本链路来拆阶段要解决的问题识别一次请求里的 token 到底从哪里来计算为什么 Agent 和 RAG 会让 token 成本放大诊断哪些上下文是真有用哪些只是噪音控制怎么做 token budget而不是事后看账单优化压缩、缓存、裁剪和分层模型怎么用读完你应该能得到一个判断标准一个成熟的 AI 应用不是只会调用模型而是知道每一次调用为什么值得花这些 token。一、模型看到的不是文字而是 Token 流OpenAI 的tiktoken项目里有一句非常关键的话语言模型看到的不是我们眼里的文字而是一串数字也就是 token。Byte Pair Encoding 这类 tokenizer 会把文本拆成可逆的 token 序列。它能处理任意文本也能把常见片段压成更短的表示。项目 README 里提到一个经验值平均来看一个 token 大约对应 4 个字节。这个细节听起来很底层但它直接影响成本。同样是“1000 字”不同内容的 token 数可能完全不同普通中文段落 英文技术文档 Markdown 表格 JSON 代码 日志 Base64 SQL 混合中英文产品文档。它们在人眼里可能都是“一页内容”在模型眼里却可能是完全不同的 token 压力。这也是很多知识库项目容易踩坑的地方团队只看文件数量和页数不看 token 密度。一个 20 页 PDF 也许没什么但如果里面全是表格、合同条款、接口字段和嵌套 JSON切成 chunks 后送进 RAGtoken 成本会比你想象中高很多。二、一次 AI 请求到底有哪些 Token先看最简单的聊天应用。你以为一次请求是用户问题 → 模型 → 回答真实情况更像系统提示词 开发者提示词 历史对话 用户问题 输出格式要求 安全策略 → 模型 → 回答如果是 RAG 应用还要再加检索 query 改写 Embedding 检索 TopK 文档片段 片段来源说明 引用格式要求 找不到答案时的拒答规则。如果是 Agent 应用还要继续加工具列表 工具 schema 工具调用结果 中间推理步骤 失败后的重试上下文 上一步执行日志 下一步计划。这就是为什么 Agent 比普通聊天更容易烧 token。普通聊天像一次对话。Agent 更像一个反复读材料、查工具、看结果、再决定下一步的循环。一次 Agent 任务如果走 5 步每一步都把历史上下文、工具结果和部分日志重新发给模型那么 token 成本就不是“一次请求的成本”而是每一步上下文成本 × 步数这还没算失败重试。三、RAG 最大的问题不是查不到而是塞太多很多团队做私有知识库第一反应是多传资料 多切 chunk TopK 调大 上下文窗口选大 让模型尽量多看。这听起来稳妥实际上很危险。RAG 的目标不是把资料全部塞给模型而是把最可能有用的证据送进去。TopK 越大不一定越准反而可能出现三类问题成本上升 关键片段被噪音淹没 模型在多个相似但冲突的片段之间摇摆。举个很常见的例子。你问企业版客户退款规则是什么检索系统如果把这些片段一起塞进去个人版退款规则 企业版退款规则 历史版本退款规则 销售 FAQ 客服话术 一份过期合同 一次内部讨论纪要。模型不一定会“更懂”它可能只是更难判断哪个版本才是当前规则。这时 token 花出去了但没有换来更好的答案。所以 RAG 的第一原则不是“多给”而是“给对”。四、Agent 的 Token 成本为什么会指数感变贵Agent 应用里token 成本有一个很隐蔽的放大器上下文累积。假设一个代码 Agent 执行任务读需求 搜索文件 打开代码 运行测试 看报错 修改代码 再运行测试 总结结果。每一步都会产生上下文。搜索结果是上下文。文件内容是上下文。测试输出是上下文。报错堆栈是上下文。模型自己的中间计划也是上下文。如果系统没有做控制它很容易把大量低价值内容带进后续步骤成功通过的测试日志 重复的依赖下载输出 完整 git diff 过长的目录树 无关文件内容 多次重复出现的错误堆栈。这类内容对人来说只是“屏幕滚了一堆”对模型来说却是实打实的 token。更麻烦的是这些噪音不只贵还会影响判断。一个模型在干净上下文里可能知道该改哪一行在一堆日志、无关文件和历史尝试里反而容易被带偏。这就是 token 的第二层含义Token 不只是成本也是一种注意力污染。五、Token BudgetAI 应用应该先有预算再有提示词很多人写 prompt 的方式是想到什么就加什么 怕模型不懂就多解释 怕模型不听话就多写规则 怕回答不准就多塞资料。这会让 prompt 越长越长最后没人敢删。更工程化的做法是先做 token budget。比如一次普通知识库问答可以先定一个预算模块Token 预算系统提示词500安全和拒答规则300历史对话1000检索文档片段4000用户问题500输出预留1500这个表不一定准确但它会迫使团队回答几个关键问题系统提示词真的需要这么长吗 历史对话是否必须完整带上 TopK 文档片段是否过多 输出是否需要限制结构 低价值上下文是否应该被摘要或丢弃这比上线后看账单更主动。成熟的 AI 系统应该在每次调用前就知道这次请求预计消耗多少 token 哪些 token 是必要的 哪些 token 可以压缩 哪些 token 可以从缓存读取 超过预算时优先删什么。六、不要只省 Token要省低价值 Token一提到 token 优化很多人会走向一个误区能压就压 能省就省 越短越好。这不对。AI 应用不是短信计费系统不能为了省字数把关键证据删掉。好的 token 优化不是把上下文变短而是把低价值上下文删掉把高价值证据留下。可以按四类处理内容类型处理方式关键证据保留原文必要时带来源重复内容去重或合并长日志提取失败原因和关键行历史对话摘要成状态而不是全文复读比如客服知识库里退款政策原文很重要不能随便摘要但用户前面寒暄了几轮完全可以压成用户是企业版客户正在咨询退款条件已确认购买时间为 2026-05-20。这才是有价值的压缩。七、Token 成本治理的 6 个动作如果你现在已经有一个 AI 应用建议从这 6 件事开始记录每次请求的输入和输出 token不要只看总账单。至少按功能、用户、模型、场景拆开记录。知识库问答平均多少 token Agent 任务平均多少 token 失败请求比成功请求贵多少 哪个工具返回最吃 token。给每类任务设 token 上限不是所有任务都配得上 100K 上下文。简单分类任务几百 token 普通问答几千 token 复杂分析几万 token 长文档审阅单独走批处理或分段流程。历史对话不要无限带多轮对话应该保留状态而不是保留所有原话。RAG 检索结果要重排和裁剪TopK 不是越大越好。宁可给 5 段高质量证据也不要给 20 段相似废话。工具输出要过滤尤其是命令行、测试日志、网页抓取、JSON 响应。模型通常不需要完整输出只需要关键事实。把稳定上下文缓存起来产品说明、工具 schema、常用政策、固定系统提示词如果平台支持缓存就应该利用缓存机制降低重复成本。八、一个简单的落地案例假设你在做一个内部制度问答助手。第一版常见做法系统提示词 2000 token 历史对话 3000 token TopK10每段 800 token 用户问题 100 token 输出 1000 token。一次请求大约2000 3000 8000 100 1000 14100 token如果每天 1000 次就是 1410 万 token。优化后系统提示词压到 800 历史对话摘要到 600 TopK5每段 500 用户问题 100 输出限制到 800。一次请求变成800 600 2500 100 800 4800 token这不是少写几个字而是系统结构变了。关键是如果检索质量更好答案质量未必下降甚至可能上升。因为模型看到的是更干净、更集中的证据。九、最终评价Token 是 AI 应用的工程边界过去大家讨论 AI 应用喜欢讲模型能力 Prompt 技巧 RAG 架构 Agent 框架 向量数据库。这些都重要但真正上线后token 会把所有问题拉回现实。它决定成本能不能接受 延迟能不能控制 上下文会不会溢出 模型会不会被噪音干扰 系统能不能规模化。所以一个成熟的 AI 团队不应该只问这个模型聪不聪明还应该问我们到底让它读了什么 这些内容值不值得读 哪些内容可以不读 哪些内容必须原文保留 哪些内容可以缓存、摘要或压缩一句话总结Token 是 AI 应用的隐形电费。不会管理 token 的团队迟早会被账单、延迟和噪音一起教育。十、实战给自己的文档算一笔 Token 账这篇文章如果只停留在观点层读者会觉得有道理但不知道怎么动手。最小实战可以很简单选一份你准备放进知识库的文档先算它到底会变成多少 token。可以准备三类材料一份普通 Markdown 文档 一份产品说明 PDF 转出来的文本 一份接口返回 JSON 或测试日志。然后用 tokenizer 做统计。如果用 Python可以用tiktoken思路做一个最小脚本importtiktokenfrompathlibimportPath enctiktoken.get_encoding(cl100k_base)forfilein[doc.md,manual.txt,api.json]:textPath(file).read_text(encodingutf-8)tokenslen(enc.encode(text))charslen(text)print(file,chars,chars,tokens,tokens,chars/token,round(chars/tokens,2))这个实验不复杂但非常有用。你会很快发现几件事中文自然段不一定最贵 JSON、表格、日志经常更吃 token 重复字段名会被反复计费 Markdown 里的表格和链接会增加 token PDF 转文本如果格式混乱token 浪费会更严重。做知识库之前先算一次比上线后看账单更有价值。因为它会逼你提前做决定哪些文件适合直接导入 哪些文件需要清洗 哪些内容应该拆成结构化字段 哪些日志不应该进入知识库 哪些资料需要先去重。十一、一个 Token 成本评估表团队内部可以用一张很朴素的表来评估 AI 功能。功能平均输入 token平均输出 token日调用量主要 token 来源优化动作内部制度问答48008001000RAG 片段降低 TopK文档去重客服回复草稿32006003000历史工单历史摘要模板缓存代码修复 Agent180002500200日志和文件压缩工具输出合同审阅40000300050合同原文分段审阅保留引用这张表的重点不是精确到个位数而是建立一种成本意识哪个功能调用量最大 哪个功能单次最贵 哪个功能最容易优化 哪个功能不能轻易压缩 哪个功能适合换小模型 哪个功能应该异步处理。很多团队一开始会把所有任务都交给同一个强模型。更成熟的做法是按任务分层任务模型策略分类、路由、意图识别小模型或规则优先简单 FAQ中等模型 短上下文复杂文档问答强模型 高质量 RAG合同、代码、安全审查强模型 保守上下文摘要和日志压缩低成本模型或规则这样做的好处是token 成本不再是黑箱。你不是每次都问“这次账单为什么高”而是提前知道“这个功能本来就贵贵在哪里怎么控”。十二、哪些 Token 不该省写成本优化时还有一个底线必须讲清楚不是所有 token 都应该省。这些内容通常不该轻易删合同里的限制条件 政策里的例外条款 代码里的类型定义 测试里的断言 安全审查里的输入来源 财务和审计里的原始数值 回答需要引用的原文证据。真正该省的是这些重复提示词 重复历史对话 无关检索片段 成功日志 进度条 模板化废话 旧版本文档 工具返回里的无用字段。一个简单判断方法是如果删掉这段内容答案是否仍然有证据 如果答案错了能不能追溯原因 如果用户追问来源能不能拿出原文如果不能就不要为了省 token 盲目压缩。Token 成本治理的目标不是让 AI 少读而是让 AI 不读废话。