# 场景介绍
阅读本文前建议您先了解以下内容：
- Stable Diffusion的基础知识，可参考[Stable Diffusion github](https://github.com/CompVis/stable-diffusion)、[Stable Diffusion wikipedia](https://zh.wikipedia.org/zh-hans/Stable_Diffusion)、[diffusers github](https://github.com/huggingface/diffusers)、[Stable Diffusion with diffusers](https://huggingface.co/blog/stable_diffusion)。
- 推理业务迁移到昇腾的通用流程，可参考[推理迁移指导（MindSporeLite）](https://support.huaweicloud.com/bestpractice-modelarts/modelarts_10_0154.html)。
  ![](https://support.huaweicloud.com/bestpractice-modelarts/public_sys-resources/note_3.0-zh-cn.png)
  由于Huggingface网站的限制，访问Stable Diffusion链接时需使用代理服务器，否则可能无法访问网站。
  
在Stable Diffusion迁移适配时，更多的时候是在适配Diffusers和Stable Diffusion WebUI，使其能够在昇腾的设备上运行。其中，Diffusers遵循了Huggingface的"[single-file policy](https://huggingface.co/blog/transformers-design-philosophy)"的设计原则，它的三个主要模块Pipeline、Schedulers和预训练模型中，Pipeline和Schedulers都完全遵循了"single-file policy"原则。该设计原则更推荐直接复制粘贴代码，而不是进行抽象处理。因此，与模型前向运算相关的所有源代码都被直接复制粘贴到同一个文件中，而不是调用某些抽象提取出的模块化库。Diffusers的这种设计原则的好处是代码简单易用、对代码贡献者友好。然而，这种反软件结构化的设计也有明显的缺点。由于缺乏统一的模块化库，对于昇腾适配而言变得更加复杂，必须针对每个不同业务的Pipeline进行单独适配。
本文以Stable Diffusion v1.5的图生图为例，通过可以直接执行的样例代码介绍Diffusers的昇腾迁移过程。对于其他pipeline的迁移，可以在充分理解其代码的基础上，参考本文的思路进行举一反三。Stable Diffusion WebUI的迁移不包含在本文中，具体原因详见[Stable Diffusion WebUI如何适配](https://support.huaweicloud.com/bestpractice-modelarts/modelarts_10_2013.html#ZH-CN_TOPIC_0000001749527461__li19973163491010)。
AI推理应用运行在昇腾设备上一般有两种方式：
- 方式1：通过Ascend PyTorch，后端执行推理，又称在线推理。
- 方式2：通过模型静态转换后，执行推理，又称离线推理。
通常为了获取更好的推理性能，推荐使用方式2的离线推理。下文将以Diffusers img2img onnx pipeline为示例来讲解如何进行离线推理模式下的昇腾迁移。迁移的整体流程如下图所示：
图1迁移流程图   
![](https://support.huaweicloud.com/bestpractice-modelarts/figure/zh-cn_image_0000001749527477.png "点击放大")