Xiaomi-Lens-0 想接入现成 Transformer——而它的掩码解码器正是问题所在

今天 UTC 12:01，一个编号为 50028 的拉取请求被提交到 huggingface/transformers，标题是仓库里最平淡无奇的那个：“Add Xiaomi-Lens-0”。这不是一个占位实现。差异涉及 19 个文件、新增 4,251 行，其中 2,199 行是单个建模文件，另有 552 行测试和 143 行文档页面。它的状态是其中不起眼的部分——开放、未审查、未合并。其背后的模型才是有趣的部分，而它已经在 Hugging Face 上放了六天，却没有附带任何发布公告。Xiaomi-Lens-0 是一个基于 Qwen3.5-4B 构建的 4B 多模态模型，可将区域掩码写成 token；其实际后果范围有限但真实：在类似这样的变更发布之前，你根本无法用原版 Transformers 类加载它。

模型从“可下载”到“变得寻常”之间的那道鸿沟，正是未来几周将要决定的。下文会把小米已发布的内容与某个框架 PR 所提议的内容区分开来，因为这两者属于不同层级的确定性，而迄今为止的报道一直将它们混为一谈。

小米实际交付了什么，以及何时交付

这次发布在五天内分阶段进行，这也是它更像是一次研究成果的发布、而非产品发布的部分原因。

• 论文——“Xiaomi-Lens-0 Technical Report”，arXiv:2610.23279，2026年10月16日提交，10月19日修订。

• 权重与代码——将于 10 月 21 日SeerRay-Lab/Xiaomi-Lens-0在 Hugging Face 上公开发布，并在 GitHub 上提供配套的推理仓库。

• 许可证 — 权重采用 Apache 2.0，基础 Qwen3.5-4B 权重同样采用 Apache 2.0。该模型卡将基础模型归属于 Alibaba Cloud，将修改归属于 Xiaomi。

• 团队 —— 署名为 Xiaoai Plus 和 SeerRay 团队，即 Xiaomi 的视觉理解团队。

• 尺寸——标题、论文和模型卡片正文中处处都写的是 4B；Hugging Face 元数据报告称，BF16 下为 5B 参数。小米未解释这一差异，而诚实的解读是：“4B”描述的是语言主干，而包含视觉塔的完整检查点参数会更高。

• 托管 — 卡片侧边栏显示该模型未由任何推理提供商部署。既没有第一方 API，也没有可供调用的托管端点。

• 热度——权重上线六天后，Hugging Face 仓库在最近一个月内获得了 723 次下载和 25 个赞。

我没能找到的是一场发布：没有小米的博客文章，没有团队的发帖，也没有产品页面。相关报道都可追溯到那份技术报告，以及权重出现之后业界的报道文章。这对任何想给这个模型确定日期的人来说都很重要——10月16日是论文，10月21日是产物，而两者都不是正式发布。

掩码是一个 token，而不是第二个模型

从视觉语言模型中获取像素掩码的常见做法，是给它外挂一个分割器。你从语言侧得到边界框或点，把它们交给类似 SAM 风格的解码器，并为此付出第二个网络、第二套权重和第二次前向传播的代价。

Xiaomi-Lens-0 跳过了这一步。模型会生成一个特殊的 <|mask|> token，而该 token 的隐藏状态——论文称之为视觉潜变量——被用作针对视觉编码器 patch 网格的查询。一个 Transformer 细化层、一个线性投影、与每个 patch 的点积，然后是两个转置卷积上采样步骤和一个 sigmoid。patch 特征在空间合并器之前提取，因此网格仍然是细粒度的，并且它们每张图像只计算一次，由响应中的每个 mask token 复用。

训练分为两个阶段，一旦架构明确，这个过程并不令人意外。第一阶段冻结主干网络，仅使用内部数据以及 Objects365、LVIS、PACO、PhraseCut 和 RefCOCO 系列数据来训练掩码解码器。第二阶段则联合微调主干网络和解码器，采用标准的下一词元预测目标，并结合由像素级 BCE 和 Dice 组成的掩码损失。

真正值得关心的结果并不是节省参数，而是掩码可以出现在推理内部，而不只是出现在最终答案中。Xiaomi 基于有视觉定位依据的推理轨迹进行训练：其中思维链会引用区域，并在推进过程中输出掩码；因此，一个 4B 模型在回答“这两个里我该拿起哪一个”时，可以把掩码附加到中间步骤，而不只是附加在最后一句话上。

基准表，请正确解读

