通过机器学习获得空中优势：计算基础设施 | 远望译品

计算基础设施

本文摘自《通过机器学习获得空中优势》| 远望译品

任务规划问题空间的强大ML展示可能需要大量的处理能力和训练时间，从而限制了这些系统的实用性。本节讨论使用AFSIM的RL计算基础设施的作用。当前的深度RL方法需要大量计算，需要进行大量评估才能进行训练。例如，AlphaGo的非分发版本使用了48个CPU和8个图形处理单元（GPU）。分布式版本利用了1202个CPU和176个GPU。政策和价值网络需要数千万到数亿个训练步骤。同样，生成足够数量的训练数据需要大量的时间，并且可能需要大量的计算。此外，AlphaGo模拟是一个游戏板，运行时需要最少的计算资源。当前问题中更复杂的模拟增加了计算负担。

通过对整体方法的早期讨论，认识到了在人工智能系统中构建一套灵活的基础设施组件的机会。通过深思熟虑的系统设计，可能会有一种自然、经济的方式来扩展人工智能系统，以实现更复杂、时间密集或数据密集的实现。表4.1详细说明了计算基础设施设计中考虑的因素。

表4.1 影响计算基础设施的因素示例

因素	潜在考虑因素
算法的并行性	算法在多大程度上是可并行的？如果算法本质上是并行的，那么最少需要多少计算人员，他们的活动是如何协调的？
对大数据集的依赖	每次迭代，算法将使用多少数据？这些数据是本地数据还是外部数据？需要与其他组件或实体交换多少数据，交换频率是多少？
算法在实现方面的模块性和可移植性	是否可以在不需要更新整个系统的情况下更新和部署系统的各个组件？需要什么样的开发管道来支持不同的研究路径？部署新版本的方便程度？
算法复杂性	计算复杂度如何与问题规模成比例？计算平台在支持所研究问题方面的固有伸缩性如何？
组件间交互的方法	如果系统中的组件相互作用，需要支持哪些通信机制？在多大程度上使用了网络或基于网络的服务？是否有标准化的接口定义？
AFSIM和学习模块之间的耦合度	AFSIM和RL引擎的执行在多大程度上依赖于其他组件实现的技术细节？每个组件是否可以独立于其他组件进行演化并完成其工作？是否正在利用共享内存或共享数据存储？
信息保障和安全	保护信息需要哪些工具和辅助功能？现有的安全机制如何限制研究工作的发展？

为了扩展最终人工智能系统的计算需求，最初的重点是为AFSIM计算组件准备一个环境，可能作为一个计算系统集群。我们专注于入门点较低的私有云和公共云产品（在我们的研究环境中立即可用）。尽管与这项工作相关，但将AFSIM分发到云架构上的能力对于其他分析工作也非常有用。

我们的下一个任务是详细说明AFSIM将在其中执行的操作环境。AFSIM的资源需求随着问题空间的大小和运行次数的增加而增加。对于计算量更大的运行，在单个计算机节点或多个节点上启动多个AFSIM实例的方法需要额外开发，因为AFSIM目前不支持并行或分布式执行。AFSIM本身的执行非常简单，可以通过命令行执行。启动AFSIM仍然需要脚本；收集或分析结果；并使用新参数重新启动AFSIM，无论是按计划还是外部触发。在初始阶段，RL组件的应用程序级接口保持打开状态，因为ML的模型变得更加精确。

还考虑了平台无关的解决方案和AFSIM实例的管理，基于“容器”的方法似乎在我们的项目范围内有效地满足了这两个需求。基于容器的管理将（1）消除对在任何平台上维护一致操作环境的担忧，（2）“加速/减速”AFSIM计算实例，以及（3）可能启用基于集群的技术，如负载平衡。AFSIM本身在Windows和Linux版本中运行。对于机器“模板”，使用标准云管理和编排工具（如Chef、Puppet、Ansible、CloudFormation）进行部署也将更加简化。附录B详细说明了与AFSIM和规划代理的集装箱化部署相关的流程和挑战。

总之，基于高度便携的容器开发了一个用于ML和AFSIM执行的虚拟化概念验证环境。AFSIM 2.2模拟器、使用TensorFlow的ML引擎实现以及批处理执行框架的部分内容已在内部平台和外部Amazon Web Services GovCloud平台上的Docker容器中准备好，初步测试至少部分成功，尤其是在外部架构上。通过重用AFSIM容器和各种ML技术，集装箱化的使用支持更高效的研究实验和算法选择。在需要大规模计算资源的情况下，应该通过分析工作来探索这种方法。

计算基础设施挑战

       

标准的、预防性的环境控制和默认私有云平台的配置是开发基于容器的解决方案的最大障碍。以安全为导向的控制妨碍了集装箱化软件的安装和基础图像的形成。例如，Docker工具依赖公共注册中心提供标准的基本映像，并且需要与外部服务进行高度沟通，以便在本地生成新映像并更新Docker本身。

尽管私有云上的磁盘空间分配足以运行AFSIM实验，但它有效地限制了高效管理和开发改进解决方案所需的“工作”空间，这依赖于多个AFSIM实例。这限制了我们实现和测试基于容器的图像以及以分布式方式生成训练数据以加速测试的能力。虽然有多个虚拟机（VM）可用，但我们发现在帐户所有者的范围内共享磁盘空间，这会在更新代码或生成数据时引发潜在冲突。需要大量特定于平台的脚本来缓解此问题。此外，集装箱化工具安装在系统级的一个分区上，以防止我们以灵活的方式重新配置该工具以使用可用的磁盘空间；重新配置工具的尝试没有成功。将开发转移到公共亚马逊网络服务GovCloud平台解决了所有这些问题，标准工具增强了人工智能系统的管理。

互操作性、ML体系结构组件之间的数据通信以及第三方依赖性的包含也带来了技术障碍。尽管互操作性和接口定义是一个标准挑战，但ML体系结构长期设计中的不确定性为“稳定”的ML容器定义（AI系统的基本映像）提供了最佳途径。例如，最佳实践是为应用程序的每个组件形成多个容器，每个容器具有独立维护的小封装外形。这些组件之间的交互可以通过主机系统资源（如共享磁盘卷）或面向服务的设计模式进行协调。随着系统的发展，实际部署中使用的一个或多个基本映像可能需要与底层计算基础设施非常不同的支持。然而，我们的期望是，这些问题可以在当前选定的云平台内解决，并使用定义的容器准备方法。

考虑到这一点，重点转移到使用外部GovCloud平台。定义了一个运行Ubuntu 16.04的Amazon弹性计算云实例（EC2）。使用AFSIM 2.2制作了一个新的Docker图像，并将RL系统的二维实现捆绑在一起。在本例中，基础图像被扩展为包括Python 3、TensorFlow、NumPy和Pandas。如前几章所述，该AI系统将通过文件传递（在容器内）在运行之间交换数据，并且主机系统可以使用标准流程通过装入的卷访问结果。虽然该系统正在开发中，但已经建立了AFSIM和AI组合系统的基本设施。接下来的步骤包括全面执行AI系统进行分析，并使用更大的EC2实例模板在AI系统的多个实例上进行分布式ML实验。将当前的多应用程序映像重组为几个较小的映像，将使系统成熟为现实世界的应用程序所需的灵活性和自由度达到理想水平。