Kubeflow KFServing 实现基于 KEDA 的 LLM 推理自动扩缩容方案

在当今大规模语言模型（LLM）应用场景中，高效的推理服务自动扩缩容能力至关重要。传统的基于请求级别的扩缩容指标（如 Knative 提供的）往往难以满足 LLM 推理的特殊需求，因为 LLM 推理是在 token 级别进行的，需要更精细的监控指标来指导扩缩容决策。

技术挑战与解决方案

LLM 推理服务具有独特的性能特征，传统的 HTTP 请求级别指标无法准确反映实际负载情况。主要面临以下挑战：

1. token 级别的处理特性：LLM 推理不是简单的请求-响应模式，而是涉及输入 token 处理和输出 token 流式生成
2. 复杂的性能指标：需要综合考虑首 token 延迟、输出 token 生成速度、总体延迟和吞吐量等指标
3. 能效考量：在大规模部署时，还需要考虑能耗指标以实现绿色计算

KFServing 团队提出的解决方案是原生集成 KEDA（Kubernetes Event-driven Autoscaling），通过 Prometheus 指标实现细粒度的自动扩缩容。这一方案具有以下技术优势：

核心监控指标体系

为实现有效的 LLM 推理扩缩容，需要建立以下关键性能指标：

1. 首 Token 时间（TTFT）：衡量用户等待第一个响应 token 的时间，直接影响交互体验
2. 输出 Token 时间（TPOT）：每个输出 token 的生成时间，决定用户感知的响应速度
3. 总体延迟：完整响应生成时间，计算公式为 TTFT + TPOT × 输出 token 数量
4. 吞吐量：系统每秒能够处理的总输出 token 数
5. 能耗指标：通过 Kepler 项目提供的容器级能耗数据

架构设计与实现

KFServing 通过两种部署模式支持 KEDA 集成：

1. Serverless 模式

利用 Knative 社区正在开发的 serving-keda 扩展，实现基于 KEDA 的 serverless 扩缩容。这种模式下，KFServing 可以：

• 动态调整副本数以响应 token 吞吐量变化
• 根据能耗指标实现能效优化的扩缩容
• 提供细粒度的性能与成本平衡

2. 原生部署模式

对于不使用 Knative 的原始部署，KFServing 控制器直接管理 KEDA 的 ScalerObject 资源。用户可以通过 InferenceService CRD 指定扩缩容查询指标：

apiVersion: "serving.kserve.io/v1beta1"
kind: "InferenceService"
spec:
  predictor:
    scaleQuery: "average_token_throughput_per_second[1m]"
    scaleMetric: custom
    maxReplicas: 10
    minReplicas: 1

对应的 KEDA ScaleObject 配置示例：

apiVersion: keda.sh/v1alpha1
kind: ScaleObject
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
  triggers:
    - type: prometheus
      metadata:
        metricName: average_token_per_second
        query: average_token_per_second[1m]
        threshold: "500"

技术价值与未来展望

这一集成方案为 LLM 推理服务带来了显著的改进：

1. 精准扩缩容：基于实际 token 处理能力而非简单请求数进行决策
2. 能效优化：结合 Kepler 的能耗数据，实现绿色计算
3. 灵活配置：支持用户自定义 Prometheus 查询和扩缩容阈值
4. 统一体验：在 serverless 和原生部署模式下提供一致的扩缩容能力

未来，该方案还可以进一步扩展支持动态批处理大小调整、多指标复合决策等高级功能，为生产环境的 LLM 服务提供更强大的自动扩缩容能力。

这一创新已被合并到 KFServing 0.15 版本中，为社区提供了开箱即用的 LLM 推理自动扩缩容解决方案。