InternLumina-U2、テキスト・画像・動画・3Dを単一の16Bモデルに統合し、2種類のウェイトを公開

統合型マルチモーダルモデルは通常、何かを引き換えにする。多くのタスクをカバーする代わりに、どれも得意ではない。InternLumina-U2は、少ないパラメータ予算でその前提を検証しようとする試みであり、その公開の仕方は、アーキテクチャと同じくらい戦略について語っている。

InternLMはApache 2.0ライセンスの下、Hugging Faceでこのモデルを公開した。16BパラメータのMixture-of-Expertsモデルで、トークンあたりのアクティブパラメータは1B、表記は16B-A1Bとなる。スパースなバックボーンと、ATokenと呼ばれる仕組みの上に構築された8コードブックの完全離散型視覚表現を組み合わせ、テキスト質問応答、テキストからの画像生成、画像理解、画像編集、動画理解、3D理解を単一モデルで処理する。

興味深いのはタスク一覧の下にある。この公開には、Huawei Ascend NPU用とNVIDIA GPU用の別々のチェックポイントが含まれている。

統合モデルが実際に何を節約するのか

統合の根拠は保守コストにある。画像を理解し、かつ生成する製品を作るチームは通常、理解用と生成用に別々のモデルを動かし、2つの推論経路、2セットのプロンプト、2つのアップグレードサイクルを維持することになる。理解と生成を1つのフレームワークにまとめれば、そのオーバーヘッドの一部は消え、同じフレームワークを動画や3Dに広げれば効果はさらに大きくなる。

それをどう実現するかは、仕組みが鍵になる。完全離散型の視覚表現とは、画像が学習済みコードブックの集合（ここでは8つ）にトークン化されることを意味し、それはATokenの上に構築されている。これにより画像・動画理解は、言語モデルがすでに扱い方を知っているトークン列に近い形になり、1つのバックボーンでこれほど多くのモダリティを扱えることが妥当になる。

この規模で統合アプローチが専用モデルに匹敵するかは、未解決の問いだ。Apache 2.0は法的な摩擦を取り除くが、寛容なライセンスは、1Bのアクティブパラメータの単一経路が専用設計の画像モデルと同じくらい画像を生成できるかという問いに答えてはくれない。技術レポートは近日公開とされており、現在利用できるベンチマークは予備的なもので、企業による自己申告だ。独立した評価が登場するまで、この主張は証明されていない。

二重のハードウェアチェックポイントが、見た目以上に重要な理由

Ascend用とNVIDIA用のチェックポイントを並べて提供することは、利便性ではなく、デプロイメントに関する声明だ。

中国のAIラボは最先端チップへのアクセスが制限される中で開発を進めており、その対応は入手可能なハードウェアに合わせた積極的な最適化だった。HuaweiのAscend NPUとNVIDIA GPUの両方で動くウェイトを公開するということは、中国国外のチームがNVIDIAハードウェアで始め、後からモデルを変えずにAscendへ移行できることを意味する。また、すでにAscendで運用している中国国内企業が、新しいアクセラレータを買わずにこのモデルを導入できることも意味する。

これは聞こえるよりも切り替えコストが低い。ハードウェアの決定は定着しやすく、両方のスタックに対応するモデルは、チームを現在のベンダーにつなぎとめる障壁の1つを取り除く。どちらかの側に既存インフラを持つ企業にとって、この公開はベンチマークよりも、すでにラックに収まっているものに組み込めるかどうかが重要だ。

この文脈が論点を際立たせる。中国のラボは、クローズドなAPIを販売するだけでなく、オープンウェイトを公開することで競争するケースが増えており、その戦略的論理は2方向に働く。オープンウェイトは、クローズドなエンドポイントよりも速く採用と標準設定への影響力を広げる。また、国内のハードウェアベンダーが自社シリコンで快適に動く実在のモデルを示せるようになる。真空状態でそれを証明するしかない状況では、これは有用だ。

より厳格なライセンスとの比較

