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 不是将视频解码为均匀间隔的帧，并将密集的 patch 网格送入 Web 预训练的编码器，而是直接读取压缩的比特流本身，使用一个从零训练的编码器 Mage-ViT，只保留编解码器花费了比特的 patch。微软报告称，这使视觉 token 减少 75% 以上，在静态图像上与 Qwen3-VL-4B 相当，在视频上超越微软自己的 15B Phi-4-Reasoning-Vision，同时实现了高达 3.5 倍的挂钟时间加速。

最后那句话需要保持距离来看待。本文中的每一项性能数据都可追溯到微软自己的论文、模型卡或项目页面。权重发布十天之后，没有任何独立方复现其中任何一项，第三方排行榜上也没有这个模型，而且——正如 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: An Efficient Codec-Native Streaming Multimodal Foundation Model.”

• 可运行的代码，而不仅仅是权重。该仓库提供了 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 许可证发布。

• 无需安装即可使用的可运行演示。微软在 ZeroGPU 上将 microsoft/mage-vl-demo 作为 Hugging Face Space 运行，并且已有两个社区 Space 在使用该模型。

• 早期社区反响热烈，形成速度快于厂商自身的宣传。上个月记录到 268 个赞、435,784 次下载，模型树中有九个社区量化版本和两个微调版本。下载计数器包含自动拉取和镜像拉取，因此应将原始数字视为关注度的信号，而非实际部署的信号。

• 一个姊妹模型。Mage-Flow 是一个文本到图像及指令编辑模型，采用相同的固定 4B 预算构建，于 7 月 22 日提前四天发布。GitHub 仓库将 Mage 描述为“一个轻量级、对研究友好的多模态模型家族”，这几乎是迄今为止最接近定位声明的公开表述。

与之相对，那些不存在的东西同样能说明问题。没有微软的博客文章或新闻稿。在 Azure AI Foundry 中也没有相关条目，这意味着没有企业支持途径、没有 SLA、没有托管端点。没有推理服务提供商提供它。没有 vLLM 或 SGLang 支持：7 月 28 日有人提交了社区请求，希望将 Mage-VL 添加到 SGLang，编号为 issue #32646；截至本文撰写时，该请求仍然开放，没有关联的拉取请求，也没有维护者回应。并且没有任何形式的独立评估——该模型没有出现在中立的排行榜上，像“在视频上击败 15B 模型”这样的说法通常会在这些排行榜上得到验证。

核心思想：读取编解码器，而非读取帧。

几乎所有具备视频处理能力的VLM在生产环境中都会做同样的事：把视频解码成RGB帧，然后均匀采样——每秒取一帧，或者在整个片段中取32帧，或者按算力预算来决定——再将每个采样帧作为密集的patch网格送入视觉Transformer。每个采样帧的每个patch都会变成token。一堵静态的背景墙，其消耗的token数量与在它前面走动的人完全一样，并且在下一帧中还会再消耗一遍，再下一帧亦然。

这是大量的冗余计算，而现代视频编解码器早在几十年前就解决了这个根本问题。H.264和HEVC并不会存储每一帧；它们会完整存储偶尔出现的锚定（I）帧，然后用运动矢量加残差来描述帧与帧之间的画面——“这个块移动到了这里，这里是发生的变化。”视频中真正有趣的部分，几乎可以说是编码器花费比特数最多的部分。

Mage-ViT 直接利用了这一点。它以 16×16 的块粒度运行，保留锚定帧的每个块，对于预测帧，仅保留被编解码器自身的运动向量和残差能量标记为显著的块——即携带真实信息、运动或场景变化的区域——同时丢弃低冗余和完全冗余的块。微软称其视觉令牌减少超过 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 有所提升时，差异可归因于编码器和编解码器原生的分词方式，而非更大或训练更好的语言模型。这实际上是以产品对比为表象的受控消融实验，也是该发布中最强的方法论特点。

这也是一把双刃剑，诚实的做法是必须承认这一点。相同主干的对比是对编码器思路最公平的检验，同时也是最可能让结果显得好看的框架——微软选择的基线恰恰隔离了自身的贡献。Phi-4 的对比不具备这一特性：Phi-4-Reasoning-Vision-15B 和 Phi-4-MM-5.6B 使用不同的主干、不同的训练方案、不同的后训练流程。“在视频上击败了我们的 15B 模型”是一个真实的结果，但宽松得多，而且这也是与微软自身旧作的对比，是最容易取胜的那种对比。

训练规模是{{1}}论文提出一个真正令人惊讶的论断{{/1}}的另一个方面。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 vs 57.7 vs 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 对比 81.60 对比 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 对比 92.30，以及 82.13 对比 81.00

• EmbSpatial — 82.67 vs 77.50

• OVO-Bench (streaming) — 总体得分 64.00，据称是流式架构中最先进的；实时视觉感知子集平均得分 79.84%，而 Qwen3-VL-4B 为 72.8%，在 1 fps 下

