跳到主要内容

削减你的 Token 用量(和成本)

进阶

每一个输入 token 和每一个输出 token 你都要付费。好消息是:大多数真实工作负载都背着死重 —— 臃肿的系统提示、反复重发的上下文、啰嗦的回复、用错模型去做简单活儿。把这些削掉,账单就会下降,而质量分毫不损。本页是给高阶用户的工具箱,大致按杠杆效应从大到小排列。

What you'll learn
  • Token 究竟在哪里漏掉 —— 输入 vs 输出 vs 复用的上下文
  • 精简 / “穴居人”风格:它真正能省下什么,以及在哪里会适得其反
  • 用提示缓存和批处理换来一分钱对一分钱的结构性节省
  • 为任务选对模型大小(简单任务用 Haiku),以及用结构化输出取代散文
  • 上线前用 token 计数端点先度量

第一步,找出 token 都去哪了​

在优化之前,把花费拆成三个桶 —— 每个桶都有不同的修法:

三个 token 桶
Term shown.
1 / 3

修法一一对应:缓存复用的上下文,精简输入,缩短输出,选对模型大小,把不时间敏感的工作拿去批处理。

精简 / “穴居人”风格(节省输出)​

那个爆火的招数,就是让 Claude 抛掉废话、用碎片化短句回答 —— 由开源的 caveman Claude Code 技能(MIT 许可,作者 Julius Brussee)带火,其标语是“few token do trick 时何必 use many token”。它强制使用短句、动词原形、零客套。

独立测试给出的诚实结论:这种风格在内容上零成本(代码、技术术语、JSON 保持精确),但节省幅度完全取决于你的基线。如果你的提示里已经写了“简明扼要”,那大部分收益其实早已到手。大幅削减(40–65%)出现在解释为主的回答上;结构化抽取几乎纹丝不动。

精简指令块 —— 粘贴进你的系统提示

Answer terse. Cut filler, hedging, and pleasantries.
Drop articles (a/an/the) and softeners (just, really, basically, actually).
No preamble, no restating the question, no "happy to help."
Fragments are fine. Keep technical terms and code blocks exact.
Pattern per point: [thing] [action] [reason]. Next step if any.
Pro tip
  • 把精简规则在系统提示里写一次,而不是写进每一轮用户输入 —— 重复它会让你每次调用都重新支付输入成本。
  • 永远不要压缩代码、标识符、JSON 或数字。只压缩散文。
  • “Be concise. Return JSON only.” 本身就占了可达成输出节省的约 60% —— 先把它写上,再去考虑更花哨的招数。
Watch out
  • 精简风格只削减输出。对于你每次调用都重发的 2 万 token 系统提示,它毫无作用 —— 那是输入/缓存问题。
  • 在扩展思考任务上,推理 token 不受影响;你只缩小了最终可见的回答。

缓存复用的前缀(节省输入)​

如果许多次调用共享同一大块不变内容 —— 一段长系统提示、一份工具目录、一份参考文档 —— 提示缓存会把它处理一次,然后在之后每次调用时以输入价格的一小部分复用。对于聊天和智能体工作负载,这是单项杠杆效应最高的结构性改动,因为它在每一轮都回本。

唯一一条规则:缓存的前缀在各次调用之间必须逐字节完全一致。靠近顶部的一个游离时间戳或重新排序的工具列表,会悄无声息地把你的命中率打到零。完整机制、可复制粘贴的 cache_control 代码片段,以及如何验证命中,都在提示缓存与成本优化。

Guided walkthrough1 of 3
  1. 把系统提示、工具和文档移到前面;把用户那轮会变的输入留在末尾。

精简你发送的上下文​

缓存能廉价地复用上下文,但最便宜的 token 是你从不发送的那个。审计窗口里到底有什么:

  • **裁剪系统提示。**长指令块会积攒杂物。砍掉那些不再值回 token 的示例;一个强示例胜过五个平庸的。
  • **检索,而非倾倒。**与其粘贴整篇文档,不如只取出相关段落(RAG)。为回答一个问题而发送一份 50 页的 PDF,是最常见的浪费。
  • **压实长会话。**当对话变长时,用一段简短的滚动摘要替换旧的轮次,而不是永远携带每一条消息。历史就是输入 token,你每次调用都要重新付费。
  • **为工具目录选对大小。**每个工具定义都是每次请求里的输入 token。只暴露当前任务需要的工具。

