KServe 集成 KEDA：基于 vLLM 指标自动扩缩容
内容提要
本文介绍如何为KServe模型服务接入KEDA，实现基于vLLM指标的自动扩缩容。通过安装KEDA和Prometheus，配置InferenceService和ServiceMonitor，利用vLLM暴露的请求指标，KEDA查询Prometheus数据并驱动HPA调整副本数。实测验证了服务从1个副本扩至2个再缩回1个的完整流程，有效平衡突发请求与资源利用率。
延伸解读
为什么选择 KEDA 而非原生 HPA
KServe 默认支持基于 CPU 或内存的 HPA，但这类指标无法直接反映推理服务的真实负载。vLLM 暴露的请求数指标（如 running 和 waiting）更能准确描述服务压力。KEDA 作为中间层，将 Prometheus 中的自定义指标转换为 HPA 可用的外部指标，从而让扩缩容决策更贴合模型服务的实际需求。
扩缩容配置的关键点
配置中 target.value 设为 1，表示每个副本期望处理 1 个请求（running + waiting）。查询语句统计所有副本的总请求数，HPA 根据总请求数除以当前副本数得到平均值，再与目标值比较。minReplicas 和 maxReplicas 限制了副本范围，避免无限扩容。缩容稳定窗口为 300 秒，防止频繁抖动。
验证流程中的注意事项
实测中，负载启动后指标值升至 12，HPA 显示目标为 6/1，说明平均每个副本 6 个请求，远超目标值，触发扩容至 2 个副本。扩容后服务仍能正常响应请求。停止负载后，指标回落到 0，但缩容并非立即发生，需等待约 300 秒稳定窗口，实际缩容时间还受 KEDA 轮询和 Pod 终止时间影响。
Q&A
KServe如何集成KEDA实现基于vLLM指标的自动扩缩容？
KServe通过配置InferenceService的annotations为serving.kserve.io/autoscalerClass: keda，并在spec.predictor.autoScaling.metrics中定义External类型的指标，指定Prometheus地址和查询语句，KEDA会创建ScaledObject和HPA，根据vLLM暴露的指标自动调整副本数。
在KServe中配置KEDA自动扩缩容时，如何设置Prometheus查询和扩缩容目标？
在InferenceService的spec.predictor.autoScaling.metrics中，设置type为External，external.metric.backend为prometheus，serverAddress为Prometheus服务地址，query为sum(vllm:num_requests_running{namespace="kserve-test",pod=~"qwen-llm-predictor-.*"}) + sum(vllm:num_requests_waiting{namespace="kserve-test",pod=~"qwen-llm-predictor-.*"})，target.type为Value，target.value为"1"，表示每个副本期望处理1个请求。
为什么需要安装Prometheus和KEDA？它们各自的作用是什么？
Prometheus用于采集vLLM暴露的指标（如vllm:num_requests_running和vllm:num_requests_waiting），KEDA则查询Prometheus并通过External Metrics API将指标暴露给HPA，HPA根据指标调整副本数。
如何验证KServe集成KEDA后的自动扩缩容效果？
通过发送持续负载（如使用curl并发请求），观察Prometheus查询值上升，ScaledObject变为ACTIVE=True，HPA目标值超过1，Deployment副本数从1扩到2；停止负载后，等待缩容稳定窗口（300秒），副本数缩回1。
在KServe中配置KEDA时，minReplicas和maxReplicas的作用是什么？
minReplicas和maxReplicas分别指定副本数的最小值和最大值，限制自动扩缩容的范围。在示例中，minReplicas为1，maxReplicas为2，确保服务至少1个副本，最多2个副本。
为什么需要配置ServiceMonitor？它如何选择要监控的Pod？
ServiceMonitor用于让Prometheus自动发现并采集KServe生成的Predictor Pod的指标。它通过namespaceSelector和selector匹配KServe生成的Service，Prometheus Operator会读取对应的EndpointSlice，将每个Pod作为独立Target进行采集。
在KServe集成KEDA的示例中，如何实现单GPU节点上运行两个副本？
通过使用HAMi DRA共享GPU，创建ResourceClaimTemplate为每个副本申请3Gi显存和20% GPU核心，这样单GPU节点可以同时运行两个副本。
