code2prompt 中的分词与 Token 计数基于 tiktoken-rs 的 Tokenizer 实现与估算机制【免费下载链接】code2promptA CLI tool to convert your codebase into a single LLM prompt with source tree, prompt templating, and token counting.项目地址: https://gitcode.com/GitHub_Trending/co/code2prompt本文围绕 code2prompt 官方文档中“Tokenization in Code2Prompt”俄文版 / 英文版展开讲清两件事其一code2prompt 如何用 tiktoken 系列编码器为代码库生成面向大语言模型的 prompt其二你看到的 token 计数为什么是一个估算值以及源码中“并行逐文件计数 空内容骨架模板”的估算算法究竟如何工作。读完后你可以准确选择适合目标模型的编码--encoding并理解token_count数值的构成与误差来源。什么是 Tokenizer与语言模型打交道时文本必须先被转换成模型能理解的格式——token本质上是数字序列。完成这一转换的组件就是tokenizer分词器。它把原始文本切分为 token而 token 可以对应完整的单词、词子片段subword甚至单个字符具体取决于分词器的设计。code2prompt 选择了tiktoken作为分词器。它是 OpenAI 官方开源的 BPE 分词实现高效、稳定并针对 OpenAI 系列模型优化。若要进一步理解 BPE 分词的原理可以自行查阅 OpenAI Cookbook 中关于 tiktoken 的计数示例笔记或 fast.ai 上 Karpathy 关于从零构建 tokenizer 的技术文章。code2prompt 的实现tiktoken-rs在 Rust 生态中code2prompt 通过tiktoken-rstiktoken 的 Rust 端口完成分词核心逻辑集中在 tokenizer.rs 这一个模块中。该模块用CoreBPE类型封装了 tiktoken 支持的 5 种编码器并定义了TokenizerType枚举与计数入口函数count_tokens/// Tokenizer types supported by tiktoken. #[derive(Debug, Clone, Copy, PartialEq, Eq, Default, Serialize, Deserialize)] pub enum TokenizerType { #[serde(alias o200k)] O200kBase, #[default] #[serde(alias cl100k)] Cl100kBase, #[serde(alias p50k)] P50kBase, #[serde(alias p50k_edit)] P50kEdit, #[serde(alias r50k)] R50kBase, } pub fn count_tokens(rendered: str, tokenizer_type: TokenizerType) - usize { // 按类型取出惰性初始化的编码器编码后取长度 let token_count bpe.encode_with_special_tokens(rendered).len(); token_count }编码映射表CLI 参数、编码器与适用模型官方文档给出的映射关系如下是选择编码时的权威参照CLI 参数编码器名称适用 OpenAI 模型cl100kcl100k_baseChatGPT 系列模型、text-embedding-ada-002p50kp50k_base代码模型、text-davinci-002、text-davinci-003p50k_editp50k_edit编辑类模型如text-davinci-edit-001、code-davinci-edit-001r50kr50k_base或gpt2GPT-3 系列模型如davincigpt2o200k_baseGPT-4o 系列模型选择原则很简单用目标模型所用的编码器来数 token得到的计数才与该模型的上下文窗口、计费口径一致。例如 prompt 最终要喂给 GPT-4o就应选o200k_base口径喂给 ChatGPTGPT-3.5/4 系则用默认的cl100k_base。源码中的默认值与解析细节从源码结构看几个值得注意的实现细节默认编码是cl100k_base。TokenizerType枚举在Cl100kBase上标注了#[default]见 tokenizer.rs#L26-L39即不指定--encoding时按 ChatGPT 口径计数。CLI 侧通过 serde 解析编码名。args.rs 中--encoding参数声明为/// Token encoding to use for token count #[clap( long, value_name cl100k, p50k, p50k_edit, r50k, value_parser ValueParser::new(parse_serde::TokenizerType), )] pub encoding: OptionTokenizerType,解析依赖serde(alias ...)o200k是O200kBase的别名cl100k、p50k、p50k_edit、r50k同理。也就是说 CLI 上写cl100k和写枚举全名都能被接受。 3.编码器实例做了进程级缓存。5 个OnceLockCoreBPE静态量保证每个编码器只初始化一次后续count_tokens调用直接复用tokenizer.rs#L69-L97避免重复加载 BPE 词表的开销。 4.可开启分词计时日志。设置环境变量DEBUG_TOKENIZER后每次计数会以 debug 级别输出字符数与耗时tokenizer.rs#L99-L105方便排查大仓库下的性能问题。 5.配置文件中同样可持久化编码。核心配置结构 configuration.rs 中的Code2PromptConfig持有pub encoding: TokenizerType字段配置文件里写入的编码值会覆盖默认值与 CLI 参数共同决定计数口径。报告值为什么是“估算”token 计数的计算流程官方文档明确提示你看到的 token 数是一个估算值estimate。CLI 与 TUI 会把它标注为 estimated而 JSON 输出中的token_count字段保留原名称。误差来源和计算方式可以从源码完整还原。第一层逐文件并行分词真正的逐文件分词发生在文件处理阶段而不是最后对完整 prompt 再数一遍。在 path.rs 中文件经处理器处理后先被包装成代码块含可选行号随后在并行管线里计数// Cache the formatted contents tokens during parallel file processing so // prompt estimates include line numbers without tokenizing the full output. let token_count count_tokens(code_block, config.encoding);文件遍历使用 rayon 的par_iter()并行执行path.rs#L176-L189因此每个文件的token_count已经包含了处理结果与行号。这个逐文件计数被缓存在FileEntry结构中path.rs#L42后续的 prompt 汇总直接求和不会重新对完整 prompt 做分词。第二层模板开销的骨架估算prompt 除了文件内容还有模板结构开销目录树、Git diff/log、文件头、代码块围栏等。对整份渲染结果再分词一次代价很高code2prompt 的做法是——用“空文件内容”把模板渲染成一个骨架再对骨架分词session.rs#L469-L545 的calculate_structural_tokens为每个已选文件构造一个结构相同、但code为空字符串的FileEntry保留路径、扩展名、元数据甚至保留entities以便 code map 被计入用这个骨架上下文渲染完整的 Handlebars 模板自定义模板或内置的 default_template_md.hbs / default_template_xml.hbs对渲染出的骨架调用count_tokens得到结构开销的近似值。最终的估算公式在calculate_estimated_token_count中一目了然fn calculate_estimated_token_count(self, tokenizer_type: TokenizerType) - usize { let files_token_count: usize self .data.files.as_ref() .map(|files| files.iter().map(|file| file.token_count).sum()) .unwrap_or(0); let structural_tokens self.calculate_structural_tokens(tokenizer_type); files_token_count structural_tokens }即估算值 Σ(各文件 token 数) 骨架模板 token 数该值由render_prompt写入输出的token_countsession.rs#L412-L447。第三层渲染失败时的兜底启发式如果骨架渲染失败模板编译或渲染报错代码退回到fallback_structural_estimatesession.rs#L558-L590统计目录树与各 Git 输出的总字符数按每 4 个字符约 1 个 token粗略估算并加 100 的头部缓冲若这部分总字符不足 10000则改为直接拼接真实文本精确分词。误差从哪来文档给出的三条提醒官方文档对估算值有三条重要限定值得原样理解token 边界不跨片段可加。文件 token 数与模板 token 数分别计数再相加但真实拼接后 BPE 的合并/切分边界可能变化因此和值与真实整体分词结果会有出入模板转义与条件渲染会改变结果。自定义模板若省略、重复或条件化渲染内容骨架估算与实际渲染的差异会被放大估算不是上界保证。它只用于成本预估与容量规划不能作为“一定装得进上下文窗口”的承诺。另外当输出格式为 JSON 时token_count估算的是内嵌 prompt 本身外层 JSON 信封prompt、files、code_map等字段以及序列化时的字符串转义都不计入。这正是文档强调“token_count字段保留其名称、且 CLI/TUI 将其标注为 estimated”的原因。实操如何选择与查看 token 计数生成 prompt 时常用选项组合如下编码与计数格式选项定义见 args.rs# 按 GPT-4o 口径计数并以人类可读格式展示估算值 code2prompt --encoding o200k --token-format format # 按默认 ChatGPT 口径cl100k_base机器可解析地输出计数 code2prompt --token-format raw--encoding接受文档映射表中的编码名含o200k/cl100k/p50k/p50k_edit/r50k等 serde 别名省略时默认cl100k_base--token-format接受raw机器可解析或format人类可读两种输出格式也可以在配置文件中写入encoding字段固化口径由 configuration.rs 中的Code2PromptConfig.encoding承载输出 JSON 模式下token_count与model_info由TokenizerType::description()生成如 cl100k (ChatGPT)一并给出便于脚本消费时确认口径。TUI 中还存在两种分析视角与这套估算直接对应见 session.rsraw_analysis直接对各文件token_count求和反映“纯代码库”口径contextual_analysis则基于渲染后 prompt 的估算值含模板开销两者的差值恰好近似模板结构所占的 token。小结code2prompt 的分词体系可以概括为三条主线编码选择通过 tiktoken-rs 支持cl100k_base、p50k_base、p50k_edit、r50k_base、o200k_base五种编码器默认cl100k_base用--encoding对齐目标模型高效计数文件内容在 rayon 并行管线中逐文件分词并缓存避免对完整 prompt 的重复分词诚实的估算模板开销用“空内容骨架渲染”近似渲染失败时退回字符启发式并明确告知使用者该值非精确值、非上界JSON 信封不计入。理解这几点后你就能把token_count当作成本规划工具正确使用对齐模型编码选口径、用 raw/format 两种视图做核对并在需要严格控制上下文窗口时预留估算误差的空间。【免费下载链接】code2promptA CLI tool to convert your codebase into a single LLM prompt with source tree, prompt templating, and token counting.项目地址: https://gitcode.com/GitHub_Trending/co/code2prompt创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
