MOSS-Imageが登場：OpenMOSSがプロンプトでバウンディングボックスを受け付ける5B DiTをリリース

MOSS-Imageのローンチをめぐる気まずい細部は、それについて最も声高に語られていることが、まだ完全には事実ではないという点だ。10月17日、vLLMの公式アカウントはOpenMOSSチームのオープンソースリリースを祝福し、「vLLM-OmniでDay 0にMOSS-Imageをサポートできることを誇りに思う」と述べた。実際にこのモデルをそのランタイムに追加するプルリクエスト——[Model] SLGを用いたMOSImageのテキストから画像への生成を追加、25ファイルにわたる3,605行の追加——は、10月14日に開かれ、今もオープンのままで、レビュアーは固定された参照実装に対する出力一致の証拠を求めている。vLLM-Omniの最新公開リリースは10月6日付のv0.31.0rc1だ。したがって、vLLM-Omniの出荷済みバージョンにこのモデルを含むものはなく、Day 0という主張を正直に言い換えれば、サービング経路はインストールできるパッケージとしてではなく、ビルドできるブランチとして存在するということになる。この区別はここではいつも以上に重要だ。なぜなら、MOSS-Imageは本当に興味深いリリースであり、その実質的な内容は重みにある：MOSS-Image-Base と MOSS-Image-SFT が2026年10月16日にApache 2.0の下でリリースされ、構造化JSONレイアウトをプロンプトとして受け取るコンパクトな拡散トランスフォーマーを中心に構築されているからだ。

要点だけを手短に。OpenMOSS——MOSSの言語・音声シリーズを手がけるラボで、MOSI Intelligenceや学術パートナーと協力している——は、ゼロから学習した5Bの単一ストリーム拡散トランスフォーマーを、凍結したQwen3.5-9Bテキストエンコーダーと凍結したFLUX.2 VAEと組み合わせ、重みと推論コードの両方をカバーする寛容なライセンスの下でリリースした。その売りは生の画像品質ではない。バウンディングボックス、リテラル文字列、タイポグラフィに関する注記を含むJSONオブジェクトを渡せば、それに従ってくれるという点だ。付随するベンチマーク数値はベンダー自身のもので、同じくベンダーが構築した2つのベンチマークで測定されている。それは失格要因ではないが、リーグ表ではなく、ラボ内部のスコアボードとして読むべきだということを意味する。

実際に出荷されたもの、そしてそれはどこへ

成果物は明快で検証可能だ。Hugging Faceでは、OpenMOSS-Team/MOSS-Image-BaseとOpenMOSS-Team/MOSS-Image-SFTが重みを公開しており、両方にModelScopeミラー、単一のA10Gで動作するGradio Space、そしてパイプライン、ComfyUIプラグイン、技術レポートを収めたGitHubリポジトリがある。openmoss.aiのプロジェクトページも同じ日付を示している：2026年10月16日 — MOSS-Image-Baseを紹介、コードとモデルの重みが利用可能。

2つのチェックポイント、1つのアーキテクチャ。Baseは事前学習済みモデルで、SFTは厳選されたデータでファインチューニングされている。ベンダー自身の比較例では、SFTがより密接なテキストのまとまりと、より整ったレイアウトを生成しており、これは意図的に未蒸留のままにされたベースモデルを厳選データでファインチューニングしたときに概ね予想されることだ。Baseカードは、それが「CFGなどの推論パラメータのポストトレーニングや蒸留を一切受けていない」ことを明言しており、その理由として、学習情報を保持し、モデルにLoRAをより簡単に学習させるためだと述べている。実際上の結果として、Baseはファインチューニングのためのより良い土台であり、気軽なプロンプティングのデフォルトとしてはより不向きである。

ライセンスは重みとスタンドアロンのパイプラインコードに対して Apache 2.0 です — 収益しきい値も、許容利用に関する付属文書も、別個の商用ティアもありません。判読可能なテキストを画像にレンダリングすることが最大の売りであるモデルにとって、これはベンチマーク表よりも重大な事実です。なぜなら、テキストのレンダリングこそが商用の仕事に現れる能力だからです。製品モックアップ、UIコンポ、インフォグラフィック、ポスター、広告レイアウト。

重要な数字で見るアーキテクチャ

技術レポートの構成表は、そのリリースがプレスリリースであることをやめ、仕様書になり始める場所である。5Bという数字は拡散生成器のみを指す — 単一ストリームのトランスフォーマーで、42のジョイントブロックの深さ、隠れ幅3072、それぞれ128次元の24のアテンションヘッド、SiTU-GLU活性化を使用する8192幅のフィードフォワード、そして最初の軸が参照インデックス用に予約された4軸の回転位置エンコーディングであり、これにより位置スキームを変更せずに参照条件付き生成を後で追加できる。

