UI-Venus-2-9B 대 Microsoft Mage-VL: 스크린샷 에이전트 대 코덱-스트림 워처

UI-Venus-2-9B와 Microsoft Mage-VL은 한 달 간격으로 조용히 출시되었습니다. Mage-VL의 저장소는 2026년 7월 26일에, UI-Venus-2-9B는 2026년 8월 26일에 나타났습니다. 둘 다 Apache-2.0 오픈 가중치이며, Qwen 계열 백본을 기반으로 합니다. 유사점은 대략 여기서 끝납니다. 차이는 정도의 문제가 아니라 각 모델이 화면의 어느 쪽에 존재하는가의 문제입니다. Microsoft Mage-VL은 코덱 네이티브 스트리밍 인식 모델입니다. 압축된 비디오를 지켜보며, 일상적인 영상에서는 조용히 있다가 이벤트가 완료되면 텍스트를 출력합니다. UI-Venus-2-9B는 GUI 에이전트입니다. 정지 스크린샷을 입력받아 상태를 추론하고 구조화된 액션을 출력합니다. 하나는 화면을 보고 묘사하고, 다른 하나는 화면을 보고 조작합니다. 둘 중 하나를 선택하는 것은 벤치마크 결정이 아닙니다. 둘은 단 하나의 벤치마크도 공유하지 않기 때문입니다. 이는 자동화가 답으로 끝나는지, 액션으로 끝나는지에 대한 결정입니다.

각 모델이 실제로 무엇인지

Microsoft Mage-VL은 공지 없이 microsoft/Mage-VL 리포지토리에서 출시된, 약 4B 파라미터의 멀티모달 모델입니다. Qwen3-4B-Instruct-2507 언어 디코더, Mage-ViT라는 처음부터 새로 구축한 비주얼 인코더, 그리고 별도의 약 0.5B 스트리밍 게이트로 구성됩니다. 그 설계는 비디오 코덱 네이티브입니다. 프레임을 균일하게 샘플링하는 대신 앵커(I) 프레임은 전체를 유지하고 예측(P) 프레임의 움직임이 두드러지는 패치만 보존합니다. 이를 통해 Microsoft는 균일 샘플링 대비 시각 토큰 소비를 75% 이상 절감하고 최대 3.5배의 실제 시간(wall-clock) 추론 속도 향상을 얻는다고 보고합니다. 두 프로세스 설계, 즉 System 1 인지 게이트가 각 롤링 코덱 창을 감시하고 System 2 VLM이 응답할 가치가 있는 이벤트가 있을 때만 작동하는 방식은, 항상 켜져 있는 비디오 감시자를 가능하게 하며, 대부분 침묵하기 때문에 정확히 저렴합니다.

inclusionAI(비너스 팀의 Ant Group 연구소)가 공개한 UI-Venus-2-9B는 Qwen3.5-9B에서 초기화된 9B 규모의 범용 GUI 에이전트입니다. 이 모델은 인터페이스를 관찰하고, 작업 상태를 추론하며, 행동을 실행하고, 피드백을 반영하는 폐쇄적인 관찰-추론-행동-피드백 루프를 수행합니다. 또한 모델 카드에 따르면 단일 체크포인트에서 모바일 앱, 웹 플랫폼, 데스크톱 운영 체제를 아우르는 학습 범위를 제공한다고 합니다. 자체 모델 카드에는 AndroidWorld 80.2, OSWorld-Verified 70.8, WebVoyager 90.8, ScreenSpot-Pro 73.0 점수가 보고되어 있으며, 이는 모두 공급업체가 제시한 수치로 독립적으로 재현된 결과는 없습니다.

입력 격차: 잡는 픽셀과 유지하는 스트림

