减少大模型Token消耗的系统化方法与实践指南

在实际使用大模型时，Token 消耗通常并不只来自“问题本身”。冗长的系统提示词、重复的历史消息、未经筛选的检索结果、格式化不合理的 JSON，以及模型输出中的解释性废话，都会持续占用上下文窗口和调用预算。

因此，降低 Token 消耗不能简单理解为“少说几句话”，而应当建立一套从输入、数据、输出到调用链路的完整优化方法。下面分别展开说明。

一、先理解 Token 消耗来自哪里

一次大模型调用通常包含四类 Token：

1. 系统指令 Token
   用于规定模型的角色、行为边界、输出格式和安全要求。

2. 用户输入 Token
   即用户的问题、任务描述和附加条件。

3. 上下文 Token
   包括历史对话、检索结果、工具调用结果、业务数据和文档片段。

4. 模型输出 Token
   即模型最终生成的回答、代码、解释、表格和结构化结果。

可以用一个简单公式表示：

总Token ≈ 系统提示词 + 用户输入 + 历史上下文 + 外部数据 + 模型输出

其中，很多消耗并不是由核心任务产生的，而是由重复信息、无关信息和过度详细的输出造成的。因此，优化时应先判断问题属于哪一类：

• 输入太长；
• 上下文重复；
• 结构化数据表达效率低；
• 检索结果过多；
• 输出没有边界；
• 调用链路中存在重复请求。

只有找到主要消耗来源，优化才不会变成盲目删减。

二、精简提示词，但不要牺牲任务边界

提示词优化的目标不是尽量短，而是用最少的文字表达清晰的任务目标、约束和验收标准。

1. 删除礼貌性和重复性描述

以下内容通常不会显著提升模型理解能力：

• “请你认真思考并给出高质量答案”；
• “希望你能够尽可能详细地回答”；
• 同一条规则在多个位置重复出现；
• 对显而易见内容的长篇背景说明；
• 与当前任务无关的角色设定。

可以将其改为结构化指令：

任务：总结输入内容。
要求：
1. 输出3个关键结论；
2. 每个结论不超过50字；
3. 不补充原文未提及的事实。

相比一大段自然语言描述，这种写法更便于模型识别，也更容易维护。

2. 将规则分为“必须遵守”和“可选建议”

并非所有提示词内容都具有相同优先级。建议采用如下层次：

任务目标：……
硬性约束：
- 只能输出JSON；
- 字段必须完整；
- 不得编造数据。
输出偏好：
- 语言简洁；
- 优先使用列表；
- 避免重复结论。

这样既能保留关键约束，也能避免把大量低优先级说明写成冗长的背景材料。

3. 使用变量替代重复文本

在批量处理场景中，固定指令应与动态数据分离。例如：

固定模板：
请根据输入内容提取实体，输出字段：
name、type、confidence。
本次输入：
{{content}}

不要在每条请求中重复解释相同的字段定义、业务背景和格式要求。对于长期运行的应用，还可以将固定提示词版本化，统一维护，避免不同调用点各自复制一份。

三、严格控制模型输出，减少“罗里吧嗦”

很多 Token 浪费来自模型输出过度展开。要让模型简洁回答，必须提供可执行的输出边界，而不是只说“请简洁”。

1. 指定输出长度

可以根据任务类型设置明确限制：

回答不超过120字。
只输出结论，不解释推理过程。
最多列出5项。
每项不超过30字。

如果任务需要代码，可以进一步约束：

只返回可执行代码，不输出说明文字。
代码后最多补充3条注意事项。

2. 明确禁止无效内容

建议显式排除以下内容：

• 开场寒暄；
• 重述用户问题；
• 与结论重复的总结；
• “当然可以”“希望对你有帮助”等套话；
• 未被要求的背景科普；
• 过多的免责声明；
• 对已知条件的再次复述。

例如：

直接回答问题，不重复题目，不添加开场白和结尾客套话。
如果信息不足，只列出缺失字段，不要猜测。

3. 采用固定输出结构

固定结构能减少模型自由发挥，也便于程序解析：

请严格按照以下格式输出：
结论：不超过80字
原因：最多3点
建议：最多3点

对于机器处理场景，应要求输出严格结构化数据，并规定字段类型、枚举值和缺省行为。结构越明确，模型越不容易生成额外解释。

四、压缩结构化数据：减少重复键名

当大量 JSON 数据被直接放入提示词时，重复的键名、括号和引号会造成明显开销。例如，下面的数据每条记录都重复了字段名称：

[
  {"id":1,"name":"Alice","role":"admin"},
  {"id":2,"name":"Bob","role":"user"},
  {"id":3,"name":"Carol","role":"user"}
]

如果数据是结构一致的对象数组，可以改写为表格化表达：

users[3]{id,name,role}:
1,Alice,admin
2,Bob,user
3,Carol,user

这种表达包含了三层信息：

