PixelUMMとSanaが指し示す同じ着想：ビジョンモデルから足場を取り除く

NVIDIAの研究リリースが数日のうちに2件登場し、どちらも同じ主張を共有している。PixelUMMは10月1日21:40 UTCにHugging Faceでひっそりと公開された。152億パラメータのチェックポイントで、ブログ記事もプレスリリースも基調講演のスライドもない。NVIDIA、MIT、清華大学の研究者によるSanaは、より早くから公開されており、同じ配管の問題に対して逆のアプローチを取っている。

PixelUMM：エンコーダを持たない統合モデル

リポジトリ名がプロジェクトの内容を語っている。nv-tlabs/PixelUMMは、その一行の説明で「エンコーダ不要の統合的な画像・動画の理解と生成」と記されている。Qwen3-8Bをバックボーンとし、リポジトリのライセンスはApache-2.0だ。

「エンコーダ不要」という部分が興味深い主張である。現在の視覚AIシステムのほとんどは、別々のコンポーネントを連結している。画像を言語モデルが読めるトークンに変換するビジョンエンコーダ、ピクセルデータを拡散モデルが扱える潜在空間に圧縮するVAE、そして系列を処理するビジュアルトランスフォーマーだ。PixelUMMはそうした中間段階なしで動作するよう作られており、だからこそ重みがダウンロード可能である一方で、プロジェクトページには今も「preview」と表示されている。

すでに存在する成果物と、何も発信していないベンダーとのこのギャップこそが、このリリースのすべてである。GitHubリポジトリがあり、9月29日付で2609.38597の番号が付されたarXivプレプリントがあり、著者はNVIDIAとウォータールー大学の研究者だ。チェックポイントは128ファイルに分割され、ローダーがなければ実行を拒否する隠しインデックスが付いている。NVIDIAがPixelUMMを発表済みと見なしているかどうかは、同社が答えていない問いである。

このリリースのパターンは、この分野を追う者にとって重要だ。かつてはブログ記事、デモページ、調整されたプレスサイクルとともに登場した研究が、今ではリポジトリと論文という形で届くことがある。成果物は公開され引用可能である一方、ベンダー自身の発信は沈黙している。そのため、モデルを使うことはできても、公式なベンチマークを引用することはできない。評価するチームは、論文と自前のテストだけを頼りに作業している。

Sana：単一モジュールではなくコストの連鎖を圧縮する

Sanaは同じスタックの層に、逆の方向から切り込む。高解像度のテキストto画像が高コストになる理由は、ピクセル数とはほとんど関係がない。拡散トランスフォーマーに入る潜在トークンの数が、解像度とともに急速に増えるからだ。標準的な自己アテンションはすべてのトークンを他のすべてのトークンと関連付ける必要があるため、計算コスト、メモリ、レイテンシがそろって上昇する。

NVIDIA自身による1024ピクセルでの比較では、FLUX-devは120億パラメータを抱え、毎秒0.04サンプルで動作し、1画像あたり23秒かかる。2Kや4Kに近づこうとすると、モデルを縮小したりサンプリングステップを削ったりしても、根本的な問題は解決しない。

Sanaは単一のコンポーネントではなく、連鎖全体を圧縮する。32倍の深い圧縮オートエンコーダが潜在トークンの数を削減する。線形アテンションが各トランスフォーマー層のコストを下げる。効率的なソルバーと少数ステップ蒸留がサンプリングの回数を減らす。スライシング、オフローディング、低ビット量子化がデプロイ時のメモリを抑える。公開されているモデルには最大4Kを狙った0.6B版と1.6B版があり、Sana-1.5では4.8Bまで拡張されている。公式の1024ピクセル比較では、0.6B版は0.9秒のレイテンシで動作する。

連鎖を圧縮するアプローチには、単一モジュールの修正にはない魅力的な性質がある。すべての段階が寄与するため、チームは自分のハードウェアに合う部分だけを適用し、残りは省くことができる。ワークステーションしか持たず量子化の経験もない者は、効率的なソルバーだけを使えばよい。大規模にデプロイする者は、スライシング、オフローディング、低ビット量子化を積み重ねて、はるかに小さなカードに収めることができる。トレードオフは、オール・オア・ナッシングの単一の判断に束ねられるのではなく、段階ごとに文書化されている。

