关于amazon-sagemaker:从软件哲学角度谈-Amazon-SageMaker

如果你喜爱哲学并且你是一个 IT 从业者，那么你很可能对软件哲学感兴趣，你能发现存在于软件畛域的哲学之美。本文咱们就从软件哲学的角度来理解一下亚马逊云科技的拳头级产品 Amazon SageMaker，有两个出发点：一是 SageMaker 自身设计所遵循的软件哲学；二是从软件哲学的角度咱们应该如何应用 SageMaker 提供的性能。SageMaker 是一个全托管的机器学习平台（包含传统机器学习和深度学习），它笼罩了整个机器学习的生命周期，如下图所示：

咱们从如下的几个方面来展开讨论：

• 天下没有收费的午餐——衡量之道
• 简略之美——大道至简
• 没有规矩不成方圆——安分守己
• 没有“银弹”——隔靴搔痒
• 变动之本——进化实质
• 知其所以然——成竹在胸
• 放弃一致性——品质可控

天下没有收费的午餐——衡量之道

软件有很多的品质（品质也叫非功能性需要）：性能（比方工夫性能，空间性能，模型性能），可用性，易用性，可扩展性，兼容性，可移植性，灵活性，安全性，可维护性，老本等。一个软件没有方法满足所有的品质，因而咱们在和用户交换的过程中，要真的弄清楚用户想要的是什么（没有设想中那么简略），哪个或者哪些软件的品质是用户以后最关怀的。很多软件品质常常会互相制约（一个经典的例子就是安全性和工夫性能，平安这个品质就是一个让人又爱又恨的货色，一般来说须要退出安全性的时候，在其余上下文不变的状况下，基本上工夫性能就会变差了），所以咱们须要衡量，而在衡量的时候肯定要把握好“度“。

对于 SageMaker 来说：

• SageMaker Processing job 要求数据的输出和输入都须要在 S3，基本原理图如下：

SageMaker Processing job 提供了托管的单个实例或者集群来做数据预处理，特色工程以及模型评估。如果你的原始数据并没有寄存在 S3，这个时候你须要 衡量空间性能与可托管性（可托管性的益处是很多运维的工作就不须要你关怀了，交给了亚马逊云科技来运维），是把数据从源拷贝到 S3 来应用托管的 Processing job 服务还是就地来用自建的集群来解决；如果你的原始数据自身就寄存在 S3，那么间接用 Processing job 来应用 SkLearn 或者 SparkML 来进行数据预处理或者特色工程是你的首选。

• SageMaker 的内建算法对数据输出格局的要求以及可配置的无限的超参数。SageMaker 提供的内建算法（SageMaker 对常见的 ML 工作根本都提供了一种或者多种算法）对数据输出格局的要求以及提供的超参数可能与开源界的算法的数据输出格局和提供的超参数略有区别。这里你须要衡量易用性与灵活性：如果你只是想实现一个 ML 的工作并且不想关注算法的实现细节，那么能够优先尝试 SageMaker 的内建算法；如果你想更深刻理解算法的实现细节以及更灵便的超参数设置，那么倡议的抉择是把你的算法或者开源的算法迁徙到 SageMaker 中。
• SageMaker 训练时的 HPO 主动超参数优化性能的应用。主动超参数优化的初衷是为了加重算法工程师 / 数据科学家 / 利用科学家们手工调参的苦楚。SageMaker 的 HPO 主动超参数优化对于内建算法和非内建算法都反对，并提供了贝叶斯搜寻和随机搜寻两种形式供你抉择。不是所有的算法都须要走主动超参数调优，须要 衡量模型性能（就是指模型成果）与老本。一般来说，对于深度学习模型或者海量数据集的状况下可能做主动超参数调优的工夫代价和老本代价太大。因而在理论的 ML 我的项目中，用户很少对深度学习模型或者海量数据集做主动超参数调优；对于传统的机器学习模型并且在数据集不大的状况下，能够思考用主动超参数调优来找到可能的最优解。
• SageMaker 内建的 inference pipeline 的数据流。SageMaker Inference pipeline 能够把多个容器（容器中能够跑特色解决逻辑或者跑模型 serving 逻辑）串接起来，它的目标是把推理时的特色解决模块和模型串接起来，或者把多个模型做成上下游串接起来。它的数据流是这样的：

