关于云计算:让不确定性变得有弹性基于弹性容器的AI评测实践

4次阅读

共计 2377 个字符,预计需要花费 6 分钟才能阅读完成。

0. 前言

AI 的场景丰富多彩,AI 的评估办法百花齐放,这对于设计一套更通用的评测框架来说,是一个极大的挑战,须要兼顾不同的协定,不同的模型环境,甚至是不同的操作系统。本文分享了咱们在 AI 评测路上的一些实践经验,重点介绍了咱们在解决执行环境的不确定性方面所做的一些尝试。弹性容器是咱们以后最合适的解决方案,冀望对大家也有所启发。

1. AI 评测是什么?

在以后的 AI 产品研发中,须要常常答复相似这样的问题。比方哪一款智能音箱更好一些,哪一款引擎更加厉害,或者是哪一个机器学习算法更适宜我去用。

诸如此类,要答复这样的问题,咱们就须要有一个度量的尺子,这个尺子就是评测。咱们须要设计指标是什么,可能用什么数据出这些指标,每一类指标所体现进去的优缺点又是什么,怎么能力无效晋升指标,这就是评测所做的事件。

2. AI 评测怎么做?

AI 评测平台架构

以下是平台的一个整体架构,分为接入层、逻辑层、数据层和存储层。这个架构是一个纯云原生零碎,所有的服务部署以及所利用的一些存储资源全部都是基于云上边的。

3. 评测工作的不确定性

上面是评测工作的一个流程图,咱们有流水线、任务调度、有工作封装这样的重要环节。咱们发现要调度和执行的工作会有一个极大的挑战,那就是这些工作要反对到多种对象。每一种工作又是协同开发的一种形式,这就导致工作执行的一个环境是不确定的,还有就是工作在执行时所耗费的资源也是不确定的。

这里举一些不同场景的特点:

评测服务的多样性

比方咱们要去评服务,可能面临多种申请协定和返回的内容。

评测模型的复杂性

咱们要去评模型,会面临不同的深度学习框架,比方基于 tensorflow 的,基于 pytorch 的。

评测算法的多样性

咱们要评算法,可能又会面临不同格局的一些数据。

4. 工作执行架构的演进之路

那么怎么解决这些不确定性呢?咱们其实做了几种不同的尝试,接下来就跟大家分享一下咱们所做的几步尝试。

专门的工作运行服务

最开始的计划就是用一套专门的服务来反对所有的场景。所有性能和环境集成在一起,最显著的一个问题就是工作间耦合特地高,保护起来特地麻烦,很难做到共同开发,因为咱们评服务、评模型、评算法有可能是不同的团队或者不同的同学,如果把所有的服务都封装在一个服务外面,实际上在每一层之间都有一个特地大的影响,其实也会导致整个的复用性特地低。

独立且固定的容器服务

咱们又摸索了第二种计划,就是将一类的服务独立进去,在肯定水平上解决了服务的复杂性,然而复杂度还是较高,因为同一类服务里边,比方以模型评测为例,不同的模型的框架是不一样的,如果还是封装在同一个服务外面,实际上要兼容不同的框架在同一个服务里边也是一个特地简单的事件。

计划二有一个益处,各种服务性能绝对独立,然而还是有一个问题,同一类服务复杂度较高,另外服务是常驻的,不同业务即便是同一种类型的评测,它的频率是不一样的,甚至是相差特地大,那么就导致服务空载比拟多,资源利用率是不高的。

弹性的容器工作

EKS[1] 推出后,作为公司内首批吃螃蟹的业务,咱们真正面向客户的一个业务,开始进行了另一种计划的摸索,就是用弹性容器工作的形式进行一个评测工作。咱们的确感觉它是一个真香的,将所有的工作齐全隔离,而后当初的一个保护老本是非常低的,不必本人部署服务,也不必本人治理资源的事件。

对每一个评测工作的开发者也是一个很好的福利,开发者甚至能够随心所欲地去做一些事件,不必放心平台的框架不反对,另外也不必放心他所做的事件会影响到其余业务。当然对整个平台设计来说,最大的益处就是用完就开释,十分正当地利用资源。

几种解决方案的比照

以下是三个计划的一个比照,也是 EKS 带给咱们的一些收益。

在计划一的时候尽管能够对立保护,然而的确要实现一个服务要失去评测对象的各种依赖是十分难的,同时工作间的耦合也特地高,导致只能反对无限的场景。

计划二,尽管做到的肯定的隔离,工作间的耦合绝对也是比拟低的。然而每一个服务的忙闲状态是不一样的,咱们的资源空耗是特地多的,就像这个图所示,可能有的服务还是比拟法则,忙一段闲一段。有的服务就会始终忙,而后有的服务就特地零散地忙一下,而后就长期处于一个闲置的状态。

基于弹性的容器工作,能够做到工作能够随启随销,保护成本低,资源可能达到一个正当利用。

5. 评测工作的“弹性”

以下是基于 EKS 后的整体任务调度流程,咱们会把工作封装到一个镜像库,而后调度镜像部署到一个 EKS 仓库中进行执行,这个就是解决评测工作所面临的不确定性的问题。

EKS 评测工作的公布过程

这是一个更具像化的过程,工作的开发者只须要把开发代码提交到代码库,咱们会有一套规范流程将代码封装到镜像外面,在具体流水线调度的时候,会将这个镜像启动到 EKS 的调度中调度执行,这个执行后果会返回到开发者这边,他就能够及时地晓得这一次工作执行的一个成果是怎么样的。

6. 总结

EKS 的确在咱们反对不同的场景的评测工作时起到了十分大的一个助力,这样对于咱们拓展本人的评测场景起到了十分好的帮忙。

在之前,咱们要解决不同场景的评测,很多时候就须要靠咱们本人平台的开发者跟具体任务的开发者一直地适配,这次工作须要什么环境,我须要帮你筹备好,而后让我的工作可能给你提供一个比拟好的环境,也可能去执行。

自从有了 EKS 之后,咱们能够只关注平台架构的一个设计,工作外面须要依赖什么环境,须要什么包,齐全都交给工作的一个开发者去设计,而后咱们将他所须要的包、环境都打到一个镜像里边,各个工作的镜像又互相独立,而后我就能够很好地通过 EKS 调度执行,这样对整个平台的架构的一个可扩展性以及咱们本人能力的拓展都有了一个很好的助力。

参考资料

[1]EKS: https://cloud.tencent.com/pro…

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯,扫码关注同名公众号,及时获取更多干货!!

正文完
 0