Sanaの系譜は、研究成果がどれほど速くプロダクトの表面になるかも示している。当初のモデルは4Kのテキストto動画出力を狙っていた。リポジトリはその後、Sana-Sprint、動画生成、ControlNet、LoRA、量子化、ComfyUI連携、オンラインサービスを含むまでに成長した。これは画像ツールがたどったのと同じ弧である。論文からリポジトリへ、そして人々がすでに使っているインターフェースのノードへ。

2つのアプローチに共通するもの

両者を並べてみると、進む方向は明らかだ。どちらも、この分野の初期からピクセルとモデルの間に鎮座してきた中間機構を取り除こうとしている。PixelUMMはエンコーダがそもそも必要なのかを問う。Sanaは品質が崩れる前に計算の連鎖をどこまで圧縮できるかを問う。

トレードオフはどちらの場合も同じで、どちらの研究室もそれを隠していない。エンコーダを取り除けば、モデルはエンコーダが提供していたものを自ら学習しなければならず、学習計算コストがかかり、エンコーダが得意としていたタスクでは品質が落ちる可能性がある。連鎖を積極的に圧縮すれば品質の天井が動き、Sana自身の資料も、そうしたレイテンシ数値の背後にあるハードウェアと測定条件について慎重に述べている。

両研究室がこの層を攻める理由は、中間物が高コストな部分になってしまったからだ。ビジョンエンコーダとVAEは別々に学習され、別々に調整され、別々に提供される。それぞれがパイプラインの他の部分と同期を失い得るコンポーネントであり、それぞれがすべてのリクエストの先頭でレイテンシを加算する。それらを取り除くことは研究上の小技ではなくアーキテクチャの簡素化であり、あらゆるデプロイで効果を発揮する。

画像を使って何かを作る人にとって重要な理由

実務家にとっての実際的な帰結は、ハードウェアの下限が下がることだ。NVIDIAのSanaの取り組みは、今年見られるより広いパターンの一部である。かつてデータセンター用カードを必要としたモデルが、コンシューマー向けハードウェアに収まるよう作り直されつつあり、オープンコミュニティは6GBのVRAMという下限を、おまけではなく要件として扱い始めている。

アーキテクチャ図に現れる第2の帰結もある。エンコーダとVAEが別々のサービスでなくなれば、バージョン管理し、監視し、対価を払うべきモデルが3つあったパイプラインが1つになる。これはレイテンシの数値ほど目立たないが、実際のプロダクトの保守負担を変えるのはまさにこの点だ。

これらのモデルの上に何かを作るチームにとって、実際的な問いは、どの簡素化を最初に採用できるかである。エンコーダ不要のアプローチはよりクリーンなアーキテクチャを約束するが、モデル自身の表現処理が専用設計のエンコーダが提供していたものと一致することを信頼する必要がある。連鎖圧縮のアプローチは、既存のアーキテクチャをそのまま保ちつつ、今日測定可能な速度とメモリの利得を約束する。一方はこの分野が向かう方向への賭けであり、もう一方はすでに持っているハードウェアへの賭けである。

どちらの賭けも合理的であり、それらを追求する研究室は同じデプロイを奪い合っているわけではない。PixelUMMの統合的な枠組みは、理解と生成に1つのモデルを求めるチームに適している。Sanaは、制約のあるハードウェアで高解像度の出力を必要とするチームに適している。重なるのは、両者が削除しようとしているスタックの部分である。

NVIDIAはPixelUMMが完成しているかどうかを明言していない。Sanaのコードは公開されており、リポジトリはSprint版、動画生成、ControlNet、LoRA、量子化、ComfyUI対応、オンラインサービスを含むまでに成長した。2つの研究チーム、2つの道筋、1つの標的。誰も考えたくなかった視覚スタックの部分が、設計から外されつつある。