深度学习推荐系统的工程实现

参考自《深度学习推荐系统》——王喆，用于学习和记录。

介绍

之前章节主要从理论和算法层面介绍了推荐系统的关键思想。但算法和模型终究只是“好酒”，还需要用合适的“容器”盛载才能呈现出最好的味道，这里的“容器”指的就是实现推荐系统的工程平台。

从工程的角度来看推荐系统，可以将其分为两大部分：数据部分和模型部分。数据部分主要指推荐系统所需数据流的相关工程实现；模型部分指的是推荐模型的相关工程实现，根据模型应用阶段的不同，可进一步分为离线训练部分和线上服务部分。根据推荐系统整体的工程架构，本章的主要内容可以分为以下三大部分：

（1）推荐系统的数据流：主要介绍与推荐系统数据流相关的大数据平台的主要框架和实现大数据平台的主流技术。

（2）深度学习推荐模型的离线训练：主要介绍训练深度学习推荐模型的主流平台，Spark MLlib、Parameter Server（参数服务器）、TensorFlow、PyTorch的主要原理。

（3）深度学习推荐模型的上线部署：主要介绍部署深度学习推荐模型的技术途径和模型线上服务的过程。

在此工程架构基础上，介绍工程和理论之间的权衡方法，探讨推荐算法工程师如何进行取舍才能达到工程和理论之间的平衡和统一。

推荐模型离线训练之 Parameter Server

上节对SparkMLlib的并行训练方法做了详细的介绍，Spark采取简单直接的数据并行的方法解决模型并行训练的问题，但Spark的并行梯度下降方法是同步阻断式的，且模型参数需通过全局广播的形式发送到各节点，因此Spark的并行梯度下降过程是相对低效的。

为了解决相应的问题，2014年分布式可扩展的ParameterServer方案被提出，几乎完美地解决了机器学习模型的分布式训练问题。时至今日，ParameterServer不仅被直接应用在各大公司的机器学习平台上，也被集成在TensorFlow、MXNet等主流的深度学习框架中，作为机器学习分布式训练重要的解决方案。

Parameter Server 的分布式训练原理

先以通用的机器学习问题为例，解释ParameterServer分布式训练的原理。

$F(w)=\sum_{i=1}^{n}\ell(x_{i},y_{i},w)+\Omega(w)$

上式是一个通用的带正则化项的损失函数，其中 $n$ 是样本总数， $l (x, y, w)$ 是计算单个样本的损失函数， $x$ 是特征向量， $y$ 是样本标签， $w$ 是模型参数。模型的训练目标就是使损失函数 $F (w)$ 最小。为了求解 $\arg(\operatorname*{min}F(w))$ ，往往使用梯度下降法。ParameterServer的主要作用就是并行进行梯度下降的计算，完成模型参数的更新直至最终收敛。需要注意的是，公式中正则化项的存在需要汇总所有模型参数才能正确计算，较难进行模型参数的完全并行训练，因此ParameterServer采取了和SparkMLlib一样的数据并行训练产生局部梯度，再汇总梯度更新参数权重的并行化训练方案。

具体地讲，下面代码以伪码的方式列出了ParameterServer并行梯度下降的主要步骤。

Task Scheduler:	// 总体并行训练流程
   issue LoadData() to all workers  // 分发数据到每一个worker节点
   for iteration t = 0 to T do
      // 每个worker节点并行执行 WORKERITERATE 方法，共 T 轮
      Issue WORKERITERATE(t) to all Workers
   end for

Worker r = 1 to m:
   function LOADDATA()	// worker 初始化过程
      load a part of training data (x_i, y_i)  // 每个 worker 载入部分训练数据
      pull the working set w_r  // 每个 worker 从 server 端拉取相关初始模型参数
   end function

   function WORKERITERATE(t)	// worker 节点的迭代计算过程
      compute gradient g_t  // 仅利用本节点数据计算梯度
      push gradient g_t to server  // 将计算好的梯度 push 到 server 端
      pull the working set w_(t+1)  // 从 server 端拉取新一轮模型参数
   end function

