마이크로소프트 Mage-VL: 발표 없이 출시된 코덱 네이티브 4B 비디오 모델

Microsoft 블로그에는Mage-VL에 관한 게시물이 없습니다. Azure 뉴스룸 항목도, Foundry 카탈로그 등재도, 출시 스레드도, Microsoft가 평소 모델을 소개하는 제품 채널 어디에도 없습니다. 대신 존재하는 것은 Hugging Face 저장소 — microsoft/Mage-VL, 커밋 6개, 10.8GB 가중치, Apache-2.0 — 추론 스크립트가 담긴 GitHub 폴더, Microsoft Mage Team이라고 자칭하는 곳이 관리하는 프로젝트 페이지, 그리고 저자 23명의 arXiv 보고서입니다. 이 자료들을 함께 읽으면 4B 규모의 비전-언어 모델이 설명되는데, 그 핵심 아이디어는 정말 이례적입니다. 비디오를 일정 간격의 프레임으로 디코딩하고 조밀한 패치 그리드를 웹 사전 학습 인코더에 통과시키는 대신, Mage-VL은 압축된 비트스트림 자체를 읽고, Mage-ViT라는 처음부터 학습한 인코더를 사용해 코덱이 비트를 소모한 패치만 유지합니다. Microsoft는 이를 통해 시각 토큰을 75% 이상 줄이고 최대 3.5배의 wall-clock 속도 향상을 제공하며, 정적 이미지에서는 Qwen3-VL-4B에 필적하고 비디오에서는 Microsoft 자체의 15B Phi-4-Reasoning-Vision을 능가한다고 보고합니다.

마지막 문장은 거리를 두고 봐야 할 부분이다. 이 글의 모든 성능 수치는 마이크로소프트 자체 논문, 모델 카드, 또는 프로젝트 페이지에서 비롯된다. 가중치가 공개된 지 10일이 지났지만, 어떤 독립 기관도 그 어떤 것도 재현하지 못했고, 어떤 제3자 리더보드에도 이 모델이 등재되지 않았으며, Hugging Face 페이지가 명확히 밝히고 있듯이 "어떤 Inference Provider에도 배포되지 않았기" 때문에, 누군가 가볍게 벤치마크할 수 있는 호스팅 엔드포인트조차 없다. 다음 내용은 저장소가 입증하는 것과 마이크로소프트가 단순히 주장하는 것을 구분한다. 발표 없는 릴리스에서 이 둘은 매우 다른 범주이기 때문이다.

열흘째, 실제로 존재하는 것

이 릴리스의 검증 가능한 표면은 작으며, 정확히 열거할 가치가 있다.

• 가중치, 2026년 7월 26일자. 두 개의 safetensors 샤드(4.97GB 및 4.52GB)와 streammind_gate.safetensors라는 별도의 1.07GB 파일이 있습니다. Hugging Face 자체 리더는 BF16 기준 5B 파라미터를 보고하는데, 언어 디코더에 4B, 나머지는 비주얼 인코더와 해당 게이트에 분산되어 있습니다.

• 2026년 7월 27일에 제출된 기술 보고서 (arXiv 2607.24904), 단일 버전, 23명의 저자, 제목은 "Mage-VL: 효율적인 코덱 네이티브 스트리밍 멀티모달 기반 모델".

• 실행 가능한 코드, 단순한 가중치가 아닙니다.이 저장소에는 modeling_mage_vl.py, processing_mage_vl.py, 전용 코덱 비디오 프로세서인 codec_video_processing_mage_vl.py를 포함한 두 개의 비디오 프로세서, 그리고 streammind_gate.py가 포함되어 있습니다 — 약 175KB의 맞춤형 Python 코드입니다. config.json의 auto_map은 여섯 개의 Transformers 클래스를 해당 파일들로 라우팅하며, 이것이 이 저장소에 custom_code 태그가 붙은 이유입니다.

• 라이선스는 하나가 아니라 둘입니다. Mage-VL은 Apache-2.0이며, 독립형 Mage-ViT 인코더는 MIT 라이선스로 별도 배포됩니다.

