安定拡散モデルをiPhoneに挿入し、1分で写真を生成するアプリに作成します

iPhone で安定拡散を実行するのは難しいですか?今回ご紹介する記事では、「それは難しいことではなく、iPhoneの性能はまだ50％も残っている」と著者が答えています。

ご存知のとおり、Apple は毎年、新しいビジョン モデルとイメージ センサーの急速な開発により、あらゆる面でより高速かつ優れていると主張する新しい iPhone を発売します。写真を例に挙げると、10 年前に戻った場合、iPhone で高品質の写真を撮ることができますか? 答えはノーです。テクノロジーの発展は徐々に進んでいます。携帯電話の写真技術は 10 年もあれば十分に向上します。

このような (進歩的な) テクノロジーの発展パターンにより、最高のコンピューティング機器であっても、一部のプログラムがほとんど使用できなくなる日が来るでしょう。しかし、新しく有効になったシナリオを備えたこれらの新しいプログラムは一部のユーザーの注目を集め、人々はそれを研究しようとしました。

この記事の著者もその 1 人であり、過去 3 週間で、著者は安定拡散を通じて画像を生成 (呼び出し) し、編集ボタンを押すことができるアプリケーションを開発しました。それはあなたの好きなように。このアプリは、最新の iPhone 14 Pro で画像を生成するのにわずか 1 分かかります。約 2 GiB のアプリ メモリを使用します。さらに、開始するには約 2 GiB の初期データをダウンロードする必要があります。

#App ストアのリンク: https://apps.apple.com/us/app/draw-things-ai-generation/id6444050820

##この結果はネチズンの間で多くの議論を呼び、携帯電話の電力消費を心配し始め、「これはすごいことだけど、これは携帯電話のバッテリーを消耗するのに良い方法のようだ」と冗談を言う人もいました。

「iPhone の熱さを感じてこんなにうれしかったことはありません。」

" 「寒い冬には、携帯電話をカイロ代わりに使えます。」

# しかし、誰もが携帯電話の発熱問題をからかっている一方で、この問題も解決しています。非常に高い評価。

「これは信じられないほどです。iPhone SE3 で完全なイメージを生成するのに約 45 秒かかります。これは、M1 Pro MacBook のオリジナル バージョンとほぼ同じ速度です。急いでください!」

#メモリとハードウェアを同時に最適化する

これはどのように行われるのでしょうか?次に、作者の実装プロセスを見てみましょう:

iPhone で Stable Diffusion を実行し、それでもパフォーマンスを 50% 節約したい場合、大きな課題は 6GiB が必要なことです。 RAM iPhone デバイスでプログラムを実行します。 6GiB というと多いように思えますが、6GiB デバイスで 2.8GiB、または 4GiB デバイスで 2GiB を超えると、iOS によってアプリが強制終了されます。

それでは、安定拡散モデルが推論に必要とするメモリの量はどれくらいでしょうか?

これもモデルの構造から始まります。通常、安定拡散モデルには 4 つの部分が含まれます: 1. 画像生成をガイドするテキスト特徴ベクトルを生成するテキスト エンコーダー; 2. 画像を潜在空間にエンコードする (画像間の生成用) オプションの画像エンコーダー; 3. デノイザー モデル画像の潜在表現をノイズからゆっくりとノイズ除去する画像デコーダ、潜在表現から画像をデコードする画像デコーダ。

1 番目、2 番目、および 4 番目のモジュールは推論中に 1 回実行され、最大約 1 GiB を必要とします。デノイザー モデルは約 3.2GiB (完全な浮動小数点) を必要とし、複数回実行する必要があるため、作成者はモジュールを RAM に長く保持したいと考えています。

元の安定拡散モデルでは、単一画像の推論を実行するのに 10 GiB 近くが必要でした。単一の入力 (2x4x64x64) と出力 (2x4x64x64) の間には、多くの出力レイヤーが点在しています。すべてのレイヤー出力をすぐに再利用できるわけではなく、一部のレイヤー出力は後で使用するためにパラメーターを保持する必要があります (残留ネットワーク)。

しばらくの間、研究者は PyTorch 安定拡散を最適化してきました。研究者は、PyTorch で使用される NVIDIA CUDNN および CUBLAS ライブラリ用に一時ストレージ スペースを予約しました。これらの最適化はすべて、メモリ使用量を削減するためです。したがって、安定拡散モデルは、 4GiB 程度のカードで実行できます。

しかし、それでも著者の期待を上回りました。そこで、著者は Apple のハードウェアと最適化に焦点を当て始めました。