次に、「5B」というラベルが密かに排除している部分がある：

・テキストエンコーダー — Qwen3.5-9B（凍結）。最終層のトークン隠れ状態を次元4096で線形射影により3072へ供給し、さらにテキスト専用トランスフォーマーブロック2つを加える。5Bの生成器に9Bのエンコーダーを接続すると、見出しの数字が示唆するよりも実質的に大きなフットプリントになる。

• VAE — FLUX.2 の VAE。凍結され、FLUX.2-klein-4B から読み込まれ、空間ダウンサンプリング係数 8 で 32 個の潜在チャネルを持ち、2×2 の潜在パッチにより実効画像ストライドは 16 ピクセルとなる。MOSS-Image 自身のモデルカードには、FLUX.2 small デコーダーを使用していると記されている。

• ダウンロードサイズ — SFTリポジトリは合計約27.2 GBで、そのうちテキストエンコーダーは4つのシャードで約16.8 GB、トランスフォーマーは3つで約10.2 GBです。計画はバッジではなく、エンコーダーを基準にしてください。

• プロンプト上限 — 最終事前学習段階で4096トークン。これはベンダーの「最大4Kトークン」という主張と一致します。出力ディメンションは正の16の倍数でなければならず、ガイドでは1メガピクセル、1.5メガピクセル、または2メガピクセルを推奨しており、サポートされる外挿範囲は0.25M（512×512）から4Mです。

• サンプリングの既定値 — フローマッチング Euler、50ステップ、CFG 3.0、shift 5.0、第22層のネガティブ分岐でスキップ層ガイダンスを使用。既定のガイダンス経路ではステップごとに Transformer の順伝播が2回必要なため、50ステップはその響きほど安上がりな設定ではない。

• 学習 — 3つの漸進的な解像度ステージ：256pxで210万ステップ、512pxで210万ステップ、その後およそ1024²で31万ステップ、サンプルあたりの最大トークン数は576から3,072、そして8,192へと増加する。コーパスはReLAION由来のセットで、重複排除とAI画像の除去によって約50億枚から30億枚に削減されており、報告書はそれ以上のフィルタリングは適用されていないと述べている — キャプションにアーティファクトが含まれる画像は除外されずに保持され、そのアーティファクトが記述される。最適化はハイブリッドなMuon–AdamWであり、ベンダー自身による10億パラメータのアブレーションでは、2つのチェックポイントにおいて同一の損失に到達するまでのステップ数がAdamWよりも33.2%および28.6%少ないと報告されている。学習には異種混在のGPUプラットフォームが使用されたと述べられているが、これはモデルについてではなくハードウェア供給についての主張であり、報告書はそれらの名称を挙げていない。

ベンチマークの前に一つ触れておきたいこと

プロンプト拡張モジュール ― 「英語のコアラ知識インフォグラフィックをデザインする」を完全なコンテンツおよびレイアウト仕様へと変える部分 ― は、ベンダー自身の小型モデルではない。レポートは、LayoutPE は推論時にモジュール式のタスク指示を用いて G​PT-6 を使用すると明言しており、リポジトリに同梱されているプロンプトエンハンサーのスキルは G​PT-6 ファミリーのエージェント向けに設計されたものだと説明されている。したがって、以下に示す最強のエンドツーエンド結果は単一モデルの出力ではない。仕様部分が他社の API 上で動作する、2 モデルによるパイプラインなのだ。Elo ランキングを生成器そのものの純粋な指標として読んでいたのなら、それはそうではない。

ベンチマーク表、およびその作成者

MOSS-Imageは、リリースに同梱された2つのベンチマークで評価されている。これらは、既存のテストでは自社が重視するものを測定できていないというベンダー自身の主張から生まれたものである。LongLongTextBenchは240件の文学テキスト描画タスク——英語120件、中国語120件、平均目標長1,339.8文字で、LongTextBenchの平均のおよそ11倍——である。RealLayoutArenaは61件のデザインタスク（ポスター20件、インフォグラフィック20件、ユーザーインターフェース21件）で、ブラインドのペアワイズ人間比較によって判定され、Bradley–TerryのEloスケールに当てはめられる。ベースラインが登場する場合、それらは他社モデルをベンダーが実行したものである。このセクションのすべての数値はベンダー報告であり、再現されておらず、そのいずれも独立した監査を受けていない。

LongLongTextBenchのMean-6テキストカバレッジにおいて、MOSS-Imageは96.3を記録している。これはベンダーの表に載ったオープンウェイトモデルの中で最高値であり、Q​wen-Image-2512の64.9を大きく上回っている。また、最長条件でのスコアは英語が97.1、中国語が92.4だ。この表の誠実さを保っているのは、そのすぐ上の行にある数字である。ベンダー自身のベンチマークで、ベンダー自身の実行において、GPT Image 2は99.0、Nano Banana Proは96.6を記録している。OpenMOSSは、競合が依然として勝利する表を公開した。それには相応の価値がある。

7Benchのレイアウト制御では、その差ははるかに大きい — 検出されたターゲットオブジェクトに対する平均IoUは、MOSS-Imageが0.88であるのに対し、I​deogram 4.0が0.44、Nano Banana ProとSeedream 5.0 Proが0.33、Q​wen Image 3.0 Proが0.31、GPT Image 2が0.30で、Layout AUCは0.70、比較対象群は0.16〜0.20の範囲にある。これらの数値が再現に耐えるなら、正確なオブジェクト配置こそ、このモデルが実際に持つ能力である。

RealLayoutArenaのエンドツーエンドでは、MOSS-Imageは1698.70 Elo、95%信頼区間は1655.96～1741.43で、総合2位となる。1844.35のGPT Image 2に次ぎ、Seedream 5.0 Pro（1661.16）、プロンプト拡張付きのQwen Image 3.0 Pro（1614.84）、Nano Banana Pro（1590.19）を上回る。共有された強化済み自然言語プロンプトの下でバックボーンのみに比較を限定すると、MOSS-Imageが1807.34で首位となり、ERNIE Imageの1748.51、SenseNova-U1の1689.23を上回る。プロンプト戦略のアブレーションは、これを使おうとしている人にとって論文内で最も有用な記述だ。JSONレイアウトプロンプトは1622.87、自然言語プロンプトは同じシステムで1506.20を記録する。レイアウトインターフェースはおまけの機能ではない。性能が宿るのはそこだ。

報告書が自らに投げかける2つの注意点は、繰り返すに値する。LongTextBenchは、現在の強力なモデルにとって飽和に近いと説明されている。これは、ベンダーが古いテストに安住するのではなく、より難しいテストを構築した理由を説明するものだ。そして、エンドツーエンドのEloの信頼区間は何とも重ならないが、人間の評価者が判定した61タスクのアリーナでは広い——85 Eloポイント——。

自分で実行すること、そしてそれにかかるコスト

現在、私たちが確認できる MOSS-Image の商用 API は存在せず、当社のカタログにも載っていません — OrcaRouter は 200 を超えるモデルを提供していますが、MOSS-Image はその一つではないため、ここに書かれている内容を当社がそれを提供していると受け取らないでください。存在するのはセルフホスティングです。すなわち、カスタムパイプラインを使った Diffusers のルート（pipeline_moss_image、diffusers 0.38 以降、transformers 5.3 以降、torch 2.9 以降、Python 3.10 以上）、Gradio アプリ、そして ComfyUI Manager からインストールできるネイティブの ComfyUI プラグインで、公式 ComfyUI リポジトリへの統合は進行中と説明されています。また、エージェントフレームワーク向けのプロンプトエンハンサースキルもあり、これは画像サービスを一切呼び出さずにピクセル座標のドラフトをモデルの中心座標 JSON 形式にコンパイルします — 小さく、しかし本当に役立つツールです。

コミュニティはすでに、ベンダーがやらなかった部分をやってのけた。リリースからおよそ1日のうちに、Hugging Face 上にサードパーティ製ビルドが現れた。Comfy-Org によるモデルのパッケージング、実験的な Kijai ビルド、GGUF 量子化、INT8 および INT4 ConvRot 変換、W4A8 OrbitQuant ビルド、そして——データセンターを持たない人にとって最も有用な——50ステップのデフォルトに正面から挑む4ステップ DMD LoRA と8ステップ蒸留版である。これらはいずれもベンダーサポート外で、ベンチマークもされていないが、リリースが、引用するためではなく実際に使おうとする人々の手に届いたという、いつものシグナルなのだ。

