見出し画像

ComfyUIのモデル格納場所、checkpointとunetの違いって何？

まぐろラボ

ComfyUIを使っていると、モデルファイルをダウンロードするたびに必ず突き当たる疑問があります。「これ、`checkpoints`フォルダに入れればいいの？それとも`unet`フォルダ？」というやつです。

Civitaiで拾ってきたSDXL系のモデルは`checkpoints`にポン、で動くのに、Anima系のモデルを持ってくると急に`unet`というフォルダの存在に気づかされる。両方とも「モデルファイル」なのに、なぜ置き場所が違うのか。今回はここを初心者目線で整理してみます。

checkpointとは「全部入り」のファイル

まず結論から言うと、checkpoint（チェックポイント）とは、画像生成に必要な3つの要素をひとつのファイルにまとめて詰め込んだものです。

  • MODEL（UNet）：ノイズ除去の本体。実際に画像を生成する計算を担う部分

  • CLIP（テキストエンコーダー）：プロンプトの文章を、モデルが理解できる数値表現に変換する部分

  • VAE：モデル内部の潜在表現と、実際に見える画像（ピクセル）を相互変換する部分

Stable Diffusion 1.5やSDXL、CivitAIにあるJuggernaut XLやPony Diffusionのようなモデルは、基本的にこの3点セットを1つの`.safetensors`ファイルに固めて配布しています。だからこそComfyUIの「Load Checkpoint」ノードひとつを置くだけで、MODEL・CLIP・VAEの3つの出力が一気に得られるわけです。置き場所は`ComfyUI/models/checkpoints/`。これが「全部入り」方式です。

unet（diffusion_models）は「本体だけ」

一方で、比較的新しいDiT（Diffusion Transformer）系のモデルの中には、事情が異なるものがあります。たとえばアニメ特化モデルのAnima（CircleStone LabsとComfy Orgが共同開発した2BパラメータのモデルでNVIDIA Cosmosをベースにしています）は、MODEL・CLIP・VAEをそれぞれ別ファイルとして配布しています。

このうち「MODEL（UNet）」の部分だけを置く場所が`ComfyUI/models/unet/`、もしくは新しめのComfyUIでは`ComfyUI/models/diffusion_models/`です（どちらのフォルダ名でも認識されるようになっています）。

Animaのワークフローを開くと、ノードの構成がSDXLよりも賑やかになっているのに気づきます。

  • UNETLoader（Load Diffusion Model）：`unet`（`diffusion_models`）フォルダからAnimaの拡散モデル本体（`anima-base-v1.0.safetensors`など）だけを読み込む

  • CLIPLoader：`text_encoders`フォルダからテキストエンコーダー（Qwen3-0.6Bの`qwen_3_06b_base.safetensors`）を読み込む

  • VAELoader：`vae`フォルダからVAE（`qwen_image_vae.safetensors`）を読み込む

つまり「Load Checkpoint」が1ファイル・1ノードで3点セットを済ませるのに対し、こちらは3ファイル・3ノードに分かれて同じ役割を果たしている、という違いです。ノードの数が増えている理由はここにあります。

なぜこんな面倒な分け方になっているのか

正直、最初は「なぜ最初から全部入りにしないんだろう」と思いました。ですが調べてみると、いくつか合理的な理由がありそうです。

1つは、テキストエンコーダーやVAEを他のモデルと共有できるという点です。Animaの場合、テキストエンコーダーにはQwen3-0.6B、VAEにはQwen-Image用のVAEがそのまま使われています。これは他のQwen系列のモデルとも共通のパーツなので、MODEL部分だけを独立させておけば、CLIPやVAEを複数のモデル間で使い回せます。全部入りのcheckpoint形式にしてしまうと、似たようなCLIPやVAEを毎回モデルサイズ分だけ重複して抱え込むことになってしまいます。

もう1つは、量子化（クオンタイズ）との相性です。以前このアカウントでも書いたGGUF形式は、まさにMODEL（UNet）部分だけを軽量化する技術で、これも置き場所は`models/unet`。MODELだけを差し替え可能な形にしておくことで、「CLIPとVAEはそのまま、MODELだけ軽量なGGUF版に差し替える」といった柔軟な運用がしやすくなっています（Anima自体は2Bパラメータとコンパクトなモデルなので必須ではありませんが、Flux系のような大型DiTモデルではこの恩恵が大きくなります）。

MacBook Air M3(24GB)ユーザーとしての実感

ここが個人的に一番興味があったポイントです。ユニファイドメモリ24GBというそこまで潤沢ではない環境で作業していると、「今どのパーツがメモリに乗っているか」を意識せざるを得ません。

checkpoint方式は、Load Checkpointノードを1つ置くだけで済むお手軽さがある一方、MODEL・CLIP・VAEがワンセットで固定されてしまいます。それに対してunet方式は、MODEL部分だけを差し替えたり、CLIPやVAEを別モデルと共有したりといった「必要な部分だけ入れ替える」調整がしやすい構造になっています。

実際、手元の環境でAnimaのワークフローを組むときは、`models/diffusion_models`にAnimaの拡散モデル本体を、`models/text_encoders`にQwen3のテキストエンコーダーを、`models/vae`にQwen-Image VAEを、それぞれ個別に配置する形になりました。ファイルの置き場所を間違えると、対象のノードのドロップダウンにそもそも出てこないので、「認識されない」＝「壊れている」ではなく「フォルダを見ていない」だけ、というのは実際に何度かハマってから気づいた点です。

まとめ

  • checkpoint：MODEL・CLIP・VAEを1ファイルに同梱した「全部入り」形式。置き場所は`models/checkpoints/`。SD1.5やSDXL系で主流

  • unet（diffusion_models）：MODEL（UNet）だけを単体で持つ形式。置き場所は`models/unet/`または`models/diffusion_models/`。Animaのような比較的新しいDiT系モデルで採用されている

  • Animaの場合、テキストエンコーダー（Qwen3-0.6B）とVAE（Qwen-Image VAE）も別ファイルなので、CLIPLoader・VAELoaderと組み合わせて使う必要がある

  • ファイルを間違ったフォルダに置いても壊れるわけではなく、単に対象ノードの選択肢に出てこないだけ

  • ユニファイドメモリ環境では、MODEL部分だけを差し替えたり他のモデルとCLIP/VAEを共有したりできるunet方式のほうが、メモリ配分の調整がしやすい印象

「checkpointかunetか」で迷ったら、まず配布元がどういう形でファイルを分けているかを確認するのが一番の近道です。フォルダの意味さえ理解しておけば、新しいモデルが出るたびに慌てずに済みそうです。

#ComfyUI #AI画像生成 #Anima #checkpoint #UNet #GGUF #macOS #生成AI初心者

いいなと思ったら応援しよう！