Servers:
   function SERVERITERATE(t)	// server 节点迭代计算过程
      // 在收到 m 个 worker 节点计算的梯度后，汇总形成总梯度
      w(t+1) = w(t) - n * (g(t) + λ * w(t))
      // 利用汇总梯度，融合正则化项梯度，计算出新梯度
   end function

可以看出，Parameter Server server worker，其主要功能如下：

server节点的主要功能是保存模型参数、接受worker节点计算出的局部梯度、汇总计算全局梯度，并更新模型参数。
worker节点的主要功能是保存部分训练数据，从server节点拉取最新的模型参数，根据训练数据计算局部梯度，上传给server节点。

在物理架构上，Parameter Server 和 Spark 的 manager-worker 架构基本一致，如图所示。

Parameter Server

可以看到，Parameter Server：服务器节点组（server group）和多个工作节点组（worker group）。资源管理中心（resource manager）负责总体的资源分配调度。

服务器节点组内部包含多个服务器节点（servernode），每个服务器节点负责维护一部分参数，服务器管理中心（servermanager）负责维护和分配server资源。

每个工作节点组对应一个Application（即一个模型训练任务），工作节点组之间，以及工作节点组内部的任务节点之间并不通信，任务节点只与server通信。

Parameter Server，Parameter Server如图所示。

Parameter Server

Parameter Server 的并行梯度下降流程中最关键的两个操作是 push 和 pull

push操作：worker节点利用本节点上的训练数据，计算好局部梯度，上传给server节点。
pull操作：为了进行下一轮的梯度计算，worker节点从server节点拉取最新的模型参数到本地。

概括整个ParameterServer的分布式训练流程如下：

（1）每个worker载人一部分训练数据。

（2）worker节点从server节点拉取（pull）最新的相关模型参数。

（3）worker节点利用本节点数据计算梯度。

（4）worker节点将梯度推送到server节点。

（5）server节点汇总梯度更新模型。

（6）跳转到第2步，直到迭代次数达到上限或模型收敛。

一致性与并行效率之间的取舍

在总结Spark的并行梯度下降原理时，笔者曾提到Spark并行梯度下降效率较低的原因是“同步阻断式”的并行梯度下降过程。

这种并行梯度下降过程需要所有节点的梯度都计算完成，由master节点汇总梯度，计算好新的模型参数后才能开始下一轮的梯度计算。这就意味着最“慢的节点会阻断其他所有节点的梯度更新过程。

另外，“同步阻断式”的并行梯度下降是“一致性”最强的梯度下降方法，因为其计算结果与串行梯度下降的计算结果严格一致。

那么，有没有在兼顾一致性的前提下，提高梯度下降并行效率的方法呢？

ParameterServer用“异步非阻断式”的梯度下降替代原来的“同步阻断式方法。下图所示为一个worker节点多次选代计算梯度的过程。可以看到节点在做第11次迭代（iter11）计算时，第10次选代后的push&pull过程并没有结束，也就是说，最新的模型权重参数还没有被拉取到本地，该节点仍在使用iter10的权重参数计算iter11的梯度。这就是所谓的异步非阻断式梯度下降法，其他节点计算梯度的进度不会影响本节点的梯度计算。所有节点始终都在并行工作，不会被其他节点阻断。

一个worker节点多次迭代计算梯度的过程

当然，任何技术方案都有“取”也有“舍”，异步梯度更新的方式虽然大幅加快了训练速度，但带来的是模型一致性的损失。也就是说，并行训练的结果与原来的单点串行训练的结果是不一致的，这样的不一致会对模型收敛的速度造成一定影响。所以最终选取同步更新还是异步更新取决于不同模型对一致性的敏感程度。这类似于一个模型超参数选取的问题，需要针对具体问题进行具体的验证。

除此之外，在同步和异步之间，还可以通过设置“最大延迟”等参数限制异步计算的程度。例如，可以限定在三轮迭代之内，模型参数必须更新一次。如果某worker节点计算了三轮梯度，还未完成一次从server节点拉取最新模型参数的过程，那么该worker节点就必须停下等待pull操作的完成。这是同步和异步之间的折中方法。

本节介绍了并行梯度下降方法中“同步”更新和“异步”更新之间的区别。在效果上，读者肯定关心下面两个指标：

