LLM Token 效率提升指南：2026 年全攻略

新闻

LLM Token 效率提升指南：2026 年全攻略

新闻 2026-05-11 0 次浏览

LLM API 的计费是按 Token 算的。你发送和接收的每一个 Token 都要花钱。当你把项目从原型推向生产环境——从每天几十个请求增加到成千上万个——优化后的 Token 使用和未优化的情况相比，每年能省下的资金可能高达数万美元。

本指南全方位解析了 LLM Token 优化策略。内容基于 Anthropic 官方文档的研究、实际使用数据，以及关于检索增强生成（RAG）和长上下文性能的学术成果。

核心论点：Token 优化是“上下文工程”问题，而非单纯的“缩短提示词”问题。 大多数团队浪费时间精简 Prompt，却忽略了真正的成本推手：臃肿的上下文、闲置的工具 Schema 以及过时的对话历史。

为何当下 Token 优化至关重要

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

  1. 定价层级：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 月发布），价格为 $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%（代码和结构化数据更明显，纯英文影响微乎其微）——在迁移或估算成本时要考虑到这一点。
  2. Agent 架构：编码 Agent、工具调用工作流以及多步推理都会成倍增加 Token 的消耗。单次 Agent 会话消耗的 Token 可能是简单 API 调用的 10 到 100 倍。
  3. 长上下文的收益递减：研究表明，埋没在长上下文中间的相关信息被利用的可靠性较低。更多的 Token 不仅意味着更高的成本，甚至可能导致结果变差。

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

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

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

核心策略：

  • 分阶段处理工作：将探索、实施和验证放在独立的会话中进行。失败尝试产生的陈旧上下文不仅会在后续每一轮中持续计费，还会降低质量。
  • 即时检索：在恰好需要的时候，精准拉取所需信息。有针对性的文件读取和 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 买单。
  • 结构化输出：工具 Schema 和 JSON 模式消除了因格式错误响应导致的重试循环。每减少一次重试，就省下了一次完整的 API 调用费用。
  • 批量 API：所有主流供应商均提供 50% 的折扣，适用于非时间敏感型任务。
  • 输出限制：设定现实的 max_tokens，请求生成 Diff 而非完整重写，并使用停止序列。

阅读深度解析：如何降低 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 中的时间戳、打乱的少样本示例以及动态工具列表都会破坏缓存命中率。

阅读深度解析：设计高命中率的提示词缓存：如何节省 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（昂贵的那种）。对于简单任务，请调低强度。
  • 子代理模型选择：将简单的子代理工作路由到更便宜的模型。Agent 团队使用的 Token 约为标准会话的 7 倍，因此模型选择至关重要。

阅读更多：现在就能降低 LLM API 成本的 5 种方法

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 倍。对于兼容性要求不高的内部管道，切换格式可以使结构化输出成本减半。
  • 提示词压缩：像 LLMLingua 这样的工具可以将提示词压缩多达 20 倍，同时保持模型正确回答的能力——对于包含长检索块的 RAG 管道尤为有效。
  • 语义缓存：应用程序级别的缓存，匹配语义相似的查询（而不仅仅是精确的前缀），从而完全避免针对重复问题类型的 API 调用。

阅读深度解析：Token 高效的提示词模式：CoD、输出格式与提示词压缩

ROI 最高的 3 项改进

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

  1. 在一个会话中拟定规格，在另一个全新会话中实施。在阶段之间重置上下文可以消除陈旧历史带来的复合成本。这完全免费实施，并能立即减少后续每一轮的 Token 使用量。

  2. 用精准检索替代代码库倾倒。使用代码智能、LSP 导航和有针对性的文件读取，而不是将整个文件或目录倾倒进上下文。更少的上下文，更好的结果，更低的成本。

  3. 精简工具和 MCP 服务器，然后对剩余稳定部分依赖缓存。禁用未使用的服务器，切换到按需工具加载，并确保你剩余的工具定义对缓存友好。这攻击的是每一次请求都会向你收费的固定开销。

这三项针对的是几乎每一轮都会出现的经常性 Token 泄漏：陈旧的历史、无关的代码上下文和闲置的工具 Schema。

这些策略适用于所有供应商

虽然本指南中的示例具体引用了 Claude 和 OpenAI，但底层问题——注意力机制有限、长上下文性能下降、检索与倾倒的权衡、工具 Schema 开销——并非特定供应商独有。同样的策略适用于 Gemini、Codex 以及任何其他基于 LLM 的工具或 API。

基本原则不变：在正确的时间发送正确的上下文，衡量 Token 的去向，并优化真正的热点。

参考文献

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

来源：查看原文

上一篇
AI Agent降本实践：生产环境下的Token经济与FinOps策略
下一篇
AI 指数 - AIscending：与AI共成长
返回列表