WAN 2.1で動画生成を試みたとき、出力が緑がかったブロックノイズのような壊れた画像になった経験はないでしょうか。この問題の原因は、テキストエンコーダーの種類の間違いとFP8量子化の非互換性の組み合わせにあります。
原因①：テキストエンコーダーのアーキテクチャが違う
よく混同されるのが、以下の2つのエンコーダーです。
| モデル | 使うT5エンコーダー |
|---|---|
| FLUX | T5-XXL（標準） |
| WAN 2.1 | umt5-XXL（UniMax T5、別アーキテクチャ） |
t5xxl_fp8_e4m3fn.safetensors は主に FLUX向け に配布されているファイルです。WAN 2.1が期待する umt5-xxl とはアーキテクチャが異なるため、テキスト埋め込みの次元やAttentionの構造が合わず、エンコーダーの出力が壊れます。
原因②：FP8 e4m3fn の数値表現の問題
FP8 e4m3fn は非常に狭いダイナミックレンジ（約 -448 〜 +448）しか持ちません。
- FP16：約 ±65,504
- BF16：約 ±3.4×10³⁸
- FP8 e4m3fn：約 ±448（極端に狭い）
WANのランタイムがFP8のスケールファクターや exponent bias を正しく解釈しない場合、逆量子化時にオーバーフロー・アンダーフローが発生し、テンソル値が破綻します。
なぜ「緑のブロックノイズ」になるのか
壊れたテキスト埋め込みがlatent空間の破綻した値（NaN・Inf・極端な値）を生み出し、VAEデコーダーがそれを無理やりRGB変換する際に、latentの特定チャンネルが緑〜シアン系にマッピングされます。これが緑のブロックノイズとして現れる原因です。
解決策：WAN用の正しいエンコーダーを使う
✅ 推奨ファイル一覧
| ファイル名 | 用途 | 使えるか |
|---|---|---|
| t5xxl_fp8_e4m3fn.safetensors | FLUX用 T5-XXL | ❌ WAN不可 |
| umt5_xxl_fp8_e4m3fn_scaled.safetensors | WAN公式リパッケージ | ✅ |
| umt5-xxl-enc-fp8_e4m3fn.safetensors | Kijai/WanVideoWrapper用 | ✅ |
| models_t5_umt5-xxl-enc-fp8.pth | WAN公式 PyTorch版 | ✅ |
| umt5_xxl_bf16.safetensors | WAN公式 BF16版（高品質） | ✅ |
入手先
- Comfy-Org公式リパッケージ版（safetensors形式）
Comfy-Org/Wan_2.1_ComfyUI_repackaged（Hugging Face）
→split_files/text_encoders/umt5_xxl_fp8_e4m3fn_scaled.safetensors（約6.74 GB） - WAN公式PyTorch版
models_t5_umt5-xxl-enc-fp8.pth（Alibaba/通义 公式リリース） - Kijai版（WanVideoWrapper向け）
Kijai/WanVideo_comfy（Hugging Face）
配置先（ComfyUIの場合）：ComfyUI/models/text_encoders/
VRAMを節約したい場合
- BF16版：約13GB → 精度は最高
- FP8版：約6.7GB → バランスが良く推奨
- GGUF版（Q4相当）：約3〜4GB →
calcuis/wan-ggufで入手可能
まとめ
T5-XXL（FLUX用）と umt5-XXL（WAN用）は名前が似ていても別のアーキテクチャです。間違ったエンコーダーを読み込ませると、テキスト埋め込みが完全に壊れ、緑のブロックノイズとして出力されます。
FP8で軽量化したい場合でも、WAN向けに量子化されたumt5のFP8ファイルを使えば問題なく動作します。ファイル名に umt5 が含まれているかを必ず確認しましょう。
