为什么大模型按 Token 计算,而不是按“字数”计算?

举报
搞点薯条 发表于 2026/08/27 08:43:32 2026/08/27
【摘要】 如果你经常使用 ChatGPT、Claude 或其他大语言模型,可能会注意到一个词:Token。模型的上下文长度是“128K Token”,API 的价格是“每百万 Token 多少钱”,输入和输出也都按照 Token 统计。于是一个很自然的问题出现了:为什么大模型不直接按字数计算,而非要引入 Token 这个看起来有点抽象的单位?答案藏在大语言模型处理文字的方式里。一、计算机其实“不认识”...

如果你经常使用 ChatGPT、Claude 或其他大语言模型,可能会注意到一个词:Token。

模型的上下文长度是“128K Token”,API 的价格是“每百万 Token 多少钱”,输入和输出也都按照 Token 统计。

于是一个很自然的问题出现了:

为什么大模型不直接按字数计算,而非要引入 Token 这个看起来有点抽象的单位?

答案藏在大语言模型处理文字的方式里。

一、计算机其实“不认识”文字

我们看到一句话:

今天天气很好。

人类看到的是几个汉字,并且能立刻理解它表达的意思。

但对于神经网络来说,“今”“天”“气”“很”“好”这些字符本身并没有任何天然意义。神经网络最擅长处理的是数字。

所以,在文字进入大模型之前,必须先完成一次转换:

文本 → 数字。

负责这个转换过程的模块,叫做 Tokenizer(分词器)。

Tokenizer 会把文本切成一个个小单元,每个单元叫做一个 Token,然后为每个 Token 分配一个数字 ID。

例如一句英文:

I love artificial intelligence.

可能被切成:

I / love / artificial / intelligence / .

也可能因为词汇表不同,被切成:

I / love / art / ificial / intelligence / .

而一句中文:

我喜欢人工智能

可能被切成:

我 / 喜欢 / 人工智能

也可能是:

我 / 喜 / 欢 / 人工 / 智能

具体怎么切,取决于模型使用的 Tokenizer。

因此,Token 并不等于汉字,也不等于英文单词。

它实际上是:

模型真正阅读和计算文本时使用的最小离散单位之一。


二、为什么不能直接“一个字就是一个 Token”?

乍一看,似乎完全可以这样设计。

中文一个汉字一个 Token,英文一个字母一个 Token,不就行了吗?

理论上当然可以。

问题是:效率太低。

假设我们要处理单词:

intelligence

如果按照字符处理,它需要拆成:

i / n / t / e / l / l / i / g / e / n / c / e

一共 12 个单位。

但如果模型的词表里直接有 intelligence 这个 Token,那么模型只需要处理一个单位。

计算量立刻下降很多。

反过来,如果规定“一个完整单词就是一个 Token”,又会遇到另一个问题。

语言中的词几乎是无限的。

比如:

run
running
runner
rerun
runnable

如果每种单词都单独收入词表,词表会变得非常庞大,而且碰到新词、人名、网址、代码、拼写错误时仍然无法处理。

因此,现代大模型通常采取一种折中的办法:

常见的文本片段尽量作为一个 Token,不常见的内容则拆成更小的 Token。

这就是为什么 Token 有时候是一个字,有时候是一个词,有时候只是半个单词。

它本质上是在:

词表大小、文本长度和通用性之间寻找平衡。


三、Token 才是大模型真正“一步一步”处理的东西

理解这一点之后,就能明白为什么大模型的很多参数都以 Token 为单位。

大语言模型最核心的任务,其实可以非常粗略地概括成一句话:

根据前面的 Token,预测下一个 Token。

比如:

法国的首都是____

Tokenizer 可能先把这句话转换成一串 Token ID:

8217, 116, 4932, 27, 981 ...

模型读取这些数字,通过神经网络计算,然后预测:

“巴黎”

对应的那个 Token 概率最高。

接着模型把“巴黎”加入上下文,再继续预测下一个 Token。

所以大模型生成文字时,并不是一次性把整个回答“想出来”然后打印出来。

而更像是:

Token 1 → Token 2 → Token 3 → Token 4 → ……

一步一步生成。

这也是为什么你会看到 AI 的回答像打字一样逐渐出现。

因此,对于模型内部来说:

“这篇文章有 1000 个汉字”并不是最重要的信息。

真正影响计算的是:

“这篇文章经过 Tokenizer 之后有多少个 Token。”


四、为什么上下文长度也按 Token 算?

你可能见过这样的参数:

上下文窗口:128K Tokens

它的意思并不是模型能记住 128K 个汉字,而是:

一次推理过程中,模型最多能处理大约 128K 个 Token。

假设你向模型发送:

  • 一篇论文;

  • 一段聊天记录;

  • 一个问题;

  • 模型之前生成的内容。

这些东西都会先变成 Token。

如果加起来超过模型的上下文窗口,就无法全部同时放进模型进行计算。

