NVIDIA PixelUMM 無預警推出——權重剛剛釋出

要發現 NVIDIA 打造了一個新的統一多模態模型，最簡單的方法就是注意到根本沒人告訴你。nvidia/PixelUMM 儲存庫在 2026 年 10 月 1 日 21:40 UTC 出現在 Hugging Face 上，帶著一個 152 億參數的檢查點，其整個學習堆疊都建立在 Qwen3-8B 主幹之上——而且沒有部落格文章、沒有新聞稿、沒有主題演講投影片，也沒有隨附的發布討論串。搜尋這個名稱，在 NVIDIA 自己的部落格上找不到任何東西。取而代之的是，一個 GitHub 儲存庫、一個網址本身仍寫著「preview」的專案頁面、一篇編號 2609.38597 的 arXiv 預印本，以及一個分割成 128 個檔案、附有隱藏索引的檢查點，而載入器沒有這個索引就拒絕執行。PixelUMM 是真的，而且今天就能下載。NVIDIA 是否認為它已經發布，這個問題該公司尚未回答。

那道落差——介於一個確實存在的產物，與一個什麼都沒說的廠商之間——就是這裡的完整故事，而值得精確釐清的是，每一項事實究竟落在這道落差的哪一側。以下所有內容都出自儲存庫、模型卡，以及作者自己發表的那篇論文。沒有任何內容出自公告，因為根本沒有公告。

出現了什麼，以及何時？

這系列為期約四週，而每一篇都悄然上線。

• 2026年9月4日 — nv-tlabs/PixelUMM 在 GitHub 上以 Apache-2.0 儲存庫授權建立，並簡單描述為「無編碼器的統一影像與影片理解與生成」。直到九月底，它都只有一個初始提交。

• 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，具備原始像素 patch 嵌入與迭代式像素生成頭；論文中將其描述為一種 Mixture-of-Transformers，會將共享注意力與任務特定參數配對。

• 主幹 — Qwen3-8B，固定至修訂版 b968826d9c46dd6066d109eabc6255188de91218。僅需其設定檔與分詞器檔案；檢查點本身帶有自己學習到的語言權重。

• 參數 — 15,199,672,064（約 15.2B），在論文自身的基準測試表格中標示為「8B MoT」，其中大小標記是將主幹與生成專家分開計算。

• 目標 — 自迴歸文字預測與像素空間流匹配經聯合訓練，這正是讓一組權重既能回答關於影像的問題，也能繪製出新影像的關鍵。

• 任務 — 文字轉圖像、文字轉影片（96 幀／24 fps／4 秒）、以圖像為條件的文字，以及以影片為條件的文字。

這篇論文的實證部分有一種值得特別指出的不尋常之處。其中八個小節研究的是設計選擇，而非排行榜名次——影像區塊大小、影片區塊大小、區塊偽影、像素空間與 VAE 空間的訓練動態、模型大小、運算擴展、多模態脈絡條件化，以及影片理解介面。這是一篇由試圖回答此方法是否行得通的人所寫的論文，而不是一篇試圖在排行榜上取勝的論文。

這些數字是作者自己的

以下每一個數字，都是由 PixelUMM 作者在他們自己的預印本中報告的。沒有獨立重現，沒有競技場 Elo，也沒有第三方評估，因為這個模型最多只有六週大，而且早於任何外部評測框架問世。請把這些視為附帶下載連結的宣稱，而不是已驗證的效能表現。

• 圖像理解 — 在官方 LMMS-Eval 協定下，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（橫跨 21 項任務共 64,750 次生成）。

• 影片理解 — 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 授權，而模型卡也明白標示了這一點。檢查點是另一項具有不同條款的成品，而這正是最可能讓團隊栽跟頭的細節。權重是以 NVIDIA One-Way Noncommercial License 發布，其使用僅限於非商業研究或評估——這是一項比緊鄰其旁的程式碼實質上更嚴格的授權。儲存庫中有一個原始碼檔案 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 打造了某個不尋常的東西，徹底公開，卻沒有告訴任何人。這個儲存庫就是那則公告。