用 AI 按量付费，账单上的单位是 token，不是"字"。第一次看账单的人常会疑惑：明明写了一千字，怎么按一千多 token 收费。原因在于大模型处理文本的方式：它不按字读，而是先把文本切成小块，每个小块是一个 token，计费和上下文长度限制都按这个单位算。搞懂切分逻辑，钱花在哪、能省在哪就都清楚了。
切分机制：从文字到 token
可以把分词器想成一台切块机：你发送一句话，它先把句子切成若干词块，每个词块对应一个编号；模型处理的从头到尾都是编号序列，回答时逐个 token 生成，最后拼回文字。你输入的提示词、上传的文档、它返回的答案，全都走这条路径，没有任何一段文本能绕过切分直接被模型"阅读"。
切分规则由各家的分词器决定，同一句话在不同平台切出来的数量可能不一样。这也是跨平台比价时容易忽略的一点：单价低不等于总价低，还要看切出来的 token 数量。
为什么不按字收费？因为模型内部处理的是编号序列，切分后做批量计算效率更高，这是工程上的选择，不是刻意把账算复杂。对使用者的含义是：切分粒度决定同样文字的实际开销，粒度粗的平台同样的内容 token 更少，这也解释了为什么不同平台的账单对不上。
中英文的用量差异
英文里一个常见单词往往就是一个 token；中文通常一个字要占一个多 token，同样的内容，中文消耗一般比英文多。粗略估算，一段几百字的中文通常在几百到上千 token 之间，这个量级够用来判断账单合不合理；想知道确切数字，用各家官方的 token 计算工具，结果比手算可靠。
输入输出分开计费
输入和输出分别计数，很多平台对输出的定价更高，让它"少废话、直接答"不只是体验问题，也是成本问题。多轮会话还有一个隐蔽开销：历史消息每轮都会重新计入输入，会话越长，每轮的基础开销越大。上下文窗口的限制同样是按 token 数算的，窗口用满就得开新会话，不是想聊多长就聊多长。
| 场景 | 省 token 的做法 | 判断标准 |
|---|---|---|
| 反复贴长文档 | 同一会话内引用原文，或先摘要再追问 | 摘要是否保留了追问需要的字段 |
| 多轮长对话 | 阶段性开新会话，把结论带过去 | 新会话的首答质量是否明显下降 |
| 批量重复任务 | 提示词模板化，删掉客套与重复说明 | 输出格式是否依然稳定 |
表里的三行对应三种最常见的浪费。长文档场景里，很多人每轮都把完整材料重贴一遍，同样的内容被反复计费；更省的做法是让模型先输出固定字段的摘要，后续追问只带摘要。多轮对话场景里，已经确认过的结论可以压缩成几句话，开新会话时随问题一起带上，比拖着全部历史便宜。批量任务场景里，把任务描述写成固定模板，跑一百次就省一百次的客套开销。
token 解释不了的部分
各家的切分方式和定价结构不同，同样的提示词在不同平台的花费可以对不上，比较成本要看官方计费说明，不能只看单价。计费规则也随版本调整，具体数字以官方最新说明为准。
另一个容易被忽略的事实：token 数不等于价值。一次便宜的调用浪费在无效提示上，累积起来比几次贵的调用更费钱。省 token 的前提是答案质量不下降，为了省一点用量把提示词删到模型理解错任务，反而要多花一轮返工的消耗。
token 速查
- 计费单位是 token，不是字
- 中文消耗一般高于英文，量级靠估算、精确靠官方工具
- 输入输出都计费，输出单价通常更高
- 长会话的历史每轮重复计入输入
- 跨平台比价要同时看单价和 token 数
三个常被问到的问题
- 为什么同一句话在不同平台算出的 token 数不一样？：分词器不同。各家训练分词器时用的词表不同，切分粒度就有差异，中文场景差异更明显，以你实际所用平台的计算工具为准。
- 上传的图片和文件也按 token 计费吗？：文本文件通常折算成 token 计入输入；图片、音频等多模态内容多数平台有单独的折算方式，具体换算规则看平台的计费说明。
- 输出长度能不能提前约束？：可以在提示词里要求字数或条目数，模型会尽量遵守，但不是硬性上限，超长或不足都可能出现。重要的格式要求，拿到结果后做一次核对更稳妥。
token 是用量的计量单位，算力也有自己的一套账，FLOPS 这个算力单位讲的正是它；按量使用时服务质量怎么约定，SLA 服务等级承诺用一个例子讲清了责任划分；想把消耗和成本盯清楚，Agent 可观测性的盯法里有对应的监控思路。
