误区一：只算输出
多数场景输入远大于输出，只统计输出会把成本低估数倍。为什么容易发生：输出是用户看得见的部分，输入埋在代码与检索里。做法是把输入输出分开统计，再合并成每任务总量，才看得清真实结构。
误区二：按字数估 token
中文、英文、代码与结构化数据的切分比例不同，同一个字在不同模型里的 token 数也不同。怎么做：用目标模型的分词工具统计，再用账单校准；边界是跨模型比较前要统一口径，否则优化方向会被误差带偏。
误区三：忽略工具定义
工具的名称、描述与参数说明会随每次请求发送，工具越多开销越大。为什么常被漏掉：它们不在对话内容里。做法是统计工具定义占比，合并低频工具、精简描述；边界是描述过简会让模型选错工具，需要样本验证。
误区四：把缓存当免费
缓存通常按写入与读取分别计价，过期重建也会产生费用。怎么做：统计写入次数与命中次数，算净收益；边界是缓存键要含权限与版本，否则省了 token 却带来错误答案，返工成本更高。
误区五：只优化单价
总支出等于单价乘以用量，而用量由调用次数与单次长度决定。为什么单价最不该先动：换模型会影响效果且难以回滚，调用侧的去重与压缩风险更低。合理顺序是先削次数与长度，再考虑单价。
适用与不适用
适合谁
- 正在核对 token 账单与预算的团队
- 工具调用多、提示词复杂的问答系统
- 准备做成本预算与评审的研发负责人与财务
不适合谁
- 只有单轮短问答、用量极小的内部项目
- 不掌握请求明细、只做比价的采购岗位
典型场景
一家在线文档工具的团队按字数估算预算，实际账单高出不少。排查发现工具定义与检索片段占了输入的一半，且结构化输出字段冗长。团队先合并低频工具、精简字段，再用分词工具重算，预算与实际终于对得上。
可执行步骤
- 把输入与输出分开统计，算出各自占比与每任务总量，再合并看总数
- 用目标模型的分词工具统计真实 token，与账单逐月校准，留差异记录
- 统计工具定义与系统提示占输入的比例，找出可合并的低频项，再决定合并
- 检查缓存的写入与命中次数，算出净收益而不是只看命中率，按接口统计
- 按次数、长度、单价的顺序排优化项，逐项验证再推进下一步，不跳步
常见坑
- 按字数折算 token 并写进预算，中英混排误差很大，追加预算常常来不及，项目被迫缩量。
- 工具描述写得很长却从不使用，每次都计入输入，白白推高支出，也没人清理。
- 缓存键没带版本，内容更新后仍返回旧答案，用户投诉才发现，影响面不小，追溯也很困难。
- 先换便宜模型，效果下滑后回滚，中间浪费的评测与沟通没人计算，账面上也看不出。
自检与验收清单
- 输入与输出是否分开统计、留档可查
- token 统计是否与账单校准过，差异多大
- 工具定义占比是否算过并可精简合并
- 缓存净收益是否算过，而不是只看命中
- 优化顺序是否先次数、后长度、再单价
常见问题
中文一个字大约几个 token
常见模型里大致一个字对应一个到一个多 token，标点与英文单词另算，具体取决于分词器。不要用固定系数做预算，建议用目标模型的分词工具统计一批真实样本，得到自己的经验系数，再随模型更换重算。
工具多一定更贵吗
工具定义会计入每次请求，因此工具越多固定开销越大。但工具少也可能导致模型反复追问，间接增加轮次。建议按使用频率合并低频工具，把常用工具的描述写清楚，再用样本验证选择准确率。
缓存要不要按用户区分
涉及权限与个性化内容时必须区分，否则会出现越权或答非所问。公共知识与固定系统提示可以共享缓存。设计缓存键时把租户、权限等级与内容版本一并纳入，避免为了省钱牺牲隔离。