背景
随着生成型AI技术的能力提升，越来越多的注意力放在了通过AI模型提升研发效率上。作为 AIGC （AI Gererative Content）领域的知名项目 Stable Diffusion , 可以帮助用户快速、准确地生成想要的场景及图片。不过当前使用 Stable Diffusion 面临如下问题：
-
单个Pod处理请求的吞吐率有限，如果多个请求转发到同一个Pod，会导致服务端过载异常，因此需要精准的控制单个Pod 请求并发处理数。
-
GPU资源很珍贵，期望做到按需使用资源，在业务低谷及时释放GPU资源
基于上面两个问题，我们提供 Knative 解决方案，可以做到基于并发请求数精准处理，自动弹性，打造生产可用的 Stable Diffusion 服务。
架构
这里我们在ACK/ASK中提供 Knative + MSE 方式解决上述问题：
-
通过 MSE 网关实现基于并发数精准转发
-
通过 Knative 实现基于请求的自动弹性
实践
部署服务
-
在 集群列表页面，单击目标集群进入集群信息页面，然后在左侧导航栏，选择 应用 > Knative。
-
在 Knative页面，单击 服务管理页签，然后单击 使用模板创建。
-
在 命名空间下拉列表中，选择 default，在 示例模板下拉列表中，选择 Knative Service，将以下YAML示例粘贴至模板，然后单击 创建。默认创建一个名为 knative-sd-demo的服务。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: knative-sd-demo
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-extra-ephemeral-storage: 50Gi
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:1c9c8fa97bc70901fc992679fd90ad622a6e54e484659766d5eab127207e9d32
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部署情况：
服务访问
在Hosts 绑定 47.96.XX.XX knative-sd-demo.default.example.com 之后，在浏览器输入域名 http://knative-sd-demo.default.example.com/直接访问SD服务
基于请求自动弹性
通过 hey 命令执行压测，其中并发设置5，发数50个请求，请求超时时间 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通过 watch 命令实时观察 Pod 扩缩容情况
watch -n 1 'kubectl get po'
./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效果：由于我们配置当前单Pod 最大并发数是1 （containerConcurrency: 1），因此压测期间，可以看到创建了 5 个Pod， 此外持续发送50个请求完成之后，可以看到请求成功率100%
可观测大盘
此外在 Knative 提供了开箱即用的可观测能力，在Knative页面，单击监控大盘页签。即可看到 Stable Diffusion 服务的请求量（Request Volume）、请求成功率（Success Rate）、4xx（客户端错误）、5xx（服务器端错误）和Pod扩缩容趋势的监控数据。
在Response Time区域，查看Knative的响应延迟数据，包括P50、P90、P95和P99。
小结
基于 Knative 请求精准处理以及自动弹性能力，完全可以提供Stable Diffusion生产可用的能力，满足在AIGC领域按需使用的 serverless 能力。
