RTX5090を乗せたPCを買って数か月くらいが過ぎた。生成AIを試した所感を書く。
あらすじ
GTX1080が搭載されたPCで生成AIを頑張ってた
GTX1080搭載機がWindows11にアップデートできないハードウェアだったので、RTX5090搭載機を新調した
RTX1080時代
①画像生成
RTX1080でもVRAMは8GBあるので、Stable Diffusionは動かせた。
最初はAUTOMATIC 1111(https://github.com/AUTOMATIC1111/stable-diffusion-webui)で512*512の画像を作って満足していた。
当時はStable Diffusionが1.5だったので、画像サイズは512*512が標準的だったような気がする。
なんだったら256*256の画像を生成して、良さそうなのを512*512に清書していた時もある。
さらに実用する時はupscaleという機能を使って、画像をでかくすればよかった。
Comfy UI(https://github.com/comfyanonymous/ComfyUI)も使っていた。
まさか画像生成でビジュアルプログラミングを始めることになるとは思わなかった。
問題はStable Diffusionの時期バージョンであるXLが出始めた頃で、画像サイズが1024*1024が標準的になったことだった。
1.5の時ですら、512*512を直接出すにもまぁまぁ時間がかかったものだが、
1024*1024になってからはさらに長くなった。
大体25枚の画像を30分程度で出力していたので、1枚で1～2分くらいの計算になる。
ControlNetなる、文字列では伝えきれないことをAIに伝える機能を使うと、1枚あたりの画像生成時間はさらに伸びた。
絵柄やポーズを固定化できるLoraという機能では、画像生成時間をそこまで増やすものではなかったが、LoRA自体のクセを把握してプロンプトを練る時間は増えた。
流石に時間がかかるということで、
Forge(https://github.com/lllyasviel/stable-diffusion-webui-forge)に途中で乗り換えたように思う。
Forgeはどういう仕組みかまでは知らないが、少なくともAUTOMATIC 1111より、厳しいマシンリソースでも手早く画像を生成してくれる神ではあった。
ただ当時、Forgeは安定的なソフトウェア開発をやめて、実験を試みるプロジェクトに切り替えられた。
今でも、私の古いマシンには当時の実験を試みる前のGitのコミットのバージョンのForgeが入っていると思う。
(Forgeの方針転換で作られたreForgeというフォークが、つい最近、開発者が更新をやめることが明示された。生成AI開発は色んな意味で進みが早い(https://github.com/Panchovix/stable-diffusion-webui-reForge/discussions/354))
(面白いことに、Stable Diffusion系のソフトウェアをアップデートする時は内部的にGitを使う。表面的には各自のPCにインストールするデスクトップアプリケーションなのだが、内部的にはローカルで動くWebシステムだからだろう)
ちなみに、動画生成もためしはした。
当時は画像1枚を連続して出力することで動画にする試みがあった1枚あたりの画像生成速度の遅い環境では、数秒の動画でもかなりの時間を費やした。
結局、世の中に動画として出せたのは1つだけだった。しかも2～3秒くらいの短くて荒いものだった。
②：LLM
GTX1080でLLMを試した時には、「こんにちは」と問いかけただけでファンがフル回転した後に意味の分からない単語を出力するだけだった。
電気代とストレージの無駄だったので、諦めた。
当時のローカルLLMなので、モデルの精度が悪かった面もあるとは思う。
どういう手順で何をしたかは覚えていない。
ただもう二度とこのハードウェアでLLMは動かさない、という誓いを立てた。
RTX5090になってから試したこと
①画像生成
当たり前ではあるが、すべての物事が各段に早くなった。
頭文字Dで86からダンレボ？とかいう現代的な車に乗った時の主人公的な気持ちがある。
(調べたらダンレボはゲームだし、車はランエボだった。それに主人公が乗ったのはインプレッサという車だった。車は何も分からない)
AUTOMATIC 1111やComfy UIを使って、1024*1024が5秒もせずに出てくる。
画像生成の早さのおかげで新しい気づきもあったりして、また試行錯誤をしている段階。
前環境の時点でIllustrious系モデルを使っているので、画像の質そのものは変わらない印象。
Illustrious系モデルはこれまでLoRAでないと出せない画像が普通に出せる。
ControlNetは試してないので、必要になったら試してみようとは思う。
②動画生成
最近、Wan 2.1という動画生成AIが発表されたとかで、EasyWanVideo(https://github.com/Zuntan03/EasyWanVideo)を試してみた。
が、主に二つの問題がある。
●よく分からない
単に触っている時間が短いだけ。
こういうのはクセを把握しないと使いこなせない。生成AIってそんなものだから。
●利用シーンが思いつかない
動く絵だけを生成できる、ではユースケースがない。
あくまで単体ではないって話。
複数の要素を合わせたらやれることは増えそうだ。
③：LLM(検索・壁打ち相手編)
まともに動くし、そもそもLLMをローカルで動かす環境が整っている。
いい時代にいい買い物をしたと思った。
同時に、もっとVRAMの大きなGPUを買うべきだったとも思う。
今の環境はOllama(https://ollama.com/)でLLMをAPIとして扱えるようにして、Open WebUI(https://github.com/open-webui/open-webui)でアクセスしてる状態。
いくつかモデルを試した中では、gemma3:27bがまぁまぁ好み。
27B前後くらいがRTX5090の現実的な実用ラインという感じは受ける。
(30B超え始めると応答に時間がかかり始める)
ただそこまでモデルを試しきれていない面もあるので、これも追々か。
DeepSeek-R1の衝撃、とか言われた割に返答がぐちゃぐちゃで大変失望した。
ローカルで動かすものではないのだろう。
ちなみにOpen WebUIでチャットから事前に起動してたAUTOMATIC 1111を呼び出して画像の生成もできた。
gemma3:27bでも余裕で画像を作ってその後のチャットもできた。
たぶんこれより上のLLMだとVRAM的に難しいかもしれない。
ただ、Ollamaは必要ないと思ったらモデルをVRAMからぽいぽい捨てているので、動作はするかもしれない。
再度VRAMにロードする時間と処理時間がかかるので、実用的かは謎だが。
④：LLM(MCP編)
うまくはいかない。
調べると出てくるのは「Claude for desktopに」MCPサーバをくっつけてみた。というものばかり。
Open WebUIはMCPを直接扱っておらず、MCPOサーバを立てる必要があるらしいのだが、
いまいち概念が理解しきれてない。
一応、Open WebUIの公式のMCP的なものを動作させることには成功はしている。
ただ、MCP的なものがくっついたことと、それをAIが利用するか・適切に利用できるか等の実用性の面では疑問に残ることが多い。
ここら辺も理解と時間をかけられていないので、もう少し試行錯誤が必要そうだ。
⑤：LLM(バイブコーディング編)
Cline(https://github.com/cline/cline)でOllamaを使えるそうなので、試しに使ってみたが、
うまくコードを書けるモデルと書けないモデルがあるようだ。
うまく書けるモデルはそもそもコード用に調整されているもの。
うまく書けないモデルはどんなにBが高くてもできない。
そこら辺は画像生成AIと変わらないな、という印象がある。
ちゃんとコードを書くのなら、Claude3.7にお金を払った方がスマートではある。
これも画像生成AIと同じ道をたどると思うが、そのうちローカルでもClaude3.7相当のことはできると思う。
最近はGitHub Copilot Free(https://docs.github.com/ja/copilot/managing-copilot/managing-copilot-as-an-individual-subscriber/getting-started-with-copilot-on-your-personal-account/about-individual-copilot-plans-and-benefits)のプランでCline的なAIを使えるからなおさら便利になったと思う。
GitHub Copilot Chatは試してはいるが、特殊なプロジェクトで試したので真価は別の場所で計測しないといけないという感じ。
どの生成AIもそうで、生成AIとはそういうものなのだが、ちょっとマイナーなものを扱うと途端にお馬鹿さんになる。
MCPもClineも、ローカルLLMは道具を使うことがイマイチうまくできていないように感じる。
細かく道具の指示をすればできそう、くらいな雰囲気。
⑥：今後
やりたいことなんてのは無限にあるので、やってから考えることにする。
私はやりたいことを周りに宣言するとやり遂げられないというジンクスがあるので、ここで宣言することはしない。
どうでもいい話だが。
病院の先生とChatGPTの話をよくしていて。
私「ローカルで動くChatGPTっぽいもので(MCPサーバを入れて)遊んでいました」
先生「あーそうだよね、ChatGPTとチャットしてたら時間溶けるよね」
みたいな若干すれ違った話をしてしまった。
その場で説明や訂正することはしなかった(先生は顧客でも友達でもないからだ)。
ただ、まだ当分はプログラマは死滅することはなさそうとも思った。
docker-compose + npm
イマイチ分かってなかったのでまとめ
docker-compose.yml
services:
app:
build: .
ports:
- "3000:3000"
volumes:
- .:/app #ここはホストのコードを/appにマウントしている
- /app/node_modules #ここは.:がないので、イメージ上に作られた/app/node_modulesが参照される
FROM node:20-alpine
WORKDIR /app
# ここでpackage.jsonやpackage-lock.jsonのみコピー
COPY package.json ./
# ここで行われるnode_modulesへの書き込みは、イメージへの書き込み
RUN npm i
EXPOSE 3000
CMD ["npm", "run", "dev"]
SourceTreeで\\wsl.localhostからソースコードをinitしようとすると失敗する
git config --global --add safe.directory '%(prefix)///wsl.localhost/Ubuntu/Gitで管理したいリポジトリ'
UbuntuのところはWSL2に入れているディストリビューションによって変わると思われる
Dockerでnodeイメージでuseradd -u 1000が失敗する
-vでホストとコンテナがファイルを共有している場合、ホストのuidとコンテナのuidが一致しているとパーミッションで書き込めない問題が起こらない
ので、Dockerfileでuid=1000のユーザを作ろうとした。イメージはnode:latest
RUN groupadd --force -g 1000 user
RUN useradd -ms /bin/bash --no-user-group -g 1000 -u 1000 user
useradd: UID 1000 is not unique
こんなエラーが出る
FROMに指定したイメージにuidが1000のユーザがすでに存在するので、作ることはできない
設定を変更することは可能
user: '1000'
docker-compose.yamlを使っている場合、コンテナにユーザを指定可能
ユーザ名でなく、uidを指定してもログイン可能っぽい
参考
dockerfile で一般ユーザーを作成する #Docker - Qiita
Adding a non-root user with UID 1000 breaks custom builds · Issue #289 · nodejs/docker-node · GitHub