也就是说，每个容器的输入由 SageMaker 外部组件做直达，该组件把上一个容器的输入做为新的 request 发送到下一个容器。通过应用 Inference pipeline 这个性能能够简略不便的实现模型的上下游串接或者特色解决模块和模型的串接，但从下面的数据流能够看到会带入一些提早，这个时候你须要思考提早是否在能够承受的范畴内并应用 Inference pipeline，也就是须要 衡量易用性与工夫性能。

• SageMaker 中对于 Tensorflow 和 Pytorch 两种框架都提供了多种训练形式。训练形式包含开源框架原生的形式以及 SageMaker 专门实现的针对这两种框架的数据并行和模型并行两种形式。SageMaker 的数据并行训练形式适宜每个 GPU 卡能够跑残缺的模型训练然而数据集是海量的状况；SageMaker 的模型并行训练形式适宜单个 GPU 卡无奈间接跑模型训练的状况（比方模型太大了）。也就是说，在海量数据集大规模训练或者超大模型训练的场景，应用 SageMaker 的这两种专有的训练形式比框架原生的训练形式会更高效，然而应用 SageMaker 的数据并行和模型并行的训练形式的话，对于框架的版本有要求并且须要肯定的代码批改，因而须要你衡量代码的可移植性与工夫性能。

简略之美——大道至简

“简略”可能的含意有很多，比方精简，俭朴，可读性好等。“简略”的度量规范可能每个人的了解都不一样，然而一个通用的准则是，“您”在设计软件的时候尽量多想着：“软件须要他人来用，还须要他人来迭代和保护”，您肯定要高抬贵手。“简略”的对立面就是“简单”，业界的共识是通过升高复杂度来失去高质量长生命期的软件，而如何升高复杂度是每个软件设计人员以及开发人员无时无刻须要关注的事件。

在 SageMaker 中的体现：

• SageMaker 是基于 container 的设计，到目前为止没有抉择 Kubernetes。在以后业界大兴 Kubernetes 的状况下，SageMaker 并没有随大流。Kubernetes 的性能很弱小然而很简单，对于 SageMaker 来说，很多 Kubernetes 的性能用不上，那么为了缩小软件依赖以及升高复杂度，SageMaker 抉择了更轻量的设计（杀鸡真的没有必要用牛刀）。
• SageMaker high level API（high level API 指的是 SageMaker Python SDK，这个 API 的应用习惯相似常见的 ML 框架比方 SKLearn）设计很简洁，类档次也很清晰（分层就是一种升高复杂度的办法），很多 feature 通过简略的参数设置就能搞定。比方通过简略的设置 distribution 参数就把底层简单的分布式环境部署暗藏掉了（信息暗藏也是升高复杂度的一种办法），让 API 调用者的关注点更集中在训练脚本自身；比方简略的设置模型的 S3 保留地位，SageMaker 就会帮忙你在训练完结或者训练中断时把对应目录下的模型压缩打包并上传到 S3 指定门路；比方通过设置 git_config 参数，你就能够间接用 github 中的代码在 SageMake 中来训练，而不须要你关怀代码的拉取过程。
• SageMaker 提供了多种算法抉择：内建算法，BYOS（基于预置的机器学习框架来自定义算法），BYOC（自定义算法设计并本人来打包容器镜像）和第三方利用市场（在 Amazon Marketplace 中筛选第三方算法包，间接在 Amazon SageMaker 中应用）。而 BYOS 和 BYOC 是 SageMaker 中理论用的最多的两种抉择。那如何抉择 BYOS 和 BYOC？总的来说，优先看 BYOS 是否能满足需要。BYOS 绝对于 BYOC 要容易，须要迁徙到 SageMaker 的工作量也少。而抉择 BYOC，常见的是如下的情景：

除了下面这些情景，尽量优先思考 BYOS 的形式，它应用形式简略，学习曲线也绝对平缓。

• SageMaker 提供了两个可用于超参数的变量 sagemaker_program 和 sagemaker_submit_directory 来帮忙你轻松的实现 BYOC 的调试。前者告知 SageMaker 把这个参数的值作为 user entry point（就是用户提供的须要 SageMaker 调用的脚本），后者则是这个 entry_point 对应的代码以及它所依赖的代码打包（tar.gz）后的 S3 门路。通过设置这两个参数，在调试代码的时候只是须要把批改后的代码从新打包上传就能够，而不是每次都 build docker file，简略不便而且很节省时间。

