文章资料 「LocateAnything 开源论文项目」 链接https://pan.quark.cn/s/372f8614067aLocateAnything把视觉定位从逐 Token 生成变成“整框并行解码”本文结合论文《LocateAnything: Fast and High-Quality Vision-Language Grounding with Parallel Box Decoding》、官方开源结果以及一次 RTX 3090 本地实测介绍这个模型解决了什么问题、为什么更快以及普通消费级显卡上的真实运行表现。一、它解决的不是“看懂图片”而是“指出目标在哪里”通用视觉语言模型擅长回答“图片里有什么”但机器人操作、GUI 自动化、文档解析和开放词汇检测通常还需要一个更严格的答案目标究竟位于哪个框、哪个点。LocateAnything 是 NVIDIA Eagle 模型家族中的通用视觉定位模型。它接收图片和自然语言查询输出归一化到[0, 1000]的边界框或点坐标覆盖以下任务开放词汇目标检测与密集检测单目标和多目标短语定位GUI 元素框定位与点定位OCR 文本区域与文档布局定位面向机器人和具身智能的指点式定位。例如输入“the large green bus at the bottom center”模型会生成refthe large green bus at the bottom center/ref box621694767988/box这里的四个数分别表示(x1, y1, x2, y2)。将它们除以 1000再乘以图像宽高就能得到像素坐标。二、传统生成式定位为什么慢许多 VLM 把二维边界框序列化为一维 Token先生成x1再依次生成y1、x2、y2。如果坐标采用文本数字还可能把一个数继续拆成多个字符 Token。这样做虽然可以复用语言模型的生成接口却有两个问题一个框的四个坐标具有强耦合关系拆开学习不符合几何结构。每个坐标都依赖前一步生成目标越密集串行解码延迟越明显。普通 Multi-Token PredictionMTP也不能直接解决问题。它通常按照固定长度切分任意 Token 流分块边界可能穿过框、类别或结构标记产生不连贯的条件分布。LocateAnything 的关键改动是 Parallel Box DecodingPBD不再把框看成四个独立坐标而是把完整边界框或点作为一个原子几何单元并行预测。论文将每个输出块固定为长度 6完整框由box、四个坐标和/box组成不足的位置用null补齐。三、PBD 如何兼顾速度与结构模型由 Moon-ViT 视觉编码器、MLP 投影层和 Qwen2.5 语言解码器组成。视觉编码器保留原生分辨率下的空间细节语言模型输出四种固定结构块Semantic Block描述目标语义Box Block包含四个量化坐标Negative Block表示目标不存在End Block表示生成结束。训练阶段同时保留两条目标表示标准 NTP 序列用于维持因果推理能力块式 MTP 序列用于学习整框并行预测。两条序列共享图片和查询上下文但通过注意力掩码隔离最终联合优化 NTP loss 与 block loss。这种设计并不是简单地“多猜几个 Token”而是让并行边界与视觉结构边界对齐。论文在 COCO 上的消融实验显示解码模式吞吐量BPSMean F1特点Slow / NTP3.952.1精度优先逐 Token 解码Fast / MTP16.949.6吞吐最高复杂场景精度有所下降Hybrid13.251.6保留大部分速度同时接近 Slow 精度这些数字来自论文消融设置并不等同于最终发布模型主表中的 12.7 BPS。四、Hybrid 模式只修复有问题的块纯并行解码可能遇到两类不可靠输出一类是类别边界附近的格式异常另一类是密集目标之间的空间歧义。Hybrid 模式默认采用快速 MTP检测到异常块后丢弃该块并回退到最后一个已验证前缀仅对问题区域执行 NTP 重解码然后重新切回并行模式。这比整段退回自回归更克制正常框继续享受并行收益只有局部异常承担额外延迟。本次本机测试的统计信息中switch_to_ar0说明该样本没有触发 NTP 回退。五、数据中心策略规模之外更重要的是任务覆盖LocateAnything-Data 包含约 1200 万张独立图像、超过 1.38 亿条语言查询和 7.85 亿个框。数据覆盖并不平均而是围绕定位能力进行组合任务查询占比通用目标检测66.9%GUI 元素定位16.5%指代表达理解7.3%OCR 文本定位3.6%文档与场景布局3.5%点定位2.2%训练流程先进行世界知识对齐再进行两阶段监督微调。第二阶段提高多目标图片的比例重点补强拥挤场景和密集检测。这解释了模型为什么既能处理自由文本查询又能在 VisDrone、Dense200 等密集场景中保持较好的实例分离能力。六、论文中的主要结果论文主结果在单张 NVIDIA H100、batch size 1、默认 Hybrid 模式下报告。BPS 表示每秒解码的边界框数量不是每秒图片数。指标LocateAnything-3B对照结果解码吞吐12.7 BPSQwen3-VL-4B 为 1.1Rex-Omni-3B 为 5.0LVIS Mean F150.7Rex-Omni-3B 为 46.9COCO Mean F154.7Rex-Omni-3B 为 52.9Dense200 Mean F158.7Rex-Omni-3B 为 58.3VisDrone Mean F139.9Rex-Omni-3B 为 35.8DocLayNet Mean F176.8Rex-Omni-3B 为 70.7M6Doc Mean F170.1Rex-Omni-3B 为 55.6ScreenSpot-Pro 平均分60.3GUI-Owl-32B 为 58.0HumanRef F10.9568.8Rex-Omni-3B 为 65.4这些结果的价值不只是平均分更高。LVIS 的 F10.95 从 Rex-Omni 的 20.7 提升到 31.1说明整框结构监督对高 IoU 精确定位尤其有帮助。论文还报告 LocateAnything-3B 在七个 point-based benchmark 上均取得表中最佳结果。七、RTX 3090 本地实测7.1 环境与输入本次测试不是论文 benchmark而是验证模型在普通工作站上的可运行性与单请求时延。项目配置GPUNVIDIA GeForce RTX 3090 24GB物理 GPU 1Python3.11.15由 uv 管理PyTorch2.12.0cu130精度BF16注意力实现PyTorch SDPA模型本地 LocateAnything-3B约 7.3GB生成模式Hybrid原始测试图为1920 x 1001图中蓝色 person 标注是官方素材自带内容并非本次模型输出。进入模型前图片被等比例缩放至1024 x 534。原始输入本次输出本次查询仅要求定位“画面底部中间的大型绿色公交车”。右图中的红框和红色标签由本地可视化脚本根据模型输出绘制蓝色 person 框来自原始图片。7.2 输出坐标模型原始回答refthe large green bus at the bottom center/ref box621694767988/box|im_end|坐标转换结果坐标空间(x1, y1, x2, y2)归一化坐标(621, 694, 767, 988)推理图像素坐标(635.90, 370.60, 785.41, 527.59)映射回原图约值(1192, 695, 1473, 989)完整原始数据见 data/local_bus_result.json。7.3 时间拆解阶段时间模型加载2.1793 秒单次推理总耗时0.7305 秒模型内部生成0.7161 秒Prefill0.6396 秒Prefill 后解码约 0.0765 秒生成速度23.7391 tokens/s本次输出框数1模型统计 BPS1.3964一次性 CLI 命令还包含 Python 启动、依赖导入和 CUDA 初始化墙钟时间约 5.8 秒。真正适合业务评估的是模型常驻后的 0.7305 秒而不是每次重新启动进程的总时间。这个样本只有一个框绝大多数时间消耗在视觉 Prefill因此不能用 1.3964 BPS 去反驳或验证论文的 12.7 BPS。论文数字来自 H100、COCO、batch size 1并衡量密集框解码吞吐本次数字来自 RTX 3090 的单图单框请求硬件、图片和工作负载都不同。7.4 显存边界模型加载后约占用 7.23GB 显存。1024 x 534输入的实测峰值约 8.51GB可以稳定运行。另一次使用2048 x 1206图片、同样走 SDPA 时出现 OOM视觉注意力还需申请约 10.11GB而进程当时总占用已接近 19GB。这表明 RTX 3090 部署的关键限制并不是 3B 权重而是原生分辨率视觉注意力的二次方内存增长。当前可视化脚本默认把最长边限制为 1024在没有 FlashAttention/MagiAttention 的 Ampere 环境中这是比直接输入 2K 图片更稳妥的默认值。八、如何复现实测在本文所在目录执行cd .. CUDA_VISIBLE_DEVICES1 \ TOKENIZERS_PARALLELISMfalse \ uv run --no-sync python visualize_locateanything.py \ --image ./assets/images/Smart_City.png \ --query the large green bus at the bottom center \ --task ground-single \ --max-size 1024 \ --max-new-tokens 128脚本会在results/locateanything/中保存带框 PNG 和对应 JSON。uv run --no-sync会直接使用项目的.venv不需要先执行source .venv/bin/activate。九、结论与边界LocateAnything 的核心价值是让输出结构决定解码结构边界框本来就是一个耦合几何单元就应当作为一个原子块训练和预测。PBD 提升了密集框生成的并行度Hybrid 模式又为格式异常和空间歧义保留了局部自回归修复能力大规模、多任务的 LocateAnything-Data 则补足了开放世界、GUI、OCR、布局和点定位的泛化覆盖。本机实验确认 LocateAnything-3B 可以在 24GB RTX 3090 上以 BF16SDPA 运行模型常驻后的单图单目标定位约为 0.73 秒。但这只是一次功能与延迟验证不代表标准数据集精度也不能替代 H100 上的 BPS benchmark。面向实际系统时应进一步使用无预标注图片建立测试集分别统计准确率、P50/P95 时延、不同分辨率显存和多目标吞吐。此外仓库代码采用 Apache-2.0但模型使用 NVIDIA License仅允许非商业研究或评估用途。商业部署前必须单独确认模型授权。参考资料Shihao Wang et al. LocateAnything: Fast and High-Quality Vision-Language Grounding with Parallel Box Decoding, 2026.NVIDIA Research. LocateAnything 项目主页.NVlabs. Eagle / Embodied 源代码.NVIDIA. LocateAnything-3B 模型仓库.本文中的方法图、数据图和论文结果图来自 LocateAnything 官方仓库本地输入、标注结果和 JSON 数据已随本文目录一并整理Markdown 中所有本地资源均使用相对路径。LocateAnything把视觉定位从逐 Token 生成变成“整框并行解码”本文结合论文《LocateAnything: Fast and High-Quality Vision-Language Grounding with Parallel Box Decoding》、官方开源结果以及一次 RTX 3090 本地实测介绍这个模型解决了什么问题、为什么更快以及普通消费级显卡上的真实运行表现。一、它解决的不是“看懂图片”而是“指出目标在哪里”通用视觉语言模型擅长回答“图片里有什么”但机器人操作、GUI 自动化、文档解析和开放词汇检测通常还需要一个更严格的答案目标究竟位于哪个框、哪个点。LocateAnything 是 NVIDIA Eagle 模型家族中的通用视觉定位模型。它接收图片和自然语言查询输出归一化到[0, 1000]的边界框或点坐标覆盖以下任务开放词汇目标检测与密集检测单目标和多目标短语定位GUI 元素框定位与点定位OCR 文本区域与文档布局定位面向机器人和具身智能的指点式定位。例如输入“the large green bus at the bottom center”模型会生成refthe large green bus at the bottom center/ref box621694767988/box这里的四个数分别表示(x1, y1, x2, y2)。将它们除以 1000再乘以图像宽高就能得到像素坐标。二、传统生成式定位为什么慢许多 VLM 把二维边界框序列化为一维 Token先生成x1再依次生成y1、x2、y2。如果坐标采用文本数字还可能把一个数继续拆成多个字符 Token。这样做虽然可以复用语言模型的生成接口却有两个问题一个框的四个坐标具有强耦合关系拆开学习不符合几何结构。每个坐标都依赖前一步生成目标越密集串行解码延迟越明显。普通 Multi-Token PredictionMTP也不能直接解决问题。它通常按照固定长度切分任意 Token 流分块边界可能穿过框、类别或结构标记产生不连贯的条件分布。LocateAnything 的关键改动是 Parallel Box DecodingPBD不再把框看成四个独立坐标而是把完整边界框或点作为一个原子几何单元并行预测。论文将每个输出块固定为长度 6完整框由box、四个坐标和/box组成不足的位置用null补齐。三、PBD 如何兼顾速度与结构模型由 Moon-ViT 视觉编码器、MLP 投影层和 Qwen2.5 语言解码器组成。视觉编码器保留原生分辨率下的空间细节语言模型输出四种固定结构块Semantic Block描述目标语义Box Block包含四个量化坐标Negative Block表示目标不存在End Block表示生成结束。训练阶段同时保留两条目标表示标准 NTP 序列用于维持因果推理能力块式 MTP 序列用于学习整框并行预测。两条序列共享图片和查询上下文但通过注意力掩码隔离最终联合优化 NTP loss 与 block loss。这种设计并不是简单地“多猜几个 Token”而是让并行边界与视觉结构边界对齐。论文在 COCO 上的消融实验显示解码模式吞吐量BPSMean F1特点Slow / NTP3.952.1精度优先逐 Token 解码Fast / MTP16.949.6吞吐最高复杂场景精度有所下降Hybrid13.251.6保留大部分速度同时接近 Slow 精度这些数字来自论文消融设置并不等同于最终发布模型主表中的 12.7 BPS。四、Hybrid 模式只修复有问题的块纯并行解码可能遇到两类不可靠输出一类是类别边界附近的格式异常另一类是密集目标之间的空间歧义。Hybrid 模式默认采用快速 MTP检测到异常块后丢弃该块并回退到最后一个已验证前缀仅对问题区域执行 NTP 重解码然后重新切回并行模式。这比整段退回自回归更克制正常框继续享受并行收益只有局部异常承担额外延迟。本次本机测试的统计信息中switch_to_ar0说明该样本没有触发 NTP 回退。五、数据中心策略规模之外更重要的是任务覆盖LocateAnything-Data 包含约 1200 万张独立图像、超过 1.38 亿条语言查询和 7.85 亿个框。数据覆盖并不平均而是围绕定位能力进行组合任务查询占比通用目标检测66.9%GUI 元素定位16.5%指代表达理解7.3%OCR 文本定位3.6%文档与场景布局3.5%点定位2.2%训练流程先进行世界知识对齐再进行两阶段监督微调。第二阶段提高多目标图片的比例重点补强拥挤场景和密集检测。这解释了模型为什么既能处理自由文本查询又能在 VisDrone、Dense200 等密集场景中保持较好的实例分离能力。六、论文中的主要结果论文主结果在单张 NVIDIA H100、batch size 1、默认 Hybrid 模式下报告。BPS 表示每秒解码的边界框数量不是每秒图片数。指标LocateAnything-3B对照结果解码吞吐12.7 BPSQwen3-VL-4B 为 1.1Rex-Omni-3B 为 5.0LVIS Mean F150.7Rex-Omni-3B 为 46.9COCO Mean F154.7Rex-Omni-3B 为 52.9Dense200 Mean F158.7Rex-Omni-3B 为 58.3VisDrone Mean F139.9Rex-Omni-3B 为 35.8DocLayNet Mean F176.8Rex-Omni-3B 为 70.7M6Doc Mean F170.1Rex-Omni-3B 为 55.6ScreenSpot-Pro 平均分60.3GUI-Owl-32B 为 58.0HumanRef F10.9568.8Rex-Omni-3B 为 65.4这些结果的价值不只是平均分更高。LVIS 的 F10.95 从 Rex-Omni 的 20.7 提升到 31.1说明整框结构监督对高 IoU 精确定位尤其有帮助。论文还报告 LocateAnything-3B 在七个 point-based benchmark 上均取得表中最佳结果。七、RTX 3090 本地实测7.1 环境与输入本次测试不是论文 benchmark而是验证模型在普通工作站上的可运行性与单请求时延。项目配置GPUNVIDIA GeForce RTX 3090 24GB物理 GPU 1Python3.11.15由 uv 管理PyTorch2.12.0cu130精度BF16注意力实现PyTorch SDPA模型本地 LocateAnything-3B约 7.3GB生成模式Hybrid原始测试图为1920 x 1001图中蓝色 person 标注是官方素材自带内容并非本次模型输出。进入模型前图片被等比例缩放至1024 x 534。原始输入本次输出原始输入本次输出原始输入本次输出本次查询仅要求定位“画面底部中间的大型绿色公交车”。右图中的红框和红色标签由本地可视化脚本根据模型输出绘制蓝色 person 框来自原始图片。7.2 输出坐标模型原始回答refthe large green bus at the bottom center/ref box621694767988/box|im_end|坐标转换结果ata-draft-nodeblock data-draft-typetabledata-sizenormal data-row-stylenormal坐标空间(x1, y1, x2, y2)归一化坐标(621, 694, 767, 988)推理图像素坐标(635.90, 370.60, 785.41, 527.59)映射回原图约值(1192, 695, 1473, 989)完整原始数据见 data/local_bus_result.json。7.3 时间拆解阶段时间模型加载2.1793 秒单次推理总耗时0.7305 秒模型内部生成0.7161 秒Prefill0.6396 秒Prefill 后解码约 0.0765 秒生成速度23.7391 tokens/s本次输出框数1模型统计 BPS1.3964一次性 CLI 命令还包含 Python 启动、依赖导入和 CUDA 初始化墙钟时间约 5.8 秒。真正适合业务评估的是模型常驻后的 0.7305 秒而不是每次重新启动进程的总时间。这个样本只有一个框绝大多数时间消耗在视觉 Prefill因此不能用 1.3964 BPS 去反驳或验证论文的 12.7 BPS。论文数字来自 H100、COCO、batch size 1并衡量密集框解码吞吐本次数字来自 RTX 3090 的单图单框请求硬件、图片和工作负载都不同。7.4 显存边界模型加载后约占用 7.23GB 显存。1024 x 534 输入的实测峰值约 8.51GB可以稳定运行。另一次使用 2048 x 1206 图片、同样走 SDPA 时出现 OOM视觉注意力还需申请约 10.11GB而进程当时总占用已接近 19GB。这表明 RTX 3090 部署的关键限制并不是 3B 权重而是原生分辨率视觉注意力的二次方内存增长。当前可视化脚本默认把最长边限制为 1024在没有 FlashAttention/MagiAttention 的 Ampere 环境中这是比直接输入 2K 图片更稳妥的默认值。八、如何复现实测在本文所在目录执行cd .. CUDA_VISIBLE_DEVICES1 \ TOKENIZERS_PARALLELISMfalse \ uv run --no-sync python visualize_locateanything.py \ --image ./assets/images/Smart_City.png \ --query the large green bus at the bottom center \ --task ground-single \ --max-size 1024 \ --max-new-tokens 128脚本会在 results/locateanything/ 中保存带框 PNG 和对应 JSON。uv run --no-sync 会直接使用项目的 .venv不需要先执行 source .venv/bin/activate。九、结论与边界LocateAnything 的核心价值是让输出结构决定解码结构边界框本来就是一个耦合几何单元就应当作为一个原子块训练和预测。PBD 提升了密集框生成的并行度Hybrid 模式又为格式异常和空间歧义保留了局部自回归修复能力大规模、多任务的 LocateAnything-Data 则补足了开放世界、GUI、OCR、布局和点定位的泛化覆盖。本机实验确认 LocateAnything-3B 可以在 24GB RTX 3090 上以 BF16SDPA 运行模型常驻后的单图单目标定位约为 0.73 秒。但这只是一次功能与延迟验证不代表标准数据集精度也不能替代 H100 上的 BPS benchmark。面向实际系统时应进一步使用无预标注图片建立测试集分别统计准确率、P50/P95 时延、不同分辨率显存和多目标吞吐。此外仓库代码采用 Apache-2.0但模型使用 NVIDIA License仅允许非商业研究或评估用途。商业部署前必须单独确认模型授权。参考资料Shihao Wang et al. LocateAnything: Fast and High-Quality Vision-Language Grounding with Parallel Box Decoding, 2026.NVIDIA Research. LocateAnything 项目主页.NVlabs. Eagle / Embodied 源代码.NVIDIA. LocateAnything-3B 模型仓库.本文中的方法图、数据图和论文结果图来自 LocateAnything 官方仓库本地输入、标注结果和 JSON 数据已随本文目录一并整理Markdown 中所有本地资源均使用相对路径。