이미지에서 자세히 볼 곳만 골라 연산을 줄인다 — VisionWeave

알리바바 Qwen 팀의 VisionWeave — 이미지에서 세밀히 볼 곳과 대충 볼 곳을 모델이 스스로 나눠, 시각 토큰을 평균 43% 줄이고도 원본 성능의 98.9%를 유지했다.
English  ·  日本語  ·  한국어
← 목록으로
온
온틀 리서치
2026년 10월 13일 수정 2026.10.16 읽기 17분 조회 1

멀티모달 LLM(이미지·영상과 글을 함께 다루는 모델)은 이미지를 그대로 읽지 못한다. 먼저 이미지를 잘게 쪼개 시각 토큰(모델이 이미지를 읽기 위해 나눈 정보 단위)으로 바꾼 뒤 처리한다. 토큰이 많을수록 계산과 메모리 비용이 올라가는데, 지금까지의 모델은 이미지의 모든 곳을 똑같이 촘촘하게 토큰으로 바꿨다.

알리바바 Qwen 팀과 중국과학기술대 등이 함께 낸 VisionWeave는, 이미지에서 꼼꼼히 봐야 할 곳(fine-grained, 세밀)과 대충 봐도 되는 곳(coarse-grained, 성김)을 모델이 스스로 나누게 해 토큰 수를 줄인 연구다. 이 능력은 토큰을 줄이지 않은 원본 모델을 교사로 삼는 자기증류(self-distillation)로 학습한다. 자기증류는 별도 정답 라벨을 만드는 대신 원본 모델의 출력을 감독 신호로 쓰는 방식이며, 외부 학습 데이터를 안 쓴다는 뜻은 아니다. 실제 학습에는 LLaVA-OneVision·LLaVA-Video-178K·UGround에서 뽑은 총 777K 샘플을 썼다(초록·§2.4·표 2 기준).

성과부터 적으면, Qwen3.8-27B 기준 여덟 개 벤치마크에서 시각 토큰을 평균 43.0% 줄이면서 원본 성능의 98.9%를 유지했다. 토큰을 50% 고정 비율로 쳐내는 기존 방식은 원본 성능의 88% 안팎에 그쳤는데, 두 수치는 절감률 조건 자체가 달라(VisionWeave 평균 43.0% vs. 비교군 50% 고정) 단순 비교가 아니다 — 절감률을 똑같이 맞춘 공정 비교는 뒤에서 따로 다룬다.

이 논문이 푸는 문제

이미지 속 정보는 고르게 퍼져 있지 않다. 문서의 깨알 같은 글자나 버튼의 위치는 세밀하게 봐야 하지만, 단색 배경이나 하늘처럼 밋밋한 곳은 대충 봐도 답이 바뀌지 않는다. 신문을 읽을 때 기사 본문은 한 글자씩 짚어도 여백은 흘려보는 것과 같다. 모든 곳에 같은 해상도를 쓰는 건 그 여백에까지 돋보기를 들이대는 셈이다.

이 낭비를 줄이려는 기존 해법은 발췌 기준 세 갈래였다.

  • 다운샘플링(downsampling): 이미지를 통째로 줄인다. 토큰은 줄지만 디테일이 날아간다.
  • 가지치기(pruning)·병합(merging): 덜 중요해 보이는 토큰을 골라 버리거나 합친다. FastV·VisionZip이 여기 속한다.
  • 콘텐츠에 맞춰 해상도를 바꾸기: 엣지·엔트로피 같은 저수준 통계로 패치 크기를 정하거나(Yu et al., 2025; Choudhury et al., 2025), 이미지를 타일로 쪼개 타일마다 해상도를 다르게 주는 ViCO(Cui et al., 2025).

