LocateAnything: VLM은 어떻게 이미지를 보고 좌표를 말할까요
이미지 안의 “빨간 셔츠를 입은 사람”, “검색 버튼”, “문서의 표 영역”, “도로 표지판의 글자”를 찾으려면 결국 모델은 좌표를 말해야 합니다. LocateAnything은 이 좌표를 더 빠르고 안정적으로 말하기 위해 나온 NVIDIA의 vision-language grounding 모델입니다.
이 글에서 잡고 갈 핵심은 하나입니다.
LocateAnything은 좌표를 토큰 하나씩 말하지 않고, 박스라는 기하학적 단위를 하나의 블록으로 다루려 합니다.
이 아이디어가 Parallel Box Decoding(PBD)입니다. 기존 VLM grounding이 <x1>, <y1>, <x2>, <y2>를 순차적으로 생성했다면, LocateAnything은 <box> x1 y1 x2 y2 </box>를 하나의 box-aligned block으로 묶어 병렬 예측합니다.
<small>그림 1. LocateAnything은 detection, pointing, GUI grounding, OCR, layout grounding을 하나의 VLM grounding 문제로 다룹니다. 출처: NVlabs/Eagle.</small>
먼저 답부터
- LocateAnything은 하나의 모델로 여러 위치 추론 태스크를 처리합니다. 방법은 태스크별 head를 여러 개 붙이는 것이 아니라, 태스크를 자연어 프롬프트로 표현하고 출력은
<ref>/<box>좌표 문법으로 통일하는 것입니다. - 기존 Transformer와 완전히 다른 모델은 아닙니다. Moon-ViT vision encoder, MLP projector, Qwen2.5 language decoder를 쓰는 VLM입니다. 차이는 backbone보다 출력 표현, 학습 목표, 디코딩 방식에 있습니다.
<box>는 단순 문자열이 아닙니다. 파서가 좌표를 읽는 경계이고, 모델이 학습한 special token이며, PBD에서 박스 블록을 맞추는 구조 신호입니다.- Fast, Slow, Hybrid는 서로 다른 모델이 아닙니다. 같은 모델을 두고, 추론 루프에서 “박스를 한 번에 제안할지”, “좌표를 하나씩 쓸지”, “빠르게 제안하되 위험하면 그 블록만 다시 쓸지”를 바꾸는 방식입니다.
- 이런 구조가 가능해진 배경에는 Pix2Seq류의 좌표 tokenization, Florence-2류의 unified prompt-output 흐름, Kosmos-2/Shikra/Ferret류의 grounded MLLM, 그리고 multi-token prediction 연구가 있습니다.
- 활용처는 GUI agent, 문서 AI, OCR 후처리, 로봇, 자동 라벨링, 산업 검사처럼 “언어 지시를 위치로 바꿔야 하는” 영역입니다.
자료목적.md 질문에 바로 답하기
자료목적.md에 적힌 질문을 그대로 놓고 하나씩 풀어보겠습니다.
1. 하나의 모델로 어떻게 여러 추론을 할 수 있을까요?
LocateAnything이 여러 태스크를 처리하는 핵심은 “태스크를 프롬프트로 넣고, 답은 같은 좌표 문법으로 받는다”는 데 있습니다.
예를 들어 태스크는 서로 달라 보입니다.
| 태스크 | 사용자가 원하는 것 | 모델이 실제로 해야 하는 일 |
|---|---|---|
| Object detection | 이미지 안의 모든 car, person 찾기 | 여러 박스 생성 |
| Referring grounding | “왼쪽의 빨간 차” 찾기 | 설명에 맞는 박스 생성 |
| GUI grounding | “검색 버튼” 찾기 | UI 요소 박스 또는 클릭점 생성 |
| OCR localization | 이미지 안 글자 영역 찾기 | 텍스트 영역 박스 생성 |
| Layout grounding | 문서의 제목, 표, 문단 영역 찾기 | 레이아웃 요소 박스 생성 |
| Pointing | “신호등을 가리켜” | 점 좌표 생성 |
하지만 출력 형식은 거의 하나로 정리됩니다.
<ref>대상 이름 또는 설명</ref><box><x1><y1><x2><y2></box>또는 point 태스크에서는 다음처럼 더 짧아집니다.
<box><x><y></box>즉 하나의 모델이 여러 “추론 모델”을 내부에 따로 갖고 있다기보다, 여러 위치 추론 문제를 같은 생성 문제로 바꿉니다. 입력은 이미지와 자연어 질의, 출력은 구조화된 좌표 텍스트입니다. 이것이 generalist grounding 모델의 핵심 설계입니다.
2. 기존 Transformers와 무엇이 다를까요?
여기서 “기존 Transformers”는 두 의미로 나눠 보는 편이 좋습니다.
첫째는 모델 뼈대 관점입니다. LocateAnything은 Transformer를 버린 모델이 아닙니다. 공식 문서 기준 Moon-ViT vision encoder, MLP projector, Qwen2.5 language decoder를 쓰는 Transformer 기반 VLM입니다. Hugging Face transformers 생태계에서도 AutoModel, AutoTokenizer, AutoProcessor와 trust_remote_code=True로 로딩합니다.
둘째는 출력과 디코딩 관점입니다. 진짜 차이는 여기에 있습니다. 일반 autoregressive Transformer는 다음 토큰 하나를 예측합니다. 좌표도 다음처럼 하나씩 나옵니다.
<box> -> <130> -> <647> -> <911> -> <887> -> </box>이 방식은 안정적이지만 느립니다. 특히 박스가 많아지면 디코딩 스텝이 크게 늘어납니다.
LocateAnything은 같은 정답을 두 표현으로 학습합니다.
| 표현 | 역할 |
|---|---|
| NTP sequence | 기존 next-token prediction 능력을 유지 |
| Block-wise MTP sequence | 박스 단위 병렬 예측 능력을 학습 |
그래서 LocateAnything은 Transformer가 아닌 새 패러다임이라기보다, Transformer 기반 VLM 위에서 좌표 출력을 박스 단위로 재구성한 모델에 가깝습니다.
3. <box> 같은 묶음은 왜 의미가 있을까요?
<box>는 세 가지 의미를 동시에 가집니다.
| 층위 | 의미 |
|---|---|
| 출력 포맷 | 후처리 코드가 좌표를 추출하는 경계 |
| 학습 신호 | 모델이 “이제 위치 정보가 나온다”고 배우는 special token |
| 디코딩 단위 | PBD에서 박스 블록을 정렬하는 구조적 앵커 |
중요한 점은 <box> 자체가 마법처럼 의미를 갖는 게 아니라는 점입니다. 의미는 데이터와 규칙에서 옵니다. 학습 데이터가 일관되게 <box><x1><y1><x2><y2></box> 형식을 쓰고, tokenizer가 이 토큰들을 special token 또는 좌표 token으로 다루며, 디코더가 이 묶음을 박스 블록으로 예측하도록 학습되기 때문에 의미가 생깁니다.
개발자 입장에서는 다음처럼 읽을 수 있습니다.
import re
def parse_boxes(answer: str, image_width: int, image_height: int):
boxes = []
pattern = r"<box><(\d+)><(\d+)><(\d+)><(\d+)></box>"
for match in re.finditer(pattern, answer):
x1, y1, x2, y2 = map(int, match.groups())
boxes.append({
"x1": x1 / 1000 * image_width,
"y1": y1 / 1000 * image_height,
"x2": x2 / 1000 * image_width,
"y2": y2 / 1000 * image_height,
})
return boxes좌표는 [0, 1000] 범위로 정규화됩니다. 그래서 실제 픽셀 좌표로 바꾸려면 이미지의 width와 height를 곱해야 합니다.
4. 이런 아키텍처는 왜 지금 나왔을까요?
LocateAnything은 갑자기 나온 아이디어가 아닙니다. 몇 가지 연구 흐름이 누적된 결과입니다.
| 흐름 | 대표 연구 | LocateAnything으로 이어지는 부분 |
|---|---|---|
| Detection을 직접 예측하기 | DETR | object detection을 복잡한 pipeline이 아니라 직접 예측 문제로 단순화 |
| Detection을 언어 생성으로 보기 | Pix2Seq | box와 class를 discrete token sequence로 생성 |
| 여러 vision task를 같은 인터페이스로 묶기 | Pix2Seq v2, Florence-2 | prompt와 text output으로 detection, grounding, segmentation 등을 통합 |
| MLLM 출력에 좌표 넣기 | Kosmos-2, Shikra, Ferret | 언어와 region/box/point를 한 출력 안에서 연결 |
| 여러 토큰을 한 번에 예측하기 | Multi-token Prediction | autoregressive decoding 병목을 줄이는 방향 |
| 범용 perception MLLM | Rex-Omni | detection, pointing, GUI grounding, OCR을 한 모델로 다루는 비교 축 |
LocateAnything은 이 흐름 중에서도 마지막 병목을 찌릅니다.
좌표를 생성하는 것은 가능해졌습니다. 이제 문제는 그 좌표를 얼마나 빠르고 기하학적으로 일관되게 생성하느냐입니다.
5. 어디에 더 써볼 수 있을까요?
LocateAnything류 아키텍처가 유용한 곳은 “자연어 지시를 화면이나 이미지의 위치로 바꾸는” 문제입니다.
| 활용 케이스 | 예시 | 왜 잘 맞는가 |
|---|---|---|
| GUI agent | “설정 버튼을 눌러”, “검색창에 입력해” | UI 요소를 박스나 클릭점으로 바꿀 수 있습니다. |
| 문서 AI/RAG 전처리 | 논문 PDF에서 표, 제목, 그림, 문단 영역 분리 | OCR 텍스트뿐 아니라 레이아웃 위치를 함께 쓸 수 있습니다. |
| OCR 후처리 | 영수증, 간판, 문서의 텍스트 위치 찾기 | 텍스트와 위치를 같이 grounding할 수 있습니다. |
| 로봇/embodied AI | “컵 손잡이를 잡아”, “오른쪽 문을 열어” | 자연어 지시를 물체 위치나 point로 바꿀 수 있습니다. |
| 자동 라벨링 | 데이터셋에 detection/grounding label 초안 생성 | 대량 박스를 빠르게 뽑는 데 유리합니다. |
| 산업 검사 | 결함 후보, 부품 위치, 계기판 영역 찾기 | dense scene에서 많은 후보 위치를 생성할 수 있습니다. |
단, 공식 모델카드는 연구·개발용, 특히 비상업적 연구 용도 중심의 라이선스를 명시합니다. 실제 제품에 쓰기 전에는 라이선스와 안전성 검토가 필요합니다.
PBD를 한 장으로 이해하기
LocateAnything의 핵심 그림은 아래와 같습니다.
<small>그림 2. NTP는 좌표를 하나씩 생성합니다. 일반 MTP는 빠를 수 있지만 토큰 묶음이 박스 경계와 어긋날 수 있습니다. PBD는 박스 경계에 맞춘 블록을 생성합니다. 출처: NVlabs/Eagle.</small>
PBD의 요지는 이렇습니다.
| 방식 | 생성 단위 | 문제 |
|---|---|---|
| Textual coordinate decoding | 숫자 자릿수 | 너무 깁니다. |
| Quantized coordinate NTP | 좌표 토큰 하나 | 여전히 순차적입니다. |
| Generic MTP | 임의 토큰 묶음 | 박스 구조가 깨질 수 있습니다. |
| PBD | 박스 또는 포인트 블록 | 구조와 병렬성을 함께 노립니다. |
박스는 x1, y1, x2, y2 네 숫자가 함께 맞아야 의미가 있습니다. PBD는 이 네 좌표를 서로 독립적인 토큰이 아니라 하나의 박스를 이루는 내부 요소로 다룹니다.
아키텍처: 복잡한 비밀보다 출력 설계가 중요하다
LocateAnything의 모델 구조는 크게 보면 익숙합니다.
<small>그림 3. Moon-ViT가 이미지 토큰을 만들고, projector가 이를 언어 모델 공간으로 연결하며, Qwen2.5 decoder가 구조화된 블록 출력을 만듭니다. 출처: NVlabs/Eagle.</small>
| 구성 | 역할 |
|---|---|
| Moon-ViT | 이미지의 세밀한 공간 정보를 token으로 추출 |
| MLP projector | vision token과 language decoder 사이를 연결 |
| Qwen2.5 decoder | 자연어 질의와 이미지 정보를 바탕으로 좌표 문법을 생성 |
LocateAnything의 차별점은 backbone보다 output formulation입니다. 논문은 네 가지 블록을 정의합니다.
| 블록 | 예시 | 의미 |
|---|---|---|
| Semantic Block | <ref> person </ref> <null>... | 라벨 또는 설명 |
| Box Block | <box> <100> <675> <218> <800> </box> | 위치 좌표 |
| Negative Block | <box> none </box> <null>... | 대상 없음 |
| End Block | <im_end> <null>... | 생성 종료 |
논문 기준 block length는 L = 6입니다. 박스 블록은 <box>, 네 좌표, </box>로 정확히 6개 자리를 채웁니다. 비어 있는 자리는 <null>로 맞춥니다. 이 고정 길이가 있어야 병렬 예측이 가능합니다.
Hybrid Mode: 빠르지만, 위험하면 천천히 갑니다
병렬 생성은 빠르지만 완벽하지 않습니다. LocateAnything은 크게 두 실패를 다룹니다.
| 실패 유형 | 설명 |
|---|---|
| Format Irregularity | <box>, </ref>, 좌표 토큰이 잘못 섞이는 문법 오류 |
| Spatial Ambiguity | 밀집된 물체 사이에서 중간 좌표를 찍는 위치 모호성 |
그래서 세 가지 추론 모드를 제공합니다.
| 모드 | 방식 | 적합한 상황 |
|---|---|---|
| Fast Mode | PBD/MTP 중심 | 속도가 가장 중요하고 장면이 비교적 단순할 때 |
| Slow Mode | NTP 순차 생성 | 정확도와 안정성이 가장 중요할 때 |
| Hybrid Mode | 기본은 PBD, 위험 블록만 NTP fallback | 실용적인 균형점 |
<small>그림 4. Hybrid Mode는 문제가 생긴 블록을 버리고 마지막 정상 prefix로 돌아간 뒤, 그 블록만 NTP로 다시 생성합니다. 출처: NVlabs/Eagle.</small>
이 방식이 좋은 이유는 전체 출력을 느리게 만들지 않는다는 점입니다. 대부분은 빠른 PBD로 가고, 불안정한 구간만 천천히 다시 생성합니다.
인퍼런스 심화: 어떻게 빠른 모드와 느린 모드를 바꿔가며 쓸까요
논문에서 가장 흥미로운 부분은 “PBD가 빠르다”보다 “빠르게 하다가 위험하면 느린 방식으로 돌아갈 수 있다”는 점입니다. 이때 모드 전환은 모델을 바꾸는 것이 아닙니다. 같은 모델, 같은 weight를 두고, generate 과정에서 어떤 디코딩 규칙을 적용할지 바꾸는 것입니다. 공식 worker도 generation_mode를 "fast", "slow", "hybrid" 중 하나로 받아 model.generate(...)에 전달합니다.
1단계: 가장 쉬운 비유
좌표를 만드는 일을 글쓰기라고 생각해 보겠습니다.
| 방식 | 비유 | 실제 의미 |
|---|---|---|
| Slow Mode | 한 글자씩 또박또박 쓰기 | <box>, x1, y1, x2, y2, </box>를 순서대로 생성합니다. |
| Fast Mode | 빈칸 6개를 한 번에 채우기 | 박스 하나를 길이 6짜리 블록으로 놓고 동시에 예측합니다. |
| Hybrid Mode | 먼저 빠르게 채운 뒤, 이상한 부분만 다시 쓰기 | 기본은 Fast Mode지만 문법이나 좌표 확신도가 이상하면 해당 블록만 Slow Mode로 다시 생성합니다. |
핵심은 “전체 답변을 처음부터 다시 쓰지 않는다”는 점입니다. 이미 맞다고 확인한 prefix는 보존하고, 문제가 난 박스 블록만 버린 뒤 다시 씁니다.
2단계: Slow Mode는 왜 느리지만 안정적일까요
일반적인 autoregressive VLM은 다음 토큰 하나를 예측합니다.
prefix
-> <box>
-> <130>
-> <647>
-> <911>
-> <887>
-> </box>이 방식은 느립니다. 박스 하나에 구조 토큰과 좌표 토큰이 여러 개 들어가고, 박스가 100개면 그만큼 디코딩 스텝이 누적됩니다. 대신 장점도 있습니다. y2를 만들 때 이미 <box>, x1, y1, x2를 모두 본 상태이기 때문에, 앞에서 생성한 좌표를 조건으로 다음 좌표를 신중하게 고를 수 있습니다. 그래서 논문은 Slow Mode를 고정밀 라벨링, offline evaluation처럼 정확도가 더 중요한 경우에 어울리는 모드로 설명합니다.
3단계: Fast Mode는 무엇을 한 번에 예측할까요
LocateAnything의 Fast Mode는 일반 MTP처럼 아무 토큰 묶음이나 자르지 않습니다. 박스라는 구조에 맞춰 자릅니다.
<box> <130> <647> <911> <887> </box>논문 기준 block length는 L = 6입니다. 그래서 박스 하나가 정확히 6자리 블록이 됩니다. point나 semantic block처럼 자리가 남는 경우에는 <null>로 채워 tensor shape을 맞춥니다.
Fast Mode의 직관은 이렇습니다.
- 지금까지 확정된 출력 prefix를 봅니다.
- 다음에 올 블록 하나를 준비합니다.
- 블록 내부의 여러 위치를 동시에 예측합니다.
<null>padding은 버리고 실제 토큰만 결과에 붙입니다.- 붙인 토큰을 다음 블록의 causal context로 사용합니다.
여기서 중요한 점은 병렬 예측이 “좌표를 아무렇게나 동시에 찍는다”는 뜻이 아니라는 점입니다. 학습 때부터 같은 정답을 NTP sequence와 block-wise MTP sequence 두 표현으로 함께 학습했기 때문에, 모델은 한 토큰씩 쓰는 능력과 박스 단위로 채우는 능력을 동시에 갖게 됩니다.
4단계: Hybrid Mode는 무엇을 검사할까요
Hybrid Mode는 매 블록마다 “이 블록을 믿어도 되는가”를 확인합니다. 논문은 크게 두 종류의 위험 신호를 제시합니다.
| 위험 신호 | 쉬운 설명 | 예시 |
|---|---|---|
| Format Irregularity | 문법이 깨졌습니다. | <box><211></ref><911><887></box>처럼 구조 토큰과 좌표 토큰이 섞입니다. |
| Spatial Ambiguity | 좌표 확신이 낮습니다. | 물체가 격자처럼 빽빽할 때 두 물체 사이 중간 좌표를 찍습니다. |
Format Irregularity는 파서 관점에서 바로 확인할 수 있습니다. 박스 블록이라면 <box> 좌표 좌표 좌표 좌표 </box> 구조가 나와야 하는데, 중간에 </ref> 같은 토큰이 끼면 문제가 됩니다.
Spatial Ambiguity는 확률과 좌표 후보의 흩어짐으로 봅니다. 논문은 ambiguity trigger를 다음처럼 둡니다.
| 조건 | 의미 |
|---|---|
top-1 coordinate token probability < 0.7 | 가장 유력한 좌표 후보에 대한 확신이 낮습니다. |
top-5 coordinate tokens의 max-min 차이 > 80 | 후보 좌표들이 [0, 1000] 정규화 좌표 공간에서 서로 멀리 흩어져 있습니다. |
두 조건이 동시에 걸리면 “이 좌표는 빠르게 찍었지만 믿기 어렵다”고 판단합니다. 이때 Hybrid Mode는 해당 블록을 결과에 붙이지 않습니다.
5단계: 실제 전환 흐름은 이렇게 이해하면 됩니다
아래는 논문 설명을 구현 관점으로 풀어쓴 의사코드입니다.
prefix = image_tokens + query_tokens
while not finished(prefix):
block = predict_next_block_with_mtp(prefix, block_size=6)
if has_format_error(block) or has_spatial_ambiguity(block):
# 문제가 난 블록은 결과에 넣지 않습니다.
block = regenerate_this_block_with_ntp(prefix)
committed = remove_null_padding(block)
prefix = prefix + committed
kv_cache = keep_only_committed_tokens(prefix)여기서 prefix는 이미 확정된 출력입니다. Hybrid Mode가 똑똑한 이유는 실패를 전체 실패로 보지 않는다는 점입니다. 문제가 생긴 블록만 버리고, 마지막으로 검증된 prefix에서 그 블록만 NTP로 다시 생성합니다. 그 블록이 끝나면 다시 MTP로 돌아갑니다.
6단계: KV cache를 왜 자를까요
Transformer 추론은 보통 KV cache를 사용합니다. 이전 토큰들의 key/value를 저장해 두면 매번 처음부터 다시 계산하지 않아도 됩니다. 그런데 MTP/PBD에서는 현재 블록을 빠르게 예측하기 위해 임시 mask token이나 anchor token이 들어갈 수 있습니다. 이 임시 토큰까지 cache에 남기면 다음 블록이 “실제로 생성된 적 없는 토큰”을 본 것처럼 됩니다.
그래서 논문은 MTP step 이후 KV cache를 실제로 commit된 토큰까지만 남기고, mask token과 duplicated anchor token은 제거한다고 설명합니다. 쉽게 말해, 초안 작성용 발판은 치우고 최종 문장만 다음 단계에 넘기는 것입니다.
7단계: attention mask 관점에서 더 전문적으로 보면
학습 때 LocateAnything은 같은 정답을 두 줄로 봅니다.
x_all = x_vis ⊕ x_q ⊕ x_ntp ⊕ x_blk| 구성 | 의미 |
|---|---|
x_vis | 이미지 토큰 |
x_q | 사용자 질의 토큰 |
x_ntp | 토큰을 하나씩 생성하는 NTP 표현 |
x_blk | 박스 단위로 재구성한 MTP 표현 |
이때 attention mask가 핵심입니다.
| 영역 | attention 규칙 | 이유 |
|---|---|---|
| NTP stream | 표준 causal attention | 기존 VLM의 순차 추론 능력을 유지합니다. |
| 블록 사이 | block-causal attention | 이전 블록은 보되 미래 블록은 보지 않습니다. |
| 블록 내부 | bidirectional intra-block attention | 같은 박스 안의 좌표들이 서로의 위치 관계를 함께 학습합니다. |
| NTP와 MTP 사이 | stream isolation | 정답 누수를 막습니다. |
그래서 PBD는 “완전한 비자기회귀 모델”이라기보다 semi-autoregressive에 가깝습니다. 블록 사이에서는 여전히 순서가 있습니다. 하지만 블록 내부에서는 여러 좌표를 동시에 맞힙니다. 이 절충 덕분에 KV cache와 causal prefix를 유지하면서도 박스 하나를 빠르게 만들 수 있습니다.
8단계: 왜 Hybrid가 실용적인 기본값일까요
논문 부록의 mode analysis는 세 모드를 이렇게 해석할 수 있게 해 줍니다.
| 모드 | 처리량 | 장점 | 약점 |
|---|---|---|---|
| Fast | 15.3 BPS | 가장 빠릅니다. | 밀집 장면에서 정확도가 조금 떨어질 수 있습니다. |
| Hybrid | 12.7 BPS | 빠른 편이면서 위험 블록을 보정합니다. | Fast보다 약간 느립니다. |
| Slow | 4.3 BPS | 안정성과 위치 정밀도가 가장 강합니다. | 처리량이 낮습니다. |
즉 Hybrid Mode는 “속도는 대부분 Fast처럼 가져가고, 실패 가능성이 높은 지점만 Slow처럼 처리하는” 전략입니다. 실제 제품 파이프라인에서 매번 Slow Mode를 쓰면 느리고, 매번 Fast Mode만 쓰면 복잡한 장면에서 불안정할 수 있습니다. Hybrid는 그 중간에서 자동으로 속도와 안정성을 조정합니다.
9단계: 한 문장으로 다시 정리하면
LocateAnything의 inference 전환은 모델 교체가 아니라 블록 단위 디코딩 정책의 전환입니다. 평소에는 박스 하나를 병렬로 제안하고, 문법이나 좌표 확신도가 흔들리면 그 블록만 순차 생성으로 다시 쓴 뒤, 다시 병렬 생성으로 복귀합니다. 이 구조가 가능한 이유는 학습 때부터 같은 정답을 token-level NTP와 block-level MTP 두 방식으로 함께 익혔기 때문입니다.
데이터: 하나의 모델이 되려면 하나의 문법으로 많이 배워야 합니다
LocateAnything은 구조만 제안하지 않습니다. LocateAnything-Data라는 대규모 데이터 엔진도 함께 제시합니다.
<small>그림 5. LocateAnything-Data는 detection, GUI grounding, referring, OCR, layout, pointing을 포함합니다. 출처: NVlabs/Eagle.</small>
| 항목 | 규모 |
|---|---|
| Unique images | 12M |
| Natural-language queries | 138M |
| Annotated bounding boxes | 785M |
태스크 비중은 다음과 같습니다.
| 태스크 그룹 | Query 비중 |
|---|---|
| General object detection | 66.9% |
| GUI element grounding | 16.5% |
| Referring comprehension | 7.3% |
| Text localization | 3.6% |
| Layout grounding | 3.5% |
| Point-based localization | 2.2% |
이 데이터 구성이 중요합니다. 여러 태스크를 하나의 모델로 다루려면 단지 출력 포맷만 같아서는 부족합니다. 여러 도메인의 이미지, 질의, 박스가 같은 문법으로 충분히 학습되어야 합니다.
성능은 어디를 보면 좋을까요
공식 문서 기준 LocateAnything-3B는 단일 H100에서 Hybrid Mode 12.7 BPS를 보고합니다. BPS는 boxes per second, 즉 초당 생성한 박스 수입니다.
| 항목 | LocateAnything-3B | 비교 포인트 |
|---|---|---|
| Throughput | 12.7 BPS | Qwen3-VL 1.1 BPS 대비 약 10배, Rex-Omni 5.0 BPS 대비 약 2.5배 |
| LVIS F1@Mean | 50.7 | Rex-Omni 대비 +3.8 |
| COCO F1@Mean | 54.7 | Rex-Omni 대비 +1.8 |
| DocLayNet F1@Mean | 76.8 | 문서 레이아웃 grounding |
| M6Doc F1@Mean | 70.1 | 문서 구조 이해 |
| ScreenSpot-Pro Avg | 60.3 | GUI grounding |
<small>그림 6. COCO/LVIS 결과. LocateAnything은 처리량과 high-IoU localization 품질을 함께 강조합니다. 출처: NVlabs/Eagle.</small>
<small>그림 7. 문서 레이아웃과 OCR localization 결과. 출처: NVlabs/Eagle.</small>
이 수치는 논문과 공식 문서의 벤치마크 결과입니다. 실제 환경에서는 GPU, 이미지 해상도, 프롬프트, batch, 후처리에 따라 달라질 수 있습니다.
관련 논문과 비교해 보면 더 선명해진다
관련 논문을 한 줄씩 놓고 보면 LocateAnything의 차이가 더 또렷합니다.
| 연구 | 핵심 | LocateAnything과의 관계 |
|---|---|---|
| DETR | object detection을 set prediction으로 직접 풂 | detection pipeline 단순화의 배경 |
| Pix2Seq | detection을 token sequence generation으로 변환 | 좌표를 언어처럼 생성하는 흐름의 시작점 |
| Pix2Seq v2 | 여러 vision task를 unified sequence interface로 처리 | “하나의 모델, 하나의 출력 인터페이스” 배경 |
| Grounding DINO | language-guided open-set detector | VLM generation 계열은 아니지만 강력한 grounding baseline |
| Kosmos-2 | text span과 bounding box를 연결 | grounded MLLM 출력 문법 배경 |
| Shikra | coordinate input/output을 자연어 대화에 포함 | 좌표를 MLLM 대화 능력으로 끌어들인 흐름 |
| Ferret | region feature와 discrete coordinate 결합 | 세밀한 refer-and-ground 계열 |
| Florence-2 | prompt로 다양한 vision task를 text output화 | unified vision foundation model 흐름 |
| MTP | 여러 future token을 한 번에 예측 | PBD가 빌려온 병렬 디코딩 배경 |
| Rex-Omni | next-point prediction 기반 범용 perception | LocateAnything의 주요 비교 대상 |
LocateAnything의 새로움은 “좌표를 말할 수 있다”는 데만 있지 않습니다. 그건 이미 여러 모델이 보여준 흐름입니다. 새로움은 좌표 박스라는 구조를 디코딩 단위와 맞추었다는 점입니다.
한 문장으로 정리하면
LocateAnything은 VLM grounding에서 “무엇을 찾을지”는 자연어로 받고, “어디에 있는지”는 박스 단위로 병렬 생성하는 모델입니다. <box>는 이 둘을 이어주는 프로토콜이고, PBD는 그 프로토콜을 빠르게 실행하기 위한 디코딩 전략입니다.
발행 전 주의할 점
- 공식 이미지 사용 조건은 블로그 공개 전 확인해야 합니다.
- 모델 라이선스는 비상업적 연구 용도 중심이므로 상용 활용 표현은 조심해야 합니다.
- 실제 모델 추론을 검증한 글이 아니라 논문/공식 문서 기반 기술 해설이라는 점을 명시하는 편이 좋습니다.
- 후속 arXiv 버전이나 코드 업데이트가 나오면 수치와 링크를 재확인해야 합니다.
참고 자료
원자료 및 공식 자료
| 자료 | 링크 | 로컬 보관 |
|---|---|---|
| 사용자 제공 자료 | raw/LOCATEANYTHING/자료.md | 원자료 |
| 사용자 목적 메모 | raw/LOCATEANYTHING/자료목적.md | 원자료 |
| LocateAnything arXiv | https://arxiv.org/abs/2605.27365 | raw/LOCATEANYTHING/sources/papers/locateanything_2605.27365.pdf |
| NVIDIA Research project page | https://research.nvidia.com/labs/lpr/locate-anything/ | _source_log.md에 기록 |
| NVlabs/Eagle Embodied | https://github.com/NVlabs/Eagle/tree/main/Embodied | 공식 코드/이미지 |
| Hugging Face model card | https://huggingface.co/nvidia/LocateAnything-3B | 모델 구조와 라이선스 |
관련 논문
| 자료 | 링크 | 역할 |
|---|---|---|
| DETR | https://arxiv.org/abs/2005.12872 | detection as set prediction 배경 |
| Pix2Seq | https://arxiv.org/abs/2109.10852 | detection as language modeling 배경 |
| Pix2Seq v2 | https://arxiv.org/abs/2206.07669 | unified sequence interface 배경 |
| Grounding DINO | https://arxiv.org/abs/2303.05499 | open-set grounding detector 비교 |
| Kosmos-2 | https://arxiv.org/abs/2306.14824 | grounded MLLM 출력 문법 배경 |
| Shikra | https://arxiv.org/abs/2306.15195 | 좌표 입출력 MLLM 배경 |
| Ferret | https://arxiv.org/abs/2310.07704 | refer-and-ground MLLM 배경 |
| Florence-2 | https://arxiv.org/abs/2311.06242 | prompt 기반 multi-task vision model 배경 |
| Better & Faster LLMs via MTP | https://arxiv.org/abs/2404.19737 | multi-token prediction 배경 |
| Kimi-VL | https://arxiv.org/abs/2504.07491 | Moon-ViT/native-resolution encoder 배경 |
| Qwen2.5-VL | https://arxiv.org/abs/2502.13923 | modern VLM localization 배경 |
| Rex-Omni | https://arxiv.org/abs/2510.12798 | LocateAnything 주요 비교 대상 |
관련 논문 PDF와 조사 노트는 raw/LOCATEANYTHING/sources/에 정리해두었습니다.
'관심있는 주제 > 논문리뷰' 카테고리의 다른 글
| 논문리뷰-Perplexity 사용자 분석 논문-The Adoption and Usage of AI Agents: Early Evidence from Perplexity (1) | 2025.12.13 |
|---|