隐藏的 Token 税：系统开销如何悄无声息地耗尽你的 LLM 上下文窗口

大多数团队知道他们的用户发送了多少 token。但几乎没有人知道在用户开口说话之前，他们已经支出了多少 token。

在典型的生产级 LLM 流水线中，系统提示词 (system prompts)、工具架构 (tool schemas)、聊天历史、安全前导词和 RAG 序言在实际用户查询到达之前，就默默消耗了上下文窗口的 30–60%。对于拥有数十个注册工具的智能体 (agentic) 系统，这种开销在 128k 窗口中可能达到 45% —— 约 55,000 个 token —— 而这些工具定义甚至从未被调用过。

这就是隐藏的 token 税。它虚增了成本、增加了延迟并降低了输出质量 —— 然而，它从未出现在任何面向用户的指标中。

被征税请求的剖析

想想当用户发送“我今天有什么会议？”时会发生什么。以下是随这个 8 token 查询一同发送的内容：

• 系统提示词 (行为规则、角色、护栏): 1,500–3,000 个 token
• 工具/函数定义 (名称、描述、参数架构): 5,000–55,000 个 token
• 聊天历史 (对话上下文的前几轮): 2,000–10,000 个 token
• RAG 上下文 (检索到的文档或知识库分块): 1,000–5,000 个 token
• 安全前导词和输出格式指令: 500–1,000 个 token
• 实际用户消息: 8 个 token

对于一个 8 token 的问题，开销超过了 10,000 个 token —— 如果有庞大的工具注册表，很容易超过 60,000 个。每一个 token 都按照输入费率计费，并竞争模型有限的注意力预算。

多轮对话使问题更加严重。一个 20 轮的对话会积累 5,000–10,000 个 token 的历史记录，但通常只有最后几轮才重要。你在每一次调用中都要为所有这些内容付费 —— 这是一种随对话长度线性增长且永远不会自动缩减的税收。

工具架构：最大的隐形罪魁祸首

工具定义是隐藏开销的最大来源。每个定义都承载着令人惊讶的成本：

• 工具名称: 5–10 个 token
• 描述: 50–150 个 token
• 参数架构 (类型、必填字段): 100–300 个 token
• 字段描述和约束: 50–200 个 token
• 用于可靠调用的 few-shot 示例: 200–500 个 token

每个工具总计 550–1,400 个 token。大多数团队从未察觉，因为他们的框架会自动注入这些定义 —— 税收隐藏在抽象层之后。

来自连接到 MCP 服务器的智能体的真实测量揭示了问题的规模：

• GitHub (35 个工具): 约 26,000 个 token
• Slack (11 个工具): 约 21,000 个 token
• 可观测性工具: 约 8,000 个 token

在开发者输入单个字符之前，128k 上下文窗口的 45% 就已经消失了。无论是否调用了工具，每个 token 都会计费 —— 一个简单的“总结这份文档”请求仍然需要支付全额税费。

选择准确度也会随着注册表的增长而下降：

• 5–10 个工具：超过 90% 的选择准确率
• 50+ 个工具：下降到 49% 左右 —— 相当于抛硬币

token 越多，结果越差。

税收在链式调用中成倍增长

token 税不是相加的，而是相乘的。一个链接了三次 LLM 调用的智能体工作流 —— 意图分类、数据库查询、响应格式化 —— 如果每次调用都带有 20,000 个 token 的开销，那么为了一个 200 token 的答案，就消耗了 60,000 个 token 的结构性成本。这相当于 300:1 的开销价值比。

智能体循环的影响更为严重。一个执行 10 个步骤的智能体，每一步都带有完整的系统提示词和工具定义，仅在开销上就消耗了 200,000–500,000 个 token。按照每百万输入 token $3 的价格计算，每个任务仅税收就要花费$0.60–$1.50 —— 这还没算上执行有用工作的 token。

在企业级规模上，这些数字变得不容忽视。一个每天处理 10,000 张工单、拥有 40 个注册工具且平均对话次数为 5 轮的客户支持系统，其成本可能从每天约 20 亿个 token（每年 219 万美元）摆动到每天约 7,000 万个 token（每年 7.7 万美元）。仅结构性开销就带来了 30 倍的成本差异。

审计你的 Token 预算

在优化之前，你需要可见性。大多数团队只有在实施细粒度跟踪后才会发现他们的 token 浪费。以下是审计你的流水线的方法：

• 测量你的开销比例。 对于每一次 API 调用，计算结构性开销占输入 token 的百分比。如果开销持续超过 50%，你就有巨大的优化空间。
• 按组件分析。 将 token 消耗分解为系统提示词、工具定义、聊天历史、RAG 上下文和用户内容。在大多数系统中，工具架构和聊天历史是前两个罪魁祸首。
• 跨流水线跟踪。 如果你链接了多个 LLM 调用，请测量端到端消耗的总 token。一个在孤立状态下看起来高效的调用，在 10 个步骤的智能体循环中成倍增加时，可能是毁灭性的。
• 监控输出 token 浪费。 输出 token 的成本通常是输入 token 的 4–5 倍。如果你的模型在 100 个 token 就足够的情况下生成了 500 个 token 的响应，那么对于这种更昂贵的 token 类型，这就是 5 倍的乘数。

