Microsoft Mage-VL: Mô hình video 4B gốc codec, ra mắt không kèm thông báo

Không có bài đăng blog nào của Microsoft về Mage-VL. Không có bài đăng nào trên newsroom Azure, không có mục nào trong danh mục Foundry, không có chủ đề ra mắt, không có gì trên các kênh sản phẩm nơi Microsoft thường giới thiệu mô hình. Thay vào đó, những gì tồn tại là một kho lưu trữ Hugging Face — microsoft/Mage-VL, sáu commit, 10.8 GB trọng số, Apache-2.0 — một thư mục GitHub chứa các tập lệnh suy luận, một trang dự án được duy trì bởi một thực thể tự xưng là Nhóm Microsoft Mage, và một báo cáo arXiv với 23 tác giả. Khi đọc cùng nhau, các hiện vật này mô tả một mô hình ngôn ngữ-thị giác quy mô 4B với ý tưởng trung tâm thực sự khác thường: thay vì giải mã video thành các khung hình cách đều và đẩy một lưới dày đặc các patch qua một bộ mã hóa được tiền huấn luyện trên web, Mage-VL tự đọc luồng bit nén, sử dụng một bộ mã hóa được xây dựng từ đầu có tên là Mage-ViT để chỉ giữ lại những patch mà codec đã dành bit cho. Microsoft báo cáo rằng điều này cắt giảm hơn 75% số token thị giác và mang lại tốc độ tăng tốc lên tới 3,5 lần (wall-clock) trong khi vẫn ngang bằng với Qwen3-VL-4B trên ảnh tĩnh và vượt qua mô hình 15B Phi-4-Reasoning-Vision của chính Microsoft trên video.

Câu cuối cùng đó chính là phần cần giữ ở một khoảng cách nhất định. Mọi con số hiệu năng trong bài viết này đều quy về chính bài nghiên cứu, thẻ mô hình hoặc trang dự án của Microsoft. Mười ngày sau khi các bộ trọng số xuất hiện, chưa có bên độc lập nào tái lập được bất kỳ kết quả nào, không có bảng xếp hạng bên thứ ba nào đưa mô hình lên, và — như trang Hugging Face nêu rõ — nó "không được triển khai bởi bất kỳ Nhà cung cấp suy luận nào", nên thậm chí cũng không có một endpoint được lưu trữ nào mà ai đó có thể chạy thử một cách thông thường. Phần tiếp theo sẽ phân tách điều kho lưu trữ chứng minh được với điều Microsoft chỉ đơn thuần tuyên bố, bởi vì với một bản phát hành không có thông báo chính thức, hai phạm trù đó khác biệt rất rõ ràng.

Những gì thực sự tồn tại, sau mười ngày

Phạm vi có thể xác minh của bản phát hành này là nhỏ và đáng để liệt kê một cách chính xác.

• Trọng số, ngày 26 tháng 7 năm 2026. Hai phân đoạn safetensors dung lượng 4,97 GB và 4,52 GB, cùng một tệp 1,07 GB riêng biệt có tên streammind_gate.safetensors. Trình đọc của chính Hugging Face báo cáo 5B tham số ở BF16 — 4B trong bộ giải mã ngôn ngữ, phần còn lại được chia giữa bộ mã hóa hình ảnh và cổng đó.

• Một báo cáo kỹ thuật, được đệ trình ngày 27 tháng 7 năm 2026 (arXiv 2607.24904), một phiên bản, 23 tác giả, mang tựa đề "Mage-VL: An Efficient Codec-Native Streaming Multimodal Foundation Model."

• Mã chạy được, không chỉ là trọng số. Repo này cung cấp modeling_mage_vl.py, processing_mage_vl.py, hai bộ xử lý video bao gồm codec_video_processing_mage_vl.py chuyên dụng, và streammind_gate.py — khoảng 175 KB mã Python tùy chỉnh. auto_map trong config.json định tuyến sáu lớp Transformers vào các tệp đó, đó là lý do repo mang thẻ custom_code.

• Hai giấy phép, không phải một. Mage-VL được cấp phép theo Apache-2.0; bộ mã hóa Mage-ViT độc lập được phát hành riêng theo MIT.

• Bản demo hoạt động mà bạn không cần cài đặt. Microsoft chạy microsoft/mage-vl-demo dưới dạng Hugging Face Space trên ZeroGPU, và hai Space cộng đồng đã sử dụng mô hình này.

