メインコンテンツへスキップ

モデルアーキテクチャの不一致

症状: 生成過程中にテンソル次元エラーが発生する、特に VAE デコード段階 一般的なエラーメッセージ:
  • Given groups=1, weight of size [64, 4, 3, 3], expected input[1, 16, 128, 128] to have 4 channels, but got 16 channels instead
  • Given groups=1, weight of size [4, 4, 1, 1], expected input[1, 16, 144, 112] to have 4 channels, but got 16 channels instead
  • Given groups=1, weight of size [320, 4, 3, 3], expected input[2, 16, 192, 128] to have 4 channels, but got 16 channels instead
  • The size of tensor a (49) must match the size of tensor b (16) at non-singleton dimension 1
  • Tensors must have same number of dimensions: got 2 and 3
  • mat1 and mat2 shapes cannot be multiplied (154x2048 and 768x320)
根本原因: 異なるアーキテクチャファミリーのモデルを混合して使用している

解決策

  1. モデルファミリーの互換性を確認する:
    • Flux モデルは 16 チャンネルの潜在空間を使用し、デュアルテキストエンコーダー条件付け(CLIP-L + T5-XXL)を伴います
    • SD1.5 モデルは 4 チャンネルの潜在空間を使用し、単一の CLIP ViT-L/14 テキストエンコーダーを伴います
    • SDXL モデルは 4 チャンネルの潜在空間を使用し、デュアルテキストエンコーダー(CLIP ViT-L/14 + OpenCLIP ViT-bigG/14)を伴います
    • SD3 モデルは 16 チャンネルの潜在空間を使用し、トリプルテキストエンコーダー条件付け(CLIP-L + OpenCLIP bigG + T5-XXL)を伴います
    • ControlNet モデルはベースチェックポイントのアーキテクチャに一致する必要があります(SD1.5 ControlNet は SD1.5 チェックポイントとのみ動作し、SDXL ControlNet は SDXL チェックポイントとのみ動作しますなど)
  2. 一般的な不一致シナリオと修正: Flux + 誤った VAE:
    問題:Flux チェックポイントで taesd または sdxl_vae.safetensors を使用している
    修正:Hugging Face Flux リリースから ae.safetensors(Flux VAE)を使用する
    
    Flux + 不正確な CLIP 設定:
    問題:DualClipLoader の両方の CLIP スロットで t5xxl_fp8_e4m3fn.safetensors を使用している
    修正:一方のスロットで t5xxl_fp8_e4m3fn.safetensors を使用し、もう一方のスロットで clip_l.safetensors を使用する
    
    ControlNet アーキテクチャの不一致:
    問題:SD1.5 ControlNet を SDXL チェックポイントで使用している(またはその逆)
    エラー:"mat1 and mat2 shapes cannot be multiplied (154x2048 and 768x320)"
    修正:チェックポイントアーキテクチャ用に設計された ControlNet 模型を使用する
         - SD1.5 チェックポイントには SD1.5 ControlNet が必要
         - SDXL チェックポイントには SDXL ControlNet が必要
    
  3. 迅速な診断:
    # エラーが VAE デコード段階で発生するか確認する
    # "expected input[X, Y, Z] to have N channels, but got M channels" を探す
    # Y 値はチャンネル数を示す:4 = SD 模型,16 = Flux 模型
    
  4. 予防戦略:
    • すべてのワークフローモデルを同一のアーキテクチャファミリー内に保つ
    • 同じソース/リリースから完全なモデルパッケージをダウンロードする(多くの場合、Hugging Face リポジトリ内にすべて存在する)
    • 新しいモデルを試す際は、カスタマイズ前にテンプレートワークフローまたは公式 ComfyUI ワークフロー例から開始する

モデル不足エラー

エラーメッセージ例:
Prompt execution failed
Prompt outputs failed validation:
CheckpointLoaderSimple:
- Value not in list: ckpt_name: 'model-name.safetensors' not in []

解決策

  1. 必要なモデルをダウンロードする:
    • ComfyUI Manager を使用してモデルを自動ダウンロードする
    • モデルが正しいサブフォルダにあることを確認する
  2. モデルパスを確認する:
    • チェックポイント: models/checkpoints/
    • VAE: models/vae/
    • LoRA: models/loras/
    • ControlNet: models/controlnet/
    • 埋め込み: models/embeddings/
  3. UI 間でモデルを共有するか、カスタムパスを使用する:

モデル検索パス設定

モデルをカスタム場所に配置している場合、ComfyUI がそれらを見つけるように設定するための詳細ガイド ComfyUI モデルの共有とカスタムモデルディレクトリ設定 を参照してください。

モデル読み込みエラー

エラーメッセージ: “Error while deserializing header”

解決策

  1. モデルを再ダウンロードする - ダウンロード過程中にファイルが破損している可能性があります
  2. 利用可能なディスク容量を確認する - モデル読み込みのに十分な容量があることを確認する(モデルは 2-15GB 以上の場合があります)
  3. ファイル権限を確認する - ComfyUI がモデルファイルを読み取れることを確認する
  4. 異なるモデルでテストする - 問題がモデル固有のものかシステム全体のものかを確認する

モデルパフォーマンス問題

モデル読み込みが遅い

症状: モデルの切り替えや生成開始時に長時間の遅延が発生する 解決策:
  1. より高速なストレージを使用する:
    • HDD を使用している場合、モデルを SSD に移動する
    • 最高のパフォーマンスには NVMe SSD を使用する
  2. キャッシュ設定を調整する:
    python main.py --cache-classic       # 旧式(積極的)キャッシュを使用する
    python main.py --cache-lru 10         # LRU キャッシュのサイズを増やす
    

大型モデルにおけるメモリ問題

“RuntimeError: CUDA out of memory”:
# 段階的なメモリ削減
python main.py --lowvram          # 最初に試す
python main.py --novram           # lowvram が不十分な場合
python main.py --cpu              # 最後の手段
モデル固有のメモリ最適化:
# 低い精度を強制する
python main.py --force-fp16

# アテンションメモリの使用量を削減する
python main.py --use-pytorch-cross-attention
追加のモデル設定とセットアップ情報については、モデルドキュメント を参照してください。