논문은 이들의 약점을 네 가지로 정리한다. ① 학습 때와 추론 때 동작이 어긋나는 불일치(training-inference mismatch), ② 과제마다 필요한 정보가 버려지는 문제, ③ 압축 비율이 고정이라 입력마다 맞추지 못하는 문제, ④ attention 가중치를 꺼내 쓰거나 LLM 내부에서 토큰을 쳐내는 설계 탓에 SGLang·vLLM 같은 실제 서빙 엔진에 붙이기 어렵다는 문제다. 저자들이 FastV와 VisionZip을 직접 평가해 보니, 정보가 빽빽한 문서와 위치를 정확히 짚어야 하는 그라운딩(grounding) 과제에서 점수가 크게 떨어졌다.

ViCO는 발상이 VisionWeave와 가장 가깝지만 타일 단위라는 점이 걸린다. Qwen·Kimi처럼 이미지를 원래 크기 그대로 처리하는 네이티브 해상도(native-resolution) 모델에는 잘 맞지 않고, 디테일이 많은 영역과 밋밋한 배경이 한 타일 안에 섞여 있기 일쑤라 타일 하나에 해상도 하나로는 충분히 잘게 나눌 수 없다.

핵심 아이디어

VisionWeave는 두 개의 장치와 한 가지 학습 과정으로 이뤄진다. 저자들은 이 능력을 "탄력적 시각 표현 직조(elastic visual representation weaving)"라 부른다. 촘촘한 실과 성긴 실을 한 천에 섞어 짜듯, 두 해상도의 토큰을 영역별로 엮는다는 뜻이다.

(1) 네 토큰을 하나로 요약하는 장치 — 게이트 공간 풀러(gated spatial pooler). 이미지를 2×2 블록으로 묶는다. 한 블록은 세밀한 토큰 네 개로 남기거나, 성긴 토큰 하나로 압축할 수 있다. 가장 단순한 압축은 네 토큰을 평균 내는 것인데, VisionWeave는 평균 풀링 상태에서 학습을 시작하도록 설계한 뒤, 블록 안 어디에 무게를 둘지 학습으로 조금씩 다듬어 간다.

(2) 요약해도 될 곳을 고르는 장치 — 입도 라우터(granularity router). 블록마다 "여기를 성기게 해도 되는 확률"을 매긴다. 그 확률이 기준값(기본 0.5)을 넘으면 성긴 토큰 하나를, 못 넘으면 세밀한 토큰 네 개를 쓴다.

두 장치를 세금계산서 캡처에 대보면 이렇다. 금액이 적힌 작은 글자 블록은 라우터가 세밀한 네 토큰을 그대로 두고, 아무것도 없는 배경 블록은 풀러가 성긴 한 토큰으로 요약한다. 이렇게 고른 토큰들을 섞어 하나의 시퀀스로 만들어 LLM에 넘긴다.

(3) 원본의 답을 따라 배우는 과정 — 자기증류. 교사는 토큰을 줄이지 않은 원본 모델의 평소 처리 결과이고, 학생은 토큰을 섞어 짠 축소판이다. 학생이 교사와 같은 답을 내도록 맞춰 간다. 여기서 두 목표가 맞물린다. 토큰을 줄이라는 압력과 원본의 답을 지키라는 압력이 함께 걸리므로, 라우터는 아무 데나 줄이는 게 아니라 "줄여도 답이 바뀌지 않는 곳"을 고르도록 배운다.

그래서 세 방식의 동작은 이렇게 갈린다. 가지치기는 토큰을 제거해 나중에 디테일이 필요해도 되살릴 수 없고, VisionWeave는 버리는 대신 성긴 표현으로 요약해 남긴다. ViCO식은 타일마다 해상도를 선택하지만 그 단위가 타일이라 더 잘게는 못 나눈다.

심화: 풀러·라우터·학습의 구현 세부

풀러는 각 패치 특징을 레이어 정규화(LayerNorm)로 다듬고, 채널별로 어디에 가중치를 줄지 게이트(gate)가 점수를 매긴 뒤, value net이 특징을 한 번 더 정제한다. 마지막 층을 0으로 초기화하면 정확히 평균 풀링으로 되돌아가, 안전한 출발점에서 학습을 시작할 수 있다. 성긴 토큰은 원래 네 토큰의 기하학적 중심에 놓이는데, MRoPE 좌표 체계 안에서 위치 보간(positional interpolation)으로 블록 중심 좌표를 부여해 성긴 토큰과 세밀한 토큰이 같은 좌표 틀을 공유하게 한다.