• Sức hút cộng đồng ban đầu, hình thành nhanh hơn cả truyền thông của nhà cung cấp. 268 lượt thích, 435.784 lượt tải xuống được ghi nhận trong tháng qua, chín bản lượng tử hóa cộng đồng và hai bản tinh chỉnh trong cây mô hình. Bộ đếm tải xuống bao gồm cả các lượt tải tự động và từ mirror, vì vậy hãy coi con số thô này là tín hiệu về sự chú ý hơn là mức độ triển khai.

• Một phiên bản anh em. Mage-Flow, một mô hình chuyển văn bản thành hình ảnh và chỉnh sửa theo hướng dẫn, được xây dựng với cùng ngân sách cố định 4B, đã ra mắt sớm hơn bốn ngày, vào ngày 22 tháng 7. Kho lưu trữ GitHub giới thiệu Mage là "một gia đình các mô hình đa phương thức nhẹ, thân thiện với nghiên cứu," đây là điều gần nhất với một tuyên bố định vị mà bất kỳ ai từng công bố.

Trong khi đó, danh sách những thứ không tồn tại cũng đầy thông tin không kém. Không có bài đăng blog hay thông cáo báo chí nào từ Microsoft. Không có mục nào trong Azure AI Foundry, nghĩa là không có lộ trình hỗ trợ doanh nghiệp, không có SLA, không có endpoint được quản lý. Không có nhà cung cấp suy luận nào phục vụ nó. Không có hỗ trợ vLLM hay SGLang: một yêu cầu từ cộng đồng để thêm Mage-VL vào SGLang đã được gửi vào ngày 28 tháng 7 với mã số issue #32646 và, tính đến thời điểm viết bài này, vẫn còn mở với không có pull request được liên kết và không có phản hồi từ người duy trì. Và không có bất kỳ đánh giá độc lập nào — mô hình này vắng mặt trên các bảng xếp hạng trung lập, nơi một tuyên bố như "đánh bại mô hình 15B về video" thông thường sẽ được kiểm chứng.

Ý tưởng duy nhất: hãy đọc codec, không phải các khung hình.

Hầu như mọi VLM có khả năng xử lý video đang được triển khai trong sản xuất đều làm cùng một điều. Nó giải mã video thành các khung hình RGB, lấy mẫu đều đặn — mỗi giây một khung, hoặc 32 khung trên toàn bộ clip, hoặc bất cứ ngân sách nào cho phép — rồi đưa từng khung hình đã lấy mẫu qua một vision transformer dưới dạng một lưới patch dày đặc. Mỗi patch của từng khung hình lấy mẫu sẽ trở thành token. Một bức tường nền tĩnh tốn đúng bằng số token như người đi bộ phía trước nó, và nó lại tiếp tục tốn thêm ở khung hình tiếp theo, rồi khung hình tiếp theo nữa.

Đó là một khối lượng tính toán dư thừa khổng lồ, và các codec video hiện đại đã giải quyết vấn đề cơ bản này từ nhiều thập kỷ trước. H.264 và HEVC không lưu trữ mọi khung hình; chúng lưu trữ đầy đủ các khung hình neo (I) không thường xuyên rồi mô tả các khung hình ở giữa dưới dạng vector chuyển động cộng với phần dư — "khối này đã di chuyển đến đây, và đây là những gì đã thay đổi." Các phần thú vị của video, gần như theo cấu trúc, chính là những phần mà bộ mã hóa đã dành bit để xử lý.

Mage-ViT khai thác trực tiếp điều đó. Hoạt động ở mức chi tiết patch 16x16, nó giữ lại mọi patch của các khung neo và, đối với các khung dự đoán, chỉ giữ lại các patch được codec đánh dấu là nổi bật dựa trên vector chuyển động và năng lượng dư của chính codec — các vùng mang thông tin thực sự, chuyển động hoặc thay đổi cảnh — đồng thời loại bỏ các patch có độ dư thừa thấp và dư thừa hoàn toàn. Microsoft ước tính mức giảm này lên tới hơn 75% số token thị giác, trong khi bối cảnh không gian-thời gian vẫn được bảo toàn vì các khung neo vẫn mang toàn bộ cảnh. Thiết kế này không phụ thuộc codec: đường dẫn truyền thống chấp nhận H.264 hoặc HEVC, và đường dẫn thần kinh chấp nhận DCVC-RT.

