一、背景：开源多模态模型进入“精细感知”阶段

近年来，开源多模态模型的竞争焦点正在发生迁移。早期模型比拼的是“能不能看懂图”，图像描述、视觉问答、图文匹配等粗粒度任务是主战场；而最新一批实验性多模态模型，开始把重心押在“能不能指认”上：密集计数、精确定位、区域级理解、文档版面分析等细粒度任务。这类任务对输出精度的要求，远超自然语言描述所能承载的上限，也因此催生了一条值得所有开发者关注的技术路线，视觉原语。

近期开源社区出现的一个实验性多模态模型，其分词器配置文件中的一组成对特殊 token 引发了讨论。透过这些看似不起眼的配置细节，可以还原出一条相对完整的技术设计链路。本文以通用技术视角切入，系统梳理这条路线的动机、实现方式与工程权衡。

二、两类鸿沟：“看不清”与“说不准”是两回事

分析视觉定位任务的失败案例时，需要区分两类性质完全不同的瓶颈。

1. 感知鸿沟

感知鸿沟发生在图像编码阶段：视觉编码器的输入分辨率有限，小目标、密集排列的物体在特征图上被压缩到寥寥几个像素，根本没进入模型的有效视野。这一问题的解法相对成熟——提高输入分辨率、动态切图、多尺度特征融合。当图像被切成足够多的局部区域分别编码后，“看不清”的问题可以大幅缓解。

2. 指代鸿沟

指代鸿沟更隐蔽也更根本。即便模型已经“看清”了图，它在推理时仍然用自然语言指代图中对象，“左上角的红色区域”“从左数第三个行人”“那栋高楼的屋顶”。自然语言是线性、有损且有歧义的：同一个物体有十种说法，“第三个”这类序数指代在密集场景下极易错位，“那儿”“那个”更是无从解析。当模型试图基于这些模糊指代继续推理时，比如数清一列队伍的总人数、框出路口全部斑马线，逻辑链条会在“指代”这一环系统性断裂。相关研究把结论概括为一句话：限制识别能力的瓶颈不在图像里，而在语言描述图像的方式上。

三、视觉原语：把坐标当作“无歧义指针”

视觉原语的核心思想，是在思维链中引入一组结构化记号，充当连续视觉空间中的无歧义指针。常见的三类原语分别对应三种定位粒度：

• 点：用一对坐标表示一个几何位置，适合计数、指向类任务；
• 框：用 [[x1,y1,x2,y2]] 表示一个矩形区域，适合目标定位、区域问答；
• 多边形：用一组顶点坐标表示任意形状，适合分割前置、精细轮廓描述。

此外通常还配有一个引用记号，用于把某个原语和一段文字描述绑定起来，形成“指代—坐标”的对照关系。

原语真正的价值在于它可以参与推理闭环：模型先框出一个可疑区域，再对该区域放大重看，再修正坐标，最终给出答案。整个过程里，“对象”不再是自然语言中的模糊代词，而是一串可计算、可校验、可回溯的坐标。对下游系统而言，这种输出还天然具备可解析性，用正则表达式就能把结构化结果抽取出来，直接接入业务代码。

四、拆解分词器配置：特殊 token 是结构化输出的基石

要让模型输出中稳定出现上述记号，仅靠提示词“要求”模型写出形如 的文本并不可靠：分词器可能把尖括号和单词切开、不同上下文的切分结果不一致、模型也可能漏写闭标签。业界的通行做法，是把原语登记为词表中的特殊 token，其配置通常形如：

{
  "id": 100275,
  "content": "<|box|>",
  "single_word": false,
  "lstrip": false,
  "rstrip": false,
  "normalized": false,
  "special": true
}

几个字段各有用意：

• special: true：标记为特殊 token，编码时不会被 BPE 规则二次切分，保证“一个记号就是一个原子单元”；
• normalized: false：不做大小写归一化等文本规整，避免记号在预处理中被意外改写；
• 成对开闭标签（如 <|box|> 与 <|/box|>）：为输出引入显式作用域，解析器可以按栈匹配，容错性远高于裸文本约定；
• id 连续分配：原语 token 通常占据一段连续 id，便于在采样与校验阶段统一施加约束（例如强制先开后闭）。

