From 275402bf2be3ab0386215c669bbc03f569141931 Mon Sep 17 00:00:00 2001 From: Mishig Davaadorj Date: Thu, 2 Dec 2021 09:01:35 +0100 Subject: [PATCH] Update doc img links (#14593) * Update doc img links * Rename toctree.yml -> _toctree.yml (#14594) * Update doc img links * Update performance.md img link --- docs/source/add_new_model.rst | 2 +- docs/source/model_summary.rst | 2 +- docs/source/parallelism.md | 20 ++++++++++---------- docs/source/performance.md | 2 +- docs/source/perplexity.rst | 6 +++--- 5 files changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/source/add_new_model.rst b/docs/source/add_new_model.rst index 7b1d1d495b..4ea8bcf1a8 100644 --- a/docs/source/add_new_model.rst +++ b/docs/source/add_new_model.rst @@ -72,7 +72,7 @@ call the model to be added to 🤗 Transformers ``BrandNewBert``. Let's take a look: -.. image:: ./imgs/transformers_overview.png +.. image:: /imgs/transformers_overview.png As you can see, we do make use of inheritance in 🤗 Transformers, but we keep the level of abstraction to an absolute minimum. There are never more than two levels of abstraction for any model in the library. :obj:`BrandNewBertModel` diff --git a/docs/source/model_summary.rst b/docs/source/model_summary.rst index b9f841fc0e..94572675be 100644 --- a/docs/source/model_summary.rst +++ b/docs/source/model_summary.rst @@ -877,7 +877,7 @@ Some preselected input tokens are also given global attention: for those few tok all tokens and this process is symmetric: all other tokens have access to those specific tokens (on top of the ones in their local window). This is shown in Figure 2d of the paper, see below for a sample attention mask: -.. image:: imgs/local_attention_mask.png +.. image:: /imgs/local_attention_mask.png :scale: 50 % :align: center diff --git a/docs/source/parallelism.md b/docs/source/parallelism.md index 2affe68f79..ce8ebaaf26 100644 --- a/docs/source/parallelism.md +++ b/docs/source/parallelism.md @@ -46,7 +46,7 @@ Most users with just 2 GPUs already enjoy the increased training speed up thanks ## ZeRO Data Parallel ZeRO-powered data parallelism (ZeRO-DP) is described on the following diagram from this [blog post](https://www.microsoft.com/en-us/research/blog/zero-deepspeed-new-system-optimizations-enable-training-models-with-over-100-billion-parameters/) -![DeepSpeed-Image-1](/transformers/_images/parallelism-zero.png) +![DeepSpeed-Image-1](/imgs/parallelism-zero.png) It can be difficult to wrap one's head around it, but in reality the concept is quite simple. This is just the usual DataParallel (DP), except, instead of replicating the full model params, gradients and optimizer states, each GPU stores only a slice of it. And then at run-time when the full layer params are needed just for the given layer, all GPUs synchronize to give each other parts that they miss - this is it. @@ -150,7 +150,7 @@ Pipeline Parallel (PP) is almost identical to a naive MP, but it solves the GPU The following illustration from the [GPipe paper](https://ai.googleblog.com/2019/03/introducing-gpipe-open-source-library.html) shows the naive MP on the top, and PP on the bottom: -![mp-pp](/transformers/_images/parallelism-gpipe-bubble.png) +![mp-pp](/imgs/parallelism-gpipe-bubble.png) It's easy to see from the bottom diagram how PP has less dead zones, where GPUs are idle. The idle parts are referred to as the "bubble". @@ -203,7 +203,7 @@ Implementations: Other approaches: DeepSpeed, Varuna and SageMaker use the concept of an [Interleaved Pipeline](https://docs.aws.amazon.com/sagemaker/latest/dg/model-parallel-core-features.html) -![interleaved-pipeline-execution](/transformers/_images/parallelism-sagemaker-interleaved-pipeline.png) +![interleaved-pipeline-execution](/imgs/parallelism-sagemaker-interleaved-pipeline.png) Here the bubble (idle time) is further minimized by prioritizing backward passes. @@ -221,16 +221,16 @@ The main building block of any transformer is a fully connected `nn.Linear` foll Following the Megatron's paper notation, we can write the dot-product part of it as `Y = GeLU(XA)`, where `X` and `Y` are the input and output vectors, and `A` is the weight matrix. If we look at the computation in matrix form, it's easy to see how the matrix multiplication can be split between multiple GPUs: -![Parallel GEMM](/transformers/_images/parallelism-tp-parallel_gemm.png) +![Parallel GEMM](/imgs/parallelism-tp-parallel_gemm.png) If we split the weight matrix `A` column-wise across `N` GPUs and perform matrix multiplications `XA_1` through `XA_n` in parallel, then we will end up with `N` output vectors `Y_1, Y_2, ..., Y_n` which can be fed into `GeLU` independently: -![independent GeLU](/transformers/_images/parallelism-tp-independent-gelu.png) +![independent GeLU](/imgs/parallelism-tp-independent-gelu.png) Using this principle, we can update an MLP of arbitrary depth, without the need for any synchronization between GPUs until the very end, where we need to reconstruct the output vector from shards. The Megatron-LM paper authors provide a helpful illustration for that: -![parallel shard processing](/transformers/_images/parallelism-tp-parallel_shard_processing.png) +![parallel shard processing](/imgs/parallelism-tp-parallel_shard_processing.png) Parallelizing the multi-headed attention layers is even simpler, since they are already inherently parallel, due to having multiple independent heads! -![parallel self-attention](/transformers/_images/parallelism-tp-parallel_self_attention.png) +![parallel self-attention](/imgs/parallelism-tp-parallel_self_attention.png) Special considerations: TP requires very fast network, and therefore it's not advisable to do TP across more than one node. Practically, if a node has 4 GPUs, the highest TP degree is therefore 4. If you need a TP degree of 8, you need to use nodes that have at least 8 GPUs. @@ -258,7 +258,7 @@ Implementations: The following diagram from the DeepSpeed [pipeline tutorial](https://www.deepspeed.ai/tutorials/pipeline/) demonstrates how one combines DP with PP. -![dp-pp-2d](/transformers/_images/parallelism-zero-dp-pp.png) +![dp-pp-2d](/imgs/parallelism-zero-dp-pp.png) Here it's important to see how DP rank 0 doesn't see GPU2 and DP rank 1 doesn't see GPU3. To DP there is just GPUs 0 and 1 where it feeds data as if there were just 2 GPUs. GPU0 "secretly" offloads some of its load to GPU2 using PP. And GPU1 does the same by enlisting GPU3 to its aid. @@ -277,7 +277,7 @@ Implementations: To get an even more efficient training a 3D parallelism is used where PP is combined with TP and DP. This can be seen in the following diagram. -![dp-pp-tp-3d](/transformers/_images/parallelism-deepspeed-3d.png) +![dp-pp-tp-3d](/imgs/parallelism-deepspeed-3d.png) This diagram is from a blog post [3D parallelism: Scaling to trillion-parameter models](https://www.microsoft.com/en-us/research/blog/deepspeed-extreme-scale-model-training-for-everyone/), which is a good read as well. @@ -342,7 +342,7 @@ We have 10 batches of 512 length. If we parallelize them by attribute dimension It is similar with tensor model parallelism or naive layer-wise model parallelism. -![flex-flow-soap](/transformers/_images/parallelism-flexflow.jpeg) +![flex-flow-soap](/imgs/parallelism-flexflow.jpeg) The significance of this framework is that it takes resources like (1) GPU/TPU/CPU vs. (2) RAM/DRAM vs. (3) fast-intra-connect/slow-inter-connect and it automatically optimizes all these algorithmically deciding which parallelisation to use where. diff --git a/docs/source/performance.md b/docs/source/performance.md index b835ce0046..51acea1732 100644 --- a/docs/source/performance.md +++ b/docs/source/performance.md @@ -225,7 +225,7 @@ Here are the commonly used floating point data types choice of which impacts bot Here is a diagram that shows how these data types correlate to each other. -![data types](/transformers/_images/tf32-bf16-fp16-fp32.png) +![data types](/imgs/tf32-bf16-fp16-fp32.png) (source: [NVIDIA Blog](https://developer.nvidia.com/blog/accelerating-ai-training-with-tf32-tensor-cores/)) diff --git a/docs/source/perplexity.rst b/docs/source/perplexity.rst index 2f7793fda5..e84e4b2af5 100644 --- a/docs/source/perplexity.rst +++ b/docs/source/perplexity.rst @@ -42,7 +42,7 @@ Calculating PPL with fixed-length models If we weren't limited by a model's context size, we would evaluate the model's perplexity by autoregressively factorizing a sequence and conditioning on the entire preceding subsequence at each step, as shown below. -.. image:: imgs/ppl_full.gif +.. image:: /imgs/ppl_full.gif :width: 600 :alt: Full decomposition of a sequence with unlimited context length @@ -56,7 +56,7 @@ input size is :math:`k`, we then approximate the likelihood of a token :math:`x_ sequence, a tempting but suboptimal approach is to break the sequence into disjoint chunks and add up the decomposed log-likelihoods of each segment independently. -.. image:: imgs/ppl_chunked.gif +.. image:: /imgs/ppl_chunked.gif :width: 600 :alt: Suboptimal PPL not taking advantage of full available context @@ -67,7 +67,7 @@ have less context at most of the prediction steps. Instead, the PPL of fixed-length models should be evaluated with a sliding-window strategy. This involves repeatedly sliding the context window so that the model has more context when making each prediction. -.. image:: imgs/ppl_sliding.gif +.. image:: /imgs/ppl_sliding.gif :width: 600 :alt: Sliding window PPL taking advantage of all available context