라우터는 ViT의 여러 깊이에서 특징을 끌어와(초반 층의 저수준 디테일 + 후반 층의 의미) 블록마다 질의 하나를 두고, 자기 블록만 보는 지역(local)과 프레임 전체를 보는 전역(global) 블록을 교차 어텐션으로 번갈아 통과시킨 뒤 선형 헤드가 확률을 낸다.

학습은 세 단계다. ① 라우팅을 끄고 모든 블록을 성기게 둔 채 풀러만 학습, ② 풀러를 얼리고 라우터만 학습하되 딱딱한 선택 대신 미분 가능한 소프트 혼합으로 바꾸고 MoE에서 빌린 균형 손실(balance loss)로 성긴 블록 비율을 목표치(80%)에 맞춤, ③ 추론 때 실제로 쓰는 딱딱한 혼합 입도 시퀀스로 풀러와 LLM을 함께 미세조정. 증류는 전부 off-policy이며 교사의 상위 vocab에 대한 forward KL을 쓴다. 3단계를 on-policy로 바꿔봤지만 일관된 이득이 없어 off-policy를 택했다고 밝힌다.

실험은 어떻게 설계됐나

평가 모델은 Qwen3.5-4B와 Qwen3.8-27B 두 개다. 비교군은 병합 계열 VisionZip과 가지치기 계열 FastV인데, SGLang 안에서 공정하게 재려고 FastV는 LLM 내부가 아니라 비전 인코더 직후에 토큰을 고르는 변형(FastV†)을 썼다.

벤치마크는 도메인을 일부러 넓게 폈다. 자연 이미지(RealWorldQA), 문서·인포그래픽(DocVQA, InfoVQA), GUI 그라운딩(ScreenSpotV2), 시각 환각(HallusionBench), 영상 속 글자 읽기(VideoOCR), 영상 이해(Video-MME, LongVideoBench)로 모두 여덟 개다. 점수는 0~100 척도이며, DocVQA·InfoVQA는 ANLS, HallusionBench는 aAcc, 나머지는 각 벤치마크 고유 지표를 쓴다.

이 표가 재는 것과 못 재는 것을 갈라두면 뒤 숫자를 섞어 읽지 않는다. 이 실험이 재는 건 "토큰을 줄였을 때 정답률이 얼마나 떨어지는가", 즉 효율-품질 트레이드오프다. 디테일이 생명인 문서·그라운딩과 중복이 많은 영상을 한 표에 넣어, 입력 성격에 따라 절감률이 달라지는지를 본다. 반대로 이 표만으로는 특정 서비스의 실제 비용이나 지연 시간은 알 수 없다. 그건 뒤의 SGLang 서빙 실험이 맡는 다른 축의 수치다.

공정성을 위한 설계가 하나 더 있다. "VisionWeave가 토큰을 더 적게 쓰면서 점수도 높다"는 비교는 절감률 자체가 달라 불공평할 수 있어, 저자들은 FastV†·VisionZip에 VisionWeave가 관측한 절감률을 그대로 부여한 비교도 추가했다(Appendix E.3).

결과와 의미

Qwen3.8-27B에서 512 토큰/이미지 예산, 기준값 0.5로 돌렸을 때 여덟 벤치마크 평균 토큰을 43.0% 줄이고 원본 성능의 98.9%를 유지했다(평균 손실 1.08%). 더 작은 Qwen3.5-4B에서는 손실이 0.90%였다. 이 숫자를 두 질문으로 나눠 읽으면 핵심이 드러난다.

첫째, 어떤 입력에서 얼마나 줄였는가. 절감률은 과제마다 달라졌다.

