Deep Learning y Big Data

¿Qué es Big Data?

Big Data se refiere a conjuntos de datos cuyo volumen, velocidad de generación o variedad hacen que las herramientas tradicionales de procesamiento sean insuficientes. El término no describe sólo un tamaño, sino un paradigma: nuevas arquitecturas, algoritmos y tecnologías diseñadas para capturar, almacenar, procesar y analizar datos a escalas antes inimaginables.

El concepto de Big Data nació a principios de los años 2000, impulsado por la necesidad de empresas como Google, Yahoo y Facebook de gestionar cantidades de información que crecían a un ritmo exponencial. Google fue la pionera: para indexar toda la web necesitaba un sistema de almacenamiento y procesamiento radicalmente diferente a las bases de datos relacionales que existían hasta entonces. Sus publicaciones internas —el Google File System (GFS, 2003) y MapReduce (2004)— sentaron las bases técnicas de lo que hoy conocemos como el ecosistema Big Data.

Desde entonces, el paradigma ha evolucionado en tres grandes eras: la era Hadoop (2006–2012), centrada en el procesamiento batch sobre clusters de máquinas commodity; la era Spark (2012–2018), que introdujo el procesamiento in-memory y el análisis iterativo necesario para el machine learning; y la era cloud-native + AI (2018–actualidad), donde la infraestructura se despliega en la nube, los datos se almacenan en lakehouses y los pipelines están optimizados para alimentar modelos de deep learning a escala masiva.

Línea temporal del Big Data

La siguiente línea temporal recorre los hitos tecnológicos más importantes en la evolución del ecosistema Big Data, desde la publicación del paper de GFS hasta las arquitecturas AI-native actuales. Cada uno de estos hitos supuso un cambio fundamental en cómo se almacenan, procesan y explotan los datos a gran escala.

Las V's del Big Data

El modelo original de Doug Laney (2001) describió tres V's. Con el tiempo se han añadido más dimensiones que caracterizan la complejidad de los datos a gran escala. Comprender estas dimensiones es fundamental para diseñar sistemas de procesamiento adecuados: no es lo mismo un problema donde el reto principal es el volumen (como almacenar petabytes de imágenes médicas) que uno donde el reto es la velocidad (como procesar millones de transacciones financieras por segundo).

En la práctica, un proyecto de Big Data rara vez se enfrenta a las cinco V's con la misma intensidad. Un pipeline de IoT industrial, por ejemplo, genera datos a altísima velocidad (miles de sensores muestreando a kHz) pero con poca variedad (siempre los mismos tipos de señal). En cambio, un proyecto de procesamiento de lenguaje natural a escala web tiene enorme variedad (texto, HTML, PDFs, imágenes con texto, audio transcrito) pero la velocidad de ingesta puede ser moderada (batch de crawls periódicos). Identificar cuáles son las V's dominantes en tu caso de uso es el primer paso para elegir la arquitectura correcta.

Tecnologías clave del ecosistema Big Data

Almacenamiento distribuido

Procesamiento batch

Procesamiento en streaming

Bases de datos para Big Data

Las mayores fuentes de producción de datos

La cantidad de datos generados globalmente ha crecido exponencialmente. Según IDC (International Data Corporation), en 2025 se generarán más de 180 zettabytes (ZB) de datos, frente a los ~2 ZB de 2010.

Evolución del almacenamiento de datos

La capacidad de almacenamiento y su coste han evolucionado dramáticamente, siendo un factor clave en la viabilidad del Big Data:

¿Por qué el Deep Learning necesita Big Data?

La relación entre Big Data y Deep Learning es simbiótica: los modelos de DL necesitan cantidades masivas de datos para aprender representaciones útiles, y al mismo tiempo son los únicos modelos capaces de escalar su rendimiento proporcionalmente con la cantidad de datos disponibles.

Esta relación simbiótica no es un accidente: tiene raíces teóricas profundas. Los modelos de deep learning son aproximadores universales —con suficientes parámetros, pueden aproximar cualquier función continua— pero esa capacidad de representación viene con un coste: necesitan enormes cantidades de ejemplos para aprender las regularidades estadísticas del dominio sin caer en overfitting. Un modelo con millones o miles de millones de parámetros tiene un espacio de hipótesis tan grande que, sin datos suficientes, memorizará el training set en lugar de generalizar. Aquí es donde el Big Data se vuelve indispensable: cuantos más datos diversos y representativos alimenten al modelo, mejor será su capacidad de generalización. Para profundizar en conceptos de overfitting y generalización, consulta el submódulo de Machine Learning Clásico.

