Token计费原理

第一次接API的人常卡在同一件事：明明只写了几行字，账单却像按整段文本收钱。原因是你付的不是字数，是切分后的token。这篇不讲缓存也不讲比价，只把token怎么切、为什么输入输出分开计价、一次调用到底消耗哪几段token讲透，让你拿到用量记录能自己推出钱的来路。

第一次接API的人常卡在同一件事：明明只写了几行字，账单却像按整段文本收钱。原因是你付的不是字数，是切分后的token。这篇不聊缓存也不聊比价，只把token怎么切、为什么输入输出分开计价、一次调用到底消耗哪几段token讲清楚，让你拿到用量记录能自己推出钱的来路。

先建立一个判断：账单是切分结果的函数，不是字符数的函数。所以「我这段中文只写了两百字，怎么比同事那段英文还贵」这种疑问，答案往往在切分方式上，而不在字数上。下面按六节拆开讲，每节都给能直接上手的口径。

你付的不是字数，是切分后的token

模型拿到你的文本后，第一步不是理解意思，而是把文本切成token序列再处理。计价单位就是这个切分结果。汉字、字母、标点、空格各自可能对应一个或多个token，也可能几个字符合并成一个token。你写下的「字数」和模型看到的token数之间没有固定换算率。

• 同一句话在不同模型里的token数可能不同，跨模型比价前要先对齐切分口径，否则比的是两套尺子
• 中文、英文、代码、标点的切分效率差别很大，这解释了同类任务花费为什么不成正比
• 标点和空格不是免费的，尤其结构化文本里它们很占位，别默认它们不算钱
• 想知道某个模型的词表大致怎么切，去 /ai-dict/category/basics 对照基础概念，别凭感觉猜

切分是怎么发生的：从字符到子词

主流做法是子词切分：常见的词整块保留成一个token，生僻词、专有名词、随机字符串会被拆成若干片段，片段再拼回语义。所以切分效率和你文本的「常见程度」高度相关，越接近模型见过的表达越省，越像随机生成的内容越费。

判断标准很直接：文本越规整、越接近自然表达的常见句式，切分越省；越像拼接出来的、无明显语义的串，切分越费。这个标准跨模型都成立，只是程度不同。它不适用的地方在于：如果某模型对某类语言或某类代码做了词表优化，那类文本的切分效率会明显好于同类模型，所以别把一条规律套死所有模型。

切分不是按你的语义直觉走的，是按模型的词表走的；想省钱，先让自己的文本长得像它见过的样子。

输入和输出为什么分开计价

输入是模型读进去的上下文，输出是它生成回来的内容。两者计算成本不同，所以绝大多数按量计价的API会把它们分开标价。读进去可以并行处理，生成回来要一个token一个token地出，输出侧的单位成本通常更高。这就是为什么同样一段长文本，当输入和当输出，价格不一样。

• 输入侧包含你的提示词、历史对话、检索到的资料、系统指令，全都算进去，不是只算你敲的那句话
• 输出侧只算模型真正生成回来的部分，你让它「只回答是或否」，输出就很少
• 系统提示、角色设定、工具描述属于每次都随请求走的固定输入，改了它们等于改了每次的输入成本
• 按次或按订阅计费的产品不拆输入输出，但你仍可用token口径估它内部大概烧了多少

输入token

这次请求里模型需要读完的全部上下文，包括你写的和系统带上的

输出token

模型这次实际生成出来的内容，按生成量累积

固定开销

不随任务变化、但每次请求都出现的输入部分，比如系统提示和工具定义

重复消耗

多轮对话里同一段历史被反复当作输入送进去的那部分

每轮对话都在重新计费上下文

这是新手最容易忽略的一点：多轮对话不是只算新一轮。前面说过的内容，会作为输入再次送进模型，所以越聊越长、越聊越贵，是结构性的，不是模型在偷偷加价。理解这一点，你就能解释为什么「我后面只问了一句」，账单却比第一轮还高。

1. 分清历史里哪些必须带只有当前任务真正依赖的上下文才值得带上，闲聊、试错、被否掉的方案留在会话里就是纯消耗。验证方法：把这段砍掉，任务结果是否明显变差。
2. 把长对话拆成新会话做完一个子任务就开新会话，把结论用一段话带过去，而不是拖着一整段过程。验证方法：对比同任务两次执行的输入token量。
3. 把固定开销单独列出来系统提示、角色设定、工具描述每次都随请求走，属于固定输入。验证方法：在不含任何用户内容的情况下看单次基础消耗。
4. 用工具换算而不是手算想知道某次请求大概多少token，去 /tools/token-price-calculator 换算更直观，比人肉数字符靠谱。

从一段文字推到最终花费的步骤

把一次调用的钱推出来，其实就是四步。难度不在数学，在于别漏项、别把单位口径搞错。很多人算错不是因为公式难，而是因为只算了正文，或者把每千token和每百万token混着用。

1. 数出两段token分别数输入token和输出token，不要加起来算一个总数，因为两者单价不同。
2. 找到两个单价找到该模型当期的输入单价与输出单价。各家单价会调整，不要凭记忆，去 /official-api 按模型核对当时的数字。
3. 各自相乘再相加输入token乘输入单价，输出token乘输出单价，两者相加得到本次调用的大致原价。
4. 补上额外请求重试、被限速后重发、工具调用产生的额外请求都要单独计入，它们不在你最初那一次调用里。

# 伪代码，不是可直接运行的命令\n输入成本 = 输入token数 * 输入单价\n输出成本 = 输出token数 * 输出单价\n单次原价 = 输入成本 + 输出成本\n总消耗 = 单次原价 * (1 + 重试次数 + 工具调用次数)

单位口径必须盯紧。有的按每百万token标价，有的按每千token标价，换算错一位就是千倍偏差。拿到任何一张价目表，先确认它的单位再动手。这个口径对照表在站内各模型的资料页里都会写清楚，去 /official-api 核对当时的数字即可，不要交叉引用别人截图里的旧数字。

为什么你自己算的数常和账单对不上

自己算一遍然后和账单对比，对不上是常态，对上了是巧合。原因基本集中在几个地方，按出现频率排，逐个排查就行，不用怀疑人生。

这里的不适用情况要讲明白：如果你走的是中转渠道，而渠道有倍率或折扣，你按官方单价算出来的只是原价，实际账单还要再过一层换算。这种时候别把自己算的数当最终账单，只能当量级参考。渠道侧的计费口径要到 /sites 看该渠道的说明，具体数字以当期页面为准。

新手该养成的三个记账习惯

与其每次出账后倒推，不如一开始就把记录做在前面。下面三个习惯成本很低，但能让你在账单异常时五分钟内定位到是哪类请求出的问题。

• 在代码里记录每次请求的输入token和输出token，而不是只记调用次数，调用次数在归因时几乎没用
• 给固定开销（系统提示、工具描述）单独建一项，它不随任务变化但一直在花钱，是最容易被忽略的持续支出
• 设置预算告警，跑飞时先看是哪类请求超量，再决定收窄提示词、历史还是并发，而不是一上来就换模型
• 给多轮会话设长度上限，到阈值就主动总结压缩，别让历史无限滚下去
• 每次换模型或换渠道后重新跑一遍自己的成本口径，不要沿用上一套单价

判断标准：如果你能在五分钟内回答「昨天花费最多的那类请求是哪种、它的输入和输出各占多少」，说明记录做到位了；如果只能说出总花费，说明还缺一层归因。这套习惯在按订阅计费的产品里优先级下降，因为消耗不直接体现为账单，但做容量规划和限流时仍然有用。