★ FEATURED ARTICLE 如果你在调大模型接口大概率碰到过这几类怪问题新建会话的时候它聪明得不行一聊到第20轮就开始“失忆”你问它最早聊过什么它一脸无辜打开账单一看没干多少活费用却高得吓人。要一次把这两件事说清楚绕不开两个核心概念Token 和上下文窗口。Token 是模型读取文本的最小单位上下文窗口是模型单次能够“同时看到”的最大文本范围。这两个东西决定了你最关心的三件事模型能看多远、会不会忘事、每次调用要付多少钱。这篇文章不扯高深的数学公式用大白话把 Token 怎么算、窗口怎么装、钱怎么烧讲透最后给出一套可以直接上手的防遗忘、省钱实操方案。适合正在调 API 的开发者、AI 产品负责人以及被“上下文不足”反复折磨的各类用户。1. Token 是什么先搞懂模型眼里的“最小文字单位”1.1 从字符到碎片Token 化是怎么回事模型不会直接读文字它读的是数字。Token 化就是把自然语言切成小块再映射成编号的过程。现在主流做法是字节对编码BPE之类的子词分词算法先看常见的词或词根把它们当作整体不常见的词再继续切成更小的碎片。拿一段中文文本举例“这是一个测试用例”在常见分词器下大概会被切成 7 到 10 个 Token。英文“What a nice day”大概切成 4 到 5 个 Token。但要注意这不是按字数、按单词数简单换算的。中文一个字有时候就要占 1 个甚至 1.5 个 Token英文一个常见单词通常 1 到 3 个 Token。代码和特殊符号更是 Token 大胃王几行配置代码吃掉的 Token 可能比一整段说明文字还多。这个特性直接决定了跨语言产品的成本差异。我做过一个小实验同一篇文档中文版约 600 字英文版约 480 个单词用同一款分词器统计中文版折算出的 Token 数大约是英文版的 1.5 到 2 倍。也就是说如果你的产品主要面向中文用户同样的功能Token 消耗天然就比英文产品高一截这不是你写代码能解决的是分词方式决定的。字数不等于 Token 数这个认知很重要。很多刚接触 API 的同学喜欢按字数估算费用一估算就乐观一结算就被打脸原因就在这。1.2 为什么按 Token 计价而不是按字数或字符先看根本原因模型的计算开销和 Token 数强相关而非字数。输入侧模型要把所有 Token 两两之间计算“注意力”Attention这是个近似 O(n²) 复杂度的操作。Token 数从 1000 涨到 2000这部分的计算量不是翻倍而是接近翻四倍。你的输入越长单位 Token 的均摊计算成本越高。这也是长上下文迟迟不敢把价格打下来的原因之一。输出侧更夸张。大模型生成文本是逐 Token 自回归的过程每次生成一个 Token都要基于前面已经生成的全部内容重新算一遍上下文。也就是说生成 100 个 Token本质上是执行了 100 次“小号预测”每往后写一个字耗费的计算资源都在增加。这也是为什么几乎所有 API 都把输出价格定得比输入贵甚至贵出 2 到 3 倍。类比一下按 Token 收费就像货车按车次计费不按包裹个数计费。司机跑一趟的成本取决于总共有多少批货、跑了几趟而不是包裹本身多大。模型处理的时候每个 Token 都要走一遍完整计算流水线它才是真正消耗计算资源的“货物”。2. 上下文窗口模型的内存边界也是遗忘的根源2.1 窗口里到底装了什么上下文窗口Context Window指的是模型单次请求能够处理的 Token 总量这是一个“同时可见”的上限。很多人把它理解成“模型记住了多少东西”其实不对它更像是“模型当前摊在桌面上能看到多少张纸”。每次你发一个请求给 API它接收的内容包括以下几个部分系统提示词System Prompt用来设定人设和固定规则之前的对话历史每一轮用户问的和 AI 答的都会带上当前这一轮你问的新问题留给模型生成回答的空间这四个部分共享同一个窗口预算。注意最后一条很多人以为窗口只是给输入用的其实模型生成回答也要占窗口空间。你设置的 max_tokens 如果太小模型回答到一半就可能被硬生生截断你如果输入太长、把窗口塞满了模型可能连回答都生成不了或者直接报错。我用一个比较形象的比喻上下文窗口是一张固定大小的会议桌。系统提示词占一块、历史记录占一块、你当前的问题占一块剩下才是放回答的地方。桌子就这么大放不下的时候只能往地上丢东西丢掉的就是你“遗忘”的内容。2.2 会“忘”的三种真相很多人把“模型忘事”归结为模型智力问题其实大部分情况不是记性差而是机制决定的。第一种遗忘是机械性截断。当历史 Token 总数超过窗口上限API 通常的做法是丢弃最早的内容只保留最近的部分。比如窗口是 8K你聊了 20 轮消耗了 12K Token那最前面的 4K 历史就被直接丢弃。这不是“忘了”而是这些内容压根没被送进模型。你一上来聊的东西早就被挤出了会议桌。第二种遗忘是注意力稀释。就算 Token 总数没超窗口内容太多也会坏菜。研究表明模型对长文本中间位置的注意力明显低于开头和结尾这被称为“Lost in the Middle”现象。你把关键信息埋在 100 条历史记录的中间模型大概率在回答时找不到它表现出的效果和“忘了”一模一样。这个现象对 Agent 类应用特别致命任务中间环节的状态信息最容易丢。第三种遗忘是输出挤占。窗口被输入占掉 90%留给输出的空间只剩 10%模型被迫在窗口边界处截断回答后半段直接消失。这也常被误读为“模型记忆力不行”其实是你的输出没地方放了。我实际调试 Agent 时踩过一个典型坑让模型参考一份很长的资料文档大约 6K Token同时塞入三轮对话历史窗口 8K结果每次到第三轮回答就断在中间。查了日志才发现输入已经占了 7.8K输出只剩 200 Token 的空间不截断才怪。之后我把资料文档改成检索后只塞相关片段问题立刻消失。2.3 长上下文窗口不是免死金牌现在各家都在宣传 128K、200K 甚至 1M 的上下文窗口看起来好像再也不用担心“忘事”了实际用起来完全不是那么回事。长窗口贵。窗口越大处理整个上下文的成本就越高长窗口的调用通常比短窗口贵出不少。而且不是只有超出部分才贵是整个输入都要重新计算一遍。长窗口慢。输入越长首 Token 延迟越高。模型必须把全部输入先“读”一遍Prefill 阶段窗口里有 10 万 Token光是读完就要花好几秒。你等得越久体验越差。长窗口还会掩盖架构问题。如果你的应用设计成“把所有东西都塞进上下文”程序确实能跑但每轮都在烧钱、每轮都在变慢最后你会得到一个能跑但根本没法商用的玩具。长窗口的真正价值是让你有更大的缓冲区域去设计更好的记忆策略而不是让你无脑塞东西进去。3. 为什么贵钱到底被什么吃掉了3.1 输入和输出不是统一定价先看一个普遍现象几乎所有 API 的定价都是输出比输入贵一大截。以某主流模型当前公开报价为例具体数字随时变思路不变输入侧大约每百万 Token 几十元人民币输出侧则是每百万 Token 上百元输出单价是输入的两到三倍。为什么这么定价前面提到过输出是逐 Token 自回归生成每生成一个 Token 都要基于整个上下文重新计算一遍计算量远大于处理一个输入 Token。输出 Token 是“生产出来的东西”也是用户真正拿走的价值贵有贵的道理。这个定价结构带来一个反直觉的结论让模型多说废话比让它多读资料更费钱。1000 Token 的回答成本往往相当于读入 3000 Token 的资料。所以在设计提示词时除了控制输入长度控制输出长度同样重要。很多产品喜欢让模型输出“详细的步骤”“全面的说明”这些漂亮话每一段都在烧钱。3.2 多轮对话的复利陷阱越聊越贵的原因这是最常见也最容易被低估的成本放大器。很多人以为多轮对话是“每次发一句话”费用应该差不多实际上完全相反。因为 API 本身是无状态的每次请求你都得把全部历史重新发一遍。假设单轮对话平均消耗 1.5K Token输入 1K输出 0.5K我们算一算累积量对话轮数第 N 轮请求的 Token 量累计消耗 Token第 1 轮1.5K1.5K第 5 轮约 7.5K约 22.5K第 10 轮约 15K约 82.5K第 20 轮约 30K约 315K看懂这个表的逻辑了吗第 20 轮时单次请求就要发送约 30K Token其中 28.5K 都是重复的历史。累计消耗 315K Token但真正“有用”的新内容只有 30K90% 的钱花在了重复计算历史上。这就是为什么你感觉“没聊几句账单却爆炸”。我见过一个实际案例某内部测试的对话机器人用户平均会话长度 25 轮后台统计下来单日 Token 消耗中历史重复发送占比超过 80%。做了历史压缩之后同样用户规模的 Token 成本直接砍掉三分之二。在 AI 应用里多轮对话的成本优化空间往往比模型选型还大。3.3 长窗口的预填充为什么供应商卷窗口反而要注意“上下文窗口 128K”听起来很爽但用长窗口是有隐性成本的。每次请求模型都要先把全部输入处理一遍这个阶段叫预填充Prefill预填充的耗时和成本大致随输入长度线性增长。你想让模型“看到”100K 内容就得先为这 100K 内容付一次全量计算的钱。现在有些平台提供上下文缓存同一段前缀如果多次使用可以复用计算结果能省一部分钱。但缓存一般有有效期命中条件也挺严格前缀必须完全相同差一个空格都可能失效。真正常被命中的也就是 System Prompt 这种固定内容。你把一堆对话历史放进去指望复用缓存基本别指望。所以我建议不要因为供应商送了大窗口就拼命用。长窗口是避险工具不是日常饭票。日常对话优先保持上下文在几 K 到十几 K 的范围需要的时候再临时拉长窗口。用 60% 的窗口预算做缓冲永远比顶着 99% 跑安全也更省钱。4. 实战策略一边省钱一边让模型少忘事4.1 滚动摘要把历史变成一块压缩饼干对付“越聊越贵”和“越聊越忘”的最实用手段就是滚动摘要。思路很简单对话超过一定轮数后让模型把之前的对话总结成一两段摘要下一轮开始用摘要替代完整历史。具体步骤设定阈值比如每聊 5 轮触发一次摘要让模型输出结构化的对话摘要“用户目标、已完成事项、待办事项、关键偏好”后续请求改为System Prompt 摘要 最近两轮原对话 当前问题这样窗口占用从“全部历史”变成“摘要 最近内容”可能把 30K 的 Token 压缩到 3K 以内。摘要带来的一个副作用是细节丢失但多数业务场景要的是上下文连续性而不是逐字记忆这点损失完全可以接受。我在实际项目中会把摘要更新做成异步任务每轮对话结束后不阻塞主流程后台把最近的对话追加到旧摘要里生成新摘要存储起来。下次用户继续对话时直接读取最新摘要全程用户无感。这套流程实施后产品连续对话能力提升明显单用户成本则大幅下降。4.2 外部记忆RAG 只取相关片段不整篇硬塞如果应用需要参考很长的知识库文档别把整篇文档丢进上下文用检索增强生成RAG的方案先把知识库切成小块用向量索引存起来每次用户提问先做语义检索只把最相关的 Top-K 片段塞进上下文。举个例子某知识库文档全文 10 万 Token如果整篇塞进上下文一次调用光输入就要花不少钱。而通过向量检索只取 3 个片段、每个 500 Token总共 1500 Token成本直接降到原来的百分之一同时回答质量更高因为模型不会被 10 万个 Token 的不相关内容分散注意力。这个模式对“多文档对比”“企业内部知识问答”这类场景尤其有效。需要提醒的是切块大小和检索结果数量需要调参块太小语义不完整块太大一样浪费 TokenTop-K 取少了可能漏掉关键答案取多了又烧钱。一般建议块大小 500 到 1000 Token、Top-K 取 3 到 5 个然后根据你的场景微调。4.3 提示词布局利用注意力分布规律让关键信息被记住前面提过“Lost in the Middle”现象模型对长文本的开头和结尾注意力更强中间区域容易被忽略。反过来利用这个规律可以显著改善“记住关键信息”的效果。实操要点系统提示词角色设定、核心规则放在最开头它会被稳定关注当前这一轮的具体任务、目标要求放在请求的最末尾紧挨着生成位置参考资料、不太重要的历史信息放在中间位置如果要引用的关键数字或结论在开头和结尾各提一次双保险这个技巧在调试 Agent 时特别有用。我遇到过很多次模型把工具调用规则忘了症状像是“记忆退化”其实只是因为规则埋在很长的历史中间。把它挪到开头问题立刻减轻。别小看这种“排布学”它不花钱却常常比调整提示词本身更有效。4.4 系统设计层面的省钱清单除了上面的三类招数还有几个系统层面的习惯长期下来能省不少。第一系统提示词保持稳定。如果提示词经常变上下文缓存的命中率会很低把固定不变的 Prompt 放在最前面后面接每次变化的部分命中率能明显提升。第二限制输出长度。max_tokens 设成你真正需要的长度而不是让模型自由发挥。一个 500 Token 就能说清的答案模型自由发挥到 1500 Token成本直接翻三倍还更容易出现废话和幻觉。第三及时开启新会话。对话超过 20 轮后哪怕有摘要上下文质量也在下降。适时给用户“开启新对话”按钮或者系统检测到上下文过载时自动清理历史是对用户体验和成本的双重保护。第四对 Token 消耗做计量。在客户端或服务端统计每个请求的 Token 数、每用户每天的平均消耗设置异常告警。很多人不是不想优化成本是压根不知道钱花在哪有了计量才有优化的起点。5. 常见问题排查与避坑记录5.1 为什么窗口明明没满回答却被截断查了几种原因。最常见的是输出空间没留够。max_tokens 设太小模型生成到一半就触及上限于是硬停。另一个原因是 API 内部会预留一部分 Token 作为输出空间你在界面上看到的窗口大小和实际可用输入大小不是同一个值。比如窗口 8K某些服务实际允许的输入可能只有窗口的一半多一些。排查方法看 API 返回的 finished_reason 字段如果是 length 而不是 stop说明是被长度截断把 max_tokens 调大或者缩短输入给输出腾地方。5.2 为什么同样的文本两次计费 Token 不一样理论上同一款分词器对同一段文本的 Token 化结果是确定的。但实际中你会发现变化常见原因是文本细节变了可能是多了个空格、换行符或者引号变成了全角。中文尤其敏感全角逗号和半角逗号的 Token 结果可能差出几个 Token。还有的 API 会自动在文本前面附加一段隐藏的元描述或不需要的格式标记。所以精确对比成本时不要靠肉眼数长度直接本地用同一版本的分词器数一遍 Token结果最可靠。5.3 为什么窗口越大的请求首 Token 越慢这是 Prefill 阶段的必然结果。窗口越大、输入 Token 越多首 Token 延迟越高用户感受到的就是“模型反应变慢”。如果你的应用对延迟敏感比如聊天机器人要快速回话宁可多用几个短请求也不要一个超长请求。短请求的 Prefill 总时间和长请求相比往往更低何况还能省 Token。5.4 避坑速查表症状根源对策模型忘了早期对话历史被截断 / 注意力稀释滚动摘要、RAG、关键信息置顶账单越聊越贵每轮重复发送全部历史压缩历史、开启新会话、启用缓存回答一半断了max_tokens 太小 / 窗口被输入挤占调大 max_tokens、压缩输入长上下文请求很慢Prefill 阶段处理大量输入减少单请求输入量、拆分请求同样的文本计费不同文本细节变化 / 隐藏附加内容本地 Tokenize 核对这个表我建议直接贴在项目文档里团队里无论谁在处理上下文问题时先对照一遍能省下不少排查时间。我自己的体会是Token 和上下文窗口这两个概念理解起来不难难的是把它内化成工程直觉。做项目的前期我也经常“能用就行”结果账户账单一旦拉出来再回头改架构改造成本比一开始就设计好要高得多。现在每接手一个新项目我会先问一个问题这个产品的对话历史到底需要保留多少能不能压缩能不能检索想清楚这三件事后面的费用和体验问题基本就解决了一大半。最后再分享一个小技巧在开发时把 Token 计数直接打在每一轮请求的日志里肉眼就能看到每次调用在不同阶段的消耗比事后看账单直观得多。等这个数据积累起来你会发现哪些功能是吃 Token 的大户、哪些提示词在慢性放血顺着数据改成本下降是水到渠成的事。Token 和上下文窗口管理没有太多玄学无非是把“模型看到什么”这件事重新捡起来管好输入、压缩历史、分清主次省下来的每一分钱都是利润。希望这篇整理对你有用有问题可以去评论区聊聊你踩过的坑正好我也在收集各种奇怪场景。
阅读完成 · 觉得有帮助？