（1）“异步”更新到底能够节省多少阻断时间（waitingtime）。
（2）“异步”更新会降低梯度更新的一致性，这是否会让模型的收敛时间变长。

针对上面两点疑问，ParameterServer论文的原文中提供了异步和同步更新的效率对比（基于Sparselogisticregression（稀疏逻辑回归）模型训练），对比了梯度同步更新策略和ParameterServer采取的异步更新策略的计算（computing）时间和阻断（waiting）时间；对比了不同策略的收敛速度。

不同策略的计算时间和阻断时间对比

System-A和System-B都是同步更新梯度的系统，ParameterServer是异步更新的策略，可以看出ParameterServer的计算时间占比远高于同步更新策略，这证明ParameterServer的计算效率有明显提高。

不同策略的收敛速度

可以看出，异步更新的ParameterServer的收敛速度比同步更新的System-A和System-B快，这证明异步更新带来的不一致性问题的影响没有想象中那么大。

多server节点的协同和效率问题

导致SparkMLlib并行训练效率低下的另一个原因是每次迭代都需要master节点将模型权重参数的广播发送到各worker节点。这导致两个问题：

（1）master节点作为一个瓶颈节点，受带宽条件的制约，发送全部模型参数的效率不高。

（2）同步地广播发送所有权重参数，使系统的整体网络负载非常大。

那么，ParameterServer如何解决单点master效率低下的问题呢？从架构图中可知，ParameterServer采用了服务器节点组内多server的架构，每个server主要负责部分模型参数。模型参数使用key-value的形式，因此每个server负责一个参数键范围（keyrange）内的参数更新就可以了。

那么另一个问题来了，每个server是如何决定自己负责哪部分参数范围呢？如果有新的server节点加人，那么如何在保证已有参数范围不发生大的变化的情况下加人新的节点呢？这两个问题的答案涉及一致性哈希（consistenthashing）的原理。ParameterServer节点组成的一致性哈希环如图所示。

ParameterServer节点组成的一致性哈希环

在ParameterServer的服务器节点组中，应用一致性哈希管理参数的过程大致有如下几步：

（1）将模型参数的key映射到一个环形的哈希空间，比如有一个哈希函数可以将任意key映射到 $\scriptstyle0\sim(2^{32})-1$ 的哈希空间内，只要让 $2^{32})$ -1这个桶的下一个桶是0这个桶，这个空间就变成了一个环形哈希空间。

（2）根据server节点的数量 $n$ ，将环形哈希空间等分成nm个范围，让每个 server 间隔地分配 $m$ 个哈希范围。这样做的目的是保证一定的负载均衡性，避免哈希值过于集中带来的server负载不均。

（3）在新加人一个server节点时，让新加人的server节点找到哈希环上的插入点，让新的server负责插人点到下一个插人点之间的哈希范围，这样做相当于把原来的某段哈希范围分成两份，新的节点负责后半段，原来的节点负责前半段。这样不会影响其他哈希范围的哈希分配，自然不存在大量的重哈希带来的数据大混洗的问题。

（4）删除一个server节点时，移除该节点相关的插人点，让临近节点负责该节点的哈希范围。

在ParameterServer的服务器节点组中应用一致性哈希原理，可以非常有效地降低原来单master节点带来的瓶颈问题。在应用一致性哈希原理后，当某worker节点希望拉取新的模型参数时，该节点将发送不同的“范围拉取请求”（rangepull）到不同的server节点，之后各server节点可以并行地发送自己负责的权重参数到该worker节点。

此外，由于在处理梯度的过程中server节点之间也可以高效协同，某worker节点在计算好自己的梯度后，只需要利用范围推送（rangepush）操作把梯度发送给一部分相关的server节点。当然，这一过程也与模型结构相关，需要跟模型本身的实现结合。总的来说，ParameterServer基于一致性哈希提供了参数范围拉取和参数范围推送的能力，让模型并行训练的实现更加灵活。

Parameter Server 技术要点总结

ParameterServer实现分布式机器学习模型训练的要点如下：