가장 교훈적인 차이는 각 모델이 무엇을 먹느냐입니다. UI-Venus-2-9B는 스크린샷 에이전트입니다. 입력은 현재 화면, 한 번에 한 프레임이며, 256K-토큰 컨텍스트 창은 긴 작업 동안 그 프레임들의 이력을 유지하는 방식입니다. Mage-VL은 스트림 에이전트입니다. 입력은 압축된 비디오이고, 효율성의 비결은 프레임 간 움직임을 데이터로 취급하는 데 있습니다. 전통적인 코덱에서는 모션 벡터와 잔차 에너지가, 신경망 코덱에서는 학습된 레이트 맵이 그 데이터입니다. 이것은 순간을 보는 모델과 연속적인 타임라인을 보는 모델의 차이입니다. 스크린샷 에이전트는 구조적으로 캡처 사이의 100밀리초를 볼 수 없습니다. 스피너, 로딩 전환, 화면에 잠깐만 존재하는 호버 상태 같은 것들이 보이지 않습니다. 스트림 관찰자는 그 틈 안에 살고 있습니다. 이는 어느 쪽 설계의 결함도 아닙니다. 실시간 화면에 대해 작동해야 하는 GUI 에이전트와 피드를 요약해야 하는 지각 모델이 서로 다른 입력 계약을 가진 다른 제품인 이유가 바로 여기에 있습니다.

산출 격차: 행동 대 논평

출력 측면에서 이 둘은 더 이상 비교할 수 없게 된다. UI-Venus-2-9B의 출력은 정의된 행동 공간 안의 구조화된 동작이다. 마우스, 키보드, 스크롤, 내비게이션 같은 것들로, Qwen3 스타일의 추론 토큰 이후에 내보내진다. 그리고 그 훈련은 시각적 혼란 속에서도 정확한 요소 위치 파악을 보상하는 grounding 및 CAPTCHA 작업을 중심으로 구축된다. Mage-VL의 출력은 텍스트, 즉 보고 있는 것에 대한 이벤트 기반 해설이다. 행동 공간도, 함수 호출도, 에이전트 루프도 없다. 두 모델 카드를 나란히 읽으면, 인식과 행동의 경계선에서 정반대편을 보고 있는 셈이다. Mage-VL은 설명으로 끝나고, UI-Venus-2-9B는 클릭으로 끝난다.

• 작업 — UI-Venus-2-9B: GUI 에이전트, 인터페이스를 조작합니다. Microsoft Mage-VL: 실시간 인식, 인터페이스를 설명합니다.

• 입력 — UI-Venus-2-9B: 정적 스크린샷, 256K-토큰 기록. Microsoft Mage-VL: 압축 비디오 코덱 스트림, 모션 중요 토큰 희소성.

• 출력 — UI-Venus-2-9B: 구조화된 마우스/키보드/내비게이션 동작. Microsoft Mage-VL: 이벤트 게이트 방식 텍스트 해설.

• 크기 — UI-Venus-2-9B: 9B. Microsoft Mage-VL: ~4B + ~0.5B 스트리밍 게이트.

• 백본 — UI-Venus-2-9B: Qwen3.5-9B. Microsoft Mage-VL: Qwen3-4B-Instruct-2507 및 처음부터 만든 Mage-ViT.

• 라이선스 — 둘 다 Apache-2.0입니다 (Mage-VL의 카드 노트에는 리포지토리에서 연구 목적으로만 사용한다고 명시되어 있음).

제공 격차

여기서 더 새롭고 더 큰 모델이 실행하기 더 쉽습니다. UI-Venus-2-9B는 256K 컨텍스트 창과 기본 OpenAI 호환 API를 갖춘 단일 vLLM 명령을 문서화합니다. Mage-VL은 다음이 필요합니다: trust_remote_code 이는 Microsoft의 맞춤형 Python을 실행하기 위해 필요하며, 이와 함께 FFmpeg, 비디오용 뉴럴 코덱 경로, mamba-ssm과 같은 종속성도 필요합니다. 그리고 아직 vLLM 또는 SGLang 서빙 스택이 없습니다 — 페이지드 어텐션도, 프로덕션 서빙 경로도 없습니다. Microsoft는 총 약 10.6GB의 BF16 파라미터를 보고하며, 이는 16GB GPU가 이미지 작업의 현실적인 최소 사양이고, 긴 비디오에는 24GB 이상이 필요함을 의미합니다. 오늘 프로덕션에 무언가를 배포하려는 팀에게 UI-Venus-2-9B가 더 깔끔한 진입로를 제공합니다. 항상 가동되는 모니터링 또는 요약 파이프라인을 구축하는 팀이라면, 어느 쪽이든 Mage-VL의 서빙 스택을 감수해야 하며, 맞춤형 Python과 모든 것을 포함합니다.