Điểm tinh tế nằm ở chỗ việc ước lượng chuyển động đã được thực hiện sẵn. Mọi video nén trên internet đều đến kèm một bản đồ về nơi hành động diễn ra, được bộ mã hóa tính toán và được trả phí bởi người đã tải nó lên. Một pipeline thông thường sẽ vứt bỏ bản đồ đó ngay khi giải mã sang RGB, rồi tốn thời gian GPU để khám phá lại cùng một thông tin. Mage-VL chỉ đơn giản là từ chối loại bỏ nó. Dù những con số benchmark có đứng vững hay không, quan sát đó chính là đóng góp bền vững ở đây — và đó là lý do bản phát hành này đáng để đọc ngay cả khi bạn không bao giờ tải các trọng số về.

Điều sạch sẽ nhất về thí nghiệm

Ẩn trong cách thiết lập là một quyết định thiết kế khiến kết quả dễ diễn giải hơn nhiều so với một bản phát hành mô hình điển hình, và hầu như không ai đưa tin về bản phát hành này đã chỉ ra điều đó: mô hình ngôn ngữ được giữ cố định.

Bộ giải mã của Mage-VL là Qwen3-4B-Instruct-2507, không được sửa đổi. Đường cơ sở so sánh, Qwen3-VL-4B, sử dụng cùng bộ khung nền Qwen3 4B với một bộ mã hóa thị giác được tiền huấn luyện trên web thông thường. Vì vậy, khi Mage-VL vượt trội hơn Qwen3-VL-4B, phần chênh lệch là do bộ mã hóa và phương pháp token hóa bản địa codec, chứ không phải do mô hình ngôn ngữ lớn hơn hay được huấn luyện tốt hơn. Đó là một thí nghiệm ablation có kiểm soát được ngụy trang thành so sánh sản phẩm, và là điểm mạnh nhất về mặt phương pháp luận của bản phát hành.

Điều này cũng có mặt ngược lại, và sự trung thực đòi hỏi phải nói ra điều đó. {{1}}Việc so sánh trên cùng một backbone là bài kiểm tra công bằng nhất cho ý tưởng encoder, đồng thời cũng là cách sắp xếp có khả năng tôn vinh nó nhất — Microsoft đã chọn baseline cô lập đóng góp của chính họ.{{/1}} {{2}}Các phép so sánh Phi-4 không có tính chất đó: Phi-4-Reasoning-Vision-15B và Phi-4-MM-5.6B có backbone khác nhau, công thức huấn luyện khác nhau, hậu huấn luyện khác nhau.{{/2}} "Đánh bại mô hình 15B của chúng tôi trên video" là một kết quả có thật nhưng kém chặt chẽ hơn nhiều, và đó cũng là sự so sánh với chính công trình cũ hơn của Microsoft, vốn là loại so sánh dễ giành chiến thắng nhất.

Quy mô đào tạo là một điểm khác mà bài báo đưa ra tuyên bố thực sự đáng ngạc nhiên. Mage-ViT được tiền huấn luyện từ đầu trên khoảng 560 triệu hình ảnh không nhãn và 100 triệu khung hình video không nhãn — một kho dữ liệu lớn về mặt tuyệt đối, nhưng vẫn thua xa hàng tỷ cặp hình ảnh-văn bản được tuyển chọn đằng sau các bộ mã hóa mà nó đang cạnh tranh. Phát hiện đầu tiên được nêu của bài báo là một bộ mã hóa VLM mạnh không yêu cầu dữ liệu có giám sát ở quy mô web. Nếu điều đó đứng vững trước sự xem xét độc lập, nó quan trọng hơn đáng kể so với bất kỳ hàng điểm chuẩn đơn lẻ nào.

Những con số, và chúng là số của ai

Những gì sau đây hoàn toàn do Microsoft tự báo cáo, chạy trên bộ đánh giá của riêng Microsoft, so với các đường cơ sở do Microsoft lựa chọn. Không có kết quả nào ở đây được bên thứ ba tái lập. Hãy đọc nó như một giả thuyết có thanh sai số chi tiết một cách bất thường, chứ không phải như một bảng xếp hạng.

