Entrenamiento distribuido en 2026: DDP, FSDP2, DeepSpeed, Megatron y los cinco ejes del paralelismo

En cuanto tiene más de una GPU en un equipo, hay que tomar una decisión. Hoy dominan el entrenamiento distribuido cuatro stacks de código abierto —PyTorch DDP, PyTorch FSDP2, Microsoft DeepSpeed y NVIDIA Megatron-Core—, a los que se suma TorchTitan como nueva referencia para el entrenamiento a gran escala nativo de PyTorch. Cada uno resuelve un problema distinto. Elegir mal cuesta semanas: o el modelo no cabe y usted se entera en el paso 30 con un fallo por falta de memoria, o ha sobredimensionado la ingeniería para una carga que DDP habría resuelto con una décima parte del esfuerzo.

Este artículo es la visión de comprador y arquitecto del entrenamiento distribuido. Recorre los cinco ejes de paralelismo, los cuatro (ahora cinco) frameworks que los combinan y las recetas que de verdad funcionan en hardware de clase Kentino: sobre todo 4× y 8× RTX 5090, 4090 y RTX Pro 6000 Blackwell en hosts AMD EPYC, con PCIe Gen5 y Ethernet convencional o InfiniBand entre nodos. La conclusión honesta va al principio para que el resto del artículo no tenga que seguir demostrándola: la mayoría de los clientes de Kentino hacen ajuste fino, no preentrenamiento, y FSDP2 en un único nodo de 8 GPU cubre el 90% de las necesidades de ajuste fino. Megatron-Core y el paralelismo 3D solo compensan cuando se preentrena desde cero por encima de la escala de 30B, y ese club es mucho más reducido de lo que da a entender el marketing.

Los cinco ejes

Todo framework moderno de entrenamiento distribuido compone algún subconjunto de los mismos cinco ejes de paralelismo. No son alternativas: las recetas de modelos grandes combinan tres o cuatro a la vez. Lea la columna de comunicación de arriba abajo; ahí está todo el juego.

DP grita una vez por paso. TP grita dos veces por capa. PP susurra una vez por etapa. SP/CP grita una vez por bloque de atención, pero a lo largo de otra dimensión. EP hace all-to-all solo en las capas MoE activas. Esa única columna decide dónde vive cada eje: dentro de una máquina rápida o a través de un tejido más lento.

El «paralelismo 3D» que aparece en todos los blogs de NVIDIA es DP × TP × PP. Añada SP y EP y pasa a ser 4D o 5D, lo cual es más un juego de notación que un cambio arquitectónico. Lo que importa es la distribución: TP dentro del nodo (donde el ancho de banda es barato), PP entre nodos (donde es caro) y DP por encima para escalar el rendimiento. SP se coloca junto a TP; EP solo se aplica a MoE.

Referencias cruzadas: el ancho de banda intranodo del paralelismo tensorial se desglosa en K07, la penalización de NVLink frente a PCIe en N03 y el tejido entre nodos en N08.

DDP: cuando el modelo cabe y usted solo quiere más rendimiento

PyTorch DDP (DistributedDataParallel) es la respuesta más antigua, más sencilla y aún correcta cuando el modelo cabe en una GPU. Cada rango guarda una copia completa del modelo y del estado del optimizador. En cada paso, cada rango hace su propio forward, su backward y su cálculo de gradientes sobre su micro-lote. Después, un único all-reduce suma los gradientes entre rangos y todos aplican la misma actualización.

DDP en PyTorch 2.x es el mismo DDP de siempre, con dos mejoras que merece la pena señalar: una ruta static_graph=True más robusta para grafos compatibles con el compilador y una integración más estrecha con torch.compile. El patrón de comunicación no cambia: un all-reduce por paso, solapado con el backward, y escala de forma lineal hasta que el all-reduce domina.

Cuándo DDP es la respuesta correcta:

• El modelo completo + los estados del optimizador + las activaciones caben en una GPU. Para optimizadores de tipo Adam con pesos maestros en FP32, la regla general es unos 16 bytes por parámetro de memoria solo para el estado entrenable (4 bytes de pesos, 4 de gradientes y 8 del optimizador), más las activaciones. Un modelo de 8B = 128 GB de estado, que cabe en una sola RTX Pro 6000 Blackwell (96 GB) únicamente con precisión mixta y pesos maestros en BF16. Por debajo de 8B parámetros, DDP va holgado en una sola 5090; por encima, mire hacia FSDP2.
• Busca el máximo rendimiento, no el máximo tamaño de modelo. DDP tiene la menor relación comunicación/cómputo de todos los enfoques de paralelismo de datos, porque los gradientes se reducen una vez por paso, después de todo el trabajo local del backward.
• Está haciendo rollouts de aprendizaje por refuerzo, LoRA o cualquier montaje en el que cada rango guarde un pequeño adaptador entrenable sobre pesos base congelados.

