上下文长度、Token 预算和接口费用到底怎么算？
上篇我们聊了中英文 Token 数量为什么不一样——同样的意思，中文要比英文多用不少"颗粒"。但光知道这个还不够。
问题是：这些颗粒怎么变成账单上的数字？你每个月付的 AI 费用，到底是怎么算出来的？
今天把这事彻底讲清楚。
Token 是什么？模型是这样"吃"文字的
先说个基本概念，免得你听到"按 Token 计费"就一脸懵。
Token 不是字，也不是词。它是大模型处理文本的最小单位。模型不是一个个读汉字的，而是一块块"吞"的。
英文怎么切？通常一个单词算 1-2 个 Token。比如 "Hello" 是一个，"World" 也是一个。但如果是 "running"，模型可能切成 "run" + "ning"，变成两个。
中文呢？更费颗粒。一个汉字大约等于 1.5-2.5 个 Token。你说四个字 "今天天气好"，可能就被切成七八个颗粒了。
同等语义的内容，中文消耗的 Token 比英文多 50% 到 100%。这就是为什么同样的对话，中文用户往往比英文用户付更多钱。
我之前用英文和中文分别让 Claude 写同一封商务邮件，中文版本的价格大概贵了 60% 左右。一开始我还以为是汇率问题，后来才搞明白是 Token 消耗的差异。
所以下次觉得 AI 账单贵，先看看自己说的是不是中文。
上下文长度——模型的"胃容量"有多大
搞懂 Token 之后，你可能还有疑问：模型能处理多长的对话？
这个限制叫"上下文长度"。你可以理解成模型一顿饭能吃多少东西。
128K 上下文是什么概念？大约能放 16 万汉字。你写一篇中篇小说塞进去，模型都能一口气读完。Gemini 1M 的上下文呢？125 万 Token，将近 150 万汉字，够塞进去好几本书了。
但问题来了：输入加输出都算在上下文里。
你发了 1000 个 Token 的 Prompt，模型回了 500 个 Token，这就算用了 1500 个 Token。如果对话历史很长，每次请求都要把之前的内容再传一遍——这些历史 Token 全都要计费。
对话越久，费用越高。而且一旦超过上下文上限，你就得截断或者开新对话，之前的上下文全丢了。
这就像自助餐的用餐时间限制。在这个时间内你能吃多少都行，但时间一到，对不起，下一顿重新开始。
我之前用 Kimi 处理一份长报告，跑到第8轮对话的时候突然发现模型"失忆"了——之前讨论的内容全忘了。后来才搞明白是上下文长度超限了，不得不重新开始。
费用怎么算？输入和输出不是一个价
终于到正题了：钱到底怎么算？
有个公式你得记住：
费用 = 输入 Token 数 × 输入单价 + 输出 Token 数 × 输出单价
但这里有个坑：输入和输出的价格不一样。
大多数模型，输出价格是输入的 3 到 5 倍。为什么？因为生成内容比读内容更费算力。模型要一个字一个字地"想"出来，比直接读要慢得多。
举个好理解的例子。视频通话怎么收费？你的说话费乘以你说的时间，加上对方的说话费乘以对方说的时间。
AI 对话同理。你输入一段 Prompt 算一次费，模型输出的每个字也要算钱。
更扎心的是：多轮对话会越来越贵。
每次对话都要带上之前的聊天记录。聊 10 轮之后，你发的请求可能包含了几千个历史 Token。这些 Token 全都要付费。
我上个月接了个项目，用 GPT-4 做对话式编程助手。项目做完了才发现，光是测试调试阶段的对话费用就花了快 200 块——那些反复的历史记录真是烧钱大户。
所以长对话的账单增长不是线性的，是指数级的。
长上下文的"隐藏费用"
你以为买了个 128K 上下文的模型就万事大吉了？未必。
有些模型会玩"超量加价"这一套。
比如某个模型，你用超过 272K Token 之后，输入价格直接翻倍。超过 1M？输出价格乘以 1.5。这就好比出租车的里程费，过了某个临界点，单价直接跳档。
但也有良心的。Claude 从 2026 年开始全窗口统一价，不管你用多少都是一个价。这种策略对需要处理长文本的用户就友好多了。
所以选模型的时候，别光看基础价格。超过某个长度之后怎么收费，这个才是关键。
有时候便宜 30% 的模型，因为超量加价，用起来反而更贵。
选型之前，把各家的超长上下文定价表拿出来对比一下。这钱花得值不值，细节里全是门道。
省钱实战——从 128K 到 1M 的优化策略
好了，道理都懂了。接下来聊点实在的：怎么少花钱？
第一招：滑动窗口，别让对话无限膨胀。
简单说就是保留关键对话，丢弃冗余历史。比如聊了 50 轮之后，把前面的总结成一段话，删掉原始记录。这样每次请求的 Token 数就控制住了。
我现在做长项目都是这么干的——每隔20轮左右让 AI 总结一下之前的要点，然后开启新一轮对话。省下来的 Token 费用挺可观的。
第二招：缓存命中，有些 Token 可以打折。
系统提示词在多轮对话里是重复的。有些 API 服务商会做缓存命中——同样的内容第二次用，价格直接打折扣。Kimi 这类国产模型缓存命中率能做到 90%，省下的钱很可观。
第三招：Batch API，不着急的任务用批量模式。
你要是需要处理一批文档，不用实时返回结果，走 Batch API 价格能打三折到一折。适合数据分析、批量翻译、内容审核这类不赶时间的任务。
我之前有个需求，需要让 AI 给 500 篇产品文档打标签。如果用实时 API，光费用就得好几百块。后来换成 Batch 模式，费用降到了原来的两折都不到。
第四招：模型分层，简单任务别用大炮。
写封邮件、问个简单问题，用 7B 的小模型完全够用，而且便宜几十倍。只有真正复杂的编程、推理任务，才动用 GPT-5、Claude 3.5 这种大块头。
打个比方：旅游预算怎么分配？背包客住青旅省钱，土豪住五星不心疼。聪明人知道什么时候该省钱、什么时候该享受。
AI 用钱也是这个道理。
选型三步法——找到最适合你的模型
那具体怎么选？
第一步：明确任务类型。
是写代码？长对话？还是偶尔问答？不同任务对上下文和模型能力的要求不一样。先想清楚自己要干什么。
第二步：上评测站验证。
别光听厂商吹。SWE-Bench 测编程能力，Artificial Analysis 这类平台能对比多家模型的实际表现。跑几个你的真实任务样本，比看广告靠谱多了。
我选模型之前都会先在几个测试任务上跑一遍，看实际效果和费用。有些模型跑分很高，但实际用起来效果一般，这种坑踩过不少。
第三步：算清楚成本。
Token 单价乘以你预估的用量。有些模型基础价格贵，但超量不加价；有些模型便宜，但用多了单价飙升。结合自己的使用场景算总账。
买车前先想好要越野还是通勤，再看测评，最后算油费。选 AI 模型也是同样的逻辑。
Token 和上下文，这些概念会影响什么？
写到这你已经知道了 Token 怎么算、上下文怎么管、费用怎么控。
但这只是基础。
Token 的切分方式、上下文的长度限制，这些会对实际应用产生更深远的影响。你写的 Prompt 要多短才有效？RAG 要不要做分块优化？长文本处理有什么技巧？
这些问题的答案，都跟今天的知识有关。
下篇我们就来聊聊：Tokenization 对 Prompt、RAG 和长文本处理有什么影响？