Microsoft Mage-VL：一款編解碼器原生的 4B 視頻模型，未經公告悄然推出

沒有任何微軟部落格文章是關於Mage-VL的。沒有 Azure 新聞室條目，沒有 Foundry 目錄列表，沒有發布討論串，在微軟通常發布模型的產品頻道上也一無所有。取而代之的是一個 Hugging Face 儲存庫——microsoft/Mage-VL，六次提交，10.8 GB 的權重，Apache-2.0——一個包含推論腳本的 GitHub 資料夾、一個由自稱為 Microsoft Mage Team 的團隊維護的專案頁面，以及一份有 23 位作者的 arXiv 報告。綜合這些材料來看，它們描述的是一個 4B 規模的視覺語言模型，其核心概念確實不同尋常：Mage-VL 不是將影片解碼為均勻間隔的影格，然後將密集的圖塊網格送入以網路資料預訓練的編碼器，而是直接讀取壓縮位元流本身，使用一個從零開始的編碼器 Mage-ViT，只保留編解碼器花費位元處理的圖塊。微軟報告指出，這讓視覺 token 減少超過 75%，並帶來最高 3.5 倍的實際時間加速，同時在靜態影像上與 Qwen3-VL-4B 持平，並在影片上勝過微軟自家的 15B Phi-4-Reasoning-Vision。

最後那句話正是需要保持距離的部分。本文中的每一項效能數字，都追溯至微軟自己的論文、模型卡或專案頁面。權重發布十天後，沒有任何獨立方重現過其中任何結果，也沒有第三方排行榜收錄該模型，而且——正如 Hugging Face 頁面所明確指出的——它「未由任何推論提供者部署」，因此甚至連一個可供人隨意評測的託管端點都不存在。接下來的內容將區分儲存庫證明了什麼、以及微軟只是宣稱了什麼，因為在一場沒有公告的發布中，這兩者是截然不同的類別。

真正存在的，是十天之後的事。

此版本可驗證的範圍很小，且值得精確列舉。

• 權重，日期為2026年7月26日。兩個safetensors分片，分別為4.97 GB與4.52 GB，另附加一個獨立的1.07 GB檔案，名為streammind_gate.safetensors。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——約 175 KB 的自訂 Python 程式碼。config.json 中的 auto_map 將六個 Transformers 類別路由到這些檔案中，這就是為什麼該儲存庫帶有 custom_code 標籤。

• 兩種授權，而非一種。 Mage-VL 採用 Apache-2.0 授權；獨立的 Mage-ViT 編碼器則另外以 MIT 授權發布。

• 一個免安裝即可運作的示範。 微軟以 microsoft/mage-vl-demo 作為 Hugging Face Space 在 ZeroGPU 上運行，且有兩個社群 Space 已在使用該模型。

• 早期社群動能，形成速度比廠商自身的對外溝通更快。 上個月記錄到 268 個讚、435,784 次下載，模型樹中有九個社群量化版本和兩個微調版本。下載計數器包含自動化與鏡像拉取，因此應將原始數字視為關注度訊號，而非實際部署情況。

• 一個姊妹模型。Mage-Flow 是一款以相同固定 4B 參數預算打造的文字轉圖像與指令編輯模型，於 7 月 22 日提早四天問世。GitHub 儲存庫將 Mage 描述為「一系列輕量、便於研究的多模態模型」，這可說是迄今為止最接近定位聲明的公開表述。

與之相對，那些不存在的事項清單同樣具有參考價值。沒有 Microsoft 的部落格文章或新聞稿。Azure AI Foundry 中也沒有相關條目，這意味著沒有企業支援途徑、沒有 SLA、沒有受管端點。沒有任何推論供應商提供此模型。沒有 vLLM 或 SGLang 支援：一項要求將 Mage-VL 加入 SGLang 的社群請求於 7 月 28 日以 issue #32646 提交，截至本文撰寫之時仍處於開放狀態，沒有關聯的 pull request，也沒有維護者的回應。而且沒有任何形式的獨立評測——該模型缺席於中立的排行榜，而像「在影片任務上擊敗 15B 模型」這類宣稱，通常會在這些排行榜上接受檢驗。

核心想法：讀取編解碼器，而非幀。