La siguiente gráfica ilustra la idea clave: mientras que los algoritmos de ML tradicional (SVM, Random Forest, XGBoost) saturan su rendimiento a partir de cierta cantidad de datos —porque su capacidad de representación es limitada—, los modelos de deep learning escalan sin saturar, siempre que el modelo sea suficientemente grande. Este fenómeno, demostrado empíricamente por las scaling laws de Kaplan et al. (2020), es la razón fundamental por la que los grandes avances en IA de los últimos años han venido de la mano de datasets cada vez más masivos.

Leyes de escala (Scaling Laws)

Las leyes de escala son relaciones empíricas que describen cómo el rendimiento de un modelo (medido como pérdida L) depende del número de parámetros (N), cantidad de datos (D) y compute (C) como leyes de potencias.

El descubrimiento de estas leyes fue un punto de inflexión para la industria del deep learning. Antes de 2020, la intuición dominante era que "más grande no siempre es mejor": se asumía que existían rendimientos decrecientes al escalar modelos. Los trabajos de Kaplan et al. en OpenAI demostraron que, al menos para modelos de lenguaje, el rendimiento mejora de forma predecible y suave siguiendo leyes de potencias, sin señales de saturación en los rangos estudiados (hasta cientos de miles de millones de parámetros). Esto transformó la estrategia de entrenamiento: en lugar de buscar arquitecturas más ingeniosas, las empresas empezaron a invertir en escalar los modelos existentes con más datos y más compute. Para una visión completa del entrenamiento de redes, consulta el submódulo de Optimización avanzada.

Datasets masivos para Deep Learning

El entrenamiento de modelos de deep learning a escala requiere datasets cada vez más grandes, diversos y cuidadosamente curados:

Datasets de texto (NLP / LLMs)

Datasets de visión

Datasets de audio y multimodal

El coste del compute para DL

El compute necesario para entrenar modelos SOTA ha crecido ~10× cada año desde 2012, mucho más rápido que la ley de Moore:

Centros de datos para Deep Learning

Entrenar modelos de Deep Learning a escala requiere infraestructura especializada que va mucho más allá de un simple servidor con GPU. Los AI data centers modernos son instalaciones de miles de millones de dólares diseñadas específicamente para workloads de entrenamiento e inferencia de modelos de IA.

Un AI data center se diferencia de un data center tradicional en prácticamente todos sus aspectos: el hardware está dominado por aceleradores (GPUs, TPUs) en lugar de CPUs genéricas; la red necesita un ancho de banda entre nodos órdenes de magnitud superior al de un data center web convencional (porque el entrenamiento distribuido requiere sincronizar gradientes constantemente entre miles de GPUs); el almacenamiento necesita un throughput sostenido de TB/s para alimentar los pipelines de datos; la energía se multiplica (una sola GPU H100 consume 700W, frente a los ~100W de un servidor web) y la refrigeración requiere sistemas de liquid cooling directo porque la densidad de calor por rack es demasiado alta para los sistemas de aire acondicionado tradicionales.

Los siguientes componentes forman la arquitectura típica de un AI data center moderno. Cada uno de ellos es un cuello de botella potencial: si cualquier componente está subdimensionado, las costosas GPUs pasan tiempo ociosas.

Arquitectura de un AI Data Center

Aceleradores de hardware para DL

GPUs NVIDIA

Otros aceleradores

Redes de interconexión para AI

La red es el cuello de botella #1 en entrenamiento distribuido. El entrenamiento de un LLM requiere sincronizar gradientes entre miles de GPUs, lo que genera tráfico de red intensísimo (all-reduce).

Almacenamiento para pipelines de DL

El almacenamiento en un AI data center tiene dos roles: datos de entrenamiento (TB–PB de datasets) y checkpoints (snapshots del modelo durante training).

Clusters de referencia en la industria

Computación eficiente para Deep Learning

La eficiencia computacional es crucial tanto a nivel de usuario (optimizar el código en tu máquina) como a nivel de centro de datos (maximizar la utilización del hardware). Comprender las diferencias entre procesamiento secuencial, paralelo en CPU y paralelo en GPU es fundamental para escribir código de DL eficiente.

