Por qué PyTorch ganó la carrera de frameworks

1. La guerra de frameworks que ya casi nadie recuerda

A mediados de la década de 2010, TensorFlow (Google, 2015) dominaba investigación e industria con un modelo de grafo estático: se definía el grafo de cómputo completo primero (tf.placeholder, sesiones, sess.run()), y recién después se ejecutaba. Esto permitía optimizaciones agresivas antes de correr una sola operación, pero hacía que debuggear fuera una pesadilla — un error de shape solo aparecía al ejecutar la sesión, lejos del código que realmente tenía el bug, y no se podía usar un print() ni un debugger de Python en medio del grafo.

PyTorch (Meta/Facebook, 2017) apostó por lo opuesto desde el día uno: ejecución eager — cada operación corre inmediatamente, como cualquier código Python normal. Se puede poner un print(tensor) en medio del forward pass, usar pdb, y ver los valores reales en cada paso. Investigadores lo adoptaron masivamente porque iterar experimentos era radicalmente más rápido — la fracción de papers de NeurIPS/ICML que usaban PyTorch pasó de ser minoritaria a dominante en apenas unos años.

La idea no era original de PyTorch: Chainer (Preferred Networks, 2015) ya había bautizado el enfoque como define-by-run — el grafo se define mientras corre, no antes — y DyNet lo exploraba para NLP. PyTorch la tomó, la combinó con la base numérica de Torch7 (la librería en Lua que Facebook AI Research ya usaba) y con una API que se sentía como NumPy, y le agregó el ecosistema de una empresa grande detrás. El paper de NeurIPS 2019 lo dice explícitamente: el objetivo era "usabilidad y velocidad", en ese orden, sin ceder ninguna de las dos.

2. Por qué "eager por defecto" fue la apuesta correcta

La presión de TensorFlow fue tan fuerte que su propia versión 2.0 (2019) adoptó eager execution por defecto, validando retroactivamente la apuesta de PyTorch. Pero para ese momento el ecosistema de investigación ya había migrado: los papers nuevos salían con código de referencia en PyTorch, lo cual generaba más tutoriales, más Stack Overflow, más ingenieros formados en PyTorch — un efecto de red que se retroalimentaba solo.

El costo de performance de eager (visto en la página anterior) se resolvió después, con torch.compile — pero se resolvió sin abandonar la experiencia eager por defecto: el modelo se sigue escribiendo y debuggeando en modo eager, y la compilación es un paso opcional y aditivo al final. TensorFlow resolvió el mismo problema al revés: empezó grafo-primero y agregó eager después. La secuencia en la que cada framework resolvió el trade-off performance/ergonomía terminó siendo la diferencia decisiva.

Vale ser concreto sobre qué significa "ergonomía", porque suena a gusto personal y no lo es. En un grafo estático, un modelo con un loop cuyo largo depende de los datos (un decoder que genera hasta encontrar el token de fin, un árbol recursivo, un algoritmo de búsqueda) requería construir el control de flujo dentro del grafo con primitivas especiales (tf.while_loop, tf.cond), que no eran Python y no se podían depurar como Python. En eager, es un while. Para un campo cuyo trabajo diario es probar arquitecturas nuevas, esa diferencia se mide en experimentos por semana. Y el argumento de performance a favor del grafo estático resultó menos fuerte de lo que parecía: la mayoría del tiempo se va en matmuls que ejecutan librerías de NVIDIA (cuBLAS, cuDNN) igual de rápido desde cualquier framework — el grafo estático solo ganaba en el pegamento alrededor, que es justamente lo que torch.compile recuperó después.

Hay un segundo factor menos comentado: TensorFlow 2.0 rompió la compatibilidad con TF1 en un momento en que buena parte del código de producción de la industria era TF1. Migrar costaba tanto como cambiar de framework, y si había que cambiar, PyTorch era donde estaban los papers. El propio Google terminó construyendo JAX (grafo funcional + compilación XLA) para su investigación interna — excelente para TPUs y para ciertos estilos de código, pero un tercer framework, no una resurrección de TensorFlow. En 2026, la división de facto es: PyTorch para casi todo, JAX en una parte de la investigación y en la infraestructura de Google/DeepMind, TensorFlow en sistemas heredados y en algunos nichos de deployment móvil.