• Video-MME — Mage-VL-4B 64.0 so với Qwen3-VL-4B 59.7 so với Phi-4-Reasoning-Vision-15B 55.3

• NExT-QA — 83.1 so với 79.8 so với 69.0

• LongVideoBench — 61.3 so với 57.7 so với 51.2

• VideoEval-Pro — 45.2 so với 20.7 cho Phi-4

• Timelens-QVHighlight (định vị thời gian) — 57.4 so với 34.9 so với 11.6

• Ref-DAVIS17 (theo dõi tham chiếu) — 25.83 vs 7.48 vs 2.15

• DocVQA-val — 95.14 so với 94.69 so với 92.79 (Phi-4-MM-5.6B)

• OCRBench — 81.80 so với 81.60 so với 81.70

• ChartQA — 84.88 so với 83.96 so với 83.40

• MMStar — 67.32 so với 62.04 so với 59.63

• RealWorldQA — 70.46 so với 70.85 so với 70.72, một trong những hàng mà Mage-VL thua

• MMBench-EN-dev — 84.02 so với 83.25, với Phi-4-Reasoning-Vision-15B vượt trội hơn cả hai ở mức 84.19

• CV-Bench-3D / CV-Bench-2D — 94.75 so với 92.30, và 82.13 so với 81.00

• EmbSpatial — 82.67 so với 77.50

• OVO-Bench (streaming) — 64.00 tổng thể, được mô tả là tiên tiến nhất trong số các kiến trúc streaming; tập con nhận thức thị giác thời gian thực đạt trung bình 79.84% so với 72.8% của Qwen3-VL-4B, ở 1 fps

• Mage-ViT như một bộ mã hóa độc lập — trên 86,3% ở ImageNet với ngân sách 676 token, trên 96,1% ở Food-101

Ba lần đọc bảng đó còn đáng giá hơn chính bảng đó.

Trên hình ảnh, "ngang bằng" là từ ngữ trung thực.DocVQA tăng 0,45, OCRBench tăng 0,20, ChartQA tăng 0,92, MMBench tăng 0,77 — những con số này nằm trong khoảng mà một mẫu prompt khác hoặc seed giải mã khác có thể đảo ngược thứ tự, và RealWorldQA thực sự nghiêng về Qwen3-VL-4B. Microsoft cũng nói rõ điều đó, đóng khung hiệu suất hình ảnh là ngang bằng thay vì chiến thắng, và cách đóng khung đó là chính xác. Nếu khối lượng công việc của bạn là trả lời câu hỏi dựa trên tài liệu và hình ảnh, bản phát hành này không cho bạn lý do gì để chuyển đổi.

Trong các bài toán video và định vị thời gian, chênh lệch là lớn và nhất quán. Timelens-QVHighlight gần như gấp đôi đường cơ sở; Video-MME, NExT-QA và LongVideoBench đều tăng từ 3,6 đến 4,3 điểm theo cùng một hướng với backbone được giữ cố định. Sự nhất quán giữa các benchmark kiểm tra các khía cạnh khác nhau là khuôn mẫu mà bạn mong đợi nếu sự thay đổi encoder là thực chất chứ không phải là một hiện tượng do tinh chỉnh.

Hai hàng không nên được trích dẫn mà không có ngữ cảnh. Ref-DAVIS17 với 25.83 so với 7.48 trông giống như một trận hủy diệt gấp 3.5 lần, và các số liệu chênh lệch không gian nổi bật của bài báo bao gồm +11.0 trên VSI-Bench và +53.1 trên CrossPoint. Khi một mô hình cơ sở đạt điểm gần mức sàn trong một nhiệm vụ, mức chênh lệch chủ yếu phản ánh mô hình nào được huấn luyện để hiểu định dạng nhiệm vụ — chứ không phải mô hình nào có năng lực hơn. Sự thận trọng tương tự cũng áp dụng cho các kết quả phát trực tuyến theo số liệu tuyệt đối: trên SoccerNet, các con số được báo cáo của Mage-VL là 55.54 TimVal, 83.14 ROC-AUC và F1 là 16.35. F1 16.35 là một con số đạt trình độ tiên tiến trong một đánh giá còn non trẻ, chứ không phải là một bài toán đã được giải quyết. Nhận thức phát trực tuyến chủ động vẫn còn ở giai đoạn đầu, và điểm số tuyệt đối của người dẫn đầu cho thấy điều đó.

