LLM Tokenization性能剖析：从正则回溯到BPE合并的优化实践-北京尧图网络

这篇文章想聊聊 LLM 推理链路里一个特别容易被低估的角色Tokenization。我是在一次给检索增强问答服务做压测时被它“绊倒”的。当时并发量一上去CPU 曲线出现一段奇怪的尖峰显存和 GPU 利用率都还好但整机负载却先被打满。一开始我怀疑是 embedding 模型的问题用 py-spy 抓了几次栈才看到大量线程陷在正则匹配和 BPE merge 的逻辑里。也就是说慢的不是模型本身而是把文本切成 token 这一步。这件事之后我把手头几个项目的分词路径都重新 review 了一遍也补了一批 profiling 和实验。这篇就把“LLM Tokenization 为什么慢”这个问题拆开讲清楚它慢在哪个环节、底层哪些数据结构决定它快不起来、实测时怎么定位以及最后怎么优化。文章偏工程向适合正在做推理服务、RAG 检索或本地小模型部署的读者想避坑的也能找到参考。1. 慢在链路里的哪个环节一张耗时段位图1.1 推理链路里的三个耗时区一次标准的 LLM 请求按时间顺序可以拆成三段输入预处理包括 tokenization、padding、attention mask 计算、模型前向计算也就是真正的 transformer 层运算、输出后处理logits 处理、采样、流式输出。大多数人压测时只盯第二段但这三段的耗时特性完全不同模型前向计算是 GPU-bound显存带宽和算力决定了下限这部分大家都很熟。输出后处理是轻量 CPU 操作采样一个 token 通常百微秒级除非用了特别重的采样器否则不是瓶颈。输入预处理是 CPU-bound而且常常是单线程的tokenization 是其中绝对的大头。如果你的服务架构是“先分词再调模型”那分词时间会直接加进首 token 延迟TTFT。模型本身算得快的时候这个前置延迟会被放得很大。举个例子一个 7B 模型在 A10 上跑 2000 token 的 prompt前向计算可能就几百毫秒但一个没优化的 Python tokenizer 对同样长度的文本做切分也可能吃掉几十毫秒这时候它已经占了不能被忽略的比例。1.2 预填充和解码阶段分词耗时的分布完全不同搞清楚“分词慢”具体发生在哪个阶段很重要因为优化手段不一样。LLM 推理分两个阶段**预填充prefill**把整段 prompt 一次性算完**解码decode**则是一个 token 一个 token 地生成。Tokenization 只发生在预填充阶段——也就是对用户输入的提示词做一次性切分。解码阶段生成 token id 之后直接查 embedding根本不会走分词器。所以如果你的服务是短 query 高频请求分词绝对耗时不高但它在请求关键路径上可能占 TTFT 的很大比例。如果你的服务是长文档问答prompt 动辄几千上万字符分词延迟线性增长这时候它就不是“毫无存在感”的小环节了。并发场景下问题更突出。分词是 CPU 密集操作多路请求同时进来时CPU 核数不够就会形成排队后端表现为“模型没跑但延迟已经上去了”。这个特性决定了后面所有优化策略的方向要么减少分词本身的耗时要么把分词从关键路径上挪开。2. 根源拆解BPE 合并与正则回溯为什么天生吃 CPU2.1 分词的底层三步主流 LLM 用的分词器比如 GPT 系列、Llama 系列、BERT 的 WordPiece在编码新文本时基本都走三步文本规范化与预切分把原始字符串做 Unicode 归一化然后用一个正则表达式把文本切成一个个“单词片段”。这一步的核心是正则引擎的匹配。字节/字符序列化对每个片段按 UTF-8 编码成字节序列。中文、emoji 这些多字节字符一个字符会膨胀成 3-4 个 byte待处理的元素数量直接翻倍。BPE/WordPiece 合并拿着训练好的词表反复把相邻字节/字符的最高频组合并成更大的 token直到不能合或者 token 数满足上限。很多人以为慢在第三步但实测你会发现第一步正则匹配常常比 BPE 合并还吃 CPU。原因接下来说。2.2 BPE 合并的串行流程与复杂度BPE 合并是一个天然串行的过程。训练好的 tokenizer 里有一个 merge 规则表比如(h, e) - he它记录了每一步应该合并哪些相邻 pair。编码时算法先初始化所有字节/字符对然后按照训练时的顺序不断找到当前“还能合并且 rank 最高”的 pair 进行合并合并完再更新相邻关系继续找下一个。从这个流程能看出两个耗时点每合并一次都要在局部范围内重新评估相邻 pair 的优先级完全并行的难度很大。合并轮数取决于文本长度。一个 5000 字节的文本可能要执行上千次合并操作每一步都涉及字典查找、数组更新、边界判断。原始的朴素 BPE 实现在这一步通常用“每轮都扫一遍词表找最优 pair”的办法复杂度可以到 O(n×V) 甚至更糟n 是字节长度V 是词表大小。好在工业实现不会这么傻。OpenAI 的 tiktoken 用了一个很关键的手段把训练好的合并规则转成一张 rank 表用整数 ID 存相邻 pair编码时直接查表决定合不合并把大部分工作压成了内存中连续的数组操作同时核心合并循环用 C 实现避开 Python 解释器的开销。这也是为什么纯 Python 手写的 BPE 和 tiktoken、tokenizers 这种底层用 C/Rust 的实现性能能差出一个数量级的原因。同样的文本前者可能跑几十毫秒后者可以压缩到几毫秒。2.3 正则 alternation 和特殊分支是隐藏的“回溯陷阱”预切分用的正则表达式看起来只是一个 pattern实际非常复杂。GPT 系列 tokenizer 的预切分 pattern 是一长串 alternation包含缩写词、数字、标点、字母簇、空白等多类分支。正则引擎拿到文本后要在这个庞大的选择分支里找出最合适的匹配。正常情况下引擎会按顺序尝试分支很快命中某个规则但遇到一些边缘情况比如“连续标点夹着空白再夹着一串数字”引擎可能在前一个分支匹配失败后触发回退重新走另一个分支这个回退过程就带来了额外开销。最坏情况下某些畸形输入会让正则引擎进入类似“灾难性回溯”的状态虽然现代引擎针对这种 alternation 做了不少优化但并不是所有实现都能抗住。我自己实测过同一份 tokenizer 配置处理普通英文句子和处理一长串连续数字、混合空白标点的文本单条延迟能差 3-5 倍。特殊 token 分支也在拖后腿。像 “|endoftext|”“”代码块标记这些 special token分词器在每段文本里都要单独做一次查找和分支判断。平时输入里没几个 special token但正则引擎并不会因为内容里没有就跳过这个分支它总是要试一遍。注意正则预切分和 BPE 合并是叠加关系不是二选一。正则先把长文本切成片段BPE 再在每个片段上合并。所以正则切出来的片段越多BPE 要初始化的相邻 pair 也越多整个耗时是乘法关系。2.4 另一个容易忽略的因素UTF-8 多字节膨胀英文文本里一个字符等于一个字节中文、日文、emoji 则要 3-4 个字节表示。BPE 的输入单位是字节而不是字符所以同样 5000 个中文字符要处理的输入元素是 15000 个字节合并轮数和 pair 统计量都按比例上涨。这个因素解释了为什么纯英文任务和中文任务在 tokenizer 上的耗时表现差异巨大。如果你做的是中文场景分词开销天然比英文场景高 3 倍左右这不是代码质量问题是编码设计决定的。3. 实测拆解给 tokenizer 做一次完整 profile3.1 一个最小可复现的测量脚本在动手优化之前先量化。下面这个脚本用 transformers 的 AutoTokenizer 测单条文本的编码耗时同时也测 tokenizers 库原生 API 的耗时两个做一个对照import time from transformers import AutoTokenizer from tokenizers import Tokenizer text 什么是 LLM Tokenization它慢不慢这篇文章来回答。 # 方式一transformers 包装层 tok AutoTokenizer.from_pretrained(your-model-path) t0 time.perf_counter() for _ in range(200): ids tok.encode(text) t1 time.perf_counter() print(ftransformers encode avg: {(t1 - t0) / 200 * 1000:.3f} ms) # 方式二直接用 tokenizers 库 tok_fast Tokenizer.from_file(tokenizer.json) t0 time.perf_counter() for _ in range(200): enc tok_fast.encode(text) t1 time.perf_counter() print(ftokenizers encode avg: {(t1 - t0) / 200 * 1000:.3f} ms)如果你对哪一步慢感兴趣可以再拆细一点单独测预切分和 BPEimport re, time from tokenizers import pre_tokenizers # 只看正则预切分耗时 pre pre_tokenizers.Sequence([ pre_tokenizers.Whitespace(), pre_tokenizers.Punctuation(), ]) t0 time.perf_counter() for _ in range(200): pre.pre_tokenize_str(text) t1 time.perf_counter() print(fpretokenize avg: {(t1 - t0) / 200 * 1000:.3f} ms)这种拆法能帮你快速判断你的场景里到底是正则匹配慢还是 BPE 合并慢。3.2 不同输入特征下的耗时差异我给同一份 tokenizer 喂了几类不同特征的文本分别测了平均编码耗时。数量级不一定适用你的机器但规律是一致的输入特征字符长度相对耗时说明普通英文句子2001x基准中文句子2002.5x-4x多字节膨胀长数字串标点混合2003x-5x正则分支回退代码缩进特殊token3002x空白规则与 special token 处理长文本段落500020x-30x线性增长长文本段落那条不是吓人而是直接说明如果你做 RAG每次把整篇文档塞进 prompt分词耗时和文档长度几乎线性相关。单条慢还可以接受并发一上来就是灾难。3.3 批量并发场景下的时间放大单独测单条文本只是第一步更重要的是测并发。分词是 CPU-bound而且不少实现有锁或有不可重入的部分。你用 200 个并发请求同时打同一个 tokenizer 实例实际耗时会比单条测试的 200 倍涨得还多因为线程切换、锁竞争、内存分配都出来了。我在服务里抓过 py-spy看到的情况是十几个 worker 线程全部卡在tokenizers的 Rust 调用上但 Rust 侧又不能完全并行因为每个请求的文本长度不同短文本做完的要等长文本的。所以在做容量评估时不要只按“单次分词 xx 毫秒”来估算。正确做法是把分词放到整个请求链路的火焰图里看看它占的 CPU 时间和墙钟时间分别是多少才能在服务端做针对性的线程池调整。4. 词表、特判、并发三个容易被忽略的隐藏杀手4.1 大词表带来的隐藏成本词表大小对分词耗时有影响但影响方式不像很多人想的那么直接。如果是纯数组扫描式的实现32K 词表和 128K 词表的遍历成本肯定不一样但现代实现都用字典或哈希表单次查找是 O(1)。大词表真正拖慢的地方有两个词表加载和预热时间。128K 词表光加载 JSON 就要花不少时间服务启动时如果每次都重新解析冷启动延迟会明显变长。正则 pattern 的 alternation 变长。词表越大预切分正则里的分支通常也越多。虽然很多 tokenizer 的 pattern 是固定写的但一些训练框架会根据词表生成分支这部分一涨正则匹配的候选路径更多回退也更频繁。另外大词表模型的 embedding 矩阵变大虽然这不属于 tokenizer 的耗时但它会让 GPU 显存占用更高间接影响整体吞吐排查性能时容易把这两件事搞混。4.2 特殊 token 处理与规范化不是免费的文本进 tokenizer 之前通常还会做 Unicode 规范化。NFKC 或 NFC 这种操作会把全角字符转半角、把兼容字符做组合本身就需要遍历字符串并做字符映射。这个开销在短文本上不明显长文本上就很可观。再加一层 special token 拼接。很多服务的 prompt 模板长这样|system|你是助手|end| |user|{query}|end| |assistant|模板里的|system|、|end|每次都要和真实文本一起传进 tokenizer。tokenizer 内部会在预切分时额外识别这些特殊片段有时候还要把它们从正常 BPE 流程里摘出来单独编码。这意味着你的 prompt 模板越复杂、special token 越多固定的分词开销就越高。4.3 不同实现路径的额外开销同一种 tokenizer 配置走不同调用路径性能能差好几倍。我做过一个对照对比几种常见方式调用方式相对耗时备注transformers.AutoTokenizer.encode最慢Python 包装层特判多tokenizers 库Tokenizer.encode快Rust 实现tokenizers 库encode_batch更快批内并行llama.cpp 的 LLM tokenizer较快C 实现含依赖加载离线预分词缓存最快不走在线路径transformers慢不慢在分词算法本身而在于 Python 层的包装、配置加载、各种兼容性特判。如果你在性能敏感的服务里直接AutoTokenizer.from_pretrained()然后同步调用那就是把大量时间花在纯 Python 代码上。4.4 服务端并发模型导致分词排队最后一个隐藏杀手在服务端架构。很多 FastAPI 服务是这样写的app.post(/generate) async def generate(request: Request): prompt request.json()[prompt] tokens tokenizer.encode(prompt) # 同步阻塞调用 result model.generate(tokens) return resulttokenizer.encode是同步阻塞的放在 async 函数里会直接把事件循环卡住。高并发下所有请求都会在分词这一步排队后面的模型推理再快也没用因为请求压根走不到那一步。正确做法要么把分词放到线程池里要么干脆用独立进程做预处理后面第 5 节会展开。5. 优化方案怎么落从缓存、批处理到换实现5.1 prompt 缓存与 LRU 是投入产出比最高的一招如果你的服务存在大量重复 prompt 前缀比如固定的 system prompt、固定的 RAG 检索模板那给分词器加缓存几乎是性价比最高的优化。一个简单的 LRU 就能解决from functools import lru_cache lru_cache(maxsize4096) def tokenize_with_cache(text: str): return tokenizer.encode(text).ids注意几个坑缓存 key 用原始文本不要用 repr 或 json 序列化后的结果那会浪费内存。文本内部有细微变化就会导致缓存失效。比如带时间戳的 prompt、每次都不一样的随机占位符这类文本不适合做整段缓存。缓存的是 token id 列表不是单个 int。Python 里存一个大列表本身有内存开销maxsize 要结合平均 token 数来调。更进一步如果 prompt 是“固定前缀可变后缀”可以对前缀做缓存只对后缀做分词再把两部分 id 拼接起来。这个优化对 RAG 场景特别明显因为检索出来的文档前缀往往很长且频繁复用。5.2 用 encode_batch 代替循环式单条编码如果一次请求里有多个文本要同时分词比如 RAG 检索后要把标题、正文、摘要都放进上下文那不要用循环调用encode直接用encode_batchtexts [title, content, summary] encodings tokenizer.encode_batch(texts)encode_batch在 Rust 侧做了并行调度多段短文本可以同时在多个线程上处理比 Python 层 for 循环快很多。要注意的是批内文本长度差异不要太大否则长文本会让短文本的线程干等并行收益会打折扣。如果你的服务是单条请求多个文本段可以在预处理时把这几段合并成一个大字符串一起编码让 BPE 在更大输入上跑也能减少多次初始化开销。但合并文本要小心 token 边界问题——不同段落拼接处的 token 可能和单独编码时不一致如果你的下游逻辑依赖逐段的 token 数量就不能这么干。5.3 离线分词把耗时从关键路径上挪走这是我自己最推荐的做法。对于 RAG 这类“文档可以预先处理”的场景文档侧的分词完全没有必要放在在线请求里。你可以在离线任务里把文档切分成 chunk每个 chunk 提前编码好把 token ids 直接落库。在线请求只对 query 做一次轻量分词再拿 token ids 去向量库或索引里检索。这样做的好处不仅是快还能保证“同一份文档每次请求的分词结果一致”不会因为词典版本更新或特殊 token 配置改动导致存储的 id 和在线渲染的 id 对不上。对于在线侧如果 query 很短分词耗时基本可以忽略如果 query 也很长比如用户直接贴了几千字的文章进来那可以把格式清洗、normalization 这部分也移到异步任务里不要让主请求链路等待。5.4 换实现从 transformers 到 tokenizers 或原生 C如果你的服务已经确定用某个开源模型且不想做离线缓存那至少要确认你调用的 tokenizer 是走 Rust 还是纯 Python 路径。能用tokenizers库直接加载tokenizer.json就尽量别走AutoTokenizer。用 llama.cpp 这类 C 推理框架时分词器是原生 C 实现直接调用 LLM 的接口做 tokenize能省掉 Python 和 C 之间的数据序列化开销。如果自己写服务可以对 tokenizer 做进程级预加载避免每个 worker 启动时都重新解析一遍词表 JSON。另外可以关注一下 tiktoken 这类专门为高速分词设计的实现。它的合并逻辑用 rank 表实现核心循环是 C 代码编码速度比 Python 版 BPE 快一个量级。换实现这个步骤通常能让分词延迟降到原来的 1/3 甚至更低。5.5 并发模型的调整前面提到同步分词会卡住事件循环对应的修法是把它放进线程池from concurrent.futures import ThreadPoolExecutor tokenizer_executor ThreadPoolExecutor(max_workers4) async def generate(request): prompt request.json()[prompt] tokens await asyncio.get_running_loop().run_in_executor( tokenizer_executor, tokenizer.encode, prompt ) result model.generate(tokens) return result注意线程池大小不要盲目开大。分词器本身有锁和内部状态线程太多反而会因为锁竞争变慢。我是从 4 个 worker 开始调的短文本场景 4-8 个足够长文本场景建议直接用进程池隔离避免一个长文本分词占满线程池导致其他请求饿死。6. 踩坑笔记与我的取舍建议6.1 几个反复出现的坑第一缓存和模型不匹配。我踩过最亏的一次是换了模型版本但忘了清分词缓存旧模型的 token ids 直接喂给新模型生成结果全乱。如果要在服务里引入缓存一定把模型名称或 tokenizer 版本号拼进缓存 key否则宁可不开缓存。第二只优化了单条路径没管峰值。单条分词从 5ms 优化到 2ms 听起来不错但高并发下真正决定上限的是 CPU 总耗时长尾请求反而会因为线程排队拖垮整体延迟。优化完一定要重新压测并发场景不能只看单条 benchmark。第三中文和英文的耗时差异。如果你拿英文基准测试的结果去估算中文服务的容量通常会被严重低估。中文场景记得把多字节膨胀系数算进去最好直接用中文语料做压测。第四词表加载时间。用大词表模型时服务冷启动时间可能比想象中长。词表加载和模型权重加载是两回事但经常一起被归到“启动慢”里。要单独 profile 才能定位。6.2 我在实际项目里的取舍综合下来我会按这个优先级做第一优先确认 tokenizer 走的是 Rust/C 路径不是 Python 慢速路径。第二优先给固定前缀和常见文档段落做缓存。第三优先把离线侧文档全量预分词在线只做轻量 query 分词。第四优先调好服务端并发模型分词放线程池或独立进程。最后才是考虑换更小的词表或自定义 tokenizer因为那会影响模型效果不是纯粹的工程问题。我见过不少团队把精力花在优化注意力机制和量化上反而忽略了 tokenizer 这个每次请求都会碰到的小环节。其实分词慢这个问题只要肯花半天时间做 profiling再按上面几个方向调整通常能把整条链路的首 token 延迟降下来一个明显的档次属于投入小、见效快的优化项。说到底一个推理服务的性能不是只由 GPU 决定的CPU 侧的每一个隐性环节最终都会在延迟曲线上显形。

LLM Tokenization性能剖析：从正则回溯到BPE合并的优化实践

相关推荐

毕业论文文本修改：从低效返工到高效交付的完整攻略

从提示词工程到技能工程：用 ponytail 打造可复用的 AI Agent 技能管理方案

从混乱到稳定：AI Agent技能化改造与容器化部署全复盘

更多资讯

### 关于IP地址192.168.1.66/26子网广播地址计算的深度解析报告

WSL 镜像下载提速指南：换源、离线导入与 Docker 加速

电影剧照猜谜游戏全拆解：从玩法设计到Show HN发布实战

Google TPU架构深度拆解：脉动阵列如何铸就极致推理性能

Prometheus PromQL 查询函数完全参考：签名、语义与源码实现

LSTM航迹预测实战：从数据处理到训练调参全解析

今日更新

能源系统对接碳交易的路径：从碳核算到碳资产运营

智能硬件数据驱动运营：订单日记与预测性维护实践

逆变器下垂控制与虚拟同步机对比：Simulink仿真建模与参数整定

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？