Qwen-Image の LoRA でキャラクターを学習させる — 41 分 $1.07 の実測

結論｜41 分・$1.07 で、参照画像の制約が外れた

前回までで、自前のワーカーを立てて 16:9 の画像を出せるようになりました。しかし画風とポーズは自由になっていません。決めているのが参照画像だからです。

そこで自社キャラクターを LoRA で学習させ、参照なしの text-to-image に切り替えました。結果を先に置きます。

そして、それまで何をしても通らなかった指定が通るようになりました。

なぜ LoRA だったのか

LoRA に入る前に、まず制約の構造を測りました。前回ワークフローを毎回渡す設計にしたので、cfg やステップ数を再ビルドなしで動かせます。分かったのは、画風もポーズも、決めているのは参照画像であってプロンプトではない ということでした。

同じ参照・同じ seed で画風の記述だけを 5 通りに変えたところ、通ったのは水彩だけでした。4 ステップの蒸留 LoRA を外して cfg を 1 から 4 へ上げると 3D レンダーは通りましたが、フラットベクターと 90 年代セル画は最後まで通りません。

通ったのは水彩と 3D、どちらも質感を「足す」変更です。通らなかったのは、階調を捨て色数を減らす、つまり情報を「引く」指定でした。参照画像が持つ描き込みの量が下限として働いている、と読めます。

参照画像を 2 枚渡して「人物は 1 枚目、画風は 2 枚目から」と分離することも試しましたが、これも通りませんでした。image2 は画風の見本ではなく 合成する被写体 として扱われ、別人を渡すと画面に人が増えます。

つまり、この制約はすべて「参照画像に縛られていること」から生じています。その鎖を切る手段が LoRA です。

学習の準備

落とし穴 1｜推論用の fp8 では学習できない

最初に足をすくわれるのがここです。公式ドキュメントに一行だけ書かれています。

fp8_scaled and fp8_e4m3fn versions cannot be used.

前回ワーカーに焼き込んだのは 19.12GB の FP8 量子化版でした。あれは学習に使えません。 別途 bf16 のフル版が要ります。

メモリ削減は --fp8_base のような実行時オプションで行う設計で、ファイル自体を量子化版に差し替える方式ではありません。推論と学習でモデルファイルが違う、というのは実際にやらないと気づきにくい点です。

落とし穴 2｜編集モデルと生成モデルは別物

もう 1 つの分岐がここです。--model_version には original (Qwen-Image = text-to-image) と edit-2511 (編集モデル) があり、DiT のファイル自体が別です。

参照画像から離れることが目的なら、選ぶのは original です。編集モデルで学習すると、結局また参照画像ありきの LoRA になります。私は最初に Edit 版を落としてしまい、38GB を追加でダウンロードし直しました。

GPU の選び方

公式が示す VRAM の目安です (1024×1024・バッチ 1・bf16・gradient checkpointing)。

24GB クラスでも動きますが、公式は「64GB のメインメモリを推奨」と付記しています。手元の条件 (1024 基準・バッチ 1) では、48GB クラスなら blocks_to_swap を考えずに済みました。ただし使用率は 94% で、解像度やバッチを上げる余地はほとんどありません。

RunPod では、RTX A6000 (48GB) が RTX 4090 (24GB) とほぼ同額の $0.33/h (community) でした。ただし community・secure とも在庫を確保できず、L40 に落ち着いています。1 本目では Serverless のワーカーが throttled になりましたが、同じことが Pod のデプロイでも起きました。

学習の実行

教師データは既存の記事キービジュアルをそのまま使いました。48 枚すべてが 1600×900 で、画風も統一されています。 教師データを新たに用意する必要がありませんでした。

キャプションは全画像で共通にし、トリガーワードと外見の特徴だけを書いています。

fxtsukasa, 1boy, black hair tied in a small bun, thin rectangular glasses,
black turtleneck with yellow stitching, anime cel shading, clean thin linework

データセットの設定はこれだけです。

[general]
resolution = [1024, 1024]
caption_extension = ".txt"
batch_size = 1
enable_bucket = true
 
[[datasets]]
image_directory = "/workspace/dataset/tsukasa"
cache_directory = "/workspace/cache/tsukasa"

resolution は面積の基準で、enable_bucket があれば縦横比ごとに振り分けられます。1600×900 を入れると、latent の形状は [16, 1, 96, 170] になりました。VAE が 8 倍なので 768×1360、つまり推論で使っている 1360×768 と同じ解像度に収まっています。

前処理は一瞬でした。

latent キャッシュ         48 枚 / 16 秒
テキストエンコーダ出力    48 枚 / 13 秒

学習は 16 epoch、768 step です。

steps: 100%|██████████| 768/768 [41:23<00:00, 3.23s/it, avr_loss=0.0648]
VRAM: 43,491 / 46,068 MiB (94%)

43.5GB。 公式が言う「最適化なしで 42GB」とほぼ一致しました。L40 のカタログ値は 48GB ですが、プロセスから見えたのは 46,068 MiB で、使用率は 94% です。