Cánh cổng: một mô hình quyết định khi nào nên nói.

Ý tưởng kiến trúc thứ hai là ý tưởng có hàm ý sản phẩm rõ ràng nhất, và nó giải thích cho tệp 1.07 GB bí ẩn đó.

Mage-VL chia quá trình streaming thành hai tiến trình, được mô tả trong bài báo là System 1 và System 2. System 1 là một "cổng nhận thức" nhẹ, theo dõi từng cửa sổ trượt của các đặc trưng codec và ước tính xác suất rằng một điều gì đó đáng nói vừa mới hoàn tất. Dưới ngưỡng này, nó giữ im lặng và phần tốn kém của mô hình không bao giờ được chạy. Trên ngưỡng, bộ giải mã đầy đủ được gọi để tạo ra phản hồi. Cấu hình demo sử dụng cửa sổ nhân quả 30 giây ở tốc độ 1 khung hình/giây, CLI hiển thị trực tiếp ngưỡng dưới dạng `--gate_threshold`, và điểm vào streaming xử lý video từng phân đoạn (`inference_streaming.py --video_backend codec --segment_sec 8`). Chỉ có cổng nhận thức được huấn luyện ở giai đoạn cuối, trên 3,35 triệu mẫu streaming.

Có hai điều đáng chú ý ở đây. Thứ nhất, gate không phải là một đầu phân loại nhỏ gắn thêm lên trên: 1,07 GB trọng số BF16 tương đương khoảng nửa tỷ tham số — một mô hình thực thụ tự thân, được phân phối dưới dạng checkpoint riêng biệt. Thứ hai, tên tệp là streammind_gate.safetensors — cách đặt tên này gợi ý rằng thành phần này kế thừa từ các nghiên cứu nhận thức luồng (streaming-perception) trước đó thay vì được tạo mới riêng cho bài báo này, dù bản thân repo không nói rõ nguồn gốc đó.

Tại sao điều này quan trọng về mặt thương mại: với video chạy liên tục, chi phí chủ đạo không phải là độ trễ mỗi lần gọi, mà là tần suất gọi. Một camera 24/7 qua một VLM thông thường ở 1 fps đồng nghĩa với 86.400 lần truyền xuôi mỗi ngày, dù có chuyện gì xảy ra hay không. Một bộ lọc đứng yên trong 99% cảnh quay không có sự kiện gì sẽ thay đổi hình dạng của hóa đơn, chứ không chỉ kích thước của nó. Liệu bộ lọc của Microsoft có đủ chính xác để đáng tin cậy cho quyết định đó hay không chính là điều mà chưa ai ngoài phòng thí nghiệm kiểm nghiệm.

Bạn có thực sự chạy được nó hôm nay không?

Có, nếu bạn có GPU và kiên nhẫn. Rào cản là có thật và chủ yếu nằm ở đường ống video chứ không phải ở mô hình.

Bộ nhớ. Microsoft không công bố yêu cầu VRAM. Từ chỉ mục trọng số: 9.49 GB shards cộng với 1.07 GB gate là khoảng 10.6 GB tham số BF16, vì vậy card 16 GB là mức sàn thực tế cho công việc hình ảnh và 24 GB trở lên là mục tiêu hợp lý khi bạn thêm bộ đệm KV cho video dài hoặc cửa sổ streaming. Đó là phép tính từ kích thước tệp, không phải thông số kỹ thuật của nhà cung cấp — hãy đo lường trước khi cấp phát.

Mã tùy chỉnh là bắt buộc. auto_map trỏ mọi điểm vào của Transformers tới các mô-đun riêng của repo, vì vậy cần phải có trust_remote_code. Bạn đang thực thi Python của Microsoft, không chỉ đơn thuần tải các tensor. Hiện chưa có đường dẫn vLLM hay SGLang, nghĩa là không có paged attention, không có continuous batching, không có ngăn xếp phục vụ sản xuất — một khoảng trống đáng kể nếu bạn hy vọng đưa nó vào sau một endpoint.

