1. 从“一句话烧掉 40 万 Token”说起这钱到底花在哪了第一次看到“一句话烧掉 40 万 Token”这个说法我下意识以为是标题党。直到我自己拿一段带完整上下文的对话去跑了一遍长文本模型账单出来那一刻我才明白这句话一点都不夸张。你随口问一句“帮我把这份合同的风险点梳理一下”如果这份合同是几十页 PDF加上系统提示词、历史对话、工具调用返回结果一次请求消耗几十万 Token 是家常便饭。所以这篇东西我想把 Token 这个词从里到外讲透。它到底是什么、怎么被切出来的、为什么中文比英文更“费”、为什么同样一句话在不同模型上价格差好几倍、以及在实际项目里怎么把 Token 用量压下来。不管你是刚接触大模型 API 的开发者还是做 AI 产品、算成本、调提示词的从业者这篇都能直接拿去用。核心关键词就几个Token、词元、BPE、GPT-4o、DeepSeek我会围绕它们把整条链路串起来。先说结论方便你带着框架往下读Token 是大模型处理文本的最小计费和处理单位它不是字也不是单词而是介于两者之间的一种“子词片段”。模型看不懂汉字也看不懂英文字母它只认一串整数 IDToken 就是文本和这串整数之间的桥梁。你付的钱、你占的上下文窗口、你触发的限流全都是按 Token 算的不是按字数算的。很多人第一次踩坑是拿“字数”去估算 Token。中文里一个字大约对应 0.6 到 2 个 Token 不等英文一个单词大约 1.3 个 Token代码和标点符号的消耗又完全是另一套逻辑。你按字数拍脑袋估成本最后账单能差出两三倍。这就是为什么我坚持要把 Token 的切分原理讲清楚——不理解切分你永远算不准账。2. Token 到底是什么把文本翻译成模型能吃的“整数”2.1 从“字”和“词”之间找一个平衡点人类读句子是按词和语义走的计算机早期做自然语言处理最朴素的做法是按空格切词。英文还好空格天然分词但中文没有空格按字切又太碎按词切又需要词典且永远覆盖不全遇到新词、网络用语、专业术语就歇菜。于是业界转向了**子词subword**方案核心思想是常见词整块保留罕见词拆成更小的片段最终保证任何文本都能被切成一串有限的、可枚举的单元。这个单元就是 Token中文常译作“词元”。你可以把它理解成乐高。整块的大积木是高频词比如 “the”“data”“模型”小颗粒是词根、词缀、单个汉字、标点。模型不关心你拼出来的是不是一个“正经词”它只关心这串积木的 ID 序列能不能稳定地表示你的输入。这样做的好处是词表规模可控通常几万到十几万又能覆盖几乎无限的新组合。2.2 BPE最主流的切分算法原理其实很朴素热词里的 BPE 就是 Byte Pair Encoding字节对编码。它的训练逻辑简单到有点反直觉从单个字符或字节开始统计语料里哪两个相邻单元出现频率最高就把它们合并成一个新单元重复这个过程直到词表达到预设大小。举个极简例子假设语料里 “low” 出现很多次初始是 l、o、w 三个字符训练中 “l”“o” 高频合并成 “lo”再和 “w” 合并成 “low”。最终 “low” 就成了一个 Token而 “lower” 可能被切成 “low”“er”。这套机制决定了 Token 的切分结果高度依赖训练语料。英文语料多常见英文单词往往一个 Token 搞定中文语料相对少很多汉字和词组会被拆得更碎。这就是为什么同样意思的一句话中文的 Token 数经常比英文多。GPT-4o 用的是一种改进的 BPE 变体DeepSeek 系列也基于 BPE 思路做了自己的词表和优化具体词表大小和切分规则各家不同所以同一个句子在不同模型上的 Token 数会有差异。2.3 一个必须记住的换算直觉我给自己总结了一套粗略但好用的换算直觉日常估成本够用了文本类型大致 Token 换算说明英文普通文本1 词 ≈ 1.3 Token常见词多为 1 Token中文普通文本1 字 ≈ 0.6~1.5 Token高频字可能 1 Token生僻字拆成多字节代码1 行 ≈ 10~30 Token缩进、符号、变量名都算JSON/结构化数据1 字符 ≈ 0.3~0.5 Token括号引号冒号消耗大纯标点/特殊符号1 个 ≈ 1~3 Tokenemoji、罕见符号尤其贵注意这只是估算真实值必须用对应模型的 tokenizer 实测。GPT-4o 和 DeepSeek 的词表不同同一段中文切出来的 Token 数可能差 20% 以上。3. 为什么一句话能烧掉 40 万 Token上下文才是真正的吞金兽3.1 一次请求的 Token 由四部分组成很多人以为“我发一句话”就只算这一句其实一次 API 调用的计费 Token 是输入 输出的总和而输入往往是大头。拆开看系统提示词System Prompt你给模型设定的人设、规则、格式要求每次请求都要重新带上长提示词动辄几千 Token。历史对话Context多轮对话里之前所有轮次的内容都会作为上下文重新发送轮次越多累积越恐怖。工具/检索返回RAG、Function Call你挂的知识库、搜索结果、数据库返回全部塞进上下文。用户当前输入 模型输出这才是你以为的“一句话”。所以“一句话烧 40 万 Token”的真相是那“一句话”背后拖着几十页文档、几十轮历史、一堆工具返回。模型每回答一次都要把这些全部重新读一遍。这就是上下文窗口的代价。3.2 上下文窗口和计费的关系上下文窗口Context Window指的是模型单次能处理的最大 Token 数比如 128K、200K。注意这个窗口是输入 输出共享的。你输入塞了 120K输出最多只剩 8K。而且很多模型对超长上下文是分段计费的超过某个阈值后单价上浮。GPT-4o 和 DeepSeek 在长上下文定价策略上就有明显差异DeepSeek 在缓存命中场景下价格优势非常突出这也是它在技术社区里被反复讨论的原因之一。我实测过一个典型场景一份 60 页的中文合同约 8 万字切出来接近 12 万 Token。加上系统提示词 2000 Token、三轮历史对话 5000 Token一次请求输入就接近 13 万 Token。如果模型输出 3000 Token总消耗 13.3 万。你要是连续追问五轮每轮都重发全部上下文累计轻松突破 40 万。这就是标题那句话的真实来源。3.3 缓存机制省钱的隐藏开关现在主流厂商都提供了上下文缓存Prompt Caching。原理是把重复的、不变的前缀部分缓存起来下次请求命中缓存时按更低价计费。系统提示词、固定文档、长历史里不变的部分都是缓存的最佳对象。DeepSeek 的缓存命中价格和未命中价格差距很大用好了成本能砍掉一大截。实操建议是把稳定不变的内容放前面变化的内容放后面这样缓存命中率最高。这个细节很多人不知道白白多花了钱。4. 不同模型的 Token 账本GPT-4o 与 DeepSeek 的实操对比4.1 词表差异带来的真实影响我拿同一段中文技术文档分别在 GPT-4o 和 DeepSeek 的 tokenizer 上跑过结果差异明显。原因在于两者词表构建的语料配比不同GPT-4o 的英文和代码覆盖更强DeepSeek 对中文的优化更充分。这意味着同一份中文内容在 DeepSeek 上往往 Token 数更少叠加单价差异成本差距会被进一步放大。反过来纯英文和代码场景GPT-4o 的切分可能更经济。这给我们的实操启示是不要用 A 模型的 Token 数去估算 B 模型的成本。选型阶段一定要拿你自己的真实业务文本在两个模型的 tokenizer 上各跑一遍拿到真实 Token 数再算钱。我见过团队直接拿网上的“1 汉字 1 Token”去报价最后预算超了一倍。4.2 计费维度对比维度GPT-4o 类DeepSeek 类输入计费按输入 Token按输入 Token缓存命中更便宜输出计费输出单价通常高于输入同样输出高于输入缓存支持前缀缓存支持命中价优势明显长上下文超阈值加价分段策略不同中文效率一般相对更省 Token提示具体单价随时会调整这里只讲结构不写死数字。你要做预算永远以官方最新价目表为准并且用真实文本实测 Token 数。4.3 选型的三个判断维度我在项目里选模型不看跑分看这三条第一你的文本以什么语言为主中文为主优先考虑中文切分效率高的第二你的调用模式是短问答还是长上下文长上下文场景缓存机制的价值会被放大第三输出占比高不高如果模型输出很长输出单价就是决定性的。把这三条想清楚比盲目追新模型靠谱得多。5. 把 Token 用量压下来的实操方法5.1 提示词瘦身删掉每一个不必要的字系统提示词是每次请求都重复的固定成本它值得你反复打磨。我常用的手法把“请你务必一定要认真地”这类客套话全删掉只留规则和格式约束能用短句不用长句能用一个词不用一句话。一个 3000 Token 的系统提示词压到 1500 Token在每天十万次调用的量级下省下的钱非常可观。别小看这几百 Token乘以调用量就是真金白银。5.2 历史对话的裁剪策略多轮对话不能无限累积。我的做法是保留最近 N 轮原文更早的轮次做摘要压缩。摘要本身也要花 Token 生成但一次性生成后可以长期复用比每轮重发原文划算得多。另一种做法是只保留与当前问题相关的历史片段用检索的方式挑出来而不是全量带上。这两种策略我在不同项目里都用过长对话场景下能砍掉 50% 以上的输入 Token。5.3 RAG 检索的精准度直接决定成本检索增强生成RAG最容易失控的地方是召回太多无关内容。你召回 20 个片段可能只有 3 个有用剩下 17 个全是白花的 Token。我的经验是把召回数量压到刚好够用同时提高切分和排序质量。宁可多花点算力做重排序也不要把一堆垃圾塞进上下文。检索质量每提升一点Token 成本就降一点这是正相关的。5.4 输出长度控制输出 Token 通常比输入贵所以控制输出长度是省钱的关键。方法包括在提示词里明确要求“简洁回答”“不超过 X 字”用结构化输出JSON替代大段自然语言对不需要解释的场景直接要求只给结论。我做过对比同一个任务加了输出长度约束后输出 Token 平均下降 40%而且可读性反而更好因为废话少了。6. 常见问题与排查技巧实录6.1 Token 相关的高频疑问速查问题现象可能原因排查方向账单远超预估按字数估了 Token用 tokenizer 实测真实 Token 数中文特别费词表中文覆盖弱换中文优化更好的模型长对话越来越贵历史全量重发做历史裁剪或摘要缓存没生效变化内容放在了前面稳定内容前置变化内容后置输出被截断输入占满上下文窗口压缩输入或换更大窗口模型同一句 Token 数不同模型词表不同分别用各自 tokenizer 实测6.2 我踩过的几个坑第一个坑是拿字符数当 Token 数。早期做预算时我按“1 汉字 1 Token”算结果中文技术文档实际接近 1.5预算直接爆掉。第二个坑是忽略输出计费。有次做长文生成输入没多少输出每篇几千 Token成本全在输出上。第三个坑是缓存没配对。我把用户每次变化的问题放在了提示词最前面导致缓存永远不命中白白多花钱。后来把固定规则前置、变量后置缓存命中率一下就上来了。6.3 一个实用的自查流程每次上线新功能前我会做一遍 Token 自查先用真实样本跑 tokenizer 拿到输入输出 Token 数再乘以预估调用量算出日成本然后检查缓存策略是否合理、历史裁剪是否到位、输出约束是否生效。这套流程走下来基本能避免上线后账单失控。别嫌麻烦等账单来了再查就晚了。7. 关于 Token 的几个延伸认知7.1 Token 不只是计费单位Token 还决定了模型的能力边界。上下文窗口多大模型一次能“记住”多少信息就多大Token 切分方式直接影响模型对中文、代码、专业术语的理解粒度。同一个词被切成不同 Token模型学到的表示就不一样。所以理解 Token其实是在理解模型的“感知分辨率”。7.2 本地部署场景下的 Token热词里出现了不少本地部署相关的内容比如用 vLLM 部署 DeepSeek、用 LM Studio 加载模型。本地部署虽然没有按 Token 计费的账单但 Token 依然重要它决定显存占用、推理速度和上下文上限。Token 数越多KV Cache 越大显存吃得越狠。所以本地部署时控制 Token 用量同样是在控制硬件成本。7.3 给不同角色的建议如果你是开发者先把 tokenizer 用起来别靠猜如果你是产品经理把 Token 成本纳入功能设计长上下文功能要单独评估如果你是做预算的记住输入输出都要算缓存能省一大笔。Token 这个词看着小但它贯穿了大模型应用的整条成本链和技术链搞懂它很多问题会豁然开朗。我个人在实际项目里的体会是Token 管理本质上是一种“上下文预算管理”。你手里的上下文窗口就是预算系统提示词、历史、检索、用户输入、模型输出都在抢这笔预算。谁抢得多谁就贵。把预算分配想清楚比事后优化账单有效得多。最后再分享一个小技巧每次调完提示词顺手跑一遍 tokenizer 看数字变化养成这个习惯你对成本的敏感度会肉眼可见地提升。