メモ。
今のところCUDA 11.8でlarge-v3に対応したfaster-whisperを動かすなら、ctranslate2==3.24.0まで落とさないと動かないらしい。
CUDA 11.x非対応なライブラリにボチボチ苦しみ始めた。WSLはほんとにイヤだから使いたくないけど、もう猶予はあんまないだろうなぁ。
WSLがイヤなのは、管理対象が純粋に増えることなんだよな。私はWindows環境だけ見てれば済む状況でずっと生きていたかったぜ。
CUDA toolkitは11.8が入ってるんだけど、torch 2.1.2+cu121がvenvではインストールできて、動いている理由はなんだろう…
互換性でなんとかなってるんかな。
そして相変わらず、共存不可能なライブラリを、1つのスクリプトから参照する方法が分からない。
そういうことは出来ないと考えるべきなのか？
ライブラリといってもたいてい何らかのAIモデルを実行するやつなんで、モデルをロードしておいたり、アンロードしたりする仕組みも要る。
今のところ、各ライブラリの機能を実行するAPIを実装したスクリプトを各々仮想環境で実行して、呼び出し側とプロセス間通信する、みたいにがっつり作り込む以外に、方法が思いつかないんだよね。たかがスクリプトぞ？
なんとか依存関係を解決しようとしてあがいてるのだけど、もう泥沼だぁ。
諦めてちゃんと機能分離して作り直さなきゃだめかね
結局、なんとか動作するバージョンの組み合わせを見つけたのだが、無情のCUDA out of memory。今までは動いてたモデルなのになんでだよ…
理由が分かった。tensorflowが1つのモデルで以前はCPUを使っていた（し、速度に問題なかった）のだが、新環境ではGPUを使ってしまっている。
それで他のモデルはGPUを使うから、不足しちゃってるんだ。なるほど…
でも片方だけCPU使わせるのってどうすればいいんだろ。os.environ["CUDA_VISIBLE_DEVICES"] = "-1"は両方に影響するからダメだし…
tensorflow-2.11.1以上ならWindowsネイティブではGPUが使えないことを逆手にとって、tensorflowはCPU、pytorchはGPUを使うようにし、CUDA out of memory回避に成功した…。
無理矢理過ぎるが、動くからヨシ。
CUDA toolkit 12.1を入れてみよう。動いてるシステムに手を入れるの、たいてい碌な事にならないけど、なんとかなるなる