• 설치할 필요 없는 작동 데모. Microsoft는 microsoft/mage-vl-demo를 ZeroGPU의 Hugging Face Space로 실행하고 있으며, 두 개의 커뮤니티 Space에서 이미 이 모델을 사용하고 있습니다.

• 초기 커뮤니티 반응이 공급업체 자체의 커뮤니케이션보다 더 빠르게 형성되고 있습니다. 지난 한 달간 좋아요 268개, 다운로드 435,784회가 기록되었으며, 모델 트리에는 커뮤니티 양자화 9개와 파인튜닝 2개가 포함되어 있습니다. 다운로드 카운터에는 자동화된 풀과 미러 풀이 포함되므로, 원시 숫자는 배포의 신호가 아닌 관심의 신호로 간주해야 합니다.

• 형제 모델. Mage-Flow는 동일한 고정 4B 예산으로 구축된 텍스트-이미지 및 지시 편집 모델로, 7월 22일에 나흘 앞서 출시되었습니다. GitHub 저장소는 Mage를 "경량의 연구 친화적인 다중 모달 모델 제품군"으로 소개하는데, 이는 누구든지 공개한 포지셔닝 스테이트먼트에 가장 가까운 표현입니다.

그에 비추어 보면, 존재하지 않는 것들의 목록도 그만큼 유익하다. 마이크로소프트 블로그 게시물이나 보도자료는 없다. Azure AI Foundry에 등재도 없으며, 이는 엔터프라이즈 지원 경로, SLA, 관리형 엔드포인트가 없음을 의미한다. 어떤 추론 제공업체도 이를 서비스하지 않는다. vLLM이나 SGLang 지원도 없다. Mage-VL을 SGLang에 추가하라는 커뮤니티 요청이 7월 28일 이슈 #32646으로 접수되었지만, 이 글을 쓰는 시점에도 연결된 풀 리퀘스트나 관리자 응답 없이 열려 있는 상태다. 그리고 어떤 종류의 독립적 평가도 없다. "15B 모델을 비디오에서 이긴다"는 주장이 일반적으로 검증될 중립적 리더보드에서 해당 모델은 완전히 부재하다.

단 하나의 아이디어: 프레임이 아닌 코덱을 읽어라

프로덕션에서 사용되는 거의 모든 비디오 지원 VLM은 같은 방식으로 작동합니다. 비디오를 RGB 프레임으로 디코딩하고, 1초에 하나, 또는 클립 전체에서 32개, 또는 예산이 허용하는 만큼 균일하게 샘플링한 다음, 각 샘플링된 프레임을 비전 트랜스포머에 패치의 밀집 격자로 전달합니다. 샘플링된 각 프레임의 모든 패치는 토큰이 됩니다. 정적인 배경 벽은 그 앞을 걷는 사람과 정확히 동일한 수의 토큰을 소비하며, 다음 프레임에서도, 그 다음 프레임에서도 다시 그만큼을 소비합니다.

그것은 엄청난 양의 중복 계산이며, 현대 비디오 코덱은 이미 수십 년 전에 근본적인 문제를 해결했습니다. H.264와 HEVC는 모든 프레임을 저장하지 않습니다. 가끔 앵커(I) 프레임을 전체로 저장하고, 그 사이의 프레임들은 모션 벡터와 잔차로 설명합니다 — "이 블록은 여기로 이동했고, 이것이 변경된 내용입니다." 비디오에서 흥미로운 부분은 거의 정의상 인코더가 비트를 소비한 부분입니다.

16x16 패치 단위로 동작하는 Mage-ViT는 그 점을 직접 활용합니다. 앵커 프레임의 모든 패치는 유지하고, 예측 프레임의 경우 코덱 자체의 움직임 벡터와 잔차 에너지가 중요하다고 표시한 패치만 남깁니다. 즉 실제 정보, 움직임, 또는 장면 전환을 담고 있는 영역만 유지하고, 중복도가 낮거나 완전히 중복되는 패치는 버립니다. Microsoft는 이로 인해 시각적 토큰이 75% 이상 줄어들고, 앵커 프레임이 여전히 전체 장면을 담고 있으므로 시공간적 맥락이 보존된다고 보고합니다. 이 설계는 코덱에 무관합니다. 기존 경로는 H.264 또는 HEVC를 수용하고, 신경망 경로는 DCVC-RT를 수용합니다.