所以大模型所谓的“记忆长度”,从底层看,本质上也是:

能够同时计算多少个 Token。

这就像一张工作台。

字数是人类看到的材料数量,而 Token 数才是模型真正需要摆到工作台上的“计算单元”。


五、为什么 API 价格也按 Token 收费?

这和大模型的计算方式直接相关。

每输入一个 Token,模型都要对它进行一系列矩阵运算。

每生成一个 Token,也需要再次运行神经网络进行预测。

因此:

Token 数量和实际计算成本高度相关。

假设两段文字都是 1000 个字符:

第一段可能被分成 700 个 Token。

第二段因为包含大量生僻词、代码、特殊符号或者复杂字符串,可能被分成 1300 个 Token。

虽然人眼看起来长度差不多,但对于模型来说,第二段需要处理的计算单元明显更多。

因此,如果按照“字数”或者“字符数”收费,并不能很好地反映真实计算成本。

按照 Token 收费会更合理:

输入越多 Token → 计算量通常越大
输出越多 Token → 生成次数越多
计算量越大 → 推理成本越高

所以 API 厂商通常会分别给出:

输入 Token 价格和输出 Token 价格。


六、为什么不同语言的 Token 数不一样?

Token 还有一个经常让人困惑的地方:

同样一句话,换一种语言,Token 数量可能不同。

例如:

Hello, how are you?

和:

你好,你怎么样?

表达的意思差不多,但经过某个模型的 Tokenizer 后,得到的 Token 数并不一定相同。

原因在于 Tokenizer 的词表是通过大量训练数据学习或设计出来的。

如果某种语言、单词或表达形式在训练数据里非常常见,它往往更容易被压缩成较少的 Token。

而罕见字符、生僻语言、特殊符号或者复杂字符串,则往往需要更多 Token 表示。

因此可以把 Tokenizer 理解成一种特殊的文本压缩方式:

常见模式使用较短的表示,不常见模式使用更长的表示。

这也是为什么不同模型即使处理完全相同的一段文字,Token 数量也可能不同——因为它们使用的 Tokenizer 和词表并不一定相同。


七、Token 为什么会影响模型速度?

这里还有一个非常重要的工程问题。

Transformer 大模型在处理上下文时,需要让不同 Token 之间进行信息交互。

例如模型阅读一句话:

小明把苹果给了小红,因为她很饿。

模型需要判断“她”到底指谁。

这要求模型在处理当前 Token 时,同时参考前面的 Token。

Transformer 中负责这种关系建模的重要机制叫做:

Attention(注意力机制)。

因此,Token 越多,需要处理的关系通常也越多。

尤其在传统 Transformer 中,注意力计算量与上下文长度存在很强的增长关系。

所以:

1000 Token 的输入

和:

100000 Token 的输入

绝不是简单的“长度增加 100 倍”那么轻松。

这也是为什么各家模型都在研究:

  • 更长上下文;

  • KV Cache;

  • FlashAttention;

  • 稀疏注意力;

  • Sliding Window;

  • 上下文压缩;

它们背后的共同目标之一,都是:

降低大量 Token 带来的计算和存储成本。


八、Token 其实是连接“人类语言”和“神经网络”的桥梁

从人的角度看,我们交流的是:

字、词、句子、段落和文章。

从神经网络的角度看,它真正接收到的是:

15339 → 1912 → 374 → 459 → 2411 → …

这些数字经过 Embedding(嵌入)后,又会被转换成一组高维向量。

于是整个过程可以简化成:

文字

↓

Token

↓

Token ID

↓

向量

↓

Transformer 计算

↓

预测下一个 Token

↓

重新转换成文字

所以 Token 的作用非常关键。

它是人类语言进入大模型计算世界之前的第一层表示。


九、理解 Token,也就理解了大模型的一部分本质

很多关于大模型的概念,其实都可以从 Token 出发理解。

为什么有上下文长度限制?

因为模型一次只能处理有限数量的 Token。

为什么长文章更贵?

因为需要计算更多 Token。

为什么输出越长越慢?

因为模型需要一个 Token 一个 Token 地预测。

为什么同样长度的中文和英文价格可能不完全一样?

因为经过 Tokenizer 后得到的 Token 数量可能不同。

为什么代码、有些特殊字符或者乱码特别“费 Token”?

因为它们可能无法被词表高效编码,只能拆成大量较小的 Token。

所以,从工程角度看,大语言模型并不是直接在“读文章”。

它真正面对的是:

一条由 Token 构成的数字序列。

如果一定要用一句话概括为什么大模型以 Token 计算,可以这样说:

因为字数是人类衡量文本长度的单位,而 Token 才是大模型真正进行计算、存储和预测的单位。

理解 Token,就像理解计算机为什么使用 Byte(字节)而不是“一个文件”来衡量存储一样。

对于用户来说,我们看到的是文字。

对于大模型来说,它看到的,是 Token。

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0)

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。