<liclass="toctree-l2"><aclass="reference internal"href="../../getstarted/build_and_install/index_en.html">Install and Build</a><ul>
<liclass="toctree-l3"><aclass="reference internal"href="../../getstarted/build_and_install/docker_install_en.html">PaddlePaddle in Docker Containers</a></li>
<liclass="toctree-l3"><aclass="reference internal"href="../../getstarted/build_and_install/build_from_source_en.html">Installing from Sources</a></li>
<liclass="toctree-l2"><aclass="reference internal"href="../../howto/usage/k8s/k8s_en.html">Paddle On Kubernetes</a></li>
<liclass="toctree-l2"><aclass="reference internal"href="../../howto/usage/k8s/k8s_aws_en.html">Distributed PaddlePaddle Training on AWS with Kubernetes</a></li>
<liclass="toctree-l2"><aclass="reference internal"href="../../howto/dev/build_en.html">Build PaddlePaddle from Source Code and Run Unit Test</a></li>
<liclass="toctree-l2"><aclass="reference internal"href="../../howto/dev/new_layer_en.html">Write New Layers</a></li>
<spanid="design-doc-distributed-training-architecture"></span><h1>Design Doc: Distributed Training Architecture<aclass="headerlink"href="#design-doc-distributed-training-architecture"title="Permalink to this headline">¶</a></h1>
<divclass="section"id="abstract">
<spanid="abstract"></span><h2>Abstract<aclass="headerlink"href="#abstract"title="Permalink to this headline">¶</a></h2>
<p>PaddlePaddle v0.10.0 uses the “trainer-parameter server”
architecture. We run multiple replicated instances of trainers (runs
the same code written by the user) and parameter servers for
distributed training. This architecture served us well, but has some
limitations:</p>
<olclass="simple">
<li>Need to write special code to handle tasks which should only be run
by a single trainer. E.g., initializing model and saving model.</li>
<li>Model parallelism is hard: need to write if-else branches conditioned
on the trainer ID to partition model onto each trainer, and manually
write the inter-model-shard communication code.</li>
<li>The user can not directly specify the parameter update rule: need
to modify the parameter server C++ code and compile a new
binary. This adds complication for researchers: A lot of extra
effort is required. Besides, the training job submission program
may not allow running arbitrary binaries.</li>
</ol>
<p>This design doc discusses PaddlePaddle’s new distributed training
architecture that addresses the above limitations.</p>
</div>
<divclass="section"id="analysis">
<spanid="analysis"></span><h2>Analysis<aclass="headerlink"href="#analysis"title="Permalink to this headline">¶</a></h2>
<p>We will assume the user writes the trainer program by Python, the same
analysis holds if the trainer program is written in C++.</p>
<divclass="section"id="limitation-1">
<spanid="limitation-1"></span><h3>Limitation 1<aclass="headerlink"href="#limitation-1"title="Permalink to this headline">¶</a></h3>
<p>If we look at the Python code that the user writes, there are two
kinds of functionalities:</p>
<ulclass="simple">
<li>The training logic such as load / save model and print log.</li>
<li>The neural network definition such as the definition of the data
layer, the fully connected layer, the cost function and the
optimizer.</li>
</ul>
<p>When we training with PaddlePaddle v0.10.0 distributedly, multiple
replicated Python instances are running on different nodes: both the
training logic and the neural network computation is replicated.</p>
<p>The tasks that should only run once all belong to the training logic,
if we only replicate the neural network computation, but do <strong>not</strong>
replicate the training logic, the limitation could be solved.</p>
</div>
<divclass="section"id="limitation-2">
<spanid="limitation-2"></span><h3>Limitation 2<aclass="headerlink"href="#limitation-2"title="Permalink to this headline">¶</a></h3>
<p>Model parallelism means running a single model on multiple nodes by
partitioning the model onto different nodes and managing the
inter-model-shard communications.</p>
<p>PaddlePaddle should be able to modify the nerual network computation
definition to support model parallelism automatically. However, the
computation is only specified in Python code, and PaddlePaddle can not
modify Python code.</p>
<p>Just like compiler uses a intermediate representation (IR) so that
programmer does not need to manually optimize their code in most of
the cases - the compiler will optimize the IR:</p>
<p><imgsrc="src/compiler.png"/></p>
<p>We can have our own IR too: PaddlePaddle can support model parallel by
converting the IR so the user no longer need to manually do it in
Python:</p>
<p><imgsrc="src/paddle-compile.png"/></p>
<p>The IR for PaddlePaddle after refactor is called <codeclass="docutils literal"><spanclass="pre">Block</span></code>, it specifies
the computation dependency graph and the variables used in the
computation.</p>
</div>
<divclass="section"id="limitation-3">
<spanid="limitation-3"></span><h3>Limitation 3<aclass="headerlink"href="#limitation-3"title="Permalink to this headline">¶</a></h3>
<p>The user can not directly specify the parameter update rule for the
parameter server because the parameter server does not use the same
computation definition as the trainer. Instead, the update rule is
baked in the parameter server. The user can not specify the update
rule in the same way of specifying the trainer computation.</p>
<p>This could be fixed by making the parameter server run the same
computation definition as the trainer. For a detailed explanation,
please
see
<aclass="reference external"href="design/refactor/dist_train.md">Design Doc: Operation Graph Based Parameter Server</a></p>
<spanid="distributed-training-architecture"></span><h2>Distributed Training Architecture<aclass="headerlink"href="#distributed-training-architecture"title="Permalink to this headline">¶</a></h2>
<p>The new distributed training architecture can address the above
<p>The architecture includes major components: <em>PaddlePaddle Python</em>,
<em>PaddlePaddle converter</em> and <em>PaddlePaddle runtime</em>:</p>
<divclass="section"id="paddlepaddle-python">
<spanid="paddlepaddle-python"></span><h3>PaddlePaddle Python<aclass="headerlink"href="#paddlepaddle-python"title="Permalink to this headline">¶</a></h3>
<p>PaddlePaddle Python is the Python library that user’s Python trainer
invoke to build the neural network topology, start training, etc.</p>
<spanclass="nb">input</span><spanclass="o">=</span><spanclass="n">paddle</span><spanclass="o">.</span><spanclass="n">op</span><spanclass="o">.</span><spanclass="n">recordIO</span><spanclass="p">(</span><spanclass="s2">"/home/data/mnist.recordio"</span><spanclass="p">)</span><spanclass="c1"># file stored on the cluster</span>
<p>The code above is a typical Python trainer code, the neural network
topology is built using helper functions such as
<codeclass="docutils literal"><spanclass="pre">paddle.layer.fc</span></code>. The training is done by calling <codeclass="docutils literal"><spanclass="pre">session.eval</span></code>
iteratively.</p>
<divclass="section"id="session-eval">
<spanid="session-eval"></span><h4>session.eval<aclass="headerlink"href="#session-eval"title="Permalink to this headline">¶</a></h4>
<p>As shown in the graph, <codeclass="docutils literal"><spanclass="pre">session.eval</span></code> sends the IR and the evaluation
inputs/targets to the PaddlePaddle cluster for evaluation. The
targets can be any variable in the computation graph. When the target
is the <codeclass="docutils literal"><spanclass="pre">optimizer</span></code> variable, the neural network will be optimized
once. When the target is the <codeclass="docutils literal"><spanclass="pre">cost</span></code> variable, <codeclass="docutils literal"><spanclass="pre">session.eval</span></code> returns
the cost value.</p>
<p>The Python <codeclass="docutils literal"><spanclass="pre">session</span></code> is a wrapper of the C++ <codeclass="docutils literal"><spanclass="pre">Session</span></code> class. For more
information about <codeclass="docutils literal"><spanclass="pre">Session</span></code>, please
see <aclass="reference external"href="design/refactor/session.md">Design Doc: Session</a>.</p>
</div>
</div>
<divclass="section"id="paddlepaddle-converter">
<spanid="paddlepaddle-converter"></span><h3>PaddlePaddle Converter<aclass="headerlink"href="#paddlepaddle-converter"title="Permalink to this headline">¶</a></h3>
<p>PaddlePaddle converter automatically converts the IR in the request
(IR and evaluation inputs/targets) from PaddlePaddle Python to new
partitioned IRs and dispatch the new IRs and evaluation inputs/targets
to different PaddlePaddle runtimes. Below are the steps:</p>
<olclass="simple">
<li>Add <codeclass="docutils literal"><spanclass="pre">feed</span></code> OP that feeds the eval inputs, and <codeclass="docutils literal"><spanclass="pre">fetch</span></code> OP that
fetches the eval targets to the IR.</li>
<li>Extract a new computation (sub)graph with <codeclass="docutils literal"><spanclass="pre">feed</span></code> and <codeclass="docutils literal"><spanclass="pre">fetch</span></code> OP as
the boundary. The runtime does not need to run the OP that is not
dependent by the <codeclass="docutils literal"><spanclass="pre">fetch</span></code> OP.</li>
<li>Optimizes the computation graph.</li>
<li>Place the OPs in the graph onto different devices on different
PaddlePaddle runtime according to a placement algorithm and device
constraint specified by the user.</li>
<li>Partition the graph according to runtime boundaries and add <codeclass="docutils literal"><spanclass="pre">send</span></code> /
<codeclass="docutils literal"><spanclass="pre">recv</span></code> OP pair on the runtime boundaries.</li>
<li>Dispatch the partitioned graph to different PaddlePaddle runtimes.</li>
<li>PaddlePaddle runtimes with the <codeclass="docutils literal"><spanclass="pre">fetch</span></code> OP reports evaluation
results back to the converter, the convert reports the evaluation
results back to the PaddlePaddle Python.</li>
</ol>
<p>The output IRs will be cached to optimize the conversion latency.</p>
<divclass="section"id="placement-algorithm">
<spanid="placement-algorithm"></span><h4>Placement Algorithm<aclass="headerlink"href="#placement-algorithm"title="Permalink to this headline">¶</a></h4>
<p>Our first implementation will only support “trainer-parameter server”
placement: the parameters, initializers, and optimizers are placed on
the PaddlePaddle runtimes with the parameter server role. And
everything else will be placed on the PaddlePaddle runtimes with the
trainer role. This has the same functionality of our
“trainer-parameter server” architecture of PaddlePaddle v0.10.0, but
is more general and flexible.</p>
<p>In the future, we will implement the general placement algorithm,
which makes placements according to the input IR, and a model of
device computation time and device communication time. Model
parallelism requires the general placement algorithm.</p>
</div>
</div>
<divclass="section"id="paddlepaddle-runtime">
<spanid="paddlepaddle-runtime"></span><h3>PaddlePaddle Runtime<aclass="headerlink"href="#paddlepaddle-runtime"title="Permalink to this headline">¶</a></h3>
<p>The PaddlePaddle runtime owns multiple devices (e.g., CPUs, GPUs) and
runs the IR. The runtime does not need to do OP placement since it’s
<spanid="local-training-architecture"></span><h3>Local Training Architecture<aclass="headerlink"href="#local-training-architecture"title="Permalink to this headline">¶</a></h3>
<p>The local training architecture will be the same as the distributed
training architecture, the differences are everything runs locally,
and there is just one PaddlePaddle runtime:</p>
<p><imgsrc="src/local_architecture.png"/></p>
</div>
<divclass="section"id="training-data">
<spanid="training-data"></span><h3>Training Data<aclass="headerlink"href="#training-data"title="Permalink to this headline">¶</a></h3>
<p>In PaddlePaddle v0.10.0, training data is typically read
with <aclass="reference internal"href="../reader/README.html"><spanclass="doc">data reader</span></a> from Python. This approach is
no longer efficient when training distributedly since the Python
process no longer runs on the same node with the trainer processes,
the Python reader will need to read from the distributed filesystem
(assuming it has the access) and send to the trainers, doubling the
network traffic.</p>
<p>When doing distributed training, the user can still use Python data
reader: the training data are sent with <codeclass="docutils literal"><spanclass="pre">session.eval</span></code>. However should
be used for debugging purpose only. The users are encouraged to use
the read data OPs.</p>
</div>
</div>
<divclass="section"id="references">
<spanid="references"></span><h2>References:<aclass="headerlink"href="#references"title="Permalink to this headline">¶</a></h2>
<p>[1] <aclass="reference external"href="https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45166.pdf">TensorFlow: Large-Scale Machine Learning on Heterogeneous Distributed Systems</a></p>
<p>[2] <aclass="reference external"href="https://www.usenix.org/system/files/conference/osdi16/osdi16-abadi.pdf">TensorFlow: A System for Large-Scale Machine Learning</a></p>
Built with <ahref="http://sphinx-doc.org/">Sphinx</a> using a <ahref="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <ahref="https://readthedocs.org">Read the Docs</a>.
<spanid="design-doc-distributed-training-architecture"></span><h1>Design Doc: Distributed Training Architecture<aclass="headerlink"href="#design-doc-distributed-training-architecture"title="永久链接至标题">¶</a></h1>
<spanid="distributed-training-architecture"></span><h2>Distributed Training Architecture<aclass="headerlink"href="#distributed-training-architecture"title="永久链接至标题">¶</a></h2>
<p>The new distributed training architecture can address the above
<spanclass="nb">input</span><spanclass="o">=</span><spanclass="n">paddle</span><spanclass="o">.</span><spanclass="n">op</span><spanclass="o">.</span><spanclass="n">recordIO</span><spanclass="p">(</span><spanclass="s2">"/home/data/mnist.recordio"</span><spanclass="p">)</span><spanclass="c1"># file stored on the cluster</span>
<p>The code above is a typical Python trainer code, the neural network
topology is built using helper functions such as
<codeclass="docutils literal"><spanclass="pre">paddle.layer.fc</span></code>. The training is done by calling <codeclass="docutils literal"><spanclass="pre">session.eval</span></code>
<p>As shown in the graph, <codeclass="docutils literal"><spanclass="pre">session.eval</span></code> sends the IR and the evaluation
inputs/targets to the PaddlePaddle cluster for evaluation. The
targets can be any variable in the computation graph. When the target
is the <codeclass="docutils literal"><spanclass="pre">optimizer</span></code> variable, the neural network will be optimized
once. When the target is the <codeclass="docutils literal"><spanclass="pre">cost</span></code> variable, <codeclass="docutils literal"><spanclass="pre">session.eval</span></code> returns
the cost value.</p>
<p>The Python <codeclass="docutils literal"><spanclass="pre">session</span></code> is a wrapper of the C++ <codeclass="docutils literal"><spanclass="pre">Session</span></code> class. For more
information about <codeclass="docutils literal"><spanclass="pre">Session</span></code>, please
see <aclass="reference external"href="design/refactor/session.md">Design Doc: Session</a>.</p>
<p>PaddlePaddle converter automatically converts the IR in the request
(IR and evaluation inputs/targets) from PaddlePaddle Python to new
partitioned IRs and dispatch the new IRs and evaluation inputs/targets
to different PaddlePaddle runtimes. Below are the steps:</p>
<olclass="simple">
<li>Add <codeclass="docutils literal"><spanclass="pre">feed</span></code> OP that feeds the eval inputs, and <codeclass="docutils literal"><spanclass="pre">fetch</span></code> OP that
fetches the eval targets to the IR.</li>
<li>Extract a new computation (sub)graph with <codeclass="docutils literal"><spanclass="pre">feed</span></code> and <codeclass="docutils literal"><spanclass="pre">fetch</span></code> OP as
the boundary. The runtime does not need to run the OP that is not
dependent by the <codeclass="docutils literal"><spanclass="pre">fetch</span></code> OP.</li>
<li>Optimizes the computation graph.</li>
<li>Place the OPs in the graph onto different devices on different
PaddlePaddle runtime according to a placement algorithm and device
constraint specified by the user.</li>
<li>Partition the graph according to runtime boundaries and add <codeclass="docutils literal"><spanclass="pre">send</span></code> /
<codeclass="docutils literal"><spanclass="pre">recv</span></code> OP pair on the runtime boundaries.</li>
<li>Dispatch the partitioned graph to different PaddlePaddle runtimes.</li>
<li>PaddlePaddle runtimes with the <codeclass="docutils literal"><spanclass="pre">fetch</span></code> OP reports evaluation
results back to the converter, the convert reports the evaluation
results back to the PaddlePaddle Python.</li>
</ol>
<p>The output IRs will be cached to optimize the conversion latency.</p>
<spanid="local-training-architecture"></span><h3>Local Training Architecture<aclass="headerlink"href="#local-training-architecture"title="永久链接至标题">¶</a></h3>
<p>The local training architecture will be the same as the distributed
training architecture, the differences are everything runs locally,
<p>[1] <aclass="reference external"href="https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45166.pdf">TensorFlow: Large-Scale Machine Learning on Heterogeneous Distributed Systems</a></p>
<p>[2] <aclass="reference external"href="https://www.usenix.org/system/files/conference/osdi16/osdi16-abadi.pdf">TensorFlow: A System for Large-Scale Machine Learning</a></p>
Built with <ahref="http://sphinx-doc.org/">Sphinx</a> using a <ahref="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <ahref="https://readthedocs.org">Read the Docs</a>.
