2026年LLM Token优化全攻略：从入门到精通

LLM API 的计费是按 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 月发布），价格为 $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 架构：编码 agents、工具使用工作流和多步推理都会成倍增加 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 使用并非靠缩短提示词

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 月测试版）：将廉价的执行器模型（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：所有主要供应商（OpenAI、Anthropic、Google）都对非时间敏感的工作负载提供 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 上节省 90%

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（昂贵的那种）。对于简单任务，请调低它。
子代理模型选择：将简单的子代理工作路由到更便宜的模型。代理团队使用的 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 使用量，这与上下文大小无关。

关键策略：

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

阅读完整深度分析：Token 高效的提示词模式：Chain of Draft、输出格式与提示词压缩

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 — 迭代检索与文件内补全
Lost in the Middle: How Language Models Use Long Contexts — 长上下文的收益递减
Chain of Draft (CoD) — 使用 7.6% 的 token 匹配 CoT 准确率
OpenAI: API Pricing — 模型定价和批量 API 费率

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