Token 成本失控通常不是因为某一次调用太贵，而是因为团队没有把输入、输出、缓存、检索、工具调用、重试和模型路由当成同一个系统来管理。账单上涨时，很多人第一反应是换便宜模型，或者要求用户少问一点。这些办法有时有用，但不是根治。真正的成本治理要能回答六个问题：哪些任务在烧钱，哪些上下文没有价值，哪些输出过长，哪些重试是无效重试，哪些缓存没有命中，哪些模型被错误使用。

对于本地 AI 和云 API 混合架构，Token 成本更容易被低估。云端模型按输入输出计费，本地模型看似不按 Token 收费，但显存、吞吐、排队、功耗、运维和机器折旧同样会被上下文长度放大。一个团队如果不治理 Token，本地部署会变慢，云 API 会变贵，RAG 会变脏，Agent 会变得不可控。成本问题不是财务问题，而是产品体验、架构设计和上下文工程问题。

一、先把账算明白

第一步不是优化，而是计量。每次模型调用都应记录任务类型、用户入口、模型、输入 Token、输出 Token、缓存命中情况、检索片段数量、工具调用次数、重试次数、响应时间、是否成功、是否被用户采纳。没有这些字段，就只能看总账单，无法知道钱花在哪里。

成本要按任务而不是按接口看。一个“问答接口”里面可能包含意图识别、查询改写、向量检索、重排、答案生成、引用整理和后置审核。如果只统计最终答案生成，就会漏掉前面的隐藏调用。一个“Agent 任务”可能包含规划、工具选择、工具执行、错误恢复、总结和复盘，任何一步失控都会把成本放大。

成本还要分输入和输出。输入贵通常来自系统提示过长、历史消息过多、RAG 召回过宽、工具说明冗余、示例堆叠、重复资料未去重。输出贵通常来自回答无长度约束、模型重复解释、一次返回过多候选、让模型写完整报告而不是结构化要点。输入和输出的治理手段不同，混在一起只会误判。

二、建立 Token 预算，而不是事后抱怨

每个任务都应有预算。客服问答可以给较小预算，因为用户需要快速明确的答案；研究报告可以给较大预算，因为需要多轮检索和长输出；代码审查可以按文件规模动态分配；Agent 自动执行任务则要设置总预算和单步预算。预算不是死板限制，而是让系统知道什么时候应该压缩、降级、澄清或停止。

预算应拆成几部分：系统提示预算、用户输入预算、历史消息预算、检索资料预算、工具结果预算、模型输出预算。很多团队只限制最终输入总长度，结果最先被挤掉的是用户问题或关键资料。更好的做法是给每类上下文设上限，超过上限时按优先级裁剪。

预算还要和价值挂钩。高价值用户、高风险任务、高复杂任务可以使用更强模型和更长上下文；低价值噪声、重复问题、简单分类、格式转换不应占用旗舰模型。成本治理不是平均削减，而是把预算给真正需要推理能力的地方。

三、缓存：最容易被忽略的降本杠杆

缓存有两类。一类是应用层缓存，例如相同问题、相同文档摘要、相同检索结果、相同工具查询结果可以复用。另一类是模型供应商提供的 Prompt 或上下文缓存，例如稳定系统提示、稳定工具说明、稳定文档块在多次请求中复用时，可以降低成本或延迟。不同供应商能力不同，但共同原则是：稳定前缀越稳定，缓存越有效。

很多缓存命中率低，不是供应商能力差，而是团队把易变内容放在前面。时间戳、请求 ID、用户昵称、临时状态、随机排序资料、动态工具列表如果放在系统提示前部，会破坏稳定前缀。模板应把稳定指令、工具协议、输出规范放前面，把用户变量、检索片段、临时上下文放后面。这样既利于供应商缓存，也利于本地应用缓存。

应用层缓存要谨慎处理权限。知识库问答不能把 A 用户可见的答案缓存给 B 用户。缓存键必须包含租户、权限范围、知识库版本、模型版本、模板版本和关键输入。缓存结果也要设置过期策略。政策、价格、库存、模型版本、接口限制这类信息变化快，缓存时间要短；固定手册、历史规范、公共说明可以缓存更久。

