1.1 Token 是什么与计费模型拆解

1.1 Token 是什么，以及它的计费模型到底怎么算

读完这一节，你应该能用一句话说清楚：「大模型账单上的每一分钱，都是按 Token 的个数，再乘以每个 Token 的单价算出来的——而 Token 既不是字、也不是词，而是一种被分词器切碎后的计费单位。」

很多团队第一次看到大模型账单时都会有一个错觉：我明明只发了两句提示词，怎么扣了八千个 Token？问题就出在「Token 到底是什么」这件事上。这一节我们不做教科书式的定义堆砌，而是从「你打开账单那一刻的困惑」倒推回去，把 Token、计费模型、以及那些最容易让人多花钱的隐藏项，一个一个拆开讲透。

一、Token 不是字，也不是词：它是被分词器切碎的「计费原子」

先说结论：在自然语言处理里，Token 是模型处理文本的最小单位，但它和我们能看见的「字」或「词」没有一一对应的关系。不同的模型用不同的分词器（tokenizer），切出来的 Token 数量差异很大。

以英文为例，单词「understanding」在 GPT 系列的分词器里通常被切成「under」「stand」「ing」三个 Token；而中文因为没有天然的空格分词边界，处理方式和英文不同——中文更多是「按字或按子词」切分。根据 OpenAI 官方给出的经验口径，中文 1 个汉字通常约等于 1 到 2 个 Token（常见经验值是 1 个汉字≈1 个 Token，但带标点或复合语义时可能更多）。这就是为什么你写一段 2000 字的中文，账单上可能显示 2200~3000 个 Token。

这里有个容易被忽视的坑：同一个意思，不同的写法，Token 数完全不同。下面这张对比图能直观说明问题。

这不是让你去「省字写作」——正文该写清楚还得写清楚。但它说明了一件关键的事：Token 数量由「模型怎么切」决定，而不由「人怎么读」决定。理解这一点，你才会明白后面的缓存策略为什么有效：缓存命中的本质，是「同样一段 Token 序列不再被重新计算、重新计费」。

二、一次调用到底算了哪几笔 Token：输入、输出、还有「隐性」部分

很多人以为「调用一次模型 = 输出多少字就付多少钱」，这是第二个大误会。一次完整的对话补全（completion）调用，账单通常包含以下几块：

• 输入 Token（Prompt Tokens）：你发给模型的所有内容，包括系统提示词、对话历史、用户本轮问题、以及你可能塞进去的检索片段（RAG 的上下文）。
• 输出 Token（Completion Tokens）：模型生成回来的内容，通常单价高于输入。
• 推理/思考 Token（Reasoning Tokens）：部分支持「思考链」的模型（如 o 系列等），会在内部消耗额外的 Token 用于推理，这部分也会计费，且常常比最终答案长得多的多。
• 其他隐藏成本：例如某些平台对「缓存写入」「缓存读取」单独计价；多模态模型里图片会被折算成若干 Token；函数调用（tool call）的参数往返同样计费。

我特意把「检索召回的上下文」标成最大的一块，因为它是一个隐蔽的成本黑洞：当你给模型塞了 30 篇文档当上下文，哪怕模型只用了其中 1 篇，那 30 篇的 Token 全都按输入计费。这正是后续「请求缓存」和「智能路由」要解决的问题之一——要么让重复检索不再反复计费，要么把简单问题路由到便宜的小模型，别用大模型去处理本可以用小模型搞定的事。

三、计费模型的数学表达式：把直觉变成公式

为了让后面的成本优化有「可计算的抓手」，我们把账单抽象成一个公式。设一次调用：

成本 = 输入 Token 数 × 输入单价 + 输出 Token 数 × 输出单价 + 推理 Token 数 × 推理单价 + 缓存相关项

如果是多轮对话，且每轮都把历史拼回去，那么第 N 轮的输入 Token 数会随轮次线性增长。设单轮新增输入为 a，输出为 b，则前 N 轮累计输入 Token 约为 a×N + b×(N−1)，输出累计为 b×N。这就是「长对话越聊越贵」的数学来源。

从公式能直接推出四条降本路线，后面章节会逐一展开：

1. 降 Q（请求量）：用缓存挡掉重复的请求，让「相同问题」不再真正打到模型。
2. 降 T（单调用 Token 数）：压缩提示词、精简上下文、去掉冗余历史。
3. 降 P（单价）：把简单任务路由到便宜模型，只在必要时用贵模型。
4. 提命中率：这是降 Q 的核心指标，也是第三章要专门建模的对象。

四、计费模式不止一种：按 Token、按时长、按请求包

除了最常见的「按 Token 数计费」，工程上你还会遇到几种变体，做成本治理时必须先认清自己属于哪一种：

• 纯 Token 计费：绝大多数公有云 API 采用，上文公式即适用。
• 包月/包量套餐：平台给一个固定额度的 Token 或请求数，超出另算。此时缓存的价值从「直接省钱」变成「避免超额降速或超量付费」。
• 按实例/时长计费：私有化部署或自建推理服务时，成本主要来自 GPU 工时，Token 计费退居其次，此时降本重点是「提高吞吐、减少空闲」。
• 分级定价：同一模型按「实时/批处理」给出不同单价，批处理更便宜但有延迟，适合离线任务。

五、一个必须建立的直觉：缓存为什么能「直接砍单价」

