本文介绍了使用函数计算部署深度学习 AI 推理的最佳实践, 其中包括使用 FUN 工具一键部署安装第三方依赖、一键部署、本地调试以及压测评估, 全方位展现函数计算的开发敏捷特性、自动弹性伸缩能力、免运维和完善的监控设施。
通过上传一个猫或者狗的照片, 识别出这个照片里面的动物是猫还是狗
如上图所示, 当多个用户通过对外提供的 url 访问推理服务时候,每秒的请求几百上千都没有关系, 函数计算平台会自动伸缩, 提供足够的执行实例来响应用户的请求, 同时函数计算提供了完善的监控设施来监控您的函数运行情况。
对于明显波峰波谷或者稀疏调用具有低成本优势, 同时还保持了弹性能力,以后业务规模做大以后并没有技术切换成本,同时财务成本增长配合预付费也能保持平滑。
假设有一个在线计算服务,由于是CPU 密集型计算, 因此在这里我们将平均 CPU 利用率作为核心参考指标对成本,以一个月为周期,10台 C5 ECS 的总计算力为例,总的计算量约为 30% 场景下, 各解决方案 CPU 资源利用率使用情况示意图大致如下:
由上图预估出如下计费模型:
注: 这里假设函数逻辑没有公网公网下行流量费用, 即使有也是一致的, >这里成本比较暂不参与 延时敏感,当 CPU 利用率大于等于 50% 就需要开始进行扩容,不然>更来不及应对峰值 成本敏感,当 CPU 利用率大约 80% 即开始进行扩容, 能容受一定几>率的超时或者5XX
上表中, 其中函数计算组合付费中的 X 为按需付费的成本价,假设按需付费的计算量占整个计算量的10%,假设CPU 利用率为100%, 对应上表,那么需要3台ECS 的计算能力即可。因此FC按量付费的成本 X = 3 * 446.4 * 10% * 2 = 267.84 (FC 按量付费大约是按量ECS 的2倍),这个时候函数计算组合付费总计 1005.8元。 在这个模型预估里面,只要FC 按量付费占整个计算量小于 20%, 即使不考虑SLB, 单纯考虑计算成本, 都是有一定优势的。
基于函数计算进行 AI 推理等CPU密集型的主要优势:
root@66fb3ad27a4c: ls .fun/nas/auto-default/classify
model python
root@66fb3ad27a4c: du -sm .fun
697 .fun
根据 Funfile 的定义:
安装完成后,从这里我们看出, 函数计算引用的代码包解压之后已经达到了 670 M, 远超过 50M 代码包限制, 解决方案是 NAS 详情可以参考: 挂载NAS访问,幸运的是 FUN 工具一键解决了 NAS 的配置和文件上传问题。
fun nas init
fun nas info
fun nas sync
fun nas ls nas://classify:/mnt/auto/
依次执行这些命令,就将本地中的 .fun/nas/auto-default 中的第三方代码包和模型文件传到 nas 中, 依次看下这几个命令的做了什么事情: • fun nas init: 初始化nas, 基于您的 .env 中的信息获取(已有满足条件的nas)或创建一个同region可用的nas • fun nas info: 可以查看本地 nas 的目录位置, 对于此工程是 $(pwd)/.fun/nas/auto-default/classify • fun nas sync: 将本地nas中的内容(.fun/nas/auto-default/classify)上传到 nas 中的 classify 目录 • fun nas ls nas://classify:/mnt/auto/: 查看我们是否已经正确将文件上传到了 NAS 登录 NAS 控制台 https://nas.console.aliyun.com 和 VPC 控制台 https://vpc.console.aliyun.com 可以观察到在指定的region 上有NAS 和 相应的 vpc 创建成功
在 template.yml 中, 指定了这个函数是 http 类型的函数, 所以根据 fun 的提示:
Tips for next step
======================
* Invoke Event Function: fun local invoke
* Invoke Http Function: fun local start
* Build Http Function: fun build
* Deploy Resources: fun deploy
执行 fun local start, 本地就会启动一个http server 来模拟函数的执行, 然后我们client 端可以使用 postman, curl 或者浏览器, 比如对于本例:
本地调试OK 后,我们接下来将函数部署到云平台:
修改 template.yml LogConfig 中的 Project, 任意取一个不会重复的名字即可, 然后执行
fun deploy
注意: template.yml 注释的部分为自定义域名的配置, 如果想在 fun deploy 中完成这个部署工作: • 先去域名解析, 比如在示例中, 将域名 sz.mofangdegisn.cn 解析到 123456.cn-hangzhou.fc.aliyuncs.com, 对应的域名、accountId 和 region 修改成自己的 • 去掉 template.yml 中的注释, 修改成自己的域名 • 执行 fun deploy
这个时候如果没有自定义域名, 直接通过浏览器访问访问http trigger 的url, 比如 https://123456.cn-shenzhen.fc.aliyuncs.com/2016-08-15/proxy/classify/cat-dog/ 会被强制下载, 原因:https://help.aliyun.com/knowledge_detail/56103.html#HTTP-Trigger-compulsory-header
登录控制台https://fc.console.aliyun.com,可以看到service 和 函数已经创建成功, 并且 service 也已经正确配置。
在这里,我们发现第一次打开页面访问函数的时候,执行环境实例冷启动时间非常长, 如果是一个在线AI推理服务,对响应时间非常敏感,冷启动引起的毛刺对于这种类型的服务是不可接受的,接下来,本文讲解如何利用函数计算的预留模式来消除冷启动带来的负面影响。
函数计算具有动态伸缩的特性, 根据并发请求量,自动弹性扩容出执行环境来执行环境,在这个典型的深度学习示例中,import keras 消耗的时间很长 , 在我们设置的 1 G 规格的函数中, 并发访问的时候耗时10s左右, 有时甚至20s+
start = time.time()
from keras.models import model_from_json
print("import keras time = ", time.time()-start)
一次压测结果
从上面图中我们可以看出,当函数执行的请求到来时,优先被调度到预留的实例中被执行, 这个时候是没有冷启动的,所以请求是没有毛刺的, 后面随着测试的压力不断增大(峰值TPS 达到 1184), 预留的实例不能满足调用函数的请求, 这个时候函数计算就自动进行按需扩容实例供函数执行,此时的调用就有冷启动的过程, 从上面我们可以看出,函数的最大 latency 时间甚至达到了 32s,如果这个web AP是延时敏感的,这个 latency 是不可接受的。
领取专属 10元无门槛券
私享最新 技术干货