技術 約9分で読めます

WAI-Anima v1をRTX 4060 LaptopのComfyUIでAPI経由で動かすまでの記録

AI 画像生成 ComfyUI Windows NVIDIA Stable Diffusion LoRA 実験
いけさん目次

WAI-Illustriousの新版探してたらWAI-Animaが出てたので試したでWAI-Anima v1をM1 Max（64GB統合メモリ）で試したが、RTX 4060 Laptop GPU（VRAM 8GB）のWindows機でも動くのか気になったので試した。

動いた。しかもM1 Maxの275秒に対して55秒。CUDAのほうがDiTの推論には圧倒的に速い。
ただし「Claude CodeからComfyUI APIを叩いてヘッドレスで回す」という横着をしようとしたら、tqdmとComfyUIのLogInterceptorの相性問題で盛大に嵌まった。その顛末も含めて記録しておく。

環境

項目スペック
GPUNVIDIA GeForce RTX 4060 Laptop GPU
VRAM8GB
RAM32GB
OSWindows 11 Home
ComfyUI0.15.0（Portable版）
PyTorch2.10.0+cu128

WAI-Anima v1の公式VRAM要件は8GB。ちょうどギリギリのスペック。

モデルのダウンロード

必要なファイルは3つ。SDXL系のように「チェックポイント1個ポン置き」ではなく、DiTモデル本体・テキストエンコーダ・VAEを個別に配置する。

ファイルサイズ配置先入手元
waiANIMA_v10.safetensors3.9GBmodels/diffusion_models/CivitAI
qwen_3_06b_base.safetensors1.2GBmodels/text_encoders/HuggingFace
qwen_image_vae.safetensors243MBmodels/vae/HuggingFace

HuggingFaceのAnima公式リポジトリではファイルが split_files/ ディレクトリの中にある。URLに注意。

# TE
https://huggingface.co/circlestone-labs/Anima/resolve/main/split_files/text_encoders/qwen_3_06b_base.safetensors

# VAE
https://huggingface.co/circlestone-labs/Anima/resolve/main/split_files/vae/qwen_image_vae.safetensors

トップレベルの text_encoder/ や vae/ を指定すると404になる（LFSポインタの15バイトだけ落ちてくる）。最初これに引っかかって「TEが15バイトしかない」という状況になった。

ComfyUI APIからのヘッドレス実行で嵌まった話

やりたかったことは単純で、ComfyUIをバックグラウンドで起動してAPI経由でワークフローを投げ、生成結果を受け取る。Claude Codeから全自動で回したかった。

CLIPLoaderのtype指定

最初のエラーはワークフローのバリデーション。Anima系のテキストエンコーダを CLIPLoader で読む際、type に "anima" と指定したら弾かれた。

type: 'anima' not in ['stable_diffusion', 'stable_cascade', 'sd3', ...
'qwen_image', 'hunyuan_image', 'flux2', 'ovis']

正解は "qwen_image"。Anima内部のアーキテクチャがQwen系ベースなので、ComfyUI側はそっちの名前で認識している。

tqdmの [Errno 22] Invalid argument

ワークフロー自体は通ったが、KSamplerノードの実行で OSError: [Errno 22] Invalid argument が発生。

File "comfy/k_diffusion/sampling.py", line 1524, in sample_er_sde
    for i in trange(len(sigmas) - 1, disable=disable):
File "tqdm/std.py", line 448, in status_printer
    getattr(sys.stderr, 'flush', lambda: None)()
File "ComfyUI/app/logger.py", line 35, in flush
    super().flush()

ComfyUIの LogInterceptor は io.TextIOWrapper を継承して sys.stderr を差し替えている。tqdmが進捗バーを初期化するとき sys.stderr.flush() を呼ぶが、TextIOWrapper.flush() は内部で underlying bufferの flush() を呼ぶ。バックグラウンド起動でファイルディスクリプタが無効だとここで [Errno 22] が飛ぶ。

試したこと（全部ダメだった）

#試したこと結果
1TQDM_DISABLE=1 環境変数でtqdmをグローバル無効化効かない
2cmd start /min で最小化ウィンドウ起動同じエラー
3PowerShell Start-Process で独立コンソール付き起動同じエラー
4LogInterceptor.flush() にtry/except追加catchされるがComfyUIがエラーとして記録
5LogInterceptor をダック型で書き直し（TextIOWrapper継承をやめる）同じエラー
6tqdm/std.py のstatus_printerを直接パッチcatchはされるがエラーが消えない
7comfy/utils.py のmodel_trangeにdisable=Trueフォールバック追加変わらず