缓存不只缓存最终答案。RAG 场景中，查询改写结果、嵌入向量、召回文档、重排结果、文档摘要都可以缓存。Agent 场景中，工具 schema、常用计划片段、权限检查结果、只读查询结果也可以缓存。不要只盯着最后一次生成调用。

四、压缩上下文：删掉无价值内容

上下文压缩不是把所有内容粗暴摘要，而是保留决策所需信息，删除噪声。一个十页文档未必比十条结构化事实更有价值。压缩应该先识别任务目标：用户要结论、证据、步骤、对比、代码修改，还是风险判断。不同目标需要不同信息。

对话历史要按状态压缩。早期闲聊、已解决问题、重复澄清、失败尝试不应长期占据上下文。可以维护一个会话状态摘要：用户目标、已确认约束、已做操作、未解决问题、重要偏好、禁止事项。新一轮调用优先使用状态摘要，而不是把全部历史原文塞进去。

RAG 资料要按证据压缩。不要把整段文档原文都塞给模型。可以先抽取与问题相关的段落、表格行、代码片段和来源元数据，再交给模型。若需要可解释性，保留引用和原文位置，而不是保留所有上下文。重排模型和引用生成比盲目增加 TopK 更能控制成本。

工具结果也要压缩。数据库查询、网页抓取、日志分析、代码搜索常返回大量结果。工具应返回结构化摘要、关键字段、异常项和可追溯 ID，而不是把全量 JSON 或日志直接扔给模型。模型需要的是可判断的信息，不是原始系统噪声。

五、路由：别让旗舰模型干所有活

模型路由是成本治理的核心。任务可以分层：简单分类、语言检测、字段抽取、格式转换、标题生成可以用便宜模型或本地模型；复杂推理、长上下文综合、代码修改、高风险决策使用强模型；需要隐私的数据留本地或私有部署；需要最新能力和强工具调用的任务走云端。

路由不能只按用户入口固定。一个入口里既有简单问题，也有复杂问题。应先做轻量意图识别，判断任务类型、风险等级、上下文长度、是否需要工具、是否需要引用、是否涉及隐私，再选择模型。路由失败时要能升级，例如便宜模型置信度低、输出校验失败、用户追问复杂化，就转强模型。

降级策略也要设计。供应商不可用时，可以切换同级模型、缩短上下文、关闭非必要多轮工具、返回需要人工确认的草稿，而不是无限重试。无限重试会把故障变成成本事故。重试必须带原因和上限：网络错误、限流、格式错误、工具超时、模型拒答分别处理。

六、任务拆解：减少一次性巨型调用

很多成本来自“一次性让模型做完所有事”。例如让模型读十篇资料、判断真假、写报告、给引用、生成表格、提出行动计划。这样的调用输入长、输出长、失败难定位。拆解后可以先检索，再抽取事实，再生成大纲，再写正文，再做事实检查。每一步都有较小上下文和明确验收。

拆解不是越细越好。过度拆解会增加调用次数和编排成本。合理拆解的原则是：每一步有明确输入输出；中间结果可复用；失败能单独重试；便宜模型能完成部分步骤；强模型只处理高价值综合任务。若拆解后每一步都用旗舰模型，成本未必下降。

任务拆解还可以减少返工。让模型先生成计划，用户确认后再执行，比直接生成长报告更省。让模型先列缺失信息，补齐后再分析，比带着不确定性写长文更省。让 Agent 每步产出工件和证据，比最后才发现方向错更省。

七、输出治理：长不等于好

输出 Token 失控很常见。用户问一个简单问题，模型回答背景、原理、步骤、注意事项、FAQ、总结；用户要列表，模型写长文；用户要结论，模型先铺垫。解决办法不是简单限制字数，而是让输出结构匹配任务。

可以给每类任务定义输出预算。故障排查先给三步行动；选型问题先给结论表；法律或医疗类高风险问题给边界和建议咨询专业人士；研究报告给摘要、证据和附录。正文很长时，把详细资料放在用户请求后再生成，而不是默认展开。