用异步非阻断式的分布式梯度下降策略替代同步阻断式的梯度下降策略。·
实现多server节点的架构，避免单master节点带来的带宽瓶颈和内存瓶颈。·
== 使用一致性哈希、参数范围拉取、参数范围推送等工程手段实现信息的最小传递，避免广播操作带来的全局性网络阻塞和带宽浪费==。

ParameterServer仅仅是一个管理并行训练梯度的权重平台，并不涉及具体的模型实现，因此 Parameter Server 往往作为 MXNet、TensorFlow 的一个组件，要想具体实现一个机器学习模型，还需要依赖通用的、综合性的机器学习平台。下一节将介绍以TensorFlow为代表的机器学习平台的工作原理。

深度学习推荐模型的上线部署

前几节介绍了深度学习推荐模型的离线训练平台，无论是TensorFlow、PyTorch，还是传统的SparkMLlib，都提供了比较成熟的离线并行训练环境。但推荐模型终究要在线上环境使用，如何将离线训练好的模型部署在线上的生产环境，进行线上实时推断，一直是业界的一个难点。本节将介绍在完成模型的离线训练后，部署推荐模型的主流方法。

预存推荐结果或 Embedding 结果

对于推荐系统线上服务来说，最简单直接的方法就是在离线环境下生成每个用户的推荐结果，然后将结果预存到Redis等线上数据库中。在线上环境直接取出预存数据推荐给用户即可。该方法的优缺点都非常明显，其优点如下。

（1）无须实现模型线上推断的过程，线下训练平台与线上服务平台完全解耦可以灵活地选择任意离线机器学习工具进行模型训练。

（2）线上服务过程没有复杂计算，推荐系统的线上延迟极低。
该方法的缺点如下。

（1）由于需要存储用户x物品x应用场景的组合推荐结果，在用户数量、物品数量等规模过大后，容易发生组合爆炸的情况，线上数据库根本无力支撑如此大规模结果的存储。

（2）无法引入线上场景类特征，推荐系统的灵活性和效果受限。

由于以上优缺点的存在，直接存储推荐结果的方式往往只适用于用户规模较小，或者一些冷启动、热门榜单等特殊的应用场景中。

直接预计算并存储用户和物品的Embedding是另一种线上“以存代算”的方式。相比直接存储推荐结果，存储Embedding的方式大大减少了存储量，线上也仅需做内积或余弦相似度运算就可以得到最终推荐结果，是业界经常采用的模型上线手段。

这种方式同样无法支持线上场景特征的引入，并且无法进行复杂模型结构的线上推断，表达能力受限，因此对于复杂模型，还需要从模型实时线上推断的角度人手。

自研模型线上服务平台

无论是在数年前深度学习刚兴起的时代，还是TensorFlow、PyTorch已经大行其道的今天，自研机器学习训练与线上服务的平台仍然是很多大、中型公司的重要选项。

为什么放着灵活且成熟的TensorFlow不用，而要从头进行模型和平台自研呢？

一个重要的原因是：TensorFlow等通用平台为了灵活性和通用性的要求，需要支持大量冗余的功能，导致平台过重，难以修改和定制。而自研平台的好处是可以根据公司业务和需求进行定制化的实现，并兼顾模型服务的效率。

另一个原因是当模型的需求比较特殊时，大部分深度学习框架无法支持。例如，某些推荐系统召回模型、“探索与利用”模型、与推荐系统具体业务结合得非常紧密的冷启动等算法，它们的线上服务方法一般也需要自研。

自研平台的端显而易见。由于实现模型的时间成本较高，自研一到两种模型是可行的，做到数十种模型的实现、比较和调优则很难。而在新模型层出不穷的今天，自研模型的选代周期过长。因此，自研平台和模型往往只在大公司采用，或者在已经确定模型结构的前提下，手动实现模型推断过程的时候采用。

预训练Embedding+轻量级线上模型

完全采用自研模型存在工作量大和灵活性差的问题，在各类复杂模型演化迅速的今天，自研模型的端更加明显，那么有没有能够结合通用平台的灵活性、功能的多样性，以及自研模型线上推断高效性的方法呢？答案是肯定的。

业界的很多公司采用了“复杂网络离线训练、生成Embedding存入内存数据库、线上实现逻辑回归或浅层神经网络等轻量级模型拟合优化目标”的上线方式。之前曾介绍过的“双塔”模型是非常典型的例子。