Cuándo DDP es un error: cuando el modelo no cabe. La solución no es «un lote más pequeño». La solución es FSDP2.

torchrun --standalone --nproc-per-node=8 train.py

Ese es todo el lanzador. DDP es la opción aburrida por defecto de la que todo el mundo se olvida y, para la carga adecuada, es lo más rápido que puede ejecutar.

FSDP2: el nuevo estándar para todo lo que DDP no puede con

FSDP (Fully Sharded Data Parallel) reparte en fragmentos los parámetros del modelo, los gradientes y los estados del optimizador entre el grupo de paralelismo de datos. Cada GPU almacena 1/N de los parámetros. Para hacer un forward, el rango reúne con all-gather la capa que necesita en ese momento, ejecuta el cómputo y descarta los pesos reunidos. La memoria cae aproximadamente N veces frente a DDP; la comunicación sube, porque cada capa se reúne y se vuelve a reunir.

La historia de 2025 es FSDP2. El FSDP original (FSDP1) envolvía grupos de parámetros en un único FlatParameter, lo que hacía doloroso o imposible razonar sobre el comportamiento de cada parámetro: congelación parcial, tipos mixtos, ajustes del optimizador por parámetro. FSDP2 reescribió las tripas sobre DTensor: cada tensor sigue siendo un torch.Tensor real que, simplemente, está fragmentado por su dimensión 0 entre los rangos. La API de cara al usuario pasó de FSDP(model, ...) a fully_shard(model, ...).

Lo que FSDP2 aporta de verdad frente a FSDP1, según las pruebas publicadas y nuestras propias ejecuciones:

• ~7% menos de memoria de GPU en Llama 2 7B con la misma configuración, porque FSDP2 evita el patrón record_stream, que fijaba memoria de forma pesimista.
• ~1.5% más de rendimiento en igualdad de condiciones, y hasta un 50% de aceleración cuando se combina con torch.compile y el entrenamiento en float8 de torchao en hardware de clase Hopper.
• Diccionarios de estado fragmentados que cargan rápido y se vuelven a fragmentar limpiamente entre distintas distribuciones de paralelismo: el formato de checkpoint de FSDP1 era célebre por lo difícil que resultaba reconvertirlo entre entrenamiento e inferencia.
• Congelación parcial de parámetros sin acrobacias, algo que importa en LoRA y en el entrenamiento de adaptadores.

FSDP1 está obsoleto desde PyTorch 2.11. Todo trabajo nuevo debería usar fully_shard. El antiguo envoltorio FullyShardedDataParallel sigue existiendo por compatibilidad, pero está camino de desaparecer.

FSDP2 expone además dos estrategias de fragmentación que deciden dónde vive el modelo:

• Full shard. Parámetros totalmente fragmentados entre todos los rangos (el valor por defecto de FSDP1). Memoria mínima, comunicación máxima.
• Hybrid shard. Parámetros fragmentados dentro de un nodo y replicados entre nodos. Dentro del nodo, la comunicación va por PCIe/NVLink (rápido). Entre nodos, solo el all-reduce de gradientes cruza el tejido lento. Es el punto óptimo para 2-4 nodos con Ethernet/IB de 100/200 Gbps.

Cuándo FSDP2 es la respuesta correcta (el caso más habitual en Kentino):

• Ajuste fino de 8B-70B en un nodo de 8 GPU. Full shard, BF16, gradient checkpointing activado, torch.compile. Listo.
• Ajuste fino de 70B-405B repartido en 2-4 nodos. Hybrid shard con full shard dentro de cada nodo y réplica entre ellos.
• Cualquier cosa con LoRA / QLoRA: el tratamiento por parámetro de FSDP2 gana aquí de calle a FSDP1.

from torch.distributed.fsdp import fully_shard, MixedPrecisionPolicy

mp = MixedPrecisionPolicy(param_dtype=torch.bfloat16, reduce_dtype=torch.float32)
for block in model.transformer_blocks:
    fully_shard(block, mp_policy=mp)
fully_shard(model, mp_policy=mp)

Se lanza igual que DDP, con torchrun. Lo único que cambia es el envoltorio.