流式输出也不能替代输出治理。流式只能让用户更早看到内容，不能减少账单。真正减少输出成本，要在提示词、产品交互和后处理上控制长度。给用户“展开细节”“生成完整报告”“显示引用”这样的操作，比每次默认生成所有内容更合理。

八、RAG 成本：召回越多不一定越准

RAG 系统常把 TopK 调大来追求召回，结果成本上升、答案反而更差。过多片段会带来冲突、重复和噪声。正确做法是提升检索质量：更好的切分、更合适的嵌入模型、混合检索、重排、元数据过滤、权限过滤、文档新鲜度管理。把垃圾片段塞进上下文，是最贵的偷懒。

RAG 还要避免重复片段。同一段资料可能来自 PDF、网页、同步文档和历史备份，向量库里重复存在。召回后如果不做去重，模型会看到重复证据，以为它更重要。数据去重、段落指纹、来源优先级和版本字段都能降低无效 Token。

引用也会增加成本，但不能随便砍掉。对知识库问答，引用是信任来源。可以让模型只引用关键证据，而不是引用所有召回片段；可以把引用元数据结构化，减少自然语言解释；可以把完整引用列表放到可展开区域。目标是保留可验证性，同时减少冗余。

九、Agent 成本：限制步数和工具

Agent 比普通聊天更容易烧钱，因为它会规划、调用工具、观察结果、再规划。每一步都可能消耗输入输出 Token。如果工具返回大段内容，下一步又把全部观察塞回上下文，成本会指数增长。Agent 必须有步数上限、预算上限、工具结果压缩、失败停止条件和人工确认点。

工具选择要有权限和代价意识。只读查询可以自动执行，写操作、付费调用、批量任务和外部发布要确认。昂贵工具要先说明为什么需要。工具返回要结构化，避免把长日志原样送回模型。Agent 的记忆也要分层，短期状态、长期偏好、任务工件和外部知识库不要混成一个长上下文。

Agent 还需要验收闭环。没有验收，模型会继续“再检查一下”“再优化一下”，直到预算耗尽。任务开始前就要定义完成标准：生成文件、通过测试、给出引用、获得用户确认、完成工具动作。达到标准就停止，不要让 Agent 用更多 Token 追求虚假的完美。

十、监控指标：看见浪费发生在哪里

Token 成本监控至少包括输入 Token、输出 Token、缓存命中率、模型分布、任务分布、用户分布、重试率、失败率、平均延迟、P95 延迟、单任务成本、单成功任务成本。单成功任务成本很重要，因为失败调用也花钱。如果某个流程失败率高，降价模型也救不了。

还要监控上下文利用率。输入很长但答案没有引用其中大部分资料，说明检索或拼接有浪费。输出很长但用户很快追问“所以结论是什么”，说明表达浪费。重试很多但最终仍失败，说明错误恢复策略浪费。工具调用很多但没有改变答案，说明工具策略浪费。

监控不能只给工程看。产品要知道哪些入口成本最高，运营要知道哪些内容导致重复问题，财务要知道预算趋势，安全要知道高风险任务是否降级到了不该用的模型。成本治理是跨团队工作。

十一、组织流程：建立成本评审

每次新增 AI 功能，都应该有成本评审。评审不需要复杂，但要回答：预计每次任务调用几次模型，平均输入输出多少 Token，使用哪些模型，是否启用缓存，是否有重试上限，是否有降级路径，是否有成本告警，是否能按用户或租户限额。

每次模型升级，也要重新估算成本。新模型价格、上下文长度、输出习惯、工具调用能力、缓存规则都可能变化。更强模型不一定更贵，如果它能减少重试、减少工具调用、缩短提示词，反而可能降低总成本。反过来，便宜模型如果失败率高，最终也可能更贵。

每次知识库扩容，也要评估召回成本。文档越多，检索、重排和上下文拼接越容易失控。新增资料不只是上传文件，还要考虑元数据、版本、权限、去重和过期策略。否则知识库越大，Token 浪费越严重。

十二、一个可执行的降本顺序