우아한 점은 움직임 추정이 이미 수행되어 있다는 것이다. 인터넷의 모든 압축된 비디오에는 인코더가 계산하고 업로더가 비용을 지불한, 액션이 어디에 있는지에 대한 지도가 함께 제공된다. 기존 파이프라인은 RGB로 디코딩되는 순간 그 지도를 버리고, 동일한 정보를 다시 찾기 위해 GPU 시간을 소비한다. Mage-VL은 단순히 그것을 버리지 않기로 한 것이다. 벤치마크 수치가 유지되는지 여부와 관계없이, 그 관찰이 이번 릴리스의 지속적인 기여이며 — 가중치를 다운로드하지 않더라도 이번 릴리스를 읽을 가치가 있는 이유다.

실험에서 가장 깔끔한 점

설정에 묻혀 있는 설계 결정 덕분에 이번 결과는 일반적인 모델 출시보다 훨씬 더 해석하기 쉬운데, 이번 출시를 보도하는 거의 아무도 그것을 지적하지 않았다: 바로 언어 모델이 고정되어 있다는 점이다.

Mage-VL의 디코더는 수정되지 않은 Qwen3-4B-Instruct-2507입니다. 비교 기준선인 Qwen3-VL-4B는 동일한 4B Qwen3 백본에 기존의 웹 사전 훈련된 시각적 인코더를 사용합니다. 따라서 Mage-VL이 Qwen3-VL-4B보다 향상된 경우, 그 차이는 더 크거나 더 잘 훈련된 언어 모델이 아니라 인코더와 코덱-네이티브 토큰화에 기인합니다. 그것은 제품 비교로 포장된 통제된 제거(ablation) 실험이며, 이번 릴리스의 가장 강력한 방법론적 특징입니다.

이는 또한 반대 방향으로도 작용하며, 정직하게 말하려면 그 점을 인정해야 한다. 동일 백본 비교는 인코더 아이디어를 가장 공정하게 시험하는 방식이면서 동시에 그것을 가장 호의적으로 보이게 할 가능성이 높은 프레임이다. 마이크로소프트는 자체 기여를 분리해 내는 기준선을 선택했다. Phi-4 비교는 그런 속성을 갖지 못한다. Phi-4-Reasoning-Vision-15B와 Phi-4-MM-5.6B는 서로 다른 백본, 서로 다른 훈련 레시피, 서로 다른 후속 훈련을 거쳤다. "비디오에서 우리의 15B 모델을 이긴다"는 것은 실제 결과이지만 훨씬 더 느슨한 결과이며, 또한 마이크로소프트 자신의 이전 작업과의 비교로서 이기기 가장 쉬운 종류의 비교이기도 하다.

훈련 규모는 이 논문이 정말로 놀라운 주장을 하는 또 다른 지점이다. Mage-ViT는 약 5억 6천만 개의 레이블이 없는 이미지와 1억 개의 레이블이 없는 비디오 프레임으로 처음부터 사전 훈련되었다. 이는 절대적인 규모로는 큰 코퍼스이지만, 경쟁 대상 인코더들이 사용하는 수십억 개의 선별된 이미지-텍스트 쌍에는 크게 미치지 못한다. 이 논문이 처음으로 밝힌 발견은 강력한 VLM 인코더가 웹 규모의 지도 학습 데이터를 요구하지 않는다는 것이다. 그것이 독립적인 검증에서도 유지된다면, 이는 어떤 단일 벤치마크 항목보다 훨씬 더 중요하다.

그 숫자들, 그리고 그 숫자들이 누구의 숫자인지

이어지는 내용은 전반에 걸쳐 Microsoft가 보고한 것으로, Microsoft 자체 평가 하네스에서 Microsoft가 선정한 기준선을 대상으로 한 결과입니다. 여기에는 제3자가 재현한 것이 없습니다. 이것은 유난히 구체적인 오차 범위를 가진 가설로 읽어야지, 점수판으로 읽어서는 안 됩니다.

