📰 来源：Towards Data Science　|　📅 翻译日期：2026年7月3日
🔗 原文：查看原文
🤖 翻译：DeepSeek AI · 仅供参考

Tokenmaxxing 是席卷大型科技公司的最新生产力病毒。

工程师们正被直接或间接地以他们能消耗多少AI来衡量。更多的 token，更多的输出，更多的计算。一些公司甚至设有排行榜。

这是2026年版本以代码行数排名工程师的做法。

少即是多

Tokenminning 是 tokenmaxxing 的对立面。

随着使用量的增长，token 效率变得愈发重要。每一个不必要的 token 都会增加成本、延迟和复杂性。

Tokenminning 是一种新模式，系统性地最小化 token 使用，同时保持（甚至提升）AI 代理的性能。

在本文中，我将介绍我用来降低成本的实用 tokenminning 策略。所有这些策略都可以在不进行重大重构的情况下部署。

结果：显著降低 AI 成本，同时不牺牲质量

Tokenmaxxing 的成本

Tokenmaxxing 和其他对AI使用的幼稚方法共同假设：输入更多 token 会带来更好的输出。

这个假设导致提示词超出必要的大小，充斥着未压缩的上下文和 RAG 膨胀。在某些情况下，它可能提升性能，但也引入了一些重大问题。

1. 财务成本

不出所料，成本飙升。

发送给模型和由模型生成的每个 token 都有价格。交互式聊天的输入和输出大小合理，因此初步估算的成本似乎可控。

然而，真实代理的 token 使用违反了你可能对平均 token 使用的所有假设。使用前沿模型运行长期代理可能导致荒谬的成本。

日常使用AI的真实成本是多少？

我对自己个人使用情况（交互式聊天和我的代理）进行了快速分析。

上下文：我目前是一家生物技术初创公司的 AI 负责人。我将AI用作交互式研究助手（医学论文、癌症研究、机器学习），并开发了多个执行以下任务的代理：

• 代码分析和自动单元测试：我每天推送代码，这些代理进行漏洞分析、发现潜在问题并修复小问题
• 实验管理：跟踪和记录多个正在运行的训练实验
• Devops：管理 AWS 资源、自动化实例配置以及常规云管理协助以优化成本

以下是分解：

如你所见，我的交互式聊天与我的代理相比相形见绌。按照这些数字，使用 Claude Opus 4 我每天将在 API 使用上花费大约 $40。由于优化，我的实际花费要少得多。

一些工程师每天花费更多，尤其是使用自主工程代理时。在某些情况下，工程师报告每周花费超过 $10,000^1。

因此，大型科技公司已开始强制实施 AI 使用限制。

2. 推理速度

更多 token 也意味着更多延迟。

逻辑上，更大的提示词需要更长时间处理，增加了首次 token 时间和整体响应时间。这对于面向客户的 AI 或时间敏感的代理可能是有害的。

3. 质量

一个常见的误解是更多上下文会带来更好的结果。事实并非如此，尤其是在非常长的上下文中。

模型具有有限的注意力。随着提示词变得越来越大，重要信息与无关细节竞争模型的关注。“上下文腐烂”是一个真实问题^2，其中 LLM 随着上下文增长而变得效率降低，并且注意力效率在大上下文下奇怪地退化：它在上下文窗口的开始和结束处工作，但在中间部分退化^3。

总的来说，行业正在转变思维，更注重上下文质量而非上下文数量，以实现更有效的AI使用。

🛠️ “Tokenminning” 的实际策略

如果你尚未体验到使用 AI 的真实成本，那么上面概述的问题现在应该很明显了。

AI 工程师需要开始思考如何在实际中减少 token 使用，同时保持高性能。

以下是我用来降低 AI 成本的一些策略。这些策略在概念上简单，以避免干扰现有的 AI 工作流程。

策略 #1：路由

实际上，大多数提示词不需要前沿模型。

确实，像 Claude Opus 或 GPT 5.5 这样的模型在复杂推理、规划和困难编码任务上表现出色。

但简单的请求，如工具使用、摘要和分类，可以由更小、更低成本的模型处理。你甚至可以将它们路由到量化的本地模型，完全跳过 API 成本。

在这里，路由不是用作 token 最小化策略，而是作为一种暴力成本降低技术，效果惊人。因此，许多公司都在采用。

以下是其工作的高级概述：

• 一个轻量级的自托管 web 服务拦截每个提示请求
• 该 web 服务是轻量级的，并且符合 OpenAI Chat Completions API 或 Anthropic Messages API（取决于你的供应商）。这个 web 服务通常被称为“LLM 网关”。
• 你可以使用这个臃肿的 LiteLLM 库，或者自己构建（大约需要1天的实际工作和测试，如果使用代理编码则更少。）

• 在 web 服务中，你需要为每个提示设置以下钩子：

  1. 处理：对每个提示运行任何必要的预处理
  2. 评估：对处理后的提示运行分类
  3. 路由：基于评估，应用预定义规则选择模型
  4. 执行：使用选定模型执行 LLM 调用
  5. 验证：[可选但有用]，对输出运行验证规则
  6. 返回：格式化结果并返回给调用者

• 自己构建有一些隐藏的复杂性，确保注意流式处理。