존재하지 않는 스코어보드

이 두 모델 사이에는 공통된 벤치마크가 없으며, 하나를 만들어 내는 것은 부정직한 일이 될 것입니다. UI-Venus-2-9B의 수치는 GUI-그라운딩, 모바일, 웹, 컴퓨터 사용 리더보드에 있습니다 (ScreenSpot-Pro 73.0, AndroidWorld 80.2, WebVoyager 90.8, OSWorld-Verified 70.8, 모두 벤더 보고 기준). Mage-VL의 수치는 비디오 이해 및 공간 리더보드에 있습니다 (Video-MME 64.0, NExT-QA 83.1, OVO-Bench 64.0, VSI-Bench +11.0 (Qwen3-VL-4B 대비), 모두 벤더 보고 기준). 이 대결을 올바르게 읽는 방법은 갈림길로 보는 것입니다. 즉, 작업이 "이 화면에서 시간에 따라 무슨 일이 일어나고 있는지 이해하는 것"이라면 Mage-VL이 적합한 도구이고 UI-Venus-2-9B는 그 용도로 만들어지지 않았습니다. 작업이 "이 화면이 어떤 동작을 하게 만드는 것"이라면 그 반대가 성립합니다.

두 개가 어우러지는 곳

이 비교의 흥미로운 버전은 어느 한쪽만 선택하는 것이 아니다. 실시간 애플리케이션을 조작하는 GUI 에이전트에게는 진정한 사각지대가 있다. 스크린샷 사이의 시간, 그리고 정적 프레임으로 안정되지 않는 상태 변화가 바로 그것이다. 코덱 네이티브 스트림 감시자는 정확히 그 틈새에서 지각 레이어로 작동할 수 있는 모델로서, 에이전트의 다음 grounding 패스 이전에 페이지가 로딩을 완료했는지 또는 모달이 애니메이션을 끝냈는지 감지한다. Microsoft는 그 용도로 Mage-VL을 만들지 않았고, Ant Group은 두 번째 모델이 제어하도록 UI-Venus-2-9B를 만든 것도 아니지만, 그 조합은 실제로 잘 맞는다. 이미 프로덕션에 적합한 스택의 구성 요소들, 즉 작업을 분해하는 플래너 LLM, 화면 상태를 검증하는 비전 모델, 에이전트 세션을 기록하는 전사 모델을 위해서는, 마크업 없는 가격과 자동 장애 조치를 갖춘 하나의 API가 실험을 저렴하게 만들며, 바로 그 용도가 라우터다. 현재 UI-Venus-2-9B도 Microsoft Mage-VL도 OrcaRouter를 통해 서빙되지 않는다. 둘 다 오픈 가중치 자체 호스팅 프로젝트이며, 만약 라우팅된 제공업체에 도달한다면 둘 다 제공업체 목록 가격으로 표시될 것이다.

누가 어떤 것을 골라야 하나요

Microsoft Mage-VL을 선택하세요. 문제가 연속적인 지각(continuous perception)일 때 말입니다 — 카메라 피드, 화면 녹화, 실시간으로 요약하거나 모니터링해야 하면서도 계속 실행할 수 있을 만큼 저렴한 스트림 같은 것들입니다. UI-Venus-2-9B를 선택하세요. 문제가 제어(control)일 때 말입니다 — 완료된 액션, 작성된 폼, 탐색된 플로우, 조작된 애플리케이션으로 끝나는 작업이죠. 그리고 자동화에 정말로 둘 다 필요하다면 — 스트림을 지각한 다음 정지 화면에 대해 행동하는 경우 — 이 둘을 한 쌍으로 실행하고, 스트림 감시자를 이벤트 감지기로 삼아 행동할 가치가 있는 순간들을 스크린샷 에이전트에 전달하세요. 이 둘은 같은 화면의 두 절반이지, 같은 일을 두고 경쟁하는 관계가 아닙니다.