Paddle应当如何提供云服务

[wangkuiyi]

在 #594 里，大家在讨论未来Paddle应该是什么形态。

这个讨论应该和Paddle未来如何支持公有云一起思考。

我想到两个路子，请大家看看：

1. 提供一个文档，教大家如何在各个公有云上申请一组机器，然后再上面部署Paddle。其中一台机器有external IP，这台机器上运行一个Paddle master process。用户的笔记本上执行的Python程序可以通过Restful API连接这个master process，提交作业，由master后面接着的多个worker processes以及parameter server processes来执行。这个设计会让Paddle变得很复杂，因为每一组 master/workers/pservers 要能执行来自多个用户的多个jobs。

2. 提供一个机群，部署好Kubernetes。另外提供一个Web服务，用户可以在上面申请由Paddle的跟CA签名的自己的CA，然后用这个CA以及kubectl来启动一组Paddle master/worker/pservers 来执行一个job。

抛砖引玉。具体结果很可能是这两个选择之外的。欢迎大家讨论。

[reyoung]

个人感觉这二选一的话，肯定是第二个好。。主要考虑的原因是 KISS (Keep it simple stupid)原则。肯定是选最简单的。

另外，我觉得如果觉得用户直接用kubectl启动不舒服的话，我们可以自己加一个paddle的命令行脚本或者gui工具。

比如，这个命令行工具，命令 paddle cluster_train --config=trainer_config.py --node=3 即可以开启集群训练。同时，可以使用另一个脚本/gui程序和master连接，达到实时控制训练过程的作用(实时调整学习率，实时优化算法)。

总的来说，有两点。

1、选择第2个方案，做出来先一套web服务。
2、每组任务有一组独立的master/worker/pserver。master里面存储kv信息，控制训练流程。
3、第一个方案中的各种用户使用上的功能，可以再第二个方案完成后的基础上，在客户端实现。

• 客户端实现申请资源，扩展资源，缩小资源
• 客户端实现于master节点通信，控制训练流程(学习率，学习算法，保存参数，暂停训练etc)

[backyes]

@wangkuiyi

提供一个文档，教大家如何在各个公有云上申请一组机器，然后再上面部署Paddle。其中一台机器有external IP，这台机器上运行一个Paddle master process。用户的笔记本上执行的Python程序可以通过Restful API连接这个master process，提交作业，由master后面接着的多个worker processes以及parameter server processes来执行。这个设计会让Paddle变得很复杂，因为每一组 master/workers/pservers 要能执行来自多个用户的多个jobs。

我理解，第一种方案中的master进程需要解决类似一个完备调度器要解决的大部分问题， 例如：

• 至少要保证对所有worker和pserver的保活监控之类

• 用户提交的master的作业如果中途失败了，怎么办？ 所以也要处理一致性问题

• 如果要实现动态增加worker和pserver的话，master也都得负责这些事情了。

• master如果挂了怎么办？所以， master可靠性也要考虑

所以第一种方案master要承载的东西特别多， 几乎要实现一个分布式系统的master总控了，会比较难，也没必要。

如果要选，个人建议第二种方案，上述大部分master功能是否能让Kubernetes去做。

[backyes]

@wangkuiyi

我理解这个讨论背景应该是， 如何让用户在公有云IaaS场景下自己搭建多机集群，对吧？

[drinktee]

我认为很少有用户愿意完整的在公有云机器上自己搭建一套环境。但是作为一个优质的开源项目，肯定需要提供常用平台上的安装部署教程。

第二种方式似乎比较友好，而且可以作为一种最佳实践或者产品。当然kubectl我认为就不必出现了，用户应该有一个paddlectl或者web页面来操作

[tizhou86]

个人倾向第二种方案。

第一种对用户的要求可能过于高了，会遇到各个不同层面的问题，从公有云iaas层，Kubernetes到深度学习都需要有充分的理解和实践。我们之所以会为用户提供尽可能简便通用的一键化脚本部署Kubernetes on AWS文档和Paddle on Kubernetes文档就是基于这个考虑，不希望用户被繁琐的配置和底层细节所困扰，能以一种像是在本地单机单进程的使用体验来使用分布式的训练。但我们会开放相应的文档，让有兴趣了解细节并且有能力进行定制化搭建的用户来阅读使用，以增强项目本身的技术影响力。

第二种基于公有云的SaaS化方案感觉更为理想，我们可以提供独立的api，命令行工具以及console，甚至和jupyter进行结合。这样也可以在kubernetes api的基础上添加权限控制，审计，计费等功能。每一次训练任务可以和kubernetes进行比较好的结合，提交相应的yaml文件以及配置文件作为输入，kubernetes来提供整个任务的生命周期管理，包括任务调度，资源分配，扩缩容量，健康检查，实时监控等，参考paddle on kubernetes。而对于控制训练流程而言，可以独立地开发模块来加以支持。

我们会在近期完成一个部署在AWS上的Paddle集群来给大家使用体验，在此基础上我们可以讨论下一步的具体方案。

[pineking]

支持第二种方案，能否做到用户不了解 Kubernetes 也能使用？

[llxxxll]

对第二种方案存疑:

• 开发者在这个方案中,想要达到的效果仅仅是run demo吗;如果仅仅是这样,服务端一定要真正有run的动作么?
• 如果可以自定义训练参数,那么在实际场景中肯定是要做限制,否则资源是不够用的.限制之后,这就是一个单纯的学习环境.那真正的开发环境还会包含在这个方案中吗?

我在幻想第三种方案

• 大家都知道比特币挖掘机和P2P网络吧.train的前期准备工作在paddlecloud上完成,而运算在用户本地(其他云\自己的集群\个人电脑).

[reyoung]

Closed because the paddle-cloud will be released soon.