/
22/09/26 Stable Diffusion追加学習の記録
検索
複製
Notionを使ってみる
22/09/26 Stable Diffusion追加学習の記録
前にStableDiffusion追加学習のサーベイを書いたが、次は実際に追加学習やってみよう!というわけで、試行錯誤の記録を残しておきたい。
■現状整理
まず、現状で世に出回ってる追加学習の手段をあらためて整理する。
・Textual-inversion
・Dreambooth
・Waifu Diffusion式追加学習
・LambdaLabs式追加学習(ポケモン・ファインチューン)
□Textual-inversion(テクスチュアル反転)
これは、AIに”新しい単語”(例えばS*)を与えて、「この単語はこういう意味ですよ」という感じで3~5枚の画像を見せて、覚えさせるみたいなもんだ。
Textual-inversion(以下TI)はAIモデルそのものは全く変更しない。ごく小さいサイズの埋め込みファイル(プラグインみたいなもん)が生成されるだけらしい。つまり、AIはなにかを追加で学習してるわけではない。単に「”新しい単語”(S*)ってこういう雰囲気の事よね」という感じで既存の学習内容の範囲で表現しようとするだけらしい。
この手法は学習に必要なVRAMが少ないのがメリットだ。birdman氏は「neomimic」という名前で、無料版のGoogle ColabでTIの学習を実行できるColabノートブックを公開している。つまり、VRAM16GB未満で実行できるわけだ。
TIは色んな情報を見てる限りはそれほどいい結果が出ないように見えていたが、こちらでは少女終末旅行のユーリを学習させて、かなりいい感じの結果が出ている。→
□Dreambooth
Dreambooth(以下DB)は「あなたの愛犬が生成した画像に登場しまくります!」みたいな売り込みだ。
TIが雰囲気とかを学習してたのに対して、DBでは与えた画像の物体そのものが埋め込まれるという感じだ。
DBでも与えるのは3~5枚の画像で十分らしい。
色々見てる限りではDBの方がTIよりもイケてる結果が出ているように思った。 例えば比較記事がこちらにある↓
これを見てもやっぱりDBの方がTIより結果が優れてるように思う。
SD公式ディスコにはジョーペンナ氏のスレがあり、そこではDreamboothによる学習が研究されている。→
TIが埋め込みファイルを生成するだけだったのに対して、DBはモデルファイル自体をガッツリ書き換えるので、実際に画像を学習している感がある。
DBは当初、グラボのVRAM30GB以上を要求していたが、9/20のアプデで24GB未満に収まっている。つまり、A100やA6000でなくとも、A5000やRTX3090で実行可能である。
また、さらなる最適化が施されたフォークも登場して、これによりVRAM24GBでもバッチサイズ2で学習可能になったようだ。↓
□Waifu Diffusion式追加学習
Stable Diffusion(SD)はオープンソースでリポジトリを公開してくれたものの、その内容についての説明はあまりしていない。どうすれば追加学習できるのかもサーパリ分からない。
そんな中で、Haru氏はSDをフォークして追加学習させてWaifu Diffusion(WD)を作ったわけだが、その際に必要になった諸々のスクリプトや手順の説明をWDのリポジトリに残してくれている。
そのWDの追加学習方法に則って追加学習に成功しているのが山岡さんだ。
Stable Diffusionにdanbooruデータセットを追加学習する - TadaoYamaokaの開発日記
Stable Diffusionに独自デー タセットで追加学習できるようになるために、まずは既存のデー タセット を使用した学習方法を試した。 追加学習の方法には、画像3~5枚を用いてスタイルを学習させるTextual Inversionという方法があるが、ここでは追加学習にデー タセット を用いて画像をテキスト条件付きで追加学習する方法を試す。 GitHubの Stable Diffusionには追加学習の方法についてドキュメントが用意されていないため、 Waifu Diffusion の方法を参考にした。 Waifu Diffusionは、Stable Diffusionを danbooruデー タセットでファイチューニングしたものである。 Waifu Diffusionがどのように追加学習を行ったか手順は書かれていないが、ファイチューニング用の configファイル が用意されているため、それを使って、トライ&エラーでなんとか追加学習できるようになった。 以下、追加学習の手順について記述する。 環境準備 NVIDIA のPyTorchのdockerイメージを使用する。 docker run --gpus all --shm-size=32g --network host -v /work:/work -w /work -it nvcr.io/nvidia/pytorch:21.10-py3 pip install albumentations==0.4.3 opencv-python==4.5.5.64 opencv-python-headless==4.5.5.64 pudb==2019.2 imageio==2.9.0 imageio-ffmpeg==0.4.2 pytorch-lightning==1.4.2 omegaconf==2.1.1 test-tube streamlit einops==0.3.0 torch-fidelity==0.3.0 transformers==4.19.2 torchmetrics==0.6.0 kornia==0.6 gradio Pillow==9.2.0 pip install git+https://github.com/openai/CLIP.git@main#egg=clip pip install git+https://github.com/hlky/k-diffusion-sd#egg=k_diffusion git clone https://github.com/CompVis/taming-transformers.git cd taming-transformers pip install -e .
https://tadaoyamaoka.hatenablog.com/entry/2022/09/15/214131
この方法は、当初はVRAM40GB以上のグラボでなければ実行できないとされていたが、その後hasuwoof氏によって、VRAM24GBのRTX3090でも実行できる事が立証されている。
VRAMを節約するためにはコンフィグ設定でバッチサイズを1に減らす事と、EMAの使用をオフにする必要があったようだ。EMAというのが何なのかよく分かってないが、これを使用すると学習速度が10%ほど上がるものだそうだ。
WD式追加学習は、実際にWDを作るために使われた手法であり、SDからWDになってアニメキャラ生成のクオリティ向上には目を見張るものがあったわけで、かなり有望な手法と思う。
□LambdaLabs式追加学習(ポケモン・ファインチューン)
9/20に、LambdaLabsはSDをファインチューニングするためのjupyterノートブックを公開してくれた。
サンプルとして作られたポケモンモデルでは、有名人だのキティちゃんだの、何でもかんでもがポケモン風にされてしまっている。
すごいのかもしれないが、なかなか反応に困るシロモノだ。
これは「VRAM16GBあれば動作する、Colabでも動作する」みたいな事を書いていたので試してみたが、完全にウソだった。それどころかVRAM24GBでも動作しない。結局VRAM40GBが必要だった。
まあ詳しくは後で書く。
・あるふ氏によるStable Diffusion改造方法の解説
ところで、あるふ氏がSDの改造方法(追加学習など)についてリサーチした資料を上げてくれていた。
特殊なファインチューニングとしてTIとDBが挙げられているが、普通のファインチューニングとしてDenising Auto Encoder(DAE)だけを使うパターンと、Auto Encoder(AE)も両方学習するパターンがあるらしいというのは知らなかった。
TIやDBは「新しい画像群を概念として埋め込んでいるだけ」だそうだ。 TIはText Encoderを改造しており、物体の雰囲気や画風を埋め込める。 それに対してDBはDAEの方を改造しており、物体そのものを埋め込めるらしい。
Text Encoderは、プロンプトをベクトルに変換するシロモノであり、DAEはそのベクトルに引っ張られながら潜在空間(64x64の画像みたいなもん)上でノイズ除去を繰り返して画像を生成するシロモノのようだ。
さて、ここでAE(オレンジ色のヤツ)とDAE(青いヤツ)は別々のシロモノである事が示されている。
AEは、元画像(512x512)を潜在空間(64x64)に圧縮したり、逆に潜在空間から元画像に復元したりするシロモノだ。
DAEは潜在空間上でノイズ除去するシロモノだ。
そして、DAEだけを追加学習させるパターンだと、AEの方がまったく成長しないため、品質は良くないそうだ。
AEとDAEの両方を追加学習させる事で、潜在空間から元画像に復元する際のクオリティが上がるので、細部がいい感じになる。
Waifu Diffusionは将来のバージョンでこのようなDAEとAEの両方学習をやるかもしれないらしい。
■追加学習に挑戦
□ポケモン・ファインチューニングに挑戦
上で挙げたように4種類のファインチューニング方法があるわけだが、私はとりあえずポケモン・ファインチューニングを触ってみることにした。
というのも、学習のためのjupyterノートブックを提供してくれていたからだ。さらに、VRAM16GBで動作(つまりGoogleColabで動作)するかのような記載があった点にも惹かれた。(ウソだったけど)
ノートブックは最近初めて触れたばかりだが、何も考えなくてもマウスポチで動作してくれて便利だ。結果がその場ですぐ見れる所もいいし、ソース改造もその場でできるし、LambdaLabsやRunPodなどでもノートブックを即実行できる環境がデフォルトで用意されていて、GoogleColabでも動いて、なんならローカルでも動くし、色んな環境で動かせるところも素晴らしい。
というわけでこのノートブックをGoogleドライブに入れてColabで実行してみた。
一瞬学習が始まったかに見えたが、すぐにエラーで落ちた。この時はプロセスキルだったが、もう一回試したら結局OOM(out of memory)エラーが出た。要するにVRAM不足だ。
ここまでやってしまったらもう引っ込みがつかない。 VRAM16GBで足りないなら24GBあればいいだろう!と思って、RunpodでVRAM24GBのA5000やRTX3090のインスタンスを借りて、ノートブックを実行してみたが、やはりOOMエラーが出てしまう。
なんだよ、結局VRAM40GB無いと実行できないんじゃねえか!実際、ポケモン・ファインチューニングを学習した環境は、LambdaLabsのA6000(VRAM48GB)が2台だったそうだ。(学習時間は6時間程度)Colabでも動くかもみたいなウソ書いて期待させるのはよせ!(まあA100引けば動くだろうけど)
実際、A6000インスタンスを借りてみたら、ちゃんと学習が始まる所が見れた。→
ところで、LambdaLabsのjupyterのエクスプローラから学習したチェックポイントをDLしようとしたら、ダウンロード速度が300k~1MB/sしか出なくて、かなり待たされるという罠がある。
さしあたって動作出来たので満足なのだが、なんとかVRAM24GB環境で実行できないか、検証しておきたいと思った。
というのも、24GBに収まれば、RTX3090やRTX4090のような一般家庭用(?)グラボさえ買えば家のPCでもSD追加学習し放題になる道が開けるからだ。ちなみに現在の私のPCのグラボはGTX1080で、VRAMは8GBしかない。
そもそもの前提の話を書き忘れていたが、何が悲しくてクラウドのGPUインスタンスに課金してああでもないこうでもないと言ってるのかというと、SDの学習に必要なVRAMが大きすぎて、TIを除いてはクラウドのA6000やA100を借りないと話にならないのが問題というわけだ。(NVLinkでスタックされたA4000インスタンスとかでも行けるのかな?未検証) さらに言っておくと、SDの登場によって、AIの学習競争が過熱しているらしく、VRAM40GB以上のA6000やA100のインスタンスは、LambdaLabsでもVast.aiでもRunpod.ioでも常に売切れっぱなしである。VRAM24GBのRTX3090やA5000ならまだ割と借りられるわけで、クラウドで学習させるにしてもVRAM24GBに収める事が重要という事だ。(AWSやGCPならインスタンスが売切れる事なんてそうそう無いだろうが、しかし料金が高い) また、VRAMの消費が16GB未満までに収まるようになれば、GoogleColabで学習できるようになるので嬉しい。
それで思い出したのが、hasuwoof氏はRTX3090(VRAM24GB)でSD学習に成功したという話だ。 どうやってそれを実現したかというと、バッチサイズを1に減らした事と、EMAを無効化しただけらしい。
この話に従って、まずコンフィグファイルでEMAを無効化してみた。 configs/stable-diffusion/pokemon.yamlだ。変更した個所は2点。
①model:params:の下に”use_ema: false”を追加する。
②末尾のあたりの、lightning:callbacks:params:log_images_kwargs:use_ema_scopeを一応Falseにする
それから、ノートブックの#Run trainingの項目をいじって、バッチサイズが1になるようにした。
これで、RunpodのA5000(VRAM24GB)で実行してみたら、見事に動作した。
つまり、hasuwoof氏が言うような、VRAM24GBでも学習できるという話が立証できて、家庭のPCでSD学習できる道が開けたわけだ。
それはいいのだが、気になる点もあった。SDは学習中に、学習の経過を画像出力(sample)してくれるが、それが単なるノイズ画像になってしまっていた。→
ファインチューニングは元のモデルを微調整してくもののハズだが、これではまるでゼロベースから学習が始まってるように見える。
これはこういうものであって、しばらく学習を続ければちゃんといい感じになるのだろうか? それともEMA無効化とかの悪影響で学習に失敗してしまってるのか? もっと学習を進めてどうなるか見ておくべきだったが、この時はとりあえず動作確認だけして中断してしまったため、検証できていない。
特筆すべき点として、ポケモン・ファインチューニングでは学習率(Learning Rate:LR)がデフォルトの1e-4に設定されていた。これは山岡さんが過学習に陥ってしまった学習率だ。
何故ポケモン・ファインチューニングはこんな高すぎる学習率で上手く行ってるのかは気になる所だ。データセットのポケモン画像のスタイルが一貫してるところがポイントなのかも。とは言え何を生成させてもポケモンになっちゃうモデルというのはある意味で完全に過学習に陥ってると言えるかもしれない。
動作検証が済んだところで、これ以上ポケモンなんか学習させてもしゃーないので、自前のデータセットを食わせたいところだ。
私の目論見としては、まどマギの美樹さやかさんの画像を食わせまくってSayaka Diffusionを作る事を目論んでいた。というのも、trinartキャラクターズモデルがまどかちゃんはしっかり描けるクセに、さやかさんは超うろ覚えだったのが不満だからだ。
で、ポケモン・ファインチューニングに独自データセットを食わせる方法は、「HuggingFace標準データセット形式でデータを用意すればいい」と書かれている。
サンプルのポケモンデータセットを見ると、parquetファイルという、未知のファイル形式だった。
ググってみても、parquetファイルの中身を見る方法も、parquetを作成する方法もサッパリ分からない。
どうしようもないので、ポケモン・ファインチューニングでSayaka Diffusionを作るのは一旦諦めた。
□WD式追加学習に挑戦
ポケモン・ファインチューニングは一旦諦めたが、山岡さんの成功例の報告があるWD式追加学習にチャレンジしてみる事にした。
RunpodやLambdaLabsでA5000かRTX3090を借りたと思う。
最初に、自分なりの方法でやってみたのだが、何故かどうしても学習実行時にエラーが出てしまう。
File "[main.py](http://main.py/)", line 721, in <module> trainer.fit(model, data) ・・・ RuntimeError: Error(s) in loading state_dict for LatentDiffusion: Unexpected key(s) in state_dict: "model_ema.decay", "model_ema.num_updates", "model_ema.diffusion_modeltime_embed0weight", "model_ema.diffusion_modeltime_embed0bias", "model_ema.diffusion_modeltime_embed2weight", "model_ema.diffusion_modeltime_embed2bias", "model_em
Plain Text
エラー内容を見ると、state_dictに想定していないキーが含まれている…みたいな文句を言われてるようだ。WDのモデルじゃダメって事?と思ってSDモデルも試したが、同様のエラーが出る。
ひょっとすると、最近のWDリポジトリの更新で何かが壊れてしまったのかも?
エラーの原因は追いきれなかったが、あらためて山岡さんの記事に厳密に従ったらうまく動作したので、上手く行ったパターンを記録しておきたい。
・インスタンスを起動
インスタンスはRunpod.ioのセキュアクラウドのA5000x1を借りる。(A100やA6000が借りたくても、Runpodでは常に在庫が売切れている。A5000しか借りられないのだ。結局VRAM24GBでやり繰りするハメになる)
まず、WDのドキュメントに書かれてる、WD追加学習用のDocker imageを使わせてもらう事にする。
ghcr.io/derfred/waifu-diffusion
Runpodで指定したDocker imageを起動するには、カスタムテンプレートを作成して、Container imageでimageを入力する。
Docker Commandになんかワチャワチャ書いているが、これはインスタンスにSSHやSCP、SFTPで接続するために必要なものだ。詳しくはこちらの記事に書いてある。↓
この設定をしなくても、Webターミナルで操作する事は可能だが、SCPやSFTP無しでダウンロードやアップロードなどファイルのやり取りをするのはかなり面倒な話になる。
Runpodではインスタンス代以外にも、ストレージ代も取られるが、SDは学習中にエポックごとにチェックポイント(モデルデータ)を出力する。これが一つあたり10GBくらいあって、かなり容量を食う。
学習途中でディスクが埋まってエラーが出ちゃうとアホらしいので、Volume Diskはそれなりに大きく取っておいた方が無難だろう。今回は250GBとした。
ところで、Runpodでは、Webターミナルからアクセスすれば問題無いが、SSHで接続するとなんかpythonやらpipやら一切入ってない状態になってしまっている。
これはDocker使いにとっては当たり前の事をなにか見落としてるんだろうか?Dockerについてはあまり詳しくなく、よく分からないので誰か詳しい人がいたら教えて欲しい。
とにかく、今回はWebターミナルから操作する事とする。
あとでpybooruというモジュールが必要なのでインスコする。
pip install pybooru
Shell
作業ディレクトリ(/waifu)をVolume Disk(/workspace)へと移動する。Volume Disk内のデータはインスタンスを一時停止しても保存されるが、Container Disk内のデータは消えてしまうためだ。
cd .. cp waifu workspace/waifu cd workspace/waifu
Shell
(ちなみに、Dockerコンテナ内のディレクトリ構造はあまり弄らない方がいいらしい。私は最初、waifuディレクトリをワークスペースに移動(mv)していたのだが、それだとWebターミナルに接続できなくなるなどの不具合に遭遇した。移動じゃなくてコピー(cp)にしておいた方が良さそうだ)
・データセットの準備(スクレイピング、ダウンロード、リサイズ)
次に、データセットを準備する。
まずはDanbooruから画像ダウンロードに必要な諸々の情報をスクレイピングしてくる。
あらかじめDanbooruでアカウントを作ってAPIキーを作成しておく。
スクレイピングするコマンド↓
python danbooru_data/scrape.py -user username -key apikey -t "miki_sayaka order:score age:<90month"
Shell
“username”と”apikey”の部分は置き換える。 また、-tの引数部分は、今回は「90カ月以内に投稿された、”miki_sayaka”タグの画像」という条件にしているが、適宜置き換える。
次に、スクレイピングされたリスト(links.json)を元に、画像とキャプションをダウンロードする。
python danbooru_data/download.py -f links.json -o danbooru-aesthetic/
Shell
次に、ダウンロードした画像を512x512にリサイズする。山岡さんの記事に従い、danbooru_data/local/convert.pyを以下のように書き換える。
WinSCPで接続できていれば、テキストエディタで書き換えれば済むが、Webターミナル接続しかできない状況だと、nanoを使ってターミナル上で編集するのがいいだろう。
from PIL import Image, ImageOps import os import argparse parser = argparse.ArgumentParser() parser.add_argument('in_dir') parser.add_argument('out_dir') args = parser.parse_args() directory = args.in_dir for filename in os.listdir(directory): var1 = os.path.join(directory, filename) if os.path.isfile(var1): print(var1) try: im = Image.open(var1) im = ImageOps.pad(im, (512, 512), color='black') im.save(os.path.join(args.out_dir, filename)) except: print('skip')
Python
では、画像リサイズを実行する。
cd danbooru-aesthetic mv img img_org mkdir img python ../danbooru_data/local/convert.py img_org img
Shell
ちなみに、このリサイズでは画像のアス比が正方形じゃない場合に、上下か左右に黒いレターボックスが付けたされる。ディスコで見かけた話題だが、このような画像を学習させると生成された画像にもレターボックスが出てしまいがちらしい。かと言って、画像をクロッピングしてしまうと、頭や手足が見切れる画像になりがちだ。waifu-diffusionは頭が見切れる画像をお出ししがちだが、それはデータセットをセンタークロッピング処理してしまったせいらしい。
ところで、WD式追加学習ではデータセットの形式は、まず親フォルダの下にimgフォルダとtxtフォルダがあり、imgフォルダの中には画像が、txtフォルダの中にはキャプションがズラッと入った状態で、画像に対応するキャプションはファイル名が同じである必要があるみたいだ。
だからtextフォルダはtxtにリネームする必要がある。
mv text txt
Shell
では、追加学習を行うAIのモデルをダウンロードする。山岡さんはSDをDLしているが、今回はWDに対して追加学習してみたいので、モデルをDLする。
cd /workspace/waifu wget https://thisanimedoesnotexist.ai/downloads/wd-v1-2-full-ema.ckpt
Shell
次に、チェックポイントに空のoptimizer_statesを追加する。 よく分からないが、追加学習時のresume(学習再開)に必要となる物らしい。
これはpythonコードなので、pyファイルとして保存して実行するか、pythonに入って1行ずつ実行してもいい。
import torch ckpt = torch.load('/workspace/waifu/wd-v1-2-full-ema.ckpt') ckpt['optimizer_states'] = [] torch.save(ckpt, '/workspace/waifu/model.ckpt')
Python
山岡さんの記事ではここでDejaVuSans.ttfのダウンロードを行うが、今回のDocker Imageではすでに用意されているので必要ない。
さて、ここでhasuwoof氏が共有してくれた、RTX3090で学習に成功したコンフィグファイルを持って来る。
config/stable-diffusion/custom.yamlという名前でこの内容を保存する。↓
hasuwoof氏のコンフィグファイルから、一か所だけ、ckpt_pathをSDのモデル名から書き換えている。
・追加学習実行
準備ができたので、いよいよ追加学習を実行する。
python main.py -t -n "waifu-diffusion" --base ./configs/stable-diffusion/custom.yaml --no-test --seed 25 --scale_lr False --gpu 0, --data_root "./danbooru-aesthetic"
Shell
Epoch 0: と表示されてゲージが伸び始めたら、めでたく学習が始まったという事だ。
あとは学習が進んでいくのを気が済むまで待つだけだ。
ところで、Webターミナルの画面を閉じたり、PCをスリープ状態にすると、ターミナルが切断されて、学習が中断されてしまう。 寝ている間に学習させたかったのに、これではPC付けっぱで寝るハメになる。
screenを使えばバックグラウンド実行させられるので、ターミナルを閉じてもPCをスリープにしても学習を継続してくれると分かった。
screenをインストールして、screenのセッションに入る。
apt install screen screen
Shell
セッションの中で先ほどの学習開始コマンドを叩けば、バックグラウンド実行できている事になる。
セッションから抜ける時は、Clrl+Aを押してから、Dを押すと抜ける。(デタッチ)
もう一度セッションに入るには、screen -rコマンドで入れる。
セッションに入るとなんかコンソールの表示がバグりがちだが、見た目の問題だけなので気にしないでいい。
・学習完了
さて、学習が始まったのはいいが、いつまで学習させればいいのだろう?初めてなのでまったく勝手が分からない。
学習中に、時々画像生成が行われて、logs/日付/images/trainの中に保存されていく。 私はてっきりこの中のsamples_~.pngという画像が学習成果の出力なのだと思っていた。 しかし、このsamples画像はいつまで経ってもグチャグチャな画像しか生成されなかった。
6エポック目に生成されたsamples
33エポック目
51エポック目
なんちゅうか…たしかに学習されとるっちゃされとるけど、基本的な画力が崩壊してないか?もしかして学習に失敗してる…!?みたいな感じで、かなり不安に駆られた。
かと言って途中で止めちゃうのもそれはそれで怖いので、9/27の0時くらいから学習開始して、28日の朝に、いい加減一旦止めようかな…と思った。
試しに最新のチェックポイントで画像生成をテストしてみよう。
わざわざチェックポイントをダウンロードしなくても、インスタンス上で画像生成する事は可能なハズだった。
しかし、scripts/txt2img.pyを実行してみると、「引数が解釈できない」だか何だかワケ分からんエラーが出てしまう。何とかする方法を知ってる人がいたら教えて欲しい。
また、学習しながら画像生成しようとすると、VRAMに余裕が無い今回のA5000ではほぼ間違いなくOOMエラーが出てしまうと予想される。
しょうがないので、手元にチェックポイントをダウンロードする。
ところでRunpodのデータをSCPやSFTPでダウンロードすると、かなり遅い。悪い時で0.8MB/s、いい時で1.6MB/s程度の速度しか出ない。
チェックポイントは一つあたり10GBあるので、相当DLに時間がかかる。(1時間半~3時間半)
そこで、チェックポイントを剪定(prune)しておく。 チェックポイントには、学習の時は必要だけど、画像生成するだけなら不要なEMAなどのデータが大量に含まれている。これを削除する事でモデルのサイズは10GBから2GBまで一気に減らせる。
剪定を行うには、scripts/prune.pyを実行するだけでよい。
まずこのprune.pyを開いて、一番下のモデルファイルへのパスをlast.ckptのものに書き換える。
あとは
python scripts/prune.py
Shell
で剪定されたモデルファイルが生成される。
これをWinSCP(SFTP)でDLした。数十分かかる。
ダウンロードしたモデルで画像生成する方法は、まあ何でもいいのだが、手軽だったのでNMKDを使った。
WindowsでGUIでStable Diffusion画像生成が行えるツールだ。
Data/modelsフォルダにモデルを入れれば、そのモデルに切り替えて画像生成を行う事も簡単だ。
ここで切り替えできる↓
てなわけで、追加学習させたチェックポイントで、プロンプトは”miki_sayaka”(Danbooruのタグ形式)だけ入れて生成させてみた。
うおっ!すげええええええ!!このAIすでにさやかさんの事完全に理解してもうてる!!無限にさやかさんが生成される!!やっべえ!追加学習大成功や!!Sayaka Diffusionの完成だ!!
これがどれだけすごいかというと、例えば素のStable Diffusionで”miki_sayaka”で生成してみると、↓
ご覧の通り、何一つ理解できてねえ。まあ一応ギリギリ、アニメキャラでなんか青っぽい女の子という事だけは知ってるようだが。。
では、追加学習する前のWaifu Diffusionではどうだろうか?↓
この体たらくである。まあ画力はSDより上がってるが、これを見てだれがさやかさんだって分かるんだ?
あのtrinartキャラクターズモデルでさえ、この程度だ↓
全然違うよ!おまえ完全にミリしらだろ!!
さて、これを踏まえて考えると、今回のファインチューニングの成果がいかに奇跡みたいなクオリティ向上をもたらしているかがよく分かる。
ちゃんと美樹さやかさんだと分かる衣装と顔が描けている時点で凄すぎる。
ちなみに、”マクドナルドでメシ食ってる制服着てるさやかさん(miki_sayaka in school_uniform eating lunch at McDonald's)”を描かせたらこうだ↓
う~ん、素晴らしい。
ここで興味深いのは、なんか全然指定してないのに杏子ちゃんが入り込んじゃう事だ。 普通に隣に座って一緒に食ってるのは分かるんだが、他の画像でもモブとして絶対に同じ画面に映り込もうとしてくる。 AIは杏子ちゃんの事を「なんか知らんけどさやかさんの隣にいつもいる人」として学習してしまってるようだ
AIは見滝原中学の制服の事も結構理解しているようだが、たまに色を間違えたりしている(右上)。というか、杏子ちゃんのパーカーの色とゴッチャになってる気がする。左下の画像では、何故かさやかさんの方がパーカー着ちゃってるし。
このチェックポイントは、50エポックほど学習させた時点の物だ。
あまり学習させすぎると、過学習に陥るリスクがあるが、今回の生成結果を見る限りは崩壊してないので過学習には至ってないように見える。ちなみに学習率は5e-6だ。
というわけで、学習が成功した結果にはきわめて満足を覚えたが、一応このあと75エポックまで学習させてから止めた。
ちなみに、学習の止め方はCtrl+Cで止めるだけである。
これで、直近までのデータがlogsのlast.ckptに保存される。
学習が終わったので、必要なデータをインスタンスからDLして回収する。 必要なのは、何は無くともまずlast.ckptだ。また、途中で自動保存されたチェックポイント(ckptファイル)もある。19エポック時点の物と、60エポック時点の物だ。後で比較するためにこれらも回収しておきたい。 (チェックポイントはひとつあたり10GBあって容量を食うので、大量に生成されてもストレージが圧迫されて困るが、とは言え10エポックに1回くらいのペースで生成してくれてもいいと思うが、これはコンフィグファイルから設定できるのだろうか?)
他にダウンロードしておきたいデータとしては、まあlogs内のtesttubeというフォルダに学習の経過(メトリクス)が記録されているので、ダウンロードしておくと後々何かに使うかもしれない。 データセットの画像やキャプションは、正直どっちでもいいかなという感じ。次回の学習ではまたDLし直せばいいような気もする。
ではckptファイル群をDLする。 19エポックと60エポックのckptは、検証に使うだけで、ここからさらに追加学習させる事も無さそうなので、prune.pyで先ほどと同様に剪定してからSFTPでDLすればいいだろう。
というか、剪定されたモデルは追加学習に使用できないのだろうか?試してないので分からない。 last.ckptはひょっとすると今後追加で学習させるかもしれない。だから一応剪定しないでDLしておきたい。
さて、上でも書いたがRunpodのDL速度は遅い。そこで一つのテクとして、WinSCPを3つ開いて3つのckptを一つずつDLさせるみたいなテクがある。試した限りでは、ダウンロードセッションを増やしても、それぞれのDL速度は落ちないようだ。
他の手としては、CloudSyncという機能を使ったり、Dropbox Uploaderを使う事でより高速にデータをDLできる。これらについては下のRunpodの項目で説明する。
で、ついでに確認しておきたいのが、学習再開(resume)の方法だ。 上で書いた学習開始のコマンドをもう一度叩くと、当たり前だがまたゼロから学習開始してしまう。 普通に考えるとコンフィグファイルのckpt_pathをlast.ckptのパスに置き換えればいいんじゃないだろうか?
これで学習開始すると、普通に始まったので、一応1エポックだけ追加学習させてからckptを回収しておいた。
データの回収まで済ませれば、もうRunpodのインスタンスは停止して、削除してしまっていいだろう。(私は一応この記事を書き終えるまでは停止だけして削除はしていない。この状態だとストレージだけは保存されていて、ごく少額の課金(0.06ドル/時間)がかかる)
・結果の検証
というわけで、結果的に手元にはいくつかのckptが残ったので、これらをつかってあらためて結果を検証してみたい。
まずは、最終的に75エポックまで学習させたckptで”miki_sayaka”を出力させてみる。
ん…? なんかキミ、50エポックの時より下手になってない?いや、と言うよりはイラストとしての様式化が進んだという事なのだろうか? それより気になるのが、衣装の布面積が減ってないか?
AIお前、スケベになってるだろ!
いや、これは私が食わせたデータセットに問題があったかもしれない。エロも全年齢もごちゃ混ぜのデータを与えてしまった。Danbooruからのスクレイピング時に、全年齢向けのイラストだけでフィルターすべきだったかもしれない。
恐らくAIは、魔法少女服のさやかさんと全裸のさやかさんを交互に見せつけられた結果、足して2で割って、衣装から布面積を減らすという選択をしたのではないかと考えられる。
まあ、マクドナルドのさやかさんも描かせてみよう↓
う~ん、50エポックの時より様式化が進んでるのは同じだが、さやかさんとまどかちゃん、ほむらちゃん、杏子ちゃんとのキメラ化が進行してる気がする…。一目でさやかさんだと分かるキャラの打率が減って、混ざり始めてる
これはひょっとすると、過学習に陥ってる…かもしれない。もっと学習率を下げるべきだったか、あるいはデータセットの2300枚は少なすぎたか…。
気を取り直して、60エポックckptでも生成してみる。
なるほど…まあ50エポックと75エポックの中間の傾向という感じ。普通に杏子ちゃんとか出したりしてしまう。
19エポックckptだとこうだ↓
さやかさん単体では、まあボチボチの結果が出ているが、マクドナルドに行かせてみると、AIの理解の足りてなさが露呈している。
1エポックだけのckptもある↓
たった1エポック回すだけでも、それなりにAIの理解が進んでいる事が分かる。だが、マクドナルドの方は全然話にならない。「miki_sayakaって日本人の女の子の名前だよね」程度の認識しかなさそうだ。
そういえば、75エポックで一旦学習を止めてから、再開(resume)させて1エポックだけ追加学習させてみたチェックポイントもあった↓
あれっ?なんか変だぞ?なんか壊れてないか?
resume方法が間違っていたのだろうか?誰かこれについて正しい方法を知ってたら教えて欲しい。
・結論
この結果を踏まえて何が言えるかという話だが、結局、個人的にはたまたま保存しておいた50エポック目のckptが一番いい感じに思えた。
だが、もっと色々なプロンプトを比較すれば、それぞれのckptの長所や短所がもっと見えてくるかもしれない。使い分けなのかもしれない。 そういえばtrinart V2モデルも6万ステップ、9万5千ステップ、11万5千ステップの3種類が配布されている。やはり、一概にどれが一番いいとも言えないなあ…という話になったのだろう。高ステップモデルほどスタイライズが強くなるそうだ。これも今回の結果と一致する。
やはり、同じ絵を何回も学習させて結果を良くしていくにも限界があるらしい。もっと沢山学習させるほど結果を良くしていきたいなら、データセットの規模を大きくしていく事が必要だろう。
結論1:必ずしも学習させればさせるほどいいってもんではなさそう
今回初めて追加学習を試したわけだが、結果は満足のいくものだった。 AIは特定のキャラの画像を重点的に追加学習させれば、ちゃんとそのキャラだと分かる顔、衣装、絵柄の画像を生成できるようになると分かった。
このモデルがあれば、さやかさんの画像を無限に生成できるわけだ。 これをまどかちゃん、ほむらちゃん、マミさん、杏子ちゃんに対して同様に行う事もできる。 しかし、一つのモデルで全員学習させるのと、キャラごとにモデルを作るのとではどちらがいい感じになるのだろうか?
データセットの話で言うと、今回はとにかく”miki_sayaka”タグが付いてる画像というシンプルな条件で収集した。 上でも書いたが、エロ画像の割合が多すぎたせいか、学習するほど衣装の布面積が減っていく現象が起きているかもしれない。全年齢だけでフィルターした方が良かったかもしれない。
また、”solo”(キャラ単体絵という意味)タグも条件に入れた方が良かったかもしれない。今回はさやかさんさえ含まれてさえいれば、他のキャラとペアになってる画像も沢山含まれている。これは何も指定してなくても一緒に杏子ちゃんが映るなどの副次的な効果はあるものの、キャラがキメラ化したり、別キャラと混同しちゃう傾向を生むようだ。
特にさやかさんと杏子ちゃんのペアの絵が多いらしく、AIは二人の見分けがあまり付いてないように見える。(ネガティブプロンプトで”sakura_kyoko”を入れるなどすれば済む問題かも)
また、画像のトリミング方法も検討の余地があるかもしれない。今回は左右か上下にレターボックスを追加する方法を使用した。そのせいで割と生成画像にもレターボックスが出てしまっている。
さて、まどマギは人気のアニメだったから、大規模なデータセットを用意できるので、特定キャラを学習したモデルを作る事が可能だったが、二次創作ならそれでいいとして、一次創作だとどうやれば自分のオリキャラを無限生成できるAIが作れるだろうか?
まあ…自分で数千枚の絵を描けばいいのかもしれないが…それができるならそもそもAIを作る必要は無いだろう。
Dreamboothなら数枚の画像でもその人物を学習できるという話らしいので、それなら数枚の絵を描いて食わせれば済む事になる。これは一度試してみたいところだ。(100枚くらい食わせた方がいいという説もある)
結論2:十分なデータセットを用意できるキャラならば、AIにそのキャラを覚えさせることは可能
さて次に、追加学習のコスト面について見てみよう。 今回は、2300枚の画像で75エポック学習させた。のべ17万回ほどの学習だ。
R5000は1.5回/秒ほどの学習速度だ。 つまり、32時間くらい学習させたことになる。
インスタンス料金は0.39ドル/時間だが、ストレージ代込みだと0.46ドル/時間ほどだった。
スピーディに学習させてれば、合計で14.72ドル、2千円ほどかかった事になる。(もし50エポックで止めていたら1400円くらい)
これを高いと見るか安いと見るか…。
ちなみにだが、Waifu Diffusionの追加学習コストは166ドルだったらしい。あれだけのイラストのクオリティ向上を、たった2万円ほどで成し遂げられたというのなら、メチャメチャコスパいいと思う。(しかしHaru氏は諸々合わせると数百万円をすでに投じてるらしい)
Waifu Diffusionは5万6千枚の画像を食わせたらしいが、次期バージョンでは一気に60万枚にふやすらしい。そうなるとコストも10倍ほどになるだろう。
現在、AI学習にはVRAMの壁がある事が分かる。
最初にあるのは16GBの壁で、VRAM使用量が16GB未満なら、GoogleColabで無料で実行させることが可能になる。Dreamboothは早くもVRAM使用量12.5GBに抑えられたバージョンが発表されて、Colabで実行する事が可能になっている。
次は24GBの壁だ。24GB未満なら、家庭用のRTX3090やRTX4090で学習させる事が可能だ。また、Runpodでいつでも借りられるA5000で実行できる。 これ以上になるとクラウドのA6000かA100でもないと実行できない。RunpodでもこれらのGPUは常に売切れているので借りたくても借りられない。相当ハードルが上がってしまう。
今回やった普通の追加学習はVRAM24GB未満に収まっている。これはクラウドで2千円程度ですむコスト感だ。
しかし、Dreamboothが12.5GBまで減るんだったら普通の追加学習も16GB未満に収まるんじゃないか?いずれ無料で追加学習できるようになる気がする。
ちなみにだが、私が現在慌てて追加学習などを調査しているのにはワケがある。 10/12にはRTX4090がいよいよ発売されてしまう。これを買うべきか買わないべきかという判断を来月までにしておきたいわけだ。
RTX4090は30万円するらしい。しかし、その性能はバケモノだ。 A100はVRAMこそ40GBと豊富だが、演算性能は単精度19.5TFlops程度しかない。RTX4090は82.58TFlopsに達する。4090が1枚あれば、A100の4倍の学習速度が期待できてしまう。
しかし、RTX4090の電力消費はハンパない。試しに試算してみると、1ヶ月間ずっとぶん回すと1時間当たり21円、月額1万5千円ほどかかるようだ。
RunpodでRTX3090を借りても1時間当たり0.3ドル(42円)程度しかかからない。
結局、どの時点でトクになるのか?というと、2年間ずっとぶん回した時点で家4090のコストが66万円(30万円+電気代36万円)でRunpod3090が72万円で、この辺からトクになってくる。
さらに、4090のパフォーマンスは3090の2倍以上なので、実質1年もあれば4090買った方がトクになってくると言える。
とは言え、自分が実際どんだけガチンコで追加学習にのめり込むかにもよる。すぐ飽きちゃうなら4090なんて必要ない。
他にも気になる点はある。9/22にEmad氏が意味深なツイートをした。→
これは、”v2 raw"というのはSDのver2.0からの撮って出し画像だという意味で、この画像の解像度が1024x1024という事は、現在SDのver2.0は解像度1024の画像で学習してて、1024x1024が最適解像度として出力できるようになるという意味ではないか?という推測が出ている。
AIの学習を1024x1024画像で行えば、必要なVRAMの量も爆増する。これが当たり前になれば、結局24GBじゃVRAMが足りなくて、4090を買っても無用の長物になっちゃうというシナリオもあり得る。
結論3:AI学習目的でRTX4090を買うべきか否かは、相当判断が難しい
さて、この次にやってみたい事としては、Textual-InversionとDreamboothも同様に試してみて、今回の結果と比較してみたいところだ。
■格安クラウドGPUのメモ
□vast.ai
vast.aiは、サーバーのPCを借りるのとは違って、だれでもPCを時間貸ししたり、借りたりできるサービスだ。
A6000x4のインスタンスが1.61ドル/時間で借りれるらしい。たしかに安い。
だが、今見る限り、A6000のインスタンスは全て売り切れている。いくら安くても在庫が無ければどうしようもない。
他の在庫があるGPUをみると、RTX3090が0.3ドル/時間、A5000が0.2ドル/時間くらいだ。
vast.aiは会員登録時に10円くらいもらえるから試用した感じは良さそうだった。 だが、何故かクレカの課金が通らなかったので、それ以上試せてない。
ちなみにコンビニでVプリカを買えばvast.aiの課金が通るらしい。→
誰とも知れぬ個人のPCを借りるわけで、実際には動作しない詐欺インスタンスとかも混じったりしてるらしい。
□LambdaLabs
LambdaLabsは普通に使えるGPUインスタンスを安く提供してくれている。 A100(40GB)は1.1ドル/時間で借りられる。Runpodだと80GB版が1.79ドル/時間かかる。 だが、A6000(48GB)は0.8ドル/時間で、Runpodの0.64ドル/時間より高い。
まあ、いずれにせよ在庫が無くて全然借りられないんだが。
LambdaLabsは素直なインスタンスなので、中でdocker runを走らせたりもできる。 秘密鍵の扱いも簡単だ。インスタンス生成時にGenerate Keyでカギを生成させれば、秘密鍵のファイルがDLできるのでそれを使えばOKだ。
ただし、DLした秘密鍵のパーミッションを適切に設定する必要がある。参考になるのはこちら↓
🐚【Windows PowerShell】SSH接続する際にパーミッションエラーが発生した場合の権限変更 - Qiita
Windows 10 Windows PowerShell EC2のインスタンスに接続したいがキーファイルのパーミッションでエラーが出る windowsなのでchmodが使えないのでファイルのプロパティから変更を行う 先ずはキーファイルのプロパティからセキュリティタブを押下 設定が下記の様になっているはず 「編集(E)」を押下して現状のすべてのグループ名またはユーザ名を「削除(R)」から削除し その後に現行のアカウントを追加してフルコントロールを許可します 削除の際に下記メッセージが表示された場合は一旦「OK」を押下して前画面に戻ります 「詳細設定(V)」を押下してセキュリティの詳細設定を開き、「継承の無効化(I)」を押下 ↓ 「継承されたアクセス許可をこのオブジェクトの明示的なアクセス許可に変換します。」を選択 「継承の無効化(I)」が「継承の有効化(I)」に変わったら「OK」で画面を閉じる ↓ 再度「編集(E)」を押下してすべてを削除 「追加(D)」からユーザ または グループ の選択を開き 選択するオブジェクト名を入力してくださいの枠内にログオンしているアカウント名を入力して「名前の確認(C)」押下 ↓ 複数表示される場合は正しい方を選び「OK」で閉じる ↓ 残った現行ユーザにフルコントロールを与えて「OK」 これでSSH可能になります 尚、フルコントロールを与えていないと下記のPermission deniedになります
https://qiita.com/eltociear/items/02e8b1f5590b49eb9d87
jupyterノートブックはすぐさま使えるIDE環境がデフォルトで入ってるのですぐさま実行できる。
“Storage”という機能があり、インスタンスを停止してもストレージ(RunpodでいうVolume)を保存しておける。この機能は現在ベータ期間なので無料で使えるようだ。
そんなわけで、今回はちょっと触ったくらいだが、値段が安くて普通に動かせて、便利だと感じた。
ただし、上でも書いたがファイルのダウンロード速度が300k~1MB/sしか出なかった。これには呆れる。(まあ帯域が無料ってだけでもありがたいのかな)
□Runpod.io
Runpodに対しては言いたい事が色々とある。
RunpodはサーバーといってもDockerコンテナを動かすのが前提のサービスだ。
LambdaLabsのように、データセンターだかサーバールームのインスタンスを借りられるセキュアクラウドと、vast.aiのような個人貸しのPCが借りられるコミュニティクラウドの両方が用意されている。
Runpodでも、VRAMが潤沢なA100やA40、A6000は常に売切れている。在庫があるのはせいぜいA5000やRTX3090くらいだ。
Runpodもノートブックを実行するだけならデフォルトで環境がセットアップされるので、何も考えなくても簡単に実行できる。しかし、普通にSSHやSFTPで接続したいとなると、ややこしい設定を弄くるハメになる。
・スポットインスタンスはアカン
まず、スポットインスタンスとオンデマンドインスタンスの2種類があるが、スポットインスタンスというのはAWSと同様に、値段は半額くらいで安いけど、いつ強制停止されても文句言えないというものだ。
私は最初、ためしにスポットの方を使ってみたが、遮断って言っても数日間くらいなら大丈夫だろと踏んでたが、それどころか、10分や20分そこらで毎回遮断されてしまう
ハッキリ言って使い物にならない。いくら半額とは言え、これをオトクに使いこなすのは相当難しいんじゃないだろうか。少なくともAI学習用途ではスポットインスタンスはオススメできない。
・コミュニティクラウドは怪しい?
それで、コミュニティクラウドのRTX3090を借りてみた。RTX3090はA5000に比べると、安い(RTX3090:0.3ドル/時間 A5000:0.39ドル/時間)うえに学習速度が速い(RTX3090:1.9回/秒 A5000:1.5回/秒)。合わせると65%くらいRTX3090の方がコスパが高い。
しかし、使っていてどうも挙動が怪しい事がチラホラあった。例えば学習が時々完全に停止して進まなくなってしまう。なにサボッてんだコイツ。コミュニティクラウドは完全に個人のPCでしかないから、例えばグラボが壊れかけだったりするかもしれないし、悪意のある細工がされているかもしれない。
いずれにせよ、なんか不安定だったので、コミュニティクラウドはやめて、セキュアクラウドのA5000に乗り換えた。
今思うと、コミュニティクラウドで優れたインスタンスはすでに全部借りられちゃってて、あとはろくでもないハズレのインスタンスだけが売れ残ってるという状況だった可能性もある。
他にも理由はある。公式の説明では、TCP対応と書かれているインスタンスならSSH、SCP、SFTPで接続できるハズだったが、実際には繋がらない
WinSCPから接続できなければ、pythonスクリプトやコンフィグファイルのテキストをちょこちょこ編集するのにターミナル上でやるハメになって、面倒だ。
そもそも、SCPやSFTPが無ければ、ファイルのアップロードやダウンロードができないではないか。一体どうすればいいのか?
そこで、RunpodにはCloudSyncという機能が用意されている。GoogleドライブやBackblaze B2、AWS S3、Dropboxなどに対してインスタンスからファイルのアップロード、ダウンロードが可能な機能だ。
便利そうだね!と思って、Googleドライブに接続しようとしてみたら、「アプリがブロックされています!」などとエラーが出て繋がらない。どうやらRunpod運営がアプリの証明書だか何だかを更新し忘れて機能しなくなってるらしい。なんというか、間が抜けている。
だったらBackblaze B2を使おう!と試したら、当たり前のように全く機能しない。
ひどくないか?
これではインスタンスからデータを回収する手段が無い。AI学習させてもckptを回収できないなら意味無いではないか。
Runpod公式ディスコで文句を垂れたら、Dropboxなら繋がると教えてもらった。だが、あいにく私のDropboxはまったく容量が空いてない。
しょうがないから有料プランを契約した。1650円の出費だ。それでDropboxのCloud Syncを試したら、無事に動作して、ckptを回収できた。DL速度は4MB/sほどだった(インスタンスによる)。普通にSFTPでDLするより速い。
ちなみにCloud Syncを使うにはここからAPIキーを生成する必要がある。
パーミッションを設定する必要があると言われるが、よく分からんがこの辺を全部チェック入れとけば動作した。(これ以外の部分はチェック入れるとむしろ怒られる)↓
これは便利だ!と言ってDropboxのCloud Syncを使いまくってたら、途中で急にスンッと動作しなくなった。なんで!?
結局データをDLする手段が無くなったわけだが、最後の手段として使ったのがこのDropboxアップローダーだ。↓
これを使えばインスタンスから簡単にデータをDropboxにアップロードできる。
Gitからクローンしてきてスクリプトを叩く。
git clone https://github.com/andreafabrizi/Dropbox-Uploader.git chmod +x dropbox_uploader.sh ./dropbox_uploader.sh
Shell
すると、APIキーとかを求められるので、CloudSyncの時に使ったものと同じものを入力すれば準備OKだ。
あとはこのコマンドでファイルやディレクトリごとアップロードできる。
./dropbox_uploader.sh upload <アップロードしたいディレクトリ> <Dropbox上のディレクトリ>
Shell
これを使うと10MB/sくらいの速度でアップロードできた。けっこう高速なので、SFTPとかでファイルDLするよりもオススメかもしれない。
・トラブル続出
ここからはコミュニティクラウドではなくてセキュアクラウドでの話だ。
セキュアクラウドでは公式の説明通りにちゃんとSCPやSFTPでの接続が可能だ。
30時間ほど学習させた後、学習を停止させて、もう一度学習再開しようとすると、「このマシンにはGPUがありません」とかいうエラーが出た。 何かの間違いかと思い、nvidia-smiコマンドを叩いたら、やっぱりGPUが存在しないらしい。
急にGPUが消失したわけだ。
困惑したが、一旦インスタンスを停止してから再開すれば、GPUが復活した。 これをやると環境がリセットされるので、環境構築のやり直しをするハメになる。コンテナ内のデータも消える。まあ今回は学習環境構築済みのDocker imageを使ってたので大した手間は無かった。これがDockerの便利なところだ。
上でも書いたが、しばらく処理をしない時はインスタンス停止しておけば、ストレージ代だけで済む。
他にも、処理はしたいけどGPUは不要な時なんかは、一旦インスタンス停止してGPU無しでインスタンス再開する事もできる。GPU無しだと安く動かせるので節約できる。
ちなみにA5000からA6000へなど、別のGPUに乗り換えたりする事はできない。
他にもトラブルに見舞われた。
何の前触れもなく急にWebターミナルが遮断されて閉じられる事もあった。これだと処理も中断されちゃうので、学習などの重要な処理はscreenセッションの中でやっといた方がいい。
挙句の果てに、Dropboxアップローダーを使ってたら「Host can’t resolved」とかいうエラーが出てまったく動作しなくなったりもした。 これはつまりDNSがおかしくなってるようだ。公式ディスコによると、何かそういうトラブルが起きていてメンテしたりしていたようだが、全然直ってないようだ。
以上のような問題が次から次へと発生するので、正直言って疲れる。
これはたまたま今だけ特に不調だったのか、それともいつもこんな調子なのだろうか?
用意されている機能が何一つマトモに動かず、危うくデータを回収する事さえ不可能になりかけた。 いくら安いとは言えこれではさすがにウンザリさせられる。だから今回Runpodを使った限りの結果で言うと、他の人にRunpodを使うのはややオススメできない。