大模型实战指南1——Token到底是什么搞懂大模型的“最小货币单位”你发给 DeepSeek 的每句话在它“理解”之前先被剁成碎片、贴上编号、变成一串整数。碎片叫 Token切碎片叫分词。Token 不是大模型的附属概念——计费按它算、上下文窗口按它量、推理速度被它拖、输出长度被它卡。搞不懂 Token你连 API 账单都看不懂。0. 前言先说清楚这个系列要干什么。网上大模型教程分两种一种太学术开口就是“自注意力机制的多头缩放点积”小白直接劝退另一种太浅教你怎么注册 ChatGPT 账号看完还是不懂大模型到底咋运作的。这个系列走中间路线用人话讲透每个核心概念配代码和图讲完你马上能用。从 Token 开始一路讲到 Transformer、微调、RAG、Agent15 篇读完你对大模型的认知会从“会打字的魔法盒子”变成“一套可拆解可操控的工程系统”。为什么第一篇讲 Token因为 Token 是整个大模型技术栈的地基。你往后学的每一个概念——上下文窗口、Embedding、注意力机制、推理优化——全都以 Token 为基本单位。地基打不牢后面全是空中楼阁。不废话直接开始。1. 大模型不认字只认数字很多人以为大模型像人一样“读”文字——它没有。你发给 DeepSeek 一句“你好世界”它接收到的不是四个汉字而是一串类似这样的整数[10236, 3827]“你好世界”四个字在 DeepSeek 的分词器里可能只被切成 2 个 Token。换成 GPT-4o可能变成 4 个甚至 6 个。同一句话不同模型切碎的方式完全不同——因为每个模型有自己的“刀法”分词器。如果你觉得抽象打个比方把大模型想象成一家餐厅你的话是客人点的菜。后厨只认标准化的食材包Token不认散装的原材料原始文字切菜师傅分词器负责把五花八门的原材料切成后厨认识的标准食材包同一棵白菜同一句话中餐师傅切成“片”DeepSeek 切法西餐师傅切成“丝”GPT 切法端出来的菜完全不同这就是为什么同一句话不同模型“理解”得不一样——它们在入口处看到的食材形态就不同。图1你输入的文字先被分词器切成 Token再查表变成整数 ID最后变成模型能处理的向量。整条流水线不可逆地决定了模型“看到”什么。整条流水线分四步原始文本你输入的自然语言文字分词器切分BPE 算法把文字切成 Token 碎片查表映射每个 Token 查词表变成一个整数 IDEmbedding整数 ID 映射为一个高维向量比如 4096 维模型开始处理这四步不可逆地决定了模型“看到”什么。同样的文字换个分词器模型接收到的信息就变了。这把“刀”是怎么工作的为什么“你好”能合在一起、有的字会被单独切开背后是一套叫BPE的算法我们第 3 节细讲。但别急先搞懂一个更基础的问题为什么不直接用字符1.1 Token 和字符到底是什么关系很多人搞混 Token 和字符。区分一下概念定义例子字符Character文本的最小显示单位“你”“好”“a”“B”“”“。”字节Byte计算机存储的最小单位一个英文字符 1 字节一个中文字符 3 字节UTF-8词Word语言中有意义的最小单位“自然语言处理”是一个词Token分词器切分后的最小单元可能是 1 个字、半个词、或一整个短语Token 介于字符和词之间——有时等于一个字有时等于一个词有时是半个词。具体等于什么取决于分词器怎么切。一个粗略的经验换算英文1 个 Token ≈ 0.75 个单词4 个字母→ 100 个单词 ≈ 130 个 Token中文GPT-3.51 个汉字 ≈ 1.5-2 个 Token → 100 个汉字 ≈ 150-200 个 Token中文DeepSeek/Qwen1 个汉字 ≈ 0.5-0.7 个 Token → 100 个汉字 ≈ 50-70 个 Token代码1 个 Token ≈ 3-4 个字符 → 100 行代码 ≈ 800-1200 个 Token注意这些只是经验估值实际 Token 数必须用分词器测。不同文本内容差异很大——常见词多的文本 Token 数少生僻字多的文本 Token 数多。2. 为什么不按“字”切为什么不按“词”切直觉上按字切最简单——“你好世界”切成“你”“好”“世”“界”四个字每个字一个编号完事。问题在于按字切模型看不到“词”。“银行”和“行走”里都有“行”字但意思完全不同。如果按字切模型只能看到孤零零的“行”它得自己猜这个字是什么意思。而你把“银行”当一个整体给模型模型一上来就知道这是个词省了大量推理功夫。更关键的是按字切会让序列变得很长。一段 1000 字的中文按字切就是 1000 个 Token。模型处理 1000 个 Token 和处理 500 个 Token计算量差一倍——注意力机制的计算复杂度是 Token 数的平方差得更多。这里有个直觉如果一个字的序列是 1000平方就是 100 万次计算如果压缩到 500平方就是 25 万次计算量直接降到四分之一。所以“把文字压缩成更少的 Token”不光是省钱更是让模型能处理更长文本的关键。那按词切呢“自然语言处理”切成一个词“我喜欢吃苹果”切成五个词——听起来完美。问题来了词的组合是无限的。“自然语言处理工程师”是一个词还是两个词“反内卷”算不算一个词“YYDS”呢按词切你的词表会膨胀到几百万模型的嵌入层每个 Token 对应一个向量参数直接爆炸训练根本扛不住。而且按词切有个致命缺陷遇到新词就抓瞎。训练时没见过的词人名、新术语、拼写错误分词器不认识只能返回一个UNKunknown标记模型完全不知道这个词是什么。你发一句“今天 ChatGPT 发布了 GPT-5o”分词器不认识“GPT-5o”全变成UNK模型看到的就是“今天UNK发布了UNK”——信息全丢了。你可能会说那不断往词表里加新词不就行了问题是语言是活的——每天都有新词诞生“打卡”“内卷”“多巴胺穿搭”词表永远追不上。而且每加一个词模型的嵌入层就要重训成本极高。BPE 的思路是在“字”和“词”之间找个平衡点高频组合合并成短 Token低频文本拆成碎片拼。这样词表大小可控几万到十几万又能覆盖几乎所有文本。最重要的是——遇到没见过的词BPE 把它拆成已知的子词碎片永远不会出现UNK。比如“tokenization”这个词如果训练语料里没见过BPE 会把它拆成“token”“ization”两个子词。模型虽然没见过“tokenization”整体但见过“token”和“ization”能推断出大概意思。这就是子词分词的核心优势开放词汇表——任何文本都能处理永远不会抓瞎。反过来高频词会被合并成一个短 Token。比如“the”在英文语料里出现频率极高BPE 几轮合并后就会把它变成一个独立 Token。这样一来模型处理“the”只需要一个步骤而不是三个“t”“h”“e”效率大幅提升。OpenAI 官方 README 里的原话“It attempts to let the model see common subwords. For instance, ‘ing’ is a common subword in English, so BPE encodings will often split ‘encoding’ into tokens like ‘encod’ and ‘ing’.”常见组成部分被独立成 Token模型在不同上下文反复见到它有助于泛化和理解语法。3. BPE大模型的“切词刀法”BPE 全称Byte Pair Encoding字节对编码2015 年由 Sennrich 等人在论文《Neural Machine Translation of Rare Words with Subword Units》中提出最初用于机器翻译后来被 GPT-2 采用如今是主流大模型分词的事实标准。3.1 一句话讲清 BPE 的核心逻辑统计训练语料里所有相邻字符对的出现频率把频率最高的组合合并成新 Token重复这个过程直到词表达到目标大小。就像压缩文件——你发现“th”这两个字母老一块出现就把它们合成一个单元又发现“the”老一块出现再合成一个更大的单元。合并到最后常见的词变成了一个 Token罕见的词被拆成几个子词碎片。3.2 用一个例子走一遍假设训练语料里有这些词后面的数字是出现次数low: 5次, lower: 2次, newest: 6次, widest: 3次初始状态每个词被拆成单个字符l o w: 5 l o w e r: 2 n e w e s t: 6 w i d e s t: 3第 1 轮统计所有相邻字符对发现e和s一起出现了 9 次newest 6 次 widest 3 次频率最高。合并es→esl o w: 5 l o w e r: 2 n e w es t: 6 w i d es t: 3第 2 轮现在es和t一起出现了 9 次合并 →estl o w: 5 l o w e r: 2 n e w est: 6 w i d est: 3第 3 轮l和o一起出现了 7 次low 5 次 lower 2 次合并 →lolo w: 5 lo w e r: 2 n e w est: 6 w i d est: 3第 4 轮lo和w一起出现了 7 次合并 →lowlow: 5 low e r: 2 n e w est: 6 w i d est: 3继续合并下去lower会变成lowernewest会变成newest……图2BPE 每一轮找出最高频的相邻组合合并成新 Token。从单字符开始一轮一轮“攒”出常见词就像捏乐高——经常一起出现的积木先拼好下次直接用。这个过程的关键特征自底向上从最小单元字符开始逐步合并频率驱动只合并出现频率最高的组合低频组合不动可逆任何 Token 序列都能无损还原成原始文本开放词汇没见过的词被拆成已知子词不会出现UNK你可能注意到了一个细节BPE 的合并顺序完全由训练语料决定。换一批训练语料合并顺序就不同最终词表也不同。这就是为什么不同公司的模型——即使都用 BPE——分词结果完全不一样它们的分词器是在各自的训练语料上训练出来的。还有一个容易混淆的点BPE 的“训练”和模型的“预训练”是两回事。分词器的训练发生在模型预训练之前是一个独立的、相对简单的过程统计频率 贪心合并。分词器训练好了词表固定下来然后才开始用这个分词器把全部训练语料转成 Token 序列喂给模型做预训练。分词器一旦确定在整个模型生命周期里不再改变——这也是为什么换分词器等于换模型。3.3 中文怎么切BPE 原本是处理英文字符的中文怎么办两种主流方案方案一字节级 BPEByte-level BPE简称 BBPE。把所有文本不管中文英文 emoji先转成 UTF-8 字节再在字节层面做 BPE。一个中文字占 3 个字节所以理论上可能被拆成 3 个碎片。好处是——不管什么语言什么字符都能处理永远不会出现“未知字符”。DeepSeek-V3 用的就是这种方案词表大小 128,100。GPT-4o 用的 o200k_base 也是字节级 BPE词表 200,000。方案二SentencePiece。Google 开源的工具直接在 Unicode 字符层面做分词不依赖空格切分。LLaMA 1/2 用的就是 SentencePiece词表只有 32,000。而 Qwen 系列虽然也用 BBPE但词表更大约 152,000中文压缩率和 DeepSeek 接近。你可能会问为什么不直接在中文“字”的层面做 BPE因为字节级方案有一个巨大优势——它不关心你的文本是什么语言。英文、中文、日文、韩文、emoji、甚至二进制数据统统先变成字节再统一处理。一个分词器通吃所有语言这对多语言大模型非常重要。还有一个小知识BPE 不是唯一的子词分词算法。还有两种常见变体——WordPieceBERT 用的合并标准不是频率最高而是似然增益最大和UnigramSentencePiece 的另一种模式从大量候选词里逆向选出最优子词集。但主流大语言模型GPT 系列、DeepSeek、Qwen、LLaMA 3基本都用 BPE 或 BBPE所以这个系列只重点讲 BPE其他两种你了解存在即可。3.4 词表大小是什么意思词表vocabulary就是分词器认识的所有 Token 的列表。词表大小就是这张列表有多少行。词表太小很多常见词被拆成碎片模型处理同样文本需要更多 Token推理更慢也浪费上下文窗口词表太大模型嵌入层参数暴增每个 Token 对应一个几千维的向量训练更贵而且低频 Token 在训练数据中出现次数太少学不好主流大模型的词表大小模型词表大小分词算法GPT-3.5 / GPT-4100,256cl100k_baseBPEGPT-4o / o1 / o3200,000o200k_baseBPEDeepSeek-V3128,100BBPE字节级 BPEQwen 系列~152,000BBPELLaMA 3128,256BBPE图3GPT-4o 把词表从 10 万翻到 20 万是为了压缩非英语文本的 Token 数。国产模型普遍 12-15 万兼顾中文压缩率和词表效率。GPT-4o 为什么要翻倍词表因为 cl100k_base 对中文压缩率太差——一个汉字经常被切成 2-3 个 Token。o200k_base 扩大词表后中文压缩率显著提升OpenAI 官方发布说明的说法是“增加了 tokenizer 的压缩率”但未公布具体倍数。注意一个细节GPT-3.5 和 GPT-4 用的是同一套分词器cl100k_base但 GPT-4o 换了新的o200k_base。这意味着同一个 OpenAI API换模型版本可能导致 Token 数变化这是很多人没意识到的坑。3.5 动手实现一个极简 BPE理论看再多不如自己跑一遍。下面用 Python 实现一个 20 行的极简 BPE只保留核心逻辑你跑完就彻底懂了。fromcollectionsimportCounterdeftrain_bpe(corpus,num_merges20):# 1. 初始化每个词拆成字符序列字符间加空格便于按对合并words{}forw,freqincorpus.items():words[w][ .join(list(w)),freq]vocabset(.join(corpus.keys()))# 初始字符集for_inrange(num_merges):# 2. 统计所有相邻字符对的频率pair_freqCounter()forseq,freqinwords.values():symbolsseq.split()foriinrange(len(symbols)-1):pair_freq[(symbols[i],symbols[i1])]freqifnotpair_freq:break# 3. 找到频率最高的对合并成新 Tokenbest_pairmax(pair_freq,keypair_freq.get)merged.join(best_pair)# 4. 把语料里所有出现该对的地方替换成新 Tokennew_words{}forw,(seq,freq)inwords.items():new_seqseq.replace(best_pair[0] best_pair[1],merged)new_words[w][new_seq,freq]wordsnew_words vocab.add(merged)returnvocab# 训练语料词 - 出现次数corpus{low:5,lower:2,newest:6,widest:3,}vocabtrain_bpe(corpus)print(训练出的词表:,vocab)运行这段代码你会看到“low”、“lower”、“est”、“newest”等词条逐渐被合并出来——和我们前面手推的 4 轮过程完全一致。这就是 BPE 的全部秘密。真实世界的 BPE 比这复杂得多还要处理字节级、特殊 Token、正则预分词等但核心就是这个 20 行的贪心合并逻辑。KarpathyOpenAI 创始成员写过 minbpe 教学项目有兴趣可以去看他的视频讲解。4. 同一句话不同模型 Token 数能差多少这是最容易踩的坑。来看实测对比——拿“人工智能正在改变世界”这句话测几个模型模型Token 数你看到的GPT-3.5cl100k_base约 12-14几乎每个字被拆成 1-2 个碎片GPT-4oo200k_base约 8-10中文压缩率提升但仍不如国产DeepSeek-V3约 5-6中文优化常见词整块保留Qwen约 5-7同样针对中文优化图4同一句中文GPT-3.5 可能切 12 个 TokenDeepSeek 只要 5-6 个。这意味着同样 128K 上下文窗口DeepSeek 实际能塞下的中文是 GPT-3.5 的 2 倍多。为什么差这么多因为分词器是在模型预训练之前单独训练的。分词器的训练语料和模型预训练语料通常是一致的——DeepSeek 和 Qwen 的训练语料里中文比例高BPE 合并时自然把高频中文组合攒成了 Token。GPT 系列训练语料以英文为主中文组合频率低没被合并成短 Token。这个差异直接影响三个东西费用、速度、上下文容量。下一节细说。4.1 先记住一张“日常换算表”不想每回都跑代码先记住这张常用表DeepSeek/Qwen 的估值常见场景大约消耗一句“你好”1-2 Token一条 20 字的微信消息10-15 Token一页 A4 中文文档约 500 字300-350 Token一篇 2000 字公众号文章1200-1400 Token一份 10000 字技术文档6000-7000 Token一本 20 万字小说12-14 万 Token注意这是**国产模型DeepSeek/Qwen**的换算。用 GPT-3.5 的话所有数字直接翻 2-3 倍。用这张表算一笔账DeepSeek-V3 的上下文窗口是 128K Token。按一个汉字约 0.6 Token 算大约能塞进 20 万汉字——相当于 2000 字文章约 100 篇或 500 页的厚书。这就是为什么很多人说“DeepSeek 能直接读整本书”。5. Token 如何影响你的钱包和体验5.1 计费API 按 Token 收费OpenAI、DeepSeek、阿里云——所有大模型 API 的计费单位都是 Token不是字符不是请求次数。价格通常写成“每百万输入 Token 多少钱”和“每百万输出 Token 多少钱”输出比输入贵因为生成比理解难。你写的 Prompt 是输入 Token模型生成的回答是输出 Token。这就意味着同样一段中文用 GPT-3.5 处理比用 DeepSeek 贵不止一倍——不是因为单价差而是因为 GPT-3.5 对同样文本消耗的 Token 数是 DeepSeek 的 2 倍多。举个例子你有一篇 10000 字的中文文档要喂给模型做摘要。用 DeepSeek约 6000 个输入 Token用 GPT-3.5约 15000-18000 个输入 Token如果 DeepSeek 每百万输入 Token 收 1 元GPT-3.5 收 0.5 元你会觉得 GPT 更便宜算一下DeepSeek 花 0.006 元GPT-3.5 花 0.008 元。GPT 单价便宜一半实际花费反而更高——因为 Token 消耗量翻了 2-3 倍。比价时必须按等量文本换算不能直接比“每百万 Token 单价”。5.2 速度生成 Token 是串行的大模型生成文本时是一个 Token 一个 Token 吐出来的实际上有投机解码等优化但本质是串行过程。每秒能生成多少 Token叫“输出速度”或“生成速度”。DeepSeek-V3 的生成速度大约 30-60 Token/秒取决于部署方式。如果一段回答有 500 个 Token大约需要 8-17 秒。这就是为什么你问大模型一个问题它要“思考”几秒才开始打字然后一个字一个字蹦出来——它在逐个生成 Token。注意输入 Token 和输出 Token 的处理速度完全不同。输入Prompt 处理可以并行计算速度快得多——10000 个输入 Token 可能 1 秒就处理完了输出必须逐个生成500 个输出 Token 要 8-17 秒。所以 API 计费时输入和输出分开算输出贵得多。5.3 上下文窗口Token 是“长度单位”大模型能“记住”的对话长度有限上限叫上下文窗口Context Window单位当然是 Token。DeepSeek-V3128K TokenGPT-4o128K TokenClaude 3.5200K TokenGemini 1.5 Pro1M Token但 128K Token 能塞多少中文取决于分词器。DeepSeek 大约能塞 20 万字中文GPT-3.5 只能塞 7-8 万字。同一个“128K”实际容量差 2-3 倍。这就是为什么很多人感觉“模型记不住前面说的话”——不是模型记忆差是对话历史已经超出了上下文窗口的 Token 上限旧消息被自动截断了。这里有个常见的误解需要澄清上下文窗口不是“对话框能显示多少条消息”而是“模型一次推理能处理的 Token 总量”。它包括系统提示词、历史对话、当前问题、以及模型要生成的回答。很多新手把对话历史全塞进去结果留给输出的空间不够模型回答到一半就断了。实操建议在构建大模型应用时始终用代码计算当前对话的 Token 总量在接近窗口上限时主动截断或摘要旧消息。主流的大模型 SDK 都提供 Token 计数功能不要靠肉眼估计。5.4 最大输出 Token模型能“说”多少除了上下文窗口输入输出总量还有一个容易忽略的限制——最大输出 Token。模型一次能生成多少 Token 是有上限的GPT-4o最大输出 16,384 TokenDeepSeek-V3最大输出 8,192 Token默认 4,096Claude 3.5最大输出 8,192 Token这意味着什么如果你让模型写一篇长文它写到上限就会自动停止不管写没写完。很多人遇到“模型回答到一半突然断了”就是踩了这个坑——不是模型不想说了是它被限制不能再说更多了。解法需要长输出时把任务拆成多轮让模型分段生成你在每轮之间传一个“继续”的指令。或者用流式输出Streaming配合后端拼接在模型停止后自动发起续写请求。实操代码用 OpenAI SDK 处理长输出的标准姿势fromopenaiimportOpenAI clientOpenAI()full_textwhileTrue:# 把已经生成的内容拼回消息里让模型接着写respclient.chat.completions.create(modelgpt-4o,messages[{role:system,content:写一篇 20000 字的中文技术文章},{role:user,content:开始写},{role:assistant,content:full_text},# 已生成的部分{role:user,content:继续},],max_tokens4000,# 每次只生成一段)chunkresp.choices[0].message.content full_textchunkif完inchunkorlen(full_text)20000:break这段代码用“接力写作”的方式突破单次最大输出限制——每次生成 4000 Token把已生成的内容塞回对话让模型接着写直到文章写完。这是所有“AI 写长文”应用的底层套路。6. 动手实验用 tiktoken 数 Token理论讲完动手跑一遍。这里用 OpenAI 开源的 tiktoken 库GitHub 19.1k stars它就是 GPT 系列分词器的官方实现。tiktoken 官方 README 里有一段值得注意的说明“On average, in practice, each token corresponds to about 4 bytes.”平均每个 Token 对应约 4 字节。这是英文场景的经验值——1 个英文单词平均 4-5 个字母约 4-5 字节大约 1 个 Token。但中文一个字就 3 字节按这个算法应该接近 1 个 Token 对应 1 个字实际却不是——因为分词器的训练语料以英文为主中文没有被充分合并。6.1 安装和基本用法pipinstalltiktokenimporttiktoken# 选择编码器# cl100k_base 对应 GPT-4 / GPT-3.5-turbo# o200k_base 对应 GPT-4o / o1 / o3 系列enctiktoken.get_encoding(cl100k_base)# 编码文本 → Token ID 列表tokensenc.encode(你好世界Hello World!)print(tokens)# 输出类似: [57668, 53901, 10236, 3827, ..., 3304, 4422, 0]# 数 Token 数print(fToken 数:{len(tokens)})# 解码Token ID → 文本无损可逆textenc.decode(tokens)print(text)# 你好世界Hello World!# 也可以按模型名自动选择编码器enc_4otiktoken.encoding_for_model(gpt-4o)# 自动用 o200k_base6.2 对比不同模型的 Token 数importtiktoken text人工智能正在改变世界大模型技术日新月异。# GPT-4 / GPT-3.5enc_cl100ktiktoken.get_encoding(cl100k_base)print(fGPT-4 (cl100k_base):{len(enc_cl100k.encode(text))}tokens)# GPT-4oenc_o200ktiktoken.get_encoding(o200k_base)print(fGPT-4o (o200k_base):{len(enc_o200k.encode(text))}tokens)# 对比英文en_textArtificial intelligence is changing the world.print(fEnglish (cl100k_base):{len(enc_cl100k.encode(en_text))}tokens)print(fEnglish (o200k_base):{len(enc_o200k.encode(en_text))}tokens)跑完你会发现两个现象同样一句中文cl100k_base 切出的 Token 数明显多于 o200k_base英文的 Token 数差异远小于中文——因为两套词表都是英文优先设计的这也是 OpenAI 在 GPT-4o 里换新词表的原因非英语用户的体验太差了同样一段话比英语用户多花 2-3 倍费用。6.3 用 HuggingFace 加载国产模型分词器如果你用 DeepSeek 或 Qwen可以用 HuggingFace 的transformers库加载对应模型的分词器fromtransformersimportAutoTokenizer# DeepSeek-V3 分词器注意DeepSeek-V3 需要 trust_remote_codeTrue# 因为它的分词器依赖自定义代码这是官方示例的标准写法tokenizerAutoTokenizer.from_pretrained(deepseek-ai/DeepSeek-V3,trust_remote_codeTrue)tokenstokenizer.encode(你好世界)print(fDeepSeek-V3:{len(tokens)}tokens)print(fToken IDs:{tokens})# Qwen 分词器无需 trust_remote_codeqwen_tokenizerAutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct)qwen_tokensqwen_tokenizer.encode(你好世界)print(fQwen:{len(qwen_tokens)}tokens)注意第一次运行会从 HuggingFace 下载模型分词器文件几十 MB需要网络。如果下载慢可以用 ModelScope魔搭社区的镜像源把from_pretrained的路径换成魔搭对应的仓库名即可。6.4 别忘了特殊 Token以上代码数的是“文本内容”的 Token 数但实际 API 调用时还有一类隐藏的 Token 消耗——特殊 TokenSpecial Tokens。每个模型在处理你的请求时会自动在文本里插入一些控制标记|im_start|/|im_end|标记一轮对话的开始和结束ChatML 格式|system|/|user|/|assistant|标记角色BOSBeginning of Sequence/ EOSEnd of Sequence序列首尾标记这些特殊 Token 也算进 Token 总数但你在界面上看不到它们。一轮对话可能多出 5-10 个 Token 的隐藏消耗。对话轮次越多这部分开销越大。# 查看 tiktoken 的特殊 Tokenimporttiktoken enctiktoken.get_encoding(cl100k_base)# cl100k_base 的特殊 Tokenprint(enc.special_tokens_set)# 输出类似: {|endoftext|, |fim_prefix|, |fim_middle|, |fim_suffix|}所以在做成本预估时给每轮对话额外预留 10-20 个 Token 的余量别算得太紧。7. 三个真坑每个都付过费坑 1你以为的“免费额度”根本不够用你看到某 API 送“100 万 Token 免费额度”心想够用一个月。结果一跑——你用 GPT-3.5 的 cl100k_base 编码器一篇 5000 字的中文文档大约消耗 8000-10000 Token。一篇就吃掉 1%。如果每篇还要让模型输出 2000 字又多 3000-4000 Token。算一下每天处理 10 篇文档每篇输入 8000 输出 3500 11500 Token一天 115000 Token9 天就花完 100 万免费额度。解法换模型前先算实际 Token 消耗。中文场景优先用 DeepSeek/QwenToken 压缩率高同样额度能用更久。按上面的例子换 DeepSeek同样 5000 字中文只消耗约 3000 Token100 万额度能用 30 天以上。坑 2上下文窗口“虚标”模型宣称 128K 上下文你以为能塞 12.8 万字中文。实际呢用 GPT-3.5 的 cl100k_base一个汉字约 1.5-2 个 Token128K 大约只能塞 6-8 万字。用 DeepSeek一个汉字约 0.6 个 Token能塞 20 万字。更坑的是有些模型的“128K 上下文”是指输入输出合计。你以为还能再让它输出 2 万字实际上输入已经把窗口挤满了输出吐了几个 Token 就被截断。解法用目标模型的分词器实际计算你的文本 Token 数别信“1 Token ≈ 1 个字”这种粗略估算。给输出预留足够的 Token 空间别把上下文窗口塞满。坑 3换模型 换刀法Token 数会变你用 DeepSeek 跑通了一个流程Prompt 精心设计成 4000 Token 以内。换 GPT-4o 后一测——同样 Prompt 变成 6000 Token直接超出某些限制。更隐蔽的情况你从 GPT-4 换到 GPT-4o以为同是 OpenAI 系列没事。结果 GPT-4 用 cl100k_baseGPT-4o 用 o200k_baseToken 数不一样。你的 Prompt 里如果有很多中文GPT-4o 的 Token 数会减少词表大了压缩率高了如果有很多英文变化不大。解法切换模型前用目标模型的分词器重新数一遍 Token。OpenAI 系用 tiktokenHuggingFace 系用transformers.AutoTokenizer国产模型用官方 SDK。把它做成一个自动化检查脚本切模型之前自动跑一遍。8. 经验清单带走这 5 条就够了Token 是大模型的最小单位计费、上下文窗口、输出长度、推理速度全以 Token 计。搞不懂 Token你连账单都看不懂。不同模型对同一句话切出的 Token 数可能差 2-3 倍国产模型中文压缩率比 GPT-3.5 高 2-3 倍。比价时必须按等量文本换算不能直接比每百万 Token 单价。BPE 的核心逻辑就一句话高频组合合并成短 Token低频文本拆成碎片拼——和 ZIP 压缩是同一个道理。词表大小是效率和覆盖率的折中。遇到没见过的词BPE 拆成已知子词永远不会抓瞎。永远用分词器实际数 Token不要用字符数估算1 个中文字在 GPT-3.5 里是 1-2 个 Token在 DeepSeek 里可能只有 0.6 个。估算误差能让你的成本预算翻倍。切模型 换刀法同一个 Prompt 在不同模型里 Token 数不同即使同是 OpenAI 系列GPT-4 和 GPT-4o 的分词器也不一样。迁移模型前用目标模型的分词器重新数一遍 Token防止上下文超限。下篇预告下一篇《大模型实战指南2——上下文窗口为什么聊着聊着模型就“失忆”了》1M 上下文到底能不能塞下一整本书为什么模型说“忘了”前面的对话KV Cache 怎么让长文本推理不死等注意力机制的计算量为什么随 Token 数平方增长系列大模型实战指南篇篇连载从 Token 到 Agent带你从零搞懂大模型。关注不迷路。本文所有数据基于 2026 年 8 月公开信息整理。词表大小和分词算法来自官方文档/技术报告OpenAI tiktoken GitHub 仓库github.com/openai/tiktoken19.1k stars、DeepSeek-V3 技术报告arxiv.org/abs/2412.19437、Qwen 官方文档。Token 换算比例为实测估值具体数值取决于模型版本和分词器配置。