摘抄自：《深度学习之Pytorch物体检测实战》一书

勾勒一幅图

原文地址：Approaching (Almost) Any Machine Learning Problem 
 原文翻译与校对：@姜范波 && @黄文畅 && 寒小阳 
 时间：2016年10月。 
 出处：http://blog.csdn.net/han_xiaoyang/article/details/52910022 
 声明：版权所有，转载请联系作者并注明出
 
前言
 
 
 
本文由Searchmetrics公司高级数据科学家Abhishek Thakur提供。
 
 
一个中等水平的数据科学家每天都要处理大量的数据。一些人说超过60%到70%的时间都用于数据清理、数据处理及格式转化，以便于在之后应用机器学习模型。这篇文章的重点便在后者—— 应用机器学习模型（包括预处理的阶段）。此文讨论到的内容来源于我参加的过的数百次的机器学习竞赛。请大家注意这里讨论的方法是大体上适用的，当然还有很多被专业人士使用的非常复杂的方法。
 
接下来会使用到python。
 
数据
 
在应用机器学习模型之前，所有的数据都必须转换为表格形式。如下图所示，这个过程是最耗时、最困难的部分。
 
 
转换完成之后，便可以将这些表格数据灌入机器学习模型。表格数据是在机器学习或是数据挖掘中最常见的数据表示形式。我们有一个数据表，x轴是样本数据，y轴是标签。标签可以是单列可以是多列，取决于问题的形式。我们会用X表示数据，y表示标签。
 
标签的种类
 
标签会定义你要解决何种问题，有不同的问题类型。例如：
 
单列，二进制值（分类问题，一个样本仅属于一个类，并且只有两个类）
单列，实数值（回归问题，只预测一个值）
多列，二进制值（分类问题，一个样本属于一个类，但有两个以上的类）
多列，实数值（回归问题，多个值的预测）
多个标签（分类问题，一个样本可以属于几个类）
 
评估指标
 
对于任何类型的机器学习问题，我们都一定要知道如何评估结果，或者说评估指标和目的是什么。举例来说，对于不均衡的二进制分类问题，我们通常选择受试者工作特征曲线下面积（ROC AUC或简单的AUC）；对于多标签或多类别的分类问题，我们通常选择分类交叉熵或多类对数损失；对于回归问题，则会选择均方差。
 
我不会再深入的讲解不同的评估指标，因为根据问题的不同会有很多不同的种类。
 
库
 
开始尝试机器学习库可以从安装最基础也是最重要的开始，像numpy和scipy。
 
查看和执行数据操作：pandas（http://pandas.pydata.org/）
对于各种机器学习模型：scikit-learn（http://scikit-learn.org/stable/）
最好的gradient boosting库：xgboost（https://github.com/dmlc/xgboost）
对于神经网络：keras（http://keras.io/）
数据绘图：matplotlib（http://matplotlib.org/）
监视进度：tqdm（https://pypi.python.org/pypi/tqdm）
 
Anaconda操作简单而且帮你准备好了这些，可是我没有使用，因为我习惯自己配置和自由使用。当然，决策在你手中。
 
机器学习总体框架
 
2015起，我开始制作一个自动机器学习框架，还在完善过程中，很快就会发布。下图所示的框架图就是这篇文章中将会提到的基础框架：
 

 
 
 
  

 
图片来源：A. Thakur and A. Krohn-Grimberghe, AutoCompete: A Framework for Machine Learning Competitions, AutoML Workshop, International Conference on Machine Learning 2015 
 
 
上面的框架图中，粉色的线代表最常用的路径。结束提取数据并将其转化为表格形式，我们就可以开始建造机器学习模型了。
 
