TensorFlow在美团推荐系统中的分布式训练优化实践( 六 ) _云知道

针对上面的问题，我们采用了Multi RequestBuffer与CQ负载均衡优化，破除了在请求发送和请求应答环节可能存在的吞吐瓶颈。
3.3.4 Send-Driven & Rendezvous-Bypass
对于Tensorflow PS架构熟悉的同学会了解，一整张计算图被切割为Worker端和PS端后，为了使两张计算图能够彼此交换数据，建立了基于Rendezvous（汇合点）机制的异步数据交换模式。如下图12所示：

图12 TensoFlow切图之Send-Recv对添加

基于上图的切图逻辑， Recv算子代表着这一侧计算图有Tensor的需求，而Tensor的生产者则位于与之配对的另一设备上的Send算子背后。
在具体实现上， Tensorflow实现了Recv-Driven的数据交换模式，如上图所示，位于DeviceA和DeviceB的两张计算图会异步并发的执行，位于DeviceB的Recv执行时会发起一条RPC请求发往DeviceA ， DeviceA收到请求后，会将请求路由到Rendezvous中，如果在当中发现所需要的数据已经生产好，并被Send算子注册了进来，那么就地获取数据，返回给DeviceB；如果此时数据还没有生产好，则将来自于DeviceB的Recv请求注册在Rendezvous中，等待后续DeviceA生产好后，由Send算子发送过来，找到注册的Recv ，触发回调，返回数据给DeviceB 。
我们看到，汇合点机制优雅地解决了生产者消费者节奏不同情况下数据交换的问题。不过Recv-Driven的模式也引入了两个潜在的问题：
据我们的观察，在实际业务模型中，在Rendezvous中Recv算子等待Send算子的比例和Send算子等待Recv算子的比例相当，也就是说对于Send等到Recv的数据，在Send准备好的那一刹那就可以发给对端，但是由于机制实现问题，还是等待Recv算子过来，才将数据拉取回去，通信过程耗时较长。Rendezvous作为一个数据交换的热点，它内部的逻辑开销并不低。
针对上面提到的问题，我们在RDMA上实现了另外一种数据交换的模式，叫做Send-Driven模式。与Recv-Driven模式相对，顾名思义就是有Send算子直接将数据写到Recv端， Recv端接收数据并注册到本地Rendezvous中， Recv算子直接从本地的Rendezvous中获取数据。具体流程如下图13所示：

图13 原生的Recv-Driven与补充的Send-Driven机制

从图中可以看到，相较于Recv-Driven模式， Send-Driven模式的通信流程得到了比较大的简化，另外在数据ready后立即发送的特性，跳过了一侧的Rendezvous ，并且对于生产者先于消费者的情况，可以加快消费端数据获取的速度。
3.4 延迟优化
这部分优化，也是分布式计算的经典优化方向。整个流程链路上那些可以精简、合并、重叠需要不断去挖掘。对于机器学习系统来说，相比其它的系统，还可以用一些近似的算法来做这部分工作，从而获得较大的性能提升。下面介绍我们在两个这方面做的一些优化实践。
3.4.1 稀疏域参数聚合
在启用HashTable存储稀疏参数后，对应的，一些配套参数也需要替换为HashTable实现，这样整个计算图中会出现多张HashTable以及大量的相关算子。在实践中，我们发现需要尽量降低Lookup/ｉｎｓｅｒｔ等算子的个数，一方面降低PS的负载，一方面降低RPC QPS 。因此，针对稀疏模型的常见用法，我们进行了相关的聚合工作。