数禾使用 Knative 加速 AI 模型服务部署

摘要

AI 服务的数据、训练、推理等都需要消耗大量的计算资源以及运维成本，在数禾科技的金融业务场景下，模型存频繁迭代，线上也会同时部署多个版本的模型用于评估模型线上的真实效果，资源成本高。如何在保证服务质量基础之上提升 AI 服务运维效率并降低资源成本具有挑战性。

Knative 是一款基于 Kubernetes 之上的开源 Serverless 应用架构，提供基于请求的自动弹性、缩容到 0 以及灰度发布等功能。通过 Knative 部署 Serverless 应用可以做到专注于应用逻辑开发，资源按需使用。因此将 AI 服务与 Knative 技术相结合可以获得更高的效率并降低成本。

当前数禾科技通过 Knative 部署 500+AI 模型服务，资源成本节约比例 60%，平均部署周期由之前的 1 天缩短至 0.5 天。

在本次分享中，我们将向您展示如何基于 Knative 部署 AI 工作负载，具体内容包括：

• Knative 介绍
• 数禾基于 Knative 的最佳实践
• 如何在 Knative 部署 Stable Diffusion

Knative 介绍

众所周知 Kubernetes 自 2014 年开源以来，受到众多厂商和开发者的关注，作为一款开源容器化编排系统，用户使用 K8s 可以做到降低运维成本、提高运维效率，并且其提供标准化 API，某种意义就是避免被云厂商绑定，进而形成了以 K8s 为核心的云原生生态。据 CNCF 2021 调查，96% 的企业正在使用或评估 Kubernetes。

随着云原生技术的演进，以应用为中心，资源按需使用的 Serverless 技术逐渐成为主流。Gartner 预测，2025 年将有 50% 以上的全球企业部署 Serverless。

我们知道以 AWS Lambda 为代表的 FaaS 将 Serverless 带火了。FaaS 确实简化了编程，只需要编写一段代码就可以直接运行，不需要开发者关心底层基础设施。但是 FaaS 当前也存在的明显的不足，包括开发模式侵入性强、函数运行时长限制，跨云平台的支持等。

而以 K8s 为代表的容器技术，恰恰已经很好的解决了这些问题。Serverless 的核心理念是聚焦业务逻辑，减少基础设施的关注。

那么如何面向开发者提供基于 K8s 开放标准的 Serverless 容器技术？答案是：Knative。

Knative 发展轨迹

Knative 是在 2018 的 Google Cloud Next 大会上发布的一款基于 Kubernetes 的开源 Serverless 容器编排框架。目标就是制定云原生、跨平台的 Serverless 应用编排标准，打造企业级 Serverless 平台。阿里云容器服务也在最早 2019 的时候，已经提供 Knative 产品化能力，随着 2022 年 3 月加入到 CNCF，目前越拉越多的开发者拥抱 Knative。

Knative 概要介绍

Knative 核心模块主要包括部署工作负载的 Serving 和事件驱动框架 Eventing 。

Knative Serving 核心能力就是其简洁、高效的应用托管服务，这也是其支撑 Serverless 能力的基础。Knative 可以根据您应用的请求量在高峰时期自动扩容实例数，当请求量减少以后自动缩容实例数，可以非常自动化的帮助您节省成本。

Knative 的 Eventing 提供了完整的事件模型。事件接入以后通过 CloudEvent 标准在内部流转，结合 Broker/Trigger 机制给事件处理提供了非常理想的方式。

Knative 应用模型

Knative 应用模型是 Knative Service：

• Knative Service 中包含 2 部分配置，一部分用于配置工作负载，叫做 Configuration，每次 Configuration 内容更新都会创建一个新的 Revision。
• 另一部分 Route 主要负责 Knative 的流量管理。

我们看一下基于流量的灰度发布我们可以怎样做：

假设一开始我们创建了 V1 版本的 Revison，这时候如果有新的版本变更，那么我们只需要更新 Service 中的 Configuration，就会创建出 V2 版本，然后我们可以通过 Route 对 V1、V2 设置不同对流量比例，这里 v1 是 70%，v2 是 30%，那么流量就会分别按照 7:3 的比例分发到这两个版本上。一旦新到 V2 版本验证没有问题，那么我们接下来就可以通过调整比例继续灰度，直到新版本 V2 100%。在这个灰度到过程中，一旦发现新版本有异常，可以通过调整比例进行回滚操作。

除此以外，我们可以在 Route 到 Traffic 中对 Revison 打 Tag，打完 Tag 的 Revison，我们可以直接通过 Url 进行单独的版本测试，可以理解为金丝雀验证，对这个版本对调试不会影响正常对流量访问。

基于请求的自动弹性: KPA

为什么要做基于请求的自动弹性？