幾乎所有在生產環境中具備影片處理能力的 VLM 都會做同樣的事。它將影片解碼為 RGB 幀，均勻地取樣——每秒一幀，或整個片段取 32 幀，或視預算而定——然後將每個取樣幀以密集的區塊網格形式送入視覺變換器。每個取樣幀的每個區塊都會變成 token。一面靜止的背景牆所花費的 token 數量，與在它前面走動的人完全相同，而且在下一幀、再下一幀中，這些 token 又會被再花一次。

那是極其大量的冗餘運算，而現代視訊編解碼器早在數十年前就已解決了背後的問題。H.264 與 HEVC 並非儲存每一幀畫面；它們會完整儲存偶爾出現的錨定（I）幀，然後以運動向量加上殘差來描述其間的各幀——「這個區塊移到這裡，而這些是改變的部分。」一部影片中值得關注的部分，幾乎可以說是編碼器花費位元的地方。

Mage-ViT 直接利用了這項特性。它以 16x16 patch 的粒度運作，保留錨定幀的每個 patch；而對於預測幀，只保留由編解碼器自身的運動向量和殘餘能量標記為顯著的 patch——也就是承載真實資訊、運動或場景變化的區域——同時丟棄低冗餘及完全冗餘的 patch。Microsoft 估計此舉可將視覺 token 減少超過 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 時，其差異可歸因於編碼器與 codec 原生的 tokenization，而非更大或訓練更好的語言模型。這是一場包裝成產品比較的受控消融實驗，也是這次發布在方法論上最突出的特點。

這也有其反面作用，誠實而言必須承認這點。相同骨幹的比較是對編碼器構想最公平的檢驗，同時也是最可能對其有利的框架——微軟選擇了能隔離自身貢獻的基準線。Phi-4 的比較則不具備這種特性：Phi-4-Reasoning-Vision-15B 和 Phi-4-MM-5.6B 是不同骨幹、不同訓練配方、不同後期訓練的模型。「在影片上擊敗我們的 15B 模型」是真實的成果，但這是寬鬆得多的比較，而且也是與微軟自身舊作的比較，這是最容易取勝的一種。

訓練規模是論文中另一個提出驚人主張的地方。Mage-ViT 從零開始預訓練，使用了約5.6億張未標註圖片和1億個未標註影片幀——就絕對數量而言，這是一個龐大的語料庫，但遠不及與之競爭的編碼器背後數十億組精選圖文配對數據。論文首要陳述的發現是，一個強大的VLM編碼器並不需要網絡規模的監督數據。若這項主張能經得起獨立審查，其重要性將遠超過任何單一基準指標的成績。

這些數字，以及這些數字屬於誰

接下來的內容全程由微軟自行報告，採用微軟自家的評測框架，並以微軟選定的基準線進行比較。這裡沒有任何內容由第三方重現。請將其視為一個帶有異常明確誤差區間的假說，而非記分板。

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

• NExT-QA — 83.1 vs 79.8 vs 69.0

• LongVideoBench — 61.3 對比 57.7 對比 51.2

• VideoEval-Pro — 45.2 對比 Phi-4 的 20.7

• Timelens-QVHighlight（時間定位） — 57.4 vs 34.9 vs 11.6

• Ref-DAVIS17（參考追蹤） — 25.83 vs 7.48 vs 2.15

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

• OCRBench — 81.80 vs 81.60 vs 81.70

• ChartQA — 84.88 vs 83.96 vs 83.40

• MMStar：67.32 對比 62.04 對比 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 對比 92.30，以及 82.13 對比 81.00

• EmbSpatial — 82.67 對比 77.50

• OVO-Bench (streaming) — 整體 64.00，被描述為串流架構中的最先進技術；在 1 fps 下，即時視覺感知子集平均為 79.84%，相較於 Qwen3-VL-4B 的 72.8%

• Mage-ViT 作為獨立編碼器 — 在 676 個 token 的預算下，於 ImageNet 上超過 86.3%，於 Food-101 上超過 96.1%

那張表格的三次閱讀比表格本身更有價值。