从开源模型的配置看，点、框、多边形、引用四类记号往往成组出现，正好对应三类原语加一个绑定记号。这是“模型原生支持结构化定位输出”的直接证据。

五、一个耐人寻味的细节：显式原语为何“消失”了

有意思的是，对这类模型做实测时，思维链中往往看不到显式的特殊 token，取而代之的是直接嵌入自然语言的坐标描述，例如“目标位于 (327, 512) 附近”。这至少存在两种解释：

1. 训练过程中的融合与内化：预训练或后训练阶段，模型学到把“开标签 + 坐标 + 闭标签”整体压缩为更简洁的坐标表达，特殊 token 退化为内部状态转移的锚点，不再出现在最终输出里；
2. 能力预留：原语 token 面向特定场景（如工具调用、定位专用的解码模式）保留，通用对话路径默认走自然语言坐标。

无论哪种解释成立，都给工程侧带来同一条启示：评测结构化定位能力时，应校验坐标本身的数值正确性（如与真值框的交并比、点位命中误差），而不是检查输出里是否出现了约定的特殊记号。能力可以换一种“皮肤”出现，评测逻辑必须跟着抽象层级走。

六、图文混排的占位符设计与 token 预算

多模态输入还有另一个容易被忽视的工程问题：图文混排时，图像内容如何嵌入文本序列。通用做法是在文本流中插入占位符，推理时再把占位符展开为该图对应的视觉 token 序列。开源模型配置中常见形如 span_0001、span_0002 的成批占位符，数量可达数百个，这就引出一笔需要算清的账：

• 占位符数量 vs 最大图片数：若配置宣称支持数百张图片，而占位符数量与之不等，一种合理解释是 span 的粒度不是“一张图”，而是“一段连续视觉片段”，同一张图可能按内容或编码窗口拆成多个 span；
• span 数量 vs 单图 token 上限：若单图编码上限是几百个视觉 token，span 数又与之对不上，则可能存在跨图共享、动态分辨率下的可变 span 长度等机制。

对应用开发者来说，不必纠结内部实现的账目细节，真正要紧的是预算公式：

总视觉 token ≈ Σ(第 i 张图的 token 数) + 占位符与分隔开销
可用文本 token = 上下文窗口 − 总视觉 token − 输出预留

举例来说：假设单图编码 384 个视觉 token、上下文窗口 32K，塞入 40 张图就会吃掉约 1.5 万 token，再叠加系统提示词与输出预留，留给用户文本的空间相当有限。多图应用的上下文规划，应当从第一行代码就按此公式估算，否则极易在长对话或批量文档场景中触发截断。

七、给开发者的工程实践建议

结合上述分析，落地高精度视觉定位能力时建议关注五点：

1. 粒度选型：计数、指向用点；定位、区域问答用框；轮廓与分割前置用多边形。粒度越细，标注与校验成本越高，按业务需求取最小充分集；
2. 坐标归一化要一致：坐标体系（0~1000 归一化、0~1 浮点、绝对像素）必须在提示词、训练数据和解析代码三处严格一致，这是实践中最高频的翻车点；
3. 解析要容错：对模型输出先按成对标签解析，失败时降级为正则抽取坐标，再失败才报错重试；不要假设模型永远输出合法 schema；
4. 评测看数值不看形式：以交并比（IoU）、点位命中率、计数误差作为核心指标，避免被“输出里有没有特殊 token”带偏；
5. 预算前置规划：多图场景按上文公式估算视觉 token 占用，为系统提示词、历史轮次和输出长度留足余量。

八、结语

视觉原语路线的价值，不在于几个特殊 token 本身，而在于它指出了一个容易被忽略的事实：多模态推理的瓶颈可能不在“看”，而在“说”。当模型学会用坐标而非自然语言来指认世界，密集计数、精确定位这类长期依赖人工后处理的任务，才真正具备端到端自动化的可能。对开发者而言，理解这条路线的设计逻辑，原语选型、token 化、占位符与预算管理，比追逐某个具体模型版本更有长期价值。