公式が「不明」と書いている領域

musubi-tuner のドキュメントは、パラメータの説明の最後にこう書いています。

The appropriate settings for each parameter are unknown. Feedback is welcome.

教師データの枚数も、解像度も、epoch 数も、推奨値が示されていません。 ここは実際にやった人が数字を持つ領域です。手元の結果を置いておきます。

少ない枚数で足りるか、epoch を増やすとどう変わるかは検証していません。この表は「1 例が通った条件」であって、最適値ではありません。

結果｜通らなかった指定が通った

学習した LoRA を当て、参照画像なしで生成しました。試したのは、前回まで何をしても通らなかった 2 つです。

1 つ目はフラットベクター。編集モデルでは cfg を 4 倍にしても平坦化しませんでした。

グラデーションが消え、色数が絞られています。引き算の指定が通りました。

2 つ目は腕組みと横向きの構図。参照画像に一度も存在しないポーズです。

生成は 20 step・cfg 4 で 55 秒、出力は 1360×768 です。2 本目の「1.0 秒」は 4 ステップの蒸留 LoRA と RTX 5090 の値なので、同じ土俵の数字ではありません。そして キャラクターの特徴 — 黒髪のお団子、細い長方形の眼鏡、黒タートルネック — は保たれたままでした。

FIXIT

えっ、参照の絵なしでも同じ人になるの？

Tsukasa

同一性は LoRA 側が持ちます。だから参照画像ではなく、プロンプトで決められます。

FIXIT

ふーん。最初から LoRA でよかったんじゃないの？

Tsukasa

制約を測ってからのほうが、何を解いたのかがはっきりします。

費用の実際

課金レコードで確認した Pod の実費は $1.07 でした。当初の見込みが $1 前後だったので、ほぼそのとおりです。

稼働時間は約 1.53 時間で、実効単価は $0.70/h 前後になります。学習そのものは 41 分で、残りはモデル 92GB (bf16 一式 53.7GB + 取り違えて落とした Edit 版 38GB) のダウンロードと環境構築でした。

そのうえで、GPU 時間の単価は Pod のほうが Serverless より安く済みます。同じ L40 でも Serverless は秒課金の代わりに単価が上がるため、数時間の連続稼働には Pod が向いています。学習のように「長く回して止める」処理は、この使い分けがそのまま効きます。

逆に言えば、取得と環境構築に費やした時間が、費用の 55% を占めています。同じ検証を繰り返すなら、ネットワークボリュームにモデルを置いて使い回すほうが安くなります。

学習の外側でつまずいた点

学習そのものは 41 分で終わりましたが、その前後で時間を溶かしました。いずれも設定の問題で、GPU の性能とは関係ありません。

推論に使っている Serverless エンドポイントで、ジョブがキューに残ったまま動かなくなりました。ワーカーは「初期化中」のまま、在庫表示上は GPU が 8 台空いています。原因は workersMax を 1 に絞っていたことでした。1 基が初期化に手間取ると、他のマシンへ振り替える先がありません。 費用を抑えるつもりの設定が、復旧できないキュー詰まりを作っていました。

さらに厄介だったのが、その修正です。

{ "workersMax": 3 }        // 無視される
{ "workers": { "max": 3 } }  // 正しい

前者を送っても HTTP 200 が返り、値は変わりません。エラーが出ないので、直したつもりで待ち続けることになります。上限を 3 に戻した直後にワーカーが 2 基立ち上がり、詰まりは解消しました。

FIXIT の運用 — 教師データは既に持っている

今回いちばん効いたのは、技術的な工夫ではなく 教師データが最初から揃っていたこと でした。

記事を書くたびにキービジュアルを作ってきた結果、上位 5 名だけで 171 枚、8 名の合計で 216 枚 の 16:9 画像を持っていました。画風も統一されており、LoRA の教師データとしてそのまま使える形です。

新たに用意しようとすれば、枚数でも画風の統一でもつまずきます。日々の制作物が、そのまま次の技術検証の入力になりました。 記録を残しながら進める価値の 1 つです。

まとめ — 制約は測ってから解く

参照画像に縛られる構造を 3 本かけて測り、最後に LoRA で外しました。順番に意味があります。先に LoRA へ飛んでいたら、何を解決したのかが自分でも分からなかったはずです。

• 1 本目で、費用と速度の判断材料を実測した
• 2 本目で、既成ワーカーの限界を越えて自前の基盤を作った
• 3 本目で、参照画像という最後の制約を外した

手をつけていないのは品質の作り込みです。教師データの枚数、epoch 数、network_dim の調整で何が変わるかは、1 例しか持っていません。

画像生成を自社の基盤に載せるかどうかは、モデルの性能ではなく運用の形で決まります。同じ判断で迷っている場合は、AI 駆動開発やお問い合わせからご相談ください。

本記事の数値はすべて 2026 年 8 月 17 日の実測です。参照した一次情報は musubi-tuner の Qwen-Image ドキュメント、kohya-ss/musubi-tuner、RunPod の料金ページ、Qwen-Image のモデルページです。