如何降低大模型 token 的消耗？

连续向ChatGPT提问多次，其背后的算力与资源损耗相当于白白消耗数百毫升水资源。更关键的是，当前主流大模型经过RLHF对齐后，普遍养成了“端水大师”式的客服思维，回答冗长且充满客套话，导致token浪费严重。

无论询问什么，模型都会以“好的，我来为您解答”开头，中间列出“首先、其次、最后”，结尾加上“希望这个回答对您有帮助，如果您还有其他问题...”。

这种看似废话文学的回答，从token计费角度看，如同不断漏水的水龙头，消耗的都是真金白银。

针对这一问题，网上已有不少用户提出了处理办法：

例如：

能用本地模型，就不用云端模型：对一些基础任务（比如录音转写），可以优先用本地模型处理，既能控制成本，也更利于保密。

确定的用脚本，不确定的用模型：重复性、流程明确的工作，尽量做成脚本或可复用的工具；真正需要探索、判断和生成的环节，再调用大模型。

用便宜模型给复杂项目写索引：在复杂项目里，先让成本较低的模型帮忙建立索引、整理结构，让更贵的模型能更高效地调用信息，避免在低效搜索上浪费Token。

也有人提到，英文通常比中文更省Token，这倒不失为一个机智的节省思路。

言归正传，让大模型“好好说话”还可以尝试以下方法：

先是大多数人用的多的日常对话，要解决的就是大模型的啰嗦病。

很多人认为让模型简短只需加一句“请简短回答”，但事实并非如此。模型只会回复：“好的，我会尽量简短回答：...”

对付这种讨好型人格，Prompt必须冷酷、具体且带有强制性。

1.设定“极简/无情”的人设。在对话开头或System Prompt中，直接剥夺模型的“客服属性”。

2.限制输出格式，这是最有效的一招。大模型在自由发挥时最容易啰嗦，将其框死在特定格式中，它就没空说废话。

写代码时：“只输出代码本身。禁止使用 Markdown 代码块标记，禁止任何解释和注释。”

提取信息时：“严格以 JSON 格式返回结果，不要包含任何 JSON 之外的文本，不要说‘这是您的JSON’。”

做选择题时：“只输出选项字母（如 A/B/C），不要输出选项内容，不要解释原因。”

3.用Few-shot（给例子）教它做人。大模型是模仿大师，光说“精简”没用，直接给它看两个一问一答、极其干练的例子，它就能学会。

然后是API调用党：

如果你是开发者，在代码里调用API，仅靠Prompt约束不够，必须采用工程手段。

1.用好stop（停止词）参数。这是节省token的好方法，尤其当只需模型输出一个词或一句话时。在API中设置stop序列，例如提取人名时设置stop=["", "."]，模型输出人名后碰到换行符或句号即停止生成，避免后续废话。

2.调高惩罚参数。将frequency_penalty和presence_penalty调高至0.2到0.5之间，可迫使模型减少重复词汇，使内容更紧凑。

3.max_tokens兜底。限制最大输出token数众所周知，但治标不治本。设得太小会导致输出残缺，需要重新调整，更费钱。因此只作为防失控的兜底，不能作为主要节省手段。

高阶玩法：架构与系统级“抠门”

如果做的是AI产品，每天成千上万次调用，必须从系统架构上节省成本。

1.给上下文“瘦身”。多轮对话是token消耗重灾区，很多新手将前20轮记录全塞进prompt，导致token爆炸。

做法：设定阈值（如超过5轮），让模型对前面对话做极简摘要，只保留“摘要+最近2轮对话”作为新上下文。

2.杀鸡别用牛刀。并非所有问题都需要最贵、最聪明的模型。

做法：在请求最前面加一个极便宜的意图识别小模型，将简单任务路由给便宜模型，复杂任务路由给昂贵模型，可省下70%以上token费用。

3.语义缓存。用户问题常有大量重复，例如重置密码和忘记密码。

做法：引入向量数据库做语义缓存，将问题向量化，相似度超过95%时直接返回缓存答案，避免调用大模型，可节省大量token。

总之，节省token虽能降低成本，但切忌过度压缩Prompt导致内容失真。否则，后续的重新生成与纠错反而会消耗更多token，得不偿失。