Microsoft Mage Teamは2026年7月22日、画像生成と画像編集に対応する新しいモデル「Mage-Flow」を公開しました。
Mage-Flowは、数十B規模へモデルを大型化するのではなく、4Bの画像生成モデル、軽量なMage-VAE、ネイティブ解像度処理を組み合わせて、品質と効率の両立を狙ったモデルです。テキストから画像を生成する「Mage-Flow」と、指示文を使って入力画像を編集する「Mage-Flow-Edit」があり、それぞれにBase、RL調整済み、4ステップTurboの3種類が用意されています。
モデルとコードはHugging FaceとGitHubで公開済みです。ComfyUIではネイティブ対応のPRが作成されていますが、2026年7月23日時点ではDraft段階にあり、正式版と公式ワークフローにはまだ収録されていません。
Mage-Flow公式デモ
Hugging FaceのSpacesでTurboとEditのデモが試せます。
Mage-Flowとは
Mage-Flowは、テキストからの画像生成と指示ベースの画像編集を扱う4B規模の生成モデルです。
モデルの中核には、独自の「Mage-VAE」と「NR-MMDiT」が使われています。プロンプトの処理にはQwen3-VLを採用し、画像とテキストを可変長のシーケンスとしてまとめて処理します。
公式が挙げている主な特徴は次の通りです。
- 4B規模の画像生成・編集モデル
- 512～2048ピクセルのネイティブ解像度に対応
- 最大4:1の縦長・横長画像に対応
- 英語と中国語のテキスト描画
- 背景変更、物体の追加・削除、置換、視点変更、スタイル変更
- Canny、深度、HED、法線、セグメンテーションなどの構造画像生成
- Base、RL調整済み、4ステップTurboの3種類
- 1枚の参照画像だけでなく、複数画像を使った編集にも対応
「Mage」という名前は画像生成モデル単体ではなく、Microsoftが展開する軽量マルチモーダルモデル群を指しています。今回公開されたMage-Flowは生成・編集を担当し、画像や動画を理解する「Mage-VL」も別モデルとして予告されています。
生成と編集で合計6種類のモデルを公開
公開されたモデルは合計6種類です。
| モデル | 用途 | 種類 | 推奨ステップ数 |
|---|---|---|---|
| Mage-Flow-Base | テキストから画像生成 | Base | 30 |
| Mage-Flow | テキストから画像生成 | RL調整済み | 20 |
| Mage-Flow-Turbo | テキストから画像生成 | 蒸留版 | 4 |
| Mage-Flow-Edit-Base | 画像編集 | Base | 30 |
| Mage-Flow-Edit | 画像編集 | RL調整済み | 30 |
| Mage-Flow-Edit-Turbo | 画像編集 | 蒸留版 | 4 |
通常の画像生成や編集を試す場合、最も注目されるのは4ステップで動くTurbo版です。Baseは追加学習や研究の土台、RL調整済みモデルは品質重視、Turboは生成時間を抑えた実用向けという位置付けになっています。
Turbo版ではCFG 1.0が使用されます。通常版とBaseではCFG 5.0が基本設定です。
高解像度処理を軽くするMage-VAE
Mage-Flowでは、画像を潜在空間へ変換するVAEにも独自設計が採用されています。
Mage-VAEは、エンコードとデコードをそれぞれ1ステップで処理する拡散ベースのVAEです。潜在空間は128チャンネル、画像は16分の1へ圧縮されます。
学習時にはFLUX.2 VAEの潜在表現を基準として利用しており、公式発表ではFLUX.2 VAEに近い再構成品質を維持しながら、ピクセル当たりの計算量をエンコードで約12分の1、デコードで約22分の1に削減したと説明されています。
高解像度画像ではVAEの処理時間も無視できないため、画像生成モデル本体だけでなく、画像のエンコードとデコードまで含めて軽量化している点がMage-Flowの特徴です。
512～2048ピクセルを同じモデルで処理
Mage-Flowは、512～2048ピクセルの範囲を1つのチェックポイントで処理します。出力サイズは16の倍数で指定し、1024×1024だけでなく、512×2048や2048×512といった最大4:1の構図にも対応します。
一般的な解像度バケットへ画像を揃えるのではなく、画像とテキストを可変長のまま詰める「Native-Resolution Packing」を採用しています。余分なパディングを減らし、画像ごとに異なる解像度やシードを指定したバッチ処理も、デノイズの各ステップでまとめて実行できます。
CFGを使用する場合も、ポジティブとネガティブの処理を1回のForwardへまとめる設計です。
Mage-Flow-Editでできる画像編集
Mage-Flow-Editは、入力画像と指示文を受け取り、内容や見た目を変更する編集モデルです。
公式サンプルでは、次のような編集が紹介されています。
- 背景の変更
- 色や素材の変更
- 被写体や物体の追加、削除、置換
- 数の変更
- 視点や動きの変更
- スタイル変換
- カラー化と画像復元
- Canny、深度、HED、法線、セグメンテーション、スケッチの生成
複数の参照画像も入力できるため、1枚目のシーンへ2枚目の物体を合成するといった編集も想定されています。
編集時には、参照画像がMage-VAEへ高解像度のまま渡される経路と、Qwen3-VLへ縮小して渡される経路があります。公式実装では、Qwen3-VL側へ入力する参照画像の長辺が標準で384ピクセルに制限されています。
4ステップTurboの生成速度
Microsoftの測定では、NVIDIA A100で1024×1024の画像を処理した場合、Mage-Flow-Turboは1枚0.59秒、Mage-Flow-Edit-Turboは1回1.02秒とされています。
| モデル | 処理 | ステップ数 | 公式測定時間 |
|---|---|---|---|
| Mage-Flow-Turbo | 1024×1024画像生成 | 4 | 0.59秒 |
| Mage-Flow-Edit-Turbo | 1024×1024画像編集 | 4 | 1.02秒 |
ピークGPUメモリは約18～20GBです。この結果はA100と公式実装を使用した測定であり、コンシューマーGPUやComfyUIでの速度は実機で確認する必要があります。
公式ベンチマークでは4Bながら大型モデルと競合
画像生成のGenEvalでは、RL調整済みのMage-Flowが0.90、4ステップのMage-Flow-Turboが0.88を記録しています。公式表ではQwen-Imageが0.87、FLUX.2-Klein-9Bが0.86、Z-Image-Turboが0.82です。
画像編集では、Mage-Flow-Edit-TurboがGEdit-Benchで高いスコアを出しています。
| モデル | パラメータ | ステップ | ImgEdit | GEdit-EN | GEdit-CN | TextEdit-Syn | TextEdit-Real |
|---|---|---|---|---|---|---|---|
| Mage-Flow-Edit-Turbo | 4B | 4 | 4.38 | 8.271 | 8.264 | 12.77 | 15.41 |
| Qwen-Image-Edit-2511 | 20B | 50 | 4.51 | 7.877 | 7.819 | 13.53 | 16.81 |
Mage-Flow-Edit-TurboはGEdit-ENとGEdit-CNでQwen-Image-Edit-2511を上回っていますが、ImgEditとTextEditではQwen-Image-Edit-2511の方が高い結果です。
ベンチマークはMicrosoft側が掲載した数値です。被写体の保持、人物の一貫性、細部の維持、日本語の指示理解など、実際の編集品質は用途ごとに確認する必要があります。
4Bでもダウンロード容量は約17.5GB
Hugging Faceで公開されている各モデルの総容量は約17.5GBです。画像生成と画像編集のモデルを1種類ずつダウンロードする場合、合計容量は約35GBになります。
4Bという数字は主に画像を生成するTransformer部分の規模を示しており、配布リポジトリにはQwen3-VLベースのテキストエンコーダー、Mage-VAE、Schedulerも含まれます。そのため、「4Bだからモデル一式も8GB程度」とはなりません。
モデルはBF16で公開されています。公式測定でもピークGPUメモリが18～20GBとされているため、16GB VRAM環境での動作や速度は、ComfyUIのモデルオフロードや今後公開される軽量版の状況に左右されます。
現在はPython、CLI、Gradioから実行可能
公式リポジトリには、Python API、コマンドライン、GradioベースのWeb UIが用意されています。
再現性を重視した公式のテスト環境は、PyTorch 2.13、Transformers 5.5、Diffusers 0.38などを使用しています。FlashAttention 2.8.3は別途ビルドする構成で、PyTorchとCUDA Toolkitのメジャーバージョンを揃える必要があります。
既存の画像生成環境へ依存関係を追加すると、PyTorchやTransformersの構成が変わる可能性があります。ComfyUIの安定環境で試す場合は、ネイティブ対応と公式ワークフローが公開されてから導入方法を確認する方が安全です。
ComfyUIはネイティブ対応を開発中
ComfyUIでは、Kijai氏によるネイティブ対応PR「feat: Support MageFlow」が2026年7月22日に作成されています。
PR番号は「#15026」で、2026年7月23日時点ではDraftです。ComfyUIの正式リリースにはまだ含まれておらず、公式ワークフローテンプレートと公式ドキュメントも未公開です。
対応コードがComfyUI本体へ提出されており、すでに実装作業へ進んでいます。PRがマージされた後、ComfyUIの正式版とワークフローテンプレートへ反映されれば、カスタムノードを使わずに動かせる可能性があります。
現時点では、PRブランチを既存のComfyUI環境へ手動で取り込むより、正式対応を待ってから別環境またはバックアップを用意して試すのが安全です。
ライセンスはMITだが研究目的の注意書きがある
GitHubとHugging Faceのライセンス表示はMITです。
ただし、MicrosoftのGitHub READMEには「研究目的で公開しており、製品やサービスへの展開を意図していない」と記載されています。学習データには公開データ、ライセンスされたデータ、内部データが含まれ、Web規模のデータに由来する偏りや不適切な出力の可能性についても説明されています。
ライセンス欄だけを見て「商用利用可能」と断定するのではなく、製品やサービスへ組み込む場合は、READMEのResponsible AI欄と最新の利用条件を合わせて確認する必要があります。
Mage-Flowは実用的な軽量モデルになるか
Mage-Flowは、4B規模の画像生成モデル、軽量なMage-VAE、ネイティブ解像度処理を組み合わせ、画像生成と画像編集を効率よく実行することを狙ったモデルです。
特に4ステップのMage-Flow-TurboとMage-Flow-Edit-Turboは、生成時間を抑えながら大型モデルと競合する公式ベンチマークを示しています。背景変更や物体編集だけでなく、構造画像の生成や複数画像編集まで1つの編集モデルで扱える点も注目されます。
現状のモデル一式は約17.5GBで、公式測定のピークGPUメモリは18～20GBです。4Bという規模だけで低VRAM向けと判断せず、ComfyUI正式対応後にコンシューマーGPUでの生成時間、メモリ使用量、編集品質を確認したいモデルです。
関連リンク