没有规矩不成方圆——安分守己

领有丰盛教训的你可能听过或者践行过契约式编程，而契约式编程简略说就是，你须要依照对方的一些约定来 coding。一般来说，只有是提供给他人应用的软件 / 工具，或多或少都会有一些约定。SageMaker 从 尽量减少代码侵入性和最小代码迁徙工作量 的思路登程，提供了很多约定。

在 SageMaker 中的体现：

训练时，数据 Channel 相干的约定：

• 训练容器本地门路相干的约定，如下图所示：

咱们重点关注下表中的四种门路（除了上面这些门路，训练过程中搁置在其余门路下的文件，在训练完结后都会被抛弃）：

SageMaker 给容器提供了很多方便使用的环境变量，包含 SageMaker 相干的和内建框架相干的。比方 SageMaker 相干的一部分环境变量如下：

SageMaker 内建的 TF serving 框架的 service side batch 相干的环境变量如下：

• SageMaker 内建算法对输出数据格式的要求。SageMaker 内建算法对输出数据的格局要求可能和开源算法对数据格式的要求不同，如果不留神这个，在调试模型的时候可能会呈现比拟奇怪的后果。比方 SageMaker 指标检测算法对 BBOX 的格局要求如下：对于 json 格局的输出标注文件，要求的坐标格局是 [top, left, width, height]，如果你的数据集的标注是 PASCAL VOC 格局的（xmin，ymin，xmax，ymax）或者是 COCO 格局的（x，y，width，height），都须要做不同的转换；对于 recordIO 格局的输出文件，要求坐标格局是绝对坐标，[xmin/width，ymin/height，xmax/width，ymax/height]。
• Spot 实例与 SageMaker checkpoint 机制的配合。为了节省成本，应用 spot 实例进行训练是首选。为了让 spot 实例被回收对你的训练任务造成的影响最小化，SageMaker 通过两个参数 checkpoint_local_path 和 checkpoint_s3_uri 来助你一臂之力（当然你不应用 spot 实例，也依然能够利用 SageMaker 的 checkpoint 机制）。这样训练 job 被 spot 回收中断当前并主动从新开始训练后，就不必从头开始训练了，而是从最新的 checkpoint 开始接着训练（SageMaker 提供了 checkpoint 上传和下载的机制，你须要批改你的代码来配合，也就是你须要从约定的 checkpoint local 门路来初始化你的模型参数，否则是空谈），从而在节省成本的同时节俭训练工夫。

没有“银弹”——隔靴搔痒

可能咱们本人脑海中或者遇到过他人问咱们如下的问题：对于 XX 工作以后哪个模型成果最好？应用 AutoML 是不是就不须要咱们做特色工程和样本工程了？主动超参调优是不是就彻底解放咱们的手动超参调优了？如果真的是这样的话，那就太美妙了。在软件界，“没有银弹”这句话风行很久了，对于人工智能畛域也是同样情理，都须要 case by case 来剖析每一个指标工作。

当初 Bert 以及 bert-like 的模型比方 GPT3，T5 等很火，巴不得只有是 NLP 的工作都用这样的模型。我感觉还是应该至多要思考具体的指标工作是什么，指标工作的建模难度这两个因素来进行模型选型。如果在语料短缺的状况下，做一个简略的文本分类工作，这个时候可能用一个简略的模型比方 fasttext 来就够用了，而不必 bert 模型做 fine tuning 这么简单；如果是针对用户评论做细粒度情感剖析工作，这个工作就很简单了，用简略模型就可能不适合了，这个时候用比方 T5 这样的简单模型才适合。自觉的追新和追热点，受伤的是你的我的项目（可能你能从中受害）。

对于 SageMaker 来说：

