Runpodを実際に使ってみた感想と注意点[実践編]

前置き

※この記事は前回の「RunpodでStable Diffusionを構築してみた」の続編にあたります。構築手順やRunpodの基本用語については前回の記事をご覧ください。

※Runpodには利用料金がかかります。ここに記載されている内容で発生したいかなることにも私は責任をとれません。あらかじめご了承ください。

また、この記事を見てRunpodを使ってみようと思った方は、以下のリンクからサインアップ（登録）してもらえると、登録者のあなたが5〜500ドル利用できるようになるので、ぜひ活用ください。

https://runpod.io?ref=efe93ke8

はじめに

前回の記事では、RunpodでStable Diffusionの環境を構築する手順を紹介しました。今回は、実際にしばらく使い続けてみて感じた「良かった点」と「ここは注意が必要」という点をまとめていきます。

結論から言うと、思った以上に使い勝手は良いです。ただし、ネットワーク越しに使うクラウドサービスであるがゆえの制約もあり、万人に手放しでおすすめできるかというと、用途と環境によるな、というのが正直な感想です。

良かった点：思った以上に快適

起動の手軽さ

前回の記事で構築手順を紹介した通り、テンプレートからPodを作成すれば、あとは待っているだけでStable Diffusionの環境が整います。ローカルで一からセットアップした経験がある方ならわかると思いますが、Pythonのバージョン管理やら依存パッケージの衝突やら、何かとトラブルが起きやすいのがローカル環境構築です。それが「待つだけ」で終わるのは、精神的にも結構健全だと思います

ただ、前回の記事にも記載した通り、デフォルトのままだとPytouchとCUDA関連でRTX5090は使えませんのでご注意ください。

非力なPCでも使える

個人的にありがたかったのが、喫茶店での作業です。
私は外出先にノートPCを持ち出して作業をすることがあるのですが、当然ノートPCにはまともなGPUは載っていません。
それでも、Runpodであればブラウザ経由でStable Diffusionを操作できるので、サクサク使えます。処理自体はクラウド上のGPUが行うため、手元のPCのスペックはほとんど関係ありません。

「試しに使ってみる」には十分

私自身は手元にRTX 5080を積んだデスクトップPCを持っていて、後述する理由からローカル環境のほうが取り回しは良いので、完全にRunpodに乗り換えるほどではありません。ただ、まだGPUを持っていない人が「Stable Diffusionってどんなものだろう？」と試してみる選択肢としては十分に活用できると思います。高価なGPUを購入する前に、クラウドで感触を掴んでから判断する、という使い方は合理的だと思います。

また、上記リンクから登録して最低限もらえる5ドルでも、使うGPUにもよりますが、4000Adaなら15時間以上使えるので、十分感じをつかむことができると思います。

問題点：ネットワーク越しであるがゆえの壁

ここからが本題です。使い続けてみると、やはりクラウドサービス特有の課題を実感しました。

モデル転送に時間がかかる

あたりまえの話ではあるのですが、改めて体感すると思った以上にインパクトがあります。

Stable Diffusionのモデルファイルは6GBを超えるものが普通です。これをRunpodに転送するには、それなりの時間がかかります。私の環境での目安としては、Stable Diffusionの起動自体に約15分、モデルを1つ転送するのに約30分かかります。つまり、新しくPodを作成してから実際に画像生成を始められるようになるまで、おおよそ1時間弱は見ておく必要があります。

ローカル環境であれば、モデルの切り替えは数秒〜数十秒の話なので、ここの差は大きいです。
複数モデルを切り替えながらいろいろ試したいといった場合はその都度モデルの転送が発生するので、少し覚悟が必要かもしれません(初めにrcloneとかで一気に送ってしまえば解決はしそう？)。

生成画像のダウンロードがボトルネックになる

私の運用スタイルでは、画像を大量に生成して、一枚一枚にファイル名をつけてあとからチェックする、という使い方をしています。そのため、生成した画像は特定のタイミングでまとめてローカルに持ってくる必要があります。

この転送の待ち時間が、意外と馬鹿になりません。