在圖像方面，「持平」才是最誠實的說法。DocVQA 的差距為 0.45、OCRBench 為 0.20、ChartQA 為 0.92、MMBench 為 0.77——這些差距都落在只要更換提示詞模板或解碼種子就可能逆轉排序的範圍內，而 RealWorldQA 實際上是由 Qwen3-VL-4B 勝出。微軟也如此表示，將圖像表現定位為持平而非勝出，這樣的定位是正確的。如果你的工作負載是文件與圖像問答，這次發布沒有給你任何轉換的理由。

在影片與時間定位方面，差距既大且一致。 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 報告的數字是 55.54 TimVal、83.14 ROC-AUC 和 16.35 的 F1。16.35 的 F1 在一個新興的評測中是頂尖數字，而不是一個已解決的問題。主動式串流感知仍處於早期階段，領先者的絕對分數說明了這一點。

閘門：一個決定何時說話的模型

第二個架構理念是產品影響最為明確的一個，它也解釋了那個神祕的 1.07 GB 檔案。

Mage-VL 將串流處理拆分為兩個流程，在論文中分別稱為 System 1 與 System 2。System 1 是一個輕量級的「認知閘門」（cognition gate），它逐一監看每個滑動視窗中的 codec 特徵，並估計「剛才是否剛結束了某件值得談論的事情」的機率。低於閾值時，閘門保持靜默，模型中成本高昂的部分完全不會被執行；超過閾值時，則會呼叫完整的解碼器來產生回應。示範設定採用每秒 1 幀（1 fps）的 30 秒因果視窗，CLI 直接以 --gate_threshold 暴露閾值參數，串流入口則逐段處理影片（inference_streaming.py --video_backend codec --segment_sec 8）。在最後階段，僅訓練閘門本身，使用的資料集包含 335 萬筆串流樣本。

關於這點，有兩件事值得注意。首先，這個 gate 並非釘在頂端的小型分類頭：1.07 GB 的 BF16 權重大約是五億個參數，本身就算得上一個真正的模型，而且是作為獨立的 checkpoint 發布。其次，檔案名稱是 streammind_gate.safetensors——這個命名暗示該元件源自更早期的 streaming-perception 研究，而非為這篇論文新發明；不過 repo 本身並未明確交代這層淵源。

{{1}}Why it matters commercially: for always-on video, the dominant cost is not per-call latency, it is call frequency. A camera feed running 24/7 through a conventional VLM at 1 fps means 86,400 forward passes a day whether or not anything happened. A gate that stays quiet during the 99% of footage where nothing happens changes the shape of that bill, not just its size. Whether Microsoft's gate is accurate enough to trust with that decision is exactly the thing nobody outside the lab has tested.{{/1}}

你今天真的能執行它嗎？

是的，如果你有GPU和耐心的話。摩擦是真實存在的，而且主要存在於影片處理流程，而非模型本身。

記憶體。 Microsoft 並未公佈 VRAM 需求。根據權重索引：9.49 GB 的分片加上 1.07 GB 的閘極約為 10.6 GB 的 BF16 參數，因此對於影像處理而言，16 GB 的顯示卡是實際可行的最低配置；而一旦加入長影片或串流視窗的 KV 快取，24 GB 或以上才是合理的目標。這是根據檔案大小推算出的算術結果，並非廠商規格——請在配置前先行測量。

自訂程式碼是強制性的。 auto_map 將所有 Transformers 的進入點指向該儲存庫自身的模組，因此需要 trust_remote_code。你執行的是微軟的 Python，而不只是載入張量。目前還沒有 vLLM 或 SGLang 的路徑，這意味著沒有分頁注意力、沒有連續批次處理、沒有生產環境的服務堆疊——如果你希望將它放到端點後面，這會是一個重大的缺口。

編解碼器路徑需要系統工具。 FFmpeg 和 ffprobe 必須位於你的 PATH 中。傳統編解碼器後端依賴於提供 cv-preinfer 步驟的 codec-video-prep 套件；神經網路路徑需要 DCVC-RT；純影格後端需要 Decord。這些需求還會引入 flash-attn 和 mamba-ssm，它們會編譯 CUDA 擴充功能——請先安裝與你的工具包相符的 PyTorch 版本，否則請預留一個下午來進行編譯。

