[论文解读] Serverless inferencing on Kubernetes

Clive Cox, Dan Sun+4 more|arXiv (Cornell University)|Jul 14, 2020

Scientific Computing and Data Management参考文献 5被引用 7

一句话总结

本文提出了 KFServing，一个基于 Kubernetes 和 KNative 构建的无服务器机器学习推理框架，支持自动扩展、多框架兼容以及为数据科学家提供一致的模型部署体验。它展示了无服务器范式如何通过在低使用率时将模型扩展至零来降低基础设施成本，同时解决了生产工作负载中 GPU 自动扩展、延迟、批处理以及服务网格开销等挑战。

ABSTRACT

Organisations are increasingly putting machine learning models into production at scale. The increasing popularity of serverless scale-to-zero paradigms presents an opportunity for deploying machine learning models to help mitigate infrastructure costs when many models may not be in continuous use. We will discuss the KFServing project which builds on the KNative serverless paradigm to provide a serverless machine learning inference solution that allows a consistent and simple interface for data scientists to deploy their models. We will show how it solves the challenges of autoscaling GPU based inference and discuss some of the lessons learnt from using it in production.

研究动机与目标

• 解决大规模部署机器学习模型时，实现一致且低成本基础设施的日益增长的挑战。
• 使数据科学家能够通过统一接口在 TensorFlow、PyTorch 和 XGBoost 等多种机器学习框架中部署模型。
• 解决包括模型版本控制、金丝雀部署和影子部署以及实时监控在内的生产环境挑战。
• 通过无服务器自动扩展至零，在空闲时段显著降低基础设施成本，尤其适用于间歇性或周期性工作负载的模型。
• 通过优化 Kubernetes 环境中的批处理和资源利用率，提升基于 GPU 的推理可扩展性和效率。

提出的方法

• 利用 KNative 作为 Kubernetes 上的无服务器基础架构，实现事件驱动、可扩展至零的模型服务。
• 集成 sidecar 代理（queue-proxy）以收集飞行中请求的实时指标，用于自动扩展决策。
• 通过统一的 API 和抽象层支持多种机器学习框架，降低数据科学家的部署复杂度。
• 使用 Istio 服务网格实现流量管理、可观测性和模型推理服务之间的安全通信。
• 采用动态批处理推理请求，以最大化 GPU 利用率并降低每请求延迟。
• 通过 Kubernetes 原生机制和 Istio 流量拆分实现金丝雀和影子部署，确保安全的模型更新。

实验结果

研究问题

• RQ1 如何有效将无服务器原则应用于机器学习推理，以在生产环境中降低基础设施成本？
• RQ2 在 GPU 环境中，将大型模型（如 GPT-2）从零自动扩展时，性能与延迟之间存在何种权衡？
• RQ3 如何在多种机器学习框架之间实现一致的部署和监控接口，以支持多框架兼容？
• RQ4 在服务网格（Istio）环境中管理数百甚至数千个模型推理服务时，面临哪些操作挑战？
• RQ5 如何实现模型监控的自动化与可扩展性，以实时检测数据漂移、异常值和对抗性输入？

主要发现

• KFServing 通过统一 API 实现了对 TensorFlow、PyTorch、XGBoost 等框架的框架无关、一致的机器学习模型部署。
• 借助 KNative 和 Istio，实现了高效的自动扩展至零，显著降低了间歇性工作负载模型的空闲基础设施成本。
• GPU 自动扩展有效，但可能受 Linux CFS 调度器错误影响，导致 CPU 限流和尾部延迟增加，需进行仔细监控。
• 无服务器模型的初始请求延迟可能对低延迟工作负载构成障碍，尤其对于大型模型（5–30GB），因模型加载时间过长，限制了扩展至零的优势。
• 动态批处理可提升 GPU 吞吐量，但需根据流量模式进行调优；次优的批处理大小会导致响应延迟增加。
• 大规模服务网格部署（如数百至数千个模型）会增加内存和控制平面开销，尽管 Istio 1.5 将控制平面合并至 istiod，有助于降低管理复杂度。