Đường dẫn codec cần công cụ hệ thống. FFmpeg và ffprobe phải nằm trong PATH của bạn. Backend codec truyền thống phụ thuộc vào gói codec-video-prep cung cấp bước cv-preinfer; đường dẫn mạng nơ-ron cần DCVC-RT; backend khung hình thường cần Decord. Các yêu cầu cũng bao gồm flash-attn và mamba-ssm, các gói này biên dịch tiện ích mở rộng CUDA — hãy cài đặt bản dựng PyTorch phù hợp với bộ công cụ của bạn trước, hoặc dành ra một buổi chiều để biên dịch.

Những gì cấu hình cho bạn biết nhưng thẻ mô hình không cho biết. Số embedding vị trí tối đa là 262.144, vì vậy bộ giải mã kế thừa ngữ cảnh dài của Qwen3-4B. Phía thị giác hoạt động với đầu vào 448 pixel với các patch 16x16, bộ mã hóa 24 lớp với chiều ẩn 1024, gộp không gian 2x2, một token mỗi giây video và cửa sổ bốn khung hình. Ở giai đoạn ba, quá trình huấn luyện đã đạt độ dài thời gian 384 khung hình. Mức trần 262K không giống với 262K hành vi đã được kiểm chứng, và 384 khung hình là độ dài mà mô hình thực sự được huấn luyện để xử lý.

Những điểm chưa hoàn thiện đã biết. Một cuộc thảo luận mở trên repo, đăng ngày 4 tháng 8 và vẫn chưa có phản hồi, báo cáo về lỗi lệch token khi hình ảnh và video được truyền trong cùng một yêu cầu. Phần mềm mười ngày tuổi hoạt động như phần mềm mười ngày tuổi. Nếu bạn muốn dùng thử mà không gặp những điều này, Space do Microsoft vận hành trên ZeroGPU là lựa chọn không cần cài đặt.

Dòng giấy phép không đơn giản như "Apache-2.0"

Thẻ mô hình ghi là Apache-2.0. Bộ mã hóa Mage-ViT ghi là MIT. Cả hai đều gần như là giấy phép cởi mở nhất dành cho trọng số mở. Nhưng kho lưu trữ của dòng mô hình lại tuyên bố rằng "các mô hình này chỉ được phát hành cho mục đích nghiên cứu," nhấn mạnh vào quy trình đánh giá AI có trách nhiệm và sự giám sát của con người — và câu đó nằm chông chênh bên cạnh giấy phép Apache-2.0, vốn không giới hạn việc sử dụng thương mại. Cộng thêm các phụ thuộc: DCVC-RT và bộ công cụ chuẩn bị codec mang các điều khoản riêng của chúng, độc lập với điều khoản của mô hình.

Với một dự án sở thích thì điều này chỉ là tiếng ồn. Còn với bất cứ thứ gì được phát hành tới khách hàng, đây là kiểu mơ hồ cần được đưa lên ban cố vấn pháp lý trước khi đưa vào sản xuất, và cũng là dạng câu hỏi đáng để đặt ngay trên repo — nơi mà, đáng chú ý, hiện không có đại diện nào của Microsoft trả lời.

Bạn có nên xây dựng dựa trên điều này không?

Quyết định được phân chia rõ ràng dựa trên một ranh giới: vấn đề của bạn là một luồng hay một yêu cầu.

Nếu bạn đang thực hiện nhận thức luôn bật — một luồng camera, một buổi phát sóng trực tiếp, tầm nhìn của robot, một cuộc họp kéo dài một giờ — Mage-VL hướng thẳng vào bạn, và tính kinh tế của việc tự lưu trữ đứng về phía bạn. Giá API theo token tính theo khung hình, một mô hình khắc nghiệt đối với video liên tục; một mô hình 4B trên phần cứng của bạn với một cổng giữ im lặng suốt cảnh quay không có sự kiện là một đường cong chi phí hoàn toàn khác. Điểm hạn chế là bạn cũng đang đăng ký trở thành người đầu tiên bên ngoài Microsoft tìm hiểu liệu phán đoán của cổng có tốt hay không.

