Berkeley

2019年Berkeley预测Serverless将取代Serverful计算，成为云计算的计算新范式。Serverless为应用程序开发提供了一种全新的系统架构，其凭借着弹性伸缩省事省心，按需付费更低成本、聚焦业务降低OPS这三大核心价值，成为云计算中一股新生力量获得无数开发者的青睐。Serverless 将开发人员从繁重的手动资源管理和性能成本优化中解放出来，就像数十年前汇编语言演变到高级语言的过程一样，让工程师的生产力再次发生变革。

另一方面，得益于随着硬件技术的不断进步以及算法的不断优化，大模型人工智能技术在各行各业的应用中变得越来越火爆。大模型 AI 能够处理和分析更加庞大和复杂的数据，有效地提升了工作效率和决策能力。比如 AIGC（AI generated content ）在数字内容创作方面，已经可以自动生成新闻报道、科技资讯等文章，自动生成音乐、绘画作品等， 可以预见 AIGC 将成为数字内容创作的重要组成部分。

因此，随着AIGC等人工智能技术的逐步成熟和应用，云原生技术在面向 AI 场景的生产级解决方案中扮演着越来越重要的角色。传统的应用通常根据某些指标（比如根据 CPU，内存等硬件资源的使用情况，或者根据延迟，队列积压等业务指标）来扩展所需要的计算资源，然而在 AI 场景中请求和后端资源的调度比传统的微服务场景的要求会更高，这种差异主要来自于 AI 场景的请求对资源的消耗特别大。比如一个 Stable Diffusion 使用 A10 GPU 卡部署，一块 A10 卡(ecs.gn7i-c8g1.2xlarge) 启动 Stable Diffusion 服务一次只能处理个位数的文本绘图请求。一旦同时进来请求过多，就会出现超时的情况。而 AI 类型应用往往镜像特别大，并且应用的启动时间又很长。比如 Stable Diffusion GPU 镜像大小就有 15G，程序的启动时间就要 60s 以上。应用实例启动之后又只能小并发串行处理请求，所以需要非常精准的调度请求和实例数的匹配关系。并且在应用实例处理完请求以后最好不要立即释放实例，最好能复用实例，否则每次请求进来都重新创建一个实例，就会出现请求超时的情况。

一些 Serverless 产品解决方案，比如 阿里云 ASK(Serverless Kubernetes ) 或阿里云函数计算 FC，都支持资源的按需调度和使用，可以根据应用实际需要资源自动伸缩。在伸缩的过程中涉及到资源的分配，在分配资源的时候会有冷启动问题。另外应用代码的初始化也有冷启动的情况，应用端到端冷启动的时长， 短则是毫秒级，长则分钟级，如果每次实时调用都行进行初始化/销毁应用实例，调用的延时可能无法接受。所以 Serverless 框架会预热应用实例，且在调用结束后保留部分实例，闲置一段时间无调用后再释放，以降低冷启动的概率， 但更多空闲实例的存在，会增加资源成本。

下面分别对 Kubernetes 中 Pod 的启动过程和 FaaS 的函数冷启动过程进行解构，可以看看里面涉及到的具体过程：

• Kubernetes 中 Pod 启动过程

• FaaS 函数的启动过程

因此，Serverless 弹性需要做好资源成本与请求延迟 RT 的平衡就要尽量降低冷启动的概率，在 AI 场景下资源成本与请求延迟 RT 的平衡这个诉求更加的明显，因此我们需要一个 AI 场景的 Serverless 弹性链路优化的技术创新。

赛题描述

Serverless 计算服务让用户无需管理服务器等基础设施，更聚焦具体的业务代码，Serverless 框架层会准备好计算资源，并以弹性、可靠的方式运行用户代码。用户无需提前准备服务器资源， 按需付费，让使用者无需为闲置资源付费，其背后是服务采用各种调度策略、容量预估以及冷启动优化技术降低应用的响应时间，并且使用尽可能少的资源，要做到这一点就需要在调度、容量规划以及冷启动加速三个方面入手。