有用な対比は、最近のもう1つのオープン画像モデルだ。Qwen-Image-2.1は、テキストからの画像生成と編集を統合した7Bのチェックポイントを公開し、アルファチャンネル付きのネイティブRGBA出力を生成し、最大10枚の参照画像を受け付ける。Artificial Analysisの2つのリーダーボードで、オープンウェイトモデル中1位にランクされた。ただしそのウェイトは厳格な非商用ライセンスの下で公開されており、商用プロジェクトは公式APIを経由する必要がある。

InternLumina-U2はApache 2.0で逆の道を取る。これにより商用製品で直接利用でき、モデルは異なる競争上の位置に置かれる。すなわち、リーダーボードの頂点に立たなくても、ライセンス交渉なしに企業が合法的に構築できるウェイトだということだ。

理解しておくべきアーキテクチャの選択

2つの設計判断が重みの大部分を担っている。

1つ目はスパースなMixture-of-Expertsバックボーンだ。総パラメータ16Bでトークンあたり1Bのみがアクティブであるため、推論コストはモデル全体ではなくアクティブな集合に比例する。これにより、広範なマルチタスクモデルを手頃なコストで提供できる。任意の入力に対してネットワークの大部分が遊休状態になるからだ。

2つ目は離散型の視覚表現だ。AToken上の8コードブック方式は、モデリング上の決定であると同時に圧縮上の決定でもある。コードブックが少なく、より整理されていれば、ステップごとに予測すべき視覚情報が減る。これは、計算量で品質を買えない小さなアクティブパラメータ数では役に立つ。

どちらの選択も単体では目新しいものではない。賭けは、この規模でそれらを組み合わせることで、あらゆる分野に手を出すものの実務からは外される「何でも屋」ではなく、モダリティをまたいで真に有用なモデルが生まれるという点にある。

公開フォーマットこそがメッセージである理由

タスク一覧は野心的だが、何の上に構築するかを決める人にとっては、公開フォーマットのほうが多くのシグナルを運んでいる。際立つ選択が3つある。

1つ目はサイズだ。アクティブパラメータ1Bの16Bモデルは、フロンティアラボが744B、さらには2.8兆パラメータのモデルを出荷している現在のオープンウェイト競争の基準では小さい。入手しやすいハードウェアで安価に動く小さなモデルは、クラスタを必要とする大きなモデルとは別の製品だ。能力をお金で買うことができず、経済的に運用できる何かを必要とするチームを対象としている。

2つ目はライセンスだ。Apache 2.0は交渉なしの商用利用を認める寛容なライセンスであり、モデルの上に製品を出荷できるかどうかを判断する企業にとって、ベンチマークスコアよりも重要だ。高いスコアと制限的なライセンスを持つモデルは、API経由で呼び出すモデルだ。寛容なライセンスを持つモデルは、組み込めるモデルだ。

3つ目はモダリティの組み合わせだ。「統合」を名乗るモデルの大半はテキストと画像を扱う。同じフレームワークに動画と3D理解を加えることで、この言葉はその座を得る。そしてここにリスクもある。小さなアクティブパラメータ集合が扱うモダリティが増えるほど、それらに分散される容量は薄くなるからだ。

まとめると、この公開はリーダーボード上の順位よりもデプロイの現実に賭けたものとして読める。提供するのに十分小さく、出荷するのに十分寛容で、パイプライン内の複数のモデルを置き換えられるほど広い。

注目すべき点

この公開がどう評価されるかを決めるのは3つの点だ。技術レポートが届いたときには完全なベンチマーク表が含まれるはずで、それらの数値は重みを持つ前に独立した再現が必要だ。2つ目は、統合された経路が特に生成において持ちこたえるかどうか。そこは専用モデルが最も強固な既得権を持つ領域だからだ。3つ目はハードウェアだ。Ascend用チェックポイントが実運用で競争力があると証明されれば、二重ハードウェアでの公開がテンプレートとなり、より多くの中国のラボが両方のスタックで動くウェイトをデフォルトで提供するようになるだろう。

現時点では、この公開は意図表明として読むのが最も適切だ。中国のラボはオープンウェイト、ハードウェアの柔軟性、寛容なライセンスのすべてで同時に競争しており、InternLumina-U2はその3つを1つのモデルカードに収めている。