这些头条数字很亮眼，而且全都属于小米。截至今天，没有 Artificial Analysis 条目、没有 arena 排名，也没有第三方复现。请将以下内容视为一份附带异常详细附录的厂商声明，而非经过实测的事实。

• 指代分割——在 RefCOCO / RefCOCO+ / RefCOCOg 的八个划分上平均 cIoU 为 81.4，而 Qwen3-VL-Seg 4B 为 78.6。SAM 3 在小米自家表格中同样八个划分的平均值约为 71.7。

• 指代理解——相比 Qwen3.5-4B 主干模型，Prec@0.5 平均提升 5.6 个百分点，其中 RefCOCO+ 提升 7.6 个百分点。

• 在 COCO 2017 上进行多实例定位——平均 F1 为 63.9，领先于 GroundingPI 的 63.0 和 Qwen3-VL 4B 的 46.5。

• 推理分割——在 ReasonSeg Test 上达到 68.0 gIoU，在对比模型中表现最佳。

• 具身指代 — 在 RoboRefIt TestA 上达到 87.0 gIoU。

• 计数——在 CountQA 上为 50.6，比骨干模型的 43.8 提高了 6.8。

其中两项值得再看一眼，因为流传的摘要把它们抹平了。

第一个是 COCO 多实例定位。Xiaomi-Lens-0 在平均 F1 上胜过 GroundingPI，但在宽松的 IoU 0.50 阈值下，它实际上反而落后——80.4 F1 对 81.2。优势来自严格的一端：IoU 0.95 时为 27.4 F1，对 22.8。这是性质上的显著差异。该模型生成的是更紧致的掩码，而不是更多掩码，而只检查宽松重叠的流水线不会看到这种改进。

第二个是 LensBench，这是 Xiaomi 随该模型一同构建并发布的基准测试，包含 1,200 个单元和 4,800 条指令。它涵盖通用、航拍、驾驶和全景影像，并经过人工审核；对于任何在 RefCOCO 之外工作的人来说，它是此次发布中最有用的东西。这也是该模型表现最不突出的测试。在通用影像上，Qwen3.8-Max 以 74.2 cIoU 领先，Xiaomi-Lens-0 为 63.9。在隐式指令上，该模型排名第五，落后于 Qwen3.8-Max、GPT-5.6-Sol、Gemini-3.6-Flash 和 Seed-2.1-Pro。Xiaomi 发布了一个其自家模型并未全面制霸的基准测试，这比一份全胜成绩单更有价值。

4B 模型真正失败的地方

这种失效模式并非随机出现。它源于一种落差：一种描述直接点明事物本身，另一种描述则只是暗示它。

• 从显式到隐式——在 LensBench 上，mask cIoU 从 71.4 降至 54.7，box Prec@0.5 从 85.0 降至 70.0。

• 全景场景中的多目标——论文中最差的切片：box Prec@0.5 从 81.3 降至 48.7，cIoU 从 71.8 降至 48.9。

• 小而受遮挡且模糊的区域——卡片明确指出，在这些情况下，预测可能会漏掉对象，或产生不准确的边界框和掩码。

• 计数——在 CountQA 上达到 50.6，提升了 6.8 个百分点，但结果仍大致相当于抛硬币，只是更有礼貌。

还有一个工程实现上的注意事项，任何把它接入产品的人都会踩坑。掩码是在处理器的图像画布上解码的，而不是在你的原始文件上。如果你在推理前调整了尺寸，却忘了反向映射，返回的掩码形状正确，但位置是错的。卡片上说要保留缩放和坐标映射；它没有说如果不这么做会发生什么，而答案是一个悄无声息、看起来却合理的错误。

拉取请求改变了什么，又没有改变什么

PR 50028 自 10 月 23 日以来一直处于进行中——共有四次提交，最后一次提交大约在拉取请求创建前一分钟落地。它新增了一个配置文件、一个模块化文件、一个 2,199 行的建模文件、一个处理器、一个权重转换脚本、模型、图像处理器和分词器的自动映射、一个文档页面，以及 552 行测试。一个 CI 机器人已经为 xiaomi_lens0 请求了慢速测试套件。目前没有任何评审。

如果它被合并，会有三件事发生变化。加载方式会变成 AutoModel 和 AutoProcessor，而不是针对 Xiaomi 的仓库执行 pip install -e .。模型会出现在人们真正阅读的文档中。并且它将有资格使用生态系统工具——量化、适配器、训练框架——这些工具会假定存在一个 Transformers 类，然后才会去处理检查点。

