InternLumina-U2 vs Microsoft Mage-VL：两家低调实验室押注视觉Token应承载更多

Microsoft Mage-VL 与 InternLumina-U2 的发布方式，正是研究实验室在拿不准某个成果是否还算产品时的典型方式：悄无声息。2026 年 7 月 25 日，微软在 Hugging Face 上发布了 Mage-VL 的权重和代码，未发任何公告；2026 年 9 月 1 日，上海人工智能实验室的 InternLM 组织在 GitHub 上发布了 InternLumina-U2 的推理代码，同样未发任何公告。两者相隔五周，全球最大的两家实验室相继放出模型，它们共享一个不动声色的信念——我们将视觉转化为 token 的方式才是瓶颈——然后把模型留给社区去发现。其中一款你今天就能下载并运行，只是跑起来颇为勉强；另一款你根本无法运行，因为它的权重尚不存在。这就是对两款模型的如实梳理，也解释了为什么“皆为厂商自报、皆未经验证”这句话，放在它们身上含义并不相同。

五周，两个关于表征效率的押注

这条主线真实存在，而非修辞性的表述。Mage-VL是一种编解码器原生的视频模型：它并不将视频流解码为均匀采样的帧，再把密集的补丁网格送入一个冻结的、基于网页数据预训练的视觉变换器；相反，它遵循现代视频编解码器的结构，将视频流拆分为锚定帧以及介于其间的压缩运动数据，并直接摄入这种紧凑的表示形式。据报道，Microsoft获得的回报是视觉令牌数量的大幅减少，以及流式感知路径的显著提速——该公司将其描述为修复了视频语言模型中的一种莫拉维克悖论：小型实时感知任务竟与困难的离线推理消耗同样多的算力。Mage-VL是一个观察者：它高效地消费视频，并近乎实时地回答关于其所见内容的问题。

InternLumina-U2 是从另一个方向对同一瓶颈的押注。Mage-VL 通过跟随编解码器来压缩视频，而 InternLumina-U2 则通过用八个互补的离散码而非一个来描述每个位置，从而压缩所有视觉输入——它使用的分词器被实验室称为 AToken。其赌注在于：单一码本限制了单个视觉 token 所能携带的信息量，因此多码本词汇表能让一个 16B 参数的扩散模型通过同一接口完成理解与生成——读图表、回答视频问题、描述 3D 资产、从文本生成图像、按指令进行编辑——而无需独立的生成栈。Mage-VL 想要低成本地感知流；InternLumina-U2 想要用同一套权重来感知和绘制。

记分牌

两款型号的数据均来自厂商报告且未经复现，因此记分板会在每一行标注其来源。

• Shape — Mage-VL：一种紧凑的编解码器原生视觉语言模型（约 5B 参数，BF16 精度），围绕 Qwen 文本骨干构建，并针对图像和视频理解进行训练。InternLumina-U2：一种 16B 参数的 MoE，其中激活参数为 1B（16B-A1B），是一种稀疏扩散 LLM，涵盖理解、生成与编辑。

• {{1}}视觉表示{{/1}} — Mage-VL：{{2}}编解码器原生词元遵循视频编解码器结构（锚点加运动）；据报道，在流式视频上视觉词元数量减少超过75%{{/2}}。InternLumina-U2：{{3}}来自AToken分词器的完全离散八码本词元{{/3}}。

• 功能 — Mage-VL：观看图像和视频输入，输出文本回答；专为流式感知打造。InternLumina-U2：宣称支持文本、图像理解、文生图、图像编辑、视频理解和3D理解。

• 权重 — Mage-VL：自 2026 年 7 月 25 日起在 Hugging Face 上公开（microsoft/Mage-VL，Apache-2.0）。InternLumina-U2：未公开 — Hugging Face 仓库只是空壳，权重标记为“即将推出”。

• 头条数字 — Mage-VL：Video-MME 64.0、NExT-QA 83.1、OVO-Bench 64.0，均为微软报告。InternLumina-U2：ChartQA 86.52、MathVision 33.22、VideoMME 51.26、GenEval 0.81，均为实验室报告，属初步且部分数据。

• 服务现实 — Mage-VL：可下载，但没有标准的 vLLM 或 SGLang 推理路径；代码需要 trust_remote_code，目前也没有任何推理服务提供商部署它。InternLumina-U2：任何人都无法提供服务 — 权重并未公开存在，甚至已发布的推理驱动所期望的 checkpoint 文件也不在仓库中。

“可用但别扭”不等于“不可用”。

