El paralelismo de tensores divide la inferencia local de IA al distribuir grandes tensores de pesos dentro de cada capa del transformador entre varias GPU y combinar sus resultados parciales.
Esto es diferente de asignar una solicitud independiente a cada GPU o distribuir distintas capas entre diferentes dispositivos. Cada GPU del paralelismo de tensores participa en la misma capa, a menudo con cada token generado. Este enfoque puede permitir que un modelo quepa en varias GPU domésticas, pero convierte la comunicación entre GPU en parte de la ruta crítica de inferencia.
El paralelismo de tensores divide una capa en lugar de copiar todo el modelo
El paralelismo de datos proporciona a cada GPU una copia del modelo y divide las solicitudes o los lotes. El paralelismo de tensores hace lo contrario con un único modelo: divide los grandes tensores de parámetros dentro de capas individuales entre varios dispositivos.
NVIDIA NeMo define el TP como la distribución del tensor de parámetros de una capa individual entre varias GPU. Cada GPU solo contiene un fragmento de la matriz correspondiente.
Esto resulta útil cuando un modelo, o incluso una sola capa grande, no cabe cómodamente en una única GPU doméstica.
Los fragmentos por columnas y filas dividen el trabajo de multiplicación de matrices
Las capas de los transformadores contienen grandes proyecciones lineales. Una división paralela por columnas asigna diferentes columnas de salida a distintas GPU, mientras que una división paralela por filas asigna diferentes filas de entrada o rangos de características.
El tutorial de paralelismo de tensores de PyTorch aplica estilos de paralelismo por filas y por columnas a las capas de los transformadores. Cada rango calcula un producto matricial parcial a partir de su fragmento local de pesos.
El modelo sigue representando una única capa lógica. La división cambia dónde se realizan las partes de los cálculos y cómo se combinan los resultados parciales.
La comunicación colectiva reconstruye la salida lógica de la capa
Como cada GPU solo ve una parte del tensor, algunas operaciones necesitan all-reduce, all-gather, reduce-scatter u operaciones colectivas equivalentes antes de que el siguiente cálculo disponga de la representación necesaria.
Open MPI define AllReduce como la combinación de valores entre procesos y la distribución del resultado de vuelta a todos los participantes. Los entornos de ejecución de paralelismo de tensores utilizan este tipo de operación colectiva, junto con all-gather y reduce-scatter, para reconstruir o redistribuir los resultados fragmentados de las capas.
En una estación de trabajo doméstica, la calidad de la conexión entre GPU puede determinar si la división ahorra tiempo o simplemente amplía la capacidad.
Las interconexiones rápidas importan porque la comunicación ocurre con la frecuencia de las capas
El paralelismo de tensores puede requerir varias operaciones colectivas por cada bloque del transformador y por cada token generado. Los sistemas que solo utilizan PCIe tienen mucho menos ancho de banda entre dispositivos que las interconexiones de aceleradores de alta gama diseñadas para grandes trabajos distribuidos.
RCCL de AMD documenta el transporte entre pares para GPU conectadas mediante PCIe. La biblioteca colectiva exacta varía según la plataforma, pero se aplica la misma limitación de topología.
Dos GPU con suficiente VRAM combinada pueden ejecutar correctamente un modelo más grande y, aun así, ofrecer un rendimiento de tokens inferior al esperado porque cada capa debe esperar a la sincronización.
Las GPU diferentes pueden hacer que el fragmento más lento marque el ritmo
Una capa con paralelismo de tensores solo avanza después de que llegan los resultados parciales necesarios. Si una GPU tiene menor rendimiento de cálculo, menos ancho de banda de memoria o un enlace más lento, el rango más rápido puede pasar tiempo esperando.
La función de inferencia con paralelismo automático de tensores de DeepSpeed está diseñada en torno a la fragmentación del modelo entre un grupo de procesos de inferencia. La eficiencia práctica presupone que los dispositivos participantes pueden realizar un trabajo equilibrado.
Una colección de GPU domésticas diferentes aún puede ser útil para que el modelo quepa, pero los tamaños de fragmento iguales no son automáticamente óptimos cuando el hardware difiere considerablemente.
Elige el paralelismo de tensores para capas amplias y memoria limitada en una sola GPU
El caso más sólido es el de un modelo cuyas grandes dimensiones ocultas y tensores de capa necesitan dividirse entre varias GPU, especialmente cuando los dispositivos cuentan con una interconexión local rápida. No es automáticamente la mejor forma de atender varias solicitudes pequeñas e independientes.
El artículo de ZimaSpace sobre la planificación de memoria para aceleradores de IA locales proporciona la referencia de capacidad; el paralelismo de tensores modifica esa referencia al distribuir las capas de un modelo entre varios dispositivos.
Compara una GPU cuando sea posible y, después, dos o más con el mismo modelo, indicación, contexto y lote. Registra la memoria de cada GPU, los tokens por segundo, la latencia, el tiempo de las operaciones colectivas y el uso del enlace.
El artículo de ZimaSpace sobre la presión de la IA local multiusuario ofrece la comparación desde el punto de vista del servicio: el TP hace que un modelo abarque varios dispositivos, mientras que la concurrencia de solicitudes determina cuántos contextos independientes compiten por ese modelo distribuido.
Centro de Tecnología e IA
Más para leer

Why Plex May Re-Analyze Media After a Server Upgrade
Plex may re-analyze media after an upgrade. Separate finite maintenance work from repeated scans, path issues, or database faults.

What Actually Sets the Plex Performance Ceiling?
A dependency model for Plex performance that helps you identify the first saturated stage instead of upgrading every component at once.

Plex Networking Explained: Discovery, DNS, Routing, and Remote Reachability
A layer-by-layer model of Plex reachability that separates local discovery from IP routing and remote NAT or port-forwarding problems.

