搞AI的人，不管你是天天泡在聊天页面里，还是自己在后端接大模型API，对 token 这个词都不会陌生。我最近被问得最多的问题之一，就是“为什么 token 消耗得这么快”“明明没聊几句，费用却涨得吓人”。这篇内容就是专门来回答这个问题的：从token计费的底层逻辑、最容易被忽视的隐性消耗点，到不花钱的优化方案、工具层面的压缩手段，再到我实际跑项目时的成本记录表。适合正在做AI客服、文档问答、自动化工具等开发的读者，也适合只是平时重度使用大模型、想省点费用的普通用户。坦白说，token消耗过快这个问题，绝大多数时候不是模型“太蠢”，而是使用方式出了问题。只要理解了它的计费规则，再把上下文管理和任务拆分的几个习惯改了，大多数人能把token消耗降低50%以上。下面我把整个思路和实操记录都写出来。1. 为什么你的token总是不够用：消耗过快的核心原因1.1 搞清楚token计费的底层逻辑先统一一下基本概念。模型在读取和生成文本时，并不是一个字一个字地处理，而是把文本切成固定大小的“小块”，这些小块就是token。不同模型的分词器不一样，中文通常一个汉字可能占1到1.5个token左右，英文一个常见单词大约占1个token，标点符号、空格、换行符也都可能按token计算。计费的核心公式是：单次请求费用 = 输入token数 × 输入单价 + 输出token数 × 输出单价。很多人只看“输出”，因为那是模型现场写出来的，肉眼可见。但实际上，输入token往往才是真正的消耗大头。你每次发出去的问题、附带的系统提示词、聊天历史、粘贴进去的文档，通通都算输入token。如果这个输入非常大，那即使模型只回答了一个“好”字，这次调用的成本也已经定下来了。我习惯用一个小例子说明问题。假设你的单次请求里，系统提示词写了300个字，历史对话累积了4000个字，这次用户的问题又占80个字，那么输入token轻轻松松超过5000。模型输出哪怕只有200字，跟输入一比完全是小头。所以排查token消耗过快的第一个方向，就是看看自己的输入侧到底塞了多东西。1.2 三个容易被忽略的隐性消耗点我接触过的项目里，至少90%的token浪费都逃不过这三点。第一点是系统提示词过于臃肿。很多人在做项目时，会把“你是一个资深的某某顾问，拥有十年以上经验，擅长……，请用专业、详尽、条理清晰的风格回答，同时注意……”这种两百字以上的设定放在系统提示词里。听起来很合理，但是请注意：这段提示词在每一次请求中都会被完整计入输入token。就算用户只问了一句“报价是多少”，系统提示词照样全部跑一遍。一次两次无所谓，调用量一大，浪费就变成真金白银。第二点是被忽视的多轮对话历史。这是普通用户踩得最重、开发者也常犯的问题。大模型本身是无记忆的，为了看起来有记忆，产品会把你和它的整个聊天记录，在当前这轮请求里重新发给模型。假设每轮问答平均消耗600个token，聊到第10轮时，你发出第11个问题，系统会把前10轮大约6000个token的历史全带上，再加上新问题，一次请求就逼近7000个token。如果你早就忘了第一轮聊过什么，这些历史就是纯粹的负担。第三点是直接把长文档和日志整段粘贴进上下文。上传资料、粘贴说明书、把一整个代码文件扔给模型，这些操作确实方便，但代价也很大。比如一份产品手册可能有一万多个token，而你真正想问的只是“退货流程”这一小节。结果就是除了那一小段，剩下九千多个token全成了“背景噪声”，你为它们付了费，模型还得花力气忽略它们。这三个点综合起来，就解释了为什么你会觉得“没聊几次就没额度了”。不是模型太能吃，而是每次请求的输入都被强行灌了大量重复内容。2. 不花一分钱的优化方案：从根本上减少token消耗2.1 精简系统提示词与固定模板先说最立竿见影的一步：给系统提示词瘦身。做项目的时候，系统提示词该有的作用一定要保留，但表达方式可以从“长篇大论”改成“清单式关键字”。我之前见过一份膨胀版的提示词，大概是这样的：你现在是一个拥有十年以上行业经验的资深顾问，特别擅长用户需求分析和问题解决。在回答问题时，请务必条理清晰，分点作答，注意考虑用户的背景和真实需求，同时给出可执行的建议，注意语气友好专业，让用户感到被尊重。这段内容看似专业，其实对模型能力的提升非常有限。精简之后可以是这样：你是行业顾问。回答要求：结论先行，不超过300字；使用列表说明依据；语气直接，不客套。两者信息量差不多，但token消耗能少一半以上。我的判断原则是：一条提示词如果去掉之后不影响任务完成度，那就果断去掉；如果只影响“语气风格”而不影响“内容正确性”，也尽量压缩成几个关键词。固定模板可以继续用，但模板本身也要控制体积。比如你做一个客服机器人，模板里只需要写明品牌名、处理规则、禁止事项，其余什么“热情”“专业”的形容词都可以浓缩成“语气友好”四个字。建议每隔一段时间把模板打出来数一遍字数，超过200字就重新精简一次。2.2 主动管理上下文窗口单次请求的input token，等于“系统提示词 + 本次问题 + 历史对话”。在系统提示词已经精简的情况下，历史对话就是最需要管理的对象。最朴素的方案是“聊天截断”：定期把之前的对话清掉，只保留最近几轮。这个方法简单粗暴，但很有效。我自己的习惯是：在做普通问答型应用时，只保留最近3轮历史；在做任务型应用时，有时候一轮历史都不保留，直接把必要的信息放进变量里。比单纯截断更进一步的是“历史摘要压缩法”。具体操作步骤是：当对话进行到5到8轮，或者明显感觉模型开始忽略早期内容时，发一条指令让它把当前对话压缩成一份简短摘要，然后把摘要复制到新会话中继续。摘要内容不需要保留每个字，只需要记录关键事实、未解决的问题和已经确定的结论。实际操作时，我会用一段类似这样的指令：请把当前对话压缩成一份200字以内的摘要，保留：已经明确的信息、尚未解决的问题、下一步计划。只输出摘要本身。这个动作的回报非常可观。原来你可能带着5000个token的历史继续聊，压缩后历史只剩200个token，输入开销直接小了一个数量级。代价只是每次压缩时花几十个token生成摘要，这笔账怎么算都划算。2.3 任务拆分与单轮聚焦第三个不花钱的办法，是改变你向模型提问的方式。我见过很多人喜欢一口气问一堆问题，比如“帮我分析这份报告的整体趋势、主要问题、竞争对手情况、下季度建议和风险提示”。模型听完了，出于尽责，会老老实实把每个点都展开说，输出轻松超过1500个token。但很多用户真正关心的只是其中一个点，剩下几段全是陪跑。我倾向于把这种大而全的问题拆成几次调用。先问“整体趋势如何”，拿到结论后，再在新会话里问“主要风险有哪些”。虽然请求次数变多了，但每次请求的输入短、输出短，总token反而更低，而且答案质量往往也更好。原因是模型不用把注意力分散到六个方向上，上下文里全是与当前问题相关的内容，生成时更聚焦，废话更少。单轮聚焦的意思是：一个会话只解决一个问题，不要让一个会话同时承担“问答、写作、分析、翻译”多个职能。模型没有真正的多任务处理能力，它只是把所有上下文混在一起推理。会话目的越单一，需要的上下文就越短，token消耗自然越少。3. 用工具和技术手段压缩token：实操方案3.1 使用结构化输出与低token偏好设置如果你的项目是直接调用API，那么几个基础参数是必须会调的。在这里先说清楚一个关键点：很多新手以为设置max_tokens就能控制整次请求的费用，这是不对的。max_tokens限制的是模型最多能输出的token数量，跟输入token没有半毛钱关系。你哪怕把max_tokens设成1，输入侧该是多少还是多少。所以它只能帮你管住输出，管不住输入。输出侧仍然值得优化。比如在系统提示词里写明“只输出JSON，字段为name, result, reason”，模型就不会给你写一大段解释。比如要求“直接给结论，不需要步骤说明，不需要礼貌用语”，模型就不会在结尾补一句“希望以上回答能帮助您”。这些冗余输出在长对话场景里累积起来不可小觑，可能占整体输出token的20%以上。temperature参数也值得注意。它控制的是模型的发散程度，调得太高，比如1.0以上，模型就容易多说废话、重复说车轱辘话。用于问答、摘要、信息抽取等任务时，我通常把它设置在0到0.3之间。只有做头脑风暴、写创意文案时才会调高到0.7以上。温度调低一点，输出会明显更紧凑，token自然更少。3.2 文本预处理与分段处理长文本处理是token消耗的重灾区。我见过一些项目，为了写一个报告摘要，把整个几十页的PDF全文塞给模型，然后要求它“总结全文”。这个问题不只是贵，还在于模型对超长上下文的中间位置内容容易遗忘或混淆，输出质量反而不如只喂关键章节。正确的做法是先分段，再定位，最后只把相关部分发给模型。比如你有一份产品手册，用户想问“退货流程”。全文可能有2万个token，直接全传太浪费。你应该先在本地把手册按章节切成若干段落，把段落标题或者首句组织成一个简单的索引，然后让一个成本更低的模型或直接靠关键词匹配定位到“售后政策”章节，最后只把那一段文本发给主力模型回答问题。我把它叫做“小模型做粗筛，大模型做精答”。这种组合拳不但省钱，而且速度更快。因为定位任务对模型推理能力要求不高，用小模型或者简单的文本检索就够用了，而生成最终答案的任务再用大模型。批量处理文档时，这个策略能把总token消耗降一个数量级。做完文本预处理后，代码结构大致长这样：先读文件、分块，再根据查询条件筛选出候选块，最后把候选块和问题拼接成新的prompt。注意，不要在一开始就把全部文本拼进prompt，否则就失去了分段处理的意义。3.3 长文档总结与检索增强的组合玩法如果你需要频繁对一个知识库提问，比如企业知识库、产品文档集，那一定要用检索增强的方式。它的核心思想特别朴素：不要每次都把整本参考资料背给模型听，而是先从资料里检索出与当前问题最相关的几段，只把这几段塞进上下文。我把这个过程用类比说明一下。平时我们看书，不会把整本书抄进笔记再回答一个问题，而是会先翻目录，找到相关章节，再精读那几页。检索增强就是这个“翻目录精读”的动作。对模型来说，上下文越短，越容易聚焦，答案也越准确。具体步骤一般是这样：把文档按固定长度切成块，比如每块500个字符，注意块与块之间保留少量重叠，避免截断重要内容。对每个块做向量化，存进一个本地索引。这个步骤只需要执行一次，目的是让机器知道“哪块内容大概在说什么”。用户提问时，先把问题向量化，然后从索引里取最相近的3到5个块。把这几个块拼接成上下文，连同原问题一起发给模型。伪代码示意如下：from your_embedding_tool import embed from your_vector_store import VectorStore full_text = load_text("product_manual.txt") chunks = split_text(full_text, chunk_size=500, overlap=50) store = VectorStore(embedding_fn=embed) store.index(chunks) query = "退货流程需要哪些材料" context_blocks = store.search(query, top_k=3) context_text = "\n".join(context_blocks) prompt = f"根据以下资料回答问题：\n{context_text}\n\n问题：{query}" result = call_llm(prompt, max_tokens=400)这个方法对token的压缩效果非常惊人。假设原始文档有2万个token，你每次只取3个块共1500个token，输入侧直接减少了92%以上。加上向量化和检索本身可能产生的少量计算成本，整体仍然比全量传入便宜太多。唯一需要注意的是切块策略：块太小会丢失上下文，块太大又起不到压缩作用，500到800个字符之间是一个比较稳妥的区间。4. 常见问题与排查技巧实录4.1 为什么同样的对话，不同模型消耗不一样经常有朋友跟我说，同样的对话换个模型，token数量就变了。这不是幻觉，主要有三个原因。第一，不同模型分词器不同。同一个句子里，中文分出来的token颗粒度可能差别很大。有的模型对中文比较友好，一个汉字可能只算1个token，有的模型可能一个常用词就占2到3个token。第二，很多服务会在系统提示词之外，偷偷加上一些固定标记，比如对话分隔符、角色标记、参数设置里的默认prompt。这些隐藏token也会计入总量。第三，部分服务会做前缀缓存，同一个前缀重复使用时计费方式不同，有的便宜，有的几乎没差别。排查异常消耗时，第一件事是看接口返回里的usage字段。它通常会包含输入token数、输出token数，有的还会给出缓存命中情况。我每次排查成本问题，绝不会只看总费用，而是先看：是输入涨了还是输出涨了？如果是输入涨了，就去检查系统提示词、历史对话和文档内嵌；如果是输出涨了，就去看max_tokens和temperature设置。不看数据就猜原因，等于闭着眼睛修代码。4.2 上下文越聊越贵的处理办法用户最常见的抱怨其实发生在这类场景里：在同一个聊天窗口里连续问了一个小时，中间夹杂着大量“好的”“明白了”“这个再解释一下”之类的互动，最后突然问“把最开始那个方案再说一遍”。此时系统为了让他“看得到上下文”，会把他这一个小时聊的所有内容重新发给模型，可能已经积累了两三万token。模型看到这么多内容，回答时还会情不自禁地联系前面所有话题，输出也变得很长。两头烧钱。处理办法其实很简单：长对话处理敏感或者价值较高的话题时，随手把重要结论复制到外部笔记里，然后果断开一个新会话。新会话里，你只需要把关键结论粘贴进去，再继续提问即可。很多聊天产品已经提供了“新开对话”或者“上下文压缩”的功能，有就用。你在同一个会话里硬撑着聊，不是在省钱，而是在给token计费器送钱。4.3 关于token计费的几个误区我整理了五个最常见的误区，方便你直接对照：误区真相只有模型生成的内容才计费输入和输出都计费，输入token更容易失控系统提示词是固定功能，不占用token系统提示词每次请求都会作为输入token参与计费设置max_tokens能降低整次调用的消耗max_tokens只限制输出，输入不会因此变少上传文档给模型是本地处理文档如果被拼进上下文参与推理，就按输入token计费一直用一个会话比开新会话省钱长历史反复重发，反而越来越贵，新会话往往更便宜这里面第一条和第二条几乎覆盖了90%的“我什么都没干怎么就没额度了”的疑问。尤其是移动端用户，很多只看到界面上的聊天内容，看不到每次请求实际发出的文本量。你一旦意识到系统提示词和历史也是计费对象，那些奇怪现象立刻就解释得通了。关于缓存，有一点也值得注意。部分服务对重复出现的前缀做缓存计费，如果同一个系统提示词被反复使用，命中缓存时可以省下不少费用。但不同服务的缓存策略和有效期差异很大，有的甚至默认关闭。做成本优化时，可以先查一下该服务是否支持缓存，再决定要不要把系统提示词固定为同一个前缀。这个信息看服务文档最准，别靠猜。5. 实测有效的token压缩工具与成本复盘5.1 我的一份token成本记录表光讲原则不讲数据，很多人还是不知道效果到底有多大。我贴一份最近做的三个模拟项目的成本记录，均来自我自己的实际测试环境，token数量是按接口返回的usage字段统计的。项目场景优化前平均每次token优化后平均每次token节省幅度主要手段智能客服问答5600140075%提示词缩到60字、只保留最近3轮历史、输出限120字文档问答工具8200220073%检索增强只取top3块、max_tokens=600会议纪要助手6000250058%分段摘要后合并、用结构化清单输出注意，这些数字不是说模型性能变了，而是我改变了使用方式。客服场景里，我把原来的“热情专业”提示词全部压缩，并且每轮只给模型最近几条消息，结果用户体感上几乎没差别，因为那个产品本身就是任务导向的。文档问答工具从“全文档塞入”改成“检索增强”后，答案反而更准了，因为上下文里没有那么多无关噪声干扰判断，模型更容易锁定关键证据。会议纪要那个项目的优化更典型。以前我是把整场两个小时的转写文本一次性丢给模型，请求输入达到一万多token，模型输出也因为上下文太长而不断重复。现在我先按时间轴切成四段，每段单独做摘要，再把四个摘要合并成全局纪要。每段处理时输入都控制在2000token左右，总token少了，纪要质量也明显提高。所以一定要养成记录和复盘的习惯。每次做完优化，都要拿接口返回的真实usage数据对比，不要凭感觉说“好像便宜了”。有了这张表，后续再出问题也方便定位，是提示词增加了？还是历史没有截断？一眼就能看出来。5.2 三个让token消耗立减一半的小技巧除了上面这些系统性方案，我再分享三个特别适合日常聊天场景的小技巧，立竿见影。在系统提示词里加一句“不要客套，不要复述问题，直接给结论”。很多模型习惯于在回答结尾写“希望以上回答能帮到您，如果还有其他问题，欢迎随时提出”，也会在开头复述一遍用户的问题。看似无害，但每句客套都是输出token。加了这句之后，输出长度能直观下降10%到20%。要求模型优先用列表、表格或JSON输出，而不是大段段落。同样一段内容，用列表表达往往比用三个自然段表达少三分之一token。比如做信息整理时，明确指定“输出字段：项目、时间、责任人、状态”，模型就会自动省略连接词和废话。在粘贴日志和报错信息前，先自己截取关键行。很多开发者在排查技术问题时，习惯把几百行日志原封不动发给模型。但这几百行里真正与错误相关的可能只有五行。先把这五行提出来再提问，输入从几百个token变成几十个，模型反而更容易看出问题。别偷懒，这一步值得做。这些技巧单独用，效果已经很明显了，组合起来使用效果更佳。我自己现在的默认习惯就是“精简提示词 + 限定输出格式 + 手动截取上下文”，几乎不用额外工具，日常使用成本就能控制在很低水平。5.3 什么时候不该为了省token而降级最后说一个容易被忽略的边界问题。token能省，但不是所有场景都该省。如果任务涉及合同条款、医疗诊断、法律文书、复杂系统的安全审计这些关键领域，把上下文压缩得太狠，比如直接丢弃部分历史摘要、只保留检索片段，是有风险的。省掉的token里可能藏着关键细节。一旦模型因为缺少上下文而做出了错误判断，后续纠错成本可能远超那点token费用。在这些场景，我宁愿把整份材料都带在上下文里，并且把超长分段窗口开大，也要保证完整性。我的实际取舍标准很简单：高频、低风险、标准化任务，比如客服问答、资料整理、信息抽取，适合极限压缩；低频、高风险、需要深度推理的任务，比如合同分析、故障根因排查、核心决策支持，宁可多花token也不能牺牲可靠度。把这两类场景分开处理，而不是一刀切地追求“最省”，才是长期做下来最划算的玩法。做技术优化久了你会发现，token消耗问题表面上是费用问题，本质上是信息管理问题。只要把该保留的保留、该截断的截断、该检索的检索，模型的能力一分不减，费用却可以大幅降下来。希望这篇里记录的方法和踩坑经验，能帮你少走点弯路。
搞AI的人，不管你是天天泡在聊天页面里，还是自己在后端接大模型API，对 token 这个词都不会陌生。我最近被问得最多的问题之一，就是“为什么 token 消耗得这么快”“明明没聊几句，费用却涨得吓人”。这篇内容就是专门来回答这个问题的：从token计费的底层逻辑、最容易被忽视的隐性消耗点，到不花钱的优化方案、工具层面的压缩手段，再到我实际跑项目时的成本记录表。适合正在做AI客服、文档问答、自动化工具等开发的读者，也适合只是平时重度使用大模型、想省点费用的普通用户。坦白说，token消耗过快这个问题，绝大多数时候不是模型“太蠢”，而是使用方式出了问题。只要理解了它的计费规则，再把上下文管理和任务拆分的几个习惯改了，大多数人能把token消耗降低50%以上。下面我把整个思路和实操记录都写出来。1. 为什么你的token总是不够用：消耗过快的核心原因1.1 搞清楚token计费的底层逻辑先统一一下基本概念。模型在读取和生成文本时，并不是一个字一个字地处理，而是把文本切成固定大小的“小块”，这些小块就是token。不同模型的分词器不一样，中文通常一个汉字可能占1到1.5个token左右，英文一个常见单词大约占1个token，标点符号、空格、换行符也都可能按token计算。计费的核心公式是：单次请求费用 = 输入token数 × 输入单价 + 输出token数 × 输出单价。很多人只看“输出”，因为那是模型现场写出来的，肉眼可见。但实际上，输入token往往才是真正的消耗大头。你每次发出去的问题、附带的系统提示词、聊天历史、粘贴进去的文档，通通都算输入token。如果这个输入非常大，那即使模型只回答了一个“好”字，这次调用的成本也已经定下来了。我习惯用一个小例子说明问题。假设你的单次请求里，系统提示词写了300个字，历史对话累积了4000个字，这次用户的问题又占80个字，那么输入token轻轻松松超过5000。模型输出哪怕只有200字，跟输入一比完全是小头。所以排查token消耗过快的第一个方向，就是看看自己的输入侧到底塞了多东西。1.2 三个容易被忽略的隐性消耗点我接触过的项目里，至少90%的token浪费都逃不过这三点。第一点是系统提示词过于臃肿。很多人在做项目时，会把“你是一个资深的某某顾问，拥有十年以上经验，擅长……，请用专业、详尽、条理清晰的风格回答，同时注意……”这种两百字以上的设定放在系统提示词里。听起来很合理，但是请注意：这段提示词在每一次请求中都会被完整计入输入token。就算用户只问了一句“报价是多少”，系统提示词照样全部跑一遍。一次两次无所谓，调用量一大，浪费就变成真金白银。第二点是被忽视的多轮对话历史。这是普通用户踩得最重、开发者也常犯的问题。大模型本身是无记忆的，为了看起来有记忆，产品会把你和它的整个聊天记录，在当前这轮请求里重新发给模型。假设每轮问答平均消耗600个token，聊到第10轮时，你发出第11个问题，系统会把前10轮大约6000个token的历史全带上，再加上新问题，一次请求就逼近7000个token。如果你早就忘了第一轮聊过什么，这些历史就是纯粹的负担。第三点是直接把长文档和日志整段粘贴进上下文。上传资料、粘贴说明书、把一整个代码文件扔给模型，这些操作确实方便，但代价也很大。比如一份产品手册可能有一万多个token，而你真正想问的只是“退货流程”这一小节。结果就是除了那一小段，剩下九千多个token全成了“背景噪声”，你为它们付了费，模型还得花力气忽略它们。这三个点综合起来，就解释了为什么你会觉得“没聊几次就没额度了”。不是模型太能吃，而是每次请求的输入都被强行灌了大量重复内容。2. 不花一分钱的优化方案：从根本上减少token消耗2.1 精简系统提示词与固定模板先说最立竿见影的一步：给系统提示词瘦身。做项目的时候，系统提示词该有的作用一定要保留，但表达方式可以从“长篇大论”改成“清单式关键字”。我之前见过一份膨胀版的提示词，大概是这样的：你现在是一个拥有十年以上行业经验的资深顾问，特别擅长用户需求分析和问题解决。在回答问题时，请务必条理清晰，分点作答，注意考虑用户的背景和真实需求，同时给出可执行的建议，注意语气友好专业，让用户感到被尊重。这段内容看似专业，其实对模型能力的提升非常有限。精简之后可以是这样：你是行业顾问。回答要求：结论先行，不超过300字；使用列表说明依据；语气直接，不客套。两者信息量差不多，但token消耗能少一半以上。我的判断原则是：一条提示词如果去掉之后不影响任务完成度，那就果断去掉；如果只影响“语气风格”而不影响“内容正确性”，也尽量压缩成几个关键词。固定模板可以继续用，但模板本身也要控制体积。比如你做一个客服机器人，模板里只需要写明品牌名、处理规则、禁止事项，其余什么“热情”“专业”的形容词都可以浓缩成“语气友好”四个字。建议每隔一段时间把模板打出来数一遍字数，超过200字就重新精简一次。2.2 主动管理上下文窗口单次请求的input token，等于“系统提示词 + 本次问题 + 历史对话”。在系统提示词已经精简的情况下，历史对话就是最需要管理的对象。最朴素的方案是“聊天截断”：定期把之前的对话清掉，只保留最近几轮。这个方法简单粗暴，但很有效。我自己的习惯是：在做普通问答型应用时，只保留最近3轮历史；在做任务型应用时，有时候一轮历史都不保留，直接把必要的信息放进变量里。比单纯截断更进一步的是“历史摘要压缩法”。具体操作步骤是：当对话进行到5到8轮，或者明显感觉模型开始忽略早期内容时，发一条指令让它把当前对话压缩成一份简短摘要，然后把摘要复制到新会话中继续。摘要内容不需要保留每个字，只需要记录关键事实、未解决的问题和已经确定的结论。实际操作时，我会用一段类似这样的指令：请把当前对话压缩成一份200字以内的摘要，保留：已经明确的信息、尚未解决的问题、下一步计划。只输出摘要本身。这个动作的回报非常可观。原来你可能带着5000个token的历史继续聊，压缩后历史只剩200个token，输入开销直接小了一个数量级。代价只是每次压缩时花几十个token生成摘要，这笔账怎么算都划算。2.3 任务拆分与单轮聚焦第三个不花钱的办法，是改变你向模型提问的方式。我见过很多人喜欢一口气问一堆问题，比如“帮我分析这份报告的整体趋势、主要问题、竞争对手情况、下季度建议和风险提示”。模型听完了，出于尽责，会老老实实把每个点都展开说，输出轻松超过1500个token。但很多用户真正关心的只是其中一个点，剩下几段全是陪跑。我倾向于把这种大而全的问题拆成几次调用。先问“整体趋势如何”，拿到结论后，再在新会话里问“主要风险有哪些”。虽然请求次数变多了，但每次请求的输入短、输出短，总token反而更低，而且答案质量往往也更好。原因是模型不用把注意力分散到六个方向上，上下文里全是与当前问题相关的内容，生成时更聚焦，废话更少。单轮聚焦的意思是：一个会话只解决一个问题，不要让一个会话同时承担“问答、写作、分析、翻译”多个职能。模型没有真正的多任务处理能力，它只是把所有上下文混在一起推理。会话目的越单一，需要的上下文就越短，token消耗自然越少。3. 用工具和技术手段压缩token：实操方案3.1 使用结构化输出与低token偏好设置如果你的项目是直接调用API，那么几个基础参数是必须会调的。在这里先说清楚一个关键点：很多新手以为设置max_tokens就能控制整次请求的费用，这是不对的。max_tokens限制的是模型最多能输出的token数量，跟输入token没有半毛钱关系。你哪怕把max_tokens设成1，输入侧该是多少还是多少。所以它只能帮你管住输出，管不住输入。输出侧仍然值得优化。比如在系统提示词里写明“只输出JSON，字段为name, result, reason”，模型就不会给你写一大段解释。比如要求“直接给结论，不需要步骤说明，不需要礼貌用语”，模型就不会在结尾补一句“希望以上回答能帮助您”。这些冗余输出在长对话场景里累积起来不可小觑，可能占整体输出token的20%以上。temperature参数也值得注意。它控制的是模型的发散程度，调得太高，比如1.0以上，模型就容易多说废话、重复说车轱辘话。用于问答、摘要、信息抽取等任务时，我通常把它设置在0到0.3之间。只有做头脑风暴、写创意文案时才会调高到0.7以上。温度调低一点，输出会明显更紧凑，token自然更少。3.2 文本预处理与分段处理长文本处理是token消耗的重灾区。我见过一些项目，为了写一个报告摘要，把整个几十页的PDF全文塞给模型，然后要求它“总结全文”。这个问题不只是贵，还在于模型对超长上下文的中间位置内容容易遗忘或混淆，输出质量反而不如只喂关键章节。正确的做法是先分段，再定位，最后只把相关部分发给模型。比如你有一份产品手册，用户想问“退货流程”。全文可能有2万个token，直接全传太浪费。你应该先在本地把手册按章节切成若干段落，把段落标题或者首句组织成一个简单的索引，然后让一个成本更低的模型或直接靠关键词匹配定位到“售后政策”章节，最后只把那一段文本发给主力模型回答问题。我把它叫做“小模型做粗筛，大模型做精答”。这种组合拳不但省钱，而且速度更快。因为定位任务对模型推理能力要求不高，用小模型或者简单的文本检索就够用了，而生成最终答案的任务再用大模型。批量处理文档时，这个策略能把总token消耗降一个数量级。做完文本预处理后，代码结构大致长这样：先读文件、分块，再根据查询条件筛选出候选块，最后把候选块和问题拼接成新的prompt。注意，不要在一开始就把全部文本拼进prompt，否则就失去了分段处理的意义。3.3 长文档总结与检索增强的组合玩法如果你需要频繁对一个知识库提问，比如企业知识库、产品文档集，那一定要用检索增强的方式。它的核心思想特别朴素：不要每次都把整本参考资料背给模型听，而是先从资料里检索出与当前问题最相关的几段，只把这几段塞进上下文。我把这个过程用类比说明一下。平时我们看书，不会把整本书抄进笔记再回答一个问题，而是会先翻目录，找到相关章节，再精读那几页。检索增强就是这个“翻目录精读”的动作。对模型来说，上下文越短，越容易聚焦，答案也越准确。具体步骤一般是这样：把文档按固定长度切成块，比如每块500个字符，注意块与块之间保留少量重叠，避免截断重要内容。对每个块做向量化，存进一个本地索引。这个步骤只需要执行一次，目的是让机器知道“哪块内容大概在说什么”。用户提问时，先把问题向量化，然后从索引里取最相近的3到5个块。把这几个块拼接成上下文，连同原问题一起发给模型。伪代码示意如下：from your_embedding_tool import embed from your_vector_store import VectorStore full_text = load_text("product_manual.txt") chunks = split_text(full_text, chunk_size=500, overlap=50) store = VectorStore(embedding_fn=embed) store.index(chunks) query = "退货流程需要哪些材料" context_blocks = store.search(query, top_k=3) context_text = "\n".join(context_blocks) prompt = f"根据以下资料回答问题：\n{context_text}\n\n问题：{query}" result = call_llm(prompt, max_tokens=400)这个方法对token的压缩效果非常惊人。假设原始文档有2万个token，你每次只取3个块共1500个token，输入侧直接减少了92%以上。加上向量化和检索本身可能产生的少量计算成本，整体仍然比全量传入便宜太多。唯一需要注意的是切块策略：块太小会丢失上下文，块太大又起不到压缩作用，500到800个字符之间是一个比较稳妥的区间。4. 常见问题与排查技巧实录4.1 为什么同样的对话，不同模型消耗不一样经常有朋友跟我说，同样的对话换个模型，token数量就变了。这不是幻觉，主要有三个原因。第一，不同模型分词器不同。同一个句子里，中文分出来的token颗粒度可能差别很大。有的模型对中文比较友好，一个汉字可能只算1个token，有的模型可能一个常用词就占2到3个token。第二，很多服务会在系统提示词之外，偷偷加上一些固定标记，比如对话分隔符、角色标记、参数设置里的默认prompt。这些隐藏token也会计入总量。第三，部分服务会做前缀缓存，同一个前缀重复使用时计费方式不同，有的便宜，有的几乎没差别。排查异常消耗时，第一件事是看接口返回里的usage字段。它通常会包含输入token数、输出token数，有的还会给出缓存命中情况。我每次排查成本问题，绝不会只看总费用，而是先看：是输入涨了还是输出涨了？如果是输入涨了，就去检查系统提示词、历史对话和文档内嵌；如果是输出涨了，就去看max_tokens和temperature设置。不看数据就猜原因，等于闭着眼睛修代码。4.2 上下文越聊越贵的处理办法用户最常见的抱怨其实发生在这类场景里：在同一个聊天窗口里连续问了一个小时，中间夹杂着大量“好的”“明白了”“这个再解释一下”之类的互动，最后突然问“把最开始那个方案再说一遍”。此时系统为了让他“看得到上下文”，会把他这一个小时聊的所有内容重新发给模型，可能已经积累了两三万token。模型看到这么多内容，回答时还会情不自禁地联系前面所有话题，输出也变得很长。两头烧钱。处理办法其实很简单：长对话处理敏感或者价值较高的话题时，随手把重要结论复制到外部笔记里，然后果断开一个新会话。新会话里，你只需要把关键结论粘贴进去，再继续提问即可。很多聊天产品已经提供了“新开对话”或者“上下文压缩”的功能，有就用。你在同一个会话里硬撑着聊，不是在省钱，而是在给token计费器送钱。4.3 关于token计费的几个误区我整理了五个最常见的误区，方便你直接对照：误区真相只有模型生成的内容才计费输入和输出都计费，输入token更容易失控系统提示词是固定功能，不占用token系统提示词每次请求都会作为输入token参与计费设置max_tokens能降低整次调用的消耗max_tokens只限制输出，输入不会因此变少上传文档给模型是本地处理文档如果被拼进上下文参与推理，就按输入token计费一直用一个会话比开新会话省钱长历史反复重发，反而越来越贵，新会话往往更便宜这里面第一条和第二条几乎覆盖了90%的“我什么都没干怎么就没额度了”的疑问。尤其是移动端用户，很多只看到界面上的聊天内容，看不到每次请求实际发出的文本量。你一旦意识到系统提示词和历史也是计费对象，那些奇怪现象立刻就解释得通了。关于缓存，有一点也值得注意。部分服务对重复出现的前缀做缓存计费，如果同一个系统提示词被反复使用，命中缓存时可以省下不少费用。但不同服务的缓存策略和有效期差异很大，有的甚至默认关闭。做成本优化时，可以先查一下该服务是否支持缓存，再决定要不要把系统提示词固定为同一个前缀。这个信息看服务文档最准，别靠猜。5. 实测有效的token压缩工具与成本复盘5.1 我的一份token成本记录表光讲原则不讲数据，很多人还是不知道效果到底有多大。我贴一份最近做的三个模拟项目的成本记录，均来自我自己的实际测试环境，token数量是按接口返回的usage字段统计的。项目场景优化前平均每次token优化后平均每次token节省幅度主要手段智能客服问答5600140075%提示词缩到60字、只保留最近3轮历史、输出限120字文档问答工具8200220073%检索增强只取top3块、max_tokens=600会议纪要助手6000250058%分段摘要后合并、用结构化清单输出注意，这些数字不是说模型性能变了，而是我改变了使用方式。客服场景里，我把原来的“热情专业”提示词全部压缩，并且每轮只给模型最近几条消息，结果用户体感上几乎没差别，因为那个产品本身就是任务导向的。文档问答工具从“全文档塞入”改成“检索增强”后，答案反而更准了，因为上下文里没有那么多无关噪声干扰判断，模型更容易锁定关键证据。会议纪要那个项目的优化更典型。以前我是把整场两个小时的转写文本一次性丢给模型，请求输入达到一万多token，模型输出也因为上下文太长而不断重复。现在我先按时间轴切成四段，每段单独做摘要，再把四个摘要合并成全局纪要。每段处理时输入都控制在2000token左右，总token少了，纪要质量也明显提高。所以一定要养成记录和复盘的习惯。每次做完优化，都要拿接口返回的真实usage数据对比，不要凭感觉说“好像便宜了”。有了这张表，后续再出问题也方便定位，是提示词增加了？还是历史没有截断？一眼就能看出来。5.2 三个让token消耗立减一半的小技巧除了上面这些系统性方案，我再分享三个特别适合日常聊天场景的小技巧，立竿见影。在系统提示词里加一句“不要客套，不要复述问题，直接给结论”。很多模型习惯于在回答结尾写“希望以上回答能帮到您，如果还有其他问题，欢迎随时提出”，也会在开头复述一遍用户的问题。看似无害，但每句客套都是输出token。加了这句之后，输出长度能直观下降10%到20%。要求模型优先用列表、表格或JSON输出，而不是大段段落。同样一段内容，用列表表达往往比用三个自然段表达少三分之一token。比如做信息整理时，明确指定“输出字段：项目、时间、责任人、状态”，模型就会自动省略连接词和废话。在粘贴日志和报错信息前，先自己截取关键行。很多开发者在排查技术问题时，习惯把几百行日志原封不动发给模型。但这几百行里真正与错误相关的可能只有五行。先把这五行提出来再提问，输入从几百个token变成几十个，模型反而更容易看出问题。别偷懒，这一步值得做。这些技巧单独用，效果已经很明显了，组合起来使用效果更佳。我自己现在的默认习惯就是“精简提示词 + 限定输出格式 + 手动截取上下文”，几乎不用额外工具，日常使用成本就能控制在很低水平。5.3 什么时候不该为了省token而降级最后说一个容易被忽略的边界问题。token能省，但不是所有场景都该省。如果任务涉及合同条款、医疗诊断、法律文书、复杂系统的安全审计这些关键领域，把上下文压缩得太狠，比如直接丢弃部分历史摘要、只保留检索片段，是有风险的。省掉的token里可能藏着关键细节。一旦模型因为缺少上下文而做出了错误判断，后续纠错成本可能远超那点token费用。在这些场景，我宁愿把整份材料都带在上下文里，并且把超长分段窗口开大，也要保证完整性。我的实际取舍标准很简单：高频、低风险、标准化任务，比如客服问答、资料整理、信息抽取，适合极限压缩；低频、高风险、需要深度推理的任务，比如合同分析、故障根因排查、核心决策支持，宁可多花token也不能牺牲可靠度。把这两类场景分开处理，而不是一刀切地追求“最省”，才是长期做下来最划算的玩法。做技术优化久了你会发现，token消耗问题表面上是费用问题，本质上是信息管理问题。只要把该保留的保留、该截断的截断、该检索的检索，模型的能力一分不减，费用却可以大幅降下来。希望这篇里记录的方法和踩坑经验，能帮你少走点弯路。