この記事について（広告・アフィリエイトリンクはありません）
紹介しているソフトとモデルは、すべて無料で入手できるものです。検証の記録に、試した環境の一覧があります。
画像を作るだけなら、MOSS-Image-heal に替える理由は今回の検証では見つかりませんでした。 元の Base は --fp16-unet でも黒つぶれや破損を起こさず、生成時間も同じです。
MOSS-Image-heal は、MOSS-Image の Base を作者の KBlueLeaf さんが学習し直したモデルです。内部の値の極端なスパイクを小さくして、fp16 で扱いやすくすることが目的で、公式値では最大値が 58,411 から 3,083 に下がっています。効き目があるのは、主に fp16 を使う学習の場面と考えられます。
先に結論（今回のテスト条件で）
| 項目 | 結果 |
|---|---|
| Base の fp16 での破損 | 再現せず（--fp16-unet で9枚） |
| 生成時間（int8、1024×1024） | Base 5.6秒、heal 5.5秒 |
| 生成時間（bf16） | Base 14.5秒、heal 14.5秒 |
| VRAM ピーク | int8 約12.6〜12.7GB、bf16 17.2GB（Base と heal でほぼ同じ） |
| 絵 | 同じシードでも変わる。少し暗めで、看板の文字が崩れた回があった |
Base と heal の計63枚（SFT の9枚は含みません）で、真っ黒や全面ノイズの画像は1枚もありませんでした。
- 普通に画像を作るなら、公式テンプレートの SFT のままで十分です。
- Base で LoRA を学習する人なら、heal は候補になります。ただし学習は今回試していません。
fp16 で壊れなかった理由は？
3つのプロンプトとシード3つで、Base と heal を同じ条件で作りました。
作者の報告を読むと、これは矛盾していません。Base の内部の最大値は fp16 の上限 65,504 に迫りますが、作者の計測でも Base に非有限の値は0個です。 下の表の 58,411（余裕 1.12 倍）は bf16 で計算したときの値です。fp16 で計算した別の計測では最大 61,696 で、上限との差は約6%でした。上限まで余裕が少ないのが問題で、推論でいつも壊れるわけではありません。
| 項目（公式値） | Base | heal |
|---|---|---|
| 内部の最大値 | 58,411 | 3,083 |
| fp16 の上限までの余裕 | 1.12倍 | 21.2倍 |
| 全体の大きさ（RMS の平均） | 27.75 | 3.70 |
| 元モデルとの速度ベクトルの一致 | 1 | 0.9983 |
条件によっては Base が壊れる可能性は残ります。今回の 1024×1024、9枚では起きなかった、というのが正確なところです。
同じシードでどのくらい絵が変わる？
作者の数字は「出力は Base に近い」としていますが、同じシードでも画像としては別物に近くなります。 Base と heal の PSNR は中央値 17〜18dB で、構図から変わる回があります。PSNR は差の小ささを表す値で、大きいほど近い画像です。
| 比べた組み合わせ（同じシード、9組） | PSNR（最小〜最大、中央値） |
|---|---|
| Base と heal（bf16） | 9.8〜21.0dB、18.3dB |
| Base と heal（int8） | 9.4〜21.7dB、17.0dB |
| 同じモデルの bf16 と int8（Base） | 18.6〜28.9dB、27.0dB |
| 同じモデルの bf16 と int8（heal） | 19.0〜34.6dB、27.0dB |
同じモデルの bf16 と --fp16-unet（heal） | 22.3〜37.8dB、27.9dB |
精度を変えるより、Base と heal を替えたときのほうが大きく変わります。Base で作った画像をシードで再現したい人は、替えないでください。
イラストでは、heal のほうが淡く、髪や服の線が柔らかく見えました（筆者の見立て）。
看板の文字は崩れやすかった
MOSS と書かれた看板を描く指定で、Base は3シードとも文字が読めました。heal は崩れる回があります。
| 精度 | Base で読めた枚数 | heal で読めた枚数 |
|---|---|---|
| int8 | 3 / 3 | 1 / 3 |
| bf16 | 3 / 3 | 2 / 3 |
--fp16-unet | 3 / 3 | 2 / 3 |
読めたかどうかは私の判断で、シード3つだけの結果です。マグカップの KOBO Lab は、どちらも全部読めました。作者の説明では、heal は danbooru の画像約100万枚で学習し直されています。文字の差との関係は確かめていません。
SFT と比べると？
ComfyUI の公式テンプレートが使うのは SFT で、Base とも heal とも別の仕上げです。比べると、SFT のほうが細部がはっきりしています。鮮明さの値（ラプラシアン分散の平均）は SFT 522、Base 264、heal 267 でした。
時間とメモリの実測
1024×1024、25 ステップ、CFG 2.5、er_sde、simple です。テキストエンコーダーはテンプレートと同じ w4a8 で、読み込み後の時間です。各9枚です。
| モデル | 精度 | 1枚 | 1ステップ | VRAM ピーク（全体） |
|---|---|---|---|---|
| Base | int8 | 5.6秒 | 0.21秒 | 12.7GB |
| heal | int8 | 5.5秒 | 0.21秒 | 12.6GB |
| SFT | int8 | 5.5秒 | 0.21秒 | 12.6GB |
| Base | bf16 | 14.5秒 | 0.57秒 | 17.2GB |
| heal | bf16 | 14.5秒 | 0.57秒 | 17.2GB |
| Base | --fp16-unet | 14.6秒 | 0.57秒 | 17.5GB |
| heal | --fp16-unet（fp16 ファイル） | 14.6秒 | 0.58秒 | 17.2GB |
速さとメモリの差はありません。fp16 にしても bf16 と同じ時間でした。前回の MOSS-Image の記事の値（int8 で約5.8秒）とも近い結果です。
heal_fp16 のファイルは要る？
今回は bf16 ファイルで足りました。 同じ --fp16-unet で moss_image_heal_bf16 と moss_image_heal_fp16 を比べると、9枚すべて完全に同じ画像でした。ファイルの中身を比べると、379 個のうち 378 個のテンソルが、bf16 を fp16 に変換した値と一致しています。残りの1個がどのテンソルで、どう違うかは記録していません（未確認）。
導入の手順
- ComfyUI を 0.42.0 以上にします（アップデートの方法）。今回は v0.44.0 です。
- 下のモデルを
models\diffusion_modelsに置きます。テキストエンコーダーと VAE は MOSS-Image のものをそのまま使います。 - テンプレートの MOSS-Image の Load Diffusion Model で、heal のファイルを選びます。
| ファイル | サイズ | 用途 |
|---|---|---|
| moss_image_heal_int8_convrot.safetensors | 5.4GB | 迷ったらこれ |
| moss_image_heal_bf16.safetensors | 10.2GB | bf16 で動かす |
| moss_image_heal_fp16.safetensors | 10.2GB | --fp16-unet で動かす |
| qwen3.5_9b_w4a8_gptq.safetensors | 7.3GB | models\text_encoders |
| flux2-vae_small.safetensors | 0.25GB | models\vae |
比較に使った Base は moss_image_base_int8_convrot と moss_image_base_bf16 です。
- moss_image_heal_int8_workflow.jsonComfyUI にドラッグして読み込みます（heal int8、1024×1024、25 ステップ、CFG 2.5。カスタムノードは不要です）
画面から実行して、成功を確かめました。カスタムノードは使っていません。
fp16 で動かすときは、起動時に --fp16-unet を付けます。
python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build --fp16-unetRTX 5090 以外の人へ
--reserve-vram を変えて、heal int8 を各9枚作りました。待機中の VRAM は約1.9GB です。
--reserve-vram | 結果 | 1枚 | VRAM ピーク（全体） |
|---|---|---|---|
| 指定なし | 9枚とも成功 | 5.5秒 | 12.6GB |
| 20 | 9枚とも成功 | 5.5秒 | 12.6GB |
| 24 | 9枚とも成功 | 5.5秒 | 10.1GB |
VRAM 容量が少ない環境を想定した簡易テストです。実際の 8GB・12GB 搭載 GPU での動作を再現・保証するものではありません。 使う VRAM を絞っても時間は変わりませんでした。RAM は ComfyUI だけで約14GB です。
VRAM が足りないときの全般の対処はこちらにまとめています。
商用で使うときの条件は？
heal のカードは Apache-2.0 で、「公式の MOSS-Image の重みと同じ」と書かれています。元の OpenMOSS-Team/MOSS-Image-Base と Comfy-Org/MOSS-Image のカードも Apache-2.0 で、一致しています（2026年11月5日に確認）。
一方で、作者の説明では、heal は danbooru の画像で学習し直されています。カードのライセンスは重みの条件で、学習データに含まれる作品の権利まで扱うものではありません。作品の雰囲気を真似る使い方には、別の注意が要ります。
よくある質問（FAQ）
Q. MOSS-Image-heal で画質は良くなりますか？
今回の3プロンプトでは、はっきり良くなったとは言えません。同じシードでも絵が変わり、看板の文字は崩れる回がありました。
Q. MOSS-Image を fp16 で動かすと黒くなりますか？
今回の Base では9枚とも黒くなりませんでした。ただし公式値では上限までの余裕が小さいので、ほかの条件で起きないとは言い切れません。
Q. heal は速いですか？
速さは Base と同じでした。int8 で1枚約5.5秒、bf16 で約14.5秒です。
Q. SFT と heal はどちらがいいですか？
画像を作るなら、公式テンプレートの SFT を勧めます。今回は SFT のほうが細部がはっきりしていました。
Q. LoRA は使えますか？
手元に合う LoRA がなく、未確認です。
Q. ライセンスは商用利用できますか？
カードは Apache-2.0 で、元の MOSS-Image と同じです。
まとめ
--fp16-unetでも Base は壊れず、heal で時間も VRAM も変わりませんでした。- 同じシードでも絵は変わります。普通に画像を作るなら SFT のままで十分です。
heal の本来の価値は、fp16 を使う学習のほうにあるはずです。今回は推論だけなので、その部分は確かめていません。
検証メモ
- 本数：プロンプト3種とシード3つの9枚を、Base と heal の int8、bf16、
--fp16-unet、SFT の int8 で作りました。Base は 27 枚、heal は 36 枚、SFT は9枚です。「計63枚」は Base と heal の合計です。 --fp16-unetの Base：Comfy-Org に Base の fp16 ファイルはないので、bf16 のファイルを--fp16-unetで動かしました。- サンプラー：ComfyUI のテンプレートの設定です。作者の比較（16 ステップ、CFG 3、shift 5）とは違います。
- 黒つぶれの見方：全画像を目で見て、画素の統計も取りました。明るさの差（標準偏差）が最小でも 32 あり、一色の画像はありません。
- 文字の判定：私が目で読めるかを見た結果です。シード3つでは傾向の目安にしかなりません。
- 未確認のこと：LoRA の併用、MOSS-Image の編集モデルとの組み合わせ、学習、1024×1024 以外、ほかの GPU、作者の設定（16 ステップ）。