DeepSpeed y los niveles ZeRO: siguen ahí, ya no son el estándar

DeepSpeed es el stack de entrenamiento distribuido de Microsoft. Su gran mérito fue ZeRO (Zero Redundancy Optimizer), que llegó años antes que FSDP y definió el enfoque moderno de fragmentarlo todo.

ZeRO-3 equivale arquitectónicamente al full shard de FSDP. Resuelven el mismo problema con las mismas primitivas de comunicación.

La realidad en 2025-2026: FSDP2 le ha comido la tostada a DeepSpeed en el caso de uso de los LLM densos. Es nativo de PyTorch, no requiere paquetes extra, se integra con torch.compile y la misma receta se traslada a Hugging Face Transformers, Accelerate y TorchTitan. Las pruebas internas de Lightning y de Hugging Face muestran el full shard de FSDP funcionando de 2 a 5× más rápido por iteración que ZeRO-3 en algunos montajes, aunque DeepSpeed recupera terreno en modelos muy grandes (más de 10B), donde sus rutas de descarga a CPU y a NVMe siguen siendo realmente útiles.

Vale la pena conocer DeepSpeed por tres motivos:

1. Descarga ZeRO-Infinity. Si tiene que ajustar un modelo que no cabe en absoluto en la memoria agregada de GPU —por ejemplo, un base de 405B en una máquina con 4× RTX Pro 6000 Blackwell—, DeepSpeed puede descargar parámetros a la RAM del sistema (barata y lenta) y a NVMe (más barata y mucho más lenta). FSDP también tiene descarga a CPU, pero la ruta a NVMe de DeepSpeed está más madura. Útil para el «tengo una sola máquina y un modelo testarudo»; no es la respuesta correcta si puede alquilar o comprar un segundo nodo.
2. Paralelismo de secuencia DeepSpeed-Ulysses. Un esquema de paralelismo de secuencia eficiente en comunicación que usa all-to-all en lugar de all-gather en anillo para la atención. Demostrado con contextos de hasta 1M de tokens en 64 A100 y entrenando Llama-8B con 15M de tokens de contexto en 32 H100 en trabajos publicados en 2025. Si va específicamente a por entrenamiento con contexto muy largo, Ulysses sigue por delante de la implementación de paralelismo de contexto de Megatron para algunas formas.
3. DeepSpeed-MoE. Entrenamiento de mixturas de expertos con paralelismo de expertos. Poco relevante para el ajuste fino; muy relevante si está preentrenando MoE.

Para la mayor parte del ajuste fino de los clientes de Kentino, la decisión correcta es FSDP2, salvo que tenga un motivo concreto para recurrir a DeepSpeed (contexto largo, descarga a CPU/NVMe, preentrenamiento de MoE). La inercia del ecosistema apunta sin ambigüedad hacia FSDP2.

Megatron-LM, Megatron-Core, NeMo: donde vive la artillería pesada

Megatron nació como el artículo de NVIDIA sobre Transformers con paralelismo tensorial en 2019. Hoy la familia tiene tres capas:

• Megatron-LM: la base de código original de investigación. Se sigue usando y se sigue actualizando.
• Megatron-Core: la versión de biblioteca modular. Bloques componibles para TP/PP/DP/EP/CP, precisión mixta (FP16/BF16/FP8/FP4) y arquitecturas de transformer de referencia. Es lo que se integra de verdad.
• NVIDIA NeMo: el framework de extremo a extremo construido sobre Megatron-Core. Recetas, pipelines de datos, alineamiento y despliegue.

Megatron-Core es el framework que gana en la gama más alta, precisamente porque implementa paralelismo tensorial, de pipeline, de secuencia, de contexto y de expertos en una única malla componible. Cuando entrena un modelo denso de 405B en más de 512 GPU no puede evitar combinar al menos tres de ellos, y Megatron-Core es la combinación más desplegada y más probada.

Las recomendaciones de paralelismo de Megatron para 2026, según la propia documentación de NVIDIA, encajan con la realidad del hardware:

Esa tabla explica por qué existe Megatron. Es el framework cuyos autores conviven con las cuentas de ancho de banda que describimos en N03 y K07, y sus recetas están afinadas para ello.

Dónde Megatron es exagerado: en cualquier ajuste fino en un solo nodo, en cualquier modelo que quepa en una memoria cómoda para FSDP2 y en cualquier carga en la que no necesite TP. La maquinaria de TP de Megatron es realmente más rápida que un TP casero sobre PCIe, pero el TP sobre PCIe sigue siendo lento: vea las cifras de K07. La fuerza de Megatron está en hardware SXM, que Kentino no fabrica.