Nếu vấn đề của bạn có dạng yêu cầu — người dùng tải lên tài liệu, PDF, ảnh chụp màn hình, đoạn clip ngắn và mong đợi câu trả lời — thì trường hợp này yếu hơn nhiều. Trong chính những tác vụ đó, Mage-VL ngang bằng với một mô hình mà bạn vẫn phải tự lưu trữ, và các điểm cuối đa phương thức được lưu trữ chỉ cách một lệnh gọi API, không cần GPU, không cần dựng ffmpeg, và không cần trust_remote_code. Trên OrcaRouter, Gemini 3.6 Flash có giá $1,50 cho mỗi triệu token đầu vào và $7,50 cho mỗi triệu token đầu ra, đây là giá niêm yết của nhà cung cấp được chuyển thẳng — chúng tôi không tính phí chênh lệch, vì vậy khi một nhà cung cấp giảm giá, mức giảm sẽ được áp dụng ngay trong ngày hôm đó thay vì sau khi xem xét giá. Một chìa khóa có thể truy cập hơn 200 mô hình với khả năng chuyển đổi dự phòng tự động nếu một nhà cung cấp suy giảm hiệu năng, đó là lý do thực tế để giữ một điểm cuối được lưu trữ làm mặc định và dành việc tự lưu trữ cho các khối lượng công việc thực sự cần đến nó.

Để nói rõ ràng, vì sự khác biệt này quan trọng: chúng tôi không lưu trữ Mage-VL, và cũng không ai khác làm điều đó. Trang mô hình của chính Hugging Face cho biết chưa có nhà cung cấp suy luận nào triển khai nó. Ngày nay, muốn chạy nó, bạn phải tự mình chạy.

Điều gì sẽ thay đổi cách đọc này?

Bốn điều, theo thứ tự gần đúng về mức độ quan trọng của chúng.

Đánh giá độc lập là điều quan trọng nhất. Mọi con số ở trên đều chỉ là tuyên bố, và tuyên bố cần kiểm chứng nhất không phải là điểm benchmark mà là mức tăng tốc 3.5x—vốn được đo bằng cách so với phương pháp lấy mẫu khung hình đồng nhất trên NExT-QA mà không công bố chi tiết phần cứng, độ phân giải hay số khung hình. Xử lý trước bằng codec chuyển khối lượng công việc thực tế sang CPU và vào ffmpeg; một mức cải thiện theo thời gian thực được đo từ đầu đến cuối trên máy của người khác mới là phiên bản duy nhất của con số đó đáng để lên kế hoạch dựa vào.

Thứ hai, hỗ trợ serving. Một triển khai vLLM hoặc SGLang hợp nhất sẽ biến thứ này từ một checkpoint nghiên cứu thành thứ bạn có thể đặt phía sau một bộ cân bằng tải. Issue SGLang hiện đang mở và chưa ai nhận; đó là luồng thảo luận cần theo dõi.

Thứ ba, việc xuất hiện trong Azure AI Foundry, điều này sẽ cho thấy rằng Microsoft có ý định coi đây là một sản phẩm chứ không phải một bài nghiên cứu. Không có gì trong bản phát hành hiện tại cho thấy điều đó sắp xảy ra.

Thứ tư, và kỳ lạ nhất: liệu Microsoft có bao giờ lên tiếng hay không. Một báo cáo kỹ thuật với 23 tác giả, một trang dự án được duy trì, một Space demo được lưu trữ, và một mô hình tạo sinh anh em ra mắt bốn ngày trước đó không mô tả một vụ rò rỉ hay tai nạn — chúng mô tả một ấn phẩm nghiên cứu có chủ đích đã bỏ qua hoàn toàn chiếc loa phóng thanh sản phẩm. Cộng đồng vẫn lấp đầy khoảng lặng đó, với chín bản lượng tử hóa và hai bản tinh chỉnh chỉ trong vòng mười ngày.

Đối với hầu hết các nhóm, hành động đúng đắn là đọc bài báo, chứ không phải tải các trọng số. Ý tưởng codec-native chính là điểm mấu chốt, và nó có tính khả chuyển: nếu việc tái sử dụng các vector chuyển động mà bộ mã hóa đã tính toán thực sự mang lại mức giảm 75% token ở cùng độ chính xác, thì kỹ thuật đó sẽ xuất hiện trong các mô hình có bài đăng ra mắt, sự hỗ trợ của nhà cung cấp, và các điểm chuẩn được tái tạo. Nếu bạn chạy video liên tục ngay hôm nay, cách tính sẽ khác — hãy clone kho lưu trữ, chạy clip của riêng bạn qua cả hai backend, và tự đo mức tăng tốc, vì lúc này bạn sẽ là người đầu tiên.

