完整题目
大模型里的 Token 是什么?为什么中英文 Token 数量差异很大,各家 API 又为什么按 Token 计费?
本文目录
答案要点
- Token 是大模型处理文本的最小单位,由分词器(Tokenizer)切出来,可能是一个词、半个词或一两个汉字
- 模型的输入输出、上下文窗口、计费全部以 Token 计量,而不是字符或单词
- 中英文差异:主流词表偏英文,1 个英文单词约 1~1.3 token,1 个汉字常需 1~2 token
- 按 Token 计费是因为计算量与 Token 数直接成正比,每生成一个 token 都要完整跑一遍前向计算
- 估算成本先估 Token:输入和输出都收费,输出单价通常更贵
核心概念
Token 是大模型读写文本时的最小处理单位,由分词器(Tokenizer,把文本切分成小片段的组件)按照训练好的词表把句子切开。它不等于「字」也不等于「词」:常见英文单词可能整体就是 1 个 token,生僻词会被拆成几段,一个汉字可能对应 1~2 个 token。主流切分算法是 BPE(字节对编码)一类:高频片段合并成一个 token,低频内容拆碎处理。
中英文 Token 差异
| 文本 | 大致换算 |
|---|---|
| 英文 | 1 个单词 ≈ 1~1.3 token,100 词 ≈ 130 token |
| 中文 | 1 个汉字 ≈ 1~2 token(新模型扩充中文词表后接近 1) |
原因是词表大多在以英文为主的语料上训练:英文高频词能整词进词表;汉字数量庞大,很多只能拆到字节级。这意味着同样含义的一段话,中文往往更「费 token」——窗口装得更少、调用费用更高(新一代国产模型已扩充中文词表,差距在缩小)。
为什么按 Token 计费
- 模型每一步计算的对象就是 token 序列,算力消耗与 token 数量近似成正比
- 生成阶段是逐 token 输出的,每吐一个 token 都要完整跑一次前向计算,所以输出单价通常比输入贵数倍
- 字符数、单词数都反映不了算力消耗,token 才是与成本对齐的计量单位
入门后可深入 BPE 的合并训练过程,以及词表大小对效果和推理成本的影响。
换一种问法，检查是否真正理解
场景切入
你要给公司做成本预算:每天 1 万次调用,平均每次输入 500 个汉字、输出 300 个汉字,你怎么估算一天大概消耗多少 token?
概念辨析
Token、字符、单词这三个概念有什么区别?为什么模型的上下文长度不用字符数来定义,而要用 token 数?
练习口述回答 · 约2分钟
- 一句话定位：Token 是大模型的基本计价和计算单位
- 中英文差异源于词表偏向英文，中文更费 Token
- 按 Token 计费因为算力和 Token 数成正比，输出更贵
- 落地时估算 Token 是关键，注意上下文窗口限制
这道题其实是在问大模型怎么理解文本、怎么定价，背后是同一个东西，Token。Token 是大模型处理文本的最小单位，由 [[Tokenizer]] 切出来。它不一定是完整的词，可能是半个词、一个汉字，甚至一个字节。模型的所有操作，输入、输出、上下文窗口、计费，全按 Token 算，而不是字符数。
中英文差异很明显，主要原因是词表大多在英文语料上训练。英文高频词能整词进词表，一个单词大概 1 到 1.3 个 Token；中文汉字数量庞大，很多词没在词表里，就得拆成字节，一个汉字大概 1 到 2 个 Token。同样一段话，中文往往更费 Token，上下文窗口能装的内容更少，调用成本也更高。不过新一代模型已经把中文词表扩充了，差距在缩小。
再说计费。为什么按 Token 而不是字数？因为模型的计算量和 Token 数成正比。每生成一个 Token，都要完整跑一遍前向计算，所以输出单价通常比输入贵好几倍。Token 是和算力成本最对齐的单位。
举个例子，你做一个客服退款场景的问答系统，用户问一句“我的订单还没退款”，大概 10 个汉字，按 1.5 倍算就是 15 个 Token。模型回复“您好，请提供订单号”，又是十几个 Token。如果上下文窗口只有 4K，那对话几轮就可能超限。所以落地时，估算 Token 是第一步，既要算输入也要算输出，还要留足窗口给历史。
这里有个坑：很多人以为上下文窗口越大越好，但窗口越大，计算成本越高，而且模型对长距离信息的注意力会衰减。实际项目中，我会根据业务场景设定窗口上限，比如客服场景 2K 到 4K 就够，文档分析才需要 8K 以上。
所以我会把 Token 看成大模型的“货币”，理解了它，你才能准确估算成本、设计提示词、选择模型。进一步，如果你对 Tokenizer 的细节感兴趣，可以聊聊 BPE 算法的合并策略，它直接影响词表大小和推理效率。