为任务选对模型大小​

别为一个 Haiku 级别的任务支付 Opus 的费率。分类、抽取、简单格式化和路由,通常在最小的模型上就跑得很好,而每 token 价格只是一小部分。把更大的模型留给真正困难的推理,并考虑路由:一个便宜模型处理简单的大多数,只把困难的个案升级上去。权衡详见选择模型和 Token、上下文与定价。

优先用结构化输出而非散文​

要求返回 JSON(或另一种紧凑的 schema)而非一段解释性文字,既削减输出 token,又免去下游的解析猜测。让 Claude 只返回一个像 {"label": ..., "score": ...} 这样的紧凑对象,生成的 token 只是啰嗦回答的零头 —— 而且你完全跳过了“结果如下:”这类开场白。详见结构化输出。

把不时间敏感的活儿拿去批处理​

对于不需要在数秒内拿到答案的离线工作 —— 评测、批量分类、数据集打标、归档摘要 —— Anthropic 的 Message Batches API 会异步运行这些请求,并对输入和输出 token 双双打 5 折,结果通常在 24 小时内返回。

把它和缓存以及选对大小的模型叠加起来,一项大型离线作业上的组合折扣会非常惊人。

度量 —— 别靠猜​

针对数字去优化,而不是凭感觉。Anthropic 的 token 计数端点会在你发送之前返回一次请求的精确输入 token 数 —— 形状与 Messages 调用相同,而且免费(有速率限制)。用它来对比一个臃肿的提示和一个精简后的提示,来做模型路由决策,并让提示保持在上下文窗口之内。

发送前先计数 token(Python SDK)

import anthropic

client = anthropic.Anthropic()

resp = client.messages.count_tokens(
  model="claude-opus-4-8",
  system="You are a scientist",
  messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(resp.input_tokens)  # exact input count, no charge for counting
Pro tip
  • 别用别的模型的分词器(例如 tiktoken)—— 不同模型家族的计数各不相同。请用 Anthropic 的端点。
  • 对于同一段文本,较新的分词器可能比旧模型多产出约 30% 的 token —— 迁移时要重新计数,别复用旧的估算。
  • 从响应的 usage 中读取 input_tokens、cache_read_input_tokens 和 output_tokens,以确认节省在生产环境中真正落地。

计数规则与成本估算公式参见 Token、上下文与定价。

一个端到端的前后对比​

一个工单分流助手,在每一张工单上都跑同样的 4,000 token 系统提示 + 工具目录,并写出一段啰嗦的 600 token 回复。

Guided walkthrough1 of 4
  1. 每次调用都按全价重发约 4,000 个输入 token + 约 600 个啰嗦的输出 token,跑在一个大模型上。什么都没缓存、同步、散文式回复。

每一根杠杆都是乘性的:缓存输入 × 更小的模型 × 更精简的输出 × 批处理折扣,复合成一个巨大的总削减 —— 而在这个简单任务上,回答质量毫无变化。用 count_tokens 度量每一步,这样你就能证明这份收益,而不是假设它。

自我检测

0/4
  1. “穴居人” / 精简风格主要减少哪种 token?
  2. 你每次调用都重发同一段 1 万 token 的系统提示。最佳修法?
  3. 哪种工作负载最适合 Message Batches API 的 5 折优惠?
  4. 你该如何验证一次提示改动真的省下了 token?
Key takeaways
  • 把花费拆成输入、输出和复用的上下文 —— 每个桶都有不同的修法。
  • 精简 / “穴居人”风格只削减输出;在散文上收益大,在本就简洁的结构化任务上收益小。
  • 缓存稳定前缀(逐字节完全一致),换来每次调用一分钱对一分钱的输入节省。
  • 裁剪上下文、为任务选对模型大小、优先 JSON 而非散文 —— 便宜且可复合的收益。
  • 把不紧急的工作拿去批处理享受 5 折,并始终用 count_tokens 度量而不是靠猜。

来源与延伸阅读​

下一步​