En deep learning, la operación dominante es la multiplicación de matrices (MatMul): cada capa fully-connected, cada atención en un Transformer, cada convolución se reduce internamente a multiplicaciones de matrices. Estas operaciones son inherentemente paralelizables: cada elemento del resultado es independiente de los demás y puede calcularse simultáneamente. Por eso, la elección del hardware de ejecución —CPU, GPU o ASIC especializado— tiene un impacto dramático en el rendimiento. La diferencia no es de porcentajes, sino de órdenes de magnitud.

Los tres tipos principales de hardware para deep learning difieren en su filosofía de diseño. Comprender estas diferencias ayuda a elegir el hardware correcto para cada tarea y a escribir código que explote al máximo la arquitectura subyacente. Para una introducción a las operaciones tensoriales que subyacen a todo esto, consulta el submódulo de Tensores.

De bucles for a operaciones vectorizadas

La diferencia de rendimiento entre código Python puro y código vectorizado puede ser de órdenes de magnitud. Veamos con el ejemplo de la multiplicación de matrices:

import time

def matmul_python(A, B):
    """Multiplicación de matrices con bucles for puros.
    Complejidad: O(n³). Extremadamente lento para n > 500.
    """
    n = len(A)
    m = len(B[0])
    k = len(B)
    C = [[0.0] * m for _ in range(n)]
    for i in range(n):
        for j in range(m):
            for p in range(k):
                C[i][j] += A[i][p] * B[p][j]
    return C

# Benchmark: matrices 512×512
n = 512
A = [[float(i + j) for j in range(n)] for i in range(n)]
B = [[float(i * j) for j in range(n)] for i in range(n)]

start = time.time()
C = matmul_python(A, B)
print(f"Python puro: {time.time() - start:.2f}s")
# → Python puro: ~45-120 segundos (¡minutos para n=1024!)

import numpy as np
import time

def matmul_numpy(A, B):
    """NumPy usa BLAS optimizado (OpenBLAS/MKL) internamente.
    Operaciones vectorizadas en C/Fortran con SIMD y multi-core.
    """
    return A @ B  # equivalente a np.matmul(A, B)

# Benchmark: matrices 512×512
n = 512
A = np.random.randn(n, n).astype(np.float32)
B = np.random.randn(n, n).astype(np.float32)

start = time.time()
C = matmul_numpy(A, B)
print(f"NumPy (CPU): {time.time() - start:.4f}s")
# → NumPy (CPU): ~0.005-0.02 segundos (¡~2000-10000× más rápido!)

# ¿Por qué? NumPy llama a BLAS (Basic Linear Algebra Subprograms)
# implementado en C/Fortran con instrucciones SIMD (AVX-512)
# y multi-threading automático.

# Para matrices más grandes:
n = 4096
A = np.random.randn(n, n).astype(np.float32)
B = np.random.randn(n, n).astype(np.float32)
start = time.time()
C = A @ B
print(f"NumPy 4096×4096: {time.time() - start:.3f}s")
# → ~1-3 segundos (4096³ = 68B operaciones)

import cupy as cp
import time

def matmul_cupy(A, B):
    """CuPy: API idéntica a NumPy pero ejecuta en GPU.
    Internamente usa cuBLAS (NVIDIA's BLAS para CUDA).
    """
    return A @ B

# Benchmark: matrices 4096×4096 en GPU
n = 4096
A_gpu = cp.random.randn(n, n, dtype=cp.float32)
B_gpu = cp.random.randn(n, n, dtype=cp.float32)

# Warm-up (primera ejecución compila kernels)
_ = A_gpu @ B_gpu
cp.cuda.Stream.null.synchronize()

start = time.time()
C_gpu = matmul_cupy(A_gpu, B_gpu)
cp.cuda.Stream.null.synchronize()  # Esperar a que GPU termine
print(f"CuPy (GPU): {time.time() - start:.4f}s")
# → CuPy (GPU): ~0.005-0.02 segundos para 4096×4096
# ¡~100-500× más rápido que NumPy para matrices grandes!

# Transferencia CPU ↔ GPU (el coste oculto)
A_cpu = np.random.randn(n, n).astype(np.float32)

start = time.time()
A_gpu = cp.asarray(A_cpu)       # CPU → GPU
elapsed_to_gpu = time.time() - start

start = time.time()
A_back = cp.asnumpy(A_gpu)     # GPU → CPU
elapsed_to_cpu = time.time() - start

