ディフューザ 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
文生图、プロンプト:「猫の写真。光を集中させて、シャープで明確なエッジを作成します。」


▐テスト結果  


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

▐詳細な比較データ  


最適化

平均生成時間 (秒)

512*512,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モデル:

  1. 固定シードの条件下では、sdxl モデルは、異なる加速スキームを使用することで画像を生成する効果に影響を与える可能性が高くなります。

  2. Oneflow は rt を 24% しか削減できませんが、それでも生成された画像の精度を保証できます。

  3. Deepcache は、間隔が 2 (つまり、キャッシュが 1 回のみ使用される) の場合、rt は 42% 削減されますが、間隔が 5 の場合、rt は 69% 削減されます。画像も一目瞭然。

  4. lcm-lora は、グラフの生成に必要なステップ数を大幅に削減し、推論の高速化を大幅に実現できますが、事前にトレーニングされた重みを使用する場合、安定性が非常に低く、ステップ数に非常に敏感です。要求された画像と一致する安定した出力を保証する

  5. oneflow と deepcache/lcm-lora は一緒に使用できます


ロラ:

  1. lora をロードすると、ディフューザーの推論速度が大幅に低下します。低下の程度は、使用される lora の種類と量に関係します。

  2. deepcache はまだ機能しており、精度の問題はまだありますが、キャッシュ間隔が短い場合には違いは大きくありません

  3. lora を使用する場合、oneflow コンパイルではシードを修正して元のバージョンとの一貫性を保つことができません。

  4. Oneflow コンパイルは、lora をロードした後の推論速度を最適化します。複数の lora がロードされた場合、推論 rt は lora がロードされていない場合とほぼ同じになり、高速化効果が非常に大きくなります。たとえば、毛糸+水彩を2ローラ同時に使用すると、rtを約65%削減できます。

  5. oneflow は lora のロード時間を若干最適化しましたが、lora ロード後の設定操作時間が増加しました。


▐詳細な比較データ  


最適化

ローラ

平均生成時間(秒) 512*512、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


图生图(示意图,仅供参考):

待替换服饰

原模特图


  测试结果


  1. pytorch2.2版本集成了FlashAttention2,更新版本后,推理加速效果明显

  2. deepcache仍然有效,为了尽量不损失精度,可设置interval为2或3

  3. 对于被“魔改”的pipeline和子模型,oneflow的图转换功能无法处理部分操作,如使用闭包函数替换forward、使用布尔索引等,而且很多错误原因较难通过报错信息来定位。在进行详细的排查之后,我们尝试了改造原模型代码,对其中不被支持的操作进行替换,虽然成功地在没有影响常规生成效果的前提下完成了改造,通过了oneflow编译,但编译后的生成效果很差,可以看出oneflow对pytorch的支持仍然不够完善

  4. 最终采取pytorch2.2.1+deepcache的结合作为加速方案,能够实现rt降低40%~50%、生成效果基本一致且不需要过多改动原服务代码


  详细对比数据


优化方法

平均生成耗时(秒)

576*768,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


总结


目前市面上有很多非常好用的开源模型加速工具,pytorch官方也不断将各种广泛采纳的优化技术整合到最新的版本中。


我们在初期的调研与测试环节尝试了很多加速方案,在排除了部分优化效果不明显、限制较大或效果不稳定的加速方法之后,初步认为deepcache和oneflow是多数情况下的较优解。


但在解决实际线上服务的加速问题时,oneflow表现不太令人满意,虽然oneflow团队针对SD系列模型开发了专用的加速工具包onediff,且一直保持高更新频率,但当前版本的onediff仍存在不小的限制。


如果使用的SD pipeline没有对unet的各种子模块进行复杂修改,oneflow仍然值得尝试;否则,确保pytorch版本为最新的稳定版本以及适度使用deepcache可能是更省心且有效的选择。


相关资料


  1. FlashAttention:

    • https://github.com/Dao-AILab/flash-attention

    • https://courses.cs.washington.edu/courses/cse599m/23sp/notes/flashattn.pdf

  2. oneflow

    • https://github.com/Oneflow-Inc/oneflow

    • https://github.com/siliconflow/onediff

  3. stable-fast

    • https://github.com/chengzeyi/stable-fast

  4. deepcache

    • https://github.com/horseee/DeepCache

  5. lcm-lora

    • https://latent-consistency-models.github.io/

  6. pytorch 2.2

  7. https://pytorch.org/blog/pytorch2-2/


团队介绍


我们是淘天集团内容技术AI工程团队,通过搭建完善的算法工程化一站式平台,辅助上千个淘宝图文、视频、直播等泛内容领域算法的工程落地、部署和优化,承接每日上亿级别的数字内容数据,支撑并推动AI技术在淘宝内容社交生态中的广泛应用。


本文分享自微信公众号 - 大淘宝技术(AlibabaMTT)。
如有侵权,请联系 [email protected] 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

90后程序员开发视频搬运软件、不到一年获利超 700 万,结局很刑! 高中生自创开源编程语言作为成人礼——网友锐评:依托答辩 RustDesk 由于诈骗猖獗,暂停国内服务 淘宝 (taobao.com) 重启网页版优化工作 Java 17 是最常用的 Java LTS 版本 Windows 10 市场份额达 70%,Windows 11 持续下滑 开源日报 | 谷歌扶持鸿蒙上位;开源Rabbit R1;Docker加持的安卓手机;微软的焦虑和野心;海尔电器把开放平台关了 Apple 发布 M4 芯片 谷歌删除 Android 通用内核 (ACK) 对 RISC-V 架构的支持 云风从阿里离职,未来计划制作 Windows 平台的独立游戏
{{o.name}}
{{m.name}}

おすすめ

転載: my.oschina.net/u/4662964/blog/11104137
おすすめ