让多模态模型「指出」它正在说的东西，一直是件别扭的事。你问它”左边那只猫在哪”，它能用文字把位置描述一遍，但要拿到精确的像素级掩码，传统做法是再挂一个分割模型（SAM 之类）做第二跳。小米 SeerRay-Lab 开源的 Xiaomi-Lens-0 换了个思路：模型自己生成特殊 mask token，每个 token 的隐状态直接解码成分割掩码——回答写到哪里，框就画到哪里。这篇文章记录我用官方在线 Space 实际调用的结果，包括一次成功定位、两个 ZeroGPU 额度坑，以及什么场景我建议你别碰它。
它是什么：Qwen3.5-4B 加一个掩码解码头
Xiaomi-Lens-0 是 4B 参数的多模态模型，基座是 Qwen3.5-4B，外加一个轻量像素掩码解码器，Apache 2.0 协议。权重在 HuggingFace 的 SeerRay-Lab 组织下（模型仓库），推理代码在 GitHub（SeerRay-Lab/Xiaomi-Lens-0），技术报告发在 arXiv（2610.23279），三处我都验证过可访问。
和同类的最大区别是掩码可以出现在推理链中间，不只在最终答案。官方给的任务清单：指代理解与分割、多实例定位、推理分割（比如”图里什么东西能挤在海鲜上当调味”→ 指着柠檬）、具身指代（”把左边那罐洁面乳递给我”）和细粒度感知。这套能力和机器人抓取、车载助手这类”必须知道答案对应哪块像素”的场景是对口的，跟我之前写的 Perceptron Mk1.5 具身推理模型实测 属于同一条赛道，只是 Lens-0 走开源权重、走分割掩码，Perceptron 走 API、走空间标注。
官方数字要先打个标：RefCOCO 系八个划分平均比 Qwen3.5 基座高 5.6 分、CountQA +6.8 分——全部是作者自评，第三方还没复现过。另外有个容易被忽略的工程细节：加载和掩码解码必须用配套的 Xiaomi-Lens 包，不是装个 transformers 就能跑的 drop-in 模型。这和小米 9 月开源的 MiMo-V2.6 全模态系列 的开箱即用路线完全不同，SeerRay-Lab 这套是研究发布，不是产品发布。
实测：官方 Space API，一次成功、两次被限额
先说清测试边界。模型权重是 BF16 三个分片共 9.2GB，官方 README 明确写了推理需要 CUDA GPU 且依赖 FlashAttention-2——我手上是 16GB 的 Apple M4，没有 NVIDIA 卡，本地部署这条线我未实测。但官方在 HuggingFace Spaces 上挂了在线 Demo（xiaomi-lens-0 Space），底层就是 ZeroGPU 跑的完整模型，所以我改走 API 路线：用 gradio_client 直接调 Space 的 /answer 接口，这是真实的模型输出，不是截图转述。
测试图用的是 COCO val2017 那张经典的两只猫躺沙发图（000000039769）。安装与调用：
python3 -m venv venv
venv/bin/pip install gradio_clientimport time
from gradio_client import Client, handle_file
c = Client('hugging-apps/xiaomi-lens-0')
t0 = time.time()
out_img, out_text = c.predict(
image=handle_file("cats.jpg"),
instruction='Locate all instances in the image that match the '
'description "the cat on the left". Report bbox '
'coordinates and masks.',
max_new_tokens=512,
api_name="/answer",
)
print(out_text, f"{time.time()-t0:.1f}s")跑通的那次（总耗时 8.9 秒）返回：
**Answer**
<bbox>[14, 112, 494, 988]</bbox><mask>[mask]</mask><|im_end|>
---
1 answer mask(s) decoded · 2.5s generation · 0.3s mask decoding坐标是 0-1000 归一化格式，[14, 112, 494, 988] 对应图片左半边。Space 返回的 overlay 图里，左边那只橘猫被半透明掩码完整覆盖、外框精确贴合——”the cat on the left” 这个指代理解对了，掩码边缘连猫尾巴都包住了，没有把沙发和遥控器框进去。生成 2.5 秒、掩码解码只用 0.3 秒，大头时间其实花在排队和图像上传上。
真正的收获在两次失败里。第一次我按接口默认参数调（max_new_tokens=3072），直接报错 The requested GPU duration (206s) is larger than the maximum allowed——ZeroGPU 免费档对单次请求的 GPU 时长有上限，3072 token 的预估时长超了。把 max_new_tokens 压到 512 立刻能跑。第二个坑紧跟着来：成功一次之后再发起第二次调用，返回 You have exceeded your ZeroGPU runs limit，匿名身份的免费次数按次计算，跑一条就锁。想要连续测试，得在调用时挂上 HuggingFace token（Client(..., hf_token=...)），或者干脆本地部署。
所以如果你照着我的代码跑，记住两条：max_new_tokens 给 512 起步（定位任务的答案很短，3072 是给推理分割那种长思维链准备的），并且第一个用例就要是你最想验证的那个——匿名额度可能只够一条。
本地部署我能确认什么、不能确认什么
能从仓库确认的：权重三个 safetensors 分片合计约 9.2GB，推理入口是 XiaomiLensQwen3_5ForConditionalGeneration，仓库自带 infer.py，支持 --draw-bbox 直接把框画到输出图上；另有 vLLM serving 路线（pip install -e ".[vllm]"）。这套是我读 README 和仓库文件确认的，本地 CUDA 跑通与否我未实测，需要自行验证。
一个我没有实测、但值得警惕的点：README 里官方给的示例提示词是固定句式（Locate all instances in the image that match the description "..."），模型对自由格式指令的容忍度未知。研究发布阶段的模型常见问题就是换个问法就掉点，正式用之前建议先拿自己的句式跑一轮对拍。
我的建议：谁该看，谁该绕开
值得花时间的：做机器人抓取、车载/手机视觉助手的团队——掩码是具身动作的直接输入；做图像标注工具的开发者——bbox 加掩码一次出，省掉第二跳分割模型；想在 RAG 里加”指哪说哪”能力的，可以拿它当感知前端。
建议绕开的：没有 NVIDIA GPU 且不想付 API/算力成本的，Space 匿名额度只够尝鲜；指望它直接进生产链路的——作者自己标注 pre-alpha 性质的研究发布，基准分又全是自评，先对拍再上线；另外它不理解”分割质量”的业务语义，医疗影像这类高精度需求我不建议直接用，掩码精度没有第三方验证。做图像编辑方向的可以对照 Qwen-Image-2.1 的开源上手实测——同样 Apache 2.0，那边走的是生成/编辑一体，这边走的是理解加定位，两条路线刚好互补。
一句话总结：这是我今年看到的第一个把”回答”和”指出”在 token 层面合成一件事的开源模型，方向值得跟，落地前先解决算力和对拍两道坎。