第一步，开日志。记录每个任务的 Token、模型、缓存、重试、延迟、成功状态。没有计量，不做优化承诺。

第二步，找 Top 20 消耗任务。不要平均优化，先处理成本最高或增长最快的入口。

第三步，拆输入。把系统提示、历史、检索、工具结果、用户输入分开看，找最长且价值最低的部分。

第四步，控输出。为常见任务设置默认长度和展开机制，避免每次生成长报告。

第五步，做缓存。先缓存稳定系统提示、文档摘要、检索结果和常见问答，再考虑复杂语义缓存。

第六步，做路由。把简单任务迁到便宜模型或本地模型，复杂任务保留强模型，失败时自动升级。

第七步，做评测。确认降本没有明显伤害质量，尤其是引用准确性、工具调用正确性和用户满意度。

第八步，设预算和告警。按任务、用户、租户、模型设上限，异常增长及时提醒。

十三、把预算写进产品契约

Token 预算不能只存在工程配置里，也要进入产品契约。一个功能如果对用户承诺“生成完整行业报告”，就必须有足够预算；如果只是“快速回答资料库问题”，就不应该默认生成几千字长文。产品文案、交互按钮和模型预算要一致。否则用户点的是一个轻量按钮，后台却跑了重型工作流，成本迟早失控。

产品契约应该明确默认行为和展开行为。默认回答可以短，包含结论、依据和下一步；用户需要更多细节时，再触发展开。默认只回答当前问题，不默认附带背景科普；默认只引用关键资料，不默认列出所有召回片段；默认只执行必要工具，不默认做完整研究。这样做不是降低质量，而是把质量放在用户真正需要的地方。

预算也要体现在套餐和权限里。免费用户、试用用户、内部高频脚本、生产客户、管理员任务，不应共享同一套无限预算。没有租户级预算，某个自动化脚本就可能把公共额度打穿。没有用户级预算，少数高频用户会影响整体体验。没有任务级预算，复杂 Agent 会吞掉普通问答的资源。

社区服务尤其要注意滥用。开放社区里，用户可能粘贴整本书、整份日志、整段代码库，要求模型总结。系统应在上传、粘贴、检索和生成前给出明确边界：当前任务最多处理多少内容，超出后建议上传资料库、分段处理或改用异步任务。把限制说清楚，比悄悄截断更可靠。

十四、缓存命中率要能解释

很多团队说自己做了缓存，但说不清为什么命中率低。缓存命中率不是一个单独指标，它受模板结构、变量位置、资料版本、权限范围和用户行为影响。只看“命中百分比”没有用，必须能解释命中和未命中的原因。

可以把未命中分成几类：稳定前缀变化、用户变量变化、知识库版本变化、权限范围变化、模型版本变化、工具 schema 变化、缓存过期、缓存主动失效。每类原因对应不同处理。稳定前缀频繁变化，说明模板管理混乱；权限范围导致未命中，可能是必要安全成本；模型版本变化导致未命中，说明发布流程需要预热缓存；知识库版本频繁变化，说明资料同步策略可能过于粗糙。

缓存预热也有价值。对于高频入口，发布新模板或新模型后，可以先用核心样本预热稳定前缀和常用资料摘要。对企业内部知识库，热门手册、政策、产品介绍、故障处理流程可以定期生成摘要缓存。对代码库助手，仓库结构、模块说明和常见命令可以在索引阶段准备好。预热不是为了造假命中率，而是减少用户请求时的重复成本。

缓存失效要有规则。资料更新后，旧摘要不能长期使用；模型升级后，旧输出缓存可能不再符合质量标准；权限变更后，旧答案不能继续给离职或降权用户。缓存越强，失效越重要。成本治理不能牺牲权限和新鲜度。

十五、RAG 限额要从资料治理开始

RAG 成本失控经常被误认为是模型问题，其实根因在资料治理。文档没有版本，重复上传；PDF 解析质量差，切分混乱；网页同步带来导航栏和页脚噪声；表格被拆散，关键字段丢失；过期资料没有下架；权限元数据缺失。这些问题会让召回变多、重排变贵、上下文变脏。