• Video-MME — Mage-VL-4B 64.0 대 Qwen3-VL-4B 59.7 대 Phi-4-Reasoning-Vision-15B 55.3

• NExT-QA — 83.1 대 79.8 대 69.0

• LongVideoBench — 61.3 vs 57.7 vs 51.2

• VideoEval-Pro — 45.2 vs Phi-4의 20.7

• Timelens-QVHighlight (시간적 접지) — 57.4 vs 34.9 vs 11.6

• Ref-DAVIS17 (참조 추적) — 25.83 대 7.48 대 2.15

• DocVQA-val — 95.14 vs 94.69 vs 92.79 (Phi-4-MM-5.6B)

• OCRBench — 81.80 vs 81.60 vs 81.70

• ChartQA — 84.88 대 83.96 대 83.40

• MMStar — 67.32 vs 62.04 vs 59.63

• RealWorldQA — 70.46 vs 70.85 vs 70.72, Mage-VL이 패배하는 항목 중 하나

• MMBench-EN-dev — 84.02 대 83.25, Phi-4-Reasoning-Vision-15B가 84.19로 둘 모두를 앞섬

• CV-Bench-3D / CV-Bench-2D — 94.75 vs 92.30, 및 82.13 vs 81.00

• EmbSpatial — 82.67 vs 77.50

• OVO-Bench (streaming) — 64.00 종합 점수, 스트리밍 아키텍처 중 최첨단으로 설명됨; 실시간 시각 인식 하위 집합은 1fps에서 Qwen3-VL-4B의 72.8%에 비해 평균 79.84%를 기록

• 독립형 인코더로서의 Mage-ViT — ImageNet에서 676토큰 예산으로 86.3% 이상, Food-101에서 96.1% 이상

그 표에 대한 세 가지 해석은 그 표 자체보다 더 가치가 있다.

이미지에서 "동등함(parity)"이 정직한 표현이다. DocVQA에서 0.45, OCRBench에서 0.20, ChartQA에서 0.92, MMBench에서 0.77 — 이러한 차이는 프롬프트 템플릿이나 디코딩 시드가 달라지면 순위가 뒤집힐 수 있는 범위에 있으며, RealWorldQA는 실제로 Qwen3-VL-4B 쪽으로 기운다. Microsoft도 이를 인정해 이미지 성능을 우위가 아닌 동등함으로 규정했고, 그 규정이 정확하다. 작업 부하가 문서 및 이미지 질의응답이라면 이번 릴리스는 옮겨갈 이유를 주지 않는다.

비디오 및 시간적 그라운딩에서는 격차가 크고 일관적입니다.Timelens-QVHighlight는 기준선을 거의 두 배로 끌어올립니다. Video-MME, NExT-QA, LongVideoBench는 모두 백본을 고정한 상태에서 같은 방향으로 3.6~4.3포인트씩 이동합니다. 서로 다른 측면을 검증하는 벤치마크들에서의 일관성은, 인코더 변경이 튜닝 부산물이 아니라 실제 효과일 때 기대되는 패턴입니다.

두 행은 맥락 없이 인용해서는 안 된다.Ref-DAVIS17의 25.83 대 7.48은 3.5배 차이의 압도적 승리처럼 보이며, 논문의 주요 공간 델타에는 VSI-Bench에서 +11.0, CrossPoint에서 +53.1이 포함된다. 어떤 작업에서 베이스라인이 바닥에 가까운 점수를 받으면, 그 델타는 대체로 어떤 모델이 작업 형식을 이해하도록 훈련되었는지를 측정할 뿐, 어떤 모델이 더 유능한지를 측정하는 것이 아니다. 동일한 주의가 스트리밍 결과의 절대 수치에도 적용된다: SoccerNet에서 Mage-VL의 보고된 수치는 TimVal 55.54, ROC-AUC 83.14, F1 16.35이다. F1 16.35는 아직 초기인 평가 분야에서 최첨단 수준의 수치이며, 해결된 문제를 의미하지 않는다. 프로액티브 스트리밍 인식은 초기 단계에 있으며, 선두 모델의 절대 점수가 이를 말해준다.

게이트: 언제 말할지 결정하는 모델