Serverless 场景需要有一个网关承接流量，请求到达网关后被转发到后端实例上。同时需要一个 Scaler 来控制后端实例数，使得实例数和请求对资源的诉求尽量匹配。可见 Scaler 是 Serverless 的核心组件，这个组件实现的智能程度直接决定了 Serverless 平台的成本控制水平。比如 Kubernetes 社区的 HPA 以及阿里云容器服务的 AHPA 都是典型的 Scaler 模块的实现方案。

AI 场景下的流量和应用实例的调度匹配

本赛题需要选手实现一个 Scaler 模块的功能。在实际生产环境中一个 Scaler 模块为了实现弹性伸缩的功能，需要解决很多工程问题，而具体的工程问题往往和实际的环境和技术栈相关。所以本赛题通过仿真框架屏蔽了这些因环境而异的繁琐工程细节，选手只聚焦在 Scaler 核心逻辑即可。

如下图所示，选手主要目标是实现 Scaler 模块的功能。在本赛题的设计中，Scaler 模块会需要提供两个接口的服务，并且仿真框架也会提供三个接口供 Scaler 调用。

选手需要实现一个遵循 gRPC 协议的 Scaler, Scaler 是一个 grpc 的服务， 需要实现对外的两个接口 Assign 和 Release，如下所示：

• Assign: 为请求分配一个应用实例，一个应用实例只能被分配给一个请求，如果无应用实例存在则需要冷启动，重新创建一个实例。无论是Kubernetes中Pod 还是 FaaS 函数，应用实例的启动过程都包括两个部分：实例的分配（CreateSlot）以及应用环境初始化（Init）。然后，实例才可以正常的处理请求。
  

• Release: 释放请求占用的应用实例，这个实例如果没有被回收， 可以被下次调用请求复用

  

实现上述接口过程中，需要调用仿真框架的三个接口：

• CreateSlot： 创建一个 Slot，一个 Slot 只能被分配至一个实例
• Init: Init 和 CreateSlot 是一对一出现的，init 是将 Slot 初始化为一个可以执行请求的实例。对于容器场景来说 init 包括拉镜像、启动容器、应用启动以及 ready 需要的时间。对于函数来说 init 包括代码包加载、程序启动等耗时
• DeleteSlot： 销毁一个 Slot

选手基于Scaler 进行二次开发，通过 ACR(阿里云容器镜像服务) 自动构建镜像，镜像部署至ASK(阿里云无服务器Kubernetes容器服务)做仿真验证。数据集内容是一条一条的请求描述，请求描述中包含目标 slot 的规格、以及请求执行时间等信息。验证框架会自动调用选手 Assign/Release 来为请求分配资源，执行结束后返回测试结果。

• Serverlsss 仿真框架和 Scaler 是一个应用， 部署到 ASK 中就是一个 Pod， 实例个数被限制为 1， 因此在一次评测任务期间， 选手可以基于实例的内存或者磁盘做状态缓存。
• Serverless Scaler 是一个需要细化完善的 grpc 的服务， 除了对外提供的 Assgin 和 Release 接口， 自身也需要有其他一些服务功能，比如定时逻辑实现对应用实例生命周期管理等。

免费产品领用

选手参赛过程中，需要使用ASK服务进行开发测试。选手参赛前可以先领取产品免费试用资源，避免产生额外计费。

容器服务 Serverless 版 ASK

ECI 8核16GB 7天

额度7天内有效

立即试用

函数计算 FC

150元额度 3个月

额度3个月内有效

不符合试用规则

解题思路

Assign过程，如果无实例可用，会产生冷启动，增加Assign延时，如果提前创建了Slot，可以减少本次冷启动延时，如果提前创建好了Instance，则可以避免冷启动，您可以设计算法来预先准备好实例或Slot，减少实时冷启动的时间；

Assign过程，如果触发了冷启动，等待冷启动完成时，如果有实例被Idle，立即使用新Idle的实例，而不去等待冷启动完成，可以减少Assign的延时；

Idle过程，如果保留函数实例不释放，下次调用可以reuse，但会增加Slot存活时间，您可以设计合理的算法，来达到性能和成本更好的平衡，比如不同的函数执行时间和频率均不一样，实例的释放时机可能有所差异。

基于以上思路，你可以设计算法来预先准备好实例或Slot，减少实时冷启动的时间。但是，提前准备实例或者复用已有的实例，可能会增加资源的使用时长。因此，需要你的调度框架（Scaler）达到请求的时延和资源使用量的最佳均衡。