ポイントは、Pythonレベルでは例外がcatchされているのにComfyUIの execution.py がエラーとして記録し続けること。execution.py:602 の except Exception as ex が sys.exc_info() でトレースバックを取得しており、tqdm初期化時に一度でもOSErrorが発生するとその痕跡がexecution engineに伝播する動作に見えた。

解決: 普通に起動する

run_nvidia_gpu.bat をダブルクリックしてComfyUIを普通に起動すればいい。コンソールウィンドウが正規のstdout/stderrを持つため、flush() のOSErrorは起きない。起動さえしてしまえば、API経由のワークフロー投入は問題なく動く。

# ComfyUIが起動済みの状態で
curl -X POST http://127.0.0.1:8188/prompt \
  -H "Content-Type: application/json" \
  -d '{"prompt": { ... }}'

つまり「バックグラウンドで完全自動化」は諦めて「GUIで起動 → APIで操作」にすれば解決。最初の起動だけ手動になるが、以降のワークフロー投入・結果取得は全部API経由で回せる。

生成結果

テスト1: 棒立ち（白背景）

プロンプト: 1girl, solo, long blonde hair, blue eyes, white robe, gold embroidery, capelet, gold sash, long sleeves, long dress, standing, looking at viewer, full body, white background

ネガティブ: lowres, bad anatomy, bad hands, text, error, worst quality, low quality

設定: er_sde / simple / 30steps / CFG 4.0 / seed 42

WAI-Anima v1 棒立ち RTX 4060

白ローブに金の刺繍とサッシュ。プロンプトにかなり忠実な出力。前回のM1 Maxでの結果と同じseed・同じ設定だが、異なるハードウェア（CUDA vs MPS）なので出力は同一にならない。

テスト2: 動的シーン（背景あり）

前回記事と同じプロンプトで比較。

プロンプト: 1girl, solo, long blonde hair, blue eyes, white robe, gold embroidery, capelet, gold sash, long sleeves, long dress, running, wind, hair blowing, dynamic pose, fantasy landscape, castle in background, sunset sky, dramatic clouds, grass field

設定: er_sde / simple / 30steps / CFG 4.0 / seed 42

WAI-Anima v1 動的シーン RTX 4060

夕焼け空・城・草原の構図。前回記事でAnima系の強みとして挙げた「空気感と光の描写」がそのまま出ている。風になびく髪とドレスの動きも自然で、SDXL系では出にくい奥行き感のある背景描写が際立つ。

テスト3: ゴブリンバトル（複数キャラ）

「複数キャラクターを1枚に出せるか」のテスト。WAI-Illustriousだと multiple goblins のような指定で複数体出すのは結構難しい。

プロンプト: 1girl, solo, long blonde hair, blue eyes, white robe, gold embroidery, capelet, gold sash, long sleeves, long dress, casting spell, magic circle, holy light, glowing hands, multiple goblins, green skin, small creatures, dark cave, battle scene, dramatic lighting, fantasy, dynamic pose, full body

設定: er_sde / simple / 30steps / CFG 4.0 / seed 777

WAI-Anima v1 ゴブリンバトル RTX 4060

魔法陣の上で光を放つ聖女と、周囲のゴブリンが複数体ちゃんと出ている。洞窟の暗い背景に青い魔法光のコントラストも良い。
主役の聖女がメインで描かれつつ、ゴブリンはプロンプト通りに背景の群衆として配置されている。Anima系のテキストエンコーダ（Qwen3 0.6B）は0.6Bと小さいわりに「複数の脇役キャラ」の解釈がまともに動く。

テスト4: i2i（棒立ち → 動的ポーズ）

LoRAがない状況で同じキャラクターを別構図に出せるか。テスト1の棒立ち画像をソースにして、動的シーンのプロンプトでi2iをかけた。

元画像（t2i）
元画像
i2i denoise 0.5
i2i 0.5
i2i denoise 0.75
i2i 0.75

プロンプトは running, wind, hair blowing, dynamic pose, fantasy landscape, castle in background, sunset sky と動的シーンを指定しているが、構図はほぼ棒立ちのまま。denoise 0.5では衣装の細部が微妙に変わる程度。0.75に上げると目つきが鋭くなり拳を握り始めて、聖女というよりROのモンクみたいになった。

i2iで構図を大きく変えるのは、元画像の構図が強すぎて難しい。キャラの一貫性を保ちつつ構図を変えたいなら、ControlNetかLoRAが必要になる。Animaは現時点でControlNet未対応なので、LoRA学習ができるAnimaLoraToolkitが事実上の唯一の選択肢。