입력 성격 과제 토큰 절감 품질
문서·인포그래픽 InfoVQA / DocVQA 16.5% / 27.3% DocVQA 손실 1.23%
GUI 그라운딩 ScreenSpotV2 55.1% 손실 3.17%
영상 VideoOCR·Video-MME·LongVideoBench 49.6~54.2% 손실 0.30% 이하

디테일이 중요한 문서에서는 절감을 보수적으로, 중복이 많은 영상에서는 공격적으로 줄였다. 앞서 본 학습 구조—"줄여도 답이 바뀌지 않는 곳"을 고르도록 배운 라우터—가 입력 성격에 따라 다른 선택으로 나타난 결과다.

둘째, 같은 절감률에서도 품질 차이가 남는가. 남는다. 50% 고정 절감 목표에서 FastV†·VisionZip의 Qwen3.8-27B 평균 손실은 각각 11.82%, 12.46%였고, 특히 VisionZip은 ScreenSpotV2에서 47.88% 하락했다. 같은 과제에서 VisionWeave는 오히려 55.1%를 아끼면서 손실을 3.17%로 막았다. 절감률을 똑같이 맞춘 비교(Appendix E.3)에서도 VisionWeave 평균이 76.73으로 FastV†·VisionZip의 70.10·70.33보다 높았다. 적게 써서 이기는 게 아니라, 같은 양을 써도 어디를 줄일지 더 잘 골라서 앞선다는 뜻이다.

절감이 실제 속도로 이어지는지도 확인했다. SGLang에 올린 Qwen3.8-27B에서 종단간 처리량이 2.30배가 됐고, 평균 TTFT(첫 토큰까지 걸리는 시간)는 54.4%, 평균 TPOT(토큰 하나 생성당 시간)는 60.6% 줄었다. 추론 때 기준값을 조절하면 압축 강도를 바꿀 수 있다는 점(§3.5)도 운영에서 쓸 손잡이다.

해상도·프레임 수를 바꿔가며 돌린 실험에서도 단순 다운샘플링보다 일관되게 유리했다. 한 예로 LongVideoBench에서 256프레임 상한의 VisionWeave가 128프레임 상한의 원본 모델보다 더 적은 토큰을 쓰면서 1.20점 높았다. 같은 예산이면 프레임을 더 담되 각 프레임을 탄력적으로 압축하는 편이 낫다는 신호다.

한계와 남은 질문

편집 주석: 논문의 "Limitations and Future Works"(Appendix A)는 발췌 범위 밖이라, 저자가 직접 인정한 한계 목록은 옮기지 못했다. 아래는 본문·초록에서 짚을 수 있는 구조적 한계다.

첫째, 학습 비용이 크다. Qwen3.8-27B에 이 능력을 심는 데 30K A100 GPU-시간이 넘게 들었다. 작은 팀이 임의 모델에 그대로 재현하기엔 벽이 높다.

둘째, 압축 단위가 2×2 블록에 묶여 있다. 성긴 토큰의 최소 단위가 이 블록이라, 블록보다 더 미세하게 나누는 건 설계 범위 밖이다.

셋째, 입력 분포의 변화다. 2단계 균형 손실은 성긴 블록 비율 80%를 목표로 하고, 3단계 전에는 라우터 편향을 토큰 절감률 50%를 목표로 별도 오프라인 보정하므로, 서비스가 다루는 입력이 이 보정 때와 크게 다르면 재보정이 얼마나 필요한지, 추론 때 기준값만 돌려 어디까지 커버되는지는 실제 트래픽에서 확인할 몫이다.

넷째, 학습이 자기증류라 원본의 맹점이 그대로 넘어올 위험이 있다. 이를 "원본 모델이 이미 틀리게 읽는 작은 숫자 영역에서, 압축 후 오류가 더 늘어나는가"라는 확인 질문으로 바꿔 도입 전에 측정해 두는 게 안전하다.

온틀 관점

온틀은 소기업·1인 창업가의 반복업무를 덜어주는 AI PM 파견형 서비스다.

