LLM Token调优实战：2026全攻略与Token优化

LLM API 的计费单位是 Token。每一个发送和接收的 Token 都会产生费用。当你从原型开发过渡到生产环境——从每天几十次请求增加到数千次——优化与否的 Token 使用量差异，每年可能导致数万美元的成本差距。

本指南涵盖了 LLM Token 优化的全貌。它基于 Anthropic 文档的研究、真实世界的数据，以及关于检索增强生成（RAG）和长上下文性能的学术发现。

核心论点：Token 优化是上下文工程问题，而非单纯的提示词缩短问题。 大多数团队浪费时间精简 Prompt，而真正的成本驱动因素是臃肿的上下文、闲置的工具 Schema 和过时的对话历史。

为何 Token 优化如今至关重要

三大趋势让 Token 优化变得愈发重要：

定价分层：Anthropic 的最新模型（Opus 4.7, Opus 4.6 和 Sonnet 4.6）包含完整的 100 万 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 月发布），价格为 $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 采用了新的分词器，处理相同文本时比 Opus 4.6 多消耗高达 35% 的 Token（对于代码和结构化数据尤为明显，纯英文文本则可忽略不计）——在迁移或估算成本时请将此因素考虑在内。
Agent 架构：编程 Agent、工具使用流程和多步推理都会成倍增加 Token 消耗。单次 Agent 会话消耗的 Token 可能是简单 API 调用的 10 到 100 倍。
长上下文的收益递减：研究表明，埋没在长上下文中间的相关信息被利用的可靠性较低。更多的 Token 不仅意味着更高的成本，还可能导致更差的结果。

以下策略是按大多数团队的投资回报率（ROI）从高到低排序的。

1. 上下文工程与会话管理

LLM 应用中最大的 Token 浪费源在于上下文臃肿——发送了远超当前步骤所需的上下文信息。

核心策略：

分阶段处理工作：将发现、实施和验证拆分到不同的会话中进行。失败尝试留下的过时上下文不仅会在后续每一轮中产生费用，还会降低质量。
即时检索：在确切需要时拉取所需信息。针对性的文件读取和 LSP 导航优于直接倾倒整个代码库。关于迭代式仓库检索（RepoCoder）的研究显示，相比文件内补全，这种方法在使用更少上下文的同时，准确率提升了 10% 以上。
仓库记忆：将持久的项目知识（架构、约定、构建命令）放入像 CLAUDE.md 这样的结构化配置文件中自动加载，而不是在每次对话中手动输入。
服务端上下文摘要：Anthropic 的 Compaction API（2026 年 2 月 Beta 版）允许 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 月 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 费用。
结构化输出：工具 Schema 和 JSON 模式消除了因格式错误响应导致的重试循环。每一次消除的重试都意味着你少支付了一次完整的 API 调用费用。
批量 API：所有主要提供商（OpenAI, Anthropic, Google）都对非时间敏感的工作负载提供 50% 的折扣。
输出约束：设定现实的 max_tokens，请求差异而非完全重写，并使用停止序列。

阅读完整深度解析：如何降低 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 缓存命中率：如何节省 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 多产生高达 35% 的 Token。
思维/强度控制：扩展思维会消耗输出 Token（昂贵的那种）。对于简单任务，请将其调低。
子代理模型选择：将简单的子代理工作路由到更便宜的模型。Agent 团队使用的 Token 约为标准会话的 7 倍，因此模型选择更为重要。

阅读更多：5 种立即降低 LLM API 成本的方法

6. 衡量与监控

无法衡量的东西就无法优化。大多数团队优化了错误的指标，因为他们没有衡量 Token 到底花在了哪里。

核心策略：

使用内置工具：Claude Code 的 /cost、/context 和 /mcp 命令可揭示实时的 Token 使用情况。
API 级别追踪：Token Count API（飞行前检查）和 Usage & Cost API（按模型、缓存和上下文层级进行事后细分）。
找到真正的热点：研究表明，审查和返工循环平均消耗约 59% 的 Token——而非初始生成。输入上下文的增长，而非 Prompt 大小，通常是主要的成本驱动因素。

阅读完整深度解析：如何衡量和监控 LLM Token 使用量

7. 高效 Token 的提示模式

你提示模型的方式——以及你请求的格式——会独立于上下文大小，显著影响 Token 使用量。

核心策略：

思维链草稿：一种提示技术，在保持与思维链相当的准确率的同时，仅使用 7.6% 的推理 Token。模型不再进行冗长的逐步推理，而是用约 5 个单词起草每个步骤。
输出格式优化：对于相同数据，JSON 消耗的 Token 大约是 YAML 或 TSV 的 2 倍。对于兼容性要求不高的内部管道，切换格式可以减半结构化输出的成本。
Prompt 压缩：像 LLMLingua 这样的工具可以将 Prompt 压缩高达 20 倍，同时保持模型正确回答的能力——对于包含长检索块的 RAG 管道特别有效。
语义缓存：应用级别的缓存，匹配语义相似的查询（而不仅仅是精确的前缀），从而为重复的问题类型完全避免 API 调用。

阅读完整深度解析：Token 高效的提示模式：思维链草稿、输出格式与 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 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 费率

针对更具体的话题，探索我们的其他指南：