开门见山说一个我最近特别有感触的事做 LLM 应用的这两年“Token”这个词几乎每天都要跟人解释一遍。跟算法同学聊是 tokenizer 的输出单位跟后端聊是计费账单上的数字跟产品聊是上下文窗口能塞多少字。到了中文用户这边大家更习惯直接叫“词”“字”“块”甚至有人叫“切片”——说法百花齐放但始终没有一个能让人一眼就懂、一拍即合的正式叫法。最近这个词的中文表述开始逐渐收敛越来越多技术文档、模型卡和开发者社区里大家开始统一使用“词元”这个名称。我自己的感受是这名字起得是真好既保留了“词”“元”两层含义又不像“令牌”那样容易让人联想到安全认证里的 token更不会让新手误以为它就是英语单词。这篇文章我就从实际开发的角度把“词元”这个概念从头到尾掰开揉碎讲清楚——它到底是什么、大模型是怎么把它切出来的、日常开发里为什么计算词元数总是容易出错以及“词元”这个叫法统一之后对我们写文档、调接口、做评测到底意味着什么。1. 从“Token”到“词元”为什么我支持这个词落地先说一个可能反直觉的事实大模型真正在“读”的从来就不是字也不是词而是词元。模型并不认识“你好世界”这四个字它只认识这四个字被切分后映射成的一串 ID。过去大家叫“Token”的时候问题还不大毕竟英文语境里 Token 的含义本来就有点暧昧——可以是词、可以是标点、可以是一段子串。但一旦翻译成中文就出乱子了。1.1 “令牌”“词元”还是“碎片”翻译里的门道我见过最要命的翻译是“令牌”。这个词在计算机安全领域已经被用滥了——访问令牌、刷新令牌、JWT Token全是“令牌”。如果大模型领域里的 Token 也叫“令牌”那新手真的会懵你说“给模型生成一个令牌”他以为你要做鉴权。而“词元”不一样它一上来就把两件事说清楚了第一这东西跟“词”有关不是纯随机的符号第二“元”意味着它是最小单元不可再分割。这个翻译的核心价值在于“名正言顺”。命名一旦稳定概念就会跟着稳定下来。以前我写技术文档头一次出现 Token 总得加个注释“也叫词片、词块、令牌”非常啰嗦。现在直接写“词元”读者马上能建立一种直觉这玩意儿是构成语言的基本粒子。类比一下化学里的“原子”、物理里的“量子”、汉字里的“字根”“词元”走的正是这种最小构成单元的命名路线。1.2 术语稳定对开发者的实际影响术语不稳定对普通用户影响不大但对开发者影响非常大。我举几个场景第一个是接口文档。早期很多 SDK 的中文文档里同一个参数一会儿叫max_tokens一会儿翻译成“最大令牌数”一会儿写成“最大词元数”一会儿又有人叫“最大分词数”。排查问题的时候特别痛苦——你根本不知道文档里说的“令牌”指的是计费单位还是模型输出的内容单位还是某个框架里的特殊 token比如|endoftext|。第二个是社区交流。我在几个技术群里见过这样的对话A 说“我的上下文窗口 4096 个 token”B 说“我的窗口能装 8000 汉字”C 说“我用了 2048 个词片”——三个人说的其实是同一件事但没法直接比较。如果大家都用“词元”来统一表述沟通成本直接下降一半。第三个是评测和复现。论文里写“训练数据包含 1.4T tokens”不同团队对 token 的理解可能完全不同。有的按字符切有的按子词切有的把标签格式也算进去。中文术语统一为“词元”之后至少大家可以用同一个词去对齐方法论。我自己现在写文档、写代码注释、做技术分享全部改用“词元”指代 Token并且会刻意避免使用“令牌”这个历史遗留翻译。这属于约定俗成的术语迁移短期看有点不适应但长期看非常值。2. 词元到底怎么切出来的从分词算法到中文的麻烦要把“词元”搞透彻光有名字还不够得知道它怎么来的。大模型启动之前第一步永远是把原始文本切成词元序列——这一步的专业术语叫 Tokenization现在可以更自然地说“词元切分”或“词元化”。很多做应用开发的同学以为切词是小事其实里面坑多得很。2.1 从 BPE 到字节级分词词元化的大致演化当前主流大模型采用的分词算法大多数是 BPEByte Pair Encoding字节对编码或者它的变体。BPE 的核心思路非常朴素但也很聪明从单个字符/字节开始反复统计相邻符号对的出现频率把最高频的对合并成一个新符号直到达到预定的词元表大小。我用一个小例子说明。假设有一批文本里全是“开发”“开放”“发开”这些词初始时都是单个字开、发、放。第一步统计相邻二元组“开发”出现了 100 次、“开放”出现了 80 次、“放开”出现 50 次。于是先把“开发”合并成一个词元。第二步可能再把“开放”合并。这样继续迭代最后词元表里就有了“开发”“开放”这种复合词元而不再是孤立地使用“开”和“发”两个单独的字符。到了 GPT 这一类模型分词器进一步演变成字节级 BPE。什么意思就是把切分的基本单位从一开始的字符降到了 UTF-8 字节。这样做的好处是不管什么语言、什么编码、什么特殊符号理论上都能用一个固定大小的词元表覆盖不会出现“某个生僻字不在词表里导致训练失败”的尴尬。代价就是同一个文字在不同上下文中可能会被切出完全不同的字节组合中文尤其明显。2.2 中文在切词元时的“四不像”困境中文是表意文字一个“字”本身就有意义但切词元的时候并不按语义切。分词器眼里没有“意思”只有“统计频率”。这导致中文词元切分有几个显著特点单字词元很多。像“的”“了”“一”“是”这种高频字通常都是独立词元因为出现频率太高算法不会把它们跟别的字合并。多字词元分布不均。常见词如“中国”“我们”“问题”会被合并成单个词元但稍微冷门一点的组合就未必。英文和数字切法完全不同。英文单词往往能整体成为一个词元“chat”是一个词元但“chatbot”这种偏长的词可能被切成“chat”和“bot”两个词元。数字也是一个长数字串会被切成好几段因为模型在训练语料里没见过那么长的连续数字组合。这里有个实操层面的重要结论中文文本的词元效率在“字”和“词”之间摇摆。对纯中文文本平均一个汉字大概会对应 0.6 到 1.5 个词元具体取决于词表、分词算法、以及文本里混入多少英文和数字。很多模型的中文词元效率做得越来越好但依然存在“同样的意思换个表达方式词元数差出一大截”的现象。2.3 特殊词元的角色不只是“切出来的碎片”除了普通文本词元还有一类特殊词元必须单独讲。它们不参与“语言内容”的表达但参与模型的结构控制。比如|im_start|、|im_end|这类角色标记告诉模型下面这段是谁在说话|endoftext|表示文本结束有的模型用pad做定长填充工具调用场景还会用tool_call之类的标记。这部分词元非常消耗上下文却经常被忽略。有一次我排查一个诡异的生成中断问题发现是开发者把max_tokens设置得很小但没考虑角色标记、系统提示词拆分、以及/s结束符都要占词元名额导致模型还没说完就被强制截断了。使用词元化的思维来看这个问题就非常清晰所有你“喂”给模型的东西——包括消息模板、角色绑定的标签、停止符——都会变成词元都要算进上下文和生成上限里。3. 词元计算的实际陷阱日常开发中容易错的几个位置如果说“词元是什么”是理论课那“怎么数词元”就是必修的实践课。这一部分我敢说大部分 AI 应用开发者都踩过坑包括我自己。词元数错了轻则计费不准重则请求直接失败甚至会把上下文塞爆。3.1 服务端按字符限制但底层按词元限制很多模型服务对外提供的接口声称“支持 2000 个字符”但实际上模型的上下文窗口是按词元算的。中间有一层服务会把用户的文本转成词元再传给模型。问题就出在这不同文本的“字符数 词元数”换算比完全不一样。我自己写过一个测试脚本用同一个模型的分词器分别统计几种文本文本类型原始字符数词元数平均字符/词元纯中文新闻稿500 字约 380约 1.32纯英文博客500 字符约 130约 3.85中文大量代码800 字符约 720约 1.11邮箱/URL密集文本300 字符约 240约 1.25这些数字不是敲定的结论不同的分词器差异很大但规律是稳定的字母型语言平均一个词元能吃下 3 到 4 个字符中文往往 1 个汉字就接近 1 个词元甚至更多混合代码的场景最耗词元。所以如果某个平台限制的是“字符数”但你调大模型时底层按词元切分你的输入一旦包含大量中文或代码就会比预想中更早撞到上限。应对办法只有一个别信“字符数”——直接用官方分词器自行统计词元数。3.2 模型回答长度、停止符和计费边界的纠缠还有一个非常隐蔽的坑回答侧的词元计算。有些模型计费只算“生成的完成部分”有些会把提示词和回答都算进去有些还会额外算“系统框架消耗”。我之前对接一个模型服务发现平台文档上写的是“按总词元计费”但实测却发现同样的提示词在多次请求中计费不一样。排查很久才发现平台在数据统计里把每一次消息携带的消息元数据、时间戳、甚至 API 密钥占位符都算成了词元。这不是模型算法的问题是平台计费口径的问题。说这些不是教大家去钻空子而是提醒在集成任何模型服务之前应该自己用一套标准测试集去确认“词元在哪里被数了”避免业务上线之后账单和心理预期完全对不上。3.3 切分不一致带不带空格、换行符、BOM 头词元切分有一个在传统字符串处理里几乎不会注意的问题相邻词的边界空格会影响词元数量但不会影响语义。很多分词器会把“hello world”和“helloworld”切成不同数量的词元前者可能因为空格的存在被整体识别成“hello”加“world”两个词元后者可能因为训练语料里没见过而被切成一堆碎片。这种特性和业务逻辑叠加之后会非常折磨人。我之前做过一个文本相似度功能想把一段核心内容去重按照“先分词元再比较特征”的方式实现。结果发现两段语义完全相同、只差一个换行符的文本切出来的词元序列差异巨大。后来老老实实先做了文本归一化去掉多余空格、统一换行、统一全半角再送进分词器词元层面的对比才稳定下来。3.4 用分词器自测一个通用的统计脚本不管用的是哪家模型最稳妥的词元统计方式就是拿到官方分词器来跑。主流模型一般会开源分词器或者提供 tokenizer API。下面是一段我用着很顺手的示例脚本用的是常见的 transformers 库风格但逻辑可以通用到任何分词器from transformers import AutoTokenizer # 换成你实际用的模型名这里只是示意 tokenizer AutoTokenizer.from_pretrained(你的模型标识) def count_tokens(text: str) - int: # 注意务必确认 add_special_tokensFalse # 否则会把 [CLS]、[SEP] 这类特殊词元也算进来 # 而实际接口调用时这些词元可能在消息模板里另算。 return len(tokenizer.encode(text, add_special_tokensFalse)) test_text 这是一段中文测试文本顺便混入一些 English 和 code: fn(x) - x 1 print(count_tokens(test_text))实操下来有两点值得注意一是分词器版本要跟着模型版本走模型更新后词表变了词元统计结果会随之变化二是真实请求环境里的 prompt 通常会包含多轮消息和格式标签不能只看单条文本的词元数。正确的做法是模拟一次完整的请求构造把整个消息序列全部拼好再统计总词元数。4. 上下文窗口与词元预算把“装得下”变成“算得清”所有做大模型应用的团队早晚会遇到同一个问题上下文窗口看着很大但实际用起来怎么都装不下。这个问题的根源往往是大家把“窗口大小”理解成了“能写多少字”而没有把它理解成“词元预算”。4.1 一个完整的词元预算长什么样假设一个模型有 8192 词元的上下文窗口。很多人以为任务是“用户最多能输入 8000 字”但实际上完整请求里的词元消费包含这些系统提示词通常 500 到 2000 词元取决于你写了多少“角色设定”“安全策略”“输出格式要求”历史对话记录每保存一轮就要吃几十到几百词元最新用户消息这是业务真正关心的部分内部消息结构标签比如开始符、结束符、角色标记几十词元回答保留区如果设置max_tokens 2048那这 2048 必须从窗口里提前扣除。算下来真正留给用户单次输入的空间可能只有 3000 到 4000 词元甚至更少。这不是模型不行是预算规划没做。我现在做系统设计一律先画一张“词元预算表”每个环节占多少、最大允许膨胀多少、超限之后怎么降级截断历史、压缩摘要、拒绝输入。4.2 历史记录为什么要做“压缩”而不是“一切了之”处理长对话时最朴素的做法是“超出窗口就丢掉旧消息”。但直接丢的问题在于模型对上下文的依赖是连贯的丢了前面的关键信息后面回答质量会断崖式下降。我尝试过另一种思路——把早期对话定期改写成摘要词元。差不多每五轮对话结束就把这五轮的主要内容浓缩成 200 词元的摘要塞回历史记录里。这样窗口里始终有“旧信息”但只占很小的词元预算效果明显比彻底丢弃好。摘要本身也得花词元。所以团队里要约定一个节奏新增对话到一定轮次后先拿旧的完整消息去生成摘要这次生成不记入用户可见的对话成本但要计入系统开销然后删掉被摘要覆盖的原始消息再继续业务对话。这个机制听起来简单实现时要注意摘要的生成本身会消耗上下文——所以通常建议摘要任务用单独的短窗口调一次模型再把摘要结果塞回主对话而不是在主窗口里既聊业务又生成摘要。4.3 动态调整 max_tokens 的一些经验回答长度参数max_tokens很多人习惯直接写死。比如统一设 1024结果短问题也等半天长问题又总被截断。我的建议是根据用户输入和意图动态设定需要写代码、写文章、做详细分析的任务预留更高的回答词元只需要分类、打分、抽取关键信息的任务把回答词元降到极低比如 128。这样不仅提高响应速度还减少“模型把词元预算浪费在离题废话上”的情况。还有一个细节如果回答被截断很多 SDK 不会主动告诉你“我截断了”它只会返回一段看起来没写完的文字。所以响应对象里那个finish_reason字段一定要看。finish_reason length就是典型的词元预算耗尽信号这时要提示用户“结果不完整”而不是把截断的内容当完整答案缓存起来。5. 统一的“词元”称呼正在重塑文档、接口与团队协作概念上的命名统一表面看只是翻译问题实际上会影响整个技术生态的使用方式。最近的一个明显变化是越来越多的模型卡、API 文档和开源项目开始直接使用“词元”而不是“Token”或“令牌”。这个趋势一旦形成带来的连锁反应比多数人想象中更实在。5.1 文档里的“对象名”终于稳定了早期接各种模型 API最烦的就是文档术语混乱。同一份文档里max_tokens被翻译成“最大令牌数”错误提示里又出现“token length exceeded”社区帖子里则是“词元数超了”。新手排查一个报错要在中英文三个名词之间来回换算。现在统一叫“词元”文档和代码里的注释可以完全对齐max_tokens就是“最大生成词元数”input_tokens就是“输入词元数”。这种对齐能显著降低 API 接入的门槛。我有一次给某跨平台系统做模型能力封装内部抽象了一个词元计数接口职责是把任意字符串转成标准词元序列。以前这个接口的命名用的是“TokenCounter”代码注释里还要解释“这里的 Token 不是认证令牌”。现在直接叫“词元计数器”团队里新来的同学看名字就能理解功能。这是一种很微妙但很重要的体验改进。5.2 评测指标从“以词论”到“以元论”对做模型评测的人来说术语统一的帮助更大。以前评估“模型回答是否比另一个模型更简洁”大家说的是“用了多少 token”但不同分词器算出来的 token 数没有可比性。叫成“词元”之后评测报告里的单位就固定下来了报告写“平均回答词元数”而不是“平均 token 数”。既然要对比单位就必须一致。术语统一强制这种一致性。我最近在做一个文本生成的加权计费系统核心成本模型就是“输入词元数 × 单价 输出词元数 × 单价”。以前系统里既有“char_count”字段又有“token_count”字段两者关系非常隐晦。现在我把计费模块的字段统一改成“input_unit”“output_unit”“unit_type词元”配合“词元/字符比”的换算函数整个成本核算链路清晰多了。5.3 一个让我印象深刻的协作细节有次跟某团队合作做一个大模型知识库问答功能对方在对接文档里写“我们按 tokens 计费但统计的是字符串长度”。两边为这个“字符串长度”争论了很久——他们说的是 UTF-8 编码的字节长度我们说的是词元数两者差了一倍多。最后靠“词元”这个词把概念钉死先约定好统一使用“词元”再各自用官方的分词器统计把统计口径用单元测试固化下来。从那以后我发现团队协作中最大的成本往往不是技术实现而是“同一个东西叫法不一样”。词元这个命名落地后这种扯皮会越来越少。6. 入门者的“词元”速查表与我的实操建议最后给刚接触大模型开发的朋友整理一张速查表把最容易混淆的点一次性说清楚。这也是我在这两年反复跟新人解释的高频问题。问题结论一个汉字等于几个词元多数主流分词器是 0.6 到 1.5 个中文纯文本通常一汉字约一个大半或一个整词元一个英文单词等于几个词元高频短词约 1 个长词/生僻词可能是 2 到 4 个词元数能直接从len(str)推算吗不能必须用分词器统计规则估算只能用于粗粒度预算最大上下文窗口是什么指模型能处理的总词元数包括输入、历史记录、输出和结构标记回答被截断怎么办检查返回状态里的结束原因区分“自然完成”和“长度耗尽”为什么计费和我预期差很多大概率是计费口径包含了消息模板、角色标记或历史消息的重复计数基于这些经验我给大家三条最朴素的建议第一所有跟词元相关的代码里一定要保存“当时使用哪一版分词器”的元信息。模型一升级词表一变历史数据里的词元统计就没法直接对比了。保存元信息是成本最低的保险。第二别试图手工“节约词元”。有些开发者为了让文本更省词元把中文缩写、去掉标点、压缩空格结果模型反而因为缺少语法边界而表达变差。真正该做的是选择合适的上下文压缩策略和摘要机制而不是在单个词元的边际上抠抠搜搜。第三教学相长。我自己带新人时会让他们亲手走一遍“原始文本 → 分词器切分 → 词元序列还原 → 结合特殊词元构造完整请求”的全流程。只要跑过一遍之后再也不会犯“上下文字符数”和“词元数”混为一谈的错。词元这个概念看着简单一旦真的理解透了模型输入输出的很多问题都能提前避开。我的体会是起一个好名字本质上就是把一个原本模糊的概念框进了清晰的边界里。“词元”这个词比“令牌”精准比英文 Token 亲民比“词块”“词片”严谨值得在中文技术社区里推广开来。以后不管是写文档、调接口还是跟团队对齐我都会坚持用这个词也希望越来越多的开发者一起把它用起来。
