共计 4496 个字符，预计需要花费 12 分钟才能阅读完成。
最近开始关注 ADAS 这个行业，静下心来找各种材料学习，自然而然从行业的领头羊 Mobileye 动手。
Mobileye 是家以色列公司，1999 年由色列希伯来大学的 Amnon Shashua 传授和 Ziv Aviram 创建，以低成本摄像头为根底，通过计算机视觉技术研发高级驾驶辅助零碎（ADAS)。产品从研发到正式商用花了 8 年工夫，而在 2017 年被 Intel 以 153 亿美元收买。
在油管上搜到了 Mobileye 联结创始人 Amnon Shashua 在往年 CES2020 上的一个主题演讲视频：
在这一小时外面 Shashua 传授解说了 Mobileye 基于纯摄像头技术来做感知：
通过多套独立算法来做零碎外部冗余：
基于 2D 传感器帮忙零碎取得 3D 的理解力：
实现像素级场景宰割：
路线拥塞，行人横穿马路等简单的路况下，很好的解决了的无爱护左转场景:
而这所有只在一块小小的芯片上实现计算：
不由得感叹犹太人真聪慧，英特尔买这家公司可太有眼光了 …
另外也看到 Mobileye 不仅仅局限在 ADAS，从 L2+ 到 L4，布局出行服务 RobotTaxi。同时做高精度地图(REM)，基于此还延长至智慧城市：
这一小时的演讲信息量挺大的，须要一点点缓缓消化。就演讲前半部分讲到的感知，是基于深度学习来做的。Mobileye 具体是如何来进行深度学习的模型训练的，这点挺让人好奇的。刚好在油管还有另一个视频，是 Mobileye 的算法工程师小哥 Chaim Rand 在去年 AWS re:Invent 上做的一个公开分享：
re:Invent 是 AWS 每年一次技术大会，下面有很多 AWS 的用户会讲述他们应用 AWS 的教训（也包含踩过的坑）。比方在这个分享外面小哥介绍了他们如何利用 SageMaker 来帮忙他们减速算法开发和这个过程中如何填坑。
小哥后面循例先简要介绍了 Mobileye 是做什么的，而后开始讲到他们做深度学习模型训练时遇到的挑战：
能够看到 Mobileye 之前在本人的数据中心做模型训练，整个开发过程是从数据标注开始，而后用 GPU 集群进行模型训练，最初再把模型部署到他们本人专有的芯片 EyeQ 上。留神到比拟大的挑战是：一个典型的模型会须要多达 200TB 的数据来进行训练。
接着讲到在数据中心做模型训练存在的问题：
能够看到在本地数据中心进行训练有很多显著的劣势：包含 GPU 资源受到限制（嗯，算法工程师必定是越多越好啦），另外存储资源也会有限度（从后面提到的训练数据量来看，能够设想 Mobileye 的数据存储会有多大），同时基础架构软硬件的降级也十分挑战（原话是说让他们直掉头发，的确从视频看小哥也头秃了。。。）
在这个背景下，他们开始尝试在 AWS 云上应用 SageMaker 来做训练。这里他总结了几个他喜爱 SageMaker 的起因：
- 无限度的 GPU 资源，按小哥的原话说，对算法工程师这几乎就像是小孩到了糖果屋 … 他们能够同时跑更多的训练任务而不必排队，这也是 Mobileye 可能在 AWS 云上把开发速度进步 10 倍的次要起因。
- SageMaker 也能够应用反对不同实例类型，单 GPU 实例，或是多 GPU 实例，不同的 Tensorflow 版本等，满足他们不同模型训练任务的需要。
- 向云上迁徙的老本也比拟低，SageMaker 有比拟敌对的 API，文档，示例等，
- 平安是极其要害的一点，Mobileye 的数据安全团队也评估过在云上进行训练是满足他们的平安要求，毕竟 IP 是 Mobileye 要害的资产。
- 最初还特地提到了 SageMaker 的 Pipe Mode
留意到后面讲到 Mobileye 的典型模型训练须要多达 200TB 的数据，接下来他还开展具体解说了 Pipe Mode 如何帮忙来解决大数据集进行训练的问题
首先是简略介绍了 SageMaker Pipe Mode. 这个性能能够把训练所须要的数据从 S3 间接流式传输到训练实例，而不须要把数据集残缺地从 S3 全量复制到每一个训练实例的本地存储（EBS）上：
通过 Pipe Mode，训练的数据集大小就没有限度了，训练实例本地也不须要存储数据集，老本能够大大降低。同时训练任务能够立刻启动，不须要期待数据从 S3 复制到训练实例本地存储：
而且很重要一点是，多个训练实例能够同时从 S3 同一份训练数据集去拉取数据。看到这里我想起在一些模型训练平台上，常常会看到在 S3 后面部署一套高性能的分布式存储（如 AWS 本人的 FSx for Lustre, 或是开源的 BeeGFS 等），供训练实例并发去高速读取训练数据。应用 SageMaker Pipe Mode 应该就不须要部署这套高性能的分布式存储。
SageMaker 将 Pipe 的实现封装到了一个叫 tf.data.Datasets API 里，因而能够比拟不便的进行调用。小哥接下来还演示了如何设置 Pipe Mode 的代码（毕竟 400 系列的 session 没有代码说不过去 …)
但没有一种技术是万能的，Pipe Mode 也是一样。接下来这部分我感觉特地有价值，就是介绍 Mobileye 在应用 Pipe Mode 时遇到的挑战以及他们是如何克服的，这些挑战包含如何将数据转换为反对的格局，Pipe Mode 程序读取的个性以及 Pipe 数量的限度（目前限度是 20 个）。
首先是数据格式的挑战：Pipe Mode 反对 CSV, TFRecord 和 Protobuf recordIO . Mobileye 抉择了 TFRecord(次要是相干的示例代码较多），因而他们须要将已有的海量的数据转换成 TFRecord 格局。这个转换过程他们应用了 AWS Batch 服务来进行任务调度，并应用了数十万个 VCPU 来并行处理。在转换过程中，每个 TFRecord 文件为 100MB，这个也是 S3 读写带宽比拟优化的一个对象大小。因为在云上来进行并行的数据转换工作，整个数据筹备工夫失去极大的晋升，从以天计到以小时来计。
在讲到数据格式转换时，小哥也顺带介绍了 Mobileye 整个在云上的端到端的开发流程：
能够看到原始数据和标注文件寄存在 S3 下面，并通过 DynamoDB 来进行元数据的治理，接着通过 AWS Batch 来进行并发的数据格式转换，生成 TFRecord 文件并写回 S3。而后在 SageMaker 上进行模型的训练和评估，生成的模型会进行剪裁并运行部署脚本，以便运行在 Mobileye 自已的芯片 EyeQ 下面，这个部署脚本也是在 SageMaker 上运行的。
回到 Pipe Mode 的挑战上，除了数据格式，第二个问题是程序读的个性。应用 Pipe Mode 的话，只能读到 Pipe 里的下一个数据，而无奈对整个数据集任意进行拜访（随机拜访）：
这个程序读的个性带来了两个挑战。第一个挑战是 Shuffling，这有点像打牌的时候进行洗牌一样。传统形式下对数据集能够进行随机拜访，因而能够很不便进行 shuffling。应用 Pipe Mode 时，能够利用 ShuffleConfig Class 来对 pipe 进行 shuffle，这样确保在每个 epoch，训练数据的程序都是不一样的，同时他们还利用了 TensorFlow Dataset 的 shuffle 性能，在 training batch level 也进行 shuffle。只管这个计划并没有达到原来随机拜访时的 shuffle 水平，但也曾经足够应用了。
第二个挑战是 boosting. 这里举了个例子，比如说训练一个进行车辆辨认的模型，其余色彩的车辨认都很胜利，但针对粉色的车就始终无奈辨认。剖析起因发现是数据集中粉色车的数据非常少（可能百万张照片中只有 5 张）。其中一种解决方案是在每个 epoch 里减少粉色车的数据量(boosting)。如果能够随机拜访数据集的话，这个问题很好解决。但在 Pipe Mode 外面要如何来做呢？这里提到解决方案是创立两个 Pipe, 一个 Pipe 只有粉色车，另一个 Pipe 是其余色彩的车，而后应用 TF Dataset Interleaving API，从两个 Pipe 里取数据。这两个 Pipe 能够设置不同的权重(Weight)，这样便能够不便地减少粉色车的数据量了。
这种办法能够无效解决一种数据类型数据量不够的问题，但如果有多种数据类型呢？这里引出了 Mobileye 遇到的第三个挑战，就是每个 Training Session 里 Pipe 的数量限度。为什么他们会感觉 20 个 Pipe 还不够用？其中一个起因还是 boosting. 这里还是接着后面的例子辨认粉色车，进一步开展，比如说能够辨认粉色的小车，但无奈辨认粉色的卡车，无奈辨认雨中粉色的卡车等等，随着数据类型的减少，很快就到了 Pipe 的数量限度。第二个起因是 Horovod 做分布式训练时，每个 GPU 要求独占 Pipe。比如说一个 GPU 应用 3 个 Pipe，那在一个 8GPU 的实例上，就须要配置 8 *3=24 个 Pipe，这就超过了 Pipe 的数量限度了。
对于 boosting，他们应用了 SageMaker Manifest 文件。在 Manifest 文件外面定义数据集的分组。如果须要加一倍粉色车的数据量，则在 manifest 文件里多写一行就能够，这样通过 Manifest 文件就能够更精细化的管制训练数据了。对于分布式训练遇到 Pipe 数量限度的问题，他们比照了 TensorFlow 内建的多 GPU 反对和 Horovod 分布式训练框架，看到性能是根本一样的，因而没有选用 Horovod，而是应用 TensforFlow 内建的计划 Estimator，从则避开这个 Pipe 数量限度。
除了下面详细分析的 Pipe Mode，Mobileye 在从数据中心转到 SageMaker 时，还进行了其余的思考，包含分布式训练、Spot 实例的利用和近程 Debugging 等等，这些细节在另外一个 Blog 外面有具体的论述（可参见附录）
最初小结了一下 Mobileye 在应用 SageMaker 过程中的一些教训：
能够看到 SageMaker 对 Mobileye DNN 的开发起到了减速作用，其中的 Pipe Mode 能够比拟好的解决模型训练时应用到大数据集的问题。因为利用到云极高的扩展性和其余 AWS 托管服务的集成，Mobileye 整个开发工夫缩短了 10 倍。尽管在应用 SageMaker 的过程中也遇到了一些问题，但都能通过一些计划比拟好的解决掉。
另外在油管上还看到了 Mobileye 在 AWS 上进行大规模仿真和高精度地图生产的分享，后续值得好好钻研一下。
注：本文资料来自于公开渠道，并基于集体教训与常识进行剖析，仅代表个人观点
参考资料：
- Mobileye 在 CES2020 的演讲视频：
https://www.youtube.com/watch?v=HPWGFzqd7pI - Mobileye 在 AWS re:Invent 的分享视频：
https://www.youtube.com/watch?v=iW0RASdjnOk - Chaim Rand 对于 Mobileye 应用 SageMaker 的博客：
https://medium.com/@julsimon/making-amazon-sagemaker-and-tens…
本文最早发表在集体的微信公众号，对云技术感兴趣的敌人也能够关注我的微信公众号 (CloudBuilder) 与我交换
