コンシューマーGPUで画像生成モデルをスクラッチ学習するには何が必要か
RTX4090級の話から、A100 80GBで「clean-base-v0.1」を作るまで
画像生成AIといえば、既存の大規模モデルを使う、LoRAを作る、あるいはファインチューニングする、という使い方が一般的です。
しかし今回考えたかったのは、もう少し根本的なことでした。
今コンシューマーGPU 1枚、あるいは個人が借りられるGPU環境で、画像生成モデルをスクラッチから作ることはできるのか。
つまり、既存のStable Diffusion系モデルをベースにするのではなく、できるだけ自分で用意したデータと構成で、最初から画像生成モデルを育てることは現実的なのか、という実験です。
きっかけは、以下の記事を読んだことでした。
「コンシューマーGPU1枚で画像生成モデルをスクラッチしよう（前編）」
「コンシューマーGPU1枚で画像生成モデルをスクラッチしよう（後編）」
この2本の記事では、RTX4090 1枚で画像生成モデルをスクラッチ学習する試みが紹介されていました。内容を整理すると、重要なのは次のような点です。
SANA系の軽量アーキテクチャを使う
VAEとテキストエンコーダーは既存のものを使う
まず512pxで学習する
テキストエンコーダーを大きくしすぎない
モデル本体は、動く範囲でできるだけ大きくする
最終的には、モデル構造よりもデータセット品質がかなり重要
特に印象的だったのは、記事の結論がかなり実践的だったことです。
「条件を細かく悩む前に、まずデータセットを見直せ」
「グラボでまともに動く範囲で、できるだけ大きいモデルを使え」
という方向性です。
これは、個人でスクラッチ学習を試す上でかなり納得感があります。
目的：まずは権利的に扱いやすい基盤モデルを作る
今回やりたかったのは、いきなりアニメ特化モデルを作ることではありません。
最初の目的は、権利関係をできるだけ自分で管理しやすい、クリーンな基盤モデルを作ることでした。
そのため、最初からDanbooru系や出所が複雑な画像を使うのではなく、まずは以下のようなデータを中心に考えました。
PD12M
The Met Open Access
Smithsonian Open Access
Wikimedia Commons の CC0 / Public Domain 限定画像
もちろん、実際に使う場合は個別のライセンス確認、人物写真の扱い、商標・ロゴ・有名建築物、NSFW、医療、暴力、子ども画像などの除外が必要です。
ただし方向性としては、まず Public Domain / CC0 / Open Access 系の画像でベースを作る。
その後、必要なら別ラインとしてアニメ特化の追加学習を行う、という考え方にしました。
モデル名も、最初から分けて考えました。
clean-base-v0.1
クリーンな素材を中心にした基盤モデルanime-adapter-v0.1
後から別規約・別データで追加するアニメ向けファインチューニング
この2つを混ぜないことが重要です。
基盤モデルと、用途特化モデルを分ける。
そして規約も分ける。
こうすることで、後から「このモデルは何を学習したものなのか」「商用利用や公開時の条件はどうするのか」を整理しやすくなります。
GPU環境：RunPod の A100 80GB を選んだ
最初は、Vast.ai などのGPUレンタルサービスも候補にしました。
安さだけで見れば Vast.ai はかなり魅力的です。RTX4090、RTX5090、H100、H200 などが比較的安く借りられることがあります。
ただし、スクラッチ学習は短時間の推論とは違います。
数時間ではなく、数日〜数週間レベルで回す可能性があります。
そのため、単純なGPU価格だけではなく、以下が重要になります。
VRAM容量
ストレージ容量
ディスク速度
回線の安定性
中断リスク
環境構築のしやすさ
チェックポイント保存のしやすさ
今回は安さ最優先ではなく、比較的安定した環境で進めるために、RunPod の A100 80GB を使う方針にしました。
A100 80GB は、個人が試すにはかなり強力です。
RTX4090よりVRAMが大きく、学習時の自由度がかなり上がります。
もちろんH100やH200の方が速いですが、まずは検証としてはA100 80GBで十分と判断しました。
実験環境：SANAを使ってスクラッチ学習する
今回の学習には、SANA系の実装を使いました。
完全にゼロから学習コードを書くのではなく、既存のSANAの学習スクリプトやデータローダーを利用しつつ、自分のデータセット・設定・チェックポイント管理を組んでいく形です。
構成としては、だいたい以下のようなイメージです。
アーキテクチャ：SANA系
解像度：まず512px
VAE：SANA系のDC-AE
テキストエンコーダー：既存の軽量寄りモデル
学習方式：flow matching系
最初のデータ：小規模サンプルから開始
最終的な初期目標：PD12Mから10万枚規模
ここで重要なのは、いきなり本番学習に入らないことです。
まずは、環境がちゃんと動くか。
データセットが読めるか。
VAEやテキスト特徴量のキャッシュが作れるか。
1枚画像で過学習できるか。
100枚で回るか。
1万枚で現実的な速度になるか。
このように段階を踏んで確認していきました。
最初の壁：環境構築が普通に重い
実際にやってみると、まず環境構築だけでもかなり時間がかかります。
SANA本体、PyTorch、CUDA、mmcv、diffusion関連、学習スクリプト、依存ライブラリなどを整える必要があります。
途中で、
pip install -e . が長い
train.py --help がなかなか返ってこない
diffusion のimport確認で止まっているように見える
mmcvの警告が出る
ログの見方が分かりづらい
といった場面がありました。
ただ、これは異常というより、かなり重い機械学習環境では普通に起きる範囲です。
特に初回セットアップでは、依存関係のビルドやダウンロードで時間がかかります。
RunPodのようなクラウドGPU環境でも、環境構築に1時間程度かかることは十分あります。
ここで焦って止めたり、別コマンドを重ねたりすると、かえって状態が分からなくなります。
まずは、
torch がCUDAを認識しているか
GPU名が正しく出るか
SANA本体がimportできるか
diffusion関連が読めるか
を順番に確認しました。
結果として、A100-SXM4-80GB 上で PyTorch と CUDA、SANA の起動確認は取れました。
1枚画像で過学習テスト
最初の実験は、1枚画像での過学習テストです。
これはとても重要です。
いきなり10万枚や100万枚で学習を始めても、もし設定が間違っていたら、何日も回した後に失敗に気づくことになります。
1枚画像で過学習できるかを見れば、最低限、
データが読めている
キャプションが読めている
VAEが動いている
テキストエンコーダーが動いている
モデルが学習している
チェックポイント保存ができる
ということを確認できます。
実際に1枚画像の学習では、途中でファイル名の不一致やデータパスの問題も出ました。
しかし、こうした問題を小規模テストで潰せたのは良かったです。
大規模学習に入る前に、小さな失敗を小さく経験しておく。
これはかなり大事だと感じました。
100枚、1万枚へ拡張する
1枚テストの次は、100枚、そして1万枚へ進みました。
この段階で見えてきたのは、キャッシュの重要性です。
画像生成モデルの学習では、毎回その場でVAEやテキストエンコーダーを回すと非常に重くなります。
そのため、事前に以下をキャッシュします。
テキスト特徴量
VAE特徴量
これを作っておくと、学習時の負荷がかなり減ります。
実際、ログ上でも lm: 0.000 や vae: 0.000 に近い状態になり、キャッシュが効いていることを確認できました。
ただし、キャッシュを作るにも時間とストレージが必要です。
画像枚数が増えるほど、学習時間だけでなく、前処理・キャッシュ・保存先の管理が重くなります。
この時点で、スクラッチ学習は「GPUが強ければ終わり」ではなく、データ処理とストレージ管理のゲームでもあると分かります。
10万枚で clean-base-v0.1 を本番扱いにする
最終的に、最初の本番ラインとして PD12M から約10万枚を使うことにしました。
モデル名は、
clean-base-v0.1-100k
です。
これは、まだ本格的な大規模基盤モデルというより、最初の実験的ベースモデルです。
ただし、ここまでで以下は確認できています。
SANA環境が動く
データセットを読める
画像・キャプションを処理できる
テキストキャッシュを作れる
VAEキャッシュを作れる
A100 80GBで学習が進む
チェックポイントを保存できる
保存したモデルから推論できる
ここまで到達すると、「スクラッチ学習の入口」は突破できたと言ってよいと思います。
学習結果：画像は出たが、プロンプト追従はまだ弱い
10万枚で３epoch学習したあと、推論を行いました。
結果として、画像は出ました。
構造的に面白い絵もあり、色も乗るようになってきました。
3epoch
ただし、プロンプト追従度はまだ弱いです。
これはかなり自然な結果だと思います。
10万枚・数epoch程度では、画像生成モデルとしてはまだ学習量が足りません。
特に、スクラッチ学習では既存モデルのような強い事前知識がないため、プロンプトに対して正確な構図や属性を返すには、かなりの学習量が必要になります。
それでも重要なのは、モデルが壊れずに画像を生成できていることです。
これはかなり大きいです。
最初の段階では、完璧な画質よりも、
学習が進む
lossが異常に発散しない
checkpointが保存できる
推論で画像が出る
追加学習できる
ことの方が大事です。
その意味では、clean-base-v0.1-100k は最初の到達点として十分な成果でした。
追加学習：e6 → e12 → e18 → e24 → e30
6epoch
※3→6の3epochの学習の間でかなり進展が見られる
最初の学習後、色が少し良くなり、画像の雰囲気も改善してきました。
そこで次の方針として、30epochまで追加学習する案を考えました。
ただし、いきなり長時間回すのではなく、6epoch単位で区切る方が安全です。
流れとしては、
e6
e12
e18
e24
e30
のように段階的に保存していきます。
なぜ分けるかというと、100k固定データで回し続けると、過学習のリスクがあるからです。
途中で、
同じような構図に寄る
色が単調になる
特定の物体ばかり出る
プロンプト追従が改善しない
逆に絵が崩れる
といった現象が出た場合、e18やe24で止める判断ができます。
長時間学習では、「最後まで回す」よりも「途中の良い地点を保存しておく」ことが大切です。
実際にやって分かったこと
今回の実験で分かったことは、主に5つあります。
1. 個人でもスクラッチ学習の入口には立てる
A100 80GBを借りれば、個人でも画像生成モデルのスクラッチ学習は現実的に試せます。
もちろん、商用品質の大規模モデルを作るには全然足りません。
しかし、学習環境を作り、データを用意し、モデルを保存し、推論まで持っていくことは可能です。
これはかなり大きな発見でした。
2. GPUよりもデータとキャッシュが大変
GPU性能はもちろん重要です。
しかし実際には、
データを集める
ライセンスを確認する
画像を整理する
壊れた画像を除外する
重複を消す
キャプションを整える
VAEキャッシュを作る
テキストキャッシュを作る
ストレージを管理する
という部分が非常に重いです。
スクラッチ学習は、モデル学習というより、半分以上はデータセット構築です。
3. 小規模テストは絶対に必要
1枚、100枚、1万枚、10万枚と段階を踏んだのは正解でした。
最初から10万枚で始めていたら、パスの間違いやキャッシュの問題でかなり時間を失っていたはずです。
小さく壊して、小さく直す。
その積み重ねが大事です。
4. 10万枚ではまだ足りない
画像は出ます。
しかしプロンプト追従は弱いです。
これは失敗というより、当然の結果です。
既存の強力な画像生成モデルは、はるかに大規模なデータと計算量で学習されています。
10万枚は、スクラッチの検証としては十分ですが、汎用モデルとしてはまだ小さいです。
今後は、データ枚数を増やすか、追加学習を重ねるか、用途を絞る必要があります。
5. 研究用途と制作用途は分けた方がいい
スクラッチ学習は非常に面白いです。
ただし、作品制作や商用成果を早く出す目的なら、既存モデルをベースにしたLoRAやファインチューニングの方が圧倒的に効率的です。
スクラッチは、独自基盤を作る研究・検証として面白い。
制作実務では、既存モデル活用の方が速い。
ここは分けて考えるべきだと思いました。
今後の方針
今後の方向性は、大きく3つあります。
まずは、clean-base-v0.1-100k を e12、e18、e24、e30 と追加学習し、どの段階が一番良いか比較すること。
次に、データセットを増やすこと。
10万枚では限界が見えやすいので、30万枚、50万枚、可能ならさらに大きなデータセットに広げたいです。
最後に、基盤モデルとは別に、アニメ向けの adapter / fine-tune を作ること。
ただし、その場合も clean-base-v0.1 と anime-adapter-v0.1 は分けて管理します。
データも規約も混ぜません。
この分離は、後から公開・配布・商用利用を考える上で重要になると思います。
まとめ
今回の実験では、A100 80GBを使い、SANA系の構成で clean-base-v0.1-100k というスクラッチ学習モデルを作るところまで進めました。
結果として、画像は生成できました。
プロンプト追従はまだ弱いですが、モデルは学習し、チェックポイントも保存でき、推論も動いています。
これは、個人が画像生成モデルをスクラッチで作る上での、かなり現実的な第一歩だと思います。
最終的な結論としては、こうです。
個人でも、スクラッチ画像生成モデルの実験はできる。
ただし、本当に大変なのはGPUではなく、データセットと運用設計。
そして、実用品質を目指すなら、スクラッチ研究と制作実務は分けて考えるべき。
今後は、10万枚モデルをさらに学習させつつ、データセットの質と量を改善していきます。
※anime-adapter-v0.1の学習にはnijijourneyの出力物を利用して検証する予定です。
※4/28から5/7までの間に（自分の作業効率が悪く大分色々ロスしてますが概ね550$程度課金してます）
コメント