Token 与上下文窗口这两个词几乎决定了你用大模型时的体验和账单但大多数人是在收到第一笔费用之后才被迫去了解它们。我做了很长一段时间的大模型应用落地也踩过不少坑被“失忆”坑过也被账单吓到过。这个主题我故意放到很靠后才写因为它是一个底层问题前面几篇讲的提示词技巧、模型选择、对话风格其实都在间接和这两个概念打交道。从一次非常典型的对话说起你早上问模型“帮我梳理下周要交的季度报告大纲”聊了十几轮细化之后下午再打开窗口问它“第三部分的数据口径是按上个月还是这个月”它一脸茫然仿佛没见过你。你气得不行觉得这产品真健忘。其实不是产品健忘是Token与上下文窗口在背后给你划了一道物理边界。这篇文章我会把这些边界讲透并分享我长期实践中沉淀下来的省钱和防遗忘方法适合刚接触大模型的用户也适合做应用开发的工程师。1. 先搞懂Token是什么模型嘴里最小的“单词”1.1 中文1个字约等于1.5个Token别急着背这个数大模型不直接读文字它读的是Token。你可以把它理解为模型处理文本时最小的语义碎片。英文里一个词常常被切成1到2个Token所以英文文档里的“一个单词”和Token数大体对应中文不一样一个汉字可能在1到2个Token之间浮动标点符号、空格、换行也会被算进Token。我第一次看到Token统计的时候也很疑惑一段70个字的中文后台显示105个Token怎么多出来35个后来才发现是标点和一些常见词组被切碎了。不同模型用的分词器不一样同一个句子在A模型是90个Token在B模型可能变成110个。所以那句“一个汉字约等于1.5个Token”只能用来做粗略估算不能当作精确换算。如果你用API每个请求返回的结果里通常会带usage字段里面有prompt_tokens、completion_tokens和total_tokens。这才是计费的唯一依据也是监控成本时最需要关注的数据。1.2 为什么切词方式直接影响“智商”和“账单”Token切分方式不只是计费问题它还影响模型的理解能力。模型看到的不是字符而是Token ID序列如果切得太碎模型可能抓不住词与词之间的整体语义切得太粗又可能把不常见的组合词揉在一起导致理解泛化能力变差。我打一个比方Token像你在菜市场买肉摊主默认给你切成块你可以要求切丝、切片还是剁成馅。同一个词在不同模型里被切成不同大小本质上就是不同摊主的刀法。刀法决定了后面炒菜的口感对应到模型上就是回答质量的差异。这也是为什么同样一个问题两个模型回答水平差不多账单上的Token数却可能差出一倍。理解了Token的底层逻辑你才算真正看懂了“为什么同样一段文字有的接口便宜有的接口贵”。1.3 从Token看长文本的“隐藏成本”长文本对Token的消耗是很多人没概念的。一份两三万字的项目文档我粗略折算过大概要消耗两万到三万个Token。如果你把这整份文档塞进对话让模型帮你“通读并总结”光输入这一步Token数就轻松破万。最容易被忽略的是附件和格式。我之前有个项目用户上传了一个PDF让模型提取表格数据模型平台会自动把PDF转成文本这一转Token量比PDF原始字数膨胀了20%。因为PDF里包含大量格式控制字符、页眉页脚和无意义的断行模型不能像人眼一样忽略它们它必须为每个字符付费。所以我现在处理长文档习惯是先做一道“清洗”用脚本把PDF里明显的页眉页脚去掉把表格转成CSV格式再喂给模型。清洗前后的Token差距能到30%以上。2. 上下文窗口就是工作桌面模型不是不想记是它只能记这么多2.1 窗口之内模型怎么“记住”前面说的话先澄清一个最常见的误解模型本身没有记忆。它本质上是一个无状态的推理函数你输入什么它输出什么一轮聊完它脑子里不残留任何东西。所谓多轮对话的“记忆”是应用层在每次请求时把所有历史聊天记录重新发送给模型让它能“看到”之前的对话。上下文窗口就是这个应用层能塞给模型的最长输入长度通常以Token为单位。打个比方模型是一个在办公桌上临时工作的顾问你的历史聊天记录是摊在桌上的文件新来的问题是一张待办便签。桌面总大小固定桌上只能放这么多纸新纸要放上来旧纸就得被抽走。不同模型的桌面大小不一样。有的模型桌面能放8000个Token大约能装下几千字的中文对话有的能放128K甚至更多可以容纳长文档。但无论窗口多大它都有边界不存在无限记忆。2.2 窗口之外超限之后到底发生了什么这是“为什么它会忘”的第一个核心答案当历史消息加上新的提问超过了上下文窗口上限应用后端最常见的处理方式是直接截断。截断不是从最早开始断就是从最中间找一段砍掉。不同平台策略不一样但结果都一样——模型的“眼前世界”里已经没有那些内容了。你问它“我上周提过的预算范围是多少”它看到的是几轮被截断后的碎片当然答不上来。更麻烦的是很多平台截断时并不会提醒你它在后台悄悄删掉旧记录只保留最近几轮所以你感觉它“失忆了”其实它是“文件被桌面管理程序清走了”。我自己遇到过最夸张的一次一个对话聊到上下文快满时模型开始反复重复同样的建议我以为它变笨了后来查了请求日志才发现最早的十几轮内容已经被截断它只能根据最后几轮内容“盲猜”我的项目背景越猜越离谱。2.3 所谓“失忆”其实是三种情况混在一起第一种是“截断失忆”就是上面说的窗口超限被清理。第二种是“注意力失忆”这个更隐蔽。就算上下文窗口完全没超限模型对同一段长文本中不同位置内容的关注度也不是均匀的很多研究都发现模型对开头和结尾部分记得更牢对中间部分的利用效率明显偏低。你如果有一份关键信息藏在长对话的中部模型很可能真的“看过”却“没注意”。第三种是“会话隔离”。你新建了一个对话窗口以前的对话记录完全不会带过来。这不算模型失忆是应用设计如此但产品上体验起来就是“你换了个人说话它不认识你了”。很多新手把这种隔离误当成模型能力问题其实换个窗口钱也省了记忆反而更专注。搞清楚这三种情况你会发现“它会忘”并不是随机bug而是有规律可循的要么超了边界要么注意力分配不均要么根本不在同一个会话里。3. 账单为什么越来越吓人Token是唯一的计价单位3.1 计费规则输入、输出、缓存三笔钱别搞混主流API平台的计费逻辑很简单输入Token和输出Token分开计价而且输出通常比输入贵3到5倍。输入是你发给模型的所有内容包括系统提示词、历史对话和当前提问输出是模型生成的回复。这个价格差异是有原因的生成过程比理解过程更消耗算力。如果一个模型按百万Token计价输入0.15美元、输出0.6美元看起来单价很低但一旦乘上频繁调用的次数费用就会迅速累积。我经常看到有人只盯着“单次响应”的价格觉得一次几分钱很便宜却忽略了每天几十上百次调用之后积少成多的账单。除了输入输出现在很多平台还多了一笔“缓存费”。上下文缓存会把相同的前缀Token缓存下来二次请求时命中缓存输入价格能打一个折扣但缓存本身按存储时间计费。这个功能用得好能省不少钱用不好反而会多出一笔固定开销。3.2 为什么多轮对话越聊越贵每次都把整本“聊天记录”重新读一遍这是“为什么会贵”最核心的机制。因为模型无状态所以每次请求你要把所有历史消息重新发一遍。你在第10轮提问时输入里包含的不只是第10轮的新问题还有前9轮的完整对话。这意味着上下文越长每一轮的输入Token越多费用呈线性增长甚至比新开一个会话贵好几倍。我用一个简化的例子来说明。假设每轮你输入500Token模型输出1000Token系统提示词固定600Token第1轮输入1100Token输出1000Token第5轮输入7100Token输出1000Token第10轮输入14600Token输出1000Token第10轮单次请求的费用大概是最开始第1轮的10倍以上。如果你连续聊30轮光是输入历史对话消耗的Token累计就有几十万。这就是为什么一款产品明明单次调用很便宜实际跑起来账单却很吓人。3.3 平台不告诉你的细节长提示词衰减和重复计费除了输入输出还有几个隐藏成本点。第一是思考链Token部分模型在输出最终答案之前会生成一段“内部思考”过程这些思考内容同样按输出Token计费你看到回复只有500字后台可能已经生成了800字思考内容。第二是输出截断浪费如果模型生成到一半被max_tokens截断前面已经生成的部分照样全额计费。更隐性的成本是“长提示词衰减导致的重试”。上下文太长、中间信息利用率低的时候模型回答质量会下降。你发现答得不对就会重新提问提问次数翻倍费用跟着翻倍。这不是平台在骗你而是Token机制本身造成了两头损失既花钱买了历史又没换回相应的质量。我现在的建议是把“历史记录”看成一种有价格的文件别随便囤着。能用摘要解决的不要整段原文搬运能新开对话的不要无限续聊。4. 实测记录一场对话从第1轮到第30轮的Token消耗4.1 测试设计从一句“帮我写个大纲”开始为了让你直观感受Token是怎么涨上去的我做了一次模拟测试。假设一个常见场景用户让模型写一篇产品介绍的大纲然后一轮一轮地提修改意见比如“第二段语气再正式一点”“数据部分换一种说法”“把卖点加到第三点”。每次用户新增大约500Token模型输出大约1000Token系统提示词固定600Token。在实际请求里应用会把每轮的用户消息和模型回复都追加到messages列表里所以到第N轮时输入Token就是“系统提示词 前N-1轮完整对话 当前轮用户输入”。我把近似计算结果放在下面。4.2 实测结果第3轮、第10轮、第20轮、第30轮的变化下表是按输入0.15美元/百万Token、输出0.6美元/百万Token估算的单次请求费用和累计费用轮次输入Token约输出Token约该轮费用美元累计费用美元第1轮110010000.00080.0008第3轮410010000.00220.0044第5轮710010000.00350.0112第10轮1460010000.00620.0362第20轮2960010000.01160.1168第30轮4460010000.01700.2419单看每一个数字都不高但累计30轮虚拟对话一共消耗了约60万Token其中大头全在反复发送旧历史。这还只是很克制的对话节奏。一旦用户每次提问都喜欢把要求重复一遍或者模型回答偏向长篇大论Token增长会更加夸张。换成企业场景就更吓人了。比如做一个文档问答助手每次提问都要把一份15万Token的项目文档作为背景发送再加上最近20轮的聊天记录。单次输入约15万 5万 20万Token单次成本20万 x 0.15美元/百万 0.03美元加上输出约0.005美元合计约0.035美元假设100个用户每人每天提问10次0.035 x 1000 35美元/天一个月按22个工作日算770美元一个月大几千元人民币的成本就这么花在了“反复读同一份文档”上。这是很多团队上线第一个AI应用后账单翻车的最常见原因。4.3 这组数据告诉我们的真话“为什么贵”的本质不是单价高而是重复发送历史内容的次数太高了。模型是无状态的你每次都要把旧内容重新喂一遍这就像每天早上把上周所有的会议记录重新朗读一遍然后才开始今天的工作。时间久了你当然觉得累放在服务器上换来的就是一笔一笔的Token账单。理解了这组数据你就能理解我后面给的实战清单所有省钱方法的本质都是减少“重复发送的Token”所有防遗忘方法的本质都是把关键信息放到模型更容易注意到的地方。5. 长期实战后总结的省Token与防遗忘清单5.1 开聊之前把项目背景写进系统提示词而不是每轮重复很多人在对话里反复说“我之前跟你说的那个项目”然后发现模型一脸懵。正确做法是开一个会话时就用一小段话把项目背景、目标、约束条件写清楚。如果你用的是API就放到system消息里如果你用的是聊天产品就放在第一轮提问里。系统提示词不是越长越好控制在200Token以内效果通常最佳。背景信息越精准模型越不需要靠历史记录去猜你也就越不容易触发上下文超限造成的“失忆”。我通常的格式是这样{ system: 你是一名产品运营顾问。项目背景面向中小企业的一站式发票管理工具本季度目标是提升老用户续费率。回答时保持简洁不重复用户原话。 }这个做法同时减少了历史里的冗余内容也把关键信息固定在模型更容易注意到的开头位置。5.2 聊到一半定期让模型“复述重点”而不是无限续聊当你发现对话轮数已经超过七八轮或者感觉模型开始忽略早期信息时别硬着头皮继续聊。用一个临时指令让模型把当前已经达成的结论整理成结构化摘要比如“请把到目前为止的关键结论、已确认参数、待办事项用50个Token以内总结出来”。拿到摘要后新建一个会话把这段摘要作为系统提示词再继续提问。这一步相当于把你桌上已经堆乱的文件整理成一张索引卡然后换一张干净桌子继续工作。Token成本立刻从那几十万的历史记录变成几百Token的摘要。我实测过同样是修改一份文案用“摘要新会话”的方式整体费用能降低60%以上而且模型对前文关键信息的遵循度反而更高因为它不再需要从海量历史里大海捞针。5.3 对话快到底时主动截断历史或清理无关内容如果你用的是API接口可以在每次请求时只保留最近N轮消息。比如设置成只传最近4轮再加一条系统提示词说明“只根据给定对话记录回答”。这能让上下文窗口保持清爽代价是更早的内容会被遗忘所以它适合对信息连贯性要求不高的场景。你还可以手动清理对话里已经被修改过的旧版本。很多人贴了第一版文案模型又给了第二版他们会在后面的对话里继续保留第一版全文。这些第一版内容已经没有任何信息价值却依然每个字都在收费。我的习惯是一旦采纳了某个版本就把旧版本从消息数组里删掉只保留最终版本。5.4 模型选择也影响成本长窗口不是默认选项长上下文窗口确实方便但它通常也更贵。如果你的任务只是日常问答、写邮件、改文案几百Token就能搞定完全没必要选一个128K窗口的高价模型。小窗口模型在成本和响应速度上都更友好而且因为窗口小输入Token也很难越积越多相当于变相强制你控制历史长度。反过来如果你的任务就是处理长文档短窗口模型才是真正的坑。因为长文本一进来就超限应用后台只能截断结果就是钱没少花模型还漏看内容。选模型之前先估算一下你需要的最小上下文长度然后在这个长度附近找一个窗口和价格都合适的模型。5.5 用好缓存而不是迷信缓存上下文缓存能降低重复部分的输入费用这对“多次提交相同系统提示词”的场景特别有用。命中缓存后重复前缀的输入单价可以便宜很多输出价格不变。但缓存有代价存储按时间计费而且缓存内容一旦更新旧缓存就失效了。所以缓存适合那种系统提示词固定、用户输入变化不大的场景。如果你的每次请求内容都高度不同缓存不仅帮不上忙还会多一笔存储费。我见过一个团队把缓存用在“每次生成不同推广文案”的接口上结果每次前缀都不同缓存命中率几乎为零账单里多出一项不小的缓存存储费。后来关掉缓存成本立刻降了。5.6 防遗忘的应急技巧把关键信息“移动”到对话边缘根据前面说的注意力偏差模型对对话开头和结尾的内容更敏感。如果有一段信息非常重要你可以在当前提问里再复述一次而不是只让模型回头去翻中间轮次。比如你可以这样写“注意预算上限是5000元这个约束在之前的讨论里已确认。请基于这个数字给出方案。”把关键约束放到提问末尾模型正确响应的概率会高很多。这招不能解决所有遗忘问题但在关键时候能抢救一下也是我自己最常用的应急手段。6. 最后说几句私货Token意识是使用大模型的分水岭我现在养成了一个习惯每次对话跑完都会下意识看一眼Token统计每次设计一个AI功能第一版一定会先估算输入输出Token的量级。这不是强迫症而是被账单教育过之后的身体记忆。如果你刚开始接触大模型我建议你也建立一个“Token意识”。它不复杂就是随时问自己两句话我这次发了多少Token其中有多少是真正有用的只要这两个问题有答案你就不会在“为什么它会忘”和“为什么这么贵”这两个问题上踩太多坑。至于那些想把历史记录全都堆给模型、指望它长点记性的做法我的建议是尽快放弃。Token与上下文窗口的边界就在那里与其对抗物理边界不如顺着边界设计你的对话和应用。桌面上的文件永远放不完聪明人知道什么时候把旧文件归档。