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

Emu3.5 中视觉与语言 ID 体系的完整分析报告

https://huggingface.co/BAAI/Emu3.5

1. 报告目的

本文专门回答一个问题：

Emu3.5 中，图片在进入大模型之前，视觉 tokenizer 的离散索引、视觉 special token 字符串、以及LLM 最终接收的统一词表整数 id，三者之间到底是什么关系？

本文将给出：

1. 视觉与语言 ID 的完整分层解释
2. codebook 索引与 LLM 词表 ID 的区别
3. <|extra_200|>、<|image start|>、<|image token|>、<|image end|>、<|visual token 000012|>等 token 的精确定义
4. 一个完整不省略的数据示例
5. 一组可以直接算出的精确整数 id

2. 先给结论

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 序列送入 LLM

3. 三类“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|>{高