如果你真的想动手构建点什么东西，这个区别才是最关键的。Mage-VL 在最要紧的意义上是真实的：权重发布在 Hugging Face 上，模型卡自七月下旬以来下载量巨大，而且围绕它已经涌现出一个由社区量化版本组成的小生态。“真实”并不意味着“容易”。模型卡上带有自定义代码标签，视觉编码器也不是现有服务栈所默认的标准冻结 ViT，微软自己的仓库里就写着随之而来的实际后果——运行它意味着要使用 `trust_remote_code`，而且没有开箱即用的服务商部署方案。但一个拥有 GPU、且有决心的团队可以加载它、把它指向视频流，然后检验“编解码器原生”这个假设是否适用于自己的数据。这与 InternLumina-U2 之间存在着天壤之别：在后者的场景中，同样一句话有不同的结局——有决心的团队能读到推理代码，然后就到此为止了，因为没有可加载的权重。

microsoft/Mage-VL 的 Hugging Face 卡片（抓取于 2026 年 8 月 27 日）——编解码器原生流式传输的描述、Apache-2.0 许可证、arxiv 标签，以及一个推理提供商部分，显示当前没有任何提供商部署该模型。

{{1}}基准测试的不对称性也遵循同样的思路。{{/1}} {{2}}两款模型的数字都只是厂商单方面宣称，尚无任何独立复测。{{/2}} {{3}}但Mage-VL的说法至少立足于一个可下载的产物，这意味着从宣称到验证之间的距离，只取决于是否有人实际去运行它。{{/3}} {{4}}InternLumina-U2的说法则立足于一项路线图承诺——“完整的对比表将出现在即将发布的技术报告中”——而且目前并不存在任何能够验证这些说法的产物。{{/4}} {{5}}该实验室自己公布的部分对比表甚至显示，该模型至少在一个它自称已超越的对手面前处于劣势（GenEval 0.81 对 LLaDA2.0-Uni 的 0.89），这也有力地提醒我们：其“初步、部分”的标注应被按字面意思理解。{{/5}}

在那里他们可以共同创作，而非相互竞争。

把这两者放在一起看，最有用的方式是把它们视为梯子上相邻的两级，而不是竞争同一份工作的对手。像 Mage-VL 这样的编解码器原生监视器之所以值得关注，恰恰在于它的成本足够低，可以持续运行——它逐帧监视视频流，只有在出现值得更大模型关注的內容时才会升级处理。它升级到的那个更大模型，原则上可以是 InternLumina-U2 所声称的那类统一模型：始终在线的门控机制决定看什么，而深度模型则真正去解读图表、跟踪 3D 场景，或生成编辑后的图像。两者都尚未得到验证——Mage-VL 是“未验证但可运行”，InternLumina-U2 是“未验证且未发布”——因此，诚实的定位是：一旦两边各自经过独立验证，你就可以构建一个组合体，而非今天就能分出高下的对决。

InternLM/InternLumina-U2 GitHub 仓库，截取于2026年9月2日——仓库落地页展示了多码本扩散模型的描述、Apache-2.0许可证徽章，以及构成公开版本的推理入口脚本，而权重文件未包含在仓库中。

路由层如何处理未经证实的检查点

这两个模型都没有托管在OrcaRouter上，我们也不会暗示相反的情况——Mage-VL在任何地方都没有标准的服务路径，而InternLumina-U2没有权重。在这种情况下，路由DSL真正有用的地方在于，将上述组合表达为一次调用，而不是定制的胶水代码：一个廉价且始终在线的感知模型，将其输出馈送给一个更深层的模型，通过链式调用，使得只有当廉价模型检测到变化时，昂贵的模型才会运行。而对于未经证实的检查点问题——这正是这两个模型的全部风险所在——自动故障转移是一种机制，它允许团队在真实路径上尝试像Mage-VL这样的模型，而不必把整条路径押在它上面：一旦新的检查点出现停滞、返回垃圾输出或抛出异常，调用就会自动回退到经过验证的模型，并且不需要唤醒任何工程师来切换开关。一个API覆盖200多个模型，提供商列表价格以0%加价直接传递，而且新模型是在安全网后面试运行，而不是直接面对生产环境。

底线

如果你想在今天检验codec原生视频这一论点，那么只有Mage-VL存在——而这个“存在”还伴随着关于自定义代码和自行部署服务的告诫。如果你想检验多码本统一模型这一论点，那你还做不到，因为InternLumina-U2仍只是一份等待权重的规格说明；你现在能做的，是先把它的架构读上一遍，好在Hugging Face上那个占位页面真正填上内容时，你已准备就绪。把微软的模型看作一个笨拙但真实存在的产物，把上海AI实验室的模型看作一份文档完备的承诺；同时要记住，在这场对垒中，“厂商自报、未经复现”对两者都适用——只不过，当有文件可以下载时，这句话的含义就有所不同。