在正式参与比赛之前， 您可以通过ASK 以及函数计算FC 来进行以下场景体验，感受Serverless 技术无需关注基础设施、弹性扩缩容、按量付费的魅力。

• 基于ASK部署在线魔方应用
• 基于函数计算一键部署Stable Diffusion【文生图】

评测方法

用户在天池平台提交 ACR 镜像，天池平台会自动将该镜像部署至 ASK 集群中：

• 部署到 ASK 中是一个 Pod， 实例个数被限制为 1， 因此在一次评测任务期间， 选手可以基于实例的内存或者磁盘做状态缓存。
• 正式评测时会替换数据集（新数据集与测试数据集同源），评测任务执行完毕后， 天池平台会给出评分。

冷启动加速作为附加项， 人工打分，权重值为 10%

评分标准

平台根据下面 3 个因素自动打分：

• 稳定性：Assign/Release 接口执行成功率 > 99.95% 为达标（接口本身执行错误，或返回的无效的 Slot、未 Init 初始化或者已经分配给其它请求的实例均为执行失败)，只有稳定性达标，后续性能相关统计才有效
• 资源使用占比（权重 50%）： “请求执行总消耗/Slot 总消耗” ，越高越好
• 冷启动时间占比（权重 50%）：“请求执行总时间/(调度总时间 + 请求执行总时间)”，越高越好

打分规则：

如果成功率低于99.95%，得分为0，反之最终得分为：

（请求执行总消耗/Slot 总消耗 + 请求执行总时间/(调度总消耗 + 请求执行总时间)）* 100/2

得分越高越好。

名词解释：

• GBs: 如果资源配置为 1GB, 使用时间 1s，则消耗 1GBs(GB秒)
• Slot: 未被初始化的实例。
• Slot 总消耗：用户调用 CreateSlot 与 DeleteSlot 之间时间为 Slot 占用时间，如果 Slot 配置为 1GB，分配了 100 个, Slot存活了10s， 则总消耗为 1000GBs
• 请求执行总消耗：每次请求执行前会调用 Assgin，执行完成后调用 Release，请求执行 1s，执行了 100 次，如果请求的资源配置 为1GB, 则总消耗为 100GBs
• 请求执行总时间：每次请求执行前会调用 Assgin，执行完成后调用 Release，请求执行 1s，执行了 100 次，则总时间为100s
• 调度总时间：每次请求 执行前会调用 Assign（可能包括冷启动时间），执行完成后调用 Release，调度总时间是所有Assign + Release的总耗时；

注意：

• 对排名靠前的代码进行 review，如果发现大量拷贝别人的代码，将酌情扣减名次
• 如果发现有作弊行为，比如 hack 评测程序，绕过了必须的评测逻辑，则程序无效，且取消参赛资格

附加题（可选）

附加题采用人工打分形式，选手自愿选择是否参与，优秀方案将有附加分。

冷启动优化主要考虑的优化方向是在 AI 场景下，大模型加载速度的优化。具体是对 Stable Diffusion 应用进行实例启动速度以及模型加载速度优化。

1.fork或者拷贝仓库 stable-diffusion 的代码到自己的仓库，阅读README了解开发环境配置及二次开发要求，并实现自己的优化逻辑。
2.对原始 stable-diffusion 工程和您优化后的工程的冷启动时间做一个对比，取5次平均值
3.将您的优化后的项目打包成一个 zip 包（包含您优化的背景和思路以及对比的 benchmark 值）发送到邮箱 ls147258@alibaba-inc.com dixing.chenjie@alibaba-inc.com qiulin.nql@alibaba-inc.com， 邮件主题统一为 "2023云原生编程挑战赛-Serverless冷启动优化"

注意：只有排行榜最终排名前10的选手才会将附加题分数加入总分的计算中。

参赛方法

1.在阿里天池找到"云原生编程挑战赛"，并报名参加。
2.fork或者拷贝仓库 Scaler 的代码到自己的仓库，阅读README了解开发环境配置及系统输入输出要求，并实现自己的优化逻辑， 通过 ACR 自动构建镜像。具体操作请参见：赛题任务提交说明
3.在天池提交成绩的入口，提交自己的 ACR 镜像 ，等待评测结果。