3. El ecosistema que se construyó encima

Prácticamente todo lo que recorriste en este curso corre sobre PyTorch como capa base:

• Hugging Face Transformers — la librería central de todo el HF LLM Course — usa PyTorch como backend principal (en versiones recientes, el único backend de primera clase; los de TensorFlow y JAX quedaron en mantenimiento).
• fastai y miniai — toda la Parte 1 y Parte 2 de fast.ai — son capas de conveniencia sobre torch.nn, torch.optim y torch.utils.data.
• vLLM, el motor de inferencia detrás de tus propios fixes upstream, está construido sobre PyTorch (con kernels custom en CUDA/Triton para las partes críticas de performance).
• Diffusers de HF, que usaste en la Unidad 5 de fast.ai Parte 2, es PyTorch puro.
• torchtitan, la librería de referencia de Meta para entrenar LLMs desde cero a escala de producción, vive directamente dentro del ecosistema oficial de PyTorch.
• PEFT, TRL, Accelerate, bitsandbytes, torchao, Triton — todo lo que usaste para LoRA, cuantización y kernels custom asume tensores y módulos de PyTorch como moneda común. Triton, el lenguaje en que están escritos los kernels de torch.compile y buena parte de los de vLLM, nació independiente y hoy es un pilar del stack.

Esto no es casualidad: cuando el framework de investigación de facto y el framework de producción de facto son el mismo, el costo de llevar un modelo de "funciona en un notebook" a "sirve tráfico real" baja drásticamente. Es una de las razones estructurales por las que el ciclo de investigación → producción en LLMs se acortó tanto en los últimos años.

El mecanismo es concreto: un state_dict de PyTorch (o su safetensors) es la interfaz universal. El mismo checkpoint que sale de un entrenamiento con torchtitan o con Trainer lo carga vLLM para servir, lo cuantiza torchao, lo fine-tunea PEFT, lo exporta ExecuTorch. Ninguna de esas librerías tuvo que ponerse de acuerdo con las demás — solo con PyTorch.

4. Entrenamiento distribuido: DDP y FSDP

Todo lo visto hasta acá asume un solo dispositivo. Entrenar modelos del tamaño de los que usás en tus propios proyectos (Gemma-4, modelos de 30B+ parámetros) requiere repartir el trabajo entre varias GPUs — dos estrategias nativas de PyTorch, con roles distintos:

• DDP (DistributedDataParallel): cada GPU tiene una copia completa del modelo y procesa un subconjunto distinto del batch; los gradientes se promedian entre todas las copias antes de cada step. Simple y eficiente cuando el modelo entero entra en la memoria de una sola GPU.
• FSDP (Fully Sharded Data Parallel): cuando el modelo no entra en una sola GPU, FSDP parte (shardea) los parámetros, gradientes y estados del optimizador entre todas las GPUs disponibles, reconstruyendo cada capa completa solo momentáneamente durante su forward/backward. Es el mecanismo detrás de entrenar modelos de decenas o cientos de miles de millones de parámetros sin necesitar una sola GPU con memoria imposible.

Ninguna de las dos requiere reescribir la arquitectura del modelo — se aplican como una capa que envuelve el nn.Module ya definido, otra vez el mismo patrón de "agregar una capa sin tocar el modelo" que ya viste con torch.compile.

El esqueleto de DDP

El modelo mental: torchrun lanza N procesos idénticos (uno por GPU), cada uno con su RANK y LOCAL_RANK en variables de entorno; init_process_group los conecta; DistributedSampler le da a cada uno una porción distinta del dataset; y el wrapper DDP engancha un hook al backward que hace all-reduce de los gradientes (promedio entre procesos) solapado con el cómputo. Después de backward(), las N copias tienen el mismo gradiente y cada una hace el mismo step() — siguen idénticas sin sincronizar pesos.

# torchrun --nproc_per_node=4 train.py        ← 4 procesos, uno por GPU
import os, torch, torch.distributed as dist
from torch.nn.parallel import DistributedDataParallel as DDP
from torch.utils.data import DataLoader, DistributedSampler

dist.init_process_group("nccl")                      # lee RANK/WORLD_SIZE/MASTER_ADDR del entorno
rank, local_rank = dist.get_rank(), int(os.environ["LOCAL_RANK"])
torch.cuda.set_device(local_rank)                     # sin esto, todos los ranks van a cuda:0

