生成AIとOSSの刹那
「生成AIとOSS」と、タイトルにつけておいて何だが、オープンソース（OSS；open source software）を名乗るべきではない生成AIプロジェクトなんて山ほどある。
「自称オープンソース生成AI」は本当に“オープン”なのか？ 45種のAIモデルをオランダの研究者らが調査 https://t.co/kRbon7Ckmy Llama3,Gemma7B,Mixtral等モデルの1/3(大手企業が多い)は重みは公開してるがコードや訓練データ等ほとんど非公開でオープンを謳う。SDはほぼフル公開で画像生成では唯一 pic.twitter.com/8HVh64GULG
— Seamless (@shiropen2) June 10, 2024
リストの一番下の方にいる Stable Diffusion であっても、オープンソースではなくオープンモデルであって、学習（調教）を含めたすべてが公開されているわけではない。それは機械学習分野の研究者が今まで作ってきた文化とも言える。ソースコードと呼ばれるものは公開しても、それは再生に必要なコードであり、調教に使えるコードはない。良くてデータセットまでだし、それだって大規模なストレージやメモリ、演算環境がなければロードすることすらままならない。
それでもDiffusionモデルによる画像生成についてはStability AIらによって2022年8月に公開され、その名もOpenなOpenAIによって準備されてきたDALL-E、画像生成AIというパンドラを世界に開放した。その魔法のような幻獣はTransformerによるCLIP、UNET、VAEによって構築されていることがソースによって明かされている（めちゃ端折った説明したが、私の2冊の書籍を読んでくれた人にはもはや説明は要るまい）。さらに、AUTOMATIC1111をはじめとする、完全なOSSによるツールがそれを詳らかにし、機能を拡張し、錬成(forge)してきた。ネガティブプロンプト、image2image、ControlNet、LoRAなど、Stable Diffusionにおける画作りのキーテクノロジーとなる機能追加の多くは、研究者なり、無名のハッカーによって実装され、いまでもメンテナンスが続けられている。「コミュニティ」と呼ぶにはおぞましいボランティアと依存と、クソの投げ合いの繰り返しであるが、それでも聡明なコントリビューター達によって、丹念にコードが修正され、シャープになり、皆が気づかないところで、実装は進んでいく。
先日、ForgeというプロジェクトでびっくりするようなOSSの事件がおきた。
リヤスヴィエル
2日前（June 9）メンテナ
forge のユーザーの皆さん、こんにちは、
本日、アップストリームの sd-webui の dev ブランチはパフォーマンスに関する多くの進捗を更新しました。以前のボトルネックの多くは解決されているはずです。ここで議論されているように、大多数のユーザーにはアップストリームの webui に戻ることをお勧めします（webui dev ブランチを直接使うか、dev ブランチが main にマージされるのを待ちましょう）。
同時に、forge の多くの機能（unet-patcher や最新のメモリ管理など）は、現在の webui のエコシステムで実装するにはコストがかかりすぎると考えられます。
そのため、Forgeは主に統合にコストがかかる機能をテストするための実験的なリポジトリとなります。私たちはGradio 4で実験し、LRUプロセススケジューリングとpickleベースのプロセス通信に基づいたhuggingface spaceのゼロGPUメモリ管理のローカルGPUバージョンの実装をforgeの次のバージョンに追加する予定です。これにより、forge に "Forge Space" という新しいタブ（Gradio 4 SDK の @spaces.GPU ネームスペースに基づく）と、"LLM" というタイトルの別のタブが追加されます。
これらのアップデートはほぼすべての拡張機能を破壊する可能性があり、本番環境で日常的に使用するすべてのユーザーにはアップストリームの webui に戻すことを推奨します。
Gradio 4に対するフィードバックと拡張は、gradioのLLMインターフェースとストリーミングシステム、イメージエディターとディスプレイ、およびゼロGPU計算管理システムのGradio sdkのシームレスな統合に関するアップストリームの検討や適応のためにも必要です。
最後に、forge ユーザーの皆様には、今すぐファイルをバックアップすることをお勧めします（可能であれば、アップストリームの webui に戻すこともできます）。このアナウンスを知らずに誤って forge を更新した場合、このアナウンス前の最後のコミットは 29be1da です。
「ここで議論されているように」という2月10日のIssue投稿がこれ。
ForgeはStable-Diffusion-WebUIの上のプラットフォームで、より高速に、より簡単に開発できるようにするためのものです。私たちはオリジナルのwebuiのdevブランチからボットを使って自動的にすべてのアップデートを取得します。
もう1つの理由は、現在進行中の研究プロジェクトがいくつか予定されており、みんなが大好きなこのとてもフレンドリーなwebuiを使いたいからです。
以下の(1)と(2)が同時に発生した場合、このレポは直ちにAutomatic1111の標準的なStable-Diffusion-WebUIの拡張版に変わります：
私たちの5つのテストデバイス（RTX 2060、RTX 3060ラップトップ、RTX 3090、RTX 4090、RTX 3070tiラップトップ）のうち少なくとも4つで、元のウェブイが等しく速いか、最大でも10％遅い場合（RTX 3090と4090を除く。） すべてのCMDフラグを受け付けますが、TensorRTやtorchコンパイルのような機能を犠牲にする技術は除外します。CLIP時間、拡散時間、モデル移動時間、VAE時間の全世代パスが含まれることに注意してください。バッチサイズ1と4、バッチカウント1と16でSDXL 1024x1024を使用しています。
5 つのテストデバイスのうち少なくとも 4 つ（RTX 2060、RTX 3060 ラップトップ、RTX 3090、RTX 4090、RTX 3070ti ラップトップ）で、元の WebUI が同等のメモリ効率であるか、最大でも 512MB 多くの VRAM を使用し、OOM のない拡散イメージ解像度が Forge の最大解像度の 90% 以上である場合（RTX 3060 ラップトップと RTX 3070ti ラップトップ）。すべての CMD フラグを受け付けます。
上記の2つのことが同時に起こった場合、私たちは直ちに元の sd-webui エコシステムに戻り、このレポは拡張機能になります。エンジニアリングの複雑さについては心配しないでください - 私たちにはあらゆる問題を解決できる優れたチームがあります。
私たちは15日ごとにオリジナルのwebui開発ブランチでテストを行います。
その前に、私たちからのすべての主要なアップデートはここで行われ、私たちはメモリや速度の問題を解決するためにアップストリームを待ちます。0.0.10以降のForgeのツールセットは比較的完成しています。ユーザーは画像処理タスクで大きな問題を抱えることはないでしょう。
Forge のバックエンド API は、拡張機能に変更しても変更されないことに注意してください。
lllyasviel
Forgeは魔法の杖のように紹介されてきた。日本でもそんな感じで紹介された。
https://ascii.jp/elem/000/004/185/4185940/
しかし、その名の通り、錬成のためだけのカウンターカルチャーであり、本家のAUTOMATIC1111を消滅させるような目的ではない。そもそもAUTOMATIC1111のコードを吸い取って比較しているので、パフォーマンスや実装コストが本家を上回るならメンテしないよ、という非常に独善的なOSSプロジェクトともいえる。それでいいんだと思う。さすが lllyasviel。この裏で、Foocusのアップデートや、Omostをリリースしているのだから超人的な博士学生である。
そんなわけで生成AIとOSSの世界は刹那だ。
ボヤッとしていると、いつだって世界の辺境に追いやられてしまう。
まあ辺境だからといって居心地が悪いわけではないだろう、というのが日本のOSS界隈の習慣でもある。動くものを使えばいい、翻訳だけをすればいい、コミットする気はない。まあそれでいいんだと思う。
ただ使っているだけよりはずいぶんとマシだと思うよ。
この記事が気に入ったらサポートをしてみませんか？