LLM API 的费用是按 Token 计算的。每一次发送和接收的 Token 都伴随着成本。当你从原型开发扩展到生产环境——从每天几十次请求增加到数千次——优化与未优化的 Token 使用量，每年可能产生数万美元的差距。
这份指南涵盖了 LLM Token 优化策略的全貌。内容基于 Anthropic 文档的研究、实际使用数据，以及关于检索增强生成（RAG）和长上下文性能的学术发现。
核心论点：Token 优化本质上是上下文工程问题，而非单纯的缩短 Prompt。 大多数团队在精简 Prompt 上浪费时间，而真正的成本驱动因素是臃肿的上下文、闲置的工具定义以及过时的对话历史。
为何当下 Token 优化至关重要
三大趋势使得 Token 优化愈发重要：
- 定价分级：Anthropic 的新模型（Opus 4.7, Opus 4.6, 和 Sonnet 4.6）均以标准价格包含完整的 1M Token 上下文窗口——长上下文附加费已于 2026 年 3 月取消。旧版 Sonnet 4/4.5 1M 上下文测试版将于 2026 年 4 月 30 日停用；Sonnet 4 和 Opus 4 模型本身也已被废弃，将于 2026 年 6 月 15 日退役——使用这些模型的团队应分别迁移至 Sonnet 4.6 和 Opus 4.7。OpenAI 最新的旗舰模型是 GPT-5.5（2026 年 4 月发布），价格为 $5/$30 每 MTok，并享有 90% 的缓存输入折扣（$0.50/MTok）——但 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 导航远胜于直接倾倒整个代码库。关于迭代式仓库检索（RepoCoder）的研究显示，相比文件内补全，使用更少上下文的情况下准确率提升了 10% 以上。
- 仓库记忆：将持久的项目知识（架构、约定、构建命令）放入结构化的配置文件（如 CLAUDE.md）中自动加载，而不是在每次对话中手动输入。
- 服务端上下文摘要：Anthropic 的 Compaction API（2026 年 2 月测试版）允许 Opus 4.6 自动摘要并压缩对话历史，从而实现无需手动修剪上下文或重置会话的无限对话。
这是对大多数团队影响最大的优化措施。阅读深度解析：上下文工程：为何减少 Token 用量不等于缩短 Prompt
2. 特定于供应商的 API 技巧
每个 LLM 供应商都有专门用于降低成本的功能。大多数开发者要么没用，要么用错了。
关键策略：
- Prompt 缓存：Anthropic 的缓存读取成本为基础输入价格的 0.1 倍——即 90% 的折扣。Anthropic 现在支持多轮对话的自动缓存（通过单个顶层
cache_control字段自动管理断点），同时也保留了现有的显式断点方式。GPT-5.5 和 GPT-5.4 均提供 90% 的缓存输入折扣，与 Anthropic 持平（例外：GPT-5.5 Pro 无缓存输入折扣）。 - Advisor Tool（2026 年 4 月测试版）：将廉价的执行模型（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，要求输出 diffs 而非完整重写，并使用停止序列。
阅读深度解析：如何降低 OpenAI 和 Claude API Token 成本
3. 工具与 Schema 开销的削减
大多数开发者不知道的一个浪费源：工具定义包含在每一次 API 请求中。实际环境的测量显示，在工作开始前，工具定义的开销高达 55K–134K Token。
关键策略：
- 禁用未使用的 MCP 服务器：每个服务器的工具定义会在每次请求时加载，无论你是否使用它们。
- 按需加载工具：使用“工具搜索”模式，仅在需要时加载工具。这一做法将某项设置的开销从 134K 降至 8.7K Token——减少了 85%。
- 优先使用 CLI 工具：当直接的命令行工具能胜任时，可避免 MCP 层的 Schema 开销。
- 渐进式披露：使用 Skills 或等效模式，仅在触发时加载完整指令。
阅读深度解析：削减 MCP 和工具开销，每次请求节省数千 Token
4. Prompt 缓存架构
缓存不仅仅是一个开关——它是一种架构。许多团队开启了 Prompt 缓存，但命中率很低，因为他们的 Prompt 设计并不利于缓存。
关键策略：
- 稳定前缀模式：将稳定内容（系统指令、工具定义）放在最前，将可变内容（用户输入）放在最后。
- 多层缓存：使用断点独立缓存变化频率不同的部分。
- 避免缓存破坏：系统 Prompt 中的时间戳、打乱的少样本示例以及动态工具列表都会破坏缓存命中率。
阅读深度解析：设计 Prompt 缓存命中：如何节省 90% 的输入 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 会使 Token 量增加多达 35%。
- 思维/投入控制：扩展思维会消耗输出 Token（昂贵的那一种）。对于简单任务，请降低此设置。
- 子代理模型选择：将简单的子代理工作路由到更便宜的模型。代理团队使用的 Token 约为标准会话的 7 倍，因此模型选择更为重要。
6. 测量与监控
无法量化就无法优化。大多数团队优化了错误的指标，因为他们没有测量 Token 到底花在了哪里。
关键策略：
- 使用内置工具：Claude Code 的
/cost、/context和/mcp命令可实时展示 Token 使用情况。 - API 级别追踪：Token Count API（飞行前检查）和 Usage & Cost API（事后按模型、缓存和上下文层级分解）。
- 找到真正的热点：研究表明，审查和返工循环平均消耗约 59% 的 Token——而非初始生成。输入上下文的增长，而非 Prompt 的大小，通常是主要的成本驱动因素。
阅读深度解析：如何测量和监控 LLM Token 使用量
7. Token 高效的 Prompt 模式
你如何 Prompt 模型——以及你要求输出的格式——会显著影响 Token 使用量，且与上下文大小无关。
关键策略：
- 思维草稿链：一种 Prompt 技巧，在保持思维链准确率的同时，仅使用 7.6% 的推理 Token。模型不再生成冗长的逐步推理，而是用约 5 个词起草每一步。
- 输出格式优化：对于相同数据，JSON 消耗的 Token 大约是 YAML 或 TSV 的 2 倍。对于兼容性要求不高的内部管道，切换格式可以减半结构化输出的成本。
- Prompt 压缩：像 LLMLingua 这样的工具可以将 Prompt 压缩高达 20 倍，同时保持模型正确回答的能力——对于包含长检索块的 RAG 管道尤为有效。
- 语义缓存：应用级缓存，匹配语义相似的查询（而不仅仅是精确前缀），从而完全避免针对重复问题类型的 API 调用。
阅读深度解析：Token 高效的 Prompt 模式：思维草稿链、输出格式与 Prompt 压缩
ROI 最高的 3 项改进
如果你只来得及做三项优化，研究和生产数据表明以下三项能带来最大影响：
在一个会话中规划，在全新会话中实施。在阶段之间重置上下文，消除了过时历史带来的复合成本。这无需任何成本即可实施，并能立即减少每轮后续的 Token 使用量。
用针对性检索替代代码库倾倒。利用代码智能、LSP 导航和专注的文件读取，而不是将整个文件或目录倾倒进上下文。上下文更少，效果更好，成本更低。
修剪工具和 MCP 服务器，然后对其余稳定部分依赖缓存。禁用未使用的服务器，切换到按需工具加载，并确保你剩余的工具定义对缓存友好。这直接攻击了每一次请求都要收费的固定开销。
这三项针对的是循环出现的 Token 泄露点：过时的历史记录、不相关的代码上下文和闲置的工具 Schema。
这些策略跨供应商通用
虽然本指南中的示例特别引用了 Claude 和 OpenAI，但底层问题——注意力有限、长上下文衰减、检索与倾倒的矛盾、工具 Schema 开销——并非特定于供应商。同样的策略适用于 Gemini、Codex 以及任何其他基于 LLM 的工具或 API。
基本原则不变：在正确的时间发送正确的上下文，追踪 Token 的去向，并优化真正的热点。
参考
- Anthropic: Claude Pricing — 定价层级、长上下文附加费和缓存费率
- Anthropic: Token-Saving Updates — 工具开销分析（55K–134K Tokens）及按需加载结果
- 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 费率
对于更具体的主题，请探索我们的其他指南：
来源：查看原文