双塔模型分别用复杂网络对“用户特征”和“物品特征”进行了Embedding化，在最后的交叉层之前，用户特征和物品特征之间没有任何交互，这就形成了两个独立的“塔”，因此称为双塔模型。

在完成双塔模型的训练后，可以把最终的用户Embedding和物品Embedding存人内存数据库。而在进行线上推断时，也不用复现复杂网络，只需要实现最后输出层的逻辑即可。这里的输出层大部分情况下就是逻辑回归或softmax，也可以使用复杂一点的浅层神经网络。但无论选择哪种神经网络，线上实现的难度并不大。在从内存数据库中取出用户Embedding和物品Embedding之后，通过输出层的线上计算即可得到最终的预估结果。

在这样的架构下，还可以在输出层之前把用户Embedding和物品Embedding，以及一些场景特征连接起来，使模型能够引人线上场景特征，丰富模型的特征来源。

在 Graph Embedding 技术已经非常强大的今天，Embedding离线训练的方法已经可以融入大量用户和物品信息，输出层并不用设计得过于复杂，因此采用Embedding $+$ 轻量级线上模型的方法进行模型服务，不失为一种灵活简单且不过多影响模型效果的方法。

利用PMML转换并部署模型

Embedding+轻量级模型的方法是实用且高效的，但无论如何还是割裂了模型。无法实现End2End训练 $+$ End2End部署这种最完美的方式。有没有在离线训练完模型之后，直接部署模型的方式呢？本节介绍一种脱离平台的通用的模型部署方式一PMML。

PMML的全称是“预测模型标记语言”（Predictive Model Markup Language，PMML），是一种通用的以XML的形式表示不同模型结构参数的标记语言。在模型上线的过程中，PMML经常作为中间媒介连接离线训练平台和线上预测平台。

这里以SparkMLlib模型的训练和上线过程为例解释PMML在整个机器学习模型训练及上线流程中扮演的角色（如图所示）。

Spark MLlib 模型利用 PMML 的上线过程

图中的例子使用JPMML作为序列化和解析PMML文件的library（库）。JPM ML 项目分为 Spark 和 Java Server 两部分。Spark 部分的 library 完成 SparkMLlib 模型的序列化，生成PMML文件并保存到线上服务器能够触达的数据库或文件系统中；JavaServer部分则完成PMML模型的解析，并生成预估模型，完成与业务逻辑的整合。

JPMML在JavaServer部分只进行推断，不考虑模型训练、分布式部署等一系列问题，因此library比较轻，能够高效地完成推断过程。与JPMML相似的开源项目还有MLeap，同样采用了PMML作为模型转换和上线的媒介。

事实上，JPMML 和 MLeap 也具备 Scikit-learn、TensorFlow 中简单模型转换和上线能力。但针对TensorFlow中的复杂模型，PMML语言的表达能力是不够的，因此上线 TensorFlow 模型就需要 TensorFlow 的原生支持——Tensor FlowServing。

Tensor Flow Serving

TensorFlow Serving 是 TensorFlow 推出的原生的模型服务器。本质上讲，TensorFlow Serving的工作流程和PMML类工具的流程是一致的。不同之处在于，TensorFlow定义了自己的模型序列化标准。利用TensorFlow自带的模型序列化函数可将训练好的模型参数和结构保存至某文件路径。

TensorFlow Serving 最普遍也是最便捷的服务方式是使用 Docker 建立模型服务API。在准备好Docker环境后，仅需要通过拉取镜像的方式（pull image）即可完成TensorFlow Serving环境的安装和准备：

docker pull tensorflow/serving

在启动该dockercontainer后，也仅需一行命令即可启动模型服务API：

tensor flow model server--port=8500 --rest_api_port=8501 \
--model_name=$(MODEL_NAME} --model_base_path=S{MODEL_BASE_ PATH}/S{MODEL_NAME)

这里仅需注意之前保存模型的路径。

当然，要搭建一套完整的TensorFlow Serving服务并不是一件容易的事情，因为其中涉及模型更新、整个docker container集群的维护和按需扩展等一系列工程问题。TensorFlow Serving的性能问题仍被业界垢病，但它的易用性和对复杂模型的支持，使其成为上线TensorFlow模型的第一选择。

