为什么tensorflow中的参数服务器这么重？

我们分析了Tensorflow的参数服务器，发现参数服务器apply gradient op仅消耗20us，但参数服务器中的RunGraphAsync总共需要200us左右（梯度是通过RunGraphAsync RPC调用发送的，recv op中没有分段的GRPC请求）

是什么原因导致Tensorflow中有如此重的参数服务器设计

我的理解是ops可以在单个或集群中重用，此外，为什么我们需要在参数服务器中运行重子图？更简单的参数服务器可以在分发模式下带来难以置信的性能

Tensorflow的PS运行worker的子图，variable/gradient需要worker的发送/接收，这是许多碎片化GRPC请求的。

---

与parameter server相比，我们分析了Tensorflow的PS可以处理来自工作者的10K请求（RunGraphAsync），但基于KV的parameter server可以处理来自工作者的100K或更多请求。

我猜可能存在可修复的错误/效率低下，使其速度变慢。谷歌主要关注大数据传输/长步骤的优化，因此小负载没有得到足够的关注。我会建议做基准测试/评测/归档错误。最近，一位用户通过找到根本原因，使TensorFlow的小张量传输速度提高了10倍——顺便说一句，纯

TF_Run

调用的开销约为20usec。如果

RunGraphAsync

增加了180 usec的开销，那么这似乎也是一个问题high@YaroslavBulatov，在我们的例子中，我们希望扩展到数千个工作人员，但使用tensorflow的参数服务器，只能扩展到200个工作人员（我们已经进行了一些优化，对于本机1.21，32个工作人员是限制）。我们分析并发现参数服务器太重了。但是现在我们需要决定是使用tensorflow的ps还是我们自己的参数服务器。在tensorflow中，使用数千名工作人员是一个常见的用例，应该进行很好的优化。瓶颈到底是什么？您确定200 usec不是由于与这么多工人同步的成本造成的吗？200us是在参数服务器端执行RunGraphAsync的时间。在官方版本中应该更多，因为recv op将等待工作人员发送张量请求。当扩展到200个工人时，参数服务器（100个参数服务器，带有参数分区）变得非常沉重。