资料进入知识库前就要做成本意识处理。解析阶段去掉目录噪声、页眉页脚、重复版权声明和空表格；切分阶段控制块大小和重叠比例；去重阶段用指纹识别近似重复；元数据阶段标明来源、版本、时间、权限、业务域和可信等级；同步阶段只增量更新变化内容，而不是每次全量重建。前面多做一分治理，后面少花很多 Token。

召回限额也要分任务。事实问答需要少量高精度片段；政策对比需要覆盖多个版本；故障排查需要日志、配置和手册同时参与；研究报告需要更宽召回但可以异步执行。不要用同一个 TopK 服务所有任务。可以先用小召回回答，如果置信度低或证据不足，再扩大召回。逐步扩大比默认大召回更省。

重排模型也要有预算。重排不是免费午餐，候选越多越贵。可以用元数据先过滤，再做向量召回，再做稀疏检索补充，最后只对候选集合重排。对于简单问题，甚至可以跳过重排；对于高风险答案，重排和引用校验必须保留。成本治理的目标不是砍功能，而是让功能按风险和价值启用。

十六、Agent 要有熔断，不然会自我放大

Agent 成本最危险的地方是自我放大。一次工具失败会引发重试，重试后模型尝试换工具，换工具后返回更多日志，日志又进入下一轮上下文，模型再解释日志，最后一个小问题变成几十次调用。没有熔断机制，Agent 会把不确定性转换成账单。

熔断条件要明确。连续两次同类工具失败就停止，要求人工确认；同一工具参数变化不大却反复调用，就停止；累计 Token 超过任务预算，就输出当前状态和建议；模型无法给出下一步理由，就停止；遇到写操作、付款、删除、发布和外部通知，必须确认。熔断不是失败，而是生产系统的安全边界。

Agent 还要区分探索和执行。探索阶段可以多查资料，但不能改外部状态；执行阶段必须按计划做少量高确定性动作；验证阶段只检查结果，不重新发散。很多成本事故来自探索和执行混在一起，模型一边想一边改，一边改一边查，最后既贵又危险。

任务记忆也要节制。Agent 不应该把所有观察永久带入上下文。每一步结束后，保留状态摘要、关键证据、已执行动作、失败原因和下一步候选即可。原始日志和工具返回放到外部工件里，通过 ID 引用。需要时再读取，不需要时不要占上下文。

十七、把重试当成成本中心

重试常被隐藏在 SDK 或网关里，最终账单却由它放大。一次用户请求看起来只有一次生成，实际上可能因为超时、限流、格式错误、网络波动、工具异常和安全拒答重试了多次。如果没有把重试次数写入日志，团队会误以为模型本身贵，而不是重试策略贵。

重试要分类型。网络错误可以短延迟重试；限流需要退避或换供应商；格式错误可以要求模型修复一次，但不能无限修复；工具错误应先检查工具参数和服务状态；安全拒答不应通过换说法反复绕过；用户输入缺失应澄清，而不是让模型猜。所有重试都要有上限和原因。

重试还要保留上下文差异。格式修复时，不需要把完整资料再次发送，可以只发送原输出、错误信息和目标 schema。工具重试时，不需要重新规划完整任务，可以只重试失败工具。供应商切换时，要注意模型差异，不能把同一长上下文盲目复制给另一个模型。精细重试比整条链路重跑便宜得多。

十八、本地模型不是免费模型

社区里常有人说“用本地模型就没有 Token 成本”。这句话只对账单表面成立。实际上，本地模型的成本体现在吞吐、延迟、显存、机器、电力、散热、维护、模型更新、量化质量和服务稳定性。长上下文会占用更多 KV Cache，降低并发；大输出会占用生成时间，拉长队列；错误路由会让本来能用小模型处理的任务占满大模型服务。

本地推理也需要 Token 预算。每个任务消耗多少输入输出，平均生成速度是多少，P95 等待多久，队列长度多少，显存占用多少，都要监控。没有这些指标，本地服务会从“省钱”变成“慢而不可用”。如果用户等待时间太长，最终还是会切回云模型，形成双重成本。