두 번째 아키텍처 아이디어는 제품에 가장 명확한 시사점을 지니며, 그 수수께끼의 1.07 GB 파일을 설명합니다.

Mage-VL은 스트리밍을 두 프로세스로 나누며, 논문에서는 System 1과 System 2로 설명합니다. System 1은 가벼운 "인지 게이트(cognition gate)"로, 코덱 특징의 각 롤링 윈도우를 관찰하여 말할 가치가 있는 어떤 일이 방금 끝났을 확률을 추정합니다. 임계값 아래에서는 침묵을 유지하고 모델의 고비용 부분은 실행되지 않습니다. 임계값 이상이면 전체 디코더가 호출되어 응답을 생성합니다. 데모 구성은 1fps에서 30초 인과 윈도우를 사용하며, CLI는 임계값을 --gate_threshold로 직접 노출하고, 스트리밍 진입점은 비디오 세그먼트를 세그먼트 단위로 처리합니다 (inference_streaming.py --video_backend codec --segment_sec 8). 최종 단계에서는 335만 개의 스트리밍 샘플로 게이트만 훈련됩니다.

그 점에서 주목할 만한 것이 두 가지 있다. 첫째, 그 게이트는 위에 덧붙여진 작은 분류 헤드가 아니다. BF16 가중치 1.07GB는 대략 5억 개의 파라미터에 해당하며, 그 자체로 하나의 실제 모델로서 별도의 체크포인트로 제공된다. 둘째, 파일 이름은 streammind_gate.safetensors인데, 이러한 명명은 이 구성 요소가 이 논문을 위해 새로 만들어진 것이 아니라 이전의 스트리밍-지각(streaming-perception) 연구에서 유래했음을 시사한다. 다만 저장소 자체는 그 계보를 명시적으로 밝히지 않는다.

상업적으로 왜 중요한가: 상시 작동하는 비디오의 경우, 지배적인 비용은 호출당 지연 시간이 아니라 호출 빈도입니다. 기존 VLM을 통해 24/7 초당 1프레임으로 실행되는 카메라 피드는 어떤 일이 발생했든 하루에 86,400번의 순방향 패스를 수행합니다. 아무 일도 일어나지 않는 영상의 99% 동안 조용히 있는 게이트는 청구서의 크기뿐 아니라 형태를 바꿉니다. Microsoft의 게이트가 그 결정을 맡길 만큼 정확한지 여부가 바로 연구소 밖에서는 아무도 테스트하지 않은 부분입니다.

오늘 실제로 그것을 실행할 수 있나요?

네, GPU와 인내심이 있다면요. 그 마찰은 실제이며, 대부분 모델보다는 비디오 파이프라인에 있습니다.

메모리. 마이크로소프트는 VRAM 요구 사항을 공개하지 않습니다. 가중치 인덱스 기준으로 샤드 9.49GB와 게이트 1.07GB를 합하면 BF16 파라미터가 약 10.6GB이므로, 이미지 작업에는 16GB 카드가 현실적인 최소 사양이고, 긴 동영상이나 스트리밍 윈도우용 KV 캐시를 추가하면 24GB 이상이 합리적인 목표입니다. 이는 파일 크기에서 계산한 산술적인 수치일 뿐 공급업체 사양이 아닙니다 — 프로비저닝 전에 직접 측정하세요.

커스텀 코드는 필수입니다. auto_map은 모든 Transformers 진입점을 저장소의 자체 모듈을 가리키므로 trust_remote_code가 필요합니다. 단순히 텐서를 로드하는 것이 아니라 Microsoft의 Python 코드를 실행하는 것입니다. 아직 vLLM이나 SGLang 경로가 없으므로 paged attention도, continuous batching도, 프로덕션 서빙 스택도 없습니다. 엔드포인트 뒤에 배치하려는 경우에는 상당한 공백입니다.

