ディフューザ SD 推論高速化ソリューションの研究と実践のまとめ

オープンソースの中国コミュニティチームは、共有の名のもとに、オープンソースの中国コミュニティの背後にあるストーリーを伝える初のライブブロードキャストを行いました。」

最近、当社のコンテンツテクノロジであるミディアムインテリジェントコンピューティングプラットフォーム (MVAP)上に展開されるサービスの数が急速に増加しており、一部のビジネスシナリオでは SD シリーズモデルの推論速度に一定の要件が求められます。そこで、現在普及しているSD高速化手法について調査・検証を行い、ビジネスシナリオに合わせたAIを例として、さまざまな高速化ソリューションを試してみました。以下に調査結果と実際の導入効果をまとめて共有します。

加速計画の概要

現在主流の高速化アイデアには、オペレーターの最適化、モデルのコンパイル、モデルのキャッシュ、モデルの蒸留などが含まれます。以下では、テストで使用されるいくつかの代表的なオープンソースソリューションを簡単に紹介します。

▐オペレーターの最適化: FlashAttendant2

主にトランス内の注目モジュール向けに最適化されています。 FlashAttendant は従来のアテンション計算方法を変更し、完全なアテンション計算を単一の cuda カーネルに統合し、フォワードタイリングとリバース再計算技術を組み合わせます。これに基づいて、FlashAttendant2 は冗長な計算をさらに削減し、リバースプロセスとのフォワードパラレル計算を強化します。メモリ使用量と計算時間。その優れた効果と広く使用されているため、FlashAttendant2 は pytorch2.2 以降のバージョンに統合されました。

▐モデルのコンパイル: oneflow/stable-fast

oneflow は、モデルを静的グラフにコンパイルし、それを oneflow.nn.Graph の組み込み演算子融合やその他の高速化戦略と組み合わせることで、モデル推論を高速化します。利点は、基本的な SD モデルではアクセラレーションを完了するために 1 行のコンパイルコードのみが必要であること、アクセラレーション効果が明白であること、生成効果の差が小さいこと、他のアクセラレーションソリューション (ディープキャッシュなど) と組み合わせて使用できることです。 , 公式の更新頻度も高いです。欠点については後で説明します。

Stable-fast もモデルコンパイルに基づく高速化ライブラリであり、一連の演算子融合高速化メソッドを組み合わせていますが、そのパフォーマンスの最適化は xformer、triton、torch.jit などのツールに依存しています。

▐モデルのキャッシュ: ディープキャッシュ

従来の SD モデルの推論プロセスには、unet 計算の多くのステップが含まれており (基本モデルのテストで設定したステップ数は 50)、deepcache の作者は、隣接するステップの unet では深部特徴量の変化が極めて小さいことを発見しました。重複を避けるために、これらの冗長な深い特徴を計算するために、ディープキャッシュは一部のステップでのみ完全な計算を実行し、残りのステップでは深い特徴の計算結果をキャッシュし、浅い特徴のみが計算され、最新のキャッシュされた特徴の結果と結合されます。このプロセスは、unet ネットワーク内のほとんどのレイヤーをスキップすることに相当するため、計算量を大幅に削減できます。

ディフューザーフレームワークでのディープキャッシュの使用は非常に便利で、実際の状況に応じてキャッシュの最も深い層とキャッシュのステップ間隔を設定できます（ここでは不均一な分散戦略も使用でき、さまざまなステップが可能です）異なるステップの冗長性に応じて間隔を設定できます)、推論速度と生成品質の間のトレードオフを自分で設定できます。

▐モデル蒸留: lcm-lora

lcm (Latent Consistency Model) と lora を組み合わせると、lcm は sd モデル全体を抽出して数ステップの推論を実現しますが、lcm-lora は lora の形式を使用して lora 部分のみを最適化し、高速化を実現することもできます。 lora を定期的に使用する場合。

SD1.5加速試験

広く使用されているディフューザーフレームワークに基づいて、テストされた主な高速化方法には、oneflow、stable-fast、deepcache、およびディフューザーによって公式に推奨されているいくつかの方法が含まれます。同時に、コントロールネットの使用シナリオにおける高速化効果もテストされました。

▐テスト環境

A10 + cu118 + py310 + トーチ2.0.1 + ディフューザー0.26.3

文生图、プロンプト：「猫の写真。光を集中させて、シャープで明確なエッジを作成します。」

▐テスト結果

生成されたイメージを固定シードと比較すると、oneflow コンパイルでは精度をほとんど損なうことなく rt を 40% 以上削減できることがわかります。ただし、新しいパイプラインを初めて使用してイメージを生成する場合、数十の時間がかかります。ウォームアップとして数秒のコンパイル時間がかかります。
これに基づいて、Deepcache は rt をさらに 15% ～ 25% 削減できますが、同時に、キャッシュ間隔が増加するにつれて、生成効果の違いがますます明らかになります。
oneflowはcontrolnetを使用したSD1.5モデルにも有効です
安定高速は外部パッケージに大きく依存しており、さまざまなバージョンの問題や外部ツールのエラーが発生しやすく、oneflow と同様に、最初のイメージ生成にある程度のコンパイル時間がかかり、最終的な高速化効果は若干劣ります。ワンフロー。

▐詳細な比較データ

最適化	平均生成時間 (秒) *512512，50ステップ**	加速効果	エフェクト1の生成	エフェクト2の生成	エフェクト3の生成
ディフューザー	3.3701	0
ディフューザー+BF16	3.3669	≈0
ディフューザー+コントロールネット	4.7452
ディフューザー+ワンフローコンピレーション	1.9857	41.08%
ディフューザー + ワンフローコンパイル + コントロールネット	2.8017
ディフューザー + ワンフローコンパイル + ディープキャッシュ	間隔=2：1.4581	56.73%(15.65%)
	間隔=3：1.3027	61.35%(20.27%)
	間隔=5：1.1583	65.63%(24.55%)