• Mage-ViT 作为独立编码器 — 在 676 token 预算下，ImageNet 上超过 86.3%，Food-101 上超过 96.1%

那张表格的三次解读比表格本身更有价值。

在图像方面，“持平”（parity）是诚实的说法。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 是一个轻量级的"认知门"，负责观察每个滚动的 codec 特征窗口，并估计"刚刚结束的、值得说出来的事情"的概率。低于阈值时，它保持沉默，模型中昂贵的部分不会运行；高于阈值时，完整的解码器会被调用以生成响应。演示配置使用 1 fps 下的 30 秒因果窗口，CLI 直接将阈值暴露为 --gate_threshold，流式入口逐段处理视频（inference_streaming.py --video_backend codec --segment_sec 8）。最后阶段仅对门控进行训练，使用 3.35M 个流式样本。

关于这一点，有两点值得注意。首先，这个门控并不是一个简单附加在顶部的分类头：1.07 GB 的 BF16 权重大约相当于五亿参数，它本身就是一个真正的模型，以独立的 checkpoint 形式发布。其次，文件名是 streammind_gate.safetensors——这个命名表明该组件源自早期的流式感知工作，而不是为这篇论文专门发明的，尽管仓库本身并未明确说明这一渊源。

这在商业上为何重要：对于全天候视频，主要成本不是单次调用延迟，而是调用频率。一个摄像头以 1 fps 全天候通过传统 VLM 运行，意味着每天都要进行 86,400 次前向传播，无论是否发生了任何事情。一个在 99% 无事件发生的画面中保持静默的门控，改变的不仅是账单的大小，更是账单的结构。微软的门控是否足够准确、足以让人放心地把这个决定交给它，恰恰是实验室之外没有人测试过的事情。

你今天真的能运行它吗？

是的，如果你有GPU和耐心。阻力确实存在，且主要来自视频处理流程，而非模型本身。

内存。 微软未公布显存（VRAM）要求。根据权重索引：9.49 GB 的分片加上 1.07 GB 的门控，总计约 10.6 GB 的 BF16 参数，因此对于图像处理而言，16 GB 显卡是现实的下限；而一旦为长视频或流式窗口添加 KV 缓存，24 GB 或以上才是合理的目标。这是根据文件大小推算出来的算术结果，并非厂商规格——请先测量，再行配置。

自定义代码是必需的。auto_map 将每个 Transformers 入口点指向仓库自身的模块，因此必须设置 trust_remote_code。你执行的是 Microsoft 的 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像素输入运行，采用16x16补丁、24层1024隐藏维编码器、2x2空间合并、每秒视频一个token以及四帧窗口。训练在第三阶段达到了384帧的时间长度。262K的上限并不等同于262K的已验证行为，384帧才是模型实际被训练处理的长度。

已知的粗糙之处。repo 上有一个公开讨论，于8月4日发起，至今仍未得到回复，报告了在同一请求中同时传入图像和视频时出现的 token 错位问题。上线十天的软件自然会有上线十天的表现。如果你想不受这些问题影响地体验一下，微软在 ZeroGPU 上运行的 Space 就是零安装的选择。

许可证行不像"Apache-2.0"那么简单

模型卡说明采用Apache-2.0许可。Mage-ViT编码器则采用MIT许可。两者在开放权重许可中都属于相当宽松的。但模型系列仓库中声明“这些模型仅用于研究目的”，并强调负责任AI审查和人工监督——这句话与Apache-2.0授权放在一起显得不太协调，因为Apache-2.0并不限制商业使用。再加上依赖项：DCVC-RT和编解码器准备工具各自带有自己的条款，独立于模型本身的许可。

对于业余项目来说，这只是噪音。对于任何要交付给客户的产品而言，这种模糊性在进入生产之前应该交由法律顾问处理，同时也是值得在代码仓库上提出的问题——值得注意的是，目前那里并没有微软的代表在回答。

你应该在此基础上继续构建吗？

该决定可以清楚地沿一条线划分：你的问题是流还是请求。

如果你在做持续不断的感知处理——摄像头视频流、实况转播、机器人的视野、持续一个小时的会议——Mage-VL 正是为你而设，而且自托管的经济性对你有利。按 token 计费的 API 定价随帧数增长，这对连续视频来说是一种残酷的模式；在自己的硬件上运行一个 4B 模型，配上一个在平淡无奇的画面中保持沉默的门控，这完全是另一条成本曲线。关键在于，你还得成为微软之外第一个验证这个门控判断力是否靠谱的人。

如果你的问题呈“请求”形态——用户上传文档、PDF、截图或短视频，并期待得到回答——那么这种理由就弱得多。恰恰在这些任务上，Mage-VL 与一个你仍需自行托管的模型旗鼓相当，而托管的多模态端点只需一次API调用即可使用，无需GPU、无需编译ffmpeg、也无需trust_remote_code。在OrcaRouter上，Gemini 3.5 Flash每百万输入token收费1.50美元，每百万输出token收费7.50美元，这是供应商的标价直接透传——我们不赚取任何加价，所以当供应商降价时，降价当天就在我们这边生效，而不用等到定价审查之后。一把密钥即可访问200多个模型，当某个供应商性能下降时自动故障转移，这正是将托管端点作为默认选项、把自托管保留给确实需要它的工作负载的务实理由。

