您可以通過Knative解決方案在AIGC領域實現按需使用的Serverless能力,并且做到并發請求精準處理,實現自動彈性擴縮容。本文介紹如何基于Knative打造生產可用的Stable Diffusion服務。
索引
前提條件
已創建Kubernetes托管版集群,且集群版本為1.24及以上。
背景信息
阿里云不對第三方模型“Stable Diffusion”的合法性、安全性、準確性進行任何保證,阿里云不對由此引發的任何損害承擔責任。
您應自覺遵守第三方模型“Stable Diffusion”的用戶協議、使用規范和相關法律法規,并就使用第三方模型的合法性、合規性自行承擔相關責任。
隨著生成型AI技術能力的提升,大家越來越關注通過AI模型提升研發效率。作為AIGC (AI Gererative Content)領域的知名項目Stable Diffusion , 可以幫助用戶快速、準確地生成想要的場景及圖片。但目前使用Stable Diffusion會面臨如下問題:
單個Pod處理請求的吞吐率有限,如果多個請求轉發到同一個Pod,會導致服務端過載異常,因此需要精準的控制單個Pod請求并發處理數。
由于GPU資源很珍貴,期望做到按需使用資源,在業務低谷及時釋放GPU資源。
基于以上兩個問題,阿里云容器服務提供Knative解決方案,可以做到基于并發請求數精準處理,實現自動彈性擴縮容,打造生產可用的Stable Diffusion服務。具體實現流程如下所示。
步驟一:部署Stable Diffusion服務
登錄容器服務管理控制臺,在左側導航欄選擇集群。
在集群列表頁面,單擊目標集群名稱,然后在左側導航欄,選擇 。
在Knative頁面的服務管理頁簽下,選擇命名空間為default,然后單擊使用模板創建,將以下YAML示例粘貼至模板,最后單擊創建,創建一個名為knative-sd-demo的服務。
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: knative-sd-demo annotations: serving.knative.dev.alibabacloud/affinity: "cookie" serving.knative.dev.alibabacloud/cookie-name: "sd" serving.knative.dev.alibabacloud/cookie-timeout: "1800" spec: template: metadata: annotations: autoscaling.knative.dev/class: mpa.autoscaling.knative.dev autoscaling.knative.dev/maxScale: '10' autoscaling.knative.dev/targetUtilizationPercentage: "100" k8s.aliyun.com/eci-use-specs: ecs.gn5-c4g1.xlarge,ecs.gn5i-c8g1.2xlarge,ecs.gn5-c8g1.2xlarge spec: containerConcurrency: 1 containers: - args: - --listen - --skip-torch-cuda-test - --api command: - python3 - launch.py image: yunqi-registry.cn-shanghai.cr.aliyuncs.com/lab/stable-diffusion@sha256:62b3228f4b02d9e89e221abe6f1731498a894b042925ab8d4326a571b3e992bc imagePullPolicy: IfNotPresent ports: - containerPort: 7860 name: http1 protocol: TCP name: stable-diffusion readinessProbe: tcpSocket: port: 7860 initialDelaySeconds: 5 periodSeconds: 1 failureThreshold: 3
如圖所示,表明knative-sd-demo服務已部署成功。
步驟二:訪問服務
在服務管理頁簽,獲取服務的訪問網關和默認域名。
將knative-sd-demo服務的網關地址與需要訪問的域名進行Host綁定,在Hosts文件中添加綁定信息。綁定示例如下:
47.xx.xxx.xx knative-sd-demo.default.example.com # 網關IP和域名請以您的實際數據為準。
完成Host綁定后,在服務管理頁簽,單擊knative-sd-demo服務的默認域名,訪問Stable Diffusion。
如圖所示,可通過域名直接對Stable Diffusion進行訪問。
步驟三:基于請求實現自動彈性擴縮容
使用Hey壓測工具,執行壓測。
說明Hey壓測工具的詳細介紹,請參見Hey。
# 發送50個請求,并發數為5,請求超時時間為180秒。 ./hey -n 50 -c 5 -t 180 -m POST -T "application/json" -d '{"prompt": "pretty dog"}' http://knative-sd-demo.default.example.com/sdapi/v1/txt2img
預期輸出:
Summary: Total: 252.1749 secs Slowest: 62.4155 secs Fastest: 9.9399 secs Average: 23.9748 secs Requests/sec: 0.1983 Response time histogram: 9.940 [1] |■■ 15.187 [17] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 20.435 [9] |■■■■■■■■■■■■■■■■■■■■■ 25.683 [11] |■■■■■■■■■■■■■■■■■■■■■■■■■■ 30.930 [1] |■■ 36.178 [1] |■■ 41.425 [3] |■■■■■■■ 46.673 [1] |■■ 51.920 [2] |■■■■■ 57.168 [1] |■■ 62.415 [3] |■■■■■■■ Latency distribution: 10% in 10.4695 secs 25% in 14.8245 secs 50% in 20.0772 secs 75% in 30.5207 secs 90% in 50.7006 secs 95% in 61.5010 secs 0% in 0.0000 secs Details (average, fastest, slowest): DNS+dialup: 0.0424 secs, 9.9399 secs, 62.4155 secs DNS-lookup: 0.0385 secs, 0.0000 secs, 0.3855 secs req write: 0.0000 secs, 0.0000 secs, 0.0004 secs resp wait: 23.8850 secs, 9.9089 secs, 62.3562 secs resp read: 0.0471 secs, 0.0166 secs, 0.1834 secs Status code distribution: [200] 50 responses
可以看到持續發送了50個請求,請求成功率為100%。
執行如下命令,可實時觀察Pod擴縮容情況。
watch -n 1 'kubectl get po'
由于部署Stable Diffusion服務時配置了單Pod的最大并發數是1 (
containerConcurrency: 1
),因此壓測期間自動擴容了5個Pod。
步驟四:查看Stable Diffusion服務監控數據
Knative提供開箱即用的可觀測能力,在Knative頁面,單擊監控大盤頁簽,即可查看Stable Diffusion服務的監控數據情況。如何開啟Knative監控大盤,請參見通過阿里云Prometheus監控查看Knative大盤。
在Overview (average over the selected time range)區域,可查看Stable Diffusion服務的請求量(Request Volume)、請求成功率(Success Rate)、4xx(客戶端錯誤)、5xx(服務器端錯誤)和Pod擴縮容趨勢的監控數據。
在Response Time區域,查看Knative的響應延遲數據,包括P50、P90、P95和P99。