업무 장면 하나를 놓고 보자. AI PM이 매일 아침 거래처가 보낸 세금계산서 캡처, 쇼핑몰 어드민 대시보드, 배송 현황 표를 멀티모달 모델로 읽어 금액·계좌번호·상태를 뽑는다. 여기서 비용 구조가 까다롭다. 세금계산서의 작은 숫자나 어드민 버튼 위치는 조금만 뭉개도 값이 틀어지는데, 같은 화면에 거대한 여백과 반복되는 표 헤더도 함께 있다. 고정 압축을 걸면 숫자가 틀리고, 압축을 안 걸면 여백에까지 풀 토큰을 써 비용이 그대로다.

그래서 온틀이 이런 기법을 도입할 때의 판단 기준은 수치의 크기가 아니라 순서다. 먼저 금액·계좌번호 추출 오류가 늘지 않는지를 비교하고, 그 허용 품질을 지키는 범위 안에서만 처리 시간과 비용을 평가한다. 논문 수치는 특정 벤치마크·특정 백본의 결과라 그대로 옮겨 쓸 수 없지만, "문서는 보수적으로, 중복 많은 입력은 공격적으로"라는 성질은 이 검토 틀에서 "우리 워크로드가 어느 쪽인지 먼저 진단하라"는 체크포인트로 쓸 수 있다.

실무자를 위한 체크리스트

  • 내 워크로드가 문서·GUI 그라운딩처럼 디테일 민감형인지, 영상·중복형인지 먼저 나눈다. 고정 비율 압축을 이미 쓰고 있다면 디테일 민감 과제의 손실부터 측정한다.
  • 토큰 절감 수치(벤치마크 정답률 기준)와 서빙 속도 수치(SGLang 기준)는 다른 실험의 숫자다. 비용 추정에서 둘을 곱해 합치지 않는다.
  • 서빙 엔진 호환성을 확인한다. 실질 이득은 SGLang 통합에서 나왔으니, vLLM 등 다른 엔진이라면 같은 작업이 재현돼 있는지 따로 본다.
  • 추론 때 기준값(threshold) 손잡이로 과제별 손실 허용선을 정해 운영 파라미터로 노출할 수 있는지 검토한다.
  • 모델이 네이티브 해상도 계열(Qwen·Kimi류)인지 확인한다. 타일 기반 모델에는 ViCO식 제약이 그대로 걸린다.
  • 자체 학습은 30K A100 GPU-시간이 넘는 비용이 드니, 공식 코드·가중치 공개(github.com/FFY0/VisionWeave) 활용을 먼저 검토한다.
코드나 가중치는 공개되나요?

논문에 따르면 SGLang 코드와 기타 세부사항을 github.com/FFY0/VisionWeave 에 공개할 예정이라고 밝혀져 있습니다. 공개 시점·범위의 구체 일정은 발췌 범위에서 확인되지 않습니다.

반정수 좌표를 정수 기반 서빙 캐시에 어떻게 넣나요?

성긴 토큰은 네 패치의 기하학적 중심, 즉 반정수 좌표에 놓입니다. SGLang의 RoPE 캐시는 정수 인덱스라 이를 직접 담지 못하는데, 저자들은 모든 위치 좌표를 2배로 키우고 회전 주파수를 절반으로 낮춰 회전 위상을 보존하는 방식으로 기존 커널을 그대로 재활용했습니다. 가지치기류가 실제 서빙 엔진에 적용되기 어렵다고 지적한 지점을 스스로 메운 셈입니다.

참고자료

  • 논문: VisionWeave: Weaving Elastic Visual Representations as a Native Capability of MLLMs
  • 저자: Yuan Feng, Qize Yang, Ruizhe Chen, Sibo Song, Haolin He, Muzhi Zhu, Zihan Liu, Yunfei Chu, Xize Cheng, Yuxuan Wang, Jin Xu, Xike Xie 외 (University of Science and Technology of China, Alibaba Token Hub / Qwen Team 외)
  • arXiv: https://arxiv.org/abs/2610.07987
  • HuggingFace: https://huggingface.co/papers/2610.07987