• SageMaker 有内建算法，BYOS，BYOC 和 Marketplace 以及新出的 JumpStart 下面的算法可供你抉择，总有一款适宜你。很有意思的一个景象是，SageMaker 在刚公布的时候 bulid 了 17 种内建算法，很多年过后始终也没有在减少新的内建算法。我猜想 SageMaker 的开发团队会认为，即便一直的减少一些内建算法，也没有方法及时对支流的一些算法进行跟进。正是因为针对任何一种细分场景，没有包治百病的“算法”，SageMaker 就不在内建算法上破费更多的工夫和精力，它提供更灵便的 BYOS 和 BYOC 让用户把开源的算法不便的迁徙过去，或者通过 Marketplace 让买家和卖家都能尝到应用算法的苦头。
• SageMaker 提供了 Autopilot 和 Auto model tuning（即主动超参数调优）这样两种 AutoML 机制。AutoML 始终是一个很热门的钻研方向，也是咱们人类很期待的一个能大量落地的方向（谁不喜爱简略省事就能实现一项工作呢？）。如果每个指标工作都能够用 AutoML 来解决的很好，那么大部分人都能够腾出工夫来攻克别的技术难题了。尽管 Autopilot 能够间接对结构化数据来建模，它也能主动做一些特色解决，然而它并不是银弹，不是什么数据集间接丢给它就能出一个不错的成果的；要应用 Autopilot，本人提前做一些特色工程可能成果会更好（比方特色缩放，特色生成，特色穿插，甚至不同的缺失值解决办法，异样值解决等）。

而对于主动超参数调优，如果应用默认的超参数搜寻空间，工夫老本和金钱老本太大，那么还是须要人工首先限定每个须要搜寻的超参数的区间的左右端点，同样这里没有“银弹”，左右端点的确定要么依据已有的教训，要么就是通过试验来大抵选取。肯定不要无条件的应用 Autopilot 或者主动超参数调优来解决你的问题，三思而后行！

变动之本——进化实质

为什么要思考“变动”？设计之初就应该思考到未来的可能变动，也就是说零碎框架要设计的比拟有弹性（就像亚马逊云科技的很多服务那样弹），对于未来的需要的改变不会付出很高代价。在软件设计中，常常谈判到“面向变动编程”，即永远不要假如需要不变，事实中需要大大小小常常变。变动是翻新的必经之路 ， 永恒不变的货色只有变动。

在 SageMaker 中的体现：

• SageMaker 晚期的版本提供了 SageMaker-container 包供你应用来创立 SageMaker 兼容的容器和自定义的框架。前期的版本，为了让基于 SageMaker-container 包的容器镜像尽量更小更内聚，SageMaker 把这个 SageMaker-container 包拆分为 sagemaker-training toolkit（专为训练的容器）和 sagemaker inference toolkit（专为推理 /serving 的容器）两个包来瘦身。
• 随着一直的进化，SageMaker 当初是一个齐全自洽的全生命周期的机器学习平台。在晚期的时候，SageMaker 只有三大外围性能：训练，推理（离线推理和线上推理），notebook 实例。为了能把 ML 生命周期中的数据预处理，特色工程，模型评估这些性能也纳入，SageMaker 后续推出了 Processing job 来做这些事件。而随着很多用户对于多种机器学习工作的高质量标注需要的回升，SageMaker 推出了带有人工标注和机器主动标注的 Ground Truth 性能（这里又体现了客户至上的企业文化）。而随着 SageMaker Studio（它是用于机器学习的集成式开发环境 IDE，可让你构建、训练、调试、部署和监控机器学习模型）的推出，以及 MLOps 的更多功能的退出，当初的 SageMaker 变成了“超人”（短时间能减少如此多的性能并且还放弃强壮，正是因为 SageMaker 的设计基因就是面向变动的）。

知其所以然——做到成竹在胸

咱们可能知其然，然而所以然晓得了吗？可能有些感兴趣的货色咱们会去理解其深层的起因，然而软件的问题咱们去钻研了吗？软件是干燥的，很多时候咱们都是作为谋生的伎俩来应酬之，因而不知所以然也就很失常了。然而如果您是要真正的学习货色，或者更好的服务于用户，最好还是”再深一点“。

对于 SageMaker 来说：

