你从什么时候开始注意到 token 不再是“用完了再充就行”的东西了有人是因为账单有人是因为连续报错有人是因为一次 80 页文档丢给模型后页面转了十几秒才出结果。我印象深的是一个团队做内部知识库问答明明只是问某个字段含义prompt 里却每次都带着整份产品手册。他们看到单日调用成本后第一反应不是换模型而是把那段拼 prompt 的代码从头读了一遍。这就是过去一年非常典型的使用方式有些人甚至给它起了个名字Tokenmaxxing。把输入尽量塞满把历史尽量带全把输出尽量拉长仿佛模型消耗的 token 越多任务完成得就越有保障。这个思路在 demo 阶段确实有效它让很多原型快速跑通。但进入生产后它正在被成本、延迟、限流和稳定性反噬。一个更务实、更抠门的阶段已经来了token 预算管理。1. 先搞清楚一件事tokenmaxxing 是怎么流行起来的1.1 “多塞点信息模型就能更聪明”是这一代 AI 工程里最贵的错觉先从底层说起。LLM 的输入不是直接读“汉字”而是经过 tokenizer 切成 token。一段中文文本可能对应几千到上万个 token英文单词会拆成子词不同模型厂商的 tokenizer 也不一样。大模型按 token 计费这不是“字数”的简单换算而是“模型处理的基本计量单位”的累计。也就是说如果你的代码里不小心多做一次 prompt 拼接、多带几轮历史那么多出来的费用并不是幻觉是真实发生的。为什么会有人忍不住多塞因为人的直觉是“信息越多模型知道得越多回答越准”。在模型能力不够强的年代这个直觉确实能提高一点成功率。但当模型的理解能力已经足够强时继续无节制地投喂信息边际收益会迅速下降边际成本却持续上升。最典型的例子就是长文档问答把 500 页 PDF 全部塞进上下文不如先做检索只把相关章节丢给模型。还有一点很多人没意识到上下文窗口的大不意味着你可以毫无代价地占用。输入会按 token 计费输出也会按 token 计费而且上下文越长单次调用的延迟越高并行能力也会被占用。上下文窗口更像是一个“最大可用范围”而不是“推荐填满的状态”。在探索期多塞一点能掩盖 prompt 设计粗糙、检索不到位的毛病在生产期这些毛病会变成一笔一笔真实账单最终逼着你回来重新设计流程。1.2 credits、token、上下文窗口先分清几个容易混的概念很多平台在账户体系里用的是“credits”或“积分”在模型调用明细里用的是“token”。两者的关系通常是模型调用按 token 计量然后按模型等级的单价换算成 credits 扣除。不同模型即使是同一个 token 数量扣除的 credits 也可能差很多。这也是为什么不能只看 token 总量还要看用的是哪个模型。把这三个概念分开理解你就知道做成本估算时必须同时考虑三件事单次请求 token 数、模型单价、请求频率。有人一天消耗 50 万 token但大多数请求都在便宜模型上成本可能还不如别人 5 万 token 的复杂推理请求高。所以讨论 token 消耗一定要绑定模型等级和业务场景否则就是一个没有意义的总数。从行业趋势看token 的计量计费也在从各家自定义走向规范化。你会在一些技术标准和规范草案里看到关于 token 计量计费管理能力的讨论这说明 token 消耗已经从开发者的口头概念逐渐变成系统治理的一部分。这背后的信号很清楚围绕 token 的成本和运维问题不是靠感觉就能解决的。1.3 tokenmaxxing 的本质用资源换时间但没算可持续性Tokenmaxxing 为什么流行本质上是人想省去思考。与其花时间设计 prompt、做检索、写缓存不如把资料一次性全丢给模型让模型自己找答案。这在原型阶段是合理的因为它省的是工程师的时间贵一点也划算。可一旦应用要长期运行账就算不过来了工程师的一次性省事变成了服务器上每天的持续支出。从工程角度看这有点像早期用暴力解法处理数据先排序再二分查找和直接把整个数组从头扫到尾在小数据集上没有区别但数据量上去之后算法复杂度会决定生死。token 消耗也一样。单次调用看不出问题乘以每日请求量之后差距会非常直观。2. 为什么“token 越多越好”在工程里必死2.1 成本失控是一次次小默认值累积出来的很多团队并不是故意浪费 token而是死在默认值上。比如对话场景没有清理历史消息多轮之后每次请求都要带上过去几十轮对话比如 RAG 查询时一次性召回 20 个片段不管相关不相关比如 prompt 里放了三段示例但其中两段跟当前请求完全无关。单个请求看上去只多花了几毛钱但一天几千次调用后账单数字就会让人坐不住。我见过更隐蔽的一种浪费模型输出超出预期长度后端直接截断但截断只发生在展示层费用照收。又或者一次任务中多个步骤反复调用模型每步都带上完整上下文中间没有任何清洗和压缩。这些都是典型的“tokenmaxxing 后遗症”——只要不按 token 维度去复盘你根本不知道钱花在哪了。2.2 上下文越长任务质量不一定越高一个被很多人忽略的事实是上下文越长模型的注意力越容易被无关内容稀释。这不是说模型没有长文本能力而是说任务执行过程中无关信息会干扰判断。你给模型一段 10 万 token 的资料让它回答一个只涉及其中一句话的问题它反而可能因为句号后面紧跟的大量噪音而给出更不确定的答案。从实际测试看把问题所需要的背景信息精确控制在一个合理范围内比无脑堆材料更容易获得稳定结果。精炼输入不是损失信息而是主动过滤噪音让模型把注意力放在真正重要的内容上。这也是为什么 prompt 工程里会反复强调“少即是多”。2.3 不可复盘的消耗是最大的隐性浪费tokenmaxxing 真正致命的地方在于不可复盘。如果一个系统没有记录每次调用的 token 用量没有按模型、按业务入口、按用户维度拆分那么任何优化建议都无法落地。你只能看到月底的总账单却说不清是哪一次重构、哪一个功能、哪一类用户把它推高的。现代软件工程的基础是“可观测”。LLM 应用也一样。只有当 token 消耗像 CPU、内存一样成为可监控的指标你才有资格谈论优化。否则每一次“猜一猜哪段 prompt 太长了”都是浪费新的 token 在调试上。token 无节制消耗不只是成本问题更会演变成质量问题和工程管理问题。它绕过了系统设计阶段该做的所有决策最后让使用者承担后果。3. 勒紧裤腰带先收紧输入3.1 先从“信息需求”出发而不是从“文档路径”出发做输入治理的第一步非常简单写代码之前先问模型要完成的这个任务真正需要哪些字段、哪些片段、哪些上下文举个例子。一个功能是“从用户提交的 bug 报告里提取优先级”。如果直接把整份报错日志、几十轮聊天记录全部塞给模型它当然也能处理但你会为大量无关文本付费。更合理的做法是程序先解析出问题描述、复现步骤、错误码、环境信息然后把这些结构化字段组合成精简 prompt。这样无论原始数据多长模型每次看到的都是同一个可控结构。这个步骤的好处是在源头就堵住了 token 膨胀。它不是模型技巧而是传统的数据处理和接口设计功底先明确输入 schema再把数据加工到 schema 需要的程度。3.2 RAG 是检索不是把资料库搬进 promptRAG 是当前控制 token 的最主流办法但很多人把它用成了“伪 RAG”检索完之后把召回到的 8 个、10 个片段全部拼进 prompt。片段一长上下文照样爆炸。真正的 RAG 要控制两个量召回片段的数量和每个片段的长度。比如先从向量库召回 top 5然后按字符或 token 截断到固定上限如果检索结果和问题相关性不高宁可返回“知识库中没有足够信息”也不要强行拼接无用材料误导模型。更精细一点的做法是让模型在回答前先判断检索内容是否覆盖了问题不覆盖就结束不再浪费第二轮调用。还有一点细节分块大小决定了 RAG 的检索质量也决定了 prompt 的膨胀程度。分块太大一条片段里大半是无关内容分块太小关键信息被切碎召回后需要更多片段才能拼完整。工程上一般从 200 到 500 token 的分块开始测试再根据实际召回效果调整。不同领域的文本结构差异很大这个参数要基于自己的数据实验不要照抄别人的值。3.3 对话历史不是所有消息都值得再次进入上下文对话类应用是 token 消耗大户因为历史消息会随轮数线性增长。最简单的做法是只保留最近 N 轮更早的消息要么丢弃要么压缩成摘要。比如设定规则最近 5 轮原文保留5 轮之前的消息交给一个小模型生成摘要下次请求时带上摘要加最近 5 轮。这样既能维持对话连续性又避免了上下文无限增长。更复杂的方案是根据