Skip to content

Parameter server design doc #1880

@helinwang

Description

@helinwang

无论是否重写parameter server,我们都需要一个清晰的parameter server接口:

  • 如果不重写,可以保证修改现有代码不会让可维护性降得更低。以后要重写只用保持接口不变,更换实现即可。
  • 如果重写,也需要一个清晰的接口,保证代码质量。

目前parameter server只需要支持:异步SGD,不带动量的优化算法(传统SGD),dense更新。
不需要支持:同步SGD,各种带动量的优化算法,sparse更新。
接口需要涵盖目前不需要支持的功能,不需要实现不支持的功能。

据我理解,design doc需要以下几块接口的定义:

  • 运行parameter server的命令行参数是什么:
    比如: --port 8000 --save-period 60

  • RPC Server接口伪代码:
    我想象的,举个例子:

    int update(string method, list of dense gradients);
    int download(pointer to list of dense gradients);
    int updateSparse(string method, xxx);
    int downloadSparse(xxx);
    int saveModel(string path);
  • RPC client API,python and C/C++
    出于性能考虑update和download貌似只能是C/C++ API (不然数据类型需要经过python中转)。

    • C/C++ API(C或者C++都行,只要表达了意思就好)。如果要用golang重写,实现的时候需要C API:
      我想象的,举个例子:
    int update(string method, list of dense gradients);
    int download(pointer to list of dense gradients);
    int updateSparse(string method, xxx);
    int downloadSparse(xxx);
    int saveModel(string path);
    int wait(int t);
    
    // e.g.,
    // update(...);
    // int errorCode = wait(download(...));
    • python API(是否只需要保存模型的API?)
  • 把parameter server 主干部分(参数存储,更新部分,除去RPC以及使用etcd做service announcement的部分)当作一个库,库的API。
    定义库API可以把RPC代码与主干部分清晰分开。以后保持接口,更换实现会很方便。另外有可能用golang写主程序,编译时候链接这个库。

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions