5B の MOSS-Image はポスターの中国語を書き切った。ただし画像編集はできない

10月中旬、MOSS-Image というオープンソースモデルが中国語の技術系グループで広まった。広まった理由はきわめて単純だ。ポスター上の中国語を正しく書けるからである。

これは大人が箸を使えることを褒める話に聞こえる。だが、ポスターやインフォグラフィック、EC の商品詳細ページを作ったことがあれば、これがどれほど難しいか分かるはずだ。この2年、私たちは次の流れに慣れてしまっていた。モデルに画像を出させ、画像編集ソフトを開き、モデルが崩した文字を一つずつ塗りつぶして打ち直す。モデルが絵を描き、人間が文字を書く。分業は明確だった。

MOSS-Image が変えようとしているのは、この分業そのものだ。開発は OpenMOSS チーム（復旦大学 NLP と上海創智など）。5B パラメータ、単流 DiT アーキテクチャ、ゼロからの事前学習で、重みは Apache-2.0 で公開されている。

では何を正しくできたのか

公式の評価で最も見る価値があるのは長文テキストのレンダリングだ。テストセットは中国語と英語が各120タスク、目標テキストの平均長は約1339.8文字、評価指標 Mean-6 で96.3を記録した。このスコアはオープンウェイトモデルの中では新高値にあたる。ここでいう「長文」は、見出しの四文字を書くことではない。ひと続きの文章を、改行や段落構造を保ったまま描くことだ。

二つ目はレイアウト。構造化された JSON Layout 入力に対応している。画面を summary と items に分解し、各要素にタイプ、説明、テキスト内容、そして bbox 座標の枠を与えると、モデルはその枠に沿って配置する。このタスクで検出枠の mIoU は 0.8786、全体レイアウトの mIoU は 0.6788。噛み砕けば、要素はおおむね指定した位置に収まるが、全体の構図はデザインソフトのように正確とはいかない。

三つ目はプロンプト長。最大約 4K トークンのプロンプトを受け付ける。この数字はポスターを書く人にとって重い意味を持つ。インフォグラフィックの説明はもともと長いからだ。メインタイトルはどんな書体の印象で、サブタイトルはどの階層で、カラーパレットは何番の色で、左下にどんなアイコンを置くのか。以前はこれを一文に圧縮しなければならなかった。今はそのまま書ける。

導入は難しくない。難しいのは、画像を編集しないことだ

動かす方法はごく普通だ。リポジトリをクローンし、仮想環境を作り、依存関係を入れ、Gradio を呼ぶか Python を直接書く。

クローンして環境を作り依存関係を入れたら、pip install -e '.[ui]' を実行し、そのあと python gradio_app.py --model OpenMOSS-Team/MOSS-Image-Base を走らせれば UI が立ち上がる。Python 側では Diffusers の custom_pipeline で読み込む。サンプリングは既定で Flow-matching Euler、50ステップ、CFG 3、shift 5、さらに22層で負分岐の層スキップを行う。VRAM が足りなければ Sequential モードに切り替えられるが、その代償は速度だ。

本当の問題はここにある。純粋なテキストto画像モデルだということだ。参照画像は受け付けず、ネイティブの編集機能もない。「このポスターのタイトルだけ差し替えたい」はできない。生成し直すしかない。プロンプト拡張モジュールも外部の言語モデルに頼る必要があり、モデル自身はその処理をしない。

これは小さな欠陥ではない。制作物を作る人は、時間の八割を生成ではなく修正に費やしている。クライアントはロゴを2ミリ大きくしろと言い、法務はそのキャッチコピーを削れと言い、運用はこの SKU の色が違うと言う。ゼロから生成するしかないモデルは、こうした人たちを「引き直し」のループに閉じ込める。引き直した2枚目では、構図がまた変わっている。

だから実際のワークフローでは、これは「起点ジェネレーター」に近い。これでレイアウトと文字を一度で正しく作り、書き出し、デザインソフトで微調整する。以前よりは楽だが、終着点ではない。

96.3点はどんな条件で出たのか

数字に引きずられないよう、ここは整理しておきたい。96.3は特定の評価セットで、特定の指標で計算された値で、目標テキストの平均は1339文字。これが証明しているのは「この長さの範囲、この種のレイアウトタスクにおいて、文字の正確さがオープンソースの同業他社より優れている」ことであって、「どんな長さの中国語コピーでも間違えない」ことではない。

さらに公式はモデルカードで自ら限界を記している。backbone は純粋なテキストto画像で、参照画像の入力もネイティブ編集もできず、プロンプト拡張は外部 LLM に依存する。限界を自ら明示する姿勢はオープンソースモデルでは珍しく、記録しておく価値がある。

コミュニティはすでに弱点を補い始めている

公開から2週間も経たないうちに、コミュニティの動きは速かった。DiffSynth-Studio は Base と SFT の両バージョンで全量ファインチューニングと LoRA 学習に対応した。SFT 版に出る縦方向の色帯を抑える DeBand LoRA を作った人もいる。同時に「縞を抑えると細部が変わる」というトレードオフも明示している。8ステップの DMD 蒸留版を作り、ComfyUI の LoRA アダプターと組み合わせた人もいる。

この3つが揃うと、これが「完成品」ではなく「ベースモデル」として扱われていることが分かる。その上で LoRA を学習し蒸留しようとする人がいることは、公開時にどれだけ star を集めたかより、実際の価値をよく示している。

Base と SFT のどちらを選ぶか。公式の比較例では、SFT のほうが文字のグルーピングが明確で、ホワイトボードのレイアウトも整っている。ポスターやインフォグラフィックを作るなら SFT をそのまま使い、自分でファインチューニングしたいなら Base から始めればいい。

今すぐ使うべき人

中国語のポスター、講座のインフォグラフィック、WeChat 公式アカウントの長図、メニュー、案内板を大量に作る仕事で、ローカルに GPU があるなら、半日かけて試す価値はある。こうした需要はレイアウトが固定で文字が多く、再現性が求められる。まさにこのモデルの得意分野だ。

画像の修正、背景の差し替え、既存写真をあるスタイルに変えるといった仕事なら、無理に使う必要はない。できない、あるいは今のツールより手間がかかる。

ドキュメントへのリンクと重みは HuggingFace と ModelScope にあり、Apache-2.0 ライセンスなので商用利用の懸念は少ない。事前に考えておくべきは VRAM とフローだ。Sequential モードは小さな GPU を救うが、「素早く試す」を「お茶を淹れて待つ」に変えてしまう。