Dónde Megatron es la respuesta correcta: preentrenar modelos densos de 70B-405B o más en hardware de clase NVLink, alquilado o propio, o construir infraestructura de entrenamiento en producción para un laboratorio de investigación. Si ese es su caso, probablemente ya esté dentro del ecosistema NeMo.

TorchTitan: la nueva referencia

TorchTitan es la referencia de entrenamiento a gran escala nativa de PyTorch creada por Meta, aceptada en ICLR 2025 y hoy el ejemplo de facto de «¿cómo debería ser una receta TP × PP × FSDP2 × CP en 2026?». No inventa paralelismos nuevos: compone los bloques que PyTorch ya incluye (fully_shard, torch.distributed.tensor.parallel, pipelining, DTensor) en un script de entrenamiento paralelo en cuatro dimensiones, limpio, con checkpointing fragmentado asíncrono, torch.compile y float8.

Por qué importa aunque usted no lo use directamente:

• Es el ejemplo canónico de cómo FSDP2 se compone con TP y PP sin frameworks de terceros.
• Las mismas API vienen en PyTorch de serie. No hay magia.
• AMD publicó un fork optimizado de TorchTitan para ROCm a finales de 2025; la alianza con Lightning AI anunciada en octubre de 2025 permite ejecutar las recetas de TorchTitan en Lightning Studios.

Para los clientes de clase Kentino, TorchTitan es más una referencia que leer que un framework que desplegar. Si hace ajuste fino, Accelerate o Axolotl sobre FSDP2 resultan más ergonómicos. Si preentrena a escala modesta (8-64 GPU) en hardware convencional, TorchTitan compite con NeMo y pesa bastante menos en lo operativo.

La matriz de frameworks

Accelerate y Axolotl no son estrategias de paralelismo aparte: envuelven los backends anteriores. La mayoría de los clientes de ajuste fino de Kentino acabarán usando Axolotl sobre FSDP2 sin pensarlo, y eso es lo correcto.

El presupuesto de comunicación: por qué su red limita el modelo

Referencia cruzada: N08 recorre las cuentas de RDMA y de enlace ascendente; esta es la visión específica del entrenamiento.

En paralelismo de datos (DDP o FSDP), la comunicación entre rangos por paso es aproximadamente proporcional al número de parámetros (gradientes que reducir). En paralelismo tensorial es proporcional al tamaño de las activaciones × número de capas, órdenes de magnitud mayor por paso.

Volumen de gradientes orientativo para un solo paso en BF16:

Solo el all-reduce de un 70B son 5.6 segundos en un tejido de 200 Gbps. Si su cómputo de forward+backward en un paso también son 5 segundos, ya está limitado por la comunicación en un 50%; si el cómputo son 2 segundos, pasa más del 70% del tiempo esperando a la red. Por eso 100 GbE ahoga el entrenamiento de 70B o más y hace falta 400 GbE o NDR IB. El cómputo no deja de acelerarse; la red tiene que seguirle el ritmo o las GPU se quedan paradas.

FSDP2 oculta parte de esto con solapamiento (empieza a reunir la siguiente capa mientras calcula la actual). El hybrid shard oculta más al mantener el all-reduce de gradientes dentro del tejido rápido intranodo y reducir solo los gradientes replicados entre nodos. Las cifras anteriores son el peor caso para un FSDP full shard entre nodos sin solapamiento.

En paralelismo tensorial, la comunicación por token escala con el tamaño oculto y el número de capas. Las cifras de K07 muestran por qué: ~80 MB por token generado durante el decodificado y ~300 GB por prefill en un 70B con lote 32. Este es el régimen en el que PCIe (50 GB/s realistas) resulta unas 14× más lento que NVLink (700 GB/s o más realistas), y en el que preentrenar un modelo denso de 70B o más sobre PCIe sencillamente no funciona con una eficiencia aceptable.

Recetas reales

Ajuste fino de Llama 8B, un nodo de 8 GPU — FSDP2

Hardware: 8× RTX 5090 u 8× RTX Pro 6000 Blackwell, host EPYC, sin necesidad de tejido entre nodos.

torchrun --standalone --nproc-per-node=8 \
  finetune.py \
    --model meta-llama/Llama-3.1-8B \
    --batch-size 1 --grad-accum 16 --seq-len 4096 \
    --bf16 --fsdp full_shard --fsdp-reshard-after-forward \
    --gradient-checkpointing --torch-compile

