2026年LLM Token调优完全攻略

LLM APIs 采用按 token 计费的模式。无论是发送还是接收的每一个 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 上下文测试版将于 2026 年 4 月 30 日停用；Sonnet 4 和 Opus 4 模型本身已被弃用，并将于 2026 年 6 月 15 日退役——使用这些模型的团队应分别迁移至 Sonnet 4.6 和 Opus 4.7。OpenAI 最新的旗舰模型是 GPT-5.5（2026 年 4 月发布），价格为每百万 token $5/$30，并提供 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 相比，处理相同文本时消耗的 token 可能增加多达 35%（在代码和结构化数据处理上更为明显，纯英文文本影响较小）——在迁移或预估成本时请将此因素纳入考量。
Agent 架构：编码 Agent、工具使用工作流以及多步推理都会成倍增加 token 消耗。单次 Agent 会话消耗的 token 可能是简单 API 调用的 10 到 100 倍。
长上下文的边际效应递减：研究一致表明，埋没在长上下文中间的相关信息被利用的可靠性较低。更多的 token 不仅意味着更高的成本，甚至可能导致结果变差。

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

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

LLM 应用中 token 最大的浪费源是上下文膨胀——即在当前步骤远超模型需求地发送大量上下文。

核心策略：

分阶段处理工作：将发现、实施和验证放在独立的会话中进行。失败尝试产生的过期上下文不仅会在后续每轮中收费，还会降低质量。
即时检索：仅在确切需要时提取所需信息。针对性的文件读取和 LSP 导航远胜于仓库堆砌。关于迭代式仓库检索的研究表明，与文件内补全相比，在使用较少上下文的同时，准确率提高了 10% 以上。
仓库记忆：将持久的项目知识（架构、约定、构建命令）存放在结构化的配置文件中（如 CLAUDE.md），使其自动加载，而不是在每次对话中手动输入。
服务端上下文摘要：Anthropic 的 Compaction API（2026 年 2 月测试版）使 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 没有缓存输入折扣）。
顾问工具（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，要求提供差异而非完全重写，并使用停止序列。

阅读深度解析：如何降低 OpenAI 和 Claude API 的 Token 成本

3. 减少工具和架构开销

一个大多数开发者未曾察觉的浪费源：工具定义包含在每次 API 请求中。现实环境中的设置测量显示，在工作开始前，工具定义的开销就达到了 55K–134K token。

核心策略：

禁用未使用的 MCP 服务器：每个服务器的工具定义会在每次请求时加载，无论你是否使用它们。
按需加载工具：使用工具搜索模式，仅在需要时加载工具。这使得某项设置的开销从 134K 降至 8.7K token——减少了 85%。
优先使用 CLI 工具：当直接命令行工具能胜任时，它避免了 MCP 层的架构开销。
渐进式披露：使用“技能”或等效模式，仅在触发时加载完整指令。

阅读深度解析：削减 MCP 和工具开销，每次请求节省数千 Token

4. 提示词缓存架构

缓存不是一个开关，而是一种架构。大多数团队启用了提示词缓存，但命中率很低，因为他们的提示词并非为此而设计。

核心策略：

稳定前缀模式：将稳定内容（系统指令、工具定义）放在前面，将可变内容（用户输入）放在最后。
多层缓存：使用断点独立缓存变化速率不同的部分。
避免缓存破坏：系统提示词中的时间戳、打乱的少样本示例以及动态工具列表都会破坏缓存命中率。

阅读深度解析：设计提示词缓存命中：如何节省 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 模型选择：将简单的子 Agent 工作路由到更便宜的模型。Agent 团队使用的 token 比标准会话多约 7 倍，因此模型选择更为重要。

阅读更多：从今天起降低 LLM API 成本的 5 种方法

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 高效的提示词模式：思维草稿、输出格式与提示词压缩

ROI 最高的 3 项改进

如果你只有时间进行三项优化，研究和生产数据表明以下三项能带来最大的影响：

在一个会话中制定规格，在另一个全新会话中实施。在阶段之间重置上下文，消除了过期历史记录的复合成本。这实施起来毫无成本，并能立即减少每一轮后续的 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 — 迭代检索 vs 文件内补全
Lost in the Middle: How Language Models Use Long Contexts — 长上下文的边际效应递减
Chain of Draft (CoD) — 用 7.6% 的 token 匹配 CoT 准确性
OpenAI: API Pricing — 模型定价和批处理 API 费率

对于更具体的主题，请探索我们的其他指南：