print(f"CPU→GPU: {elapsed_to_gpu:.4f}s, GPU→CPU: {elapsed_to_cpu:.4f}s")
# ¡La transferencia puede ser más lenta que el cómputo!

Devices en TensorFlow y PyTorch

Tanto TensorFlow como PyTorch permiten mover tensores y modelos entre diferentes devices (CPU, GPU, TPU). Entender cómo gestionar devices es esencial para el rendimiento.

import torch

# ═══════════════════════════════════════════════════
# Detectar devices disponibles
# ═══════════════════════════════════════════════════
print(f"CUDA disponible: {torch.cuda.is_available()}")
print(f"MPS disponible: {torch.backends.mps.is_available()}")  # Apple Silicon
print(f"Nº GPUs CUDA: {torch.cuda.device_count()}")
if torch.cuda.is_available():
    print(f"GPU actual: {torch.cuda.get_device_name(0)}")

# ═══════════════════════════════════════════════════
# Crear tensores en devices específicos
# ═══════════════════════════════════════════════════
x_cpu = torch.randn(1000, 1000)                    # CPU (por defecto)
x_gpu = torch.randn(1000, 1000, device='cuda')     # GPU directamente
x_gpu2 = torch.randn(1000, 1000, device='cuda:1')  # Segunda GPU

# ═══════════════════════════════════════════════════
# Mover tensores entre devices
# ═══════════════════════════════════════════════════
x_to_gpu = x_cpu.to('cuda')      # CPU → GPU
x_to_cpu = x_gpu.cpu()           # GPU → CPU
x_to_gpu_fp16 = x_cpu.to('cuda', dtype=torch.float16)  # + cambio de tipo

# ═══════════════════════════════════════════════════
# Mover modelos completos
# ═══════════════════════════════════════════════════
model = torch.nn.Linear(1000, 100)
model = model.to('cuda')         # Todos los parámetros a GPU
# ⚠️ Los datos de entrada también deben estar en el mismo device
output = model(x_to_gpu)

# ═══════════════════════════════════════════════════
# Device-agnostic code (buena práctica)
# ═══════════════════════════════════════════════════
device = torch.device(
    'cuda' if torch.cuda.is_available()
    else 'mps' if torch.backends.mps.is_available()
    else 'cpu'
)
model = model.to(device)
data = data.to(device)

import tensorflow as tf

# ═══════════════════════════════════════════════════
# Detectar devices disponibles
# ═══════════════════════════════════════════════════
print("Devices:", tf.config.list_physical_devices())
gpus = tf.config.list_physical_devices('GPU')
print(f"GPUs: {gpus}")
tpus = tf.config.list_physical_devices('TPU')
print(f"TPUs: {tpus}")

# ═══════════════════════════════════════════════════
# Configurar memoria GPU
# ═══════════════════════════════════════════════════
# TF por defecto reserva TODA la memoria GPU.
# Para permitir crecimiento dinámico:
for gpu in gpus:
    tf.config.experimental.set_memory_growth(gpu, True)

# O limitar a una cantidad fija:
# tf.config.set_logical_device_configuration(
#     gpus[0],
#     [tf.config.LogicalDeviceConfiguration(memory_limit=4096)]  # 4 GB
# )

# ═══════════════════════════════════════════════════
# Placement explícito de operaciones
# ═══════════════════════════════════════════════════
with tf.device('/CPU:0'):
    a = tf.random.normal([1000, 1000])  # En CPU

with tf.device('/GPU:0'):
    b = tf.random.normal([1000, 1000])  # En GPU

# TF automáticamente mueve datos entre devices si es necesario
c = tf.matmul(a, b)  # a se copia a GPU automáticamente

# ═══════════════════════════════════════════════════
# TPU setup (Google Cloud / Colab)
# ═══════════════════════════════════════════════════
# resolver = tf.distribute.cluster_resolver.TPUClusterResolver()
# tf.config.experimental_connect_to_cluster(resolver)
# tf.tpu.experimental.initialize_tpu_system(resolver)
# strategy = tf.distribute.TPUStrategy(resolver)

Comparativa de devices soportados

Prácticas de eficiencia computacional

A nivel de usuario

from torch.cuda.amp import autocast, GradScaler

scaler = GradScaler()

for batch in dataloader:
    optimizer.zero_grad()
    
    # Forward pass en FP16
    with autocast(dtype=torch.float16):
        output = model(batch['input'].cuda())
        loss = criterion(output, batch['target'].cuda())
    
    # Backward con gradient scaling (evita underflow en FP16)
    scaler.scale(loss).backward()
    scaler.step(optimizer)
    scaler.update()
