2025-05-04 · Actualizado 2026-07-15

[!NOTE] Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Escalado de modelos de lenguaje grandes: estrategias multi-GPU y multi-nodo que funcionan en la práctica

Las cargas de trabajo con modelos grandes trascienden el uso de un único GPU por distintas razones. Un proceso de entrenamiento puede quedarse sin memoria debido al estado del optimizador, otro lo hace a causa de las activaciones de secuencias largas, y aun un modelo que cabe en los recursos puede no alcanzar su objetivo de rendimiento. Cada problema exige un patrón de particionamiento y comunicación diferente.

Se trata de una explicación práctica de las principales estrategias de paralelismo y de las limitaciones que las condicionan, basada en los principios establecidos por Hugging Face’s Guía de implementación a ultraescala. El objetivo es mostrar qué aporta cada división, qué información transmite y cuándo resultan necesarias las combinaciones.

TL;DR. El paralelismo de datos replicado aumenta el rendimiento del entrenamiento siempre que cabe una réplica. El paralelismo de datos completamente shardizado divide el estado del modelo, pero implica operaciones adicionales como recopilación total de parámetros y dispersión/reducción de gradientes. El paralelismo de tensores, pipeline, de contexto y de expertos divide las operaciones matemáticas de las capas, la profundidad, las secuencias y los expertos MoE. Solo se deben combinar estos enfoques tras identificar las restricciones de memoria o de comunicación vinculantes.

Esta guía parte de la premisa de que ya tienes conocimientos sólidos sobre la retropropagación, las capas Transformer y un bucle de entrenamiento estándar PyTorch.

Comience con dos presupuestos de memoria

El entrenamiento y la inferencia no presentan el mismo consumo de recursos.

training peak ≈ parameters
              + gradients
              + optimizer state
              + saved activations
              + temporary buffers
              + communication buffers
              + allocator headroom

inference peak ≈ resident weights
               + KV cache
               + runtime workspace
               + communication buffers
               + allocator headroom

Un modelo de 70 mil millones de parámetros requiere como mínimo 140 GB en formato decimal solo para los pesos de BF16. Dicha cifra proporciona poca información sobre el proceso de entrenamiento, donde los gradientes, el estado del optimizador, los pesos maestros y las activaciones suelen tener un papel predominante. Tampoco refleja el tamaño necesario para serving, ya que en este caso son decisivos la política de caché, la longitud de las secuencias, la concurrencia por lotes y la cuantización.

Perfile la arquitectura exacta, la precisión, la longitud de secuencia, el tamaño de los micro lotes, el optimizador, la política de guardado de puntos de control, y runtime. Registre la memoria máxima asignada y reservada, los tokens por segundo, el tiempo de ejecución en los kernels, y el tiempo que permanece expuesto en los collectives.

Cada dimensión paralela implica un compromiso

La pregunta relevante no es «¿Cuál es la técnica mejor?», sino «¿Qué dimensión del tensor se divide, qué estado se replica y qué colectivo entra en la ruta crítica?».

Estrategia	Divisiónes	Alivio primario	Comunicación establecida
Paralelismo de datos replicado	lote	rendimiento de entrenamiento	reducción global por gradiente
Paralelismo de datos completamente shardizado	parámetros, gradientes y estado del optimizador en un grupo de DP	memoria de estado del modelo	parámetro all-gather, reducción de gradiente por scatter
Paralelismo de tensores	dimensiones de la matriz o de atención dentro de las capas	pesos y activaciones de capa	conjuntos dentro de los bloques Transformer
Pipeline paralelismo	grupos de capas	profundidad del modelo y estado por etapa	activaciones punto a punto más burbujas de programación
Paralelismo de contexto	dimensión de secuencia	memoria de activación para secuencias largas	Intercambio de clave/valor o de atención a lo largo del grupo de secuencias
Paralelismo experto	MoE expertos y tokens enrutados	Capacidad de experto por rango	envío y combinación de tokens, habitualmente de tipo todos-con-todos

La reducción de memoria no es un multiplicador fijo. Depende del grado de sharding, de lo que queda replicado, del estado transitorio sin sharding, de la política de activación, del relleno, del desequilibrio y de los buffers.

Paralelismo de datos replicado: rendimiento sin limitaciones de capacidad

Entrenamiento en paralelo con datos replicados

El paralelismo de datos distribuido mantiene una réplica completa del entrenamiento en cada nodo. Cada nodo procesa un micro-lote distinto, y los gradientes se sincronizan antes de ejecutar el paso del optimizador.

Úsalo cuando el estado completo de entrenamiento cabe sin problemas y existe margen suficiente, permitiendo que el lote global crezca o que la acumulación de gradientes se ajuste. Sus principales ventajas son una semántica sencilla y una integración consolidada entre el cálculo hacia atrás y la reducción de gradientes por bloques.

La adición de rangos puede ser perjudicial si el lote local se vuelve demasiado pequeño, la red no puede ocultar la operación all-reduce, se producen retrasos en la entrega de las entradas, o el lote de optimización deseado no es escalable.

Paralelismo de datos completamente shardizado: memoria de estado para colectivos