RunpodではRTX 4090やRTX 5090といったハイエンドGPUも選択できますが、生成速度がいくら速くても、ローカルへの転送時間がボトルネックになりがちです。結果として、RTX 4090の半額程度で借りられる4000 Adaクラスのスペックでも、転送込みの「実質的な時間あたり生成枚数」はほとんど変わらない、という状況になったりします。
(RTX 4090だと3秒で生成、4000Adaだと20秒で生成、ただし転送に40秒、みたいな。そして、4000AdaはRTX 4090の半額で使えるのでこっちにしがち)

生成しながらバックグラウンドで並列転送すれば改善できそうではあります。rcloneも使えるのでいろいろ逃げ道はありそうです。
ただ、ネットワーク越しの並列処理にはあまりいい思い出がないので、現状は「生成 → 転送 → ファイル名変更 → 生成……」というシーケンシャルな運用にしています。これは私個人の問題でもあるのですが、あとからわけわからないことにならないように安定性を優先してこうしています。

転送に失敗することがある

Stable Diffusionは生成日付のフォルダを作成して、そこに画像を保存します。ここで問題になるのが、ローカルPCとPodでタイムゾーンが異なる場合があるということです。Podのリージョンによっては、ローカルPCとサーバー上の時刻にずれが生じ、想定と異なるフォルダに画像が保存されることがあります。

ファイル転送に限らず、SSHでサーバーの時刻を確認したりする場面でも、ネットワークの「あるある」としてリクエストが返ってこないことがあります。こういったタイムアウトやネットワーク不安定に起因する転送失敗は、スクリプトで自動化している場合に特に影響が大きく、リトライ処理やエラーハンドリングなど何らかの対策が必要になります。

問題点：GPU枯渇問題

ネットワーク周りとは別に、もう一つ厄介な問題があります。

stop状態からの起動ができない

Runpodには「stop」というステータスがあります。Podを停止状態にしておけば、稼働中よりも料金を抑えることができ、モデルの転送も不要なので再開時にすぐ使い始められる……はずなのですが、ここに落とし穴がありました。

stop中にそのリージョンでGPUが枯渇すると、起動ができなくなります。

これには何度か遭遇しました。特に土日はこの傾向が強い印象です。
せっかく停止状態で保存していたPodが、いざ使おうと思ったら起動できない、というのはなかなかストレスです。

停止状態でもじわじわと課金される

stop状態であれば稼働中よりは安いのですが、それでもストレージ分の費用は発生し続けます。体感として、3日も停止状態にしていれば1ドルくらいは消えていきます。金額としては大きくないのですが、「使っていないのにお金が減っていく」というのは精神衛生上あまりよくありませんでした。

ネットワークボリュームでも同じ問題

前回の記事で紹介したネットワークボリュームを使う方法でも、GPU枯渇の問題は解消しません。ネットワークボリュームにモデルを保存しておけば転送の手間は省けますが、起動しようとしたタイミングでそのリージョンに該当のGPUがなければ、そもそもPodを作成できません。ボリュームの維持費だけが発生する状態になります。
これもちょっとあんまりイケてないですね。

現時点でのおすすめ運用

全般的にGPUがかつかつな印象があるので、現時点での私は以下の運用で使っています。

使いたいときに新規でPodを作成し、その都度モデルを転送する。使い終わったらPodを削除する。

stopやネットワークボリュームで「すぐ再開できる状態」を維持しようとすると、GPU枯渇問題と停止中の課金に悩まされることになります。毎回モデル転送で1時間弱かかるのは手間ですが、確実にGPUを確保できるリージョンを選べるぶん、使いたいときに使えないストレスよりはマシだと感じています。

まとめ

Runpodは「クラウドでGPUを借りてStable Diffusionを動かす」という体験としては、思った以上に良くできています。起動の手軽さ、ブラウザだけで使える利便性は素直に評価できます。

一方で、日常的にヘビーに使ったり、安定稼働させたいとなると、ネットワーク転送のオーバーヘッドやGPU枯渇問題がじわじわと効いてきます。
仕事で使っているのに「GPU枯渇してpodが起動できず仕事ができませんでした！」とかは悲惨ですからね。

ただ、「GPUを持っていないけど画像生成を試してみたい」「ローカル環境構築のハードルが高い」という方にとっては、十分に活用できるサービスだと思います。まずは前回の記事を参考に環境を作ってみて、自分の使い方に合うかどうか試してみてください。