国产精品久久久aaaa,日日干夜夜操天天插,亚洲乱熟女香蕉一区二区三区少妇,99精品国产高清一区二区三区,国产成人精品一区二区色戒,久久久国产精品成人免费,亚洲精品毛片久久久久,99久久婷婷国产综合精品电影,国产一区二区三区任你鲁

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

優(yōu)化 Stable Diffusion 在 GKE 上的啟動體驗

谷歌開發(fā)者 ? 來源:未知 ? 2023-06-03 08:35 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

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

背景


現如今隨著 AIGC 這個話題越來越熱,越來越多優(yōu)秀的開源項目基于文生圖的 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 提供穩(wěn)定的服務。本文將重點討論 Stable Diffusion 模型在 GKE 上的實踐。


提出問題


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



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

觸發(fā) Cluster Autoscaler 擴容 + Node 啟動并調度 Pod: 225s

啟動 Pull Image:4s

拉取鏡像: 5m 23s

啟動 Pod:1s

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


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

優(yōu)化 Dockerfile,選擇正確的 base image,精簡 runtime 的依賴安裝,減小鏡像大小。

借助基礎環(huán)境與 runtime 依賴分離方式,通過磁盤復制方式加速運行環(huán)境的創(chuàng)建。

通過 GKE Image Streaming 優(yōu)化鏡像加載時間,利用 Cluster Autoscaler 提升彈性擴縮容速度。


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


優(yōu)化 Dockerfile


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


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


▲調優(yōu)之前容器鏡像大小為 16.3GB


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


以下是初始的 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 塊磁盤,完全能滿足大規(guī)模擴縮容的使用場景。



掛載磁盤到 GKE 節(jié)點


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



那么如何將磁盤掛載到 GKE 的節(jié)點上呢?可以直接調用 Cloud SDK,創(chuàng)建基于磁盤鏡像的磁盤。


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


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


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


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


最后的啟動效果如下:



按時序排列

觸發(fā) Cluster Autoscaler 擴容:38s

Node 啟動并調度 Pod:89s

掛載 PVC:4s

啟動 Pull Image:10s

拉取鏡像:1s

啟動 Pod:1s

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


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


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


通過 VolumeSnapshot


除了掛載 Disk 到 GKE 節(jié)點上,還有一種嘗試,我們可以使用 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:

name: image-class

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:

name: test-snapshotcontent-from-image

spec:

deletionPolicy: Retain

driver: pd.csi.storage.gke.io

volumeSnapshotClassName: image-class

source:

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

volumeSnapshotRef:

name: test-snapshot

namespace: default


接下來,我們再創(chuàng)建一個 VolumeSnapShot,指定它的 source 是剛剛定義的VoluemSnapShotContent。


apiVersion: snapshot.storage.k8s.io/v1

kind: VolumeSnapshot

metadata:

name: test-snapshot

namespace: default

spec:

source:

volumeSnapshotContentName:test-snapshotcontent-from-image


最后,我們創(chuàng)建一個 StatefulSet 來掛載這個 VolumeSnapShot。


apiVersion: apps/v1

kind: StatefulSet

metadata:

name: stable-diffusion-statefulset-image

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"

name: runtime-lib

resources:

limits:

nvidia.com/gpu: 1

ports:

- containerPort: 7860

volumeClaimTemplates:

- metadata:

name: runtime-lib

spec:

dataSource:

name: test-snapshot

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 技術趨勢與最新解讀


原文標題:優(yōu)化 Stable Diffusion 在 GKE 上的啟動體驗

文章出處:【微信公眾號:谷歌開發(fā)者】歡迎添加關注!文章轉載請注明出處。

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

    關注

    27

    文章

    6254

    瀏覽量

    111366

原文標題:優(yōu)化 Stable Diffusion 在 GKE 上的啟動體驗