Ejecución paralela de datos completamente shardizada

La documentación actual de PyTorch diferencia las características de FSDP2 fully_shard API proveniente de las versiones anteriores FullyShardedDataParallel envoltorio. FSDP2 agrupa la comunicación según los módulos a los que fully_shard Se aplica este enfoque y se recomienda su implementación de abajo hacia arriba, de modo que los grupos de capas puedan superponer la comunicación y el cálculo.

from torch.distributed.fsdp import fully_shard


# Apply bottom-up: each block becomes a communication group.
for block in model.transformer.blocks:
    fully_shard(block)

# Shard remaining root parameters such as embeddings and output projection.
fully_shard(model)

# Construct the optimizer after parameters have become sharded DTensors.
optimizer = AdamW(model.parameters(), lr=learning_rate)

Se trata de un boceto estructural, no de un lanzador completo. Las mallas de dispositivos, la precisión mixta, el guardado de puntos intermedios, la inicialización, el estado del optimizador y la implementación distribuida de checkpoints deben coincidir con la pila de entrenamiento.

El sharding resulta atractivo cuando el estado del modelo constituye la restricción determinante y el procesamiento en capas permite ocultar una cantidad suficiente de tráfico colectivo. Sin embargo, puede ser una opción poco adecuada para modelos pequeños, conexiones lentas, capas reducidas o diseños cuyo grupo de shards cruza los límites topológicos inadecuados.

Paralelismo de tensores: matemática de particionamiento de capas

Partición de capa paralela de tensores

El paralelismo de tensores divide las operaciones de álgebra lineal dentro de una capa; por ejemplo, las proyecciones columnar y horizontalmente paralelas. Los resultados parciales necesitan mecanismos de recolección dentro de los bloques de transformador, por lo que la latencia y el ancho de banda son factores cruciales en cada uno de los pasos hacia adelante y hacia atrás.

Úsalo cuando una capa o sus activaciones no caben en el espacio disponible, o cuando las operaciones de multiplicación matricial son lo suficientemente intensas como para que los núcleos particionados ofrezcan un rendimiento superior al de un único núcleo. Asigna el grupo de tensores paralelos al dominio de comunicación más rápido del que se disponga y, a continuación, realiza mediciones. Un grado elevado puede reducir el tamaño de cada matriz local hasta que disminuya la eficiencia del núcleo, al tiempo que aumenta la sobrecarga colectiva.

El paralelismo por secuencias se combina con frecuencia con el paralelismo por tensores para evitar la duplicación de ciertos cálculos de activación; difiere del paralelismo por contexto, que se aplica a toda la secuencia de entrada del modelo.

Pipeline Paralelismo: profundidad de partición y tiempo de programación

Pipeline etapas paralelas y microlotes

El Pipeline permite distribuir diferentes grupos de capas en etapas distintas y enviar las activaciones entre ellas. Los micro-lotes garantizan que dichas etapas funcionen de forma concurrente.

Alivia el estado del modelo por etapa y permite reducir el volumen de comunicación que atraviesa una frontera con menor velocidad, en comparación con los métodos de recolección de tensores por capa. Sus costes incluyen la generación de “burbujas”, las transferencias de activaciones, el desequilibrio entre etapas, una planificación más compleja, así como una recuperación y creación de puntos de control más difíciles.

Para un horario sencillo y equilibrado al estilo GPipe con p etapas y m Los micro-lotes: la fracción idealizada de burbuja hacia adelante es aproximadamente:

(p - 1) / (m + p - 1)

Los horarios reales pueden emplear variantes de tipo uno-adelante/uno-atrás, entrelazado o sin burbujas, y el costo desigual de las capas puede tener un impacto dominante en la fórmula. Es necesario seleccionar los límites entre etapas en función del tiempo y la memoria medidos, y no en base a un número igual de capas.

Paralelismo de contexto: particionamiento de activaciones de secuencias largas

Intercambio de atención paralelo en contexto

El paralelismo de contexto permite distribuir la dimensión de secuencia. Cada nodo gestiona un fragmento de dicha secuencia, mientras que la atención intercambia la información necesaria para mantener la semántica del contexto completo. Las implementaciones pueden recurrir a topologías en anillo punto a punto, algoritmos de tipo all-gather, all-to-all, o combinaciones jerárquicas.

Reduce la memoria de activación necesaria para el entrenamiento con contextos extensos, pero replica los pesos en todo el grupo de contexto e introduce mecanismos de comunicación por atención. El beneficio depende del tipo de atención utilizado, del enmascaramiento causal, de la longitud de la secuencia, de las recálculaciones, y de cómo se combinan los grupos de contexto con los grupos paralelos a tensores y datos.

No lo seleccione a partir de umbral universal de 8K, 32K o 100K. Utilice la memoria de activación del perfil y la comunicación de atención adaptadas a la arquitectura concreta.

Paralelismo experto: exclusivo para una arquitectura MoE

Ruteo de tokens en paralelo por expertos

