Transitioning from standard 32-bit precision ( $FP32$ ) to lower-precision formats like 16-bit floating-point ( $FP16$ ) or bfloat16 ( $BF16$ ) offers compelling advantages, primarily revolving around reduced memory consumption and increased computational throughput. These benefits are particularly significant when training large language models, where resource constraints are often the main bottleneck.

Memory Reduction

The most direct benefit of using 16-bit formats is the substantial reduction in memory requirements. Both $FP16$ and $BF16$ use 16 bits to represent a number, exactly half the 32 bits used by standard single-precision floats ( $FP32$ ).

This halving of memory applies to several main components during training:

Model Parameters: The weights and biases of the neural network. For a model with billions of parameters, this directly translates to gigabytes of saved GPU memory.
Gradients: During backpropagation, gradients computed for each parameter have the same dimensions as the parameters themselves. Storing these in a 16-bit format halves their memory footprint.
Optimizer States: Optimizers like Adam or AdamW maintain state, such as momentum and variance estimates, for each parameter. For Adam/AdamW, this typically involves storing two additional values per parameter. Using 16-bit formats for these states (where applicable and numerically safe) further reduces memory usage.
Activations: The intermediate outputs of layers computed during the forward pass must often be stored for the backward pass. Storing these activations in $FP16$ or $BF16$ can significantly decrease the memory required, especially for models with large activation tensors or long sequence lengths.

Consider a single parameter stored in $FP32$ versus $FP16$ :

import torch

# A single parameter value in FP32
param_fp32 = torch.tensor(3.14159, dtype=torch.float32)
size_fp32 = param_fp32.element_size()
print(f"FP32 Parameter Size: {size_fp32} bytes") # Output: 4 bytes

# The same parameter value potentially stored in FP16
# Note: Actual conversion might lose precision
param_fp16 = param_fp32.to(torch.float16)
size_fp16 = param_fp16.element_size()
print(f"FP16 Parameter Size: {size_fp16} bytes") # Output: 2 bytes

# Or in BF16
param_bf16 = param_fp32.to(torch.bfloat16)
size_bf16 = param_bf16.element_size()
print(f"BF16 Parameter Size: {size_bf16} bytes") # Output: 2 bytes

For a model with 10 billion parameters, switching the parameters alone from $FP32$ to a 16-bit format saves approximately $10 \times 10^9 \times (4 - 2) = 20$ gigabytes of memory. When accounting for gradients and optimizer states (which can double or triple the memory required for parameters), the total savings become even more substantial.

This memory reduction allows practitioners to:

Train significantly larger models on the same hardware configuration.
Increase the batch size for training, potentially improving training stability and throughput.
Reduce the degree of model parallelism required, simplifying the distributed training setup.

Relative memory consumption for main training components when using $FP32$ compared to $FP16$ or $BF16$ . Optimizer states for Adam/AdamW typically require twice the memory of the parameters themselves.

Computational Speedup

Lower precision often translates to faster computation, especially on modern hardware accelerators like GPUs and TPUs equipped with specialized processing units.

Hardware Acceleration: NVIDIA GPUs feature Tensor Cores, and Google TPUs have Matrix Multiply Units (MXUs), both designed to perform matrix multiplications at high speed using mixed precision. Tensor Cores, for instance, can execute $FP16 \times FP16 \rightarrow FP32$ multiply-accumulate operations much faster than equivalent $FP32$ operations on standard CUDA cores. Performing the bulk of the expensive matrix multiplications in transformer layers (within attention and feed-forward networks) using $FP16$ or $BF16$ directly leverages this hardware acceleration, leading to significant increases in training throughput (measured in FLOPS, Floating-Point Operations Per Second).
Reduced Data Movement: Moving data between different levels of memory (e.g., from the high-bandwidth memory (HBM) on a GPU to its compute cores) is often a bottleneck. Since 16-bit values occupy half the space of 32-bit values, twice as many numbers can be transferred in the same amount of time for a given memory bandwidth. This reduction in data movement further contributes to overall speed improvements, as less time is spent waiting for data to arrive at the compute units.

The practical speedup depends heavily on the specific model architecture, the hardware used, and the efficiency of the software implementation (e.g., utilizing libraries like cuDNN with Tensor Core support). However, it's common to observe speedups ranging from 1.5x to 3x or even more for large transformer models when effectively using mixed-precision training on compatible hardware compared to pure $FP32$ training.

In summary, the adoption of $FP16$ or $BF16$ offers a compelling trade-off: by accepting a potential (and often manageable) reduction in numerical precision, we gain significant reductions in memory usage and notable increases in computational speed. This makes mixed-precision training an essential technique for pushing the scale of language models and accelerating the development cycle.