• SageMaker 相干的代码比拟扩散，为了满足好奇心能够去浏览源码。比方有 SageMaker 平台相干的开源代码包 sagemaker-container，sagemaker-training，sagemaker-inference；与内建框架相干的开源的代码比方 SageMaker tensorflow training，SageMaker tensorflow serving；SageMaker Python SDK 的开源实现代码。通过浏览这些代码，你会对 SageMaker 如何工作有更粗浅的了解。
• 当训练文件的数量比拟多的时候，SageMaker Pipe mode 和 File mode 哪种形式训练 更快呢？拿 Tensorflow 的 tfrecorddataset API 来举例，在其余的 dataset API 根本一样的前提下，File mode 更快（这个在多个理论用户我的项目中测试过）。次要的区别就是 pipemodedataset API 和 tfrecorddataset API。tfrecorddataset API 能够设置 num_parallel_reads 来并行读取多个文件的数据，还能够设置 buffer_size 来优化数据读取。Pipemodedataset API 则没有相似下面的参数来减速数据的读取。也就是说 Pipe mode 更适宜读取文件数量不多，然而每个文件都很大的场景（除了这里提到的 Pipe mode 和 File mode，SageMaker 训练的数据读取形式还提供了 FastFile mode；SageMaker 训练反对的数据源除了 S3，还包含 Amazon Elastic File System 以及 Amazon FSX for Lustre，具体内容能够参考官网博客）。
• SageMaker Endpoint for TFS vs for Mxnet/Pytorch 的内建 serving 框架复杂性比照. SageMaker Endpoint for TFS 的介绍如下：

SageMaker Endpoint for Pytorch serving 的介绍如下（SageMaker Endpoint for Mxnet serving 是相似的）：只应用一个组件 torchserve，它的特点是，间接反对钩子函数；反对解决 /ping REST API；缺省会应用所有的 GPU 来做推理（而单个 TFS 过程只应用一个 GPU 来推理）。

放弃一致性——品质可控

一致性是升高零碎复杂度无利的伎俩。如果一个零碎保持一致，意味着相似的事件用相似的办法去做，升高了认知负荷。在 ML 机器学习畛域，咱们常常谈判到一致性，比方成果线上线下一致性（如果模型离线成果好，模型上线当前体现不好，这就是产生了成果线上线下不统一），特色的线上线下一致性（特色的线上线下不统一是成果线上线下不统一的一个常见起因；特色的线上线下不统一指的是线下训练时样本中的特色的特征值可能会发生变化，并不和该样本在线上生成时的特征值齐全一样。对于特色的线上线下一致性更具体的探讨请参考我的另一个文章）。放弃一致性是模型品质可控的一个重要因素。

对于 SageMaker 来说：

• 应用 SageMaker Processing job 对训练集做的一些特色工程比方某个特色 Z-score 标准化，那么为了让预测时与训练时有统一的特色工程，须要如何解决呢？在对训练集做了某个特色的 Z-score 标准化当前，用到的该特色的均值和方差这些 metadata 须要保存起来（SparkML 和 Sklearn 都有相应的 API 把这些 metadata 以文件的模式保存起来）；而后利用 SageMaker Inference pipeline 在第一个容器中把之前保留的 metadata 文件加载进来对原始特色进行 Z-score 标准化解决之后再送入第二个容器即模型推理容器。
• 如果在模型 serving 的时候，能及时晓得每个特色的散布是否和训练时的数据集尤其是验证集的散布是否基本一致，对于模型才更可控。而 SageMaker 的 model monitor 的一个重要性能就是监控特色的统计漂移，如果模型在生产过程中接管到的数据的统计性质偏离了训练所根据的基准数据的性质，则模型将开始失去其预测的准确性。Model Monitor 应用规定检测数据漂移，并配合 Amazon 其余服务在产生数据漂移时向您收回警报。下图阐明了此流程的工作形式：

总结

本文从软件哲学角度来介绍了 SageMaker 的一些设计思维以及如何应用 SageMaker 的一些性能。总体来讲，不论你是否思考采纳 SageMaker 作为你的机器学习平台，至多它的这些实现的思路以及设计哲学都是能够用来参考的。SageMaker 作为寰球使用量最大的机器学习平台，是值得你花工夫来好好钻研和摸索以及实际的。对于 SageMaker 更多具体和更多深刻的内容请参考我的 github。感激大家的急躁浏览。

本篇作者

梁宇辉

亚马逊云科技机器学习产品技术专家，负责基于亚马逊云科技的机器学习计划的征询与设计，专一于机器学习的推广与利用，深度参加了很多实在客户的机器学习我的项目的构建以及优化。对于深度学习模型分布式训练，举荐零碎和计算广告等畛域具备丰盛教训。

文章起源：https://dev.amazoncloud.cn/column/article/63098fa80c9a20404da…