国产精品自产拍在线_日韩精品成人无码专区免费_一级aⅴ性色生活片_无码亚洲精品视频_亚欧无码中文字幕_911国产影院在线观看

以下文章來源于谷歌云服務，作者 Google Cloud

背景

現如今隨著 AIGC 這個話題越來越熱，越來越多優秀的開源項目基于文生圖的 AI 模型如 MidJourney，Stable Diffusion 等應運而生。Stable Diffusion 是一個文字生成圖像的 Diffusion 模型，它能夠根據給定任何文本輸入生成逼真的圖像。我們在 GitHub Repo 中提供了三種不同的解決方案 (可參考https://github.com/nonokangwei/Stable-Diffusion-on-GCP)，可以快速地分別在 GCP Vertex AI，GKE，和基于 Agones 的平臺上部署 Stable Diffusion，以提供彈性的基礎設施保證 Stable Diffusion 提供穩定的服務。本文將重點討論 Stable Diffusion 模型在 GKE 上的實踐。

提出問題

在實踐中，我們也遇到了一些問題，例如 Stable Diffusion 的容器鏡像較大，大約達到 10-20GB，導致容器在啟動過程中拉取鏡像的速度變慢，從而影響了啟動時間。在需要快速擴容的場景下，啟動新的容器副本需要超過 10 分鐘的時間，嚴重影響了用戶體驗。

我們看到容器的啟動過程，按時序排列：

●觸發 Cluster Autoscaler 擴容 + Node 啟動并調度 Pod: 225s

●啟動 Pull Image:4s

●拉取鏡像: 5m 23s

●啟動 Pod:1s

●能夠提供 sd-webui 的服務 (大約): > 2m

在這段時序分析中，我們可以看到，在 Stable Diffusion WebUI 運行在容器上啟動慢主要面臨的問題是由于整個 runtime 依賴較多，導致容器鏡像太大從而花費了很長時間拉取下載、也造成了 pod 啟動初始化加載時間過長。于是，我們考慮優化啟動時間從以下三個方面入手：

●優化 Dockerfile，選擇正確的 base image，精簡 runtime 的依賴安裝，減小鏡像大小。

●借助基礎環境與 runtime 依賴分離方式，通過磁盤復制方式加速運行環境的創建。

●通過 GKE Image Streaming 優化鏡像加載時間，利用 Cluster Autoscaler 提升彈性擴縮容速度。

本文著重為大家介紹通過基礎環境與 runtime 依賴分離方式，借助磁盤復制的高性能來優化 Stable Diffusion WebUI 容器啟動時間的方案。

優化 Dockerfile

首先，我們可以參考官方 Stable Diffusion WebUI 安裝說明，生成其 Dockerfile。在這里給大家一個參考: https://github.com/nonokangwei/Stable-Diffusion-on-GCP/blob/main/Stable-Diffusion-UI-Agones/sd-webui/Dockerfile

在初始構建的 Stable Diffusion 的容器鏡像中，我們發現除了基礎鏡像 nvidia runtime 之外，還安裝了大量的庫和擴展等。

▲調優之前容器鏡像大小為 16.3GB

在 Dockerfile 優化方面，我們對 Dockerfile 進行分析后，發現 nvidia runtime 約占 2GB，而 PyTorch 庫是一個非常大的包，約占 5GB。另外 Stable Diffusion 及其擴展等也占據了一定的空間。因此，我們按照最小可用環境為原則，去除環境中不必要的依賴。將 nvidia runtime 作為基礎鏡像，然后把 PyTorch、Stable Diffusion 的庫和擴展等從原始鏡像中分離出來，單獨存放在文件系統中。

以下是初始的 Dockerfile 的片段。

# Base image

FROM nvidia/cuda:11.8.0-runtime-ubuntu22.04

RUN set -ex &&

apt update &&

apt install -y wget git python3 python3-venv python3-pip libglib2.0-0 pkg-config libcairo2-dev &&

rm -rf /var/lib/apt/lists/*

# Pytorch

RUN python3 -m pip install torch==1.13.1+cu117 torchvision==0.14.1+cu117 --extra-index-url https://download.pytorch.org/whl/cu117

…

# Stable Diffusion

RUN git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git

RUN git clone https://github.com/Stability-AI/stablediffusion.git /stable-diffusion-webui/repositories/stable-diffusion-stability-ai

RUN git -C /stable-diffusion-webui/repositories/stable-diffusion-stability-ai checkout cf1d67a6fd5ea1aa600c4df58e5b47da45f6bdbf

…

# Stable Diffusion extensions

RUN set -ex && cd stable-diffusion-webui

&& git clone https://gitcode.net/ranting8323/sd-webui-additional-networks.git extensions/sd-webui-additional-networks

&& git clone https://gitcode.net/ranting8323/sd-webui-cutoff extensions/sd-webui-cutoff

&& git clone https://ghproxy.com/https://github.com/toshiaki1729/stable-diffusion-webui-dataset-tag-editor.git extensions/stable-diffusion-webui-dataset-tag-editor

我們在移除 Pytorch 的庫和 Stable Diffusion 之后，我們只保留了基礎鏡像 nvidia runtime 在新的 Dockerfile 中。

FROM nvidia/cuda:11.8.0-runtime-ubuntu22.04

RUN set -ex &&

apt update &&

apt install -y wget git python3 python3-venv python3-pip libglib2.0-0 &&

rm -rf /var/lib/apt/lists/*

▲基礎鏡像變成了 2GB

其余的運行時類庫和 extension 等存放在磁盤鏡像中，磁盤鏡像的大小為 6.77GB。采用磁盤鏡像的好處是，它可以最多支持同時恢復 1,000 塊磁盤，完全能滿足大規模擴縮容的使用場景。

掛載磁盤到 GKE 節點

然而，問題來了，如何將這個單獨的文件系統掛載到容器運行時中呢？一種想法是使用 Persistent VolumeClaim (PVC) 進行掛載，但由于 Stable Diffusion WebUI 在運行時既需要讀取又需要寫入磁盤，而 GKE 的 PD CSI 驅動程序目前不支持多寫入 ReadWriteMany，只有像 Filestore 這樣的 NFS 文件系統才能支持，但是通過網絡掛載的 Filestore 就延遲來說仍然無法達到快速啟動的效果。同時，由于 GKE 目前不支持在創建或更新 Nodepool 時掛載磁盤，所以我們考慮使用 DaemonSet 在 GKE 節點啟動時掛載磁盤。具體做法如下：

那么如何將磁盤掛載到 GKE 的節點上呢？可以直接調用 Cloud SDK，創建基于磁盤鏡像的磁盤。

gcloud compute disks create sd-lib-disk-$NOW --type=pd-balanced --size=30GB --zone=$ZONE --image=$IMAGE_NAME

gcloud compute instances attach-disk ${MY_NODE_NAME} --disk=projects/$PROJECT_ID/zones/$ZONE/disks/sd-lib-disk-$NOW --zone=$ZONE

利用 GKE Image Streaming

和 Cluster Autoscaler

另外，正如我們前面提到的那樣，在優化鏡像下載和加載時間方面，我們還啟用了 GKE Image Streaming 來加速鏡像的拉取速度。它的工作原理是使用網絡掛載將容器數據層掛載到 containerd 中，并在網絡、內存和磁盤上使用多個緩存層對其進行支持。一旦我們準備好 Image Streaming 掛載，您的容器就會在幾秒鐘內從 ImagePulling 狀態轉換為 Running (無論容器大小)；這有效地將應用程序啟動與容器映像中所需數據的數據傳輸并行化。因此，您可以看到更快的容器啟動時間和更快速的自動縮放。

我們開啟了 Cluster Autoscaler 功能，讓有更多的請求到來時，GKE 節點自動進行彈性擴展。通過 Cluster Autoscaler 觸發并決定擴展到多少個節點來接收新增的請求。當 CA 觸發了新的一輪擴容，新的 GKE 節點注冊到集群以后，Daemonset 就會開始工作，幫助掛載存儲了 runtime 依賴的磁盤鏡像，而 Stable Diffusion Deployment 則會通過 HostPath 來訪問這個掛載在節點上的磁盤。

我們還使用了 Cluster Autoscaler 的 Optimization Utilization Profile 來縮短擴縮容時間、節省成本并提高機器利用率。

最后的啟動效果如下：

按時序排列

●觸發 Cluster Autoscaler 擴容:38s

●Node 啟動并調度 Pod:89s

●掛載 PVC:4s

●啟動 Pull Image:10s

●拉取鏡像:1s

●啟動 Pod:1s

●能夠提供 sd-webui 的服務 (大約): 65s

總共經歷了大約 3 分鐘的時間，就完成了啟動一個新的 Stale Diffusion 容器實例，并在一個新的 GKE 節點上進行正常服務的過程。相比于之前的 12 分鐘，可以看見，明顯的提升啟動速度改善了用戶體驗。

完整代碼: https://github.com/nonokangwei/Stable-Diffusion-on-GCP/tree/main/Stable-Diffusion-UI-Agones/optimizated-init

通過 VolumeSnapshot

除了掛載 Disk 到 GKE 節點上，還有一種嘗試，我們可以使用 StatefulSet 來掛載 PVC。

具體做法如下:先定義一個 storageclass，注意我們使用DiskImageType: images來指定 PVC從 Disk Image 來恢復，而不是 Snapshot。

●Snapshot 每 10 分鐘只能恢復一次，一小時以內恢復 6 次 Disk 的限制。

●而 Image 可以支持每 30 秒恢復一次，最多 1,000 個 Disk。

apiVersion: snapshot.storage.k8s.io/v1

kind: VolumeSnapshotClass

metadata:

driver: pd.csi.storage.gke.io

deletionPolicy: Delete

parameters:

DiskImageType: images

再定義一個 VoluemSnapShotContent，它指定了 source 為一個 Disk Image sd-image。

apiVersion: snapshot.storage.k8s.io/v1

kind: VolumeSnapshotContent

metadata:

spec:

deletionPolicy: Retain

driver: pd.csi.storage.gke.io

volumeSnapshotClassName: image-class

source:

snapshotHandle:projects/flius-vpc-2/global/images/sd-image

volumeSnapshotRef:

namespace: default

接下來，我們再創建一個 VolumeSnapShot，指定它的 source 是剛剛定義的VoluemSnapShotContent。

apiVersion: snapshot.storage.k8s.io/v1

kind: VolumeSnapshot

metadata:

namespace: default

spec:

source:

volumeSnapshotContentName:test-snapshotcontent-from-image

最后，我們創建一個 StatefulSet 來掛載這個 VolumeSnapShot。

apiVersion: apps/v1

kind: StatefulSet

metadata:

labels:

app: stable-diffusion

spec:

podManagementPolicy: "Parallel"

replicas: 1

selector:

matchLabels:

app: stable-diffusion

template:

metadata:

labels:

app: stable-diffusion

spec:

containers:

- name: stable-diffusion-webui

image: us-central1-docker.pkg.dev/flius-vpc-2/stable-diffusion-repo/sd-webui-final:0.1

command: ["/bin/bash"]

args: ["-c", "source /runtime-lib/bin/activate; cp/user-watch.py /runtime-lib/stable-diffusion-webui/user-watch.py;cp/start.sh /runtime-lib/stable-diffusion-webui/start.sh; cd /runtime-lib/stable-diffusion-webui; python3 launch.py --listen --xformers --enable-insecure-extension-access--no-gradio-queue" ]

volumeMounts:

- mountPath: "/runtime-lib"

resources:

limits:

nvidia.com/gpu: 1

ports:

- containerPort: 7860

volumeClaimTemplates:

- metadata:

spec:

dataSource:

kind: VolumeSnapshot

apiGroup: snapshot.storage.k8s.io

accessModes: [ "ReadWriteOnce" ]

storageClassName: "standard-rwo"

resources:

requests:

storage: 30Gi

我們嘗試擴容更多的副本。

kubectl scale statefulset stable-diffusion-statefulset-image --replicas=15

可見 GKE 可以支持并行的啟動這些 Pod，并且分別掛載相應的磁盤。

PersistentVolumeClaims

完整代碼:

https://github.com/Leisureroad/volumesnapshot-from-diskimage

最終，我們可以看見如下的 Stable Diffusion 的 WebUI。

?點擊屏末|閱讀原文|了解更多 Google Cloud 技術趨勢與最新解讀

原文標題：優化 Stable Diffusion 在 GKE 上的啟動體驗

文章出處：【微信公眾號：谷歌開發者】歡迎添加關注！文章轉載請注明出處。

聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容侵權或者其他違規問題，請聯系本站處理。舉報投訴

谷歌

谷歌

+關注

關注
27

文章
6142

瀏覽量
105111

原文標題：優化 Stable Diffusion 在 GKE 上的啟動體驗

文章出處：【微信號：Google_Developers，微信公眾號：谷歌開發者】歡迎添加關注！文章轉載請注明出處。

在主板上優化PCIe通道設置

在主板上優化PCIe通道設置是提升系統性能的重要步驟，以下是具體的優化建議：一、了解主板和PCIe規格查閱主板手冊：首先，需要了解主板支持的PCIe版本（如PCIe 3.0、PC

發表于 11-06 09:30 ?685次閱讀

DRA7xx器件上的Android啟動優化

電子發燒友網站提供《DRA7xx器件上的Android啟動優化.pdf》資料免費下載

發表于 10-11 09:41 ?0次下載

DRA7xx器件<b class='flag-5'>上</b>的Android<b class='flag-5'>啟動</b><b class='flag-5'>優化</b>

使用TPS61178x優化啟動的環路補償

電子發燒友網站提供《使用TPS61178x優化啟動的環路補償.pdf》資料免費下載

發表于 09-25 09:58 ?0次下載

使用TPS61178x<b class='flag-5'>優化</b><b class='flag-5'>啟動</b>的環路補償

優化 FPGA HLS 設計

其他設計經驗的推薦策略列表。單擊“Start Recipe”開始優化。如果在云上運行，則應同時運行多個編譯以減少時間。優化過程和結果在第一輪（“熱

發表于 08-16 19:56

實操: 如何在AirBox上跑Stable Diffusion 3

StableDiffusion3Medium是一種多模態擴散變換器(MMDiT)文本到圖像模型，在圖像質量、排版、復雜提示理解和資源效率方面具有顯著提升的性能。目前瑞莎團隊

發表于 07-23 08:34 ?218次閱讀

實操: 如何在AirBox<b class='flag-5'>上</b>跑<b class='flag-5'>Stable</b> <b class='flag-5'>Diffusion</b> 3

4.3s，Linux快速啟動優化方法分享，基于全志T113-i國產平臺！

系統資源浪費，例如電力和硬件資源。而優化啟動時間可節省這些資源，從而提高系統的效率和可靠性。另外，在某些嵌入式系統和設備中，啟動時間對于系統的穩定性和可靠性至關重要，因此盡可能縮短

發表于 07-09 11:50

OpenHarmony之開機優化

對其進行詳細的性能分析，從而優化系統啟動速度和運行效率。三丶開機優化開機優化的主要目的是為了快速啟動開機動畫和退出開機動畫（顯示桌面）。

發表于 07-01 16:39

設置應用冷啟動優化案例

應用，詳細介紹如何進行冷啟動的性能優化。 AppSpawn 預加載可以通過預加載一些so，加快冷啟動的速度。預加載so 配置在appspawn_preload.json文件中。文件

發表于 04-22 16:31

UL Procyon AI 發布圖像生成基準測試，基于Stable Diffusion

UL去年發布的首個Windows版Procyon AI推理基準測試，以計算機視覺工作負載評估AI推理性能。新推出的圖像生成測試將提供統一、精確且易于理解的工作負載，用以保證各支持硬件間公平、可比的性能表現。

發表于 03-25 16:16 ?839次閱讀

韓國科研團隊發布新型AI圖像生成模型KOALA，大幅優化硬件需求

由此模型的核心在于其運用了“知識蒸餾”（knowledge distillation）技術，這使得開源圖像生成工具Stable Diffusion XL可大幅縮小其規模。原Stable Dif

發表于 03-01 14:10 ?588次閱讀

Stability AI試圖通過新的圖像生成人工智能模型保持領先地位

Stability AI的最新圖像生成模型Stable Cascade承諾比其業界領先的前身Stable Diffusion更快、更強大，而Stable

發表于 02-19 16:03 ?896次閱讀

MCU上電不啟動的可能原因分析

在GD32 MCU上，BOOT引腳決定了MCU的啟動方式，通常BOOT0引腳下拉時是flash啟動，如果BOOT電平不對就不會執行我們下載的程序了。

發表于 01-12 17:08 ?1968次閱讀

MCU為什么上電不啟動

相信很多朋友們都遇到過，自信滿滿的將程序下載到板子上，發現MCU居然沒啟動。那這個現象可能有很多問題會導致，讓我們來看看會有哪些原因。

發表于 01-11 09:41 ?1044次閱讀

一種新的分割模型Stable-SAM

SAM、HQ-SAM、Stable-SAM在提供次優提示時的性能比較，Stable-SAM明顯優于其他算法。這里也推薦工坊推出的新課程《如何將深度學習模型部署到實際工程中？

發表于 12-29 14:35 ?627次閱讀

免費開源圖像修復工具lama-cleaner介紹

Lama Cleaner 是由 SOTA AI 模型提供支持的免費開源圖像修復工具。可以從圖片中移除任何不需要的物體、缺陷和人，或者擦除并替換（powered by stable diffusion）圖片上的任何東西。

發表于 12-04 10:23 ?2821次閱讀