Apple Siliconでローカル生成AIを動かすと、FP8チェックポイントの読み込み時にFloat8_e4m3fnや未対応dtypeのエラーで停止することがあります。この時、メモリ不足、モデル破損、ComfyUIの不調を一度に疑うと、必要のない再インストールやモデル追加へ進みがちです。
結論：エラーの型を固定し、BF16代替を同じ条件で測る
FP8を使わない、だけで終わらせず、どのファイルをどのバックエンドへ載せた時に失敗したかを記録します。そのうえでBF16本体へ替え、同じプロンプト、seed、解像度、step、参照枚数で成功率、処理時間、推定最大メモリ、出力品質を比較します。動く構成を最短で選び、将来の更新時にも再検証できる形を残せます。
FP8とBF16は何が違うのか
FP8とBF16は、モデルの重みや計算で使う数値の表現形式です。一般に低いビット幅はファイルやメモリを抑えやすい一方、すべてのハードウェア、バックエンド、演算子が同じdtypeへ対応しているとは限りません。Apple SiliconのGPU処理はMPS経路を使うため、配布ページで「軽量」「FP8」と書かれたモデルでも、そのまま動くとは断定できません。
BF16はFP8より重くなる可能性がありますが、対応する構成では安定して読み込める選択肢になります。ただし、BF16なら必ず成功する、FP8ファイルはすべて使えない、という意味ではありません。モデル本体、テキストエンコーダ、VAE、ローダー、PyTorch、ComfyUIノードの組み合わせを分けて確認します。
最初に保存する5つの情報
- エラー全文と、最初に未対応dtypeが示された行
- モデル本体、テキストエンコーダ、VAEのファイル名と容量
- PyTorch、ComfyUI、カスタムノード、macOSのバージョン
- MPSが利用可能か、CPUへフォールバックしたか
- プロンプト、seed、解像度、step、cfg、参照画像数
環境確認では、PyTorch公式のMPSバックエンド資料にある利用可否チェックも使えます。ここでMPS自体が利用できない場合は、FP8/BF16の比較より先に環境を直します。
エラーを4種類へ分ける
| 症状 | 最初に疑う範囲 | 次の確認 |
|---|---|---|
Float8_e4m3fnなどdtype名が出る | MPSと数値形式の対応 | BF16本体で同じワークフローを試す |
| モデルやノードが見つからない | 配置、ファイル名、ノード定義 | パスとworkflow JSONを確認 |
| 処理中にメモリ不足で停止 | 解像度、参照枚数、モデル容量 | 条件を1つずつ下げる |
| 特定ノードで未実装演算 | MPS演算子の対応 | ノード更新、CPUフォールバック、別経路を比較 |
dtypeエラーが出た時に解像度だけを下げても、読み込み段階で停止しているなら改善しないことがあります。逆にメモリ不足なのにモデル形式だけを替えると、条件が同じでなくなり、何が効いたのか分からなくなります。ログの停止位置を先に見ます。
BF16代替を試す手順
比較ではモデル本体だけをBF16へ替え、その他の条件を固定します。複数ファイルを一度に入れ替えると、成功理由を特定できません。ファイル容量とハッシュも記録し、同名の古いコピーを誤って読み込まないようにします。
- 失敗したFP8構成のworkflowとログを保存する
- 対応するBF16本体を別名で配置し、既存ファイルを上書きしない
- ローダーが選ぶファイルを画面とworkflow JSONの両方で確認する
- テキストだけ、1参照、2参照の順で負荷を上げる
- 各条件で秒数、メモリ、完成画像、エラーを同じ表へ記録する
実測例：本体だけBF16へ替えて成功
同じApple Silicon環境で、公式FP8本体はUndefined type Float8_e4m3fnで停止しました。BF16本体と既存エンコーダの構成では、テキスト生成20.2秒、1参照30.3秒、800×1408pxの2参照編集90.2秒で完了しました。これは特定環境の実測であり、すべてのMacの保証値ではありません。
速度だけでなくメモリと品質も測る
最速の構成が運用に最適とは限りません。参照画像を増やすと処理時間とメモリが増え、低精度化で細部が崩れる場合もあります。少なくとも次の4指標を同じテストで残します。
- 成功率：同じ条件を再実行して完走するか
- 処理時間：キュー投入から完成までの秒数
- 推定最大メモリ：参照枚数と解像度を上げた時の変化
- 出力品質：構図、文字、人物、素材の維持など用途別の合否
生成条件や検証を機械的に残すには、LLMと決定論スクリプトを分ける設計が役立ちます。プロンプトの意味判断と、ハッシュ、秒数、寸法、エラーの記録を別工程にすると、モデル交換後も比較できます。
よくある失敗
- エラー全文を残さず、モデルを次々と入れ替える
- 本体、エンコーダ、VAE、ノードを同時に更新する
- 成功した1枚だけで安定動作と判断する
- 解像度や参照枚数が違う結果を速度比較する
- ファイル名だけを見てFP8/BF16の役割を決めつける
画像の一貫性を評価する場合は、dtypeだけでなく入力条件も固定します。顔、衣装、画質を揃える考え方はAI画像で同じ人物を保つ確認手順も参考になります。
運用構成を決める判断表
| 状態 | 判断 |
|---|---|
| FP8でdtypeエラー、BF16で安定 | BF16を現行構成にし、FP8は対応更新後に再検証 |
| 両方成功、FP8が十分速い | 品質とメモリを比較し、用途別に使い分ける |
| BF16は成功するがメモリが厳しい | 解像度、参照枚数、バッチ数を一つずつ調整 |
| 両方が同じノードで失敗 | dtype以外の演算子・ノード・環境を調べる |
よくある質問
Q. Apple SiliconではFP8モデルを使えませんか？
A. すべて使えないとは限りません。モデル本体、エンコーダ、ローダー、PyTorch、MPS演算子の組み合わせで結果が変わります。エラーにdtype名が出るかを確認し、役割ごとに切り分けてください。
Q. BF16へ替えれば必ず動きますか？
A. 保証はできません。dtypeエラーの代替候補にはなりますが、モデル欠損、未対応ノード、メモリ不足が原因なら別の確認が必要です。同じ条件で小さなテストから進めます。
Q. CPUフォールバックを有効にすれば解決しますか？
A. 未対応演算を回避できる場合はありますが、速度が大きく変わる可能性があります。フォールバックしたことをログへ残し、MPSだけの結果と同じ表に混ぜないでください。
Q. 何回測ればよいですか？
A. 最低でもテキストだけ、1参照、実運用に近い最大参照の3条件を測り、重要な構成は再実行して安定性を確認します。1枚成功だけで採用を決めないことが大切です。
まとめ
Apple SiliconでFP8モデルが動かない時は、エラー全文、ファイルの役割、MPS環境、生成条件を固定します。dtypeエラーならBF16本体を同じ条件で比較し、成功率、秒数、メモリ、品質から運用構成を決めます。モデルを闇雲に追加するより、1要素ずつ替えた記録が次の更新にも使えます。実測条件は後から再現できる粒度で保存してください。
自分で環境を組むか相談したいか迷う場合はACSサービス選択診断、公開中の製品を確認する場合はプラグイン一覧をご覧ください。
この記事は役に立ちましたか？
ありがとうございます！