Lo esperable: ~2000 tok/s agregados en BF16, cabe con holgura junto a KV y activaciones, y el full shard de FSDP2 sobre PCIe Gen5 se encarga del all-reduce de gradientes dentro de la máquina. Así es también el 90% de los trabajos de ajuste fino de Kentino.

Ajuste fino de Llama 70B, 2 nodos de 8 GPU — hybrid shard de FSDP2

Hardware: 2× 8× RTX Pro 6000 Blackwell, IB de 200 Gbps o RoCE de 100 GbE entre nodos.

torchrun --nnodes=2 --nproc-per-node=8 \
  --rdzv-backend=c10d --rdzv-endpoint=node0:29500 \
  finetune.py \
    --model meta-llama/Llama-3.3-70B \
    --batch-size 1 --grad-accum 32 --seq-len 4096 \
    --bf16 --fsdp hybrid_shard \
    --gradient-checkpointing --torch-compile \
    --activation-cpu-offload

El hybrid shard mantiene el full shard dentro de cada nodo de 8 GPU y replica entre los 2 nodos. El tejido entre nodos solo transporta el reduce-scatter de los gradientes replicados: unos 70 GB por paso en BF16, ~3 s con IB de 200 Gbps. El solapamiento oculta casi todo. Con 100 GbE el mismo paso cuesta ~5-6 s y las GPU empiezan a mostrar tiempo muerto; la receta sigue funcionando, solo que cada época tarda más.

Preentrenamiento de 405B, 8 nodos de 8 GPU — Megatron-Core 3D

Hardware: 8 nodos NVLink/SXM de 8 GPU, IB NDR de 400 Gbps. No lo fabrica Kentino; se incluye para completar el cuadro.

# Lanzador de Megatron-Core (abreviado)
torchrun --nnodes=8 --nproc-per-node=8 \
  pretrain_gpt.py \
    --tensor-model-parallel-size 8 \
    --pipeline-model-parallel-size 8 \
    --sequence-parallel \
    --context-parallel-size 1 \
    --num-layers 126 --hidden-size 16384 --num-attention-heads 128 \
    --seq-length 8192 --micro-batch-size 1 --global-batch-size 2048 \
    --bf16 --use-flash-attn --transformer-impl transformer_engine

TP=8 × PP=8 = 64 rangos por réplica; 8 nodes × 8 GPUs = 64 GPUs en total, exactamente una réplica. Para escalar a varias réplicas y ganar rendimiento, multiplique por DP. Aquí es donde Megatron se gana el sueldo. El mismo modelo solo con FSDP2 pasaría la mayor parte del tiempo comunicando entre rangos; la distribución 3D mete la comunicación más pesada (TP) dentro del dominio NVLink.

Nuestra opinión sincera para los clientes de Kentino

La mayoría de los clientes de Kentino no preentrenan. Ajustan modelos base de pesos abiertos —Llama, Qwen, Mistral, a veces Gemma— con sus datos de dominio, en ocasiones con LoRA o QLoRA y en ocasiones con ajustes finos completos. Para ese trabajo, la elección de framework es así:

• Un modelo que cabe en una GPU en BF16, con el estado del optimizador. Use DDP. Replique copias para ganar rendimiento.
• Un modelo que no cabe en una GPU pero sí en el agregado de un nodo de 8 GPU. Use el full shard de FSDP2. Esto cubre los ajustes finos de 8B-70B.
• Un modelo que cabe en el agregado de dos nodos de 8 GPU. Use el hybrid shard de FSDP2. Ajustes finos de 70B-200B.
• Un modelo mayor que eso, o preentrenamiento desde cero. Esta es la conversación en la que encajan Megatron-Core, el hardware SXM y el IB NDR. Nosotros construiremos el almacenamiento y el plano de gestión, pero para esa fase las GPU suelen alquilarse.

Ese 10% de clientes que necesitan de verdad entrenamiento multinodo fuertemente acoplado son, sobre todo, laboratorios de investigación con programas de preentrenamiento financiados, y saben lo que necesitan antes de llamar. Al otro 90% no hay que venderle un clúster: hay que venderle un nodo de 8 GPU bien dimensionado, con la toma de tejido preparada para un segundo nodo futuro, y dejar el equipamiento de red como una partida de prioridad 2.

---

Esto forma parte de la Kentino Wiki, una serie de referencia sobre computación de IA, robótica y los sistemas que las conectan. Comentarios y correcciones son bienvenidos en info@kentino.com.