設定檔告訴你的，是模型卡沒有告訴你的事。最大位置嵌入為 262,144，因此解碼器繼承了 Qwen3-4B 的長上下文能力。視覺端以 448 像素輸入、16×16 patch 運行，採用 24 層、1024 隱藏維度的編碼器，2×2 空間合併，每秒影片一個 token，以及四幀視窗。訓練在第三階段達到了 384 幀的時間長度。262K 的上限並不等於 262K 的驗證行為；384 幀才是模型實際被教導處理的長度。

已知的未盡完善之處。 在儲存庫上有一則於8月4日提出、至今仍未獲回覆的公開討論，回報了在同一請求中同時傳入圖片與影片時，會出現 token 錯位的情況。第十天的軟體，表現得就像第十天的軟體。若想一探究竟又不想遇到這些問題，Microsoft 在 ZeroGPU 上營運的 Space 就是零安裝的選擇。

授權行不像「Apache-2.0」那麼簡單。

模型卡上寫的是 Apache-2.0。Mage-ViT 編碼器則採用 MIT。兩者都是開源權重中相當寬鬆的授權。但{{1}}家族儲存庫{{/1}}中聲明「{{2}}這些模型僅供研究用途發布{{/2}}」，並強調負責任 AI 審查與人工監督——這句話與{{3}}Apache-2.0 授權{{/3}}並存時顯得格格不入，因為 Apache-2.0 並不限制商業使用。再加上相依套件：{{4}}DCVC-RT{{/4}} 與編解碼器準備工具各自帶有獨立於模型本身的條款。

對業餘專案來說，這只是雜訊；對任何要交付給客戶的產品而言，這種模糊性理應在進入生產環境前交由法務顧問定奪，也是值得在 repo 上提出的問題——值得注意的是，目前那裡沒有微軟代表在回答。

你應該在此基礎上建置嗎？

這個決定沿著一條明確的界線分開：你的問題是串流還是請求。

如果你正在做常時感知——攝影機畫面、直播、機器人的視野、長達一小時的會議——Mage-VL 正是衝著你來的，而自行託管的經濟效益站在你這邊。按 token 計費的 API 價格會隨著幀數攀升，這對連續影片來說是種殘酷的計費模式；在你自己的硬體上跑一個 4B 模型，加上一道在平淡無奇的畫面中保持沉默的閘門，這是一條從根本上截然不同的成本曲線。但代價是，你也等於自願成為微軟以外第一個發現這道閘門的判斷到底準不準的人。

如果您的問題是請求型態——使用者上傳文件、PDF、截圖或短片並期望獲得答案——那麼自架的理由就薄弱得多。正是在這類任務上，Mage-VL 與您仍需自行託管的模型表現持平，而託管的多模態端點只需一次 API 呼叫即可使用，無需 GPU、無需編譯 ffmpeg、也無需 trust_remote_code。在 OrcaRouter 上，Gemini 3.6 Flash的價格是每百萬輸入代幣 1.50 美元、每百萬輸出代幣 7.50 美元，這是供應商的定價直接轉嫁——我們不收取任何加成，因此當供應商降價時，降價在當天就在我們這邊生效，而不是在定價審查之後。一把金鑰即可存取 200 多個模型，若供應商效能下降會自動故障轉移，這正是將託管端點設為預設、並把自架保留給真正需要的工作負載的實際原因。

明確地說，因為這個區別很重要：我們不託管 Mage-VL，其他任何人也都沒有託管。Hugging Face 自家的模型頁面指出，沒有推理服務提供商部署過它。如今，要運行它就意味著必須自己運行。

什麼會改變這個讀數？

四件事，大致按影響程度排序。

{{1}}獨立評估才是重頭戲。{{/1}}{{2}}以上每個數字都是一種宣稱，而最需要檢驗的宣稱不是基準測試分數，而是3.5倍的加速。{{/2}}{{3}}該加速是在NExT-QA上以均勻幀採樣為基準測得的，但並未公布硬體、解析度或幀數等細節。{{/3}}{{4}}Codec預處理將實際工作轉移到CPU和ffmpeg上；{{/4}}{{5}}只有在別人的設備上進行端到端量測所得的實際耗時優勢，才是那個數字唯一值得作為規劃依據的版本。{{/5}}