• users[3] 表示数据名称和记录数量；
• {id,name,role} 表示列名及其顺序；
• 后续每一行表示一条记录。

它适用于字段固定、对象结构一致的大数组，能够减少重复键名和标点。对于几百条甚至更多记录，节省效果通常比单条 JSON 更明显。

但这种方式也有适用边界：

• 字段经常缺失时，需要额外声明缺失值规则；
• 嵌套对象复杂时，表格化收益会下降；
• 字段顺序必须稳定；
• 日期、逗号、换行等特殊字符需要转义；
• 程序之间的数据交换仍应优先使用标准 JSON 或其他严格格式。

因此，建议把它作为“发送给模型前的提示层表示”，而不是替代系统内部的数据格式。

五、不要把全部历史对话都发送给模型

多轮对话是 Token 消耗的重要来源。最简单的做法是每次携带全部历史消息，但随着轮次增加，上下文会不断膨胀。

更合理的方案是采用分层上下文：

1. 保留近期对话

只保留最近若干轮，用于维持当前语境。

2. 压缩早期对话

将较早内容总结为结构化记忆：

用户目标：完成数据清洗任务
已确认条件：
- 输入格式为CSV
- 缺失值保留为空
- 输出需要包含错误记录
未解决问题：
- 是否需要去重

3. 删除已经失效的信息

如果用户后来修改了要求，旧规则不应继续保留。上下文管理需要区分：

• 当前有效约束；
• 已被覆盖的旧约束；
• 仅供参考的历史内容；
• 已经完成且不再需要的任务。

这比单纯截断消息更加可靠。

六、优化检索结果，避免“把整个文档都塞进去”

在知识库问答和文档问答中，检索结果往往是输入 Token 的主要来源。常见问题包括召回片段过多、片段之间重复，以及排序不合理。

可以采用以下策略：

1. 先召回，再重排
   初步找出候选片段，再选取与问题最相关的少量内容。

2. 去除重复片段
   对相邻段落或高度相似内容进行合并。

3. 优先保留结论性内容
   表格、定义、操作步骤和限制条件通常比大段背景描述更有价值。

4. 按问题动态设置数量
   简单问题不需要携带大量文档，复杂问题再适当扩大上下文。

5. 先摘要后回答
   对很长的资料先分段总结，再将总结结果用于最终回答。

检索系统的目标不是“找到最多内容”，而是以较少 Token 提供足以支撑答案的证据。

七、区分“减少Token”与“减少成本”

Token 优化有三个不同目标：

• 减少输入长度；
• 减少输出长度；
• 降低实际调用成本。

例如，某些调用机制可能对重复的固定前缀进行缓存或优惠处理。在这种情况下，虽然请求中仍然携带了固定提示词，但实际成本可能下降。不过，这并不意味着上下文窗口占用消失，也不代表模型处理压力完全没有变化。

因此，评估优化效果时应同时记录：

输入Token
输出Token
总Token
平均响应时间
任务准确率
失败率
实际费用

不能只观察某一个指标。过度压缩可能导致模型缺少必要信息，最终因重试次数增加而抵消节省效果。

八、建立可执行的Token治理机制

如果应用规模较大，Token 优化不能依赖个人经验，而应当纳入工程监控。

1. 记录每次调用信息

建议至少记录：

• 请求类型；
• 模型版本；
• 输入 Token；
• 输出 Token；
• 总 Token；
• 是否重试；
• 响应耗时；
• 结果是否通过校验。

2. 设置异常阈值

例如：

单次输入超过阈值：触发上下文压缩
单次输出超过阈值：终止或要求模型总结
连续重试超过次数：进入人工处理
检索片段超过数量：执行二次筛选

3. 通过样本评估质量

每次优化后，都应对代表性问题进行对比测试，观察：

• 关键信息是否丢失；
• 结构化结果是否仍可解析；
• 回答准确率是否下降；
• 是否出现更多幻觉；
• 用户是否需要重复追问。

Token 少并不等于方案好。真正有效的优化是：在保持任务质量的前提下，删除冗余输入和无效输出。

九、一套推荐的落地流程

可以按以下顺序实施：

第一步，统计当前请求的输入、输出和上下文组成，找出最大消耗项。

第二步，删除重复提示、礼貌用语和无关背景，将规则改成简洁的结构化指令。

第三步，为模型输出设置长度、条数、字段和格式限制。

第四步，对大规模同构数组采用表格化数据表示，减少重复键名。

第五步，对历史对话进行摘要，只保留当前有效信息。

第六步，优化检索结果，执行去重、重排和动态截断。

第七步，增加 Token、质量、耗时和重试率监控，持续做对照实验。

总的来说，减少大模型 Token 消耗并不是单一技巧，而是一项上下文工程。最有效的原则是：输入只保留完成任务所必需的信息，结构化数据避免重复表达，历史内容及时压缩，输出必须有明确边界，同时用监控数据验证优化是否真正有效。