World Community Grid(WCG)で課題待ち時間を減らして、難病解明にさらに貢献

分散計算プロジェクトの一つ、World Community Grid(本記事ではWCGと略す)において、長期にわたったIBMからの移管もようやく終わって再開するも、課題受信に高確率で失敗する。瞬間的に連続で受信成功するタイミングもあるものの、基本的にランダムに成功・失敗しているようだ。
WCG(というかBOINCで動くプロジェクト)で受信に失敗が続いた場合、リトライの待ち時間が倍々ペースで長くなっていく。初回のリトライは1,2分後だが、10回も連続で失敗したら5時間といった待ち時間になる。さらに、WCGのOpenPandemicの課題は、1課題につき5つくらいのファイルが送られてきて、それが全部そろわないと解析を始められない。要は、ずっと監視していて課題のリロードをしまくらない限り、課題受信にことごとく失敗しPCが遊んでいるだけになる。
以前Folding@Home(F@H)でも似たような状況を経験した。（当時は参加者が増えすぎて課題自体が枯渇していたことが主な原因）

Folding@Homeで課題待ち時間を減らして、難病解明にさらに貢献 - 雑記帳(新居)

F@Hの場合は、Telnet接続のAPIが用意されており、課題の状態もJSON形式で取得可能である。そこで、課題受信待ちの状況を解析して待ち状態に陥っていたら待ち時間のリセット、ということをスクリプトで書けた。
BOINCもコマンドインタフェースはあるものの、スクリプトなどで解析して課題送受信させるのは極めて困難そうで、正面から攻めることは断念した。その代わり、人間の操作の自動化を試みる。
・BOINC managerのウィンドウをアクティブ化
・[ファイル転送]タブをクリック
・Ctrl-Aキーで全ファイルを選択
・[今すぐ再試行]ボタンを押す
今回、筆者はUWSCという自動化ツールを利用した。

UWSCの詳細情報 : Vector ソフトを探す！

上記の操作をUWSCで記録し、記録された(UWSCの)スクリプトから必要な部分だけを抜き出し、上記程度であればごく簡単なものになる。これを1分ごとに自動という設定もできる。

これで、ようやく枕を高くして寝ることができる。

(追記)ただし一つ問題があることが判明した。通常、5分とか10分とか一定時間操作をしないと、ディスプレイの電源を切るように設定している。しかし、この方法ではごく短い間隔でWindowsの操作を繰り返すので、ディスプレイが常に点灯したままになってしまう。使用しないときは電源スイッチから切るようにしたが、毎回ディスプレイの裏側に回り込んで電源のON/OFFをする必要がある。考えてみればこれが本来あるべき使い方だが、なんとも億劫である。

Stable Diffusionの環境を構築してみた

画像生成AIのStable Diffusionが大きな話題になっている。高精度な画像を生成できるAIが無料で一般公開され、しかも出力した画像も基本的に自由に利用できるライセンスとなっている。
筆者もStable Diffusionをローカルで動作させる環境を構築して実行してみた。
（筆者が最初に参考にしたサイトの例題: a dog painted by Katsushika Hokusaiで生成してみた画像）

公式的な手順では、Python実行環境とCUDA Toolsを導入、AI関連のパッケージを順次導入し、Stable Diffusionの環境を構築する。その環境で、コマンドインタフェースでオプションを指定したうえでスクリプトを実行、画像生成するのが、本来のやり方である。しかし、それにはPythonに関する知識なども必要で、不慣れな人には敷居が高い。
そこで、前提パッケージを一括導入できたりGUIもついていたりするものも、有志によっていくつか公開されている。
(9/13追記)下記で紹介されている環境に差し替えた。前に試した環境よりもさらに多機能である。
https://gigazine.net/news/20220909-automatic1111-stable-diffusion-webui-how-to-use/
よりよい環境が出てくるたびに、Python(Anaconda)の仮想環境を削除、さらにPython自体入れ替えになるのでてんやわんや。
(追記ここまで)
筆者は下記で紹介されている手順を利用した。
https://golabo.net/stablediffusion_local_webgui/
これを選択した理由は、GUIによって、画像生成だけでなく画像の拡大・顔の調整という後処理も行えることである。

Stable Diffusionで生成される画像の解像度は、デフォルトで512*512である。これより大きい画像を生成しようとすると、必要なGPUのVRAM量が急増する。筆者の環境はVRAM11GBで、768*576程度が最大のようだ。それより高い解像度を指定するとエラーが発生する。VRAM使用量を最適化する設定もあるが、それでも768*768が限界で、またその設定をするとVRAM使用量削減と引き換えに画像生成の速度が低下する。
そのため必然的に、Stable Diffusionで生成する画像の解像度は低いままで、後処理で拡大となる。そこで、この手順で導入するGUIが便利というわけである。
また、Stable Diffusionは画像生成の学習を主に512*512解像度で行っていて、縦横の比率が1:1から大きく離れると奇妙な画像が生成される可能性が高くなるとのことだ。4:3(3:4)程度までならあまり問題は起きないようだ。

ところで、GPUの需要が急激に縮小し、価格を下げても在庫をさばききれない状況になっているようだ。Stable Diffusionが大流行すれば、NVIDIAにとってはGPUの需要を回復させるワンチャン救いの手になるかも？（無理すぎ）もっとも、Stable Diffusion用途とすれば2060-12GBか3060ばかり売れそうだが。この種の用途はVRAM多いのが正義だ。
以下のURL末尾に参考情報として各GPUでの画像生成の所要時間がある。
https://rentry.org/GUItard
3090Ti（おそらく3090無印も）は飛びぬけて高速だが、promptを変更しながら100枚単位で画像生成とかしない限り、2060(12GB版)～3060でも十分と思われる。1000番台以前は相当遅い。2000番台以降のAI向け機能強化の効果も大きいことがわかる。