ここがルーティング層の真価が発揮される場面であり、境界線については正確に述べておく価値がある。当社はMOSS-Imageをホストしていないため、それを提供することはできず、そうであるかのような示唆も行わない。当社にできるのは比較のもう半分だ。自前でホストするMOSS-Imageをホスト型の画像モデルと比較したいなら、ホスト型の側には当社のカタログから1つのAPIキーで、プロバイダー定価・マークアップ0%でアクセスできる——つまりホスト型モデルのベンダー価格の変更は、四半期ごとの契約サイクルではなくその日のうちにここへ反映される——しかもプロバイダー間の自動フェイルオーバーと、複数のモデルを単一のエンドポイントの背後に配置できるルーティングDSLを備えている。実績のないチェックポイントをレンタルのものと突き合わせて試すのに、2つ目のSDKを必要とすべきではない。それがここで述べている唯一の主張だ。

この件では誰が動くべきで、誰が待つべきか

あなたの仕事が、特定の位置に正確で判読可能な多言語テキストを含む画像——ポスター、インターフェースのモックアップ、情報カードなど、レイアウトそのものが成果物であって偶然の産物ではないもの——の生成に関わるなら、MOSS-Image はここ一か月で最も直接的に狙いを定めたオープンウェイトのリリースであり、Apache 2.0 ライセンスのおかげで通常の商用レビューは短く済む。SFT チェックポイントから始め、散文ではなく構造化 JSON を渡すことを前提とし、生成器の予算を確保する前にエンコーダの 16.8 GB を見込んでおこう。

今週中に呼び出し可能なエンドポイントが必要なら、キャパシティを所有するのではなく借りているなら、あるいは本格導入する前に独立した数値が欲しいなら、待ったほうがよい。アーキテクチャは、凍結されたエンコーダーと凍結されたVAEを備えたクリーンな単一ストリーム設計で、実行は容易になる。ただし、1ステップにつき2回のフォワードで50ステップというのは実際のサービングコストであり、「5B」というバッジはダウンロード量を過小評価しており、主要なスコアは、サードパーティのモデル上で動作する仕様化ステージを使って、ベンダーがベンダー自身のベンチマークで出したものである。再現を待つか、vLLM-Omniの経路がインストールできる形にマージされるのを待ったほうがよい。

このリリースでは解決しない2つの疑問

モデルのレイアウト制御は、ワークフローの変更を正当化するでしょうか？

それは、意図をボックスと文字列として表現できるかどうかによります。レイアウト JSON はキャンバス中心から測定された絶対ピクセル座標を、bbox_format "yxyx"とともに使用しますが、これは、他のいくつかの最近のレイアウトシステムが採用している相対座標の慣習とは異なります——ベンダーは、絶対ピクセルのほうがマルチ解像度の作業に適していると主張しています。それを採用するには、すでにあるプロンプトロジックを書き直すことになります。そして、書き直しに見合うという唯一の証拠は、ベンダー自身の 7Bench ギャップ（0.88 mIoU 対 0.30–0.44 の競合群）です。それは、その指標を作成した人々によって測定されました。

ファインチューニングの話は、ライセンスが示唆するほどオープンなのか？

一部不明。重みとパイプラインのコードは Apache 2.0 で、Base は LoRA が噛みつく対象を持つように意図的に蒸留されないままにされた――これは本気のコミットメントだ。しかし、レポートの学習レシピ――段階的解像度カリキュラム、ReLAION フィルタリングの判断、Muon–AdamW 分割――はドキュメントであり、公開されたデータではない。また、ファインチューニングのガイダンスは今のところ、具体的な指示（テキストエンコーダは凍結したままにする、ファインチューニングしない）とキャプション用プロンプトから成る。単純な SFT が参照ベース生成と GIF 出力を可能にするという主張は、「乞うご期待」が付された所見として述べられているのであり、今日確認できる結果としてではない。

MOSS-Imageを印象的なリポジトリから定番の選択肢へと押し上げるには3つのことが必要だが、そのいずれもまだ存在しない。著者以外の誰かによるLongLongTextBenchまたはRealLayoutArenaの独立した実行、レビュアーが求めた出力同等性の証拠を伴ってタグ付きリリースにマージされたvLLM-Omniパッチ、そしてコミュニティによる変換だけでなくベンダーのお墨付きを得た数ステップ蒸留チェックポイントである。それまでは、正確な要約はこうだ — 十分に文書化された5B拡散トランスフォーマーで、テキストとレイアウトのインターフェースが異常に強く、コードだけでなく重みもカバーする寛容なライセンスを持ち、自ら作成したテストではベンチマーク首位、エンドツーエンド比較では2位で、サービングの話は実在するものの依然としてオープンなプルリクエストの中にある。

このようなリリースの背景にある、文書化されたAI障害やエージェントのインシデントは、OrcaRouter AI Incident Archiveに収集されており、各エントリには独自の情報源、重大度、信頼度グレード、異議申し立てフラグが付いています。