设置
  • 日夜间
    随系统
    浅色
    深色
  • 主题色

KubeCon 演讲实录|通过功能化调度和 RDMA 加速无服务器 AI 大模型推理

2024/9/30 18:04:01 来源:之家网站 作者:- 责编:-

近日,由 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 应用开发的主要平台。

2KServe:简化模型管理,推动云原生 AI 应用落地

2.1KServe 架构解析

KServe 作为 Kubernetes 上的模型推理平台,成为简化和加速机器学习模型部署、管理的重要工具。KServe 最初是从 Kubeflow 项目中的 KFServing 演变而来的,从架构图中能够看出,它的底层是基于 Kubernetes,对加速推理的设备进行统一管理; 中间是 Serverless 层,依托于 Knative,支持 GPU 自动缩放、按需扩缩至零等功能; 上层是支持的主流的机器学习框架、像 PyTorch、Tensorflow。

总之 KServe 解决的就是把训练后的模型怎么快速上线提供服务的问题,简化 AI 模型的部署。

2.2KServe——Serverless 层

KServe 的 Serverless 层通过服务抽象、配置管理和流量路由实现了无服务器的 AI 模型推理。

Knative 主要分为两部分:

1.上半部分通过 CRD 自定义资源 Configuration 来管理 Deployment 的生命周期,每次修改 Configuration 都会生成一个 Revision,Revision 记录并对应着 Deployment 的一个版本,所以 Knative 基于这种机制来实现灰度发布的功能;

2.下半部分通过 CRD Route 来定义流量的路由规则,将网络请求路由到特定的 Revision,从而实现流量切分功能。这使得不同版本的模型可以同时处理请求,进行平滑过渡和流量控制。

2.3KServe—— 基于 GPU 的弹性伸缩

如何通过请求数来实现推理服务的冷启动和 GPU 自动弹性伸缩?

Knative 提供两种访问模式:代理模式和直连模式。AI 容器缩容到 0 后,当有推理请求时,这个时候为代理模式,请求先被送到 Activator 组件进行缓存,同时触发 autoscaler 进行快速扩容。扩容完成后,缓存的请求会被重新转发,并切换为直连模式,随后的流量就会直接请求到对应的 Pod。这种动态切换模式设计,既能在没有请求时节省资源,又能在有请求时快速响应。

2.4KServe—— 控制面

可以通过一个直观的例子来了解如何使用 KServe 快速部署 AI 推理服务:

第一步:创建 InferenceService CR 资源,指定模型运行时和 checkpoint 存储路径

第二步:确定网关地址

第三步:进行推理请求

从架构图和示例中能够看出,KServe 在 Knative 的基础上又进一步的抽象和封装,通过使用 InferenceService 这个 CRD,KServe 实现了对 AI 服务整个生命周期的管理。

2.5KServe—— 数据面

每个 InferenceService 由多个组件组成:“预测器”、“解释器”和“转换器”:

预测器:系统的核心组件,负责实际的模型推理

解释器:提供模型解释功能,有助于调试和验证模型的行为,特别是在高风险或需要高透明度的应用场景中

转换器:用于对输入数据进行预处理,或对输出数据进行后处理。可以执行数据清洗、特征提取、格式转换等操作,以确保输入数据符合模型要求,或将输出结果转换为用户期望的格式

这些组件协同工作,确保数据平面能够高效、准确地执行推理任务。KServe 另一个大的优点就是模型服务的调用协议更加标准化和统一化,使得跨系统的集成更加方便,从而提升了模型推理的兼容性和灵活性

2.6KServe—— 高级特性

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.2AI 模型推理流程

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 等方向,助力构建更为开放、智能的云原生基础设施,推动全球开源技术的落地与创新。

广告声明:文内含有的对外跳转链接(包括不限于超链接、二维码、口令等形式),用于传递更多信息,节省甄选时间,结果仅供参考,IT之家所有文章均包含本声明。

相关文章

关键词:业界动态

软媒旗下网站: IT之家 最会买 - 返利返现优惠券 iPhone之家 Win7之家 Win10之家 Win11之家

软媒旗下软件: 软媒手机APP应用 魔方 最会买 要知