Qwen Image Editで写真をドット絵に変換できるか試すではIllustrious i2iでドット絵変換するパイプラインを組んだが、今回の結果を見るとAnima系のi2iでは構図が変わらない以前に画風変換自体が弱い。ドット絵変換のような「画風を大きく変える加工」にAnima系のi2iを使うのは現状厳しそう。

生成速度

条件時間
コールドスタート（モデル未ロード）約55秒
ウォーム（モデルロード済み）約52秒
M1 Maxでの同条件約275秒

RTX 4060 Laptop（VRAM 8GB）がM1 Max（64GB統合メモリ）を約5倍上回った。DiTアーキテクチャの推論はCUDAが圧倒的に速い。

コールドとウォームの差がほぼないのは、ComfyUI 0.15.0の「async weight offloading with 2 streams」が効いている。モデルのVRAMロードとサンプリングがオーバーラップして実行されるため、ロード時間が見えにくくなっている。

VRAM 8GBでメモリ不足も出なかった。WAI-Anima v1（3.9GB）+ Qwen3 0.6B TE（1.2GB）+ VAE（243MB）で合計約5.3GB。8GBに収まっている。

おまけ: fp16_accumulation モード

ComfyUI Portable版には run_nvidia_gpu_fast_fp16_accumulation.bat が同梱されている。--fast fp16_accumulation オプションでFP16の累積演算を使い、精度を少し犠牲にして速度を稼ぐモード。RTX 40系はFP16が得意なので効果があるかもしれない。

同じseed・同じ設定で通常モードと比較した。

通常（棒立ち）
通常 棒立ち
fp16_accumulation（棒立ち）
fp16 棒立ち
通常（動的）
通常 動的
fp16_accumulation（動的）
fp16 動的
通常（ゴブリン）
通常 ゴブリン
fp16_accumulation（ゴブリン）
fp16 ゴブリン
モード棒立ち動的ゴブリン
通常55秒52秒55秒
fp16_accumulation51秒47秒48秒

5〜8秒の短縮で、約10%の高速化。画像は同じseedなので構図は同じだが、FP16の丸め誤差で細部が微妙に異なる。品質劣化は目視では判別できないレベル。RTX 4060 Laptopでは速度面のメリットは薄かった。

ComfyUI APIのワークフロー

ブラウザUIを使わずにAPIだけで生成する場合のワークフローJSON。

{
  "1": {
    "class_type": "UNETLoader",
    "inputs": {"unet_name": "waiANIMA_v10.safetensors", "weight_dtype": "default"}
  },
  "2": {
    "class_type": "CLIPLoader",
    "inputs": {"clip_name": "qwen_3_06b_base.safetensors", "type": "qwen_image"}
  },
  "3": {
    "class_type": "VAELoader",
    "inputs": {"vae_name": "qwen_image_vae.safetensors"}
  },
  "4": {
    "class_type": "CLIPTextEncode",
    "inputs": {"text": "プロンプトをここに", "clip": ["2", 0]}
  },
  "5": {
    "class_type": "CLIPTextEncode",
    "inputs": {"text": "ネガティブプロンプト", "clip": ["2", 0]}
  },
  "6": {
    "class_type": "EmptyLatentImage",
    "inputs": {"width": 832, "height": 1216, "batch_size": 1}
  },
  "7": {
    "class_type": "KSampler",
    "inputs": {
      "model": ["1", 0], "positive": ["4", 0], "negative": ["5", 0],
      "latent_image": ["6", 0], "seed": 42, "steps": 30, "cfg": 4.0,
      "sampler_name": "er_sde", "scheduler": "simple", "denoise": 1.0
    }
  },
  "8": {
    "class_type": "VAEDecode",
    "inputs": {"samples": ["7", 0], "vae": ["3", 0]}
  },
  "9": {
    "class_type": "SaveImage",
    "inputs": {"images": ["8", 0], "filename_prefix": "wai-anima"}
  }
}

ノード構成はシンプルで、SDXL系のCheckpointLoaderと違い、UNETLoader + CLIPLoader + VAELoaderの3ノードで個別にロードする。CLIPLoaderの type は "qwen_image" を指定する。

正直なところ、tqdmのOSError問題で1時間以上溶かした。
7回パッチを試してダメだったのは記事ネタとしては面白いが、最初から普通にbatファイルで起動していれば一発で動いていた。
教訓: ヘッドレス実行はComfyUIの想定用途ではない。