如果你用过任何大语言模型——ChatGPT、Claude、文心一言、通义千问——你大概率在某个角落见过这个词Token。API 按 Token 计费、模型有 Token 上限、你的上下文太长请缩短……Token 像是 LLM 世界的最小货币单位。但你有没有想过一个问题大模型到底是怎么看到文字的答案可能会让你意外大模型根本不认识字。它连一个汉字、一个字母都不认识。它只认数字——准确地说是一长串整数 ID。把文字变成数字的过程就叫Tokenization分词/标记化而这个数字就是Token。这篇文章会带你从最底层理解 Token搞清楚这层抽象到底是怎么运作的、为什么它如此重要、以及你在日常使用中应该注意什么。我们会深入到 BPE 算法的原理也会手把手给你看代码。读完你会明白Token 不止是计费单位它决定了 LLM 能记住多少东西、能不能读懂代码、以及你到底要花多少钱。一、Token 到底是什么——从一个简单的实验开始先做一个直觉实验。打开 OpenAI 的 Tokenizer 工具输入这句话你好世界GPT-4 的 tokenizer 会把它拆成这样你 (1 token) 好 (1 token) (1 token) 世界 (1 token) (1 token)5 个 Token。为什么因为 GPT-4 用的 tokenizer 不认识你好是个固定搭配——它把每个汉字当成一个 Token 来存。再试试这句话Hello, world!GPT-4 的 tokenizer 这次怎么拆Hello (1 token) , (1 token) world (1 token) ! (1 token)也是4 个 Token。看起来中文和英文差别不大那你试试这句Transformer架构彻底改变了自然语言处理GPT-4 tokenizer 拆出来是Transformer (1 token) 架构 (1 token) 彻底 (1 token) 改变 (1 token) 了 (1 token) 自然 (1 token) 语言 (1 token) 处理 (1 token)8 个 Token。而英文的 Transformer architecture completely changed natural language processing 是Transformer (1) architecture (1) completely (1) changed (1) natural (1) language (1) processing (1)7 个 Token。似乎差不多。但如果你输入的是一个 Python 代码块呢def fibonacci(n): if n 1: return n return fibonacci(n-1) fibonacci(n-2)GPT-4 tokenizer 会把它拆成def (1) fib (1) on (1) acc (1) i (1) ( (1) n (1) ) (1) : (1) (LINEBREAK) (1) if (1) n (1) (1) 1 (1) : (1) (LINEBREAK) (1) return (1) n (1) (LINEBREAK) (1) return (1) fib (1) on (1) acc (1) i (1) ( (1) n (1) - (1) 1 (1) ) (1) (1) fib (1) on (1) acc (1) i (1) ( (1) n (1) - (1) 2 (1) ) (1)67 个 Token注意看——fibonacci被拆成了fibonacci不是一整个单词。为什么因为fibonacci不是一个常见的前缀/词根组合tokenizer 不认识只能拆到更细的粒度。这就是 Token 的第一个核心认知Token ≠ 单词。Token ≠ 字符。Token 是 tokenizer 认为值得作为一个整体记忆的最小语义单元。二、为什么需要 Token——一个极其朴素的问题有人可能会问为什么不直接把每个字符当成一个 Token这样多简单你好世界就 4 个字符4 个 Token。何必搞那么复杂的 tokenization答案是效率。一个 GPT-4 级别的 Transformer 模型在计算 self-attention 时计算复杂度是O(n²)n 是 Token 数量。如果你好世界拆成 4 个字符处理那还好。但如果是一篇 5000 字的文章呢按字符拆可能是 5000 个 Token按 tokenization 拆可能是 3500 个 Token。单层 attention 的计算量差就是 25,000,000 vs 12,250,000——差了一倍。而且把常见词组变成单个 Token意味着模型只需要学习一个 embedding 向量就能理解这个概念。如果是按字符拆transformer 要拆成 11 个字符模型需要通过 attention 机制把 11 个字符的 embedding 组合起来才能理解——这需要更深层的学习、更多参数、更多数据。Tokenization 本质上是一项压缩技术。它把常见模式打包成一个 Token让模型更高效。三、Tokenization 怎么做——三大主流算法的底层原理现在我们来点硬核的。LLM 的 tokenizer 通常使用子词subword级别的分词——不是单词级别也不是字符级别而是在两者之间找一个最优平衡点。主流算法有三种。3.1 BPEByte Pair Encoding——GPT 系列的选择BPE 是 OpenAI GPT 系列GPT-2、GPT-3、GPT-4使用的核心分词算法也是最广泛使用的一种。核心思想特别简单从字符级开始反复合并最常见的相邻字符对直到达到预设的词汇表大小。举个例子。假设我们有一个非常小的语料库只包含三个词low lower lowestBPE 的步骤是Step 1初始化。把每个词拆成字符每个字符后加一个/w词尾标记l o w /w l o w e r /w l o w e s t /wStep 2统计字符对频率。在这个语料库中(l, o)出现了 3 次(o, w)出现了 3 次(w, e)出现了 2 次(e, r)出现了 1 次(e, s)出现了 1 次(s, t)出现了 1 次(w, /w)出现了 1 次(r, /w)出现了 1 次(t, /w)出现了 1 次Step 3合并最高频对。(l, o)和(o, w)都是 3 次选第一个(l, o)合并成lo。此时词汇表新增了lolo w /w lo w e r /w lo w e s t /wStep 4重复。继续统计并合并。下一步最高频的是(lo, w)3 次合并成lowlow /w low e r /w low e s t /w继续。最高频的是(low, e)2 次合并成lowelow /w lowe r /w lowe s t /w继续……最终经过多轮合并词汇表里会出现low、er、est、ing等常见组合。当词汇表达到预设大小比如 GPT-4 的 100,000算法就停止了。那遇到词汇表里没有的新词怎么办BPE 会把新词拆成已知的子词。比如unhappily- 词汇表里有un、happi通过happy→happily学到、ly- 那unhappily→unhappily这就是BPE 的精髓从未见过的词也能用已知的子词组合拼出来。这也是为什么 architecture 被拆成architecture或architecture——取决于训练数据中这些子词的频率。3.2 WordPiece——BERT 的选择Google 的 BERT 使用 WordPiece 算法。和 BPE 很像但合并策略不同。BPE 合并「出现频率最高」的字符对WordPiece 合并「组合在一起时值得成为一个 Token」的字符对。衡量标准是score count(pair) / (count(first) × count(second))这个分数的含义是这对字符实际一起出现的频率与它们偶然碰在一起的概率之比。如果这个值很高说明它们是真正的组合不是巧合。举个例子如果语料库中un出现了 100 次而u出现了 1000 次n出现了 2000 次偶然碰在一起的概率 ≈ (1000 × 2000) / N²实际 100 / Nscore 100N / (2,000,000)如果 N 够大这个值可能很大。而如果uq出现了 10 次u出现了 1000 次q只出现了 5 次因为 q 总是跟在 u 后面偶然碰在一起的概率 ≈ (1000 × 5) / N²实际 10 / Nscore 10N / 5000这个值可能比上面的还要大——因为q几乎总是和u一起出现。WordPiece 的优势在于它不容易被高频但不重要的组合误导。比如 the 空格在英语中频率极高但这不是有意义的组合WordPiece 不会优先合并它们。3.3 Unigram SentencePiece——LLaMA 等现代模型的选择Google 的 T5 和多语言模型使用 SentencePiece基于 Unigram 算法。和 BPE/WordPiece 不同Unigram 是自上而下的从一个大词汇表开始比如所有可能的子词组合计算每个子词的损失如果去掉它模型的困惑度会增加多少删除损失最小的子词不太重要的重复直到词汇表缩小到目标大小SentencePiece 最大的特点是它把空格也当普通字符处理用特殊符号▁U2581表示词边界。这意味着它能优雅地处理任何语言——中文、日文、韩文、阿拉伯文——不需要语言特定的预处理。Meta 的 LLaMA 系列使用的 tokenizer 就基于 SentencePiece。同一个算法既管英文也管中文这也是为什么 LLaMA 处理中文的能力也在不断提升。四、Token 经济——为什么每个 Token 都在烧钱现在你知道了 Token 怎么来的。我们聊聊更现实的Token 与钱的关系。所有主流 LLM API 都是按 Token 计费的。以 GPT-4o 为例2026 年价格操作价格输入prompt$2.50 / 1M tokens输出completion$10.00 / 1M tokens缓存输入命中$1.25 / 1M tokens看起来不贵那我们来算一笔账。一只AI 助手每天要烧多少 Token假设你的 AI Coding 助手比如 Cursor、CodeBuddy、GitHub Copilot每天帮你写代码典型场景每次对话1500 tokens 上下文你问的问题 相关代码 2000 tokens 系统提示词 3500 tokens 输入每次生成800 tokens 输出生成的代码每天对话次数50 次真实的——你在调试时可能一小时就十几轮每天 Token 消耗输入3500 × 50 175,000 tokens ≈ $0.44输出800 × 50 40,000 tokens ≈ $0.40单日成本约 $0.84看起来还好。但如果你用的是Claude Opus 4.8$15/$75 每 1M tokens输入175,000 tokens × $15/1M $2.63输出40,000 tokens × $75/1M $3.00单日成本约 $5.63一个月约 $169这就是为什么大家在关心用哪个模型最划算——Token 经济是真金白银。Token 定价的隐性成本还有一个更容易被忽视的成本system prompt 上下文窗口的浪费。大多数 AI Coding 工具每次对话都带着一个很长的 system prompt可能 2000-5000 tokens即使在多轮对话中每轮都被重复计费。再加上对话历史不断增长——第 10 轮对话的输入可能已经膨胀到 8000 tokens。实战建议在 long-running coding session 中适时开启新对话重置上下文。这是减少 Token 浪费最直接的方法。五、Token 与上下文窗口——为什么 Claude 能记住200K而 GPT-3.5 只有 4K上下文窗口Context Window的单位就是 Token。一个模型的上下文窗口有多大决定了它一次性能看到和记住多少内容。模型上下文窗口约等于GPT-3.54,096 tokens~3,000 个汉字GPT-4-Turbo128K tokens~96,000 个汉字Claude 3.5 Sonnet200K tokens~150,000 个汉字Gemini 2.5 Pro1M tokens~750,000 个汉字Qwen3.7 Max256K tokens~192,000 个汉字但这里有一个关键陷阱上下文窗口大 ≠ 模型能有效利用全部内容。这涉及到 LLM 的注意力衰减问题——在长上下文中模型对开头的注意力会逐渐减弱导致遗忘早期的信息。业界有一套叫做大海捞针Needle in a Haystack的测试来评估这个能力。简单说就是把一个关键信息藏在超长文本的不同位置看模型能不能找到。2026 年的主流模型在 128K 范围内表现都不错但超出这个范围后准确性会显著下降。对 AI Coding 的实际影响如果你把整个项目的代码可能十几万行一次性喂给模型它虽然能读到但大概率会遗漏很多细节。更好的做法是配合 RAG检索增强生成这个我们上篇文章刚聊过做精准检索只把相关代码段送进上下文。六、Tokenization 的坑——那些让你 Debug 到崩溃的隐形问题6.1 中文的 Token 效率问题回到开头的实验。相同意思的一句话中文大语言模型正在改变世界 →8 tokens英文Large language models are changing the world →7 tokens看起来差不多。但如果内容长了一篇 3000 汉字的中文文章 ≈ 4500-6000 tokens一篇 3000 单词的英文文章 ≈ 3500-4000 tokens中文的 Token 效率天然比英文低约 30%-50%。这意味着在同样的上下文窗口下中文用户能喂给模型的内容更少。这也是为什么很多中文 AI 应用对上下文窗口更敏感。如果你在做中英混合的 prompt 工程考虑核心指令用英文写更省 Token但领域知识用中文因为模型对英文 Token 的语义压缩更好。6.2 数学和数字——Token 的绝对黑洞这是一件很多人不知道的事大模型处理数字的能力很差Tokenization 是主要罪魁祸首。试试用 tokenizer 处理1234567890它可能被拆成1234567890四个 Token。而模型需要理解这不是四个独立的数字而是一个整体。如果 GPT-4 的 tokenizer 把1234567890拆成了123、456、789、0四个 Token模型在计算1234567890 9876543210时必须先通过 attention 机制把四个 Token 的语义组装成一个数字——而这正是 LLM 的弱点。这就是为什么大模型做数学经常翻车——不是因为不会算而是因为数字在 tokenization 阶段就被打散了。这也是为什么你需要 MCP 的 Server 端工具——把数学计算交给 Python 或 Calculator MCP Server而不是让 LLM 自己算。MCP 那篇文章里我们详细聊过这个。6.3 特殊字符和代码——Tokenization 对程序员的特殊关照代码里的符号在 tokenization 中通常被当作独立 Tokenx arr[i] 1 # → x, , arr, [, i, ], , 1 # → 8 tokens但同一行代码在不同模型的 tokenizer 下可能差别很大GPT-4arr[i]→arr[i] 4 tokensCodeGemmaGoogle 代码专用模型arr[i]→ 可能只有 1 token专门为这类模式训练了 tokenizer这就是为什么不同模型处理代码的效率天差地别。代码专用模型如 CodeGemma、DeepSeek Coder、StarCoder的 tokenizer 通常对编程语言的常见模式做了优化让for i in range这样的高频代码模式被压缩成更少的 Token。七、实战用 Python 亲手操作 Tokenizer光说不练假把式。我们直接用 Python 把 tokenization 跑一遍。7.1 安装和基础操作# 安装 tiktokenOpenAI 的 tokenizer # pip install tiktoken import tiktoken # 加载 GPT-4o 的 tokenizer enc tiktoken.encoding_for_model(gpt-4o) # 编码文字 → Token ID 列表 text AI Coding is changing the way we build software. tokens enc.encode(text) print(f原始文字: {text}) print(fToken IDs: {tokens}) print(fToken 数量: {len(tokens)}) # 输出: Token 数量: 12 # 解码Token ID 列表 → 文字 decoded enc.decode(tokens) print(f解码结果: {decoded}) # 输出: AI Coding is changing the way we build software. # 逐个看每个 Token 对应什么 for token_id in tokens: token_bytes enc.decode_single_token_bytes(token_id) print(fID {token_id:6} → {token_bytes})输出大概是ID 2582 → bAI ID 16565 → b Cod ID 318 → bing ID 374 → b is ID 5079 → b changing ID 290 → b the ID 1638 → b way ID 584 → b we ID 4761 → b build ID 6543 → b soft ID 1193 → bware ID 13 → b.注意看Coding 被拆成了Codingsoftware 被拆成了software。这就是 BPE 在起作用。7.2 批量统计不同语言的 Token 效率import tiktoken enc tiktoken.encoding_for_model(gpt-4o) # 中英文对比 cn_text 人工智能正在彻底改变软件开发的方式从代码生成到自动化测试AI Coder正在成为每个工程师的标配工具。 en_text Artificial intelligence is fundamentally changing the way software is developed, from code generation to automated testing, AI Coders are becoming a standard tool for every engineer. cn_tokens len(enc.encode(cn_text)) en_tokens len(enc.encode(en_text)) print(f中文: {len(cn_text)} 字符 → {cn_tokens} tokens (效率 {cn_tokens/len(cn_text):.2f})) print(f英文: {len(en_text)} 字符 → {en_tokens} tokens (效率 {en_tokens/len(en_text):.2f})) # 典型结果 # 中文: 52 字符 → ~85 tokens (效率 ~1.63) # 英文: 190 字符 → ~45 tokens (效率 ~0.24)注意看这个颠倒的结果英文字符数更多但 Token 更少。因为每个英文字母平均不到半个 Token而每个汉字通常就是 1 个 Token。7.3 估算 API 费用def estimate_cost(prompt: str, model: str gpt-4o): 估算单次 API 调用的费用 enc tiktoken.encoding_for_model(model) input_tokens len(enc.encode(prompt)) # GPT-4o 预估输出长度实践经验通常在输入的 0.3-1.5 倍之间 estimated_output int(input_tokens * 0.5) # GPT-4o 2026 年定价 input_price 2.50 / 1_000_000 # $2.50 per 1M input tokens output_price 10.00 / 1_000_000 # $10.00 per 1M output tokens cost input_tokens * input_price estimated_output * output_price print(f输入 Token: {input_tokens}) print(f预估输出 Token: {estimated_output}) print(f预估费用: ${cost:.6f}) print(f如果每天调用 100 次: ${cost * 100:.4f}/天, ${cost * 100 * 30:.2f}/月) return cost # 示例一篇 2000 字的技术文章作为 prompt long_prompt 请分析以下代码的性能瓶颈并给出优化建议...\n\n x 1\n * 500 estimate_cost(long_prompt)7.4 上下文窗口检查器import tiktoken def check_context_limit(text: str, model: str gpt-4o, context_limit: int 128000): 检查文本是否超出模型的上下文窗口 enc tiktoken.encoding_for_model(model) token_count len(enc.encode(text)) percentage (token_count / context_limit) * 100 print(f模型: {model}) print(f上下文窗口: {context_limit:,} tokens) print(f文本 Token 数: {token_count:,}) print(f使用率: {percentage:.1f}%) if token_count context_limit: print(f⚠️ 超出限制 {token_count - context_limit:,} tokens请精简内容。) elif percentage 80: print(f⚠️ 接近上限{percentage:.0f}%建议缩减或开启新对话。) else: print(f✅ 空间充足还有 {context_limit - token_count:,} tokens 可用。) return token_count # 可以检查你的 system prompt 对话历史的长度 conversation System: You are an expert coding assistant...\nUser: ...\nAssistant: ... check_context_limit(conversation)八、Token 在 AI Coding 中的实战优化8.1 Prompt 设计中的 Token 优化很多人写 prompt 很随意充满了请、麻烦、能不能这些礼貌用语。每个礼貌用语都是 1-2 个 Token。在单次对话中无所谓但如果你的 prompt 是一个每天被调用 10 万次的 API 调用每个 prompt 省 3 个 Token 就是每天省 30 万个 Token——按 GPT-4o 价格是 $0.75/天一个月 $22.5。优化前请帮我分析一下下面这段代码中可能存在的性能问题并对每个问题给出详细的优化建议。非常感谢优化后分析以下代码的性能问题并给出优化建议第一个版本 ~35 tokens第二个版本 ~18 tokens。内容几乎一样Token 省了一半。如果你做一个面向海量用户的 AI Coding 产品这种优化非常关键。8.2 代码注释的 Token 权衡很多 AI Coding 工具在生成代码时会附带详细注释。但你有没有想过——注释也是 Token也占用上下文窗口。对于 prompt 里喂给模型的参考代码注释很有用它是few-shot 示例的一部分。但对于模型输出的代码冗长的注释可能是浪费——尤其是那种// i 自增 1级别的无效注释。更好的策略在 system prompt 中指示只对关键逻辑写注释让模型输出时自动控制注释密度。8.3 选择合适的模型 Tokenizer同样的中文文章不同模型的 Token 数量差异可能很大模型Tokenizer1000 汉字的 Token 数约GPT-4otiktoken (o200k_base)~1600Claude 3.5自定义 BPE~1400DeepSeek V3自定义多语言优化~1200Qwen 2.5自定义中文优先~900Qwen 因为是中文优先的模型处理中文的 Token 效率显著高于 GPT 和 Claude。如果你的应用场景主要是中文选择 Qwen 或 DeepSeek 不仅能获得更好的中文理解能力还能省不少 Token 费用。九、常见误区与真相误区 1Token 单词真相Token ≠ 单词。一个单词可能是一个 Token如 hello也可能是多个 Token如 unhappiness → un happiness也可能多个单词合并成一个 Token如 the → 1 token 包含了 the 和后面的空格。中文里一个 Token 通常是一个汉字或常见词组。误区 2上下文窗口大小就是字数真相上下文窗口的单位是 Token不是字数。128K tokens ≠ 128,000 个汉字。根据语言不同128K tokens 约等于 80,000-100,000 个汉字或约 90,000-110,000 个英文单词。误区 3Token 越多模型理解越好真相Token 是手段语义是目的。如果把 the 拆成 t-h-e 三个 Token模型需要多花注意力来粘合它们反而降低理解效率。好的 tokenizer 是把有意义的单元压缩成一个 Token而不是让 Token 越多越好。误区 4只要上下文窗口够大就能无限塞内容真相即使不超出窗口超长的上下文也会导致注意力衰减——模型对文本中间和结尾部分的关注度不均匀。而且长上下文的推理速度会显著变慢O(n²) 的 self-attention费用也会急剧上升。十、总结Token 是 LLM 世界的最小作用量如果把 LLM 比作物理学Token 就是作用量量子 h——它是一切计算的最小不可分割单元。你写的每一行 prompt、每一段代码、每一个字最终都会落到 Token 这个层面被模型处理。理解 Token 能帮你-省钱优化 prompt 设计选择合适的模型 tokenizer控制上下文长度-提效在有限的上下文窗口内塞进更多有效信息-Debug当模型出现不能理解数字、漏掉关键信息等问题时知道可能是 Tokenization 的锅-选模型根据你的语言需求选择 Token 效率更高的模型中文选 Qwen/DeepSeek代码选 StarCoder/DeepSeek CoderTokenization 这个翻译层看似简单却深刻影响了大模型的一切行为。搞懂了它你就掌握了 LLM 世界的底层密码。上一篇Agent彻底讲透让AI从问答工具进化成能自主干活的智能体推荐文章MCP彻底讲透AI Coding的万能接口如何让你的Agent真正拥有动手能力