# → ~2× más rápido, ~50% menos memoria

accumulation_steps = 4  # Effective batch = micro_batch × 4

for i, batch in enumerate(dataloader):
    output = model(batch['input'].cuda())
    loss = criterion(output, batch['target'].cuda())
    loss = loss / accumulation_steps  # Normalizar
    loss.backward()
    
    if (i + 1) % accumulation_steps == 0:
        optimizer.step()
        optimizer.zero_grad()
# Effective batch size = 32 × 4 = 128, usando memoria de batch=32

from torch.utils.checkpoint import checkpoint

class EfficientModel(torch.nn.Module):
    def forward(self, x):
        # En lugar de almacenar activaciones de cada bloque,
        # re-computa durante backward:
        x = checkpoint(self.block1, x, use_reentrant=False)
        x = checkpoint(self.block2, x, use_reentrant=False)
        x = checkpoint(self.block3, x, use_reentrant=False)
        return self.head(x)

# En HuggingFace Transformers:
model.gradient_checkpointing_enable()

# PyTorch 2.0+
model = torch.compile(model, mode='reduce-overhead')
# Opciones de mode:
#   'default':         balance entre compilación y rendimiento
#   'reduce-overhead': minimiza overhead de Python (mejor para inference)
#   'max-autotune':    prueba múltiples estrategias (más lento en compilar)

# TensorFlow equivalente:
# @tf.function(jit_compile=True)  # Activa XLA
# def train_step(data, labels):
#     with tf.GradientTape() as tape:
#         predictions = model(data, training=True)
#         loss = loss_fn(labels, predictions)
#     gradients = tape.gradient(loss, model.trainable_variables)
#     optimizer.apply_gradients(zip(gradients, model.trainable_variables))

A nivel de centro de datos

¿Por qué entrenamiento distribuido?

Los modelos modernos de Deep Learning son demasiado grandes para caber en una sola GPU y requieren demasiado compute para entrenarse en un tiempo razonable. El entrenamiento distribuido resuelve ambos problemas dividiendo el trabajo entre múltiples aceleradores.

Para entender por qué es necesario, consideremos las cifras: entrenar LLaMA-3 70B desde cero requirió aproximadamente 6.4 millones de GPU-horas. En una sola GPU H100, eso serían ~730 años. Meta utilizó 2,048 H100 durante ~30 días, reduciendo el tiempo casi linealmente. Sin entrenamiento distribuido, los modelos que hoy consideramos state-of-the-art simplemente no existirían: nadie puede esperar siglos para entrenar un modelo. El entrenamiento distribuido no es un lujo o una optimización; es un requisito fundamental para el deep learning a escala.

El reto principal del entrenamiento distribuido es la comunicación entre GPUs. Cada GPU calcula gradientes de forma local, pero estos deben sincronizarse con las demás GPUs para que el modelo aprenda de forma coherente. Esta sincronización (llamada all-reduce) genera un tráfico de red enorme que puede convertirse en el cuello de botella dominante si la infraestructura no está diseñada adecuadamente. Para más contexto sobre cómo funcionan los gradientes y el backpropagation, consulta el submódulo de Perceptrón y MLP.

Data Parallelism (DP)

En Data Parallelism, cada GPU tiene una copia completa del modelo. Los datos de entrenamiento se dividen entre GPUs, cada una computa gradientes locales, y luego se sincronizan (all-reduce) antes de actualizar los pesos.

# ═══════════════════════════════════════════════════
# PyTorch DDP — Data Parallelism distribuido
# ═══════════════════════════════════════════════════
import torch
import torch.distributed as dist
from torch.nn.parallel import DistributedDataParallel as DDP
from torch.utils.data import DataLoader, DistributedSampler

