KServe项目中的推理服务启停控制机制解析

背景与需求场景

在私有云环境中，GPU资源往往十分紧缺。当用户创建KServe推理服务(InferenceService)后，可能会遇到以下典型场景：

• 服务暂时闲置时希望释放GPU资源供其他用户使用
• 需要完全停止服务以避免意外访问
• 后续使用时能够快速恢复而不必重新创建实例

这种精细化资源管控的需求促使KServe社区开始设计推理服务的启停控制机制。

技术方案设计

经过社区讨论，最终确定通过注解(Annotation)方式实现服务启停控制，核心设计要点包括：

1. 控制开关
   新增serving.kserve.io/stop注解，当值为true时停止服务，false或移除时恢复服务。

2. 多模式支持

   • Serverless模式：删除KSVC(Knative Service)及其相关资源
   • Raw模式：删除HPA(Horizontal Pod Autoscaler)及相关资源
   • 两种模式在恢复时都会重建被删除的资源

3. 状态管理
   服务停止后会更新状态字段，新增Stopped状态类型，其他状态字段会标记为reason: Stopped。

实现细节解析

Serverless模式处理

在Knative环境下，当前存在一个技术限制：当设置minReplicas/maxReplicas为0时，由于Knative将revision timeout赋值给Pod的TerminationGracePeriodSeconds，导致Pod终止过程较慢。社区正在等待Knative解决相关问题以优化停止速度。

Raw模式处理

相比Serverless模式，Raw模式需要KServe自行实现部署的删除和重建逻辑，这是方案中需要重点开发的部分。

状态同步机制

服务停止后会呈现以下典型状态：

status:
  conditions:
    - type: Stopped
      status: 'True'
    - type: Ready
      status: False
      reason: Stopped
  modelStatus:
    transitionStatus: 'Stopped'

这种设计既保持了API的兼容性，又能清晰反映服务状态。

技术价值与展望

该机制的实现将为KServe带来以下优势：

1. 资源利用率提升：实现GPU资源的动态回收与分配
2. 成本优化：避免闲置资源产生的费用
3. 运维便捷性：无需删除重建即可实现服务启停

未来可考虑与自动伸缩策略结合，实现基于负载预测的智能启停，进一步优化资源使用效率。同时，ModelMesh模式的完整支持也是后续开发的重点方向。

该功能体现了KServe在云原生机器学习服务领域的持续创新，为企业在资源受限环境下的模型服务部署提供了更灵活的解决方案。