LLM Tokenizer详解2026
模型不读汉字也不读单词，它读token。同一段话换一个模型，切出来的token数可能差一倍，账单和上下文上限也跟着差一倍。这篇讲清tokenizer怎么切、怎么自己数、哪些写法在偷偷烧钱。
LLM Tokenizer详解2026：为什么你的提示词比想象中贵
模型不读汉字也不读单词，它读token。同一段话换一个模型，切出来的token数可能差一倍，账单和上下文上限也跟着差一倍。这篇讲清tokenizer怎么切、怎么自己数、哪些写法在偷偷烧钱。
一、tokenizer在做什么
tokenizer是"文本→整数序列"的翻译层，主流做法是BPE（字节对编码）：从单个字节开始，统计语料里最常一起出现的字节对，反复合并，最后得到一张几万到二十万条的词表。模型看到的永远是一串编号，不是字。
三个后果直接影响成本：
- 词表里已被合并的常见词，1个token就够；没见过的词退化成子词甚至单字节，成本翻几倍。
- 中文按UTF-8是每字3字节。国产模型词表对汉字覆盖好，常用字多为1个token；很多海外模型上，生僻字、人名、品牌名、中英混排会被拆成2-4个token。
- 数字串最吃亏。一长串数字常被切成碎片，这也是模型做算术容易错的原因之一，跟"聪不聪明"关系不大。
词表各模型不同：OpenAI 用 tiktoken 公开词表（如 o200k_base），Claude、Gemini 和国内各家基本不公开。所以不同模型的token数不能互相代用，算成本必须用对应模型的tokenizer。
二、几组能自查的比例
| 内容类型 | 大致换算 | 说明 |
|---|---|---|
| 英文自然语言 | 1 token ≈ 4个字符，≈0.75个单词 | 即1个英文词约1.3 token |
| 中文 | 1个汉字约1-1.7 token | 模型词表差异大，常用字接近1 |
| 代码、JSON | 每个字符约0.3-0.5 token | 缩进空格、引号、括号都算钱 |
| emoji | 每个2-4 token | UTF-8四字节，常被拆碎 |
| 长数字 | 每3-4位约1 token | 不要指望它逐位精确 |
这些是估算用的锚点，真正掏钱前用tokenizer数一次，误差就没了。
三、自己数token的三条路
路线1：OpenAI 系（tiktoken）
# pip install tiktoken
import tiktoken
enc = tiktoken.get_encoding("o200k_base") # GPT-4o 一代用的词表
print(enc.encode("把这段提示词数一下token"))
print(len(enc.encode("把这段提示词数一下token")))
路线2：开源模型（Hugging Face tokenizers）
from transformers import AutoTokenizer
tok = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct")
ids = tok("把这段提示词数一下token")["input_ids"]
print(len(ids))
词表要联网下载，离线机器把模型目录指到本地路径，加 local_files_only=True 就不联网。
路线3：不写代码
OpenAI 平台上有个 tokenizer 页面，把文本粘进去直接看切分结果和总数，调到哪一段被切碎一目了然。Hugging Face 上各模型的 "Tokenizer" 页面也能在线试。
四、上下文窗口折算成字
| 标称窗口 | 英文约 | 中文约 |
|---|---|---|
| 32K token | 2.4万词 | 2.6万汉字 |
| 128K token | 9.6万词 | 10.6万汉字 |
| 200K token | 15万词 | 16.6万汉字 |
| 1M token | 75万词 | 83万汉字 |
（按1 token≈0.75英文词、1汉字≈1.2 token折算，换模型请重算。）
注意窗口容量不等于可用质量：能装进去，不代表模型能用好。中间位置的信息经常被忽略，详见文末上下文窗口那篇。
五、四个立刻省钱的写法
- 裁历史：只带最近几轮完整对话，更早的压成一段摘要。多轮Agent里历史每轮重发，不裁等于重复付费。
- 压JSON：去掉缩进、缩短字段名、只传下游真用到的字段。缩进用的空格按输入计费，纯浪费。
- 静态前缀缓存：system prompt、工具定义、知识库背景放在最前面并且一字不改，很多家对缓存命中的输入单独计价，折扣幅度以各官网为准。
- 卡输出长度：给
max_tokens一个合理上限，并在提示词里要求"只给结论，不要过程复述"。输出单价普遍比输入贵数倍。
还有一个常被忽略的乘法：一份2000 token 的 system prompt，每天1万次请求，就是每天2000万输入token。它一个字没改，你却付了1万遍。
六、一份对账的完整算法
拿一个具体场景过一遍：中文长文摘要接口，每次带2000 token的 system prompt、3000字正文，输出600 token。
- 估输入：3000汉字按1.2 token/字约3600 token，加 system 的2000，合计5600。
- 加输出：单次约6200 token。
- 乘量：每天500次，日消耗约310万token，月约9300万token。
- 套单价：拿这个token量去乘官网的输入、输出单价，才是真账单。
再换一个：RAG问答，上下文5000 token、问题100 token、输出300 token，单次5400 token，每天2000次就是日1080万、月3.24亿token。量一大，档位选择比提示词技巧重要得多。
七、常见问题
Q：同一段文字两次token数不一样？ A：多半是提示词里混了动态内容：时间戳、随机ID、检索结果顺序、工具定义顺序。把可变部分挪到最后，数量就稳定了。
Q：中文是不是比英文贵？ A：看模型。同样信息量下，汉字覆盖好的词表token数更少。跨模型比较请用各自tokenizer实测同一段材料，别拿经验值互相换算。
Q：本地模型怎么数token？ A：用该模型的 AutoTokenizer，或 llama.cpp 自带的 tokenize 接口。别用 OpenAI 的词表估算本地模型。
Q：为什么输出比输入贵好几倍？ A：生成是一个token一个token串行出的，占用的算力时间远高于并行处理的输入。各家定价结构不同，具体倍数以官网定价页为准。
Q：词表越大越好吗？ A：不是。词表大，同样文本的token数少、序列短；但嵌入矩阵和输出层更大，小设备上反而吃显存。这是权衡，不是单向优化。
注：各模型词表与定价随版本变化，具体数值以官方文档和定价页为准。
相关文章
本站文章由编辑人工撰写，收录的工具均经过实测或公开资料核验。文中链接指向工具官网或 GitHub 仓库，仅作信息参考，不构成付费推广。