近日,由Linux基金会、云原生计算基金会(CNCF)主办的云原生顶级盛会KubeCon+CloudNativeCon+Open Source Summit+China AI_dev 2024成功举办,浪潮云海高级软件工程师王成龙受邀出席会议,发表《通过功能化调度和RDMA加速无服务器AI大模型推理》主题演讲,以下为议题要点实录。
1前言:今年是Kubernetes发展的十周年,在这十年里Kubernetes已经成为云原生的事实标准,根据云原生计算基金会(CNCF)调查报告,在2023年全球84%用户在生产中使用或计划使用Kubernetes,这更加巩固了其在云原生的技术地位。
与此同时,以ChatGPT为代表的AIGC技术也在迅猛地发展,将人们对AI期待推向一个新的高峰。从CNCF发布的云原生AI白皮书中我们看到,人工智能已经形成上云趋势,越来越多的AI应用正在借助Kubernetes强大的容器编排能力来提高开发和部署效率,容器和 Serverless 技术将成为未来 AI 应用开发的主要平台。
2 KServe:简化模型管理,推动云原生AI应用落地
2.1 KServe架构解析
KServe作为Kubernetes上的模型推理平台,成为简化和加速机器学习模型部署、管理的重要工具。KServe最初是从 Kubeflow 项目中的 KFServing 演变而来的,从架构图中能够看出,它的底层是基于Kubernetes,对加速推理的设备进行统一管理;中间是Serverless层,依托于 Knative,支持 GPU 自动缩放、按需扩缩至零等功能;上层是支持的主流的机器学习框架、像PyTorch、Tensorflow。
总之KServe解决的就是把训练后的模型怎么快速上线提供服务的问题,简化AI模型的部署。
2.2 KServe——Serverless层
KServe 的 Serverless 层通过服务抽象、配置管理和流量路由实现了无服务器的 AI 模型推理。
Knative主要分为两部分:
1. 上半部分通过CRD自定义资源Configuration来管理Deployment的生命周期,每次修改Configuration都会生成一个Revision,Revision记录并对应着Deployment的一个版本,所以Knative基于这种机制来实现灰度发布的功能;
2. 下半部分通过CRD Route来定义流量的路由规则,将网络请求路由到特定的 Revision,从而实现流量切分功能。这使得不同版本的模型可以同时处理请求,进行平滑过渡和流量控制。
2.3 KServe——基于GPU的弹性伸缩
如何通过请求数来实现推理服务的冷启动和GPU自动弹性伸缩?
Knative提供两种访问模式:代理模式和直连模式。AI容器缩容到0后,当有推理请求时,这个时候为代理模式,请求先被送到Activator组件进行缓存,同时触发autoscaler进行快速扩容。扩容完成后,缓存的请求会被重新转发,并切换为直连模式,随后的流量就会直接请求到对应的Pod。这种动态切换模式设计,既能在没有请求时节省资源,又能在有请求时快速响应。
2.4 KServe——控制面
可以通过一个直观的例子来了解如何使用KServe快速部署AI推理服务:
第一步:创建InferenceService CR 资源,指定模型运行时和checkpoint存储路径
第二步:确定网关地址
第三步:进行推理请求
从架构图和示例中能够看出,KServe在Knative的基础上又进一步的抽象和封装,通过使用InferenceService这个CRD,KServe实现了对AI服务整个生命周期的管理。
2.5 KServe——数据面
每个 InferenceService 由多个组件组成:“预测器”、“解释器”和“转换器”:
预测器:系统的核心组件,负责实际的模型推理
- 解释器:提供模型解释功能,有助于调试和验证模型的行为,特别是在高风险或需要高透明度的应用场景中
- 转换器:用于对输入数据进行预处理,或对输出数据进行后处理。可以执行数据清洗、特征提取、格式转换等操作,以确保输入数据符合模型要求,或将输出结果转换为用户期望的格式
这些组件协同工作,确保数据平面能够高效、准确地执行推理任务。KServe另一个大的优点就是模型服务的调用协议更加标准化和统一化,使得跨系统的集成更加方便,从而提升了模型推理的兼容性和灵活性
2.6 KServe——高级特性
KServe原本的InferenceService是一个模型一个服务的模式,在部署大量模型的情况下,会面临计算资源限制(每个 Pod 中注入了 Sidecar,每个 InferenceService 额外增加 0.5核 CPU 和 0.5G 内存开销)、最大 Pod 限制(Kubernetes建议每个节点最多 110 个 Pod,假设每个 InferenceService 平均有 4 个 Pod,50 节点集群最多可以运行 1000 个模型)、最大IP地址限制(4096 个 IP 地址的集群最多可以部署 1024 个模型)
因此KServe开发了ModelMesh技术,一个Pod可以加载多个模型,这些模型可以共享GPU,由Mesh层来调度转发推理请求,Puller负责模型拉取,提高资源利用率。
ML 推理系统越来越大、越来越复杂,它们通常由许多模型组成,才能做出单一预测。例如,人脸识别需要先在图像中定位人脸区域,然后计算人脸的特征以匹配数据库中的记录。所以KServe推理图允许用户将多个机器学习模型和处理步骤链接在一起,形成一个图形化的推理工作流。这种方法使得用户能够在单一的推理请求中组合多个模型的输出和处理逻辑,简化了复杂机器学习应用的部署和管理。
3 浪潮云海基于 KServe 的实践方案:突破性能瓶颈,实现大规模推理高效运行
3.1 浪潮云海产品简介
浪潮云海云操作系统 InCloud OS 是浪潮面向私有云领域,以可继承、可演进为理念自研的一套开放、稳定、高效、安全的云平台软件,提供云主机、容器、数据库、中间件、云安全等服务和智能运维、灵活运营等能力,助力政企数字化转型。
整体架构秉承可继承、可演进的理念,横向上各组件灵活选配,不强绑定;纵向上各层次间分层解耦,开放融合。
3.2 AI 模型推理流程
AI 服务的生产流程涵盖了从数据准备、模型训练与微调,到模型推理服务上线的全周期管理,形成一个自我增强的闭环。在推理阶段生成的结果以及使用过程中收集的新数据,会回流至数据处理环节,持续推动模型的优化与迭代
3.3 浪潮云海AI模型推理服务上云
浪潮云海推理模型的上云过程有如下步骤, 为了将导出的推理数据,也就是checkpoint存储到浪潮的分布式文件系统里, 以PVC的形式进行统一数据管理:
① 创建持久卷声明 (PVC)
② 创建一个 Pod 来访问 PVC
③ 将模型存储在持久卷上
④ 自定义运行时:基于KServe API 实现自定义 REST ServingRuntime 模型
⑤ 部署新的推理服务
⑥ 执行推理请求
通过一系列步骤确保了模型可以顺利地在云端环境中运行,满足实际业务需求。
3.4 面临的挑战
在模型推理服务上云和使用的过程中,浪潮云海团队遇到了多个技术挑战。
挑战一:模型镜像大,拉取时间长,影响AI推理模型启动速度
浪潮云海的解决方案:
引入 Fluid(开源的Kubernetes原生的分布式数据集编排和加速引擎), 与 KServe 相结合,通过数据预热到分布式缓存加速模型加载流程,提升冷启动速度
通过数据复用,多个任务能够共享数据缓存,避免重复拉取同一份数据,减少网络消耗
挑战二:高并发场景下,推理存在延迟,影响服务的响应时间
浪潮云海的解决方案:
自适应批处理:将多个推理请求组合成单个批处理,从而优化吞吐量和延迟
- 自适应弹性伸缩:模型推理服务Serverless部署,基于请求数快速弹性伸缩,加快处理速度
挑战三:模型推理过程中传输的KV 缓存数据高达 GB 级别,通信开销高
浪潮云海的解决方案:
基于 SR-IOV 和容器多网卡技术,为容器提供 RDMA 和标准Kubernetes网络的双重能力
- 通过 RDMA 高性能通信技术,加速模型推理中的高速 KV 缓存迁移,避免传统网络协议栈的高开销
挑战四:现有Kubernetes的集中式控制平面无法及时应对大规模的突发请求
为了解决上述问题,浪潮云海提出了函数化的控制平面设计。通过将控制平面解耦成可拓展的控制函数,根据请求负载动态地调整每个控制函数的实例数量,应对扩容请求的高并发和稀疏性特征。
弹性Serverless控制平面的设计如图所示,浪潮云海设计了一个顶层控制平面用于协调和管理函数化控制平面,它会根据请求负载动态地区调整每个控制模块的实例数量,而函数化控制平面使用解耦出的各个控制函数去管理数据平面的各个函数实例。
为了实现快速调度,浪潮云海进行了动态分区和探测两大设计。为了避免调度冲突,将节点拆分为多个分区,每个分区由单独的控制函数进行管理和调度,实现对于调度质量和调度速度的权衡。在分区资源不足时,控制函数会探测其他分区的可用资源并进行任务迁移,控制函数级的探测相比集中架构和节点级的探测开销显著降低,并且额外设计了探测缓存进行分区的预先过滤,可以进一步降低探测开销。总结:浪潮云海团队积极参与CNCF等开源社区活动,并持续为社区做出贡献。未来,浪潮云海将持续深入参与社区,聚焦资源调度、云原生AI、Serverless等方向,助力构建更为开放、智能的云原生基础设施,推动全球开源技术的落地与创新。
