目前深度学习应用广发， 其中 AI 推理的在线服务是其中一个重要的可落地的应用场景。本文将为大家介绍使用函数计算部署深度学习 AI 推理的最佳实践, 其中包括使用 FUN 工具一键部署安装第三方依赖、一键部署、本地调试以及压测评估， 全方位展现函数计算的开发敏捷特性、自动弹性伸缩能力、免运维和完善的监控设施。
通过上传一个猫或者狗的照片， 识别出这个照片里面的动物是猫还是狗
开通服务
免费开通函数计算， 按量付费，函数计算有很大的免费额度。
免费开通文件存储服务NAS， 按量付费
如上图所示， 当多个用户通过对外提供的 url 访问推理服务时候，每秒的请求几百上千都没有关系， 函数计算平台会自动伸缩， 提供足够的执行实例来响应用户的请求， 同时函数计算提供了完善的监控设施来监控您的函数运行情况。
| 自建服务 | 函数计算 Serverless | |
|---|---|---|
| 基础设施 | 需要用户采购和管理 | 无 |
| 开发效率 | 除了必要的业务逻辑开发,需要自己建立相同线上运行环境， 包括相关软件的安装、服务配置、安全更新等一系列问题 | 只需要专注业务逻辑的开发, 配合 FUN 工具一键资源编排和部署 |
| 学习上手成本 | 可能使用 K8S 或弹性伸缩( ESS )，需要了解更多的产品、名词和参数的意义 | 会编写对应的语言的函数代码即可 |
| 自建服务 | 函数计算 Serverless | |
|---|---|---|
| 弹性高可用 | 需要自建负载均衡 (SLB)，弹性伸缩，扩容缩容速度较 FC 慢 | FC系统固有毫秒级别弹性伸缩，快速实现底层扩容以应对峰值压力，免运维 |
| 监控报警查询 | ECS 级别的 metrics | 提供更细粒度的函数执行情况，每次访问函数执行的 latency 和日志等， 更加完善的报警监控机制 |
对于明显波峰波谷或者稀疏调用具有低成本优势， 同时还保持了弹性能力，以后业务规模做大以后并没有技术切换成本，同时财务成本增长配合预付费也能保持平滑。
假设有一个在线计算服务，由于是CPU 密集型计算， 因此在这里我们将平均 CPU 利用率作为核心参考指标对成本，以一个月为周期，10台 C5 ECS 的总计算力为例，总的计算量约为 30% 场景下， 各解决方案 CPU 资源利用率使用情况示意图大致如下:
由上图预估出如下计费模型：
| 平均CPU利用率 | 计算费用 | SLB | 总计 | |
|---|---|---|---|---|
| 函数计算组合付费 | >=80% | 738+X（246.27*3+X） | 无 | <= 738+X |
| 按峰值预留ECS | <=30% | 2190（10*219） | 526.52 | >=2716.52 |
| 弹性伸缩延迟敏感 | <=50% | 1314（102193/5） | 526.52 | >= 1840.52 |
| 弹性伸缩成本敏感 | <=70% | 938.57 (102193/7) | 526.52 | >= 1465.09 |
注：
这里假设函数逻辑没有公网公网下行流量费用， 即使有也是一致的， 这里成本比较暂不参与
延时敏感，当 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 密集型的主要优势：
FUN 操作简明视频教程
免费开通函数计算， 按量付费，函数计算有很大的免费额度。
免费开通文件存储服务NAS， 按量付费
git clone https://github.com/awesome-fc/cat-dog-classify.gitfun install -v, fun 会根据 Funfile 中定义的逻辑安装相关的依赖包
root@66fb3ad27a4c: ls .fun/nas/auto-default/classify
model python
root@66fb3ad27a4c: du -sm .fun
697 .fun根据 Funfile 的定义：
.fun/nas/auto-default/classify/python 目录下.fun/nas/auto-default/model 目录下安装完成后，从这里我们看出， 函数计算引用的代码包解压之后已经达到了 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可用的nasfun nas info: 可以查看本地 NAS 的目录位置, 对于此工程是 $(pwd)/.fun/nas/auto-default/classifyfun nas sync: 将本地 NAS 中的内容（.fun/nas/auto-default/classify）上传到 NAS 中的 classify 目录fun nas ls nas:///mnt/auto/: 查看我们是否已经正确将文件上传到了 NAS登录 NAS 控制台 https://nas.console.aliyun.com 和 VPC 控制台 https://vpc.console.aliyun.com<br />可以观察到在指定的 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 中完成这个部署工作:
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 是不可接受的。
有任何问题欢迎进扫码进钉钉群沟通
“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术圈。”
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
