NVIDIA PixelUMM 在毫无公告的情况下发布了——权重刚刚落地

要发现 NVIDIA 构建了一个新的统一多模态模型，最简单的方式就是注意到：没人告诉过你。nvidia/PixelUMM 仓库于 2026 年 10 月 1 日 21:40 UTC 出现在 Hugging Face 上，携带一个 152 亿参数的检查点，其整个学到的堆栈都建立在 Qwen3-8B 主干之上——而且没有与之配套的博客文章、新闻稿、主题演讲幻灯片或发布帖。在 NVIDIA 自己的博客上搜索这个名字，结果一无所获。取而代之的是：一个 GitHub 仓库、一个自身 URL 仍写着 “preview” 的项目页面、一篇编号为 2609.38597 的 arXiv 预印本，以及一个拆分成 128 个文件的检查点，带有一个隐藏索引，加载器没有它就拒绝运行。PixelUMM 真实存在，而且今天就可以下载。NVIDIA 是否认为它已经发布，是该公司尚未回答的问题。

那个缺口——介于一个已经存在的制品与一个一言未发的厂商之间——就是这里的全部故事，而值得精确说明的是：每一条事实究竟落在它的哪一侧。下文的一切都来自代码仓库、模型卡以及作者自己发表的论文。没有任何内容来自公告，因为根本就没有公告。

出现了什么，以及何时出现？

这个系列持续了大约四周，每一篇都悄然落地。

• 2026年9月4日 — nv-tlabs/PixelUMM 以 Apache-2.0 仓库许可证在 GitHub 上创建，简介仅为“无编码器的统一图像与视频理解与生成”。在九月底之前，它一直只保留着一次初始提交。

• 2026年9月28–29日——该仓库的首次提交落地，arXiv 随即为这篇预印本分配了编号 arXiv:2609.38597，日期标注为9月29日，所列作者来自 NVIDIA 和滑铁卢大学：Cong Wei、Xuanchi Ren、Bryan Chu、Weiming Ren、Huan Ling、Jiahui Huang、Laura Leal-Taixé、Sanja Fidler、Wenhu Chen、Zian Wang 以及 Jay Zhangjie Wu。

• 2026年10月1日 21:32 UTC — 向该仓库提交了最后一次提交，标题为“docs: add PixelUMM paper citation”。

• 2026年10月1日 21:40 UTC——八分钟后，Hugging Face 模型仓库创建完成，并填入了检查点分片。

项目页面托管在一个路径下，该路径字面写着 pixelumm-project-page-preview，而论文没有会议信息行——没有 CVPR，没有 NeurIPS，也没有“accepted to”。综合来看，这一连串迹象读起来像是研究团队把论文成果直接上线，并让 HF 上传本身充当公告。这是对证据的观察，而不是对意图的断言：NVIDIA 完全可能计划在之后发布，这里没有任何内容排除这种可能。

PixelUMM实际上是什么

设计主旨写在模型卡片的第一行：没有 VAE，没有视觉编码器。传统统一模型带有两个视觉接口——一个视觉 Transformer 用于产生供理解使用的语义特征，一个变分自编码器用于产生供生成使用的重建潜变量——而 PixelUMM 一个都没有。图像被切成 16×16 像素图块；视频被切成 4 帧时空管状片段；两者都仅通过单层线性投影进入主干网络。原始像素输入；原始像素输出。

• 架构——仅解码器 Transformer，采用原始像素块嵌入和迭代式像素生成头，论文中将其描述为一种 Mixture-of-Transformers，将共享注意力与任务专属参数相结合。

• 骨干——Qwen3-8B，锁定到修订版 b968826d9c46dd6066d109eabc6255188de91218。只需其配置文件和分词器文件；检查点自带其学习到的语言权重。

• 参数量 — 15,199,672,064（约 15.2B），在论文自身的基准测试表格中标注为 "8B MoT"，其中该规模记法将主干网络与生成专家分别计数。

• 目标——自回归文本预测与像素空间流匹配联合训练，这正是让同一套权重既能回答关于图像的问题、又能绘制出新图像的原因。

• 任务 — 文生图、文生视频（96帧 / 24 fps / 4秒）、图像条件文本和视频条件文本。

这篇论文的实证部分有一种值得指出的不寻常之处。它的八个章节研究的是设计选择，而非排行榜名次——图像块大小、视频块大小、块伪影、像素空间与 VAE 空间的训练动态、模型规模、计算扩展、多模态上下文条件化，以及视频理解接口。这是一篇由试图回答该方法是否有效的人所写的论文，而不是一篇试图在榜单上争胜的论文。

这些数字是作者自己的

以下每个数字都是由 PixelUMM 作者在他们自己的预印本中报告的。没有独立复现，没有竞技场 Elo，也没有第三方评估，因为该模型最多只有六周大，并且早于任何外部测试框架。请将这些视为带有下载链接的说法，而非经过验证的性能。

• 图像理解 — 在官方 LMMS-Eval 协议下（涵盖 21 项任务、共 64,750 次生成），MMMU 41.67、MMStar 53.99、AI2D 80.12、DocVQA 90.42、ChartQA 82.96、OCRBench 78.00、BLINK 53.46、MMMU-Pro 27.63。

• 视频理解 — MVBench 70.53，无字幕 Video-MME 57.33，LongVideoBench 59.61，LVBench 40.41。

• 图像生成 — 使用 LLM 提示词重写器时，GenEval 总体得分为 0.83，不使用时为 0.77；DPG-Bench 总体得分为 85.74。

