作者唐文，腾讯高级工程师，十年从业经验，在腾讯主导过海量数据处理和分析系统的设计和研发工作，参与过多个自动化测试框架和研发管理平台的研发，在后台框架设计、研发效能工具开发等方面有丰富的经验，近期专注于AI能力的评测方法研究以及相关系统的研发。
目录
- 前言
- AI评测是什么？
- AI评测怎么做？
- 评测任务的不确定性
- 任务执行架构的演进之路
- 评测任务的“弹性”
- 总结
0. 前言
AI的场景丰富多彩，AI的评价方法百花齐放，这对于设计一套更通用的评测框架来说，是一个极大的挑战，需要兼顾不同的协议，不同的模型环境，甚至是不同的操作系统。本文分享了我们在AI评测路上的一些实践经验，重点介绍了我们在解决执行环境的不确定性方面所做的一些尝试。弹性容器是我们当前最合适的解决方案，期望对大家也有所启发。
1. AI评测是什么？
在当前的AI产品研发中，需要经常回答类似这样的问题。比如哪一款智能音箱更好一些，哪一款引擎更加厉害，或者是哪一个机器学习算法更适合我去用。
诸如此类，要回答这样的问题，我们就需要有一个度量的尺子，这个尺子就是评测。我们需要设计指标是什么，能够用什么数据出这些指标，每一类指标所体现出来的优缺点又是什么，怎么才能有效提升指标，这就是评测所做的事情。
2. AI评测怎么做？
AI评测平台架构
以下是平台的一个整体架构，分为接入层、逻辑层、数据层和存储层。这个架构是一个纯云原生系统，所有的服务部署以及所应用的一些存储资源全部都是基于云上边的。
3. 评测任务的不确定性
下面是评测任务的一个流程图，我们有流水线、任务调度、有任务封装这样的重要环节。我们发现要调度和执行的任务会有一个极大的挑战，那就是这些任务要支持到多种对象。每一种任务又是协同开发的一种方式，这就导致任务执行的一个环境是不确定的，还有就是任务在执行时所消耗的资源也是不确定的。
这里举一些不同场景的特点:
评测服务的多样性
比如我们要去评服务，可能面临多种请求协议和返回的内容。
评测模型的复杂性
我们要去评模型，会面临不同的深度学习框架，比如基于tensorflow的，基于pytorch的。
评测算法的多样性
我们要评算法，可能又会面临不同格式的一些数据。
4. 任务执行架构的演进之路
那么怎么解决这些不确定性呢？我们其实做了几种不同的尝试，接下来就跟大家分享一下我们所做的几步尝试。
专门的任务运行服务
最开始的方案就是用一套专门的服务来支持所有的场景。所有功能和环境集成在一起，最明显的一个问题就是任务间耦合特别高，维护起来特别麻烦，很难做到共同开发，因为我们评服务、评模型、评算法有可能是不同的团队或者不同的同学，如果把所有的服务都封装在一个服务里面，实际上在每一层之间都有一个特别大的影响，其实也会导致整个的复用性特别低。
独立且固定的容器服务
我们又探索了第二种方案，就是将一类的服务独立出来，在一定程度上解决了服务的复杂性，但是复杂度还是较高，因为同一类服务里边，比如以模型评测为例，不同的模型的框架是不一样的，如果还是封装在同一个服务里面，实际上要兼容不同的框架在同一个服务里边也是一个特别复杂的事情。
方案二有一个好处，各种服务功能相对独立，但是还是有一个问题，同一类服务复杂度较高，另外服务是常驻的，不同业务即使是同一种类型的评测，它的频率是不一样的，甚至是相差特别大，那么就导致服务空载比较多，资源利用率是不高的。
弹性的容器任务
在EKS1推出后，作为公司内首批吃螃蟹的业务，我们真正面向客户的一个业务，开始进行了另一种方案的探索，就是用弹性容器任务的方式进行一个评测任务。我们确实感觉它是一个真香的，将所有的任务完全隔离，然后现在的一个维护成本是非常低的，不用自己部署服务，也不用自己管理资源的事情。
对每一个评测任务的开发者也是一个很好的福利，开发者甚至可以为所欲为地去做一些事情，不用担心平台的框架不支持，另外也不用担心他所做的事情会影响到其他业务。当然对整个平台设计来说，最大的好处就是用完就释放，非常合理地利用资源。
几种解决方案的对比
以下是三个方案的一个对比，也是EKS带给我们的一些收益。
在方案一的时候虽然可以统一维护，但是确实要实现一个服务要得到评测对象的各种依赖是非常难的，同时任务间的耦合也特别高，导致只能支持有限的场景。
方案二，虽然做到的一定的隔离，任务间的耦合相对也是比较低的。但是每一个服务的忙闲状态是不一样的，我们的资源空耗是特别多的，就像这个图所示，可能有的服务还是比较规律，忙一段闲一段。有的服务就会一直忙，然后有的服务就特别零散地忙一下，然后就长期处于一个闲置的状态。
基于弹性的容器任务，可以做到任务可以随启随销，维护成本低，资源能够达到一个合理利用。
5. 评测任务的“弹性”
以下是基于EKS后的整体任务调度流程，我们会把任务封装到一个镜像库，然后调度镜像部署到一个EKS仓库中进行执行，这个就是解决评测任务所面临的不确定性的问题。
EKS评测任务的发布过程
这是一个更具像化的过程，任务的开发者只需要把开发代码提交到代码库，我们会有一套标准流程将代码封装到镜像里面，在具体流水线调度的时候，会将这个镜像启动到EKS的调度中调度执行，这个执行结果会返回到开发者这边，他就可以及时地知道这一次任务执行的一个效果是怎么样的。
6. 总结
EKS确实在我们支持不同的场景的评测任务时起到了非常大的一个助力，这样对于我们拓展自己的评测场景起到了非常好的帮助。
在之前，我们要解决不同场景的评测，很多时候就需要靠我们自己平台的开发者跟具体任务的开发者不断地适配，这次任务需要什么环境，我需要帮你准备好，然后让我的任务能够给你提供一个比较好的环境，也能够去执行。
自从有了EKS之后，我们可以只关注平台架构的一个设计，任务里面需要依赖什么环境，需要什么包，完全都交给任务的一个开发者去设计，然后我们将他所需要的包、环境都打到一个镜像里边，各个任务的镜像又相互独立，然后我就可以很好地通过EKS调度执行，这样对整个平台的架构的一个可扩展性以及我们自己能力的拓展都有了一个很好的助力。
参考资料
1
EKS: https://cloud.tencent.com/product/eks
