tokenizer_config.json 逐行说明这份文件控制的是 tokenizer 的行为。模型本身不会直接读自然语言字符串，它必须先通过 tokenizer，把文本拆成 token，再映射成编号。
{
JSON 配置开始。
"add_prefix_space": false,
这表示 tokenizer 在处理文本时，不会自动在最前面补一个空格。
对 GPT-2 这类 byte-level BPE tokenizer 来说，空格是有意义的，因为“词前面有没有空格”会影响 token 化结果。
"backend": "tokenizers",
说明底层使用的是 Hugging Face 的 tokenizers 后端，而不是一个纯 Python 的简化实现。
这个后端速度更快，也更适合正式加载。
"bos_token": "<|endoftext|>",
定义 beginning-of-sequence token 的文本形式。它对应的 token 字符串是 <|endoftext|>。
"eos_token": "<|endoftext|>",
定义 end-of-sequence token 的文本形式。这里和 bos_token 一样。
这也是 GPT-2 的一个特点：它经常复用同一个特殊 token 来承担多个角色。
"errors": "replace",
表示在处理某些编码问题时，如果遇到非法字符或不兼容内容，就采用 replace 策略，而不是直接报错中断。
这是一种更稳妥的文本处理方式。
"is_local": false,
这个字段通常表示 tokenizer 最初的来源并不是“明确记录为本地构建的对象”。即使你现在把它放在本地目录里，它保存时的元信息可能仍然是 false。
这不是错误，不影响使用。
"model_max_length": 1024,
表示 tokenizer 认为模型最大可处理长度是 1024 个 token。这和 config.json 里的 n_ctx、n_positions 是对应的。
"pad_token": null,
没有定义专门的 padding token。GPT-2 原始方案就是这样，所以这里是 null。
如果以后要做 batch padding，常常需要手动把 eos_token 临时当作 pad_token。
"tokenizer_class": "GPT2Tokenizer",
说明要用 GPT2Tokenizer 这个类来加载和解释 tokenizer 文件。
"unk_token": "<|endoftext|>"
未知 token 也映射到 <|endoftext|>。这同样反映出 GPT-2 对特殊 token 的复用方式。
}
JSON 配置结束。
model_max_length、tokenizer_class、bos/eos/unk_token。add_prefix_space 这样的参数很重要。