如果合并，有四件事不会改变。它仍然需要支持 bfloat16 和 FlashAttention-2 的 CUDA GPU。它仍然没有托管端点。掩码解码仍然通过处理器运行，而不是普通的生成调用。而且这些数字仍与今天厂商报告的结果完全一致，因为框架移植是打包事件，不是评测。

关于状态，也值得直说。一个尚未合并的 PR 并不等于一项功能。Transformers 有自己的合并节奏，维护者尚未表态，而这种规模的移植在落地之前通常会经历好几轮。今天任何写下“Xiaomi-Lens-0 现在可以在 Transformers 中运行了”的人，都差一次合并，说早了。

本周运行它需要哪些条件

官方途径是小米自家的软件包，而且它假定有一台真正的 GPU 机器。

• 环境配置 — Python 3.10 或更高版本，支持 bfloat16 和 FlashAttention-2 的 CUDA，然后在 inference 仓库内运行 pip install -r requirements.txt 和 pip install -e .

• 单张图像 — infer.py 接收检查点、图像、文本查询和输出路径，并写出标注后的图像以及生成的文本。

• 输出格式——框在 <bbox> 标签内会被归一化到 0–1000 范围，掩码在 <mask> 标签内会以 <|mask|> token 的形式输出，而 thinking 块内的任何内容都不会包含在最终叠加层中。

• 服务 — {{1}}vLLM{{/1}} 支持已存在，但以两个同机部署的服务运行：文本生成在端口 8000，掩码解码在 8001；客户端必须位于同一台机器上，因为它传递的是图像路径而不是字节。如果覆盖 MAX_PIXELS，两个服务需要使用相同的值。

存在两条社区路线，但都不是小米的。一个名为 xiaomi-lens-mnn 的 PyPI 包在 MNN 上针对 CPU 以 fp16 或 int8 重新实现了推理，且不依赖 torch；另有一个非官方 ComfyUI 节点包声称其输出与官方代码逐位一致。两者都是有用的信号——尤其是 MNN 移植版，因为它表明该架构足够简单，可以重新实现，而不只是做封装。

小米未公布显存占用数值、延迟测量结果和吞吐量数据。对于 4B 模型，权重不是问题；高分辨率下的视觉塔和掩码解码环节才是问题，而这两者的成本均未公布。在据此确定集群规模之前，请先进行测量。

本周谁应该下载它？

如果你需要根据自然语言描述获得像素级精确的掩码，并且能掌控硬件，那么在宽松许可证下，这是可选的较好的 4B 选项之一，而且权重无需门控。其显式指令评测数据可与数倍于其规模的模型竞争，该架构从你的流程中去掉了整个第二个网络，而 Apache 2.0 意味着法律审查很短。

如果你今天需要一个托管的分割端点，那并不是这里提供的东西。Xiaomi-Lens-0 不在 OrcaRouter 目录中——我们不提供它，这里的任何内容都不应被解读为声称相反。我们确实提供的是用于对比的模型集合。如果真正的问题是 4B 开源模型在你的图像上是否能胜过托管视觉模型，诚实的做法是在本地运行 Lens-0，并通过一个密钥调用托管侧。Qwen3-VL-8B-Instruct例如，其价格为每百万输入 token 0.18 美元、每百万输出 0.70 美元，按供应商标价透传且无加价，同一个密钥还能访问目录中的其余部分，如果你想要第二种意见，或在一个供应商降级时自动故障转移。在你的数据上做这项对比，比论文里的任何表格都更有价值。

什么会改变这一评估？

四件事，按照它们重要程度的大致顺序排列。

合并 PR 50028，因为它把研究产物变成了普通 Python 环境可以加载的东西。由 Xiaomi 以外的人在 LensBench 或 RefCOCO 上进行的独立评估，因为当前数字只有一位作者，而论文自身表现较弱的切片表明平均值掩盖了真实方差。vLLM 或 SGLang 中的原生掩码路径，将双服务架构合并为一个端点，这正是演示与部署之间的差别。以及来自任何人的托管服务，这会让模型成为一项条目，而不是一个项目。

到那时，准确的描述是这样的：Xiaomi-Lens-0 是一个真实存在、可下载、采用 Apache-2.0 许可的 4B 模型，其分割方法不同寻常且有充分文档记录，发布仅六天，厂商数据亮眼，有一份并不美化它的公开基准，以及一个尚属提案而非已交付的框架移植。知道这一点，比听“小米刚扔出一个 Segment Anything 杀手”或“在它合并之前没什么可看的”都要有用。