def train(rank, world_size):
    # 1. Inicializar proceso distribuido
    dist.init_process_group("nccl", rank=rank, world_size=world_size)
    torch.cuda.set_device(rank)
    
    # 2. Crear modelo y wrappear con DDP
    model = MyModel().cuda(rank)
    model = DDP(model, device_ids=[rank])
    
    # 3. DataLoader con DistributedSampler
    sampler = DistributedSampler(dataset, num_replicas=world_size, rank=rank)
    dataloader = DataLoader(dataset, batch_size=32, sampler=sampler)
    
    optimizer = torch.optim.AdamW(model.parameters(), lr=1e-4)
    
    for epoch in range(num_epochs):
        sampler.set_epoch(epoch)  # Shuffle diferente cada epoch
        for batch in dataloader:
            inputs = batch['input'].cuda(rank)
            targets = batch['target'].cuda(rank)
            
            output = model(inputs)
            loss = criterion(output, targets)
            
            optimizer.zero_grad()
            loss.backward()        # DDP sincroniza gradientes automáticamente
            optimizer.step()
    
    dist.destroy_process_group()

# Lanzar con: torchrun --nproc_per_node=4 train.py
# O: python -m torch.distributed.launch --nproc_per_node=4 train.py

# ═══════════════════════════════════════════════════
# TensorFlow MirroredStrategy — Data Parallelism
# ═══════════════════════════════════════════════════
import tensorflow as tf

# 1. Crear strategy (auto-detecta GPUs)
strategy = tf.distribute.MirroredStrategy()
print(f"Número de replicas: {strategy.num_replicas_in_sync}")

# 2. Crear modelo dentro del scope de la strategy
with strategy.scope():
    model = tf.keras.Sequential([
        tf.keras.layers.Dense(512, activation='relu'),
        tf.keras.layers.Dense(10)
    ])
    model.compile(
        optimizer=tf.keras.optimizers.Adam(1e-4),
        loss=tf.keras.losses.SparseCategoricalCrossentropy(from_logits=True),
        metrics=['accuracy']
    )

# 3. Crear dataset distribuido
batch_size_per_replica = 32
global_batch_size = batch_size_per_replica * strategy.num_replicas_in_sync

dataset = tf.data.Dataset.from_tensor_slices((x_train, y_train))
dataset = dataset.shuffle(10000).batch(global_batch_size).prefetch(tf.data.AUTOTUNE)

# 4. Entrenar — TF distribuye automáticamente
model.fit(dataset, epochs=10)

# Para multi-nodo:
# strategy = tf.distribute.MultiWorkerMirroredStrategy()

Model Parallelism

En Model Parallelism, el modelo se divide entre múltiples GPUs. Cada GPU solo tiene una parte del modelo. Existen dos variantes principales.

La necesidad de model parallelism surge cuando el modelo es demasiado grande para caber en una sola GPU, incluso con mixed precision. Un modelo de 70B parámetros en FP16 ocupa ~140 GB solo para los pesos, sin contar gradientes, optimizer states ni activaciones. Como ninguna GPU actual tiene tanta memoria (la H200 llega a 141 GB, pero el overhead la hace insuficiente), es necesario distribuir el modelo entre varias GPUs. A diferencia del data parallelism —donde cada GPU tiene el modelo completo y los datos se dividen—, en model parallelism cada GPU tiene solo una fracción del modelo, y la comunicación entre GPUs es necesaria incluso durante un solo paso de forward. Esto hace que la latencia y el ancho de banda de la red sean mucho más críticos.

Tensor Parallelism (TP)

Pipeline Parallelism (PP)

3D Parallelism y FSDP

Cuando un modelo es suficientemente grande —cientos de miles de millones de parámetros—, ninguna de las técnicas anteriores es suficiente por sí sola. Data parallelism necesita que el modelo quepa en cada GPU; tensor parallelism satura a pocos GPUs por la comunicación all-reduce dentro de cada operación; y pipeline parallelism introduce burbujas que limitan la eficiencia. La solución es combinar las tres en lo que se denomina 3D parallelism: una cuadrícula tridimensional donde cada eje corresponde a una dimensión de partición diferente.

Esta idea fue formalizada por NVIDIA en su framework Megatron-LM v2 (2021). La clave es asignar cada eje de paralelismo al nivel de interconexión adecuado: TP dentro del nodo (NVLink, alta velocidad), PP entre nodos cercanos, y DP en la dimensión más externa (tolera mayor latencia). Esta asignación jerárquica minimiza la comunicación en los enlaces más lentos.

# ═══════════════════════════════════════════════════
# PyTorch FSDP — Fully Sharded Data Parallel
# ═══════════════════════════════════════════════════
import torch
from torch.distributed.fsdp import (
    FullyShardedDataParallel as FSDP,
    MixedPrecision,
    ShardingStrategy,
)
from torch.distributed.fsdp.wrap import transformer_auto_wrap_policy
from transformers import AutoModelForCausalLM

