近日，由 Linux 基金会、云原生计算基金会 (CNCF) 主办的云原生顶级盛会 KubeCon+CloudNativeCon+Open Source Summit+China AI_dev 2024 成功举办，浪潮云海高级软件工程师王成龙受邀出席会议服务器与IP代理的区别，发表《通过功能化调度和 RDMA 加速无服务器 AI 大模型推理》主题演讲，以下为议题要点实录。

　　1 前言：今年是 Kubernetes 发展的十周年，在这十年里 Kubernetes 已经成为云原生的事实标准，根据云原生计算基金会 (CNCF) 调查报告，在 2023 年全球 84% 用户在生产中使用或计划使用 Kubernetes，这更加巩固了其在云原生的技术地位。

　　与此同时，以 ChatGPT 为代表的 AIGC 技术也在迅猛地发展，将人们对 AI 期待推向一个新的高峰。从 CNCF 发布的云原生 AI 白皮书中我们看到，人工智能已经形成上云趋势，越来越多的 AI 应用正在借助 Kubernetes 强大的容器编排能力来提高开发和部署效率，容器和 Serverless 技术将成为未来 AI 应用开发的主要平台。

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

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

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

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

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

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

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

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

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

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

　　因此 KServe 开发了 ModelMesh 技术，一个 Pod 可以加载多个模型，这些模型可以共享 GPU，由 Mesh 层来调度转发推理请求，Puller 负责模型拉取，提高资源利用率。

　　ML 推理系统越来越大、越来越复杂，它们通常由许多模型组成，才能做出单一预测。例如，人脸识别需要先在图像中定位人脸区域，然后计算人脸的特征以匹配数据库中的记录。所以 KServe 推理图允许用户将多个机器学习模型和处理步骤链接在一起，形成一个图形化的推理工作流。这种方法使得用户能够在单一的推理请求中组合多个模型的输出和处理逻辑，简化了复杂机器学习应用的部署和管理。

　　浪潮云海云操作系统 InCloud OS 是浪潮面向私有云领域，以可继承、可演进为理念自研的一套开放、稳定、高效、安全的云平台软件，提供云主机、容器、数据库、中间件、云安全等服务和智能运维、灵活运营等能力，助力政企数字化转型。

　　整体架构秉承可继承、可演进的理念，横向上各组件灵活选配，不强绑定; 纵向上各层次间分层解耦，开放融合。

　　AI 服务的生产流程涵盖了从数据准备、模型训练与微调，到模型推理服务上线的全周期管理，形成一个自我增强的闭环。在推理阶段生成的结果以及使用过程中收集的新数据，会回流至数据处理环节，持续推动模型的优化与迭代

　　浪潮云海推理模型的上云过程有如下步骤, 为了将导出的推理数据，也就是 checkpoint 存储到浪潮的分布式文件系统里, 以 PVC 的形式进行统一数据管理：

　　引入 Fluid (开源的 Kubernetes 原生的分布式数据集编排和加速引擎)，与 KServe 相结合，通过数据预热到分布式缓存加速模型加载流程，提升冷启动速度

　　自适应弹性伸缩：模型推理服务 Serverless 部署，基于请求数快速弹性伸缩，加快处理速度

　　通过 RDMA 高性能通信技术，加速模型推理中的高速 KV 缓存迁移，避免传统网络协议栈的高开销

　　为了解决上述问题，浪潮云海提出了函数化的控制平面设计。通过将控制平面解耦成可拓展的控制函数，根据请求负载动态地调整每个控制函数的实例数量，应对扩容请求的高并发和稀疏性特征。弹性 Serverless 控制平面的设计如图所示，浪潮云海设计了一个顶层控制平面用于协调和管理函数化控制平面，它会根据请求负载动态地区调整每个控制模块的实例数量，而函数化控制平面使用解耦出的各个控制函数去管理数据平面的各个函数实例。为了实现快速调度，浪潮云海进行了动态分区和探测两大设计。为了避免调度冲突，将节点拆分为多个分区，每个分区由单独的控制函数进行管理和调度，实现对于调度质量和调度速度的权衡。在分区资源不足时，控制函数会探测其他分区的可用资源并进行任务迁移，控制函数级的探测相比集中架构和节点级的探测开销显著降低，并且额外设计了探测缓存进行分区的预先过滤，可以进一步降低探测开销。总结：浪潮云海团队积极参与 CNCF 等开源社区活动，并持续为社区做出贡献。未来，浪潮云海将持续深入参与社区，聚焦资源调度、云原生 AI、Serverless 等方向，助力构建更为开放、智能的云原生基础设施，推动全球开源技术的落地与创新。

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