说清楚一点，因为这个区别很重要：我们不托管 Mage-VL，也没有其他人托管它。Hugging Face 自己的模型页面显示，没有推理提供商部署过它。如今，要运行它就只能自己运行。

什么会改变这个读数

四件事，按照它们重要程度的大致顺序排列。

独立评估才是关键。上面每一个数字都只是声称，而最需要验证的不是基准分数，而是3.5倍的加速——这个数字是在NExT-QA上对比均匀帧采样测得的，且未公开硬件、分辨率或帧数详情。编解码器预处理把实际工作转移到了CPU和ffmpeg中；只有在别人的设备上进行端到端测量所得的挂钟时间优势，才是这个数字唯一值得规划参考的版本。

其次，服务支持。合并的 vLLM 或 SGLang 实现将把它从研究检查点变成可以放在负载均衡器后面的东西。SGLang 的 issue 是开放的且无人认领；这是值得关注的帖子。

第三，在Azure AI Foundry中上架，这将表明微软打算将其作为产品而非论文。当前版本中没有任何迹象表明这一点即将实现。

第四点，也是最奇怪的一点：微软是否会公开发声。一份由23位作者署名的技术报告、一个持续维护的项目页面、一个托管的演示 Space，以及四天前发布的一个姊妹生成模型——这些描述的不是泄露或意外，而是一次深思熟虑的研究发布，只是完全跳过了产品宣传的扩音器。即便如此，社区还是填补了这片沉默，十天之内便出现了九个量化版本和两个微调版本。

对大多数团队而言，正确的做法是阅读论文，而不是下载权重。编解码器原生的理念才是关键收获，而且它具备可移植性：如果复用编码器已计算出的运动矢量，真能在精度持平的情况下让token数量减少75%，那么这项技术就会出现在那些有发布公告、供应商支持和可复现基准的模型中。如果你今天要处理连续视频，这笔账就得另算了——克隆仓库，用你自己的片段在两个后端上各跑一遍，亲自测量加速效果，因为眼下你将是最先这样做的人。

真正值得问的问题

Mage-VL 只是贴了微软标签的 Qwen3-VL 吗？

不，不过这种混淆可以理解。语言解码器是 Qwen3-4B-Instruct-2507，按原样使用——微软没有训练新的 LLM。其他一切都是新的：Mage-ViT 是从零开始预训练的，编解码器原生的分词方式在 Qwen3-VL 中没有对应物，流式门控则是一个额外的五亿参数模型。复用开放骨干并更换视觉前端是一种合理且越来越常见的研究策略，在这里也正是这一点让正面对比具有可解释性。如果你有关于模型来源的合规要求，请注意其血统源自阿里巴巴的 Qwen3 权重，并检查两份许可证。

“快3.5倍”是否意味着服务成本便宜3.5倍？

并不可靠。这个数字是在 NExT-QA 上相对于均匀帧采样的墙钟时间加速比，微软将其表述为“最高可达”。在实践中，有两个因素会削弱它。编解码器原生推理需要一个准备过程——ffmpeg、ffprobe 和 cv-preinfer 步骤，或对神经路径进行 DCVC-RT 重编码——这会消耗 CPU 时间，而朴素的帧管线不会消耗这部分时间，并且这部分时间也不会出现在 GPU 侧的测量中。而收益来自 token 数量的减少，因此它随素材的冗余程度而变化：画面基本静止的安防摄像头应该比引用数字效果更好，而快剪编辑的视频中几乎每个图像块都在变化，效果则应该更差。在你自己的片段上测量一下。

我需要特殊的视频文件才能使用编解码器路径吗？

大多数情况下不需要，而这正是令人惊喜之处。普通的 MP4 文件已经是 H.264 或 HEVC，这正是传统编解码器后端所消费的格式——它需要的运动矢量就存在于你已有的文件中。你需要补充的是工具链：将 FFmpeg 和 ffprobe 加入 PATH，再加上编解码器准备包。神经后端是个例外；DCVC-RT 期望的是用该编解码器编码的视频，因此你需要重新编码。而纯帧后端仍可作为一个回退方案，其行为与任何其他 VLM 相同，这也是让你亲自 A/B 验证编解码器说法的最诚实方式。

我可以商业使用它吗？

许可证声明为 Apache-2.0，允许商业使用、修改和再分发。但仓库还声明这些模型“仅用于研究目的发布”。这两种说法指向不同的方向，而微软方面没有人澄清这一差距——考虑到这次发布没有公告、没有产品列表，也没有供应商参与仓库讨论，这并不令人意外。如果答案关系到资金问题，请聘请律师阅读这两份文件以及依赖项许可证，而不要仅凭许可证徽章就做出判断。