本地模型更适合做稳定、可控、隐私敏感或高频简单任务。比如分类、摘要初稿、日志初筛、嵌入、轻量问答、格式转换、离线批处理。复杂推理、强多模态、长上下文综合、严格工具调用仍可能需要云模型。混合架构要让本地模型承担合适工作，而不是为了省钱把所有任务都压到本地。

十九、成本优化必须做质量回归

降本最怕降质量。缓存可能返回过期答案，压缩可能删掉关键证据，路由可能把复杂任务发给弱模型，拆解可能丢失全局目标，输出限制可能让答案不完整。每次降本改动都要跑回归评测，确认关键路径没有退化。

评测集要覆盖高频问题、高价值客户问题、高风险问题、长上下文问题、工具调用问题、RAG 引用问题和历史事故样本。指标不能只看模型评分，还要看引用是否正确、工具是否正确、是否需要人工补救、是否节省真实成本。一个方案如果省了百分之三十 Token，却让人工处理增加一倍，实际并不省。

质量回归还要看用户体验。更短答案未必更差，但如果用户需要连续追问三次才能得到完整信息，整体成本可能更高。更便宜模型未必更差，但如果用户满意度下降或投诉上升，长期价值会受损。成本优化必须和体验指标一起看。

二十、团队落地模板

可以给每个 AI 功能建立一张成本卡：

功能名称：
用户入口：
任务类型：
默认模型：
备用模型：
本地模型是否可用：
平均输入 Token：
平均输出 Token：
P95 延迟：
缓存策略：
RAG TopK：
重排策略：
最大工具步数：
最大重试次数：
单任务预算：
超过预算处理：
质量回归集：
负责人：

这张卡不是一次性文档，而是上线后持续更新。每次模型换代、价格变化、知识库扩容、提示词改版、工具变化，都要更新成本卡。团队讨论成本时，不再凭感觉说“太贵”或“还好”，而是看每个入口的真实数据。

还可以建立月度成本复盘。看哪些任务增长最快，哪些缓存命中下降，哪些用户触发异常消耗，哪些失败重试最多，哪些模型路由不合理。复盘结论要变成具体改动：调预算、改模板、做缓存、拆任务、优化检索、增加告警、修改套餐。成本治理只有进入固定节奏，才不会等到账单爆炸才处理。

二十一、三个常见成本事故

第一个事故是长提示词模板失控。团队最初只有一段简短系统提示，后来为了修复格式问题、安全问题、语气问题、工具问题、引用问题，不断往里面加说明。半年后，一个普通客服问答的系统提示已经超过用户问题几十倍。每次调用都带着大量低价值历史补丁，缓存又因为模板频繁改动而命中很低。解决这类事故，不是继续追加规则，而是重构模板：拆出稳定系统前缀，拆出任务模板，拆出输出 schema，删掉已经被结构化输出和后处理覆盖的自然语言约束。

第二个事故是知识库召回失控。某团队把所有文档都同步进向量库，默认 TopK 从五调到二十，又为了“提高准确率”把每个片段重叠设置很大。结果一次问答带入大量重复段落，模型开始在冲突资料中摇摆，答案变长，引用变乱，账单也上涨。正确修复是先治理资料：按版本去重，过滤页眉页脚，给资料加业务域和有效期，按问题类型动态选择 TopK，再用重排模型控制进入上下文的证据数量。

第三个事故是 Agent 自动重试失控。一个浏览器代理在网页加载失败后反复刷新，又把每次失败截图和错误日志写进上下文，最后一个简单表单任务消耗大量 Token。修复方式是建立熔断：同一页面连续失败两次就停止；截图只保留最新关键状态；错误日志只保留摘要；超过预算后向用户说明当前卡点，而不是继续试。Agent 不是越坚持越好，生产系统要知道什么时候停止。

二十二、指标阈值可以从粗到细

刚开始做成本治理，不必追求完美指标。可以先设粗阈值：单次普通问答输入不超过某个预算，输出不超过某个预算，重试不超过一次，RAG 进入生成的片段不超过固定数量，Agent 工具步数不超过固定上限。粗阈值能先挡住明显浪费。