코덱 경로에는 시스템 도구가 필요합니다. FFmpeg와 ffprobe는 PATH에 있어야 합니다. 기존 코덱 백엔드는 cv-preinfer 단계를 제공하는 codec-video-prep 패키지에 의존하며, 신경망 경로에는 DCVC-RT가 필요하고, 일반 프레임 백엔드에는 Decord가 필요합니다. 또한 요구 사항에는 CUDA 확장을 컴파일하는 flash-attn과 mamba-ssm이 포함되므로, 먼저 툴킷과 일치하는 PyTorch 빌드를 설치하거나 빌드에 오후 시간을 할애하세요.

카드가 알려주지 않는 것을 설정이 알려준다.최대 위치 임베딩은 262,144이므로 디코더는 Qwen3-4B의 긴 컨텍스트를 상속받습니다. 비전 쪽은 448픽셀 입력, 16x16 패치, 24레이어 1024히든 인코더, 2x2 공간 병합, 비디오 1초당 토큰 1개, 4프레임 창으로 작동합니다. 훈련은 3단계에서 시간적 길이 384프레임에 도달했습니다. 262K 상한은 검증된 동작의 262K와 같지 않으며, 384프레임은 모델이 실제로 처리하도록 학습된 길이입니다.

알려진 미흡한 점.8월 4일에 제기되어 아직 답변을 받지 못한 저장소의 공개 토론에서는 이미지와 비디오가 동일한 요청으로 전달될 때 토큰 정렬 문제가 발생한다고 보고합니다. 출시 10일 차 소프트웨어는 출시 10일 차 소프트웨어답게 행동합니다. 이런 문제 없이 살펴보고 싶다면 Microsoft가 운영하는 ZeroGPU의 Space가 설치 없이 이용할 수 있는 옵션입니다.

라이선스 표기는 "Apache-2.0"만큼 단순하지 않습니다.

모델 카드에는 Apache-2.0이라고 명시되어 있습니다. Mage-ViT 인코더는 MIT 라이선스를 사용합니다. 둘 다 오픈 가중치(open weights) 기준으로는 거의 가장 허용적인 수준입니다. 하지만 패밀리 저장소는 "이 모델들은 연구 목적으로만 공개되었다"고 명시하면서, 책임 있는 AI 검토와 인간의 감독을 강조합니다. 그리고 그 문장은 상업적 사용을 제한하지 않는 Apache-2.0 허가와 어색하게 나란히 놓입니다. 여기에 의존성까지 더하면: DCVC-RT와 코덱 준비 도구는 모델과는 별개로 각자의 조건을 지닙니다.

취미 프로젝트로서는 그냥 잡음일 뿐이다. 고객에게 배송되는 무엇이든 간에, 이는 프로덕션에 들어가기 전에 법무 검토를 거쳐야 하는 모호함이며, 저장소 자체에서 질문할 가치가 있는 문제다 — 특히 현재 마이크로소프트 담당자가 답변하고 있지 않은 상황에서는.

이것을 기반으로 구축해야 할까요?

그 결정은 하나의 기준으로 명확히 갈린다: 문제가 스트림인지 요청인지.

항상 켜져 있는 인식(always-on perception) 작업 — 카메라 피드, 실시간 방송, 로봇의 시야, 한 시간 동안 진행되는 회의 — 을 처리하고 있다면, Mage-VL은 정확히 당신을 겨냥하고 있으며 자체 호스팅의 경제성은 당신 편입니다. 토큰당 API 가격이 프레임 수에 따라 증가하는 구조는 연속 비디오에는 매우 가혹한 모델입니다. 자체 하드웨어에서 돌아가는 4B 모델에, 특별한 일이 없는 영상에서는 침묵을 유지하는 게이트가 결합되면 이는 근본적으로 다른 비용 곡선을 만들어냅니다. 문제는 당신이 Microsoft 외부에서 그 게이트의 판단이 실제로 쓸 만한지 알아내는 첫 번째 사람이 된다는 것입니다.