model = MiModelo().to(local_rank)
model = DDP(model, device_ids=[local_rank])           # model.module es el modelo real

sampler = DistributedSampler(dataset)                 # cada rank ve 1/N del dataset, sin solaparse
loader = DataLoader(dataset, batch_size=32, sampler=sampler)   # 32 por GPU → 128 global
optimizer = torch.optim.AdamW(model.parameters(), lr=3e-4)

for epoch in range(epochs):
    sampler.set_epoch(epoch)                          # sin esto, el shuffle es idéntico cada epoch
    for X, y in loader:
        X, y = X.to(local_rank), y.to(local_rank)
        loss = loss_fn(model(X), y)
        loss.backward()                               # all-reduce de gradientes, solapado
        optimizer.step(); optimizer.zero_grad()
    if rank == 0:                                     # un solo proceso loggea y guarda
        print(epoch, loss.item())
        torch.save(model.module.state_dict(), "ckpt.pt")
    dist.barrier()                                    # que nadie siga hasta que rank 0 terminó de guardar

dist.destroy_process_group()

El esqueleto de FSDP

FSDP tiene dos APIs. La original (FullyShardedDataParallel, "FSDP1") envuelve el modelo con una política de qué submódulos shardear; la nueva (fully_shard, "FSDP2", construida sobre DTensor) se aplica capa por capa, es más simple de componer con tensor parallelism y torch.compile, y es la recomendada en versiones recientes. El resto del loop es idéntico al de DDP — lo que cambia es la línea del wrapper:

# FSDP1
from torch.distributed.fsdp import FullyShardedDataParallel as FSDP, MixedPrecision
from torch.distributed.fsdp.wrap import transformer_auto_wrap_policy
import functools
policy = functools.partial(transformer_auto_wrap_policy, transformer_layer_cls={TransformerBlock})
model = FSDP(model, auto_wrap_policy=policy, device_id=local_rank,
             mixed_precision=MixedPrecision(param_dtype=torch.bfloat16, reduce_dtype=torch.float32))

# FSDP2 (versiones recientes): shardear cada bloque y después la raíz
from torch.distributed.fsdp import fully_shard, MixedPrecisionPolicy
mp = MixedPrecisionPolicy(param_dtype=torch.bfloat16, reduce_dtype=torch.float32)
for block in model.blocks:
    fully_shard(block, mp_policy=mp)
fully_shard(model, mp_policy=mp)                      # el modelo sigue siendo el mismo nn.Module

La política de wrap importa porque define la unidad de shardeo: FSDP reconstruye (all-gather) los parámetros de una unidad justo antes de su forward, los descarta después, y los vuelve a reunir en el backward. Shardear por bloque de transformer es el equilibrio habitual — unidades más chicas gastan más comunicación, una sola unidad gigante no ahorra memoria durante el cómputo.

DDP vs FSDP: la cuenta de memoria

Para decidir, la cuenta que hay que hacer es de bytes por parámetro entrenado con AdamW en precisión mixta: 2 (peso bf16) + 2 (gradiente bf16) + 4 (master weight fp32) + 8 (momento y varianza fp32) = 16 bytes por parámetro, sin contar activaciones. Un modelo de 7B son 112 GB de estado de entrenamiento — no entra en ninguna GPU sola, y esa es la razón de FSDP.

Y cuando ni con FSDP alcanza — porque una sola capa no entra en una GPU, o porque el all-gather por capa domina el tiempo — entran las otras dimensiones: tensor parallelism parte cada matmul entre GPUs (cada una calcula una porción de las columnas de la proyección) y pipeline parallelism asigna bloques consecutivos del modelo a GPUs distintas y las encadena con micro-batches. PyTorch las ofrece como torch.distributed.tensor.parallel y torch.distributed.pipelining, y torchtitan las compone con FSDP en lo que se llama paralelismo "3D" o "4D" — la receta con la que hoy se entrenan los modelos de cientos de miles de millones de parámetros.

5. Errores comunes en entrenamiento distribuido

Los bugs multi-GPU rara vez son de matemática — son de coordinación entre procesos que corren el mismo script.

6. Resumen — cierre de PyTorch

