¿Cómo mueve el paralelismo de canalización las capas del modelo entre aceleradores de IA domésticos?
El paralelismo de canalización distribuye un modelo entre aceleradores de IA domésticos asignando distintos grupos de capas a etapas secuenciales en diferentes dispositivos y pasando las activaciones entre ellos.
Este método resulta útil cuando un modelo profundo es demasiado grande para un solo acelerador, pero puede dividirse en grupos de capas que quepan en varios dispositivos. A diferencia del paralelismo tensorial, cada etapa posee capas completas en lugar de fragmentos de una misma matriz. La principal contrapartida es una menor cantidad de pesos residentes por dispositivo a cambio de transferencias de activaciones, desequilibrios entre etapas y tiempos de inactividad de la canalización.
El paralelismo de canalización divide un modelo profundo en etapas secuenciales de capas
Un transformador tiene un orden natural: las primeras capas transforman la entrada antes de que puedan ejecutarse las posteriores. El paralelismo de canalización agrupa secciones contiguas de esa profundidad y asigna cada sección a un acelerador diferente.
El entorno de ejecución de canalización de PyTorch divide un modelo en particiones que se ejecutan como etapas secuenciales en distintos dispositivos. Cada dispositivo almacena únicamente los parámetros de la etapa que tiene asignada.
Esto puede reducir la memoria del modelo por dispositivo lo suficiente como para ejecutar un modelo que no cabría en una sola GPU doméstica.
Las activaciones avanzan de una etapa a la siguiente
Después de que la GPU 0 termina sus capas, envía la activación del estado oculto a la GPU 1. Ese dispositivo aplica el siguiente conjunto de capas y reenvía otra activación hasta que la etapa final produce los logits u otra salida del modelo.
vLLM-Omni describe el paralelismo de canalización como la división de los bloques del transformador en etapas secuenciales distribuidas entre GPU. En la ruta básica de propagación hacia delante, solo las activaciones de los límites deben cruzar entre etapas vecinas.
A diferencia del paralelismo tensorial, los dispositivos no calculan conjuntamente una matriz dentro de la misma capa. Cada uno posee capas diferentes.
Una sola solicitud sigue atravesando las etapas en orden
Para un token o un micro lote, las etapas posteriores no pueden comenzar hasta que reciben la activación necesaria de la etapa anterior. Simplemente colocar cuatro grupos de capas en cuatro GPU no hace que una solicitud secuencial sea cuatro veces más rápida.
La guía de paralelismo de NVIDIA define PP como la división vertical de las capas del modelo según su profundidad. La dependencia secuencial a lo largo de la profundidad se mantiene.
Por tanto, la ganancia inmediata puede ser de capacidad más que de latencia. El rendimiento mejora cuando el entorno de ejecución puede solapar distintas partes del trabajo entre las etapas.
Los micro lotes llenan la canalización para que varias etapas trabajen a la vez
Una canalización se vuelve eficiente cuando la entrada se divide en micro lotes o cuando varios elementos de inferencia pueden ocupar simultáneamente distintas etapas. Mientras la etapa 2 procesa un micro lote, la etapa 1 puede comenzar con el siguiente.
La guía de paralelismo de Hugging Face explica que la ejecución en canalización utiliza micro lotes para reducir el tiempo de inactividad de la canalización. El mismo principio de utilización se aplica siempre que un entorno de inferencia pueda solapar trabajo independiente.
La generación interactiva de tokens para un solo usuario ofrece menos paralelismo natural, porque cada token nuevo depende de la salida del token anterior. Las solicitudes agrupadas o el tráfico de varios usuarios pueden brindar más oportunidades para mantener ocupadas las etapas.
Los tiempos desiguales entre etapas crean burbujas y hacen que predomine la etapa más lenta
Si una etapa contiene más capas, hardware más lento u operaciones especialmente costosas, la etapa siguiente espera la entrada y la anterior termina esperando espacio. Estos periodos de inactividad son burbujas de la canalización.
El motor de canalización de DeepSpeed destaca la partición de las capas del modelo en etapas de canalización. Por ello, equilibrar el cálculo de las etapas es tan importante como equilibrar los bytes de parámetros.
Una configuración doméstica con aceleradores de distintos tipos puede asignar intencionadamente menos capas a una GPU más lenta, pero la capacidad de memoria, el tamaño de las activaciones y las transferencias compatibles entre dispositivos limitan esa distribución.
El paralelismo de canalización intercambia capacidad para pesos por transferencias de activaciones y planificación
El PP resulta atractivo cuando el modelo es profundo y puede dividirse en grupos de capas que quepan en dispositivos individuales. Comunica activaciones de los límites en lugar de realizar las operaciones colectivas frecuentes dentro de una capa, típicas del paralelismo tensorial, pero paga el coste de las dependencias secuenciales y las burbujas.
La guía de ZimaSpace sobre la concurrencia de IA doméstica para varios usuarios es relevante porque un mayor volumen de trabajo simultáneo puede ayudar a llenar una canalización, aunque también aumenta la presión sobre la caché KV y la planificación.
Mide la memoria por etapa, el tiempo de ejecución de cada etapa, el tiempo de transferencia de activaciones, la latencia de extremo a extremo, el rendimiento y el porcentaje de inactividad de los dispositivos. Una configuración que permite cargar el modelo, pero deja la mitad de los aceleradores inactivos, puede necesitar una división diferente.
La guía de hardware para IA local de ZimaSpace proporciona la referencia de capacidad. El paralelismo de canalización es una forma de superar el límite de memoria de un solo dispositivo, pero su éxito depende más del equilibrio entre etapas que del número de GPU.
Productos recomendados
Centro de Tecnología e IA
Más para leer
¿Pueden las cámaras domésticas sincronizar eventos sin servicios de hora en la nube?
Una explicación centrada en el mecanismo del tiempo de la cámara sin nube, sus compensaciones por recursos compartidos, tres preguntas frecuentes sobre la propagación...
¿Puede un servicio de IA local detectar capas de modelo dañadas antes de la inferencia?
Una explicación basada primero en los mecanismos de la detección de capas de modelo dañadas, sus compensaciones en recursos compartidos, tres preguntas frecuentes sobre...
¿Se puede restaurar un sistema RAG sin regenerar cada embedding?
Una explicación centrada primero en el mecanismo de la restauración de RAG sin volver a generar embeddings, sus compromisos en el uso compartido de...