• 视频生成——VBench 第 1 部分质量得分 84.10，语义得分 79.80；VBench 第 2 部分总分 83.24。

诚实的解读是，这些是同类中具有竞争力的数字，而不是领跑类别的数字，论文自己也这么说：它指出，由于各模型的训练数据不同，结果“无法确定哪种架构更优越”。与 Qwen3-VL-8B 相比，图像理解差距在 MMMU 上很大（41.67 对 69.60），而在 MMMU-Pro 上，作者未报告可对比的数字。与 Qwen-Image 20B 相比，GenEval 差距为 0.83 对 0.87。就其自身数字而言，PixelUMM 不是一个最先进的模型。就其自身数字而言，它是一个 15B 模型，拥有真正不同寻常的架构，与周边专用系统落在同一档位。

最锋利的武器是许可证，而不是基准测试

该仓库采用 Apache-2.0 许可，模型卡片也明确如此标注。而检查点（checkpoint）是另一种制品，适用不同的条款，这正是最容易让团队踩坑的细节。权重文件以 NVIDIA One-Way Noncommercial License（NVIDIA 单向非商业许可）发布，其使用仅限于非商业研究或评估——相比紧邻其旁的代码，这一授权范围要严格得多。仓库中还有一个源文件 modeling/pixelumm/modeling_utils.py，额外保留了源自 DiT 的 CC BY-NC 4.0 声明。

对于研究小组、评估团队或任何要发表论文的人来说，这是一份完全可用的许可证。对于正在为内部功能做原型的产品团队来说，这是首先要交给法务审的东西，而答案可能是“不行”。一个你无法发布的模型，与一个你可以发布的模型，是不同类别的资产，再多基准测试上的持平也无法改变这一点。

运行它需要什么条件

这不是一个周末就能完成的下载。环境文档要求 Linux x86-64、Python 3.12、CUDA 13.0 开发工具包、NVIDIA GPU，以及针对该工具包从源码构建的 FlashAttention——仅含运行时的 CUDA 镜像是不行的。检查点本身也不是 model.safetensors 文件：它是 128 个 .distcp 分片，总计约 30 GB，外加一个隐藏的 .metadata 索引，而加载器要求每个被引用的分片和该索引都必须存在。

还有两个细节会决定你实际能用它做什么。首先，文生视频默认会运行 Cosmos 护栏，而这些护栏需要访问受门控的 nvidia/Cosmos-1.0-Guardrail 仓库，外加一个具有不同 Transformers 主版本的第二个 Python 环境——仅靠登录并不能解锁权重。其次，四步玩具训练示例是唯一已发布的训练配方，其文档说明需要七块 GPU，每块至少 48 GiB，并且输出需要约 61 GB 的可用磁盘空间。在工作站上进行微调并非预期路径；在单块现代显卡上进行推理才是。

该仓库提供四个检查点。S8-F22-R05 是默认检查点，也是论文评估所使用的那个，涵盖全部四项任务。S8-F18-R01 在 480p 和 720p 下额外进行了 10,000 步微调，通常能给出略好的文本到视频结果，但它无法进行视频理解。S8-F19-R03 和 S8-F21-R02 是中间阶段。在它们之间做选择是一个真正的决定，而不是细枝末节。

什么尚未确认

一份简短的清单，但它比上面那份长清单更重要。

• 没有 NVIDIA 的公告。截至本文撰写时，该型号既没有新闻稿，公司自家博客上也没有相关文章。如此低调的发布可能是有意为之——研究成果往往以此方式推出——也可能根本尚未正式发布。

• 无独立评估。本文中的每一个数字均出自作者本人。没有任何数据在 NVIDIA 和 Waterloo 之外被重新运行。

• 任何地方都没有托管线路。如今你无法通过 API 调用 PixelUMM，OrcaRouter 也不例外——我们不为其提供路由，也无能为力，因为采用非商业许可的检查点，不是商业服务型平台所能提供的。任何告诉你并非如此的人，描述的其实都是自托管部署。

• 未就未来许可表明立场。非商业条款即发布时的既定条款。其是否会放宽尚不可知，而且鉴于 NVIDIA 在科研检查点方面的过往表现，这也不应成为规划的依据。

接下来要关注什么

有三件事会让 PixelUMM 从研究产物变成更广泛受众能够使用的东西。第一是对检查点的许可变更——那一个文件就是“有趣”与“可用于产品”之间的全部障碍。第二是 NVIDIA 的官方发布，它会带来该仓库无法提供的定位说明：这个模型的用途是什么，以及它究竟是一条产品方向，还是一篇论文。第三是首次独立复现，最可能是由某个拥有闲置 GPU 集群的人重跑 GenEval 或 MVBench——那一刻，作者给出的数字将不再是唯一的数字。

在那之前，正确的姿态是证据支持的那一个。PixelUMM 确实存在，代码和论文公开可读，权重可以下载，而所有性能声明都尚未被打造它们的团队之外的任何人核实过。这不是对这项工作的批评——这只是一个诞生六周的研究发布该有的样子。这也正是路由层日后能体现价值的那种情形，如果许可证有一天放宽的话：用一个密钥访问你已经信任的模型，按 0% 加价转传标价，以及故障转移——让你能把一部分流量指向某个未经证实的东西，而不必把一条生产路径押在它上面。不过就目前而言，诚实的总结更简单。NVIDIA 造出了某种不寻常的东西，详尽地发表了它，却没有告诉任何人。那个代码仓库就是公告。