文章出處:【微信號:Google_Developers,微信公眾號:谷歌開發(fā)者】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關推薦
    熱點推薦

    從炫技到量產,具身智能要突破哪些瓶頸?

    LingBot-VLA 開源,具身智能的 Stable Diffusion 來了?
    的頭像 發(fā)表于 01-28 17:12 ?8951次閱讀
    從炫技到量產,具身智能要突破哪些瓶頸?

    LDO性能優(yōu)化的應用技巧

    本文圍繞LDO性能優(yōu)化的關鍵環(huán)節(jié)展開,系統(tǒng)闡述了從啟動過程控制、不同負載條件下穩(wěn)定工作到瞬態(tài)響應提升的全鏈路應用技巧。內容涵蓋啟動過沖抑制、電子負載CC/CR模式下的適應性
    的頭像 發(fā)表于 01-22 10:24 ?4568次閱讀
    LDO性能<b class='flag-5'>優(yōu)化</b>的應用技巧

    GM9-2003/D3000主板圖形適配方案:Ventoy啟動與顯卡兼容性優(yōu)化指南

    GM9-2003/D3000飛騰商務主板使用Ventoy工具安裝服務器系統(tǒng)時,若搭配AMD R5 230顯卡,可能出現啟動階段花屏現象;而切換至MTT S30顯卡則顯示正常。此問題源于顯卡驅動
    的頭像 發(fā)表于 01-04 14:36 ?975次閱讀
    GM9-2003/D3000主板圖形適配方案:Ventoy<b class='flag-5'>啟動</b>與顯卡兼容性<b class='flag-5'>優(yōu)化</b>指南

    Linux系統(tǒng)冗余設計裁剪開機時間優(yōu)化

    1、保留現有功能(RT-Linux實時特性、SPI驅動正常工作、網口通信正常、USB驅動)的前提下,將Upboard開發(fā)板的Linux系統(tǒng)開機時間從當前~60秒優(yōu)化至≤20秒(啟動
    發(fā)表于 12-16 22:17

    本地部署Stable Diffusion實現AI文字生成高質量矢量圖片應用于電子商務

    本地部署Stable Diffusion
    的頭像 發(fā)表于 11-28 07:19 ?738次閱讀

    CW32時鐘的啟動過程

    SYSCTRL_HSE.STABLE 被置 1;如果在一定時間內未檢測到 SYSCTRL_HSE.WAITCYCLE 個時鐘信號則認為 HSE 振蕩器起振失敗。 其它時鐘振蕩器的時鐘啟動過程類似,但注意各時鐘
    發(fā)表于 11-13 07:49

    潤和軟件優(yōu)化昇騰310B啟動時間

    邊緣計算場景中,“啟動速度”往往直接決定著設備的響應效率——工業(yè)監(jiān)控設備若啟動過慢,可能錯過關鍵數據采集;智能電網邊緣網關若恢復遲緩,會影響電力調度穩(wěn)定性;無人機飛控設備若初始化耗時久,甚至可能延誤任務執(zhí)行。昇騰310B作為邊
    的頭像 發(fā)表于 10-14 14:06 ?764次閱讀
    潤和軟件<b class='flag-5'>優(yōu)化</b>昇騰310B<b class='flag-5'>啟動</b>時間

    【Sipeed MaixCAM Pro開發(fā)板試用體驗】基于MaixCAM-Pro的AI生成圖像鑒別系統(tǒng)

    手繪掃描圖。該模型將被優(yōu)化并部署MaixCAM-Pro邊緣計算設備,使其具備離線、實時、低功耗的圖片鑒別能力,可應用于藝術鑒定、內容審核、學術誠信核查等多個場景。 2. 核心目標 高精度分類:模型
    發(fā)表于 08-21 13:59

    無感FOC算法電機啟動時具體如何優(yōu)化性能?--【其利天下】

    現代電機控制系統(tǒng)中,無感FOC(磁場定向控制)算法因其卓越的性能表現而備受關注。尤其是電機啟動階段,無感FOC算法通過一系列優(yōu)化措施,極大地提升了電機的
    的頭像 發(fā)表于 08-08 18:38 ?1517次閱讀
    無感FOC算法<b class='flag-5'>在</b>電機<b class='flag-5'>啟動</b>時具體如何<b class='flag-5'>優(yōu)化</b>性能?--【其利天下】

    無法NPU推理OpenVINO?優(yōu)化的 TinyLlama 模型怎么解決?

    NPU 推斷 OpenVINO?優(yōu)化的 TinyLlama 模型。 遇到的錯誤: get_shape was called on a descriptor::Tensor with dynamic shape
    發(fā)表于 07-11 06:58

    鴻蒙5開發(fā)寶藏案例分享---冷啟動優(yōu)化案例分享

    程 ?非必要資源延遲加載 ?首屏數據本地緩存優(yōu)先 優(yōu)化后我們的應用冷啟動速度提升300%+!這些寶藏案例都在官方性能優(yōu)化文檔中,強烈建議大家仔細研究。 最后送大家一句話 :性能優(yōu)化不是
    發(fā)表于 06-12 17:22

    系統(tǒng)啟動時間優(yōu)化方案--基于米爾MYD-YG2LX開發(fā)板

    設接口,工業(yè)、醫(yī)療、電力等行業(yè)都得到廣泛的應用。 米爾基于瑞薩RZ/G2L開發(fā)板本文主要介紹基于MYD-YG2LX開發(fā)板進行系統(tǒng)啟動時間優(yōu)化的調試案例,一般啟動方式有去掉常規(guī)uboo
    發(fā)表于 05-09 18:03

    ?Diffusion生成式動作引擎技術解析

    Diffusion生成式動作引擎 Diffusion生成式動作引擎是一種基于擴散模型(Diffusion Models)的生成式人工智能技術,專注于生成連續(xù)、逼真的人類動作或動畫序列。這類引擎
    的頭像 發(fā)表于 03-17 15:14 ?3044次閱讀

    優(yōu)化模式下低啟動低消耗的充電器ic U6018

    可能會對電路中的其他組件造成損害,而過小的啟動電流則可能導致電路無法正常啟動。來看看這顆優(yōu)化模式下低消耗的充電器icU6018!集成電路開始工作之前,充電器icU
    的頭像 發(fā)表于 03-13 16:15 ?806次閱讀
    <b class='flag-5'>優(yōu)化</b>模式下低<b class='flag-5'>啟動</b>低消耗的充電器ic U6018

    使用OpenVINO GenAI和LoRA適配器進行圖像生成

    借助生成式 AI 模型(如 Stable Diffusion 和 FLUX.1),用戶可以將平平無奇的文本提示詞轉換為令人驚艷的視覺效果。
    的頭像 發(fā)表于 03-12 13:49 ?1873次閱讀
    使用OpenVINO GenAI和LoRA適配器進行圖像生成