クラウドSD動作環境夜話
この記事は生成AI Advent Calendar 2024の12/11(水)のエントリー記事です。最初は地方創生とAIについて書こうと思っていましたが趣旨を変えてクラウド実行環境についての、主に料金についての比較記事になります。久しぶりの技術系アドベントカレンダーのエントリーでとてもわくわくしています。どうぞよろしくお願いします。
人によって、または要求によって違うことは大前提ですが、そのうえで時代によっても画像生成AI動作環境に求めるものが違ってきますよね。結論から言うとFLUX1.1 devを使う今はVRAM盛々環境をクラウドで用意する必要があるよねっていう話です。自宅で生成AIを楽しむ民としては、そうそうポンとRTX A6000を買えないし、Cloudでも$3/1hurとかのマシンを簡単には動かせないので落とし所を見つけましょう、でも落とし所って結局個人によって求めるものが違うよねっていうことで、SD発表直後からいろいろと変化してきた筆者の動作環境を以下に長々書いていきますという試みです。なので生成AIの話というよりは生成AI動作環境の話になります。
SD1 - SD1.5時代
家にある RTX3060 VRAM12GB 環境で十分だった
A1111以前
sdをリポジトリからクローンして自分でせっせとPython動かして512 x 512 の画像が出て面白がる時代
バッチ処理も自分で書いてた
A1111以後
Generate forever機能以前
自宅でマシンを立ち上げて、連続処理できる最大回数を増やす設定で回してた
Generate forever機能以後
おま環だがGenerate foreverしているとGPUが落ちるように。調べてみるとグラボに繋がってる電源が焦げている
とりあえず電源プラグを別の焦げてないプラグにつなぎ替えることで動作は復旧できたが、事が事だけに再現して検証するわけにもいかず自宅RTX3060環境での生成AIは封印することに
グラボを変えればすむことなのか、電源の方に原因があるのかも検証するハードルが高く、この時点から生成AIはクラウド環境時代へ
M1MAC
SD発表当日はAppleSiliconでの動作ノウハウも揃わず苦労したがそれでも当日には動作させることに成功。ただしappleが想定してる以上の発熱がしてけっこうやばい
こんなことを続けていれば、いずれ火事になって死ぬか仕事道具のMacBookProが燃えて仕事が出来なくなって死ぬ
やはり世はクラウド生成時代へ
ControllNet時代
独自のControllNet Tile Upscaleを見いだしA1111 API実行へ
独自と言ったがControllNet Tileでupscaleする知見は一般的なものだったが、A1111 webuiでテキスト生成から一発でControllNet Tile upscaleする方法が当時は確立されておらず、自動処理する人は少なかった印象
A1111 webuiではt2iで一度生成した画像をそのままControllNetの画像として渡すことができず、GUIでやるしかないのでこの部分がどうしても自動化できなかった
ということでA1111 webui APIから t2i -> ControllNet Tile + Hires.fix -> img2img ultimate upscale までを独自で自動化
ついでにA1111の処理を全部yamlで書いて自動化できるようにすれば便利かもということで開発して皆も使えたらいいなと思って公開したが、自分以外使いにくいのと作り込みもあまりよくないのもあって誰にも使ってもらえず
もうお気づきの人もいるかもしれないが、これってつまりComfyUIの超下位互換的存在
A1111webuiのAPIが提供している処理を最小単位と捉えて、処理のインプットとアウトプットを自由に繋ぐことで結果を得るという意味で、ComfyUIのノードベースのワークフローの組み立て方の下位的存在といえる
筆者がComfyUIの存在を知るまではしばらくこれで遊べたでござる
ComfyUI認識以前
AWS EC2
us-east-1 g4.xlargeスポットインスタンスがおそらく一番安い
当時は東京リージョンのec2を勧める記事は多かったが、生成AIはサーバーとローカル間の距離の転送速度がボトルネックになる機会は少なく、要はリージョンは無視できるのでus-east-1がいいと思う。今だとawsでSD環境構築の日本語ノウハウもたくさんの方が出していただいてるので迷わずus-east-1ではじめることが出来る
g4dn.xlargeのvram 16GB環境でも何ら問題なくSD環境が遊べた
まだ時代はSD1 - SD1.5時代なので
Google colab
筆者はSD発表以前は画像生成AIでいうとGANモデルを使っていたので、SD発表時点ですでにGoogle colab有料環境が使える状態にあった
この時代のGoogle colabはSD動作使いたい放題環境
ただしバックグラウンド実行はもう一つ上の高額課金プランじゃないと使えないので、webuiはAPIだけ動作させたい筆者の使い方にマッチしなかった
Paperspace
今も続く筆者の本命環境のひとつ
この時代のPaperspaceはwebuiで動作させてもAPIが問題なく使えた。言い方を変えると今はAPIは塞がれてたり使えても問題があったりする
高火力GPUの取り合いに勝って一度起動できたら6時間はバックグラウンドで起動しっぱなしに出来るのも魅力
クラウド機械学習の少なくともSD動作環境用途黎明期だったので、Paperspaceでのwebui動作ノウハウも世界的に少なく試行錯誤の繰り返し
python3.11 -> 3.10 とか xformersインストールノウハウとか
python3.11 -> 3.10
確かPaperspaceのpythonが3.11でwebuiが3.10推奨だったとかで、実行環境のpythonバージョンをどうするか問題
Dockerでやるよ派 -> notebook環境の初手でやらないと詰む
notebookでやるよ派 -> notebook起動するたびにするので毎回時間かかる
「はあ？venvでやればいいじゃん」-> paperspaceは永続ストレージにお金がかかるので富豪しか無理
つまり環境まで永続化したらストレージ代がけっこう嵩む。環境を永続化させずなるべくnotebook起動後に環境構築自動処理させる工夫
最近のnotebookは環境構築がやりやすくなってる印象。これは構築ノウハウが溜まってきたからなのかPaperspace側の何らかの改善があったからなのか、もしくはその両方なのか、はたまた筆者の勘違いや思い違いなのかは未検証
ComfyUI認識以後
自分が自作していたweb1111 API自動実行環境以上の全てが揃っている
自分にはプロンプト検証フェーズ、自動実行フェーズと大きく二つのフェーズがあって、このうちの自動実行フェーズが完全にComfyUIでまかなえる
ただし一般的にも知られているようにA1111とComfyUIで同じパラメーターを渡して完全に同じ生成物を出すようにするためにはいろいろと調整が必要で、つまり検証フェーズで時間をかけて作ったプロンプトやパラメーターが自動実行フェーズでそのまま使えるというには追加作業が必要で、つまりA1111 API自動実行の必要性はまだまだ残ることに
この頃からPaperspaceではAPIの接続に制限がかかるようになり、長時間のHTTPセッションが切られるように
時間のかかる筆者の処理が事実上無理になった
HTTPセッション系やkeep alive系やパケットポーリングや色々試したが、非公開でpaperspace側で何らかの制限がかけられているという結論に至り、EC2でのAPI実行環境の強化へ乗り出す
AWS EC2 g4dn.xlaege環境の強化
特に難しいことはなく、初期に作っていた環境をローカルから自動実行できるようにしたりするのみ
大量のファイルを並列処理させるために5台くらいインスタンスを同時起動させはじめ、AWSからの毎月の請求がコンスタントに2万を上回りはじめ、お財布事情的にしばらくは自動実行そのものを封印
SDXL時代
筆者はwebui-forgeが出るまでSDXLは手を出していなかったが、この頃からいよいよローカル実行がVRAM的に苦しい時代に
Flux1.1 & SD3.5 時代
しばらくはpaperspaceにforge入れて遊ぶくらいで済んでいたが、詳細化やupscaleをやり始めるとComfyUI環境の再構築が必要に
cost-effective-aws-deployment-of-comfyui
良い時代になったのもので、AWSの公式チームがec2上にComfyUI環境を作る方法を提供してくれている
筆者の言葉ですご〜く雑に言うと、CloudFormation（をラップしたCloudDevelopmentKit)で一発でComfyUI環境作っちゃいましょうというもの
それをSageMakerで管理できるよ！というのが便利ポイントらしい
g6.xlargeで立ち上げる方法
そのまま使うとg4dn.xlargeが起動する
他のインスタンスも選べそうだが、いろいろやったけど自分の力ではどうしてもスポットインスタンス料金の安い順にオートスケーリングしてしまう動作が変えられず、結局このリストからこの行以外を削除することで（g6.xlaege以外を削除することで）対応した
大変ありがたいのだが、以下の点が筆者にはアンマッチだった
簡単と言いつつ複雑なIAM権限周り
これはこの環境構築に限らずAWS全般に言えるけど、権限周りちゃんとやろうと思えば思うほどどこがボトルネックになるのかわからないおま環環境になりはてる
なぜか頻発するメモリーオーバー
素で立ち上げたインスタンスと同じスペックでも、この構成で動かしてるとVRAMもCPU RAMもメモリーオーバーが発生しやすい
おま環での再現性は高いが他者と共有するのが難しいので検証断念
自動化と言いつつ削除にはそれなりに手動作業が必要
Auto Scaling Group を手動で削除する（これはドキュメントにも書いてある）
S3バケットを削除する（バケットを削除する前にちゃんと空にしないといけないのが地味に面倒ポイント）
ECRを削除する
sagemakerで npx cdk destroy する（これはドキュメントにも書いてある）
がその前に、公式サンプルの通りにsagemakerを構築したらコンテナ環境で実装されるので、npx cdkする前にnpm installしないといけない
公式ドキュメントで npx と npm run が混乱して書かれてある（こんなところに書く前にプルリク送れといわれればそれはそう）
毎回 npm installしないといけないならいっそnpxなしの素でcdkでいいのでは？ -> 結局 pip install cdkしないといけない -> コンテナ環境の儀式化からは逃れられない
コストパフォーマンスに優れているといううたい文句だが、自動停止するには40分以上は何もアクセスされない空白時間を作らないといけなくて、その間のサーバー代がきつい。例えg4dn.xlargeとはいえ馬鹿にならない。
少し脱線だがこのへんのコストパフォーマンスの閾値の差分が、自分以外のAWS使ってる人ってやっぱお金持ちが多いんだろうな〜と毎回実感する。
実行コンテナへの接続が、公式のスクリプトが古い（プルリク送れと言われればそれはそう）ので、接続に工夫が必要
sudo docker container ls --format '{{.ID}} {{.Image}}' これして目grepでコンテナID見つけて sudo docker exec -it ＜目grepの成果物＞ /bin/bash するだけなんだけどね
ドキュメントには書かれてないが、手動でサーバー止めるにはオートスケーリングあたりを掘って ＜実行環境のURL>/admin/shutdownとかが使えそうではあるが、思ったほどサーバーをコントロールできず、結局何のためにあるのかわからず
このへんから自分の理解力を超えてるものだから、ありがたいのはありがたいけど無理に使おうとせず自分で作った環境でComfyUI立ち上げた方が良さそうだと理解
Paperspace ComfyUI環境
もともとPaperspaceはリバースプロキシにgradioしか許可しておらず、他の抜け道をしようものなら即垢BANもありえるためPaperspaceでのComfyUI環境構築を筆者は最初は視野に入れていなかった
いちおうA1111 webui の extentions にComfyUIを動作させる拡張機能があって、当初はPaperspaceでもこれが動いたので事実上ComfyUIを使えはした
結局やってることはリバースプロキシなのでPaperspaceがどう見るかはコントロール権はこちらにはない状態で動作させていた
のちのち塞がれた
言うまでもないが、この拡張自体はPaperspaceでwebuiを経由してComfyUIを操作するためだけのものではなくて、A1111にComfyUIのパイプラインを使えるようにしようという目的で大変便利なもの
Paperspace公式が出しているこのリポジトリのこのnotebookを使う
メリットは公式が出してくれているだけあってかなりすんなり使えること
情報に感謝です！ PaperspaceでComfyUIを導入する
デメリットというか気をつけないといけないのが、環境構築がかなり抽象化されているのでこちらで手を入れる方法が限られていること
custom_nodeによっては正しくインストールできない場合がある
筆者の場合はkijai / ComfyUI-CogVideoXWrapperとlumalabs / ComfyUI-LumaAI-APIがどうしてもnotebook起動する毎と他のcustom_node入れたときのタイミングなどで環境が破損する
都度手動でpip installなどを行えば上記環境も動作するが、こちらを動作させればこちらが動作せずのモグラ叩き状態になって、どうにも面倒。根本的な解決を見つけるしかない
AWS EC2 d6.xlarge環境
Fluxを動かそうと思うとvram16GBのg4dn.xlargeでは少し難しい場面が増えてくるので自然とg6.xlargeに手が伸びることになるが、スポットインスタンス換算でもg4dn.xlargeの1.5倍の料金という、なかなかに勇気のいる構成
ちなみにg5.xlargeよりもg6.xlargeのほうが安い
よくVRAM容量とCPU RAM容量を混乱する人がいるが、g4dn.2xlargeで32GBなのはCPUメモリのほうなので、VRAMは2xlargeでも変わらず16GMなので注意
まあこのへんはAWS公式も他のインスタンスにならってVRAMがわかりにくいところにしか書いてないし、ぱっと見で比べられるのはCPU RAMのほうなのもあって混乱するのは無理もないよねということ
g4dn系のVRAMの初期スタートがCPU RAMもどっちも16GBスタートなのも混乱しやすい
EC2インスタンスについての表を作りました
RunComfyどうなの？
Paperspaceと比べてどうなの？
Paperspaceの勝ち
なんと言ってもサブスクしとけばGPU争奪戦に勝てばA6000が6時間使えるというロマンがPaperspaceにはある
なにせA6000環境に慣れてしまうとA5000で起動できたとしても遅く感じてしまう始末
RunComfyの勝ち
逆に言えば画像生成AIしたい時にGPU争奪戦という目的外の行為が挟まるという心理的負担がRunComfyにはない
Paperspaceも（RunComfyと同じく）従量課金でマシン立ち上げられるし！
従量課金制なら現時点でどれがいいかは比較しやすいように表にまとめた。のちほど表示
なんと言ってもComfyUI専用環境というのがいい。Paperspaceで悩まされる諸々が考えなくて済みそう
AWS EC2と比べてどうなの？
従量課金であるなら、スペックと値段のバランスだけ見ればAWSのほうが軍配があがりそう
結局のところIAM管理が大変でえらいことになったりとかそういうのが無いのがRunComfyのいいところかも
lambdalabsどうなの？
筆者はlambdalabsそのものを知らなかったのですがなんと同じ生成AI Advent Calendar 2024でpacyさんがlambdalabsを使ってcomfyuiを立ててみる🐪という非情に有用な記事を挙げてくださっています。今すぐにでも使いたいと思いました。ありがとうございました！
特にEC2をスポットではなくオンデマンドで稼働させたときのコスパの比較がlambdalabsは圧倒的にいい
runpodはどうか？
最有力候補のひとつ
インスタンス停止時にストレージに課金されるので、停止毎にインスタンス削除の運用が求められる
ファイルのバックアップや復旧はAWS S3などに行えるので、ファイルベースでインスタンスを再現させる方法が確立されていれば使い勝手が良い
逆に当初paperspaceを選んだのはpaperspaceは月額課金していればインスタンス停止時にストレージをある程度保持してくれるからで、runpodの一長一短がちょうど反転する形で当時の自分のニーズにマッチしてたため
ある程度A1111webui環境やComfyUI環境をファイルベースで復旧するノウハウを知った今では運用が楽かもという期待がある
例えば環境構築はローカルで行って、S3で同期後runpodを立ち上げて生成、とかのフローが出来そうならメインで使える期待をしてる
GPUSOROBANさんどうなの？
国内GPUクラウドなので頑張ってほしい陰ながら応援してる
わかりやすい料金体系に好感。
VRAM16GBが、ホビーユースFlux1.1民には辛いところ
今後の発展に期待しつつ問い合わせ検討したい
その他
Azure（Microsoft）とかGCP（Google）とかどこも似たり寄ったりで、それならどうしても筆者がEC2サービス開始当初からのユーザーだけにAWSにいきがち
GPUSOROBANさんと似たような構成と価格帯。今後の発展に期待しつつ問い合わせ検討したい
さくらインターネットさんも国内GPU老舗だが、ホビーユースには辛い価格帯
というわけで現時点で限られてくる環境の比較はこちら
表が見にくい場合は以下のGoogleスプレッドシートも参考にしてください。
ほとんどのサービスがオンデマンド型であることを考えて、EC2の比較用もスポットインスタンスだけでなくオンデマンドインスタンスの料金も比較に入れてみました。2年前ならGPU系インスタンスはスポットでも十分でしたが、EC2もスポットでは落ちることがたまにあるようになってきましたので、抑えさえすれば稼働できるオンデマンドでの運用も視野に入ってきます。
単純にVRAMの容量だけで比較してたり、ストレージや転送量の課金要素を意図的に無視してたり、定額課金のサービスを抜いてたり月額の料金を反映させてなかったりと、データとしてはいろいろ穴がありますが、EC2で自前で環境を揃えるのに対してどれだけコストがかかってどれだけ便利になるかがある程度わかりやすくなるかと思います。
その上で言いたいことは、昔は（といっても1年前とか）好きな環境選べば良いだけだったのが、VRAM盛った構成が必要になってきて（Tiled VAEは低VRAMにとって銀の弾丸では無い的な）クラウド環境選びも複雑になってきましたねということでした。