PixelUMM 與 Sana 指向同一個理念：拆掉視覺模型的鷹架
NVIDIA 的兩項研究成果在幾天內相繼問世，而且共享同一個核心論點。PixelUMM 於 10 月 1 日 21:40 UTC 悄然現身 Hugging Face，是一個 1,520 億參數的檢查點，沒有部落格文章、沒有新聞稿、沒有主題演講投影片。來自 NVIDIA、MIT 與清華大學研究人員的 Sana，公開的時間更早，對同一個底層管線問題採取相反的解法。
PixelUMM：沒有編碼器的統一模型
儲存庫名稱就說明了這個專案是什麼：nv-tlabs/PixelUMM，其自身的一行簡介寫著「無編碼器的統一圖像與影片理解與生成」。它以 Qwen3-8B 為骨幹，儲存庫採用 Apache-2.0 授權。
「無編碼器」是最有意思的主張。當今多數視覺 AI 系統都是把各自獨立的元件串接起來：用視覺編碼器把圖像轉成語言模型能讀取的 token，用 VAE 把像素資料壓縮到擴散模型可運作的潛空間，再用視覺 transformer 處理序列。PixelUMM 的設計就是要在沒有這些中介階段的情況下運作，這也是為什麼它的專案頁面至今仍標示為「preview」，而權重卻已經可以下載。
一個已經存在的成品，與一個什麼都沒說的廠商之間的落差，就是這次發布的全部故事。有一個 GitHub 儲存庫、一篇編號 2609.38597、日期為 9 月 29 日的 arXiv 預印本，作者來自 NVIDIA 與滑鐵盧大學，還有一個被拆成 128 個檔案的檢查點，內含隱藏索引，載入器少了它就拒絕執行。NVIDIA 是否認為 PixelUMM 已經正式發布，這個問題公司並未回答。
對任何關注這個領域的人來說，這種發布模式本身就很值得注意。過去研究成果會伴隨部落格文章、示範頁面和一套協調好的公關宣傳一同登場，如今有時只是以一個儲存庫和一篇論文的形式出現。成品公開且可被引用，而廠商自身的對外溝通卻一片沉默，這使得你可以使用這個模型，卻無法引用任何官方基準數據。評估它的團隊只能依據論文和自家測試。
Sana：壓縮成本鏈，而非單一模組
Sana 從相反方向切入同一個技術堆疊層。高解析度文字轉圖像之所以昂貴，原因和像素數量關係不大：進入擴散 transformer 的潛在 token 數量會隨解析度快速成長。標準自我注意力必須讓每個 token 與其他所有 token 建立關聯，因此成本、記憶體與延遲會一起攀升。
在 NVIDIA 自家的 1024 像素比較中，FLUX-dev 擁有 120 億參數，執行速度為每秒 0.04 個樣本，每張影像需 23 秒。當推向 2K 或 4K 時，縮小模型或減少取樣步數並不能解決根本問題。
Sana 壓縮的是整條鏈，而不是單一元件。32 倍深度壓縮自動編碼器減少了潛在 token 的數量。線性注意力降低了每一層 transformer 的成本。高效率求解器與少步蒸餾減少了取樣次數。切分、卸載與低位元量化降低了部署時的記憶體需求。已發布的模型包含針對最高 4K 的 0.6B 與 1.6B 版本，Sana-1.5 則擴展到 4.8B。在官方 1024 像素比較中，0.6B 版本的延遲為 0.9 秒。
鏈式壓縮法有一項單一模組修正所沒有的誘人之處。由於每個階段都有貢獻，團隊可以只採用符合自家硬體的部份，其餘略過。只有工作站、沒有量化經驗的人，可以只採用高效率求解器。大規模部署的人則可以疊加切分、卸載與低位元量化，塞進小得多的顯示卡。各項取捨都按階段分別記錄，而不是全部綁成一個非全即無的決定。
Sana 的發展脈絡也顯示研究成果轉化為產品介面的速度有多快。最初的模型目標是 4K 文字轉影片輸出。該儲存庫後來擴展到包含 Sana-Sprint、影片生成、ControlNet、LoRA、量化、ComfyUI 整合以及線上服務。這與圖像工具走過的路徑相同：從論文，到儲存庫，再到人們早已在使用的介面中的一個節點。
兩種做法的共通點
把這兩項發布並排來看，行進方向就很清楚了。兩者都試圖移除自這個領域早期以來、一直卡在像素與模型之間的中介機制。PixelUMM 質問編碼器究竟是否有必要存在。Sana 則追問在品質崩壞之前，這條運算鏈能被壓縮到什麼程度。
兩種情況下的取捨都一樣，而兩個實驗室都沒有隱瞞。移除編碼器意味著模型必須自行學會編碼器原本提供的東西，這會耗費訓練算力，也可能在編碼器原本擅長的任務上犧牲品質。激進壓縮整條鏈則意味著品質天花板會改變，而 Sana 自家的資料對這些延遲數字背後的硬體與量測條件都相當謹慎。
兩個實驗室之所以都攻擊這一層，是因為中介元件已經變成最昂貴的部分。視覺編碼器與 VAE 分別訓練、分別調校、分別服務。每一個都是可能與流程其餘部分失去同步的元件，而且每一個都會在每次請求的最前端增加延遲。移除它們是架構上的簡化，而非研究上的花招，而且能在每一次部署中帶來回報。
為什麼這對任何以圖像打造產品的人都很重要
對實務工作者而言，實際的結果是硬體門檻降低了。NVIDIA 的 Sana 研究是今年一個更大趨勢的一部分：過去需要資料中心顯示卡的模型，正被改造到能跑在消費級硬體上，而開源社群已開始把 6GB VRAM 的門檻視為基本要求，而非額外福利。
還有第二個後果，會出現在架構圖上。當編碼器與 VAE 不再是各自獨立的服務，過去需要三個模型來做版本控管、監控與付費的流程，就變成只有一個。這比延遲數字更不明顯，但真正改變實際產品維護負擔的正是這一點。
對在這些模型之上開發的團隊來說，實際的問題是：他們能先採用哪一種簡化。無編碼器路線承諾更乾淨的架構，但前提是要相信模型自身的表徵處理能比得上專門打造的編碼器所提供的效果。鏈式壓縮路線則承諾在今天就帶來可量測的速度與記憶體效益，同時保持現有架構不變。前者是對這個領域走向的押注；後者是對你手上現有硬體的押注。
兩種押注都合理，而投入其中的實驗室也並非在爭奪同一種部署場景。PixelUMM 的統一框架適合想要用一個模型同時做理解與生成的團隊。Sana 則適合需要在有限硬體上產出高解析度結果的團隊。兩者重疊之處，正是雙方都試圖刪掉的那一層。
NVIDIA 尚未說明 PixelUMM 是否已完成。Sana 的程式碼已經釋出，而該儲存庫已擴展到包含 sprint 變體、影片生成、ControlNet、LoRA、量化、ComfyUI 支援以及線上服務。兩個研究團隊、兩條路線、一個目標：視覺堆疊中那些沒人想理會的部分，正被設計剔除。