Emu3.5：vision、text 的vocab id 体系

Emu3.5 中视觉与语言 ID 体系的完整分析报告https://huggingface.co/BAAI/Emu3.51. 报告目的本文专门回答一个问题：Emu3.5 中，图片在进入大模型之前，视觉 tokenizer 的离散索引、视觉 special token 字符串、以及LLM 最终接收的统一词表整数 id，三者之间到底是什么关系？本文将给出：视觉与语言 ID 的完整分层解释codebook 索引与 LLM 词表 ID 的区别|extra_200|、|image start|、|image token|、|image end|、|visual token 000012|等 token 的精确定义一个完整不省略的数据示例一组可以直接算出的精确整数 id2. 先给结论Emu3.5 里和“图像”有关的 ID，其实分成三层：第 1 层：视觉 codebook 索引这是 vision tokenizer 真正量化出来的二维整数网格。例如：[ [12, 48001, 7], [83, 640, 99999] ]这里的12、48001、7、83、640、99999都是视觉 codebook 索引。它们的范围大致是：0 ~ 131071因为 Emu3.5 论文中明确写了视觉词表大小是131,072。这表示 codebook 里共有 131072 个离散视觉条目。第 2 层：视觉 special token 字符串二维视觉索引网格不会直接把[12, 48001, 7, ...]这种整数矩阵送进 LLM，而是先被格式化为字符串，例如：|visual token 000012| |visual token 048001| |visual token 000007|也就是说：codebook index =12被包装成字符串 =|visual token 000012|这一步是视觉离散索引到统一序列 token 表面形式的转换。第 3 层：LLM 统一词表整数 ID这些字符串接着还会被Emu3Tokenizer映射成真正送给 Transformer 的整数词表 ID。例如：|visual token 000012|不是最终输入张量里的文本字符串；真正进入 Transformer 的，是它在统一词表中的一个整数 ID。所以完整链路是：图像 → vision tokenizer 输出二维离散索引 → 格式化为视觉 special token 字符串 → tokenizer 再把字符串转成统一 vocab id → 作为一维 token id 序列送入 LLM3. 三类“ID”不要混淆3.1 视觉 codebook 索引例如：12 48001 99999 131071这些数字表示：“图像某个空间位置，对应 codebook 中第几个离散视觉条目。”它们是视觉内容离散化后的索引。3.2 视觉 token 的表面字符串例如：|visual token 000012| |visual token 048001| |visual token 099999|这些字符串只是把视觉离散索引显式写出来的一种文本化表示形式。例如：12-|visual token 000012|48001-|visual token 048001|99999-|visual token 099999|这里的 6 位补零只是格式统一，不改变含义。3.3 LLM 的统一词表 ID例如：151846 151851 151852 151853 151866 ...这些是 Emu3 统一 tokenizer 内部使用的最终整数 token id。这才是 Transformer 真正看到的离散输入。4. 视觉 token 字符串是怎么生成的项目源码中的格式化逻辑可以直接概括为：4.1 单个视觉索引的格式化规则token_id = 12 ↓ "|visual token 000012|"规则就是 6 位补零。4.2 整个二维网格的格式化规则最终图像字符串结构是：|image start|{高