削减代币税的六大策略

既然你已经了解了 token 的去向，以下是按影响程度排序的高杠杆优化建议。

1. 动态工具选择。 不要在每次调用时注册所有工具，而是仅选择与当前查询相关的工具。轻量级分类器或基于嵌入（embedding）的过滤器可以挑选出最可能需要的 3–5 个工具，并且只在请求中包含这些定义。仅此一项就能减少 85% 与工具相关的开销，同时提高准确度 —— 在将 50 多个工具过滤到 5 个时，选择准确度会从 49% 提升到 74%。

2. 提示词压缩。 彻底审计你的系统提示词（system prompt）。大多数提示词都是有机增长的 —— 每一个边缘情况和错误修复都会增加一段内容。原本 3,000 token 的系统提示词通常可以在不损失行为忠实度的情况下压缩到 1,000 token。删除冗长的示例，合并冗余的限制条件，并使用简洁的指令语法。

3. 对话历史管理。 不要附加完整的聊天历史，而是实现滑动窗口或基于总结（summary-based）的压缩。将较旧的对话轮次总结为一个紧凑的上下文块，并仅逐字保留最近的 2–3 轮。一个消耗 10,000 token 的 20 轮对话可以降低到 1,500 token，且质量影响微乎其微。

4. 提示词缓存。 现在大多数 LLM 提供商都支持提示词缓存 —— 存储并重复使用静态提示词前缀的计算表示。由于你的系统提示词和工具定义在不同调用中是完全相同的，缓存可以避免在每次请求时重新处理它们。这虽然不会减少 token 计数，但对于缓存部分，它可以降低高达 85% 的延迟和高达 90% 的成本。

5. 语义缓存。 对于具有重复查询的高流量系统，可以根据语义相似度对 LLM 响应进行缓存。如果 “今天天气如何？” 和 “现在天气怎么样？” 产生相同的答案，则直接返回缓存版本，而不是再次进行 API 调用。在高重复的工作负载中，节省额度可达 73%。

6. 模型路由。 并非每次调用都需要最昂贵的模型。将简单的分类、提取或格式化任务路由到更小、更便宜的模型，并将前沿模型（frontier models）留给复杂的推理任务。

为什么 “代币税” 损害的不只是成本，还有质量

代币税不仅昂贵，它还会主动降低输出质量。

LLM 通过注意力机制处理上下文，其中每个 token 都会关注其他所有 token。随着上下文的增加，模型的注意力会被分散。研究一致表明，模型从上下文的开头和结尾提取信息的效果最好，而对于埋在中间的信息，准确率会下降 30% 以上。

当 55,000 token 的工具定义堆在系统提示词和用户的实际问题之间时，你实际上是将用户的内容推向了低注意力区域。模型在用户最关心的内容（用户的请求）上投入的注意力更少，因为它把注意力预算花在了用户根本没有要求的服务的工具 schema 上。

动态工具选择不仅是成本优化，更是质量优化。更少无关的 token 意味着有更多的注意力分配给真正重要的 token。

构建具备 token 意识的架构

最有效的长期解决方案不是优化单个调用，而是在设计架构时将 token 经济学作为首要考虑因素。

将 token 视为一种受管资源。 跟踪每个请求、每个用户、每个功能的消耗情况。像设置数据库查询或 API 速率限制一样设置预算和告警。实施粒度化跟踪的团队通常会发现，20%–50% 的支出几乎没有产生任何业务价值。

为最小上下文而设计。 上下文窗口中的每一条信息都应实至名归。在包含任何内容之前，请自问：

• 这段系统提示词真的改变了模型的行为吗？
• 这个工具定义的使用率是否超过了 1%？
• 这一轮对话历史对当前查询是否重要？

如果答案是 “否”，那就是代币税。

对提示词进行版本管理和测试。 系统提示词应该是具有可衡量性能特征的版本化产物，而不是无限增长的维基页面。当你为了处理某种边缘情况而增加一段话时，请衡量它是否真的改变了结果。如果没有，请删除它 —— 它是纯粹的开销。

从一个端点开始

隐藏的代币税永远不会导致显式的停机故障。你的系统仍然在运行 —— 只是比应有的速度更慢、更贵、准确度略低。在生产规模下，数百万次请求中累积的 “略逊一筹” 就是可持续的 AI 产品与悄悄亏损的产品之间的区别。

选择你流量最高的端点，衡量其开销比例。那个数字会让你感到惊讶 —— 而这种惊讶正是开始削减开销的最佳动力。