最近开始关注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)与我交换