1. PyTorch ganó apostando por ejecución eager cuando TensorFlow apostaba por grafos estáticos — más fácil de debuggear, más rápido de iterar para investigación. La idea (define-by-run) venía de Chainer; la ejecución y el ecosistema fueron de PyTorch.
2. El efecto de red (papers → tutoriales → ingenieros formados) se retroalimentó solo, incluso después de que TensorFlow 2.0 adoptara eager también — y la migración rota de TF1 a TF2 empujó en la misma dirección.
3. PyTorch resolvió el costo de performance de eager sin sacrificar la ergonomía — torch.compile es opcional y aditivo, no un cambio de paradigma forzado. La cronología: 2015 TF, 2017 PyTorch, 2018 1.0, 2019 TF2, 2022 Foundation, 2023 2.0.
4. El ecosistema completo de este curso (HF Transformers, fastai/miniai, vLLM, Diffusers, PEFT, torchao) corre sobre la misma base — investigación y producción comparten framework, y el state_dict es la interfaz común.
5. DDP y FSDP escalan el mismo nn.Module sin reescribirlo — de una GPU a un cluster, la arquitectura del modelo no cambia. DDP replica (16 bytes/parámetro con AdamW); FSDP shardea (1/N); tensor y pipeline parallelism cubren lo que ni FSDP alcanza.
6. Los bugs distribuidos son de coordinación: set_epoch, batch global vs por GPU, logging y checkpoints solo desde rank 0, parámetros sin usar, ranks que divergen.

7. Ponete a prueba

Respondé antes de abrir cada respuesta. Si fallás una, volvé a la sección indicada.

8. Para practicar

import os, torch, torch.nn as nn, torch.distributed as dist
from torch.nn.parallel import DistributedDataParallel as DDP
from torch.utils.data import DataLoader, DistributedSampler, TensorDataset

dist.init_process_group("gloo")
rank, world = dist.get_rank(), dist.get_world_size()
torch.manual_seed(0)                                  # DDP igual copia los pesos de rank 0

ds = TensorDataset(torch.arange(16).float().unsqueeze(1), torch.arange(16).float().unsqueeze(1) * 2)
sampler = DistributedSampler(ds)
loader = DataLoader(ds, batch_size=4, sampler=sampler)
model = DDP(nn.Linear(1, 1))
opt = torch.optim.SGD(model.parameters(), lr=1e-3)

for epoch in range(2):
    sampler.set_epoch(epoch)
    vistos = []
    for X, y in loader:
        vistos += X.flatten().int().tolist()
        loss = ((model(X) - y) ** 2).mean()
        loss.backward(); opt.step(); opt.zero_grad()
    print(f"epoch {epoch} rank {rank}/{world} vio {vistos}  peso={model.module.weight.item():.5f}")

dist.destroy_process_group()

9. Fuentes y para seguir

• PyTorch: An Imperative Style, High-Performance Deep Learning Library (Paszke et al., NeurIPS 2019, arXiv:1912.01703) — el paper de diseño: los principios (Pythonic, investigadores primero, performance pragmática), el reconocimiento a Chainer y DyNet, y cómo se implementa autograd y el manejo de memoria.
• PyTorch 2.0 — overview técnico y PyTorch 2.0: Our next generation release (marzo 2023) — la motivación de torch.compile, los benchmarks y la cronología del release.
• Getting Started with Distributed Data Parallel y Distributed Data Parallel — notes — el tutorial y la nota de diseño: cómo se solapa el all-reduce con el backward, los buckets de gradientes y find_unused_parameters.
• Getting Started with Fully Sharded Data Parallel — el tutorial oficial de FSDP (actualizado a FSDP2 / fully_shard), con el ejemplo de mixed precision y checkpointing distribuido.
• ZeRO: Memory Optimizations Toward Training Trillion Parameter Models (Rajbhandari et al., 2019, arXiv:1910.02054) — el paper de DeepSpeed que formalizó la cuenta de 16 bytes por parámetro y los tres stages de sharding que FSDP implementa.
• torchtitan y el blog de la PyTorch Foundation — el primero para ver FSDP2 + TP + PP compuestos en código real de pre-entrenamiento; el segundo para los anuncios de cada release y los posts técnicos de los equipos de compile y distributed.