隐藏的 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。

加载中…