第二阶段再做动态阈值。根据任务类型、用户等级、知识库规模、模型能力、历史成功率自动调整预算。复杂研究任务可以申请更大预算，普通问答保持短路径；高风险任务保留强模型和引用，低风险格式转换走便宜模型；命中缓存的任务允许更快返回，缓存未命中的任务走完整链路。

第三阶段要做异常检测。某个入口 Token 突然上涨，可能是新模板过长；某个用户成本突然上涨，可能是自动脚本或滥用；某个模型输出突然变长，可能是模型版本或系统提示变化；某个知识库调用变贵，可能是资料同步重复。异常检测不是为了惩罚用户，而是让团队在账单爆炸前发现问题。

指标还要看趋势。单日成本高不一定是坏事，可能是正常活动；单任务成本缓慢上涨更危险，说明系统在被复杂度侵蚀。每次功能上线、模型切换、知识库扩容、模板改版后，都要观察一段时间，确认成本曲线是否按预期变化。

二十三、混合架构的分工建议

本地模型、私有模型和云 API 不应该互相替代，而应该分工。高频、低风险、隐私敏感、格式稳定的任务适合本地：分类、摘要初稿、日志初筛、嵌入生成、简单问答、批量离线处理。需要强推理、强多模态、最新模型能力、复杂工具调用和高质量长文生成的任务，可以走云端。中间层用统一网关做路由、审计、限额和回退。

混合架构要避免重复推理。同一个请求不要先本地跑一遍、再云端完整跑一遍，除非这是明确的级联策略。更好的方式是本地做预处理和压缩，云端做关键推理；或者本地先给低成本答案，置信度不足再升级云端。升级时应携带压缩后的状态，而不是把原始长上下文复制过去。

本地部署还要看并发。一个模型在单用户测试时很快，不代表生产可用。上下文越长，KV Cache 占用越大，并发越低。团队应测不同上下文长度下的吞吐和延迟，把本地模型的“隐形 Token 成本”换算成排队时间、机器成本和用户体验。只有这样，才知道哪些任务应该本地跑，哪些任务应该交给云端。

二十四、提示词和工具说明也要瘦身

很多系统提示里有大量重复内容：一遍说明角色，一遍说明输出格式，一遍说明安全边界，一遍说明不要泄露内部信息，又在每个工具说明里重复相同要求。模型并不会因为重复十遍就稳定十倍。重复说明会占用上下文，还可能造成歧义。模板瘦身应删除重复、合并相近规则，把机器可校验的约束交给 schema 和后处理。

工具说明要写给模型使用，不是写给人看。好的工具说明包含工具能做什么、何时使用、必填参数、错误处理和限制；坏的工具说明包含一大段背景故事、内部实现、无关字段和自然语言示例。工具越多，说明越要短。对于不常用工具，可以在路由阶段按需注入，而不是每次把全部工具表塞进上下文。

示例也要控制。Few-shot 示例有价值，但示例太多会让模型模仿不该模仿的细节。示例应覆盖边界和格式，而不是堆数量。模型升级后，旧示例可能不再必要；结构化输出上线后，格式示例也可以减少。每个示例都应能解释它保留的原因，否则就是成本负担。

二十五、从用户体验看成本

成本治理最终会体现在用户体验里。一个回答短但清楚，用户满意，成本低；一个回答长但混乱，用户继续追问，成本高；一个 Agent 自动跑十步但没完成，用户失望，成本高；一个系统先澄清关键条件再执行，虽然多一次交互，却避免长任务返工，实际更省。

产品设计可以主动帮助降本。让用户选择“快速回答”“详细解释”“生成报告”；让用户在上传大文件前选择目标；让用户确认是否需要联网检索；让用户选择引用数量；让用户把大任务保存为异步作业。这些交互不是把成本负担甩给用户，而是让用户用明确意图换取更合适的模型行为。

也不要为了降本破坏信任。不能偷偷截断关键资料后假装读完，不能用弱模型处理高风险问题却不做校验，不能为了省输出 Token 删除必要引用，不能为了命中缓存返回过期答案。生产级降本必须透明、可控、可回滚。