灵活选择模型服务方法

深度学习推荐模型的线上服务问题是非常复杂的工程问题，因为其与公司的线上服务器环境、硬件环境、离线训练环境、数据库/存储系统等有非常紧密的联系。正因为这样，各家采取的方式也各不相同。在这个问题上，即使本节已经列出了5种主要的上线方法，也无法囊括业界的所有推荐模型上线方式，甚至在一个公司内部，针对不同的业务场景，模型的上线方式也不尽相同。
因此，作为一名算法工程师，除了应对主流的模型服务方式有所了解，还应对公司客观的工程环境进行综合权衡，给出最适合的解决方案。

工程与理论之间的权衡

工程和理论往往是解决技术问题过程中矛盾又统一的两面。理论依赖工程的实现，脱离了工程的理论是无法发挥实际作用的空中楼阁；而工程又制约着理论的发展，被装在工程框架下的理论往往需要进行一些权衡和取舍才能落地。本节希望与读者讨论的是在推荐系统领域，如何在工程与理论之间进行权衡。

工程师职责的本质

工程和理论的权衡是工程师不得不考虑的问题，对这个问题的思考决定了一名工程师应具备的是“工程思维”，而不是学者具备的“研究思维”。推荐系统是一个工程性极强，以技术落地为首要目标的领域，“工程思维”的重要性不言而喻。接下来，笔者会站在工程师的角度阐述如何在工程和理论之间进行权衡。

无论你是算法工程师，还是研发工程师，甚至是设计电动汽车、神舟飞船、长征火箭的工程师，职责都是相同的，那就是：在现有实际条件的制约下，以工程完成和技术落地为目标，寻找并实现最优的解决方案。

回到推荐系统中来，这里的“现有实际条件的制约”可以是来自研发周期的制约、软硬件环境的制约、实际业务逻辑和应用场景的制约，也可以是来自产品经理的优化目标的制约，等等。正因这些制约的存在，一名工程师不可能像学术界的研究人员一样任意尝试新的技术，做更多探索性的创新。

也正是因为工程师永远以“技术落地”为目标，而不是炫耀自己的新模型、新技术是否走在业界前沿，所以在前沿理论和工程现实之间做权衡是一名工程师应该直有的基本素质。下面笔者用三个实际的案例帮助读者体会如何在实际工程中进行技术上的权衡。

Redis容量和模型上线方式之间的权衡

对线上推荐系统来说，为了进行在线服务，需要获取的数据包括两部分模型参数和线上特征。为了保证这两部分数据的实时性，很多公司采用内存数据库的方式实现，Redis自然是最主流的选择。但Redis需要占用大量内仔资源，而内存资源相比存储资源和计算资源文是比较稀缺和昂贵的资源，因此无论是用Aws（AmazonWebServices，亚马逊网络服务平台）、阿里云，还是自建数据中心，使用Redis的成本都比较高，Redis的容量就成了制约推荐模型上线方式的关键因素。

在这个制约因素的限制下，工程师要从两个方面考虑问题。

（1）模型的参数规模要尽量小，特别是对深度学习推荐系统而言，模型的参数量极较传统模型有了几个量级的提升，更应该着重考虑模型的参数规模。

（2）线上预估所需的特征数量不能无限制地增加，要根据重要性做一定程度的取舍。

在这样的制约因素下上线推荐系统，必然需要舍弃一些次要的要素，关注主要矛盾。一名成熟的工程师的思路应该是这样的：

（1）对于千万甚至更高量级的特征维度，理论上参数的数量级也在千万量级，线上服务是很难支持这种级别的数据量的，这就要求工程上关注模型的稀疏性，关注主要特征，舍弃大量次要特征，舍弃一定的模型预测准确度，提升线上预估的速度，减小工程资源消耗。

（2）增强模型的稀疏性的关键技术点有哪些？加入L1正则化项，采用FTRL等稀疏性强的训练方法。

（3）实现目标的技术途径有多种，在无法确定哪种技术效果更佳的情况下，实现所有备选方案，通过离线和在线的指标进行比较观察。