Những câu hỏi thực sự đáng để hỏi

Mage-VL có phải chỉ là Qwen3-VL với nhãn Microsoft trên đó không?

Không, mặc dù sự nhầm lẫn này là dễ hiểu. Bộ giải mã ngôn ngữ là {{1}}Qwen3-4B-Instruct-2507{{/1}}, được sử dụng nguyên trạng — Microsoft không huấn luyện một LLM mới. Mọi thứ khác đều mới: {{2}}Mage-ViT{{/2}} được tiền huấn luyện từ đầu, phương pháp token hóa dựa trên codec không có gì tương đương trong {{3}}Qwen3-VL{{/3}}, và streaming gate là một mô hình bổ sung có nửa tỷ tham số. Tái sử dụng một backbone mở và thay thế phần front-end thị giác là một chiến lược nghiên cứu hợp lệ và ngày càng phổ biến, và ở đây chính điều đó cũng giúp cho việc so sánh trực diện trở nên dễ diễn giải. Nếu bạn có các yêu cầu tuân thủ liên quan đến nguồn gốc mô hình, hãy lưu ý rằng dòng dõi bắt nguồn từ các trọng số Qwen3 của {{4}}Alibaba{{/4}} và hãy kiểm tra cả hai giấy phép.

'3.5x faster' có nghĩa là chi phí phục vụ rẻ hơn 3.5x không?

Không đáng tin cậy. Con số này là mức tăng tốc thời gian thực trên NExT-QA so với việc lấy mẫu khung hình đều đặn, và Microsoft trình bày nó là "tối đa". Hai điều làm giảm giá trị của nó trong thực tế. Suy luận gốc codec cần một bước chuẩn bị — ffmpeg, ffprobe, và bước cv-preinfer, hoặc mã hóa lại DCVC-RT cho đường dẫn mạng nơ-ron — bước này tiêu tốn thời gian CPU mà một quy trình xử lý khung hình đơn giản không cần, và không xuất hiện trong phép đo phía GPU. Và lợi ích đến từ việc giảm token, nên nó phụ thuộc vào mức độ dư thừa của đoạn phim của bạn: camera an ninh chủ yếu tĩnh sẽ cho kết quả tốt hơn con số được trích dẫn, trong khi video biên tập cắt nhanh với hầu như mọi mảng cảnh thay đổi sẽ cho kết quả tệ hơn. Hãy tự đo trên các clip của bạn.

Tôi có cần tệp video đặc biệt để sử dụng đường dẫn codec không?

Phần lớn là không, và đây chính là điều bất ngờ thú vị. Các tệp MP4 thông thường đã được mã hóa bằng H.264 hoặc HEVC, đúng thứ mà backend codec truyền thống tiêu thụ — các vector chuyển động mà nó cần đã nằm sẵn trong tệp bạn đang có. Điều bạn cần thêm vào là công cụ: FFmpeg và ffprobe trong PATH, cùng với gói chuẩn bị codec. Backend thần kinh là ngoại lệ; DCVC-RT yêu cầu video được mã hóa bằng codec đó, vì vậy bạn sẽ phải mã hóa lại. Và backend khung hình đơn thuần vẫn có sẵn như một phương án dự phòng hoạt động giống như bất kỳ VLM nào khác, đó cũng là cách trung thực để tự mình so sánh A/B tuyên bố về codec.

Tôi có thể sử dụng nó cho mục đích thương mại không?

Giấy phép cho biết Apache-2.0, vốn cho phép sử dụng thương mại, sửa đổi và phân phối lại. Kho lưu trữ cũng cho biết các mô hình được "phát hành chỉ cho mục đích nghiên cứu". Hai tuyên bố này chỉ về hai hướng khác nhau, và khoảng trống giữa chúng vẫn chưa được bất kỳ ai tại Microsoft làm rõ — điều này, với một bản phát hành không có thông báo, không có danh mục sản phẩm, và không có sự hiện diện của nhà cung cấp trong các cuộc thảo luận của kho lưu trữ, cũng không có gì đáng ngạc nhiên. Nếu tiền bạc phụ thuộc vào câu trả lời, hãy nhờ luật sư đọc cả hai tài liệu và giấy phép của các thành phần phụ thuộc thay vì chỉ tin vào huy hiệu giấy phép.