应用 token 成本突然涨了 3 倍，怎么排查和治理？
谁在问：二三面·排障题；被成本考核的技术负责人、平台组、以及所有做过 Agent 产品的团队
口语化问法
- 假设某天你发现 token 成本突然涨了 3 倍，功能没上新，你怎么查？
- 你们做过成本治理吗？讲一个具体的例子，省了多少、怎么省的？
- 如果老板要求这个季度成本砍一半，你会按什么顺序做？
考察意图
这是排障题，考的不是知识，是排查的次序。面试官在等一句话："我先分桶，不猜。"
同时在判断三件事：
- 你知不知道成本的构成。 不知道输出单价是输入的五六倍、不知道思考 token 计在输出侧的人，第一刀就会切错方向。
- 你有没有真的看过账单和 trace。 这道题一旦落到"你们当时输入输出各占多少"，纸面知识就藏不住了。
- 你会不会被面试官带偏。 面试官经常顺口说"是不是模型涨价了""要不要换个便宜的模型"——跟着走就掉进了第三刀，而正确的第一刀还没切。
参考答案
60 分答案（及格线）
我会按这几步查：
- 先看是不是量的问题：DAU 涨了吗、请求数涨了吗。如果调用量本身涨了 3 倍，那就不是成本问题，是容量问题。
- 再看是不是有异常调用：有没有死循环、有没有重试风暴、有没有被刷。
- 然后看 prompt 有没有变长：是不是检索条数调大了、历史没有压缩、few-shot 例子加多了。
- 最后看模型：是不是有人把模型换成了更贵的，或者上游调价了。
治理上主要是几个手段：把 prompt 压短、上 prompt 缓存、把不重要的场景换成小模型、能异步的走批处理。如果还不够，就砍一些用得少的功能。
为什么只有 60 分：排查步骤是合理的，也没有跳过分桶。但方向不完整——全部集中在输入侧（prompt 变长、调用量），完全没有输出侧（effort 档位、输出长度、工具调用次数）。而 2026 年真实成本异动里，输出侧往往才是大头。而且治理手段是并列的，没有顺序，也没有说各自的代价。
90 分答案（有生产经验的回答）
我的第一句话是：先分桶，不猜。 成本异动几乎从来不是单一原因，而是几条合理改动的叠加，靠猜一定会漏。我用三刀。
第一刀：输入侧还是输出侧。
它排第一，是因为能立刻把范围砍掉一半，而且判据是硬数字：输出 token 单价是输入的五到六倍（截至 2026-08，Anthropic 全系 5 倍、OpenAI 全系 6 倍），且思考 token 四家全部按输出计费。同样涨 1000 万 token，涨在输出侧的钱是输入侧的五六倍。
操作很简单：从账单或 trace 拉出输入与输出 token 总量各乘单价，看哪边涨得多。这是一个查询就能出的数，没有任何理由靠猜。
这一刀还顺带解释了一个高频困惑——"我们上了缓存为什么还是没省钱"。因为缓存只作用于输入侧被缓存的那一段：
缓存节省率 = 0.9 · I / (I + k·O) k = 输出/输入倍数 输入 50K / 输出 2K（RAG 问答） → 67% 输入 50K / 输出 20K（含思考） → 27% 输入 2K / 输出 20K（长文生成） → 1.5%
成本大头在输出侧的时候，正确动作是去看 effort 和输出长度，而不是加缓存断点。
第二刀：各侧内部再切。
输入侧四个成因（按发现难度排）：① 工具结果累积——最常见也最被低估，工具结果默认是上下文的永久居民、成本按剩余轮次复利，一个 4000 token 的返回体在 10 轮会话里被重复计费近 10 次；② 上下文膨胀——检索条数调大、few-shot 加多、历史没压缩；③ 缓存命中率塌陷——唯一会静默发生的一类，缓存前缀里插入任何每次都变的内容都会让命中率归零，而账单上只表现为"输入变贵了"；④ 前缀低于最小可缓存长度——截至 2026-08 按模型分四档（512 / 1024 / 2048 / 4096），低于门槛静默不缓存、不报错。
输出侧三个成因：effort 档位、输出长度、工具调用次数。第三个最容易漏，而且它是输出侧影响输入侧的通道——提高 effort 会让工具调用次数变多，每次调用又把工具结果永久留在上下文里。
第三刀：单价。 前两刀都做完了才轮到换模型和路由，而且有一条硬判据：只有降两档才有意义——旗舰到次旗舰只有 2.5 到 3 倍价差，旗舰到同厂最小模型才是 10 到 80 倍。只降一档基本白忙。
举个真实例子。 客服 Agent 三周内成本涨 3 倍，功能没上新、DAU 只涨 15%。团队第一反应是砍功能，关了两个用得少的能力，结果只降了 8%。按三刀查出来是三条叠加：① 新加的订单查询工具返回完整 JSON、平均 4000 token，在多轮会话里复利；② 有人为修一个 badcase 把 effort 从 medium 提到 high——不只思考 token 变多，还让平均工具调用次数从 2.1 涨到 3.4，把第一条放大了；③ 有人在 system prompt 末尾加了一行"当前时间"，缓存命中率从 85% 掉到 12%，账单上完全看不出来。
三条里只有第三条是纯技术失误，另外两条都是"有人为了做对一件事而做的正常改动"。这就是成本排查的难点：它不是 bug，是一堆合理决策的叠加。
治理动作有严格顺序，越靠前"收益 / 风险"比越好：精确缓存（零风险，吃掉重复流量 15%–30%）→ prompt 缓存做满（零风险，输入侧降到 0.1 倍）→ 能异步的走批处理（五折且可与缓存叠加，代价是 24 小时窗口、不支持流式）→ 削工具结果（代价是可能丢信息，要跑轨迹评测）→ 降 effort 档位（输出侧唯一的大杠杆）→ 修缓存命中率 → 跨模型路由（降两档才有意义）→ 语义缓存（正确性风险不可消除）→ 减功能，最后一步，而且往往收效最小。
最后一条我一定会说：降 effort 会改变工具调用次数和整条轨迹，任何档位调整都必须重跑轨迹评测，不能只看最终答案。 这是我们的教训——第一次降档只抽查了答案，上线后才发现有一类工单因为少调一次工具而给出了不完整的结论。
追问链
你说先分桶。如果 trace 里根本没记这些数据怎么办？
期望最低要记：分环节输入/输出 token（缓存创建与读取分开记）、模型 ID 与 effort 档位、max_tokens、工具调用次数与结果 token 数、会话轮次。没有就先从上游控制台按 key、按模型、按天拆用量，立刻补埋点 —— 这次蒙对下次还得猜信号列得出「缓存创建与读取要分开记」 → 真做过成本归因；只说「看看日志」 → 没建过成本可观测怎么确认缓存命中率是不是塌了？
期望看用量字段：缓存读取与创建 token 分开报，创建高读取低就是每次都在重写。四种成因：① 前缀混进时间戳、随机 ID；② 前缀被改（改 tool 定义会让 system 与 messages 级联全失效）；③ 低于最小可缓存门槛，静默不缓存；④ 断点掉出回溯窗口信号知道「缓存创建与读取 token 分开报」并据此判断 → 真调过；只说「看命中率指标」却说不出它从哪来 → 多半没接过你要降 effort 档位，怎么保证质量不掉？
期望effort 缩放整个响应，含工具调用次数，验证必须轨迹级：① 离线跑high/medium/low三档对照；② 用不变量断言代替参考轨迹匹配（「没调订单工具不许返回订单状态」）；③ 灰度盯转人工率与重问率，比 judge 早报警。降档有时反而更好信号说出「effort 会改变工具调用次数所以必须做轨迹评测」 → 真调过档位；只说「跑评测集看分数」 → 会漏掉轨迹问题批处理五折听起来很香，为什么不是所有请求都走批处理？
期望三条硬约束：24 小时窗口（不保证时限）、不支持流式、批次与文件大小上限 —— 只适合真异步负载：跑评测、语料 embedding、批量打标。最易漏的收益：折扣可与 prompt 缓存叠加；风险是最容易饿死在线链路，得走独立配额池信号说得出「折扣可与 prompt 缓存叠加」和「要走独立配额池」 → 真用过；只说「批处理慢所以只能离线」 → 停在文档层面老板要下季度成本降 50%，还说「用户体验一点都不能降」，你怎么答？
期望① 先拉成本构成：输入/输出占比、命中率、可迁批量、旗舰占比 → ② 零体验损失的先做完：精确缓存、prompt 缓存做满、修命中率、迁批处理，多数团队能拿 30%–50% → ③ 缺口只能从降 effort、压输出长度、路由三处要，都要评测门禁 → ④「体验不能降」拆成首字延迟 / 质量分 / 转人工率三个可验收项信号第一动作是「拉成本构成」而不是承诺一个数字 → 真做过；能把方案分成「零损失」和「有取舍」两类交回决策 → 有职业成熟度
评分要点
- 第一句是"先分桶，不猜"，并说得出第一刀切什么
- 知道输出单价是输入的五六倍、思考 token 计在输出侧
- 能写出或口算缓存节省率公式，并知道推理密集场景会从 67% 掉到 27%
- 输入侧四个成因说得全，尤其是工具结果按剩余轮次复利
- 知道缓存命中率塌陷是静默的，并说得出排查方法
- 知道最小可缓存长度有门槛且低于门槛不报错
- 输出侧能说到工具调用次数，并指出它是输出侧影响输入侧的通道
- 主动说出 effort 会改变工具调用次数，必须重跑轨迹评测
- 治理动作有顺序，并解释为什么"减功能"排最后
- 知道只降一档没意义（2.5 到 3 倍 vs 10 到 80 倍）