二十六、给小团队的第一周行动

第一天，给所有模型调用加统一日志，至少记录任务名、模型、输入输出 Token、延迟、成功状态。第二天，按任务汇总成本，找出最贵的五个入口。第三天，检查这五个入口的系统提示、历史消息、RAG 片段和输出长度。第四天，给它们设置预算和输出结构。第五天，给高频稳定内容加缓存。第六天，引入简单路由，把分类、摘要、格式转换等任务迁到便宜模型或本地模型。第七天，跑一批真实样本，确认质量没有明显下降。

第一周不要试图搭建完美成本平台，也不要先做复杂仪表盘。先把最粗的浪费挡住：重复上下文、过长输出、无限重试、过宽召回、旗舰模型滥用。很多团队做到这一步，成本就会明显下降，系统也更容易解释。

第二周再做工程化：把预算写进配置，把模型路由放进网关，把缓存键纳入权限和版本，把失败样本进入评测，把异常成本接入告警。第三周再做组织化：建立月度复盘，给每个 AI 功能建立成本卡，让产品、工程、运营和财务都能看懂成本从哪里来。

二十七、不要优化错对象

成本治理还有一个陷阱：只优化单次模型调用价格，不优化完整任务成本。一个便宜模型如果需要更长提示词、更多示例、更多重试和更多人工返工，最终可能比强模型更贵。一个强模型如果能一次完成、少调用工具、少产生错误、少占用人工，整体反而更省。选模型时要比较“成功完成一次任务”的总成本，而不是只比较百万 Token 单价。

也不要只优化机器成本，忽略人的时间。为了省一点 Token 让答案变短，如果用户需要反复追问，客服需要二次解释，工程需要手工修复，成本只是从账单转移到了人。生产级 AI 系统的目标是总成本可控，包括模型、机器、等待时间、人工处理和用户信任。

最后，不要用成本治理掩盖产品边界不清。用户真正需要的是明确结果，而不是无限对话。很多 Token 浪费来自产品没有让用户选择目标、范围和深度。把入口设计清楚，把任务拆小，把默认输出做准，比在底层反复压缩更有效。

结论

Token 成本失控不是一个参数能解决的问题。它来自上下文工程、产品交互、模型路由、RAG 数据、Agent 编排、缓存策略和组织流程共同失衡。真正有效的治理，不是让模型少说一点，而是让系统只把有价值的信息交给合适的模型，在合适的步骤生成合适长度的结果。

如果团队只能做一件事，就先建立调用级成本日志；如果能做两件事，再把任务预算和缓存做好；如果要做成生产级能力，就把路由、压缩、评测、告警和回滚纳入同一套工程流程。成本可控，AI 应用才有可能长期运行，而不是演示时很强、上线后太贵。

参考资料

1. OpenAI，Prompt caching： https://platform.openai.com/docs/guides/prompt-caching
2. OpenAI，API pricing： https://openai.com/api/pricing/
3. Anthropic，Prompt caching： https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
4. Anthropic，Pricing： https://www.anthropic.com/pricing
5. Google Cloud Vertex AI，Context cache overview： https://cloud.google.com/vertex-ai/generative-ai/docs/context-cache/context-cache-overview
6. Google AI for Developers，Gemini API pricing： https://ai.google.dev/gemini-api/docs/pricing
7. LangChain，How to track token usage： https://python.langchain.com/docs/how_to/llm_token_usage_tracking/
8. LangSmith，Trace LLM applications： https://docs.smith.langchain.com/observability/how_to_guides/trace_llm_applications
9. LlamaIndex，Cost analysis： https://docs.llamaindex.ai/en/stable/module_guides/observability/cost_analysis/
10. Microsoft Azure OpenAI，Plan and manage costs： https://learn.microsoft.com/en-us/azure/ai-services/openai/how-to/manage-costs
11. AWS Well-Architected，Cost optimization pillar： https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html
12. Google Cloud Architecture Center，Cost optimization： https://cloud.google.com/architecture/framework/cost-optimization