（4）根据数据确定最终的技术途径，完善工程实现。

以上是模型侧的“瘦身”方法，针对在线特征的“瘦身”计划当然可以采用同样的思路。首先采用“主成分分析”等方法进行特征筛选，在不显著降低模型效果的前提下减少所用的特征。针对不好取舍的特征，进行离线评估和线上A/B测试，最终达到工程上可以接受的水平。

研发周期限制和技术选型的权衡

在实际的工程环境中，研发周期的制约同样是不可忽视的因素。这就涉及工程师对项目整体的把控能力和对研发周期的预估能力。在产品选代日益迅速的互联网领域，没人愿意成为拖累其他团队的最慢一环。

书籍作者曾经经历过多次产品和技术平台的大规模升级。在技术平台升级的过程中，要充分权衡产品新需求和技术平台整体升级的进度。例如，公司希望把机器学习平台从Spark整体迁移到TensorFlow，这是顺应深度学习浪潮的技术决策，但由于Spark平台自身的特性，编程语言、模型训练方式和TensorFlow有较大差别，整个迁移必然要经历一个较长的研发周期。在迁移的过程中，如果有新的产品需求，就需要工程师做出权衡，在进行技术升级的过程中兼顾日常的开发进度。

这里可能的技术途径有两个：

（1）集中团队的力量完成Spark到TensorFlow的迁移，在新平台上进行新模型和新功能的研发。

（2）团队一部分成员利用成熟稳定的Spark平台快速满足产品需求，为TensorFlow的迁移、调试、试运行留足充分的时间。与此同时，另一部分成员则全力完成TensorFlow的相关工作，力保在大规模迁移之前新平台的成熟度。

单纯从技术角度考虑，既然已经决定升级到TensorFlow平台，理论上没必要再花时间利用Spark平台研发新模型。这里需要搞清楚的问题有两个。

（1）再成熟的平台也需要整个团队磨合调试较长时间，绝不可能刚迁移至TensorFlow就让它支持重要的业务逻辑。

（2）技术平台的升级换代应作为技术团队的内部项目，最好对其他团队透明，不应成为减缓对业务支持的直接理由。

因此、从工程进度和风险角度考虑，第2个技术途径应成为更符合工程头际和公司实际的选择。

硬件平台环境和模型结构间的权衡

几平所有算法工程师都有过类似的抱怨一“公司的平台资源太少，训练一个模型要花将近一天的时间”。当然，“大厂”的资源相对充足，“小厂”囿于研发成本的限制更容易受到硬件平台环境的制约。但无论什么规模的公司，硬件资源总归是有限的，因此要学会在有限的硬件资源条件下优化模型相关的一切工程实现。

这里的“优化”实际上包括两个方面：

一方面是程序本身的优化。经常遇到一些实习生抱怨Spark跑得太慢，究其原因，是因为他们对Spark的shuffle机制没有深入了解，写的程序包含大量触发shuffle的操作，容易导致大量的数据倾斜问题。这样的问题本身并不涉及技术上的“权衡”，而是应该夯实自己的技术功底，尽量通过技术上的“优化”提升模型的训练效率和实时性。

另一方面的优化就需要一些技术上的取舍了。能否通过优化或者简化模型的结构大幅提升模型训练的速度，降低模型训练的消耗，提升推荐模型的实时性呢？典型的案例已经提到。在深度学习模型中，模型的整体训练收敛速度和模型的参数数量有很强的相关性，而模型的参数数量中输人层到Embedding层的数量占绝大部分。因此，为了大幅加快模型的训练速度，可以将Embedding部分单独抽取出来做预训练，这样可以做到上层模型的快速收敛。当然，这样的做法舍弃了End2End训练的一致性，但在硬件条件制约的情况下，增强模型实时性的收益可能远大于End2End训练带来的模型一致性收益。

其他类似的例子还包括简化模型结构的向题。如果通过增加模型复杂性（例如增加神经网络层级，增加每层神经元的数量）带来的收益已经趋于平缓，就没有必要浪费过多硬件资源做微乎其微的效果提升，而是应该把优化方向转换到提升系统实时性，挖掘其他有效信息，为模型引入更有效的网络结构等方面。