LLM 的 API 通常是按 token 计费的。每一次发送和接收的数据都对应着具体的费用。当你从原型开发过渡到生产环境——请求数量从几十飙升至每天数千次时——是否进行了 token 用量优化，其年度成本差异可能高达数万美元。
本指南全方位解析了 LLM token 优化策略。内容基于 Anthropic 官方文档的研究、真实世界的使用数据，以及关于检索增强生成（RAG）和长上下文性能的学术成果。
核心论点：token 优化本质上是上下文工程问题，而非单纯的精简提示词。 许多团队陷入了缩短提示词的误区，但实际上，导致成本飙升的元凶往往是臃肿的上下文、闲置的工具架构以及过时的对话历史。
为何 token 优化刻不容缓
三大趋势使得 token 优化变得愈发关键：
- 定价分级：Anthropic 现有的模型（Opus 4.7, Opus 4.6, 以及 Sonnet 4.6）均以标准价格包含完整的 1M token 上下文窗口——长上下文的附加费已于 2026 年 3 月取消。旧版 Sonnet 4/4.5 的 1M 上下文 beta 版将于 2026 年 4 月 30 日停用；Sonnet 4 和 Opus 4 模型本身也已被弃用，并将于 2026 年 6 月 15 日退役——使用这些模型的团队应分别迁移至 Sonnet 4.6 和 Opus 4.7。OpenAI 最新的旗舰模型是 GPT-5.5（2026 年 4 月发布），价格为每 MTok $5/$30，并提供 90% 的缓存输入折扣（缓存输入每 MTok $0.50）——但 GPT-5.5 Pro ($30/$180/MTok) 不提供缓存输入折扣。此前的 GPT-5.4 系列（$2.50/$15，mini 版 $0.75/$4.50，nano 版 $0.20/$1.25）依然可用，同样享有 90% 的缓存输入折扣。一个重要的注意事项：Claude Opus 4.7 采用了全新的分词器，处理相同文本时消耗的 token 数量比 Opus 4.6 多出多达 35%（在处理代码和结构化数据时更为显著，对纯英文文本影响微乎其微）——在迁移或估算成本时请务必将此因素考虑在内。
- Agent 架构：代码编写 Agent、工具使用工作流以及多步推理都会成倍增加 token 的消耗。单次 Agent 会话消耗的 token 数量可能是简单 API 调用的 10 到 100 倍。
- 长上下文的收益递减：研究表明，埋没在长上下文中间的相关信息被利用的可靠性较低。更多的 token 不仅意味着更高的成本，甚至可能导致结果变差。
下文列出的策略是按照对大多数团队的投资回报率（ROI）从高到低排序的。
1. 上下文工程与会话管理
LLM 应用中 token 最大的浪费源在于上下文膨胀——即发送了远超当前步骤所需的上下文信息。
关键策略：
- 分阶段处理工作：将发现、实施和验证分离到不同的会话中进行。失败尝试产生的过时上下文不仅会降低后续轮次的质量，还会持续增加计费。
- 即时检索：仅在确切需要时才提取相关信息。针对性的文件读取和 LSP 导航远胜于直接倾倒整个仓库。关于迭代式仓库检索的研究显示，与单文件补全相比，这种方法在使用更少上下文的同时，准确率提升了 10% 以上。
- 仓库记忆：将持久的项目知识（架构、约定、构建命令）存放在结构化的配置文件中（如 CLAUDE.md），使其自动加载，而不是在每次对话中手动输入。
- 服务端上下文摘要：Anthropic 的 Compaction API（2026 年 2 月 beta 版）允许 Opus 4.6 自动对对话历史进行摘要和压缩，从而实现几乎无限的对话，无需手动修剪上下文或重置会话。
这是对大多数团队影响最大的优化手段。阅读深度解析：上下文工程：为何减少 Token 用量不等于缩短提示词
2. 特定供应商的 API 技巧
每个 LLM 供应商都设计了专门用于降低成本的功能。但大多数开发者要么没有使用，要么使用方式不当。
关键策略：
- 提示词缓存：Anthropic 的缓存读取成本仅为基本输入价格的 0.1 倍——即享受 90% 的折扣。Anthropic 现已支持多轮对话的自动缓存（通过单一的顶层
cache_control字段自动管理断点），同时也保留了原有的显式断点方式。GPT-5.5 和 GPT-5.4 均提供 90% 的缓存输入折扣，与 Anthropic 的费率持平（例外：GPT-5.5 Pro 没有缓存输入折扣）。 - Advisor Tool（2026 年 4 月 beta 版）：将廉价的执行模型（Sonnet 4.6 或 Haiku 4.5）与作为高智能顾问的 Opus 4.6 或 Opus 4.7 搭配使用，仅在必要时咨询顾问。典型的编码 Agent 会话成本比单独使用 Opus 低 73–87%，因为大多数轮次由 Sonnet/Haiku 费率处理，而顾问每次咨询仅生成 400–700 个 token。注意：如果使用 Opus 4.7 作为顾问，在估算顾问轮次成本时，需考虑其新的分词器。
- 抑制思考输出：Claude 4.6 模型支持
thinking.display: "omitted"，可从 API 响应中剥离推理轨迹。模型仍会在内部进行推理，你只是无需为最终会被丢弃的轨迹支付输出 token 费用。 - 结构化输出：工具架构和 JSON 模式消除了因格式错误响应导致的重试循环。每减少一次重试，就节省了一整笔 API 调用费用。
- 批量 API：所有主要供应商均提供 50% 的折扣，适用于非时间敏感的工作负载。
- 输出限制：设定现实的
max_tokens，请求提供差异而非全文重写，并使用停止序列。
阅读深度解析：如何降低 OpenAI 和 Claude API Token 成本
3. 工具与架构开销的削减
一个大多数开发者都未曾察觉的浪费源：工具定义会被包含在每一次 API 请求中。实测显示，在实际应用中，工作开始前的工具定义开销高达 55K 至 134K token。
关键策略：
- 禁用未使用的 MCP 服务器：无论是否使用，每个服务器的工具定义都会在每次请求时加载。
- 按需加载工具：采用工具搜索模式，仅在需要时加载工具。这一举措将某项设置的开销从 134K 降至 8.7K token——减少了 85%。
- 优先使用 CLI 工具：当直接命令行工具能胜任时，可避免 MCP 层带来的架构开销。
- 渐进式披露：使用 Skills 或等效模式，使得完整指令仅在触发时才加载。
阅读深度解析：削减 MCP 和工具开销，每次请求节省数千 Token
4. 提示词缓存架构
缓存不仅仅是一个开关，它更是一种架构。许多团队虽然启用了提示词缓存，但由于提示词设计不当，命中率很低。
关键策略：
- 稳定前缀模式：将稳定的内容（系统指令、工具定义）放在前面，将可变的内容（用户输入）放在后面。
- 多层缓存：利用断点对不同变化频率的区块进行独立缓存。
- 避免缓存破坏：系统提示词中的时间戳、被打乱的少样本示例以及动态工具列表都会破坏缓存命中率。
阅读深度解析：设计高命中率的提示词缓存：输入 Token 省钱攻略
5. 模型路由与规格调整
并非所有任务都需要动用最昂贵的模型。建立一个路由层，将简单任务分发给低成本模型，将复杂难题分发给高成本模型，可削减 40–60% 的成本。
关键策略：
- 基于任务的路由：分类、提取和格式化任务交给小模型（Haiku 4.5, gpt-5.4-nano，价格 $0.20/MTok）。复杂的推理和架构决策交给大模型（Opus 4.7 或 Opus 4.6, GPT-5.5 Pro）。值得注意的是，o3 的价格在 2026 年 4 月下调了 80%（降至 $2/$8/MTok），使得强推理能力在中端成本范围内即可获得——如果你此前因价格原因放弃过它，现在值得重新评估。当专门路由到 Opus 4.7 时，请先验证 token 预算——对于代码密集型输入，其新分词器比 Opus 4.6 多消耗高达 35% 的 token。
- 思考/投入控制：扩展思考会消耗输出 token（这也是最昂贵的类型）。对于简单任务，请调低此项。
- 子 Agent 模型选择：将简单的子 Agent 工作路由到更便宜的模型。Agent 团队使用的 token 数量约为标准会话的 7 倍，因此模型选择至关重要。
6. 衡量与监控
无法衡量的东西就无法优化。大多数团队优化错了方向，因为他们没有测量 token 到底消耗在哪里。
关键策略：
- 使用内置工具：Claude Code 的
/cost、/context和/mcp命令可实时显示 token 使用情况。 - API 级别追踪：Token Count API（预检）和 Usage & Cost API（事后按模型、缓存和上下文层级细分）。
- 找出真正的热点：研究表明，审查和返工循环平均消耗约 59% 的 token——而非初始生成阶段。输入上下文的增长，而非提示词的大小，通常是主要的成本驱动因素。
阅读深度解析：如何衡量和监控 LLM Token 使用量
7. 节省 Token 的提示词模式
你提示模型的方式——以及你要求输出的格式——会独立于上下文大小，显著影响 token 的消耗。
关键策略：
- 思维草稿链：一种提示词技术，能匹配思维链的准确率，同时仅消耗 7.6% 的推理 token。模型不再进行冗长的逐步推理，而是用约 5 个单词草拟每个步骤。
- 输出格式优化：对于相同数据，JSON 消耗的 token 大约是 YAML 或 TSV 的两倍。对于兼容性要求不高的内部管道，切换格式可让结构化输出成本减半。
- 提示词压缩：像 LLMLingua 这样的工具可以将提示词压缩多达 20 倍，同时保持模型正确回答的能力——这对于包含长检索块的 RAG 管道特别有效。
- 语义缓存：应用程序级别的缓存，匹配语义相似的查询（而不仅仅是精确的前缀），从而完全避免针对重复问题类型的 API 调用。
阅读深度解析：节省 Token 的提示词模式：CoD、输出格式与提示词压缩
ROI 最高的三项改进
如果你只时间进行三项优化，研究和生产数据建议优先考虑以下几项，因为它们带来的收益最大：
-
在一个会话中定规格，在全新会话中实施。在不同阶段之间重置上下文，消除了过时历史带来的复合成本。这无需任何成本即可实施，并能立即减少每一轮后续对话的 token 消耗。
-
用精准检索替代代码库倾倒。利用代码智能、LSP 导航和专注的文件读取，而不是将整个文件或目录倾倒进上下文。上下文更少，结果更好，成本更低。
-
精简工具和 MCP 服务器，并对剩余稳定部分进行缓存。禁用未使用的服务器，切换到按需加载工具，并确保你剩余的工具定义对缓存友好。这能解决在每一次请求中都会产生的固定开销。
这三项针对的是几乎在每一轮都会出现的经常性 token 泄漏：过时的历史、不相关的代码上下文以及闲置的工具架构。
跨供应商通用的策略
虽然本指南中的示例特别引用了 Claude 和 OpenAI，但底层问题——注意力有限、长上下文性能衰减、检索与倾倒的权衡、以及工具架构开销——并非特定供应商独有。同样的策略也适用于 Gemini、Codex 以及任何其他基于 LLM 的工具或 API。
基本原则不变：在正确的时间发送正确的上下文，衡量你的 token 去向，并优化真正的热点。
参考资料
- Anthropic: Claude Pricing — 价格层级、长上下文附加费及缓存费率
- Anthropic: Token-Saving Updates — 工具开销分析（55K–134K token）及按需加载结果
- RepoCoder: Repository-Level Code Completion — 迭代式检索与单文件补全的对比
- Lost in the Middle: How Language Models Use Long Contexts — 长上下文的收益递减
- Chain of Draft (CoD) — 用 7.6% 的 token 匹配 CoT 的准确率
- OpenAI: API Pricing — 模型定价及批量 API 费率
针对更具体的主题，请探索我们的其他指南：