大模型应用如何控制 Token 成本？
面试怎么回答
我会先把输入、输出、缓存和重试 Token 归因到模型调用、会话和业务任务，再从五处优化：按难度做模型路由；压缩历史与 Prompt；RAG 去重重排；提高前缀缓存和批处理；限制输出并治理重试。最终看的是每次成功任务成本，同时用固定评测集约束质量，避免单纯降 Token 导致完成率下降。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
业务量只增长了 20%，模型账单却翻了一倍。排查后发现，真正上涨的不是用户问题，而是越来越长的历史上下文、重复系统提示和无效检索内容。
Token 成本不是采购问题，而是数据链路和产品策略问题。
先按请求拆清 Token 去向，再从模型路由、上下文、检索、缓存和输出五个位置优化，并始终用质量回归做约束。
第一步：把成本算到具体场景
每次调用记录模型、应用、租户、Prompt 版本、输入 Token、输出 Token、缓存 Token、重试次数和工具调用。成本按 Model Call 计算，再汇总到 Turn、Session 和业务任务。
只看月度总账无法定位问题。需要知道哪个场景、哪个版本、哪类用户的“每次成功任务成本”上升了，以及上升来自输入、输出还是重试。
第二步：让模型与任务难度匹配
分类、改写、抽取等稳定任务不一定需要最强模型；复杂推理、高风险回答再路由到更强模型。路由规则要通过评测验证，不能只按关键词猜难度。
同一个任务也可以先用低成本模型尝试，在置信度不足、校验失败或用户升级时再走高能力路径。
第三步：治理不断膨胀的上下文
系统 Prompt 只保留真正有效的规则；工具目录按需加载；长会话把完成历史压缩成结构化状态；RAG 通过重排和去重保留少量高价值证据。
“给模型更多上下文更安全”往往是误区。无关内容既消耗 Token，也可能降低注意力和答案一致性。
第四步：提高缓存和批处理收益
把稳定系统指令、工具定义和公共背景放在前面，把用户动态内容放在后面，更有利于前缀缓存。监控缓存命中 Token，而不是只确认“已经打开缓存”。
离线抽取、Embedding 和批量生成可考虑批处理；重复知识查询可以缓存检索结果或最终回答，但缓存 Key 必须包含租户、权限、版本和时效边界。
第五步：限制输出与无效重试
通过明确格式、长度预算和结构化输出减少冗余生成。重试只针对可恢复错误，并设置退避、上限和幂等；格式校验失败时，优先局部修复，不要每次重新生成完整长答案。
一个典型反例
团队把近 50 轮完整对话、全部工具 Schema 和 Top20 文档都放入每次请求。为了偶尔需要的信息，所有请求都支付固定成本。
后来改成短期状态摘要、工具按需加载、检索重排和场景路由，成本结构才变得可解释。优化的前提仍是同一套 Evals 不能明显退化。