基于Kubernetes的大模型推理服务弹性伸缩方案

基于Kubernetes的大模型推理服务弹性伸缩方案踩坑记录

最近在为公司的大模型推理服务搭建弹性伸缩架构时，踩了不少坑，分享一下经验教训。

背景

我们使用Kubernetes部署了基于TensorFlow Serving的模型推理服务，需要根据请求量动态调整实例数量。

核心方案

采用Horizontal Pod Autoscaler (HPA) + 自定义指标监控的组合方案：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: model-serving-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: model-serving-deployment
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: requests_per_second
      target:
        type: AverageValue
        averageValue: "100"

遇到的问题

1. 指标采集延迟：默认的metrics-server延迟较高，导致伸缩不及时
2. 资源限制设置不合理：CPU和内存限制过低导致频繁OOM
3. 模型预热问题：新Pod启动后需要时间加载模型，影响响应时间

解决方案

1. 部署Prometheus + Prometheus Adapter替代metrics-server
2. 为Deployment添加资源请求和限制：

   resources:
     requests:
       cpu: "500m"
       memory: "1Gi"
     limits:
       cpu: "2000m"
       memory: "4Gi"
   

3. 在Deployment中添加启动探针：

   livenessProbe:
     httpGet:
       path: /v1/models
       port: 8501
     initialDelaySeconds: 60
   

复现步骤

1. 部署基础模型服务
2. 创建HPA配置并应用
3. 模拟高并发请求观察伸缩效果
4. 监控Pod状态和资源使用率

建议在生产环境部署前充分测试伸缩策略，避免因配置不当导致服务不稳定。