ディフューザー+高速	2.3799	29.38%

SDXL 加速テスト

SD1.5 とは異なり、このパートでは主に lora の使用シナリオで oneflow、deepcache、lcm-lora の最適化効果をテストします。

▐テスト環境

A10 + cu118 + py310 + トーチ2.0.1 + ディフューザー0.26.3

文生图、プロンプト：「猫の写真。光を集中させて、シャープで明確なエッジを作成します。」

▐テスト結果

基本的なsdxlモデル:

固定シードの条件下では、sdxl モデルは、異なる加速スキームを使用することで画像を生成する効果に影響を与える可能性が高くなります。
Oneflow は rt を 24% しか削減できませんが、それでも生成された画像の精度を保証できます。
Deepcache は、間隔が 2 (つまり、キャッシュが 1 回のみ使用される) の場合、rt は 42% 削減されますが、間隔が 5 の場合、rt は 69% 削減されます。画像も一目瞭然。
lcm-lora は、グラフの生成に必要なステップ数を大幅に削減し、推論の高速化を大幅に実現できますが、事前にトレーニングされた重みを使用する場合、安定性が非常に低く、ステップ数に非常に敏感です。要求された画像と一致する安定した出力を保証する
oneflow と deepcache/lcm-lora は一緒に使用できます

ロラ：

lora をロードすると、ディフューザーの推論速度が大幅に低下します。低下の程度は、使用される lora の種類と量に関係します。
deepcache はまだ機能しており、精度の問題はまだありますが、キャッシュ間隔が短い場合には違いは大きくありません
lora を使用する場合、oneflow コンパイルではシードを修正して元のバージョンとの一貫性を保つことができません。
Oneflow コンパイルは、lora をロードした後の推論速度を最適化します。複数の lora がロードされた場合、推論 rt は lora がロードされていない場合とほぼ同じになり、高速化効果が非常に大きくなります。たとえば、毛糸+水彩を2ローラ同時に使用すると、rtを約65%削減できます。
oneflow は lora のロード時間を若干最適化しましたが、lora ロード後の設定操作時間が増加しました。

▐詳細な比較データ

最適化	ローラ	*平均生成時間(秒) 512512、50step**	Lora のロード時間 (秒)	lora 変更時間 (秒)	効果1	効果2	効果3
ディフューザー	なし	4.5713
	糸	7.6641	13.9235 11.0447	0.06~0.09 根据配置的lora数量
	watercolor	7.0263
	yarn+watercolor	10.1402
diffusers+bf16	无	4.6610
	yarn	7.6367	12.6095 11.1033	0.06~0.09 根据配置的lora数量
	watercolor	7.0192
	yarn+ watercolor	10.0729
diffusers+deepcache	无	interval=2：2.6402
	yarn	interval=2：4.6076
	watercolor	interval=2：4.3953
	yarn+ watercolor	interval=2：5.9759
	无	interval=5： 1.4068
	yarn	interval=5：2.7706
	watercolor	interval=5：2.8226
	yarn+watercolor	interval=5：3.4852
diffusers+oneflow编译	无	3.4745
	yarn	3.5109	11.7784 10.3166	0.5左右移除lora 0.17
	watercolor	3.5483
	yarn+watercolor	3.5559
diffusers+oneflow编译+deepcache	无	interval=2：1.8972
	yarn	interval=2：1.9149
	watercolor	interval=2：1.9474
	yarn+watercolor	interval=2：1.9647
	无	interval=5：0.9817
	yarn	interval=5：0.9915
	watercolor	interval=5：1.0108
	yarn+watercolor	interval=5：1.0107
diffusers+lcm-lora		4step：0.6113
diffusers+oneflow编译+lcm-lora		4step：0.4488

应用：AI试衣加速

AI试衣业务场景使用了算法在diffusers框架基础上改造的专用pipeline，功能为根据待替换服饰图对原模特图进行换衣，基础模型为SD2.1。

根据调研的结果，deepcache与oneflow是优先考虑的加速方案，同时，由于pytorch版本较低，也可以尝试使用较新版本的pytorch进行加速。

▐ 测试环境

A10 + cu118 + py310 + torch2.0.1 + diffusers0.21.4

图生图（示意图，仅供参考）：

待替换服饰	原模特图

▐ 测试结果

pytorch2.2版本集成了FlashAttention2，更新版本后，推理加速效果明显
deepcache仍然有效，为了尽量不损失精度，可设置interval为2或3
对于被“魔改”的pipeline和子模型，oneflow的图转换功能无法处理部分操作，如使用闭包函数替换forward、使用布尔索引等，而且很多错误原因较难通过报错信息来定位。在进行详细的排查之后，我们尝试了改造原模型代码，对其中不被支持的操作进行替换，虽然成功地在没有影响常规生成效果的前提下完成了改造，通过了oneflow编译，但编译后的生成效果很差，可以看出oneflow对pytorch的支持仍然不够完善
最终采取pytorch2.2.1+deepcache的结合作为加速方案，能够实现rt降低40%~50%、生成效果基本一致且不需要过多改动原服务代码

▐ 详细对比数据

优化方法	平均生成耗时（秒） *576768，25step**	生成效果
diffusers	22.7289
diffusers+torch2.2.1	15.5341
diffusers+torch2.2.1+deepcache	11.7734
diffusers+oneflow编译	17.5857
diffusers+deepcache	interval=2：18.0031
	interval=3：16.5286
	interval=5：15.0359