机器学习中的serving

在实际的机器学习任务中，在模型训练完成后，通常或将得到的模型用于离线预测，或发布为线上服务（deploy）。离线预测的情况由于与训练过程同为离线批处理过程，因此并不复杂。而发布为服务进行在线预测的情况则不同，往往需要考虑以下问题：

    1. 　预测性能：

        不同于离线预测，在线预测对于性能的要求通常要苛刻得多；

    2.　运行时（runtime）差异：

        离线训练/预测时，数据处理流程通常运行在离线批处理环境下（参考Spark pipeline），其逻辑无法直接在在线预测时使用；

    3.    模型版本问题：

        模型需要不断迭代，而线上服务一方面能够平滑的处理版本切换，另一方面又要能够允许对特定版本的调用以进行对比测试；

    显而易见的是，要将模型在线上服务中使用，在技术上需要一套相对通用的机制，能够解决好上述问题，也就是通常所说的serving。

    针对上面提到的几个问题，开源世界中已经有了一些不错的解决方案。根据其功能和解决的问题，大致可以分为以下几类：

    1. 深度学习推断 （dl inference）框架:

    解决问题1，旨最大化深度模型执行性能（这里指forward过程），尤其是在特定硬件环境下。

    2. 处理流（Pipeline）框架:

    解决问题2，旨在提供能够在离线/在线不同环境中兼容的处理流接口，如mleap。    

    3. 模型服务框架：

    解决问题３，旨在提供通用的模型加载和接口发布服务，如tensorflow serving。

    不难发现，虽然上述问题都有相应的方案予以解决，然而在实际应用中，仍然需要根据实际情况进行细致的选型、整合和改造。除此以外，在线预测环节，对于特征（实时/离线）的整合和管理也是不小的挑战。关于这一点，以后再进行详细探讨。