当初、作者は、Apple の OOM (メモリ不足、つまり、アプリが単一の iOS システムの制限に達した場合 アプリがメモリの上限を占有し、システムによって強制終了された後、作成者には約 500MiB のスペースが使用可能になります。

最初の質問は、各中間出力のサイズはどれくらいかということです。

それらのほとんどは比較的小さく、それぞれ 6MiB (2x320x64x64) 未満であることがわかりました。作成者が使用しているフレームワーク (s4nnc) は、再利用のためにそれらを 50MiB 未満に合理的にパッケージ化できます。

デノイザーには、画像の潜在的な表現を入力として受け取るセルフアテンション メカニズムがあることに言及する価値があります。セルフ アテンションの計算中には、サイズ 16x4096x4096 のバッチ行列が存在します。これは、softmax 適用後の FP16 では約 500MiB で、「インプレース」で実行できます。つまり、破損することなく入力を安全に書き換えることができます。幸いなことに、Apple と NVIDIA の両方の低レベル ライブラリはインプレース Softmax 実装を提供しますが、PyTorch などの高レベル ライブラリは提供しません。

では、約 550MiB と 1.6GiB のメモリを使用して本当に実行できるのでしょうか?

Apple ハードウェアでは、ニューラル ネットワーク バックエンドを実装するための一般的な選択肢は、MPSGraph フレームワークを使用することです。そこで著者はまず、MPSGraph を使用してすべてのニューラル ネットワーク操作を実装しようとしました。 FP16 精度でのピーク メモリ使用量は約 6GiB ですが、これは明らかに予想されるメモリ使用量をはるかに超えています。

著者はその理由を詳しく分析しましたが、まず、一般的な TensorFlow の方法で MPSGraph を使用していませんでした。 MPSGraph では、計算グラフ全体をエンコードし、入出力テンソルを消費し、内部割り当てを処理し、ユーザーがグラフ全体を実行のために送信できるようにする必要があります。

作者は、PyTorch とよく似た MPSGraph を操作実行エンジンとして使用しています。推論タスクを実行するために、コンパイルされた多くの MPSGraphExecutable が Metal コマンド キューで実行され、それぞれが中間に割り当てられたメモリを保持する場合があります。一度に送信すると、これらすべてのコマンドは実行が完了するまで割り当てられたメモリを保持します。

この問題を解決する簡単な方法は、送信速度を調整することです。すべてのコマンドを一度に送信する必要はありません。実際、Metal にはキューごとに同時送信数が 64 という制限があります。著者は、一度に 8 つの操作を送信するように変更してみたところ、ピーク時のメモリは 4GiB に減少しました。

ただし、それでも iPhone が処理できる量を 2 GiB 超えています。

CUDA を使用して自己注意を計算するには、元の安定拡散コードの実装に共通のトリックがあります。それは、転置の代わりに順列を使用することです。このトリックが機能するのは、CUBLAS が並べ替えられたストライド テンソルを直接処理できるため、テンソルを転置するために専用のメモリを使用する必要がなくなるからです。

しかし、MPSGraph にはストライド テンソルがサポートされていないため、並べ替えられたテンソルはいずれにしても内部で転置され、中間メモリ割り当てが必要になります。明示的に転置することで、割り当ては上位層によって処理され、MPSGraph の内部効率の低下が回避されます。このトリックを使用すると、メモリ使用量は 3GiB 近くになります。

iOS 16.0 以降、MPSGraph はソフトマックスに対する最適な割り当ての決定を行うことができなくなっていることが判明しました。入力テンソルと出力テンソルが両方とも同じデータを指している場合でも、MPSGraph は追加の出力テンソルを割り当て、その結果を指された場所にコピーします。

作者は、代替の Metal Performance Shaders を使用すると要件を完全に満たし、パフォーマンスを低下させることなくメモリ使用量を 2.5 GiB に削減できることを発見しました。

一方、MPSGraph の GEMM カーネルは内部転置を必要とします。これらの転置は上位層の「インプレース」操作ではなく、特定の 500MiB サイズのテンソルの場合、この追加の割り当ては避けられないため、ここでも明示的な転置は役に立ちません。 Metal Performance Shader に切り替えることで、プロジェクト作成者は約 1% のパフォーマンス ヒットを伴いさらに 500MiB を再利用し、最終的にメモリ使用量を理想的な 2GiB まで削減しました。

以上が安定拡散モデルをiPhoneに挿入し、1分で写真を生成するアプリに作成しますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。