其次，服務支援。一個合併進 vLLM 或 SGLang 的實作會把這個從研究檢查點變成你可以放在負載平衡器後面的東西。SGLang 的 issue 是開放的且無人認領；那是值得關注的討論串。

第三，在 Azure AI Foundry 中上架，這將表明微軟打算將其視為產品而非論文。目前發布的內容中，沒有任何跡象顯示此事即將發生。

第四點，也是最奇怪的：微軟是否會說些什麼。一份有23位作者的技術報告、一個持續維護的專案頁面、一個代管的展示用Space，以及四天前發布的姊妹生成模型——這些都不像是洩漏或意外，而是刻意發表的研究成果，完全跳過了產品發布的宣傳管道。社群依然填補了這份沉默，在十天內就完成了九個量化版本和兩個微調。

對大多數團隊來說，正確的做法是閱讀論文，而不是下載權重。編解碼器原生（codec-native）的概念才是重點，而且它具有可移植性：如果重用編碼器已經算好的運動向量，真的能在同等準確度下換來 75% 的 token 減少，那麼這項技術就會出現在帶有發布文章、供應商支援和可重現基準的模型中。如果你今天要跑連續影片，得失權衡就不同了——把 repo 複製下來，用自己的片段在兩個後端上各跑一遍，親自量測加速效果，因為目前你會是第一個這麼做的人。

真正值得提出的問題

Mage-VL 是否只是貼上 Microsoft 標籤的 Qwen3-VL？

不，儘管這種混淆可以理解。語言解碼器是 Qwen3-4B-Instruct-2507，按原樣使用——微軟並沒有訓練新的 LLM。其他一切都是全新的：Mage-ViT 是從頭預訓練的，codec 原生的 tokenization 在 Qwen3-VL 中毫無對應之物，而串流門控是一個額外的五億參數模型。重用開放式骨幹並更換視覺前端，是合理且日益常見的研究策略，在此也正是這點讓直接對比具有可解釋性。如果你對模型溯源有合規要求，請注意其血統源於阿里巴巴的 Qwen3 權重，並檢查兩者的授權許可。

「快3.5倍」是否意味著服務成本便宜3.5倍？

並不可靠。該數字是在 NExT-QA 上相對於均勻幀取樣的實際耗時加速比，微軟將其表述為「最高可達」。在實務上，有兩件事會削弱其效果。Codec 原生推論需要一個準備階段——ffmpeg、ffprobe 和 cv-preinfer 步驟，或針對神經路徑的 DCVC-RT 重新編碼——這個階段會消耗樸素幀管線所不會消耗的 CPU 時間，而這部分時間並不會出現在 GPU 端的測量中。此外，這項增益來自於 token 減少，因此其效果會隨您影片素材的冗餘程度而呈比例變化：大部分靜態的監視攝影機應該會比所引用的數字表現得更好，而幾乎每個 patch 都在變化的快速剪輯影片則應該會表現得更差。請用您自己的影片片段進行測量。

使用編解碼器路徑是否需要特殊的視頻檔案？

大致上不需要，而這就是令人驚喜之處。普通的 MP4 檔案本來就已採用 H.264 或 HEVC，這正是傳統編解碼器後端所消費的格式——它所需的運動向量就存在於你已有的檔案中。你需要額外添增的是工具鏈：將 FFmpeg 和 ffprobe 放入 PATH，再加上編解碼器準備套件。神經網路後端是例外；DCVC-RT 預期影片是以該編解碼器編碼的，因此你會需要重新編碼。而純幀（plain frames）後端仍可作為備援（fallback）使用，其行為與任何其他 VLM 相同，這也是最誠實的方式，讓你自己對編解碼器的宣稱進行 A/B 測試。

我可以在商業上使用它嗎？

授權條款標示為 Apache-2.0，允許商業使用、修改與再散佈。但該 repository 同時也聲明這些模型「僅供研究目的釋出」。這兩項陳述指向不同方向，而微軟方面無人釐清這之間的落差——考量到這次釋出既無公告、無產品列表，repository 討論中也沒有廠商代表參與，這樣的狀況並不令人意外。若答案牽涉金錢利益，請讓律師閱讀這兩份文件及相依授權條款，而非僅信賴授權徽章。