문제가 요청 형태, 즉 사용자가 문서, PDF, 스크린샷, 짧은 클립을 업로드하고 답변을 기대하는 형태라면 그 근거는 훨씬 약해집니다. 바로 그러한 작업에서 Mage-VL은 여전히 직접 호스팅해야 하는 모델과 동등한 성능을 보이며, 호스팅형 멀티모달 엔드포인트는 GPU, ffmpeg 빌드, trust_remote_code 없이 API 호출 한 번이면 됩니다. OrcaRouter에서는 Gemini 3.6 Flash가 입력 토큰 100만 개당 $1.50, 출력 토큰 100만 개당 $7.50이며, 이는 공급업체의 공시 가격을 그대로 통과시킨 것입니다. 저희는 마크업 0%를 적용하므로, 공급업체가 가격을 인하하면 그 할인은 가격 검토를 거친 후가 아니라 당일 바로 저희 쪽에도 반영됩니다. 하나의 키로 200개 이상의 모델에 접근할 수 있으며, 공급업체의 성능이 저하되면 자동 장애 조치(failover)가 이루어집니다. 이것이 호스팅 엔드포인트를 기본값으로 유지하고, 자체 호스팅은 진정으로 필요한 워크로드에만 사용해야 하는 실질적인 이유입니다.

명확히 하자면, 그 구분이 중요하기 때문입니다: 우리는 Mage-VL을 호스팅하지 않으며, 다른 누구도 호스팅하지 않습니다. Hugging Face의 자체 모델 페이지에는 어떤 추론 제공업체도 이를 배포하지 않았다고 나와 있습니다. 오늘날 이를 실행한다는 것은 직접 실행하는 것을 의미합니다.

무엇이 이 읽기를 바꿀까요?

대략 중요도가 높은 순서대로 네 가지.

독립 평가가 가장 중요합니다. 위의 모든 숫자는 주장이며, 가장 검증이 필요한 주장은 벤치마크 점수가 아니라 NExT-QA에서 균일 프레임 샘플링을 기준으로 측정된 3.5배 속도 향상입니다. 이 수치는 게시된 하드웨어, 해상도 또는 프레임 수 세부 정보 없이 측정되었습니다. {{1}}코덱 전처리는 실제 작업을 CPU와 ffmpeg로 이동시킵니다{{/1}}; 다른 사람의 시스템에서 엔드투엔드로 측정된 실제 소요 시간상의 이점만이 계획을 세울 가치가 있는 유일한 버전의 수치입니다.

둘째, 서빙 지원입니다. vLLM 또는 SGLang 구현체가 병합되면, 이 연구용 체크포인트를 로드 밸런서 뒤에 배치할 수 있는 무언가로 바꿔줍니다. SGLang 이슈는 열려 있고 아직 담당자가 없으며, 바로 그 스레드를 주목해야 합니다.

셋째, Azure AI Foundry에 등재되는 것은 마이크로소프트가 이를 논문이 아닌 제품으로 의도하고 있다는 신호가 될 것입니다. 현재 릴리스에서는 그러한 일이 임박했음을 시사하는 어떤 것도 없습니다.

넷째, 그리고 가장 이상한 점은: 마이크로소프트가 어떤 입장 표명을 할지 여부다. 23명의 저자가 쓴 기술 보고서, 유지 관리되는 프로젝트 페이지, 호스팅된 데모 Space, 그리고 4일 전에 공개된 자매 생성 모델은 유출이나 사고를 설명하는 것이 아니다. 그것들은 제품 홍보용 확성기를 완전히 건너뛴 의도적인 연구 발표를 설명한다. 그럼에도 커뮤니티는 열흘 안에 아홉 개의 양자화와 두 개의 파인튜닝을 내놓으며 침묵을 메웠다.

대부분의 팀에게 {{1}}옳은 선택은 가중치(weights)를 다운로드하는 것이 아니라 논문을 읽는 것{{/1}}입니다. 코덱 고유의 아이디어가 핵심이며, 이는 이식 가능합니다: {{2}}인코더가 이미 계산한 모션 벡터를 재사용하는 것이 실제로 동일 정확도에서 토큰을 75% 줄여준다면{{/2}}, 그 기법은 출시 포스트, 제공업체 지원, 재현된 벤치마크를 갖춘 모델들에 나타날 것입니다. 오늘날 연속 비디오를 실행한다면 판단 기준이 다릅니다 — {{3}}저장소를 클론하고, 자체 클립을 두 백엔드 모두에서 실행하고, 속도 향상을 직접 측정하세요{{/3}}, 왜냐하면 {{4}}지금 당신이 첫 번째가 될 것이기 때문입니다{{/4}}.

