From 1bb63413552e30a9880ecf71c1320b6a3c41896d Mon Sep 17 00:00:00 2001 From: Aaron Jimenez Date: Fri, 17 May 2024 14:31:33 -0800 Subject: [PATCH 1/7] add model_memory_anatomy to es/_toctree.yml --- docs/source/es/_toctree.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/source/es/_toctree.yml b/docs/source/es/_toctree.yml index cf1ae39c03077e..5a20aca2e56a35 100644 --- a/docs/source/es/_toctree.yml +++ b/docs/source/es/_toctree.yml @@ -102,4 +102,6 @@ title: Perplejidad de los modelos de longitud fija - local: pipeline_webserver title: Flujo de trabajo para la inferencia de los servidores web + - local: model_memory_anatomy + title: Anatomía del entrenamiento de los modelos title: Guías conceptuales From bbd80340b217a246f9cc330297918794b0c994d4 Mon Sep 17 00:00:00 2001 From: Aaron Jimenez Date: Fri, 17 May 2024 14:32:38 -0800 Subject: [PATCH 2/7] copy model_memory_anatomy.md to es/ --- docs/source/es/model_memory_anatomy.md | 272 +++++++++++++++++++++++++ 1 file changed, 272 insertions(+) create mode 100644 docs/source/es/model_memory_anatomy.md diff --git a/docs/source/es/model_memory_anatomy.md b/docs/source/es/model_memory_anatomy.md new file mode 100644 index 00000000000000..1fc7b495932aff --- /dev/null +++ b/docs/source/es/model_memory_anatomy.md @@ -0,0 +1,272 @@ + + +# Model training anatomy + +To understand performance optimization techniques that one can apply to improve efficiency of model training +speed and memory utilization, it's helpful to get familiar with how GPU is utilized during training, and how compute +intensity varies depending on an operation performed. + +Let's start by exploring a motivating example of GPU utilization and the training run of a model. For the demonstration, +we'll need to install a few libraries: + +```bash +pip install transformers datasets accelerate nvidia-ml-py3 +``` + +The `nvidia-ml-py3` library allows us to monitor the memory usage of the models from within Python. You might be familiar +with the `nvidia-smi` command in the terminal - this library allows to access the same information in Python directly. + +Then, we create some dummy data: random token IDs between 100 and 30000 and binary labels for a classifier. +In total, we get 512 sequences each with length 512 and store them in a [`~datasets.Dataset`] with PyTorch format. + + +```py +>>> import numpy as np +>>> from datasets import Dataset + + +>>> seq_len, dataset_size = 512, 512 +>>> dummy_data = { +... "input_ids": np.random.randint(100, 30000, (dataset_size, seq_len)), +... "labels": np.random.randint(0, 1, (dataset_size)), +... } +>>> ds = Dataset.from_dict(dummy_data) +>>> ds.set_format("pt") +``` + +To print summary statistics for the GPU utilization and the training run with the [`Trainer`] we define two helper functions: + +```py +>>> from pynvml import * + + +>>> def print_gpu_utilization(): +... nvmlInit() +... handle = nvmlDeviceGetHandleByIndex(0) +... info = nvmlDeviceGetMemoryInfo(handle) +... print(f"GPU memory occupied: {info.used//1024**2} MB.") + + +>>> def print_summary(result): +... print(f"Time: {result.metrics['train_runtime']:.2f}") +... print(f"Samples/second: {result.metrics['train_samples_per_second']:.2f}") +... print_gpu_utilization() +``` + +Let's verify that we start with a free GPU memory: + +```py +>>> print_gpu_utilization() +GPU memory occupied: 0 MB. +``` + +That looks good: the GPU memory is not occupied as we would expect before we load any models. If that's not the case on +your machine make sure to stop all processes that are using GPU memory. However, not all free GPU memory can be used by +the user. When a model is loaded to the GPU the kernels are also loaded, which can take up 1-2GB of memory. To see how +much it is we load a tiny tensor into the GPU which triggers the kernels to be loaded as well. + +```py +>>> import torch + + +>>> torch.ones((1, 1)).to("cuda") +>>> print_gpu_utilization() +GPU memory occupied: 1343 MB. +``` + +We see that the kernels alone take up 1.3GB of GPU memory. Now let's see how much space the model uses. + +## Load Model + +First, we load the `google-bert/bert-large-uncased` model. We load the model weights directly to the GPU so that we can check +how much space just the weights use. + + +```py +>>> from transformers import AutoModelForSequenceClassification + + +>>> model = AutoModelForSequenceClassification.from_pretrained("google-bert/bert-large-uncased").to("cuda") +>>> print_gpu_utilization() +GPU memory occupied: 2631 MB. +``` + +We can see that the model weights alone take up 1.3 GB of GPU memory. The exact number depends on the specific +GPU you are using. Note that on newer GPUs a model can sometimes take up more space since the weights are loaded in an +optimized fashion that speeds up the usage of the model. Now we can also quickly check if we get the same result +as with `nvidia-smi` CLI: + + +```bash +nvidia-smi +``` + +```bash +Tue Jan 11 08:58:05 2022 ++-----------------------------------------------------------------------------+ +| NVIDIA-SMI 460.91.03 Driver Version: 460.91.03 CUDA Version: 11.2 | +|-------------------------------+----------------------+----------------------+ +| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | +| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | +| | | MIG M. | +|===============================+======================+======================| +| 0 Tesla V100-SXM2... On | 00000000:00:04.0 Off | 0 | +| N/A 37C P0 39W / 300W | 2631MiB / 16160MiB | 0% Default | +| | | N/A | ++-------------------------------+----------------------+----------------------+ + ++-----------------------------------------------------------------------------+ +| Processes: | +| GPU GI CI PID Type Process name GPU Memory | +| ID ID Usage | +|=============================================================================| +| 0 N/A N/A 3721 C ...nvs/codeparrot/bin/python 2629MiB | ++-----------------------------------------------------------------------------+ +``` + +We get the same number as before and you can also see that we are using a V100 GPU with 16GB of memory. So now we can +start training the model and see how the GPU memory consumption changes. First, we set up a few standard training +arguments: + +```py +default_args = { + "output_dir": "tmp", + "eval_strategy": "steps", + "num_train_epochs": 1, + "log_level": "error", + "report_to": "none", +} +``` + + + + If you plan to run multiple experiments, in order to properly clear the memory between experiments, restart the Python + kernel between experiments. + + + +## Memory utilization at vanilla training + +Let's use the [`Trainer`] and train the model without using any GPU performance optimization techniques and a batch size of 4: + +```py +>>> from transformers import TrainingArguments, Trainer, logging + +>>> logging.set_verbosity_error() + + +>>> training_args = TrainingArguments(per_device_train_batch_size=4, **default_args) +>>> trainer = Trainer(model=model, args=training_args, train_dataset=ds) +>>> result = trainer.train() +>>> print_summary(result) +``` + +``` +Time: 57.82 +Samples/second: 8.86 +GPU memory occupied: 14949 MB. +``` + +We see that already a relatively small batch size almost fills up our GPU's entire memory. However, a larger batch size +can often result in faster model convergence or better end performance. So ideally we want to tune the batch size to our +model's needs and not to the GPU limitations. What's interesting is that we use much more memory than the size of the model. +To understand a bit better why this is the case let's have a look at a model's operations and memory needs. + +## Anatomy of Model's Operations + +Transformers architecture includes 3 main groups of operations grouped below by compute-intensity. + +1. **Tensor Contractions** + + Linear layers and components of Multi-Head Attention all do batched **matrix-matrix multiplications**. These operations are the most compute-intensive part of training a transformer. + +2. **Statistical Normalizations** + + Softmax and layer normalization are less compute-intensive than tensor contractions, and involve one or more **reduction operations**, the result of which is then applied via a map. + +3. **Element-wise Operators** + + These are the remaining operators: **biases, dropout, activations, and residual connections**. These are the least compute-intensive operations. + +This knowledge can be helpful to know when analyzing performance bottlenecks. + +This summary is derived from [Data Movement Is All You Need: A Case Study on Optimizing Transformers 2020](https://arxiv.org/abs/2007.00072) + + +## Anatomy of Model's Memory + +We've seen that training the model uses much more memory than just putting the model on the GPU. This is because there +are many components during training that use GPU memory. The components on GPU memory are the following: + +1. model weights +2. optimizer states +3. gradients +4. forward activations saved for gradient computation +5. temporary buffers +6. functionality-specific memory + +A typical model trained in mixed precision with AdamW requires 18 bytes per model parameter plus activation memory. For +inference there are no optimizer states and gradients, so we can subtract those. And thus we end up with 6 bytes per +model parameter for mixed precision inference, plus activation memory. + +Let's look at the details. + +**Model Weights:** + +- 4 bytes * number of parameters for fp32 training +- 6 bytes * number of parameters for mixed precision training (maintains a model in fp32 and one in fp16 in memory) + +**Optimizer States:** + +- 8 bytes * number of parameters for normal AdamW (maintains 2 states) +- 2 bytes * number of parameters for 8-bit AdamW optimizers like [bitsandbytes](https://github.com/TimDettmers/bitsandbytes) +- 4 bytes * number of parameters for optimizers like SGD with momentum (maintains only 1 state) + +**Gradients** + +- 4 bytes * number of parameters for either fp32 or mixed precision training (gradients are always kept in fp32) + +**Forward Activations** + +- size depends on many factors, the key ones being sequence length, hidden size and batch size. + +There are the input and output that are being passed and returned by the forward and the backward functions and the +forward activations saved for gradient computation. + +**Temporary Memory** + +Additionally, there are all kinds of temporary variables which get released once the calculation is done, but in the +moment these could require additional memory and could push to OOM. Therefore, when coding it's crucial to think +strategically about such temporary variables and sometimes to explicitly free those as soon as they are no longer needed. + +**Functionality-specific memory** + +Then, your software could have special memory needs. For example, when generating text using beam search, the software +needs to maintain multiple copies of inputs and outputs. + +**`forward` vs `backward` Execution Speed** + +For convolutions and linear layers there are 2x flops in the backward compared to the forward, which generally translates +into ~2x slower (sometimes more, because sizes in the backward tend to be more awkward). Activations are usually +bandwidth-limited, and it’s typical for an activation to have to read more data in the backward than in the forward +(e.g. activation forward reads once, writes once, activation backward reads twice, gradOutput and output of the forward, +and writes once, gradInput). + +As you can see, there are potentially a few places where we could save GPU memory or speed up operations. +Now that you understand what affects GPU utilization and computation speed, refer to +the [Methods and tools for efficient training on a single GPU](perf_train_gpu_one) documentation page to learn about +performance optimization techniques. From 6f813da5b65a026a920d41ce039b3a55d87e1c98 Mon Sep 17 00:00:00 2001 From: Aaron Jimenez Date: Fri, 17 May 2024 15:10:45 -0800 Subject: [PATCH 3/7] translate first section --- docs/source/es/model_memory_anatomy.md | 45 ++++++++------------------ 1 file changed, 14 insertions(+), 31 deletions(-) diff --git a/docs/source/es/model_memory_anatomy.md b/docs/source/es/model_memory_anatomy.md index 1fc7b495932aff..f7076b9b775e9a 100644 --- a/docs/source/es/model_memory_anatomy.md +++ b/docs/source/es/model_memory_anatomy.md @@ -14,24 +14,19 @@ See the License for the specific language governing permissions and limitations under the License. --> -# Model training anatomy +# Anatomía del entrenamiento de los modelos -To understand performance optimization techniques that one can apply to improve efficiency of model training -speed and memory utilization, it's helpful to get familiar with how GPU is utilized during training, and how compute -intensity varies depending on an operation performed. +Para entender las técnicas de optimización del rendimiento que se pueden aplicar para mejorar la eficiencia en la velocidad del entrenamiento de los modelos y la utilización de la memoria, es útil familiarizarse con cómo se utiliza la GPU durante el entrenamiento y cómo varía la intensidad de cálculo según la operación realizada. -Let's start by exploring a motivating example of GPU utilization and the training run of a model. For the demonstration, -we'll need to install a few libraries: +Empecemos explorando un ejemplo enfocado en la utilización de la GPU y la ejecución del entrenamiento de un modelo. Para la demostración, necesitaremos instalar algunas bibliotecas: ```bash pip install transformers datasets accelerate nvidia-ml-py3 ``` -The `nvidia-ml-py3` library allows us to monitor the memory usage of the models from within Python. You might be familiar -with the `nvidia-smi` command in the terminal - this library allows to access the same information in Python directly. +La biblioteca `nvidia-ml-py3` nos permite monitorear la utilización de memoria de los modelos desde Python. Es posible que estés familiarizado con el comando `nvidia-smi` en la terminal, esta biblioteca nos permite acceder a la misma información en Python directamente. -Then, we create some dummy data: random token IDs between 100 and 30000 and binary labels for a classifier. -In total, we get 512 sequences each with length 512 and store them in a [`~datasets.Dataset`] with PyTorch format. +Luego, creamos algunos datos ficticios: IDs de tokens aleatorios entre 100 y 30000 y etiquetas binarias para un clasificador. En total, obtenemos 512 secuencias cada una con longitud 512 y las almacenamos en un [`~datasets.Dataset`] con formato PyTorch. ```py @@ -48,7 +43,7 @@ In total, we get 512 sequences each with length 512 and store them in a [`~datas >>> ds.set_format("pt") ``` -To print summary statistics for the GPU utilization and the training run with the [`Trainer`] we define two helper functions: +Para imprimir estadísticas resumidas para la utilización de la GPU y la ejecución del entrenamiento con [`Trainer`], definimos dos funciones auxiliares: ```py >>> from pynvml import * @@ -67,17 +62,14 @@ To print summary statistics for the GPU utilization and the training run with th ... print_gpu_utilization() ``` -Let's verify that we start with a free GPU memory: +Comencemos comprobando que la memoria GPU este libre: ```py >>> print_gpu_utilization() GPU memory occupied: 0 MB. ``` -That looks good: the GPU memory is not occupied as we would expect before we load any models. If that's not the case on -your machine make sure to stop all processes that are using GPU memory. However, not all free GPU memory can be used by -the user. When a model is loaded to the GPU the kernels are also loaded, which can take up 1-2GB of memory. To see how -much it is we load a tiny tensor into the GPU which triggers the kernels to be loaded as well. +Parece estar bien: la memoria de la GPU no está ocupada como esperaríamos antes de cargar cualquier modelo. Si no es el caso en tu máquina, asegúrate de detener todos los procesos que estén utilizando la memoria de la GPU. Sin embargo, no toda la memoria libre de la GPU puede ser utilizada por el usuario. Cuando se carga un modelo en la GPU, también se cargan los kernels, lo que puede ocupar 1-2GB de memoria. Para ver cuánta es, cargemos un tensor diminuto en la GPU, lo que también desencadena la carga de los kernels. ```py >>> import torch @@ -88,13 +80,11 @@ much it is we load a tiny tensor into the GPU which triggers the kernels to be l GPU memory occupied: 1343 MB. ``` -We see that the kernels alone take up 1.3GB of GPU memory. Now let's see how much space the model uses. +Vemos que los kernels solos ocupan 1,3GB de memoria de la GPU. Ahora, veamos cuánto espacio ocupa el modelo. -## Load Model - -First, we load the `google-bert/bert-large-uncased` model. We load the model weights directly to the GPU so that we can check -how much space just the weights use. +## Cargar el Modelo +Primero, cargamos el modelo `google-bert/bert-large-uncased`. Los pesos del modelo son cargados directamente en la GPU para que podamos verificar cuánto espacio ocupan solo los pesos. ```py >>> from transformers import AutoModelForSequenceClassification @@ -105,11 +95,7 @@ how much space just the weights use. GPU memory occupied: 2631 MB. ``` -We can see that the model weights alone take up 1.3 GB of GPU memory. The exact number depends on the specific -GPU you are using. Note that on newer GPUs a model can sometimes take up more space since the weights are loaded in an -optimized fashion that speeds up the usage of the model. Now we can also quickly check if we get the same result -as with `nvidia-smi` CLI: - +Podemos ver que los pesos del modelo solos ocupan 1,3 GB de memoria de la GPU. El número exacto depende de la GPU específica que estés utilizando. Ten en cuenta que en GPUs más modernas, un modelo puede ocupar más espacio ya que los pesos se cargan de manera optimizada lo cual acelera el uso del modelo. Ahora también podemos verificar rápidamente si obtenemos el mismo resultado que con la CLI de `nvidia-smi`: ```bash nvidia-smi @@ -138,9 +124,7 @@ Tue Jan 11 08:58:05 2022 +-----------------------------------------------------------------------------+ ``` -We get the same number as before and you can also see that we are using a V100 GPU with 16GB of memory. So now we can -start training the model and see how the GPU memory consumption changes. First, we set up a few standard training -arguments: +Obtenemos el mismo número que antes y también puedes ver que estamos utilizando una GPU V100 con 16GB de memoria. Ahora podemos empezar a entrenar el modelo y ver cómo cambia el consumo de memoria de la GPU. Primero, configuramos algunos argumentos de entrenamiento estándar: ```py default_args = { @@ -154,8 +138,7 @@ default_args = { - If you plan to run multiple experiments, in order to properly clear the memory between experiments, restart the Python - kernel between experiments. +Si planeas ejecutar varias pruebas, reinicie el kernel de Python entre cada prueba para borrar correctamente la memoria. From 6405abd3c6b955f7fc50a0c88ad21a52d5778457 Mon Sep 17 00:00:00 2001 From: Aaron Jimenez Date: Fri, 17 May 2024 16:04:26 -0800 Subject: [PATCH 4/7] translate doc --- docs/source/es/model_memory_anatomy.md | 100 +++++++++++-------------- 1 file changed, 42 insertions(+), 58 deletions(-) diff --git a/docs/source/es/model_memory_anatomy.md b/docs/source/es/model_memory_anatomy.md index f7076b9b775e9a..10eaf85f9daea9 100644 --- a/docs/source/es/model_memory_anatomy.md +++ b/docs/source/es/model_memory_anatomy.md @@ -142,9 +142,9 @@ Si planeas ejecutar varias pruebas, reinicie el kernel de Python entre cada prue -## Memory utilization at vanilla training +## Utilización de la memoria en el entrenamiento -Let's use the [`Trainer`] and train the model without using any GPU performance optimization techniques and a batch size of 4: +Vamos a utilizar el [`Trainer`] y entrenar el modelo sin utilizar ninguna técnica de optimización del rendimiento de la GPU y un tamaño de lote de 4: ```py >>> from transformers import TrainingArguments, Trainer, logging @@ -164,92 +164,76 @@ Samples/second: 8.86 GPU memory occupied: 14949 MB. ``` -We see that already a relatively small batch size almost fills up our GPU's entire memory. However, a larger batch size -can often result in faster model convergence or better end performance. So ideally we want to tune the batch size to our -model's needs and not to the GPU limitations. What's interesting is that we use much more memory than the size of the model. -To understand a bit better why this is the case let's have a look at a model's operations and memory needs. +Vemos que incluso un tamaño de lote relativamente pequeño casi llena toda la memoria de nuestra GPU. Sin embargo, un tamaño de lote más grande a menudo puede resultar en una convergencia del modelo más rápida o un mejor rendimiento final. Así que idealmente queremos ajustar el tamaño del lote a las necesidades del modelo y no a las limitaciones de la GPU. Lo interesante es que utilizamos mucha más memoria que el tamaño del modelo. +Para entender un poco mejor por qué es el caso, echemos un vistazo a las operaciones y necesidades de memoria de un modelo. -## Anatomy of Model's Operations +## Anatomía de las Operaciones del Modelo -Transformers architecture includes 3 main groups of operations grouped below by compute-intensity. +La arquitectura de los transformers incluye 3 grupos principales de operaciones agrupadas a continuación por intensidad de cálculo. -1. **Tensor Contractions** +1. **Contracciones de Tensores** - Linear layers and components of Multi-Head Attention all do batched **matrix-matrix multiplications**. These operations are the most compute-intensive part of training a transformer. + Las capas lineales y componentes de la Atención Multi-Head realizan **multiplicaciones matriciales por lotes**. Estas operaciones son la parte más intensiva en cálculo del entrenamiento de los transformers. -2. **Statistical Normalizations** +2. **Normalizaciones Estadísticas** - Softmax and layer normalization are less compute-intensive than tensor contractions, and involve one or more **reduction operations**, the result of which is then applied via a map. + Softmax y normalización de capas son menos intensivas en cálculo que las contracciones de tensores, e implican una o más **operaciones de reducción**, cuyo resultado se aplica luego mediante un mapa. -3. **Element-wise Operators** +3. **Operadores por Elemento** - These are the remaining operators: **biases, dropout, activations, and residual connections**. These are the least compute-intensive operations. + Estos son los operadores restantes: **sesgos, dropout, activaciones y conexiones residuales**. Estas son las operaciones menos intensivas en cálculo. -This knowledge can be helpful to know when analyzing performance bottlenecks. +Este conocimiento puede ser útil al analizar cuellos de botella de rendimiento. -This summary is derived from [Data Movement Is All You Need: A Case Study on Optimizing Transformers 2020](https://arxiv.org/abs/2007.00072) +Este resumen se deriva de [Data Movement Is All You Need: A Case Study on Optimizing Transformers 2020](https://arxiv.org/abs/2007.00072) -## Anatomy of Model's Memory +## Anatomía de la Memoria del Modelo -We've seen that training the model uses much more memory than just putting the model on the GPU. This is because there -are many components during training that use GPU memory. The components on GPU memory are the following: +Hemos visto que al entrenar un modelo se utiliza mucha más memoria que solo poner el modelo en la GPU. Esto se debe a que hay muchos componentes durante el entrenamiento que utilizan memoria de la GPU. Los componentes en memoria de la GPU son los siguientes: -1. model weights -2. optimizer states -3. gradients -4. forward activations saved for gradient computation -5. temporary buffers -6. functionality-specific memory +1. pesos del modelo +2. estados del optimizador +3. gradientes +4. forward activations guardadas para el cálculo del gradiente +5. buffers temporales +6. memoria específica de funcionalidad -A typical model trained in mixed precision with AdamW requires 18 bytes per model parameter plus activation memory. For -inference there are no optimizer states and gradients, so we can subtract those. And thus we end up with 6 bytes per -model parameter for mixed precision inference, plus activation memory. +Un modelo típico entrenado en precisión mixta con AdamW requiere 18 bytes por parámetro del modelo más memoria de activación. Para la inferencia no hay estados del optimizador ni gradientes, por lo que podemos restarlos. Y así terminamos con 6 bytes por parámetro del modelo para la inferencia en precisión mixta, más la memoria de activación. -Let's look at the details. +Veámoslo a detalle: -**Model Weights:** +**Pesos del Modelo:** -- 4 bytes * number of parameters for fp32 training -- 6 bytes * number of parameters for mixed precision training (maintains a model in fp32 and one in fp16 in memory) +- 4 bytes por número de parámetros para entrenamiento en fp32 +- 6 bytes por número de parámetros para entrenamiento en precisión mixta (mantiene un modelo en fp32 y uno en fp16 en memoria) -**Optimizer States:** +**Estados del Optimizador:** -- 8 bytes * number of parameters for normal AdamW (maintains 2 states) -- 2 bytes * number of parameters for 8-bit AdamW optimizers like [bitsandbytes](https://github.com/TimDettmers/bitsandbytes) -- 4 bytes * number of parameters for optimizers like SGD with momentum (maintains only 1 state) +- 8 bytes por número de parámetros para un AdamW normal (mantiene 2 estados) +- 2 bytes por número de parámetros para optimizadores de 8 bits como [bitsandbytes](https://github.com/TimDettmers/bitsandbytes) +- 4 bytes por número de parámetros para optimizadores como SGD con momentum (mantiene solo 1 estado) -**Gradients** +**Gradientes** -- 4 bytes * number of parameters for either fp32 or mixed precision training (gradients are always kept in fp32) +- 4 bytes por número de parámetros para entrenamiento en fp32 o precisión mixta (los gradientes siempre se mantienen en fp32) **Forward Activations** -- size depends on many factors, the key ones being sequence length, hidden size and batch size. +- El tamaño depende de muchos factores, los principales siendo la longitud de la secuencia, el tamaño oculto y el tamaño de lote. -There are the input and output that are being passed and returned by the forward and the backward functions and the -forward activations saved for gradient computation. +Hay entradas y salidas que se pasan y se devuelven por las funciones hacia adelante y hacia atrás, y las activaciones hacia adelante (*forward activations*) guardadas para el cálculo de gradientes. -**Temporary Memory** +**Memoria Temporal** -Additionally, there are all kinds of temporary variables which get released once the calculation is done, but in the -moment these could require additional memory and could push to OOM. Therefore, when coding it's crucial to think -strategically about such temporary variables and sometimes to explicitly free those as soon as they are no longer needed. +Además, hay todas clases de variables temporales que se liberan una vez que se completa el cálculo, pero en el momento podrían requerir memoria adicional y podrían provocar un error de memoria insuficiente. Por lo tanto, al codificar es crucial pensar estratégicamente sobre tales variables temporales y a veces liberarlas explícitamente tan pronto como ya no se necesitan. -**Functionality-specific memory** +**Memoria Específica de Funcionalidad** -Then, your software could have special memory needs. For example, when generating text using beam search, the software -needs to maintain multiple copies of inputs and outputs. +Entonces, su software podría tener necesidades especiales de memoria. Por ejemplo, al generar texto mediante la búsqueda por haz, el software necesita mantener múltiples copias de las entradas y salidas. -**`forward` vs `backward` Execution Speed** +**Velocidad de Ejecución `forward` vs `backward`** -For convolutions and linear layers there are 2x flops in the backward compared to the forward, which generally translates -into ~2x slower (sometimes more, because sizes in the backward tend to be more awkward). Activations are usually -bandwidth-limited, and it’s typical for an activation to have to read more data in the backward than in the forward -(e.g. activation forward reads once, writes once, activation backward reads twice, gradOutput and output of the forward, -and writes once, gradInput). +Para convoluciones y capas lineales, hay 2x flops en la ejecución hacia atrás (`backward`) en comparación con la ejecución hacia adelante (`forward`), lo que generalmente se traduce en ~2x más lento (a veces más, porque los tamaños en la ejecución hacia atrás tienden a ser más complejos). Las activaciones suelen ser limitadas por ancho de banda, y es típico que una activación tenga que leer más datos en la ejecución hacia atrás que en la ejecución hacia adelante (por ejemplo, la activación hacia adelante lee una vez, escribe una vez, la activación hacia atrás lee dos veces, gradOutput y salida de la ejecución hacia adelante, y escribe una vez, gradInput). -As you can see, there are potentially a few places where we could save GPU memory or speed up operations. -Now that you understand what affects GPU utilization and computation speed, refer to -the [Methods and tools for efficient training on a single GPU](perf_train_gpu_one) documentation page to learn about -performance optimization techniques. +Como puedes ver, hay potencialmente unos pocos lugares donde podríamos ahorrar memoria de la GPU o acelerar operaciones. Ahora que entiendes qué afecta la utilización de la GPU y la velocidad de cálculo, consulta la página de documentación [Métodos y herramientas para entrenamiento eficiente en una sola GPU](https://huggingface.co/docs/transformers/perf_train_gpu_one) para aprender sobre técnicas de optimización del rendimiento. From 8ea0add0f8b12476593222794e3da4f3c4f2039d Mon Sep 17 00:00:00 2001 From: Aaron Jimenez Date: Fri, 17 May 2024 16:16:15 -0800 Subject: [PATCH 5/7] chage forward activations --- docs/source/es/model_memory_anatomy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/source/es/model_memory_anatomy.md b/docs/source/es/model_memory_anatomy.md index 10eaf85f9daea9..16b40b68c346c1 100644 --- a/docs/source/es/model_memory_anatomy.md +++ b/docs/source/es/model_memory_anatomy.md @@ -195,7 +195,7 @@ Hemos visto que al entrenar un modelo se utiliza mucha más memoria que solo pon 1. pesos del modelo 2. estados del optimizador 3. gradientes -4. forward activations guardadas para el cálculo del gradiente +4. activaciones hacia adelante guardadas para el cálculo del gradiente 5. buffers temporales 6. memoria específica de funcionalidad @@ -218,11 +218,11 @@ Veámoslo a detalle: - 4 bytes por número de parámetros para entrenamiento en fp32 o precisión mixta (los gradientes siempre se mantienen en fp32) -**Forward Activations** +**Activaciones hacia Adelante** - El tamaño depende de muchos factores, los principales siendo la longitud de la secuencia, el tamaño oculto y el tamaño de lote. -Hay entradas y salidas que se pasan y se devuelven por las funciones hacia adelante y hacia atrás, y las activaciones hacia adelante (*forward activations*) guardadas para el cálculo de gradientes. +Hay entradas y salidas que se pasan y se devuelven por las funciones hacia adelante y hacia atrás, y las activaciones hacia adelante (*forward activations*) guardadas para el cálculo del gradiente. **Memoria Temporal** From a7abcd593567f6cd15e5ac31743439ffbb5da576 Mon Sep 17 00:00:00 2001 From: Aaron Jimenez Date: Sat, 18 May 2024 19:50:21 -0800 Subject: [PATCH 6/7] fix sentence and and link to Trainer --- docs/source/es/model_memory_anatomy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/source/es/model_memory_anatomy.md b/docs/source/es/model_memory_anatomy.md index 16b40b68c346c1..0785594aa85ce4 100644 --- a/docs/source/es/model_memory_anatomy.md +++ b/docs/source/es/model_memory_anatomy.md @@ -43,7 +43,7 @@ Luego, creamos algunos datos ficticios: IDs de tokens aleatorios entre 100 y 300 >>> ds.set_format("pt") ``` -Para imprimir estadísticas resumidas para la utilización de la GPU y la ejecución del entrenamiento con [`Trainer`], definimos dos funciones auxiliares: +Para imprimir estadísticas resumidas para la utilización de la GPU y la ejecución del entrenamiento con [`Trainer`](https://huggingface.co/docs/transformers/v4.41.0/en/main_classes/trainer#transformers.Trainer), definimos dos funciones auxiliares: ```py >>> from pynvml import * @@ -69,7 +69,7 @@ Comencemos comprobando que la memoria GPU este libre: GPU memory occupied: 0 MB. ``` -Parece estar bien: la memoria de la GPU no está ocupada como esperaríamos antes de cargar cualquier modelo. Si no es el caso en tu máquina, asegúrate de detener todos los procesos que estén utilizando la memoria de la GPU. Sin embargo, no toda la memoria libre de la GPU puede ser utilizada por el usuario. Cuando se carga un modelo en la GPU, también se cargan los kernels, lo que puede ocupar 1-2GB de memoria. Para ver cuánta es, cargemos un tensor diminuto en la GPU, lo que también desencadena la carga de los kernels. +Parece estar bien: la memoria de la GPU no está ocupada como esperaríamos antes de cargar cualquier modelo. Si no es el caso en tu máquina, asegúrate de detener todos los procesos que estén utilizando la memoria de la GPU. Sin embargo, no toda la memoria libre de la GPU puede ser utilizada por el usuario. Cuando se carga un modelo en la GPU, también se cargan los kernels, lo que puede ocupar 1-2GB de memoria. Para ver cuánta memoria será ocupada por defecto, cargemos un tensor diminuto en la GPU, lo que también desencadena la carga de los kernels. ```py >>> import torch @@ -144,7 +144,7 @@ Si planeas ejecutar varias pruebas, reinicie el kernel de Python entre cada prue ## Utilización de la memoria en el entrenamiento -Vamos a utilizar el [`Trainer`] y entrenar el modelo sin utilizar ninguna técnica de optimización del rendimiento de la GPU y un tamaño de lote de 4: +Vamos a utilizar el [`Trainer`](https://huggingface.co/docs/transformers/v4.41.0/en/main_classes/trainer#transformers.Trainer) y entrenar el modelo sin utilizar ninguna técnica de optimización del rendimiento de la GPU y un tamaño de lote de 4: ```py >>> from transformers import TrainingArguments, Trainer, logging From d2966ccf61395d168c5e4ff88090ddfe0c6e1c24 Mon Sep 17 00:00:00 2001 From: Aaron Jimenez Date: Mon, 20 May 2024 13:58:55 -0800 Subject: [PATCH 7/7] fix Trainer link --- docs/source/es/model_memory_anatomy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/source/es/model_memory_anatomy.md b/docs/source/es/model_memory_anatomy.md index 0785594aa85ce4..6a220da993dba3 100644 --- a/docs/source/es/model_memory_anatomy.md +++ b/docs/source/es/model_memory_anatomy.md @@ -43,7 +43,7 @@ Luego, creamos algunos datos ficticios: IDs de tokens aleatorios entre 100 y 300 >>> ds.set_format("pt") ``` -Para imprimir estadísticas resumidas para la utilización de la GPU y la ejecución del entrenamiento con [`Trainer`](https://huggingface.co/docs/transformers/v4.41.0/en/main_classes/trainer#transformers.Trainer), definimos dos funciones auxiliares: +Para imprimir estadísticas resumidas para la utilización de la GPU y la ejecución del entrenamiento con [`Trainer`](https://huggingface.co/docs/transformers/en/main_classes/trainer#transformers.Trainer), definimos dos funciones auxiliares: ```py >>> from pynvml import * @@ -144,7 +144,7 @@ Si planeas ejecutar varias pruebas, reinicie el kernel de Python entre cada prue ## Utilización de la memoria en el entrenamiento -Vamos a utilizar el [`Trainer`](https://huggingface.co/docs/transformers/v4.41.0/en/main_classes/trainer#transformers.Trainer) y entrenar el modelo sin utilizar ninguna técnica de optimización del rendimiento de la GPU y un tamaño de lote de 4: +Vamos a utilizar el [`Trainer`](https://huggingface.co/docs/transformers/en/main_classes/trainer#transformers.Trainer) y entrenar el modelo sin utilizar ninguna técnica de optimización del rendimiento de la GPU y un tamaño de lote de 4: ```py >>> from transformers import TrainingArguments, Trainer, logging