回到公式。假设你的系统每天有 10000 次调用，其中 4000 次是高度重复的同类问题（例如「怎么重置密码」「营业时间几点」）。如果不做缓存，这 4000 次每次都完整计费；如果做了语义缓存，命中后可能只按「缓存读取」的低价计费、甚至不计模型推理费。那么：

原成本 = 10000 × T × P
加缓存后 ≈ (6000 × T × P) + (4000 × T × P_read)，其中 P_read ≪ P

当命中率到了 40%，账单可能直接降三成以上。这还只是一个保守估计——在检索类（RAG）场景里，上下文 Token 动辄几千，缓存命中省下的远不止三成。「缓存命中率」是降本的杠杆支点，而它正好是后面第三章要精密建模的核心指标。

六、给工程师的实操清单（这一节你可以马上做的）

读到这里，你已经具备成本意识的基本盘。现在可以做几件零成本的小事，为后续系统化治理铺路：

1. 先把账单拉出来看分布：哪类调用最频繁？Token 中位数多少？有没有「超长上下文」的异常调用？没有数据就没有优化方向。
2. 给每次调用打标签：在日志里记录「用了哪个模型、输入/输出 Token 数、是否命中缓存」。这是后面做成本模型的最小必要字段。
3. 区分「必须精准」和「可以近似」的请求：前者才需要大模型，后者是路由到小模型或缓存的候选。
4. 警惕推理 Token：如果用了带思考链的模型，先看一眼推理 Token 占比，很多时候它比答案本身还贵。

七、不同提供商的计费口径，别用一家经验套另一家

虽然「按 Token 计费」是行业共识，但落到具体平台，口径差异足以让你的成本预估偏差数倍。举几个需要警惕的点：

• 系统提示是否重复计费：有的平台把「系统提示词」在每一轮对话里都重复计入输入 Token；有的平台对长系统提示提供「预缓存（prompt caching）」，命中后单价大幅下降。如果你没开启预缓存，一个 2000 Token 的系统提示在 100 轮对话里就是 20 万 Token 的输入开销。
• 推理 Token 是否单独计价：有的平台对「推理 Token」单独计价且价格不低；有的平台把推理过程对用户隐藏、只按最终输出计费。前者成本更容易失控，做预算时必须单列。
• 多模态折算规则不同：图片折算成多少 Token 各平台不同，通常按分辨率和压缩档位换算，一张高清图可能顶几百个文本 Token。
• 函数调用的往返计费：模型输出的「调用参数」和「工具返回结果」都会往返计费，工具返回过长会悄悄推高账单。

因此，1.1 建立的公式要「本土化」：先去读你所用平台的计费文档，把「哪些部分单独计价、是否有预缓存折扣」填进公式，再谈优化。这也是本教程反复强调「建议结合官方文档核实」的原因——我不替你编造某个平台的精确单价。

八、一个手算示例：把公式真正跑一遍

假设你运营一个客服助手，使用某按 Token 计费的模型，大致单价（仅为示意，非真实报价）：输入 0.01 元/千 Token、输出 0.03 元/千 Token、推理 0.02 元/千 Token。一个典型「查询订单」对话：

• 系统提示 + 检索上下文：输入 1800 Token
• 用户问题：输入 120 Token
• 模型推理：400 Token
• 模型答案：输出 300 Token

单次成本 ≈ (1800+120)/1000×0.01 + 400/1000×0.02 + 300/1000×0.03 ≈ 0.0192 + 0.008 + 0.009 = 0.0362 元。

如果一天有 5000 次这类查询，日成本约 181 元，月成本约 5430 元。现在设想：其中 40% 是高度重复的「订单到哪了」类问题，若用语义缓存命中，命中部分只产生极低的缓存读取费（约原输入费的 1/10），那么月成本可降至约 3500 元出头，省下近 35%。这一个例子就说明了：降本不是玄学，是可算的。

九、流式输出、重试、并发：三个容易被忽略的账单放大器

• 流式输出不省钱：很多人以为「用流式（stream）就少计费」，其实流式只是把输出分片传回，Token 总数不变，费用不变。它提升的是体验，不是账单。
• 重试是隐形吞金兽：网络超时后客户端自动重试，每次重试都重新计费。如果重试逻辑没做幂等和缓存，一次用户请求可能在后台烧了三次钱。1.2 的「止损扫描」第一个就要查它。
• 并发放大瞬时成本：做批量任务时为了快开高并发，单看每次调用不贵，但总量瞬间放大，容易撞上平台的「突发限流」或「超额阶梯价」。批处理档位 + 错峰，往往比硬并发更划算。

小结：本节你带走了什么

• Token 是分词器切出来的计费原子，不等于字数；写法不同，Token 数不同。
• 一次调用计费 = 输入 + 输出 + 推理 + 隐藏项（缓存读写、多模态、工具调用），RAG 的上下文是最容易被忽视的大头。
• 成本公式是 Q × T × P，由此推出四条降本路线：降量、降 Token、降单价、提命中率。
• 缓存命中的本质是「同样的 Token 序列不再重复计费」——这是整套教程的支点。
• 动手前先建数据：拉账单、打标签、分请求类型。

下一节（1.2）我们不再谈抽象模型，而是把目光对准你的真实账单，找出那「成本最高的 10 类请求」——它们才是缓存与路由最该优先下手的地方。