# 1. Configurar mixed precision
mp_policy = MixedPrecision(
    param_dtype=torch.bfloat16,
    reduce_dtype=torch.bfloat16,
    buffer_dtype=torch.bfloat16,
)

# 2. Definir qué capas se fragmentan
auto_wrap_policy = transformer_auto_wrap_policy(
    transformer_layer_cls={transformers.models.llama.modeling_llama.LlamaDecoderLayer}
)

# 3. Crear modelo FSDP
model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-2-7b-hf")
model = FSDP(
    model,
    sharding_strategy=ShardingStrategy.FULL_SHARD,  # ZeRO-3
    mixed_precision=mp_policy,
    auto_wrap_policy=auto_wrap_policy,
    device_id=torch.cuda.current_device(),
)

# 4. Training loop normal — FSDP gestiona fragmentación automáticamente
optimizer = torch.optim.AdamW(model.parameters(), lr=2e-5)
for batch in dataloader:
    loss = model(**batch).loss
    loss.backward()
    optimizer.step()
    optimizer.zero_grad()

# Lanzar: torchrun --nproc_per_node=8 --nnodes=4 train_fsdp.py

Frameworks de entrenamiento distribuido

El ecosistema de entrenamiento distribuido ha madurado enormemente desde 2020. Mientras que antes cada organización construía sus propias soluciones, hoy existen frameworks de código abierto que encapsulan las técnicas de paralelismo descritas arriba y las hacen accesibles con pocas líneas de configuración.

La elección del framework depende fundamentalmente de tres factores: la escala del modelo (modelos de <10B suelen basta con DDP/FSDP, mientras que modelos de 100B+ necesitan Megatron-DeepSpeed), el hardware disponible (GPUs NVIDIA vs TPUs Google), y la complejidad que estés dispuesto a asumir. La siguiente tabla resume las opciones más relevantes en 2024.

# deepspeed_config.json
{
    "bf16": {"enabled": true},
    "zero_optimization": {
        "stage": 3,
        "offload_optimizer": {"device": "cpu"},
        "offload_param": {"device": "none"},
        "overlap_comm": true,
        "contiguous_gradients": true,
        "reduce_scatter": true
    },
    "gradient_accumulation_steps": 4,
    "train_micro_batch_size_per_gpu": 2,
    "wall_clock_breakdown": false
}
# Lanzar: deepspeed --num_gpus=8 train.py --deepspeed ds_config.json

# ═══════════════════════════════════════════════════
# HuggingFace Accelerate — wrapper unificado
# ═══════════════════════════════════════════════════
from accelerate import Accelerator

accelerator = Accelerator(
    mixed_precision='bf16',       # o 'fp16'
    gradient_accumulation_steps=4,
)

# Preparar modelo, optimizer, dataloader
model, optimizer, dataloader = accelerator.prepare(
    model, optimizer, dataloader
)

for batch in dataloader:
    with accelerator.accumulate(model):
        outputs = model(**batch)
        loss = outputs.loss
        accelerator.backward(loss)
        optimizer.step()
        optimizer.zero_grad()

# Configurar: accelerate config (wizard interactivo)
# Lanzar: accelerate launch --num_processes=8 train.py

¿Cuándo usar qué técnica?

La regla de oro es empezar siempre con la técnica más simple que funcione. Data parallelism con DDP debería ser el primer recurso; solo cuando el modelo no cabe en una GPU (o la velocidad es insuficiente) se justifica pasar a sharding (FSDP/ZeRO) y, más allá, a combinaciones de paralelismo más complejas. Cada nivel de complejidad introduce overhead de comunicación, dificultades de debugging y puntos de fallo adicionales.

Para fine-tuning de LLMs, la combinación de LoRA + cuantización (QLoRA) ha democratizado enormemente el acceso: permite adaptar modelos de 70B en una o dos GPUs consumer (24 GB VRAM). Consulta el submódulo de Optimización avanzada para detalles sobre estas técnicas de eficiencia paramétrica.

Papers y recursos fundamentales

El entrenamiento distribuido es una de las áreas de investigación más activas en sistemas para deep learning. Los siguientes papers constituyen las referencias canónicas que todo practicante debería conocer. Están ordenados cronológicamente para reflejar la evolución del campo, desde los primeros trabajos en data parallelism hasta las técnicas de sharding que hacen posible entrenar modelos de cientos de miles de millones de parámetros.