Token 与计费单位 | 大模型 | 做产品

Token 与计费单位

模型看不见字，它看见的是 token。你写的每一段话，都要先按一张固定的表切成碎片，再变成数字进模型。

你会遇到的现象

切分表不是人定的，是从语料里统计出来的：把最常一起出现的字符组合并成一个 token，反复合并几万轮，得到一张几万到几十万条的词表。越常见的东西，越可能被压成一个 token；越少见的，越会被拆碎。

于是就出现了几种反直觉的情况。一个完整的英文常用词，往往只占 1 个 token。一个长一点的专业词，会被拆成两三段。一个汉字，可能是 1 个 token，也可能因为生僻而被按字节拆成 2 到 3 个。一个 emoji 通常占 2 个以上。空格和换行也算，缩进多的代码会比你想的贵。

内容大致 token 数说明常见英文单词1词表里直接有一条较长的专业术语2 – 4被拆成词根加后缀常用汉字0.6 – 1高频词组会被合并成一个生僻字、异体字2 – 3退化成按字节切 emoji2 – 4同上一段带缩进的代码比看上去多空格和换行都要算钱

这些数字是量级，不是精确值——每家模型的词表都不一样，同一段文字换个模型算出来就不同。要准数只能拿对应模型的 tokenizer 实测。

还要知道一条：**词表是训练时定死的，不能改。**你们业务里那些自造词、内部缩写、产品代号，在词表里没有专门的条目，会被切得很碎。这既费钱，也让模型更难把它当成一个完整概念来理解。

所有模型都按 token 计费，输入一个价，输出另一个价，输出通常贵好几倍。所以估成本的公式不是「字数 × 单价」，而是要先把字数换算成 token 数。

**先做一次实测，别用经验值。**拿你们真实的一条请求，用目标模型的 tokenizer 数一遍。中英文混排、带表格、带代码的内容，估算误差经常在两倍以上。
**算的是整条上下文，不是这一句。**多轮对话里，每一轮都要把前面所有内容重发一遍。第十轮的那句话很短，但那次调用的输入可能是几万 token。真正贵的从来不是最后那句。
**输出长度是最值钱的旋钮。**输出单价高，而且它是一个一个吐的，所以输出还直接决定延迟。让它「用三句话回答」，同时省了钱和时间。
**中英文的价差没有传说中那么大，但确实在。**新一代词表对中文的压缩好了很多，可一旦碰上生僻字、专有名词、竖排表格，中文这边仍然会明显吃亏。

token 不只是计费单位，它是模型的感知单位

你看到的 s t r a w b e r r y 10 个字符，r 出现 3 次，你一眼能数

它看到的 str aw berry 3 个 token，字母被封在里面看不见

这个错位直接解释了四种失灵

数不清字数「写刚好 100 字」只能靠估，要精确得由代码截

数学不稳长数字被切成好几段，数位关系不是强规律

字符级任务很吃力数字母、倒着拼、判断回文，它看不见字符

200K 上下文 ≠ 20 万字中文能塞进去更多，代码则往往比你估的少

很多「模型怎么连这个都不会」的时刻，根都在这条错位上。这类任务的正确解法不是换更强的模型，而是让它调工具去数、去算——把字符级的活交给代码。

token 不只是计费单位，它是模型的感知单位。很多莫名其妙的失灵，根都在这。

**它数不清字数。**因为它看到的是 token，不是字。让它「写一段刚好 100 字的文案」，它只能凭感觉估，估不准是必然的。要精确控字数，得由你的代码去截，或者让它调工具去数。

**它数学不稳。**一个长数字会被切成好几个 token，数位之间的关系在统计上不是强规律。所以涉及计算的场景，正确做法是让它写出算式、交给计算工具，而不是让它心算。

**字符级的任务它很吃力。**数某个字母出现了几次、把一个词倒着拼、判断回文，这些任务要求它看见字符，可它只看得见 token。

**上下文长度也是按 token 算的。**说「200K 上下文」，指的是 20 万个 token，不是 20 万字。你能塞进去的中文内容比这个数字多一些，塞进去的代码则往往比你估的少。

大模型的运作原理切出 token 之后发生了什么：一次只猜下一个，然后重复几百遍。

训练与推理的区别 token 计费落在推理这一侧。账单的三个乘数分别在哪里能压。

上下文预算窗口是按 token 算的。这一篇讲怎么把有限的额度花在刀刃上。