실제로 물어볼 가치가 있는 질문들

Mage-VL은 Microsoft 라벨을 붙인 Qwen3-VL에 불과한가요?

아니요, 혼동할 만도 합니다. 언어 디코더는 Qwen3-4B-Instruct-2507을 그대로 사용한 것이며, 마이크로소프트가 새로운 LLM을 학습시킨 것은 아닙니다. 나머지는 전부 새롭습니다. Mage-ViT는 처음부터 사전학습되었고, 코덱 네이티브 토크나이제이션은 Qwen3-VL에 대응하는 것이 없으며, 스트리밍 게이트는 추가로 도입된 5억 파라미터 규모의 모델입니다. 오픈 백본을 재사용하고 비주얼 프런트엔드를 교체하는 것은 정당하고 점점 더 보편화되는 연구 전략이며, 여기서는 바로 그 덕분에 직접 비교가 해석 가능해지기도 합니다. 모델 출처(provenance) 관련 컴플라이언스 요구사항이 있다면, 계보가 Alibaba의 Qwen3 가중치를 거친다는 점을 유의하고 두 라이선스를 모두 확인하세요.

"3.5x faster"가 서빙 비용이 3.5배 저렴하다는 뜻인가요?

확실하지 않습니다. 해당 수치는 NExT-QA에서 균일 프레임 샘플링 대비 실제 경과 시간(wall-clock) 속도 향상이며, Microsoft는 이를 "최대"라고 표현합니다. 실제로는 두 가지가 그 효과를 약화시킵니다. 코덱 기반 추론에는 준비 과정이 필요합니다 — ffmpeg, ffprobe, cv-preinfer 단계, 또는 신경망 경로의 경우 DCVC-RT 재인코딩 — 이는 단순한 프레임 파이프라인에는 없는 CPU 시간을 소비하며 GPU 측정에는 포함되지 않습니다. 그리고 그 이득은 토큰 감소에서 비롯되므로 영상의 중복성에 따라 달라집니다: 대부분 정적인 보안 카메라 영상은 제시된 수치보다 나은 결과를 보여야 하고, 거의 모든 패치가 변하는 빠른 컷 편집 영상은 더 나쁜 결과를 보여야 합니다. 직접 영상으로 측정해 보세요.

코덱 경로를 사용하려면 특별한 동영상 파일이 필요한가요?

대체로 그렇지 않으며, 이것이 기분 좋은 놀라움입니다. 일반 MP4 파일은 이미 H.264 또는 HEVC로 인코딩되어 있는데, 이는 전통적인 코덱 백엔드가 소비하는 바로 그 형식입니다. 필요한 모션 벡터는 이미 가지고 있는 파일 안에 들어 있습니다. 추가로 필요한 것은 도구입니다: PATH에 FFmpeg와 ffprobe, 그리고 코덱 준비 패키지입니다. 신경망 백엔드는 예외입니다. DCVC-RT는 해당 코덱으로 인코딩된 비디오를 기대하므로, 다시 인코딩해야 합니다. 그리고 일반 프레임 백엔드는 다른 VLM처럼 동작하는 폴백으로 계속 사용 가능하며, 이는 코덱 주장을 스스로 A/B 테스트하는 정직한 방법이기도 합니다.

상업적으로 사용할 수 있나요?

라이선스는 Apache-2.0이라고 명시되어 있으며, 이는 상업적 사용, 수정, 재배포를 허용합니다. 또한 저장소에는 모델이 {{1}}"연구 목적으로만 공개되었다"{{/1}}고 명시되어 있습니다. 이 두 진술은 서로 다른 방향을 가리키며, 그 간극은 Microsoft 측 어느 누구도 명확히 해명하지 않았습니다. 발표도, 제품 등록도, 저장소 토론에서 공급업체의 참여도 없는 릴리스라는 점을 고려하면 이는 놀라운 일이 아닙니다. 만약 답에 따라 돈이 좌우된다면, {{2}}라이선스 배지만 믿지 말고 변호사를 고용해 두 문서와 의존성 라이선스를 검토하게 하십시오.{{/2}}