第一步是识别（区分）问题。这个可以通过观察标签解决。你一定要知道这个问题是二元分类，还是多种类或多标签分类，还是一个回归问题。当识别了问题之后，就可以把数据分成训练集和测验集两个部分。如下图所示。 
 
 
 
 
  
 
 

 
将数据分成训练集和验证集“必须”根据标签进行。遇到分类问题，使用分层分割就对了。在Python中，用scikit-learn很容易就做到了。 
 
 
 
 
  
 
 

 
遇到回归问题，一个简单的K-Fold分割就可以了。当然，也还有很多复杂的方法能够在维持训练集和验证集原有分布的同时将数据分割开来。这个就留给读者们自己去练习啦。 
 
 
 
 
  
 
 

 
相关阅读: Startup Lessons: This Is Why You Need To Move Quickly
 
在以上的例子中我选择用全数据的10%作为验证集，当然你可以根据手中具体的数据决定取样的大小。 
 分好数据之后，就可以把它放在一边不要碰了。任何作用于训练集的运算都必须被保存并应用于验证集。验证集无论如何都不可以和训练集混为一谈。因为混到一起之后虽然回到一个让用户满意的评估指标值，但却会因为模型过拟合而不能使用。 
 下一步是识别数据中不同的变量。通常有三种变量：数值变量、分类变量和文本变量。让我们用很受欢迎的关于泰坦尼克号的数据集来举个例子。 
 (https://www.kaggle.com/c/titanic/data).
 

 
 
 
  
 
 

 
在这里，“survival”（生存）就是标签。在前一个步骤中我们已经把标签从训练集中去掉了。接下来，有pclass，sex, embarked变量这些变量由不同的级别，因此是分类变量。像age, sibsp, parch等就是数值变量。Name是一个含有文本的变量，但我不认为它对预测是否生存有用。
 
先把数值变量分离出来。这些变量不需要任何形式的处理，所以我们可以开始对其归一并应用机器学习模型。
 
处理分类变量有两种变法：
 
把分类变量转化为标签 
 
   
   
 
    
   
 
  
把标签转化为二进制变量 
 
   
   
 
    
   
 
  
 
请记住在应用OneHotEncoder之前要用LabelEncoder把分类变量转化为数值变量。
 
既然泰坦尼克数据里面没有好的关于文本变量的例子，我们就自己制定一个处理文本变量的一般规则。我们可以把所有文本变量整合在一起然后用一些文本分析的算法把他们转换成数字。
 
文本变量可以如下这样整合： 
 
 
然后就可以应用CoutVectorizer或者TfidfVectorizer在上面啦： 
 
 
或者
 
 
TfidfVectorizer大多数时候比单纯计数效果要好。下面的参数设置在大多数时候都有很好的结果。
 
 
如果你在训练集上做了向量化处理（或者其他操作），请确保将其（相应的处理）转存在硬盘上，以便以后在验证集上应用。
 
 
接下来，就是堆叠器模块。堆叠器模块不是模型堆叠而是特征堆叠。上述处理步骤之后得到的不同特征可以通过堆叠器模块整合到一起。 
 
 
 
 
  
 
 
 
 
你可以水平地堆叠所有的特征，然后通过使用numpy hstack或sparse hvstack进行进一步处理，具体取决于是否具有密集或稀疏特征。 
 
 
 
 
  
 
 

 
也可以通过FeatureUnion模块实现，以防万一有其他处理步骤，如PCA或特征选择（我们将在后文提到分解和特征选择）。 
 
 
 
 
  
 
 

 
一旦我们把特征找齐了，就可以开始应用机器学习模型了。在这个阶段，你只需用到基于树的模型，包括：
 
随机森林分类器
随机森林回归器
ExtraTrees分类器
ExtraTrees回归器
XGB分类器
XGB回归器
 
由于没有归一化，我们不能将线性模型应用到上述特征上。为了能够应用线性模型，可以从scikit-learn中使用Normalizer或者StandardScaler。
 
这些归一化的方法仅限于密集特征，对稀疏特征，结果差强人意。当然，也可以在不使用平均值（参数：with_mean=False）的情况下对稀疏矩阵使用StandardScaler。
 
如果以上步骤得到了一个“好的”模型，我们就可以进一步做超参数的优化了。得不到的情况下，可以做如下步骤以改进模型。
 
接下来的步骤包括分解模型： 
 
 
 
 
  
 
 

 
简洁起见，我们跳过LDA和QDA转化。对高维数据，一般而言，PCA可以用来分解数据。对图片而言，从10-15个组分起始，在结果质量持续改进的前提下，逐渐增加组分数量。对其它的数据而言，我们挑选50-60个组分作为起点（对于数字型的数据，只要我们能够处理得了，就不用PCA） 
 
 
 
 
  
 
 

 
对文本型的数据，把文本转化为稀疏矩阵后，进行奇异值分解（Singular Value Decomposition (SVD)），可以在scikit-learn中找到一个SVD的变异版叫做TruncatedSVD。 
 
 
 
 
  
 
 

 
一般对TF-IDF有效的奇异值分解成分(components)是120-200个。更多的数量可能效果会有所改进但不是很明显，而计算机资源耗费却很多。
 
在进一步评价模型的性能以后，我们可以再做数据集的缩放，这样就可以评价线性模型了。归一化或者缩放后的特征可以用在机器学习模型上或者特征选择模块里。 
 
 
 
 
  
 
 

 
特征选择有很多方法。最常用的方法之一是贪心算法选择（正向或反向）。具体而言，选择一个特征，在一个固定的评价矩阵上训练一个模型，评价其性能，然后一个一个地往里面增加或移除特征，记录每一步的模型性能。最后选择性能得分最高时的那些特征。贪心算法和其评价矩阵的AUC的一个例子见链接： https://github.com/abhishekkrthakur/greedyFeatureSelection。 
 需要注意的是，这个应用并非完美，必须根据要求进行修改。
 
其他更快的特征选择方法包括从一个模型中选取最好的特征。我们可以根据一个逻辑回归模型的系数，或者训练一个随机森林来选择最好的特征，然后把它们用在其它的机器学习模型里。 
 
 
 
 
  
 
 

 
记得把估计值或者超参数的数量控制得尽量少，这样你才不会过拟合。
 
用Gradient Boosting Machine也可以实现特征选择。如果能用xgboost就不要用GBM，因为前者要快得多，可扩展性更好。 
 
 
 
 
  
 
 

 
对稀疏数据集，也可以用随机森林分类器/随机森林回归器或xgboost做特征选择。
 
从正性稀疏数据集里选择特征的其它流行方法还有基于卡方的特征选择，scikit-learn中即可应用。 
 
 
 
 
  
 
 

 
这里，我们用卡方联合SelectKBest的方法从数据中选择了20个特征。这个本身也是我们改进机器学习模型的超参数之一。
 
别忘了把任何中间过程产生的转化体转存起来。在验证集上你会要用它们来评价性能。
 
下一步（或者说，紧接着）主要的步骤是模型选择+超参数优化。 
 
 
 
 
  
 
 

 
一般来说，我们用下面的算法来选择机器学习模型：
 
分类
 
  
随机森林
GBM
逻辑回归
朴素贝叶斯
支持向量机
K最近邻法
回归
 
  
随机森林
GBM
线性回归
Ridge
Lasso
SVR
 
我需要优化哪个参数？如何选择最好的参数？这些是人们经常会遇到的问题。没有大量数据集上不同模型+参数的经验，无法得到这些问题的答案。有经验的人又不愿意把他们的秘诀公之于众。幸运的是，我有丰富的经验，同时愿意分享。让我们来看看不同模型下超参数的秘密： 
 
 
 
 
  
 
 

 
RS* =不好说合适的值是多少，在这些超参数里随机搜索一下。
 
以我个人浅见（原文作者个人意见），上述的这些模型比其他模型好，无需评价其它模型。
 
再说一次，记得保存这些转化体： 
 
 
 
 
  
 
 

 
然后对验证集做相同的操作。 
 
 
 
 
  
 
 

 
上面的规则和框架对我遇到的数据集而言运行良好。当然，在特别复杂的情况下也失败过。天下没有完美的东西，我们只能在学习中不断改进，如同机器学习一样。
 
任何疑问，请与原文作者联系：abhishek4@gmail.com

现在很多互联网公司都有自己的机器学习平台，冠以之名虽然形形色色，但就平台所要解决的问题和技术选型基本还是大同小异。
 
所谓大同是指大家所要处理的问题都相似，技术价格和选型也差不太多，比如都会使用 GPU 集群、采用 Spark/K8S 平台等。所谓小异是指各家规模不同，各家都在结合自己的情况、所处的阶段并根据自己的特点解决平台化的问题。
 
以下就滴滴的机器学习平台做一些介绍，侧重于介绍机器学习平台不同阶段所要解决的问题，以及解决问题的思路和技术方案。
 
滴滴机器学习平台的治理思路主要是：减少重复，提高效率。
 
机器学习平台 1.0：从“作坊”向“集中化”过渡
 
滴滴的机器学习平台建设开始于 2016 年，当时滴滴内部各算法团队逐步开展机器学习、深度学习等 AI 相关的研究和实践应用，这类算法大都属于计算密集型应用，一般都会使用单价较昂贵的 GPU 服务器。但随着业务的开展，各算法团队仅针对各自的问题做规划，导致了一种小作坊式的生产局面。
 
作坊式生产方式在早期有其积极的一面，能够保证创新的灵活性，但是越往后，这种小作坊式算法生产模式的局限就越明显：资源缺乏统筹调度，无法形成规模化效应，大量重复性工作，自拥算力有限。逐渐增多的这种小作坊式生产方式致使整体投入产出的效益大打折扣。
 
滴滴机器学习平台在这种背景下应运而生，这个阶段也主要致力于解决这些问题。
 
这期间机器学习平台所采用的架构和技术选型主要针对作坊式生产方式的问题来展开，也就是提高复用性和规模化能力。
 
首先要解决的问题就是统一资源管理，这个“统一”要解决包括线下和线上两类问题。
 
线下“统一”的问题着重解决 GPU 的服务器选型、测试、引入、上线等的集中化。这类集中化一方面提高了服务器引入的上线质量；另一方面相比于作坊式模式，由于有 GPU 相关专业人员参与进来，GPU 的选型避免了一味追新的盲目性和发散性。再者，集中化能够和公司整体大局结合起来，从而可以做最优化的选型和引入方案。
 
线上“统一”需要解决的问题细分为资源管理问题和任务调度问题，使资源使用方能够用即申请，完即释放，从而盘活整个资源大池，对平台要求则需要做到资源的隔离和管理。
 
这个阶段需要解决资源统一管理后如何避免重复性工作的问题。此时所谓的避免重复性，意在让各个算法业务不需重复诸如 Caffe、TensorFlow、PyTorch 等运行环境的构建，而是要一次构建所有用户都可用。这对平台来讲，需要做到应用环境管理、用户自定义环境、快速环境部署。
 
厘清这些需求之后，结合当时的技术环境和成熟度来看及以上的基本要求，平台选择当下盛行的 Docker 来兼做环境的管理、资源的弱隔离和任务的调度。但由于此时支持 GPU 资源调度的资源管理器乏善可陈，所以我们选择对 Yarn 做了扩展以支持 GPU 资源维度上的资源管理和任务调度，环境上平台同时提供 Notebook、Jupyter 的交互接口给用户。
 
统一资源管理、环境管理后，不得不面对的问题是多个资源节点间数据共享的问题，用户在当前资源释放后申请新资源时往往对之前的数据有依赖。
 
多节点数据共享在作坊式时期受限于单个的规模，问题不会十分突出，但是集中化之后随用户增多就会逐渐尖锐起来乃至是个大的技术挑战。因为：
 
机器学习的任务计算特点依赖于 GPU 的高速计算，它们对数据访问延迟有一定要求，这要求必须有足够高的 IO 带宽做支持；
用户数量增加，对存储带宽的需求会变的非常大；
对存储系统来说，支持 POSIX 接口的要求使得现有技术方案大大减小，另外也需在高可靠性、高性能以及成本之间做折中。
 
滴滴机器学习平台在存储系统上的尝试还是借用传统超算使用的 PFS 作为整个数据存储的一级，底层网络基础设施使用高带宽的以太网络，使用 RoCE 协议做 RDMA 的支持，并往这个方向演进。
 

 机器学习平台架构-Yarn
 
总的来看，这个阶段所面对的问题以内部问题为主，从作坊式到集中化生产的发展阶段，要解决的相关重复性的问题也比较简单。其中有些问题本质属于集中化后产生的问题，但是解决思路还是作坊式的，技术选型上的局限性也没有完全暴露出来。
 
机器学习平台 2.0：平台发展
 
随着作坊逐渐消失，机器学习平台作为一种集中化的生产方式呈现给公司所有算法团队。平台功能开始完整和完善，监控体系，运维体系，更加精细化的资源隔离、管理及优化；根据用户不同的任务性质也提供了不同性质的任务支持。
 
经历了前一个阶段后，虽然有效降低了作坊生产的重复性工作，但也几乎必然的产生了一些新形态的重复工作。用户接入的增多，用户任务的性质也多样化，有些是实验性质的、有些是在线生产任务、有些是单卡任务、有些是多卡多机的训练任务等等。
 
每种性质的任务都有各自重复的具体形式，比如用户在模型生产后要部署模型服务就需要解决服务的 HA、负载均衡等生产服务问题，每一个在线模型都要解决这类问题。
 
再比如，用户训练时往往需要调参，而这些参数都是同形的，只是数值上的变化，这种值上的变化后就是一个个独立的任务，需要用户提交任务的流程，这提交流程也是重复性的工作。
 
再比如，用户在运行多机多卡时需要参数服务器，低效的参数服务器把大量的时间浪费在通信上，这种浪费会加重用户资源使用上的重复；与这种重复形式相似的，还有比如模型服务要上线，为了满足服务的延迟、QPS、资源的约束，需要做从服务、到深度学习框架、再到计算库的全栈优化，基本上，大部分模型上线也需要经历这个优化过程。
 
针对上述新出现的问题，平台需要更加强大的资源管理和任务调度能力。
 
在上一时期选用作为资源管理和任务调度器的 Yarn 开始呈现出疲态，具体表现在 K8S 日臻成熟，与 Docker 的结合更加合理和完整，并能够整合多种维度的资源，使用 K8S 为解决模型服务的自动化部署提供了环境和条件，也降低了服务的运维成本，综合 K8S 和 Yarn 各自的利弊，滴滴机器学习平台开始由 Yarn 架构向 K8S 建构迁移。
 
 机器学习平台架构-K8S
 
针对用户同形调参的效率问题，平台对用户的 Python 代码做语义分析以自动识别出哪些参数可能会是需要调整的参数，用户只需要设置值域和步距就可以自动获取整套参数的模型训练任务以及最终的结果。
 
针对多机多卡训练效率问题，平台结合自己的硬件特点和通信模式特点，开发了滴滴参数服务器。滴滴参数服务器采取环状结构，实现了高效的 RDMA 通信的 Allreduce 算法。
 
环状结构而非中心集中的 server-client 模式，消除了网络传输可能的带宽竞争和网络拥塞。底层自研的高效 RDMA 通信库，规避了设备厂家提供用户态 Verbs 内部分性能损失，重写的底层通信库实现了 sig/read 及 post/recv 两种模式，尽量规避了 RDMA 固有的通信开销，充分挖掘了硬件的属性来提高性能。
 
另外，自研的 Allreduce 算法巧妙重叠了计算和传输，尽量减少了不必要的内存拷贝来减少额外代价，并充分考虑了 GPU 拓扑、CPU 亲和性等硬件属性来提高性能。
 
在机房 40G 带宽的 RoCE v2 RDMA 网络实际测试中，对比业界的 OpenMPI 和 Nvidia 的 NCCL2 方案，滴滴参数服务器有明显优势。
 
 
针对模型服务部署和优化，平台结合自己的场景特点开发了 DDL（DiDi Deep Learning） Serving 服务框架、IFX 框架和 Autotuning 优化库，极大的加速了模型上线部署和优化过程。
 
DDL Serving 独创自适应的 batch 机制，优化 RPC 协议，解决 Tensorflow Serving 的缺陷，相比于 Tensorflow Serving 性能对比加速如下：
 
 
 
DDL Serving 框架服务本身不再成为整个服务链路中的瓶颈点，对于一些轻量模型可以有 3 倍的性能提升，包括 RT 和 QPS 的提升, 而对于一般模型，性能热点落在深度学习框架层。
 
因此，针对框架层，我们自主研发了深度学习框架 IFX，并同时适配于 GPU 服务器和移动端平台。在 GPU 服务器上，由于 CUDA 存在 context 管理的问题，所以我们设计实现了一种 GPU 上的并发机制，有效地绕开了这些问题所带来的额外开销，另外对大量的 OP 做了优化，使得 IFX 的性能远高于 Tensoflow 乃至 TensorRT。
 
IFX 针对移动端的不同硬件配置，比如：流水线长度、顺序乱序、超标量等特点进行指令重排、访存优化，结合业务的计算特点，使得 IFX 的性能取得不俗的表现：
 
 
在 IFX 的优化过程中，大量的重复工作基本在 Tuning Blas 计算，由于硬件架构不同，不同模型的计算量、计算访存比、计算访存模式都不同，在极高性能要求下都需要综合这些具体的情况做针对性的优化。这些优化都很底层，并且调优都相对繁琐，对于上层服务用户来讲，不必关心这些底层细节。
 
为解决这类问题，平台开发了 Autotuning 工具链，包括 Kepler、Pascal、Volta 架构的原生汇编器。对于用户来讲，只需要把 GPU 上的二进制代码发给平台，平台就可产生在该 GPU 平台上几乎是最优，也就是当前最高性能优化后的二进制代码。
 
滴滴机器学习平台团队也是目前除了 NV 以外，自己掌握 NV GPU 原生汇编器支持版本最多，对 NV GPU 微架构最了解的。
 
 
这些“重复问题”随着集中化和平台化产生，也在平台化的环境下使得解决这些“重复”变得有意义。
 
集中化、平台化带来的第二个好处便是在此基础上，通用性的需求逐渐会沉淀为平台的服务。比如相似检索的需求在滴滴地图的 POI 优化、人脸检索、视频图像内容检索等业务场景中都是共性需求，因此平台会获得足够的业务信息来开发这种平台级的服务，而在作坊式时代很难获得这类跨业务场景的需求而自发的沉淀出平台服务，大多还是自扫门前雪。
 
机器学习平台 2.1：内外云平台成形
 
集中化生产后的第二个影响，随着平台能力的增加以及孵化落地算法逐步丰富，加上滴滴内部数据、AI 工程和算法逐步积累成熟，机器学习平台的功能、定位也变得多样化。
 
除了服务好滴滴内部机器学习平台用户，进一步夯实资源调度、任务管理、监控运维等能力外，平台开始承接内部能力对外输出的职能，期间机器学习平台和滴滴云着手在公有云上打造从底层资源到上层平台、从公有云到私有云的解决方案。
 
机器学习内部的集中化生产也给滴滴机器学习平台能力的输出做了储备，但外部客户的技术产品要求相对更复杂。这个复杂首先体现在产品要求的多层次性：有对资源乃至对硬件的直接要求、有对具体服务的需求、也有例如在私有云中对平台能力的需求；其次, 产品考量因素的多维性：资源的性价比往往只是一方面，安全性、稳定性、与其他基础设施的整合能力等也都是影响用户决策的因素；最后，横向各友商竞品的对比。
 
所有这些问题都是滴滴机器学习平台对外服务碰到的问题，但是这些问题不可能做到“毕其功于一役”，都是分阶段分步骤，有侧重的解决此间的问题。
 
第一步要解决的是基础问题，如何透出能力，如何保证客户的安全性，如何在前两个能力的基础上，尽最大力减少外部用户的重复性工作（用户使用的成本）和滴滴机器学习平台的重复性工作（产品性价比）。
 
GPU 资源：减少资源的重复性工作
 
相比于内部的用户，外部用户使用资源需要有一个安全的隔离环境，仅用 Docker 的弱隔离方式无法给用户提供安全且隔离的环境。所以滴滴云上 GPU 云资源使用 KVM 和 GPU 透传的方式把 GPU 资源透传给用户。
 
滴滴机器学习平台技术团队对 GPU 的使用颇有心得，团队成员也是早期一批在工业界尝试 GPU 的团队，积累了丰富的 GPU 使用一线的知识和经验，而且这些在滴滴内部被佐证十分有效，从 GPU 资源、拓扑和相关配套上都特别花心思，所以相同 GPU 型号，用户往往可以获得更好的性能，对比如下图。这部分的沉淀也减少了外部用户在探索使用 GPU 过程中的重复性工作，降低了使用的隐性成本。
 
 
弹性推理服务（EIS）：减少服务部署优化的重复
 
所有的算法模型最终都需要用于生产服务，国外有很多 PAML 平台能够部署机器学习模型服务，机器学习平台在滴滴云上也提供了一种模型部署服务——EIS（弹性预测服务）。
 
EIS 服务根植于内部使用的 DDL Serving 服务，但因在云上服务我们对一些理念的坚持，所以大家可能会产生我们有“起大早赶晚集”的疑问，诚然，EIS 在滴滴内部以 DDL 的形式出现的相对不算晚，但这一块的服务市场现在只能说是刚刚起步，产品的差异化和多样化会是必然的趋势，对用户来讲也有更好更大的选择空间。
 
目前，市面上大大小小提供 PA 服务的厂商大都有各自的特点，但总的来说他们对这个产品的定位依然仅仅是作为资源产品的辅助角色，着重为用户解决资源和部署问题。这种辅助角色，有他的好处，主要包括：
 
模式简单，把服务转化为最小粒度资源开销，按最小单位资源消耗来计费；
对基础设施的能力要求降低，简化为资源开销，本质上只是多了一种资源的售卖形式；
服务厂商的工作最小化，虽然用户可以选择多种资源，并且每种资源的都有各自理论上的计算能力，用户怎么利用好这些资源是用户自己的事情。
 
这个模式的问题在于服务商虽然为客户解决了一部分问题，但是对用户实际的服务部署考虑仍然不周。为什么？
 
原因在 DDL 描述中也提到过，模型服务部署服务都需要用户自己优化服务以满足 RT、QPS 的要求，更进一步说，成本如何最优化，用户使用云服务，成本几乎是必然会面对和慎重考虑的。
 
所以从这个点来看，PA 服务提供商以资源为主，服务为辅的模式的缺点也显而易见：
 
最小粒度资源的粒度对模型服务来说，粒度依旧比较粗，如若使用到 GPU，问题更加突出；
资源的理论计算能力对用户来讲往往仅是个理论数字，受限于硬件的限制和客户自己的技术能力，客户往往并不能充分利用 PA 厂商提供的资源的计算能力，而一般利用率都有限，这实际使用和标称的理论数字之间的资源费用实际是由用户买单的，而更甚者，对用户来讲这里有两部分工作是重复的：资源的使用优化的重复，服务部署的运维相关工作的重复。
 
根据我们内部用户和一些外部用户的经验，服务最核心的技术指标是 QPS 和 RT，进而才是满足这两个指标情况下的部署成本和使用成本。而这些成本的降低则必须在尽可能减少用户的重复工作和“实用实销”的基础上，除了一般服务部署需要的 HA 和运维支持外，EIS 从技术架构设计上侧重于解决这两方面问题。
 
从 RT 来讲：用户服务 RT 的开销受限于网络链路和实际前向计算的开销，为了减少网络链路的开销，滴滴云花了不少时间，在公有云上实现了纯公有云化的 Gateway，一方面用于支持用户自定义的鉴权等操作，另一方面也最小化网路跳数以降低网络的开销，保证用户服务的 RT。
 
从 QPS 来讲，EIS 使用滴滴机器学习平台的 DDL Serving 作为服务引擎框架，使用 DDL Serving 的用户可以忽略底层硬件的细节，从而可以避免用户重复地去做服务框架层面的已知的优化工作，这样也为实现用户“实用实销”提供了条件。可以通过以下的架构图了解：
 
 
要做到“实用实销”，还有一个非常关键的环节就是需要知道用户的模型实际的计算需求量，以及某一种硬件下的计算利用率。
 
我们开发了一个自动压测模块，用户提供模型和部署输入就可以获得使用 DDL Serving 在某种硬件下的计算性能，进一步回归出某种 RT 性能要求下的 QPS 能力。对用户来讲，用户折算出业务需总的 QPS 后按 QPS 横向扩容即可，相当于用户只负担了实际消耗的计算性能的那部分资源，这比之前的模式是更加细粒度的资源控制。
 
用户优化上的重复性工作的减少，如之前讲过的除了服务框架的优化外，还有一部分优化是花在计算性能的优化上，但计算性能的优化往往取决于程序的计算特性和相关的硬件特性，并且每种模型都有各自的特点，这部分工作 EIS 也提供了 Autotuning 的优化服务，用户需要提供他的二进制代码，通过 Autotuning 服务后会产生某种模型和框架下在指定硬件下几乎是最优的性能代码。
 
Autotuning 服务除了能降低重复基础的和琐碎的优化工作外，也能够提升用户模型服务 RT 和每 QPS 实际资源消耗资源。
 
目前 EIS 已经接入滴滴内部大量的业务，其整个功能模块图如下。因为一些限制，对外部客户，当前滴滴云 EIS 服务还是通过提交工单接入的方法，用户自助的方式马上会上线。
 
 
简枢：降低用户重复平台建设
 
同 EIS 一样，机器学习平台级产品在内部积累了丰富的一线的平台经验，基于此，机器学习平台在滴滴云上开发了平台级产品简枢。
 
简枢包装了多种平台能力，弱隔离方案的资源管理、多种任务管理、监控报警、在线服务快速部署等，能够帮助其他公司在平台化过程中少踩坑，快速具备平台能力，提高生产效益。
 
 
未来展望
 
对于机器学习来讲，计算力仍然是最具革命性的力量，正如 2011 年开始的这波深度学习浪潮的助力正是 GPU 一样，未来计算力还是工程层面的制约力。
 
如 Jeff Dean 所言“事实证明，我们真正需要的是超过现在 100 万倍的计算能力，而不仅仅是几十倍的增长。”因此，对平台来讲，如何更好的管理不断爆发式增加的计算力、如何有效的释放出这些计算力，如何驾驭好这些计算力仍然需要平台不断的探索、实践、技术升级等等。
 
所有平台的生命力源自于生产效率的综合提高，降低整体成本。对于滴滴机器学习平台而言，内部第一目标是要降低滴滴在使用最新的机器学习、深度学习、强化学习等技术上能够保证整体效率和成本控制，同时兼顾创新的活力；对于外部来讲，秉承持续为客户创造价值的理念，深化云平台产品的各项产品功能、质量和成本，为客户打造物美价廉的技术产品。
 

 机器学习平台3.0
 
具体来说，滴滴机器学习平台要实现 3.0 阶段，也即从硬件选型到基础设施到上层整个软件栈，能够做到内外统一架构，降低内外两部分的重复性工作。同时会从 AI 解决问题的效率和规模两方面着手，在平台上提供更丰富的功能，比如开发算法市场、模型市场、数据市场、GUI 界面以提高用户使用各种学习技术的效率，也会继续沉淀更多的具体服务，比如：人脸比对、语音识别、翻译等等。
 
 
本文首发于AI前线微信号（id:ai-front），作者：孔建钢，查看「原文链接」