El paralelismo experto distribuye los expertos en las capas de mezcla de expertos. El enrutador envía representaciones de tokens a los expertos seleccionados y combina sus resultados. Solo los expertos elegidos realizan cálculos para cada token, pero los pesos totales de los expertos siguen requiriendo almacenamiento y ubicación en serving.

Se trata de un elemento que forma parte de la arquitectura MoE y no es un interruptor de optimización destinado a modelos densos. Este componente gestiona el equilibrio de carga, la capacidad de procesamiento, la comunicación token a token entre todos los nodos, los tokens descartados o rellenos, las pérdidas auxiliares, así como las desviaciones en caso de fallos. Permite hacer un seguimiento del número de tokens por experto, de la entropía de enrutamiento, de los desbordes de capacidad, del tiempo de comunicación y de la calidad según la ruta utilizada.

Componer un diseño a partir de la topología

Los sistemas de entrenamiento a gran escala combinan distintas dimensiones. El tamaño total del mundo suele seguir una forma de producto, como por ejemplo:

world size = DP × TP × PP × CP

El paralelismo experto puede compartir o plegar las dimensiones de manera distinta; por lo tanto, es necesario verificar la malla compatible con el framework en lugar de realizar operaciones de multiplicación de forma indiscriminada.

Construye el diseño en este orden:

Dibujar los dominios de comunicación: enlaces GPU-a-GPU, conmutadores, límites NUMA, estructura de nodos, sobresuscripción y ruta de almacenamiento.
Colocar los conjuntos que requieren baja latencia con frecuencia, como suelen ser los TP, en el dominio más rápido y adecuado.
Elegir FSDP o grupos DP replicados a partir de la capacidad y ancho de banda restantes.
Añadir PP cuando sea beneficioso debido a la colocación por profundidad o al tráfico entre dominios, equilibrando el tiempo de procesamiento medido y el uso de memoria.
Añadir CP únicamente por la restricción de secuencia, y EP únicamente por la topología especializada del modelo.
Verificar que las dimensiones de cabezas, dimensiones ocultas, capas, expertos, lotes y secuencias sean divisibles para la malla candidata.
Benchmark genera varias mallas válidas; las heurísticas conscientes de la topología seleccionan candidatos, no al mejor resultado.

Dos clústeres que presentan el mismo valor en GPU pueden optar por diseños diferentes, ya que varían la anchura de banda de los enlaces, la jerarquía de los conmutadores, la conexión mediante CPU y la contención de red.

El entrenamiento y serving requieren decisiones independientes

La inferencia normalmente no transporta gradientes ni el estado del optimizador, por lo que los esquemas de entrenamiento al estilo FSDP no se transfieren automáticamente.

Para serving, pregunte:

¿Una única réplica es suficiente para gestionar los pesos, KV cache, el espacio de trabajo y la concurrencia de destino?
¿El rendimiento es mejor logrado con más réplicas independientes o mediante la partición de una sola réplica?
¿El TP reduce lo suficiente la carga de pesos por rango y la presión en la caché como para compensar las comunicaciones entre capas?
¿El PP se puede implementar de forma eficiente tanto para el modelo como para el planificador de solicitudes?
¿De qué manera prefill y el proceso de decodificación afectan de forma distinta el consumo de memoria, el ancho de banda y las interconexiones?
¿Qué ocurre con la latencia en casos extremos cuando las solicitudes presentan longitudes diferentes de prompt y de salida?

Benchmark el servidor completo que incluye el planificador, la cuantización, la distribución de contexto, la política de agrupamiento y la configuración del tráfico. La cantidad de tokens de entrenamiento por segundo no permite predecir el serving tiempo necesario hasta obtener el primer token ni la latencia entre tokens.

Medir con precisión un diseño escalable

Para cada candidato, registre:

modelo, código, runtime, kernels e identidad de topología
distribución por lotes globales y locales, secuencias y recuento de tokens
memoria máxima por categoría, cuando esté disponible
tokens útiles por segundo y utilización de FLOP del modelo, siempre que se calcule de forma consistente
tiempo invertido en operaciones como all-reduce, all-gather, reduce-scatter, all-to-all y point-to-point
cuellos de botella en la entrada, tiempo checkpoint, comportamiento al reiniciar y distribución de elementos rezagados
pérdida de entrenamiento o paridad entre salida serving y el valor de referencia

Se compara deliberadamente la escala débil con la escala fuerte. La escala débil incrementa el trabajo total a medida que aumenta el número de rangos, mientras que la escala fuerte mantiene constante el trabajo total. Un porcentaje denominado “eficiencia de escala” carece de sentido sin dicho denominador y punto de referencia.

Conclusión

El paralelismo consiste en una asignación que relaciona un cuello de botella detectado con una dimensión del tensor y un patrón de comunicación específico. La replicación, el sharding, la particionación por capas, la etapa intermedia de procesamiento, la particionación por secuencia y el enrutamiento especializado atenúan restricciones distintas y generan modos de fallo diferentes.

Inventarioe la carga de trabajo, dibuje la topología, genere mallas válidas y realice su perfilado. La configuración óptima es aquella que cuenta con suficiente margen de maniobra y minimiza las comunicaciones expuestas para la tarea que realmente se ejecuta.