Tokenizer 为什么会成为大模型服务的 CPU 瓶颈，如何优化？

面试时怎么答

Tokenizer 瓶颈要沿模板渲染、UTF-8 预处理、编码、入队、增量解码和流式发送逐段测时，证明 GPU 是否真的在等 CPU。优化可谈 Fast Tokenizer、批量化、受限线程池和版本绑定缓存；单纯加线程可能增加切换、内存与排队。

可以这样答：

长 Prompt 或大量短请求下，GPU 可能在等 CPU 完成模板渲染、分词和流式解码。我会拆分 Encode、排队、GPU 与 Decode 耗时，确认而不是猜。优化上用 Fast Tokenizer、批量调用和受限线程池，对不可变公共前缀按 Tokenizer 与模板版本缓存。定位问题时监控分词队列、P95 编码耗时、每秒 Token、CPU 饱和度和 TTFT。

核心回答

Tokenizer 会消耗 CPU 做文本归一化、子词切分、ID 转换、Chat Template 渲染和输出反解码。当模型较小、GPU 很快、Prompt 很长，或并发中包含大量短请求时，这些工作可能比预期更显著；同步分词还会阻塞请求进入 GPU 调度器，表现为 GPU 有空闲但 TTFT 仍然升高。

正确做法是先把端到端链路分段计时，确认瓶颈在模板、Encode、队列还是 Decode。优化通常包括使用原生实现的 Fast Tokenizer、批量编码、受限的异步线程/进程池、避免重复渲染和重复计数、把 CPU 池与 GPU Engine 解耦扩缩容。缓存 Token ID 时必须绑定 Tokenizer、Chat Template、特殊 Token 和截断配置版本，否则同一文本可能得到不兼容序列。

展开说明

分词线程并非越多越好。线程数超过 CPU、NUMA 与内存带宽承载后，会增加抢占和尾延迟；进程池又有序列化成本。对输出流也要增量解码，避免每到一个新 Token 就反复解码完整序列。若 API 同时做安全扫描和复杂模板拼装，应分别记录耗时，避免把所有 CPU 时间误归因于 Tokenizer。

版本边界上，不同服务框架的 Tokenizer Pool 实现和参数会变化，采用前应以目标版本官方文档与压测结果为准。

工程实践

用真实语言、字符长度和并发分布压测，至少记录模板渲染耗时、Encode/Decode P50/P95、等待分词队列长度、CPU 核利用率、每秒输入 Token、TTFT 与 GPU 空闲比例。先消除重复工作，再调池大小；若独立扩缩容，还要给队列设置上限和背压，避免 CPU 堆积把请求延迟转移到内存。

常见追问

为什么 GPU 利用率不高，TTFT 仍可能很高？ 请求可能阻塞在网关、模板渲染、分词或调度队列，尚未进入 GPU；必须用分段 Trace 判断。
Tokenizer 结果可以长期缓存吗？ 只能在文本与 Tokenizer、模板、特殊 Token、截断策略版本都一致时复用，并遵守租户和隐私边界。
线程池和进程池怎么选？ 原生实现能释放 GIL 时线程池通常更轻；纯 Python 或隔离需求可用进程池，但要实测序列化、内存和 NUMA 代价。

一句话复习

先用分段 Trace 证明 CPU 分词是瓶颈，再用快速实现、批量化、受限并发和版本化缓存优化。

参考资料

面经主题：公开 LLM 面试题主题汇总
官方文档：vLLM Tokenizers
官方文档：Hugging Face Tokenizers