Redes de ampliación de GPU basadas en Ethernet

El reciente lanzamiento de Intel Gaudi-3, que utiliza RoCE para la interconexión Scale-UP, junto con las discusiones de Jim Keller sobre la sustitución de NVLink por Ethernet, han llamado la atención sobre este enfoque innovador. En particular, Tenstorrent, en el que participa Jim Keller, ha implementado inteligentemente la interconexión de redes entre chips mediante Ethernet. Por lo tanto, es pertinente abordar los desafíos y requisitos para que Ethernet reemplace a NVLink.

Reemplazar NVLink con Ethernet no es simplemente una cuestión de adoptar un nuevo protocolo de transporte; Requiere una serie de modificaciones en la arquitectura de la GPU. Esencialmente, el problema equivale a descubrir cómo colgar la memoria de alto ancho de banda (HBM) en una red Ethernet y lograr tanto el escalamiento horizontal como una serie de optimizaciones de comunicación para satisfacer las demandas computacionales, como la computación en red ejemplificada por SHARP. A nivel mundial, existen sólo unas pocas personas capaces de abordar este problema multifacético, y está claro que UltraEthernet no ha comprendido completamente el concepto.

Para avanzar, es necesario abordar las siguientes preguntas clave:

• Límite de latencia: ¿Cuál es el límite de latencia aceptable? La latencia del enlace causada por SerDes FEC de alto rendimiento y alta velocidad y la interconexión más allá de la escala de decenas de miles de tarjetas es inevitable. Estos problemas no se pueden resolver simplemente modificando un protocolo de paquetes o introduciendo HPC-Ethernet.
• Semántica de la transmisión: ¿Cuáles son la semántica de la transmisión? Los profesionales de redes normalmente comprenden las operaciones básicas de ENVÍO/RECV. Por ejemplo, la definición de UEC de Entrega No Ordenada Confiable para Operaciones Idempotentes (RUDI) es un paso en falso técnico. Si bien satisface las leyes conmutativa e idempotente, no aborda cómo se pueden implementar ciertas operaciones, como la idempotencia de la suma reductora. Además, también son necesarias optimizaciones basadas en la ley asociativa, que no son compatibles con el acceso detallado a la memoria en NVLink. En términos más generales, la semántica debe evolucionar a la de un Semi-Lattice.
• Agrupamiento de memoria más grande en NVLink: ¿Cómo abordar el agrupamiento de memoria más grande en NVLink? Esto implica resolver las compensaciones de tiempo/espacio para los operadores de Compute Bound en problemas computacionales, como KV Cache.
• Enrutamiento dinámico y control de congestión: la capacidad de enrutar y controlar dinámicamente la congestión en una red sin pérdidas no convergente 1:1 no es un problema importante para clústeres con decenas de miles de tarjetas mediante ajuste codificado. Sin embargo, para clusters a escala de cientos de miles a millones de tarjetas, que pueden incluso requerir RDMA para transmisión a larga distancia, ningún proveedor comercial ha resuelto estos problemas todavía.

Descripción general de las soluciones de interconexión actuales de ScaleUP

Intel Gaudí3

Según el documento técnico de Gaudi3, Gaudi Die está estructurado de la siguiente manera: incorpora 24 enlaces RoCE de 200 Gbps, 21 de los cuales se utilizan para FullMesh interno y tres para conexiones externas.

Se ha calculado la topología para redes a ultra gran escala y el ancho de banda del conmutador Leaf es equivalente a un conmutador de 25.6T.

Control de congestión

El documento técnico de Intel afirma que en lugar de utilizar PFC, se emplea un mecanismo ACK selectivo. Además, el algoritmo SWIFT se utiliza para el control de congestión (CC) para evitar el uso de ECN. Esencialmente, se trata de una reutilización del Reliable Transport Engine de Google Falcon en la IPU de Intel.

Reducción de rutas múltiples y dentro de la red

Intel afirma admitir la pulverización de paquetes, pero no está claro qué conmutador de empresa se está utilizando; Ciertamente no es su propio Tofino. Por tanto, debe ser Broadcom. Además, la reducción dentro de la red admite FP8/BF16, etc., y los operadores solo admiten Sum/Min/Max. Combinado con los grupos de trabajo de UEC sobre In-Network-Computing (INC), el panorama se vuelve más claro.

Microsoft Maia100

Hay información limitada disponible, pero hay un ancho de banda de un solo chip de 4800 Gbps. Un chasis de servidor único contiene cuatro tarjetas Maia100 y un gabinete completo con ocho servidores forma un grupo de 32 tarjetas.

Al examinar los conmutadores ampliados y los cables de interconexión, hay tres conmutadores y cada servidor tiene 24 interfaces de red de 400 Gbps. Hay conexiones loopback entre los puertos (indicados en negro en el diagrama) y líneas de interconexión externas (indicadas en violeta).

Esto sugiere una topología que forma una interconexión en forma de boca dentro de la placa base, creando un anillo en la dirección X y conectándose a tres interruptores en tres planos en la dirección Y.

Los enlaces ascendentes de los conmutadores realizan conexiones de escalamiento horizontal entre gabinetes, y cada plano en cada gabinete tiene un total de 32 400G interfaces. Al agregar una convergencia 1:1, el conmutador de enlace ascendente se vincula para formar un conmutador de 25.6 T, lo que hace teóricamente factible una expansión multicapa. Esto representa una fusión de redes Scale-Up y Scale-Out. En cuanto al protocolo, un RoCE simple punto a punto no debería suponer un problema para Torus Ring. Sin embargo, se necesitarán capacidades de rutas múltiples al interconectarse con conmutadores de escalamiento horizontal.

La desventaja es la posibilidad de una mayor latencia. Sin embargo, para los chips personalizados que no siguen el modelo SIMT como CUDA sino que utilizan un enfoque de matriz sistólica, la latencia no es un problema importante. Además, con sólo cuatro grupos Torus, el impacto de la latencia de la comunicación colectiva es mínimo. Personalmente, creo que estos chips probablemente se utilicen principalmente para inferencia, ya que los CSP suelen desarrollar un chip de inferencia antes de entrenar chips. Otros CSP también tienen una distinción clara entre entrenamiento e inferencia, como AWS Trainium/Inferentia y V5p/V5e de Google.

TPU de Google

La interconexión de Google TPU es bien entendida, presenta una topología Torus Ring e interruptores ópticos para conmutación de enlaces.

La conmutación de circuitos ópticos (OCS) tiene dos propósitos: partición dinámica según la escala de ventas y optimización del ancho de banda de bisección para comunicaciones de todos a todos como MoE.

Por ejemplo, un solo chip TPUv5p admite una conexión de interconexión entre chips (ICI) de 4800 Gbps con una topología 3D-Torus. OCS puede dividir dinámicamente un grupo de 8960 unidades TPUv5p para vender diferentes escalas, siendo la configuración máxima vendible 6144 unidades formando un 3D-Torus.

La tolerancia a fallos es una consideración crítica para la topología 3D Torus.

Además, Google admite la extensión de dos Pods a través de la red del centro de datos para crear entrenamiento multislice, con paralelismo de datos paralelos (DP) entre Pods.

tren de AWS

La arquitectura AWS Trainium consta de 16 chips que forman un pequeño clúster interconectados en una estructura Torus Ring 2D.

dojo de tesla

Tesla Dojo ha desarrollado su propio protocolo de transporte Tesla para unificar Wafer/NOC y extensiones Ethernet externas.

Utilizando System-on-Wafer de TSMC, se encapsulan 25 unidades de cómputo D1 en una sola oblea, interconectadas en una red de malla 5D de 5 × 2, y cada oblea forma un mosaico que contiene 40 matrices de E/S.

Los Tiles están interconectados a una velocidad de 9TB/s.

El enrutamiento de red en el chip puede evitar los núcleos o mosaicos D1 fallidos.

Para Ethernet de escalamiento horizontal externo, hay una tarjeta de procesador de interfaz Dojo (DIP), en la que cada motor de cálculo D1 tiene su propia SRAM y otra memoria ubicada en la tarjeta DIP equipada con HBM.

Cada tarjeta de red está conectada al módulo de E/S del Dojo a través de un bus especial de 900 GB/s, el Protocolo de Transporte Tesla (TTP), correspondiente al 800GB Ancho de banda de HBM, con cada módulo de E/S capaz de conectarse a cinco tarjetas DIP.

Debido a la comunicación interna de la red 2D Mesh, la comunicación a larga distancia es costosa, por lo que se han implementado diseños de enrutamiento especiales.

El enrutamiento proporciona múltiples rutas en el chip y está fuera de servicio. Para comunicaciones de larga distancia y gran escala, un uso inteligente de la tarjeta de interfaz Dojo construye un bus Ethernet TTPoE de 400 Gbps como acceso directo.

Dojo construye una red en chip de alta densidad a escala de oblea a través de System-on-Wafer y una red privada de comunicación entre obleas de alta velocidad y corta distancia a 9 TB/s. Las E/S y la memoria están integradas en la tarjeta DIP, lo que proporciona 900 GB/s por tarjeta conectada a la red de escala de oblea, formando una red de malla 2D a gran escala. Sin embargo, considerando el control de la congestión debido a la larga distancia de comunicación en la red en chip, se ha diseñado un canal de escape de 400 Gbps basado en la tarjeta DIP, que envía la comunicación a través de un conmutador Ethernet externo a la oblea de destino.

Tentorrent

En el diseño de interconexión de chip a chip en Tenstorrent, Jim Keller utilizó Ethernet, que tiene una estructura simple. El encabezado de control Tensor + forma un paquete Ethernet y puede activar capacidades de ejecución condicional, como se muestra a continuación:

Interconexión completa de chip a chip mediante Ethernet

Admite múltiples idiomas de origen de comunicación funcional

Luego está la partición del gráfico. Parece que se puede estimar el número de instrucciones por etapa y también se puede estimar el ancho de banda de los operadores que entran y salen.

Las restricciones finales de mapeo de los núcleos también parecen ser sencillas:

Una estructura de malla 2D simple

Puede ampliarse hasta 40,960 XNUMX núcleos para interconexiones a gran escala

Requisitos técnicos para la ampliación

Selección de topología

En la selección de topología de red ScaleUp, podemos observar que Nvidia actualmente utiliza una estructura Fat Tree convergente 1:1, mientras que otras empresas utilizan principalmente topologías Torus Ring o 2D Mesh. Nvidia luego evolucionará a DragonFly.

La lógica detrás de esta elección se puede ver en el artículo de HammingMesh:

Para el ancho de banda de Allreduce, Torus es el más rentable y básicamente puede alcanzar el máximo rendimiento. Sin embargo, para modelos como MoE que requieren AlltoAll, se debe considerar el ancho de banda de bisección. DragonFly funciona bien en términos de complejidad del cableado, ancho de banda global y diámetro de la red.

Enrutamiento dinámico y transmisión confiable

Si bien todo el mundo critica las deficiencias de RoCE, el hecho es que BF3+Spectrum-4 tiene enrutamiento adaptativo, Broadcom tiene DLB/GLB para evolucionar la pulverización de paquetes y también existen tecnologías VoQ similares a las de Cisco. Meta también tiene enrutamiento estático de múltiples rutas para ingeniería de tráfico o programación de afinidad en el plano de control.

Sin embargo, estas soluciones sólo pueden resolver parte de los problemas a una escala de decenas de miles de tarjetas. El verdadero desafío surge cuando se escala a cientos de miles de tarjetas. ¿Cómo abordamos esto?

Resolver algorítmicamente las ráfagas es una tarea difícil, y aún más desafiante es que nadie está tratando de comprender la causa raíz de las ráfagas. En cambio, intentan constantemente probar los buffers de conmutación para mitigar las ráfagas, y algunos incluso están explorando redes deterministas y análisis de Fourier. Esto simplemente no tiene sentido.

Este es un problema muy difícil y aún está por ver cuándo lo resolverán los demás actores de la industria. Otro aspecto es la falla del sistema y el escalamiento elástico. El artículo NSDI24 de Google menciona las razones de la fragmentación.

Si no se consideran estas cuestiones, se producirán desafíos de programación. Una buena opción podría ser la implementación de la tabla de enrutamiento dentro de ICI, junto con conmutadores OCS.

¿Por qué es importante que Ethernet admita ScaleUP? Porque Ethernet necesita implementar una capa de enrutamiento aquí para admitir DragonFly y las capacidades de conmutación de enlaces fallidos.

¿Es la latencia importante para la ampliación?

La esencia de esta pregunta es cómo las GPU realizan la ocultación de latencia y las diferencias de latencia entre NVLink y RDMA. Es importante tener en cuenta que las GPU son inherentemente procesadores de rendimiento optimizado y, si buscaran una latencia baja, indicaría problemas con su implementación. El problema fundamental es que NVLink usa semántica de memoria, mientras que RDMA usa semántica de mensajes, y también existen desafíos en la implementación de RDMA para computación heterogénea.

Deficiencias de la implementación de RDMA

El factor clave que provoca una mayor latencia en RDMA en comparación con NVLink es la CPU.

Nvidia está abordando esto a través de GDA-KI, que ayuda a ocultar muchas latencias de acceso a la memoria de manera más efectiva.

Acceso detallado a la memoria

Otro problema es que NVLink se basa en la semántica de la memoria y tiene una gran cantidad de accesos de carga/almacenamiento detallados, lo que hace que la eficiencia de transmisión y la latencia sean muy importantes. Pero, ¿cómo se puede hacer esto usando Ethernet RDMA? Requeriría HPC Ethernet, ya que los paquetes serían demasiado grandes.

Este es el problema que he estado discutiendo en NetDAM: la necesidad de una semántica Semi-Lattice para mensajes RDMA:

• La conmutatividad garantiza que los datos se puedan enviar de forma desordenada.
• La idempotencia resuelve el problema de ambigüedad de los paquetes descartados y las retransmisiones, pero para operaciones como Reducir con efectos secundarios, se requiere idempotencia de datos o basada en transacciones.
• La asociatividad ayuda a mejorar la eficiencia de la transmisión para accesos específicos a la memoria mediante la programación.

Para los requisitos de acceso a la memoria, el protocolo interno suele tener el tamaño FLIT. Para respaldar esto y al mismo tiempo habilitar interconexiones ScaleUP a ultra escala, confiabilidad, encabezados de enrutamiento, encabezados Ethernet, aislamiento multiinquilino (encabezados VPC), etc., la clave es aprovechar la asociatividad. Sin embargo, la UEC parece haber pasado por alto esto por completo y solo brinda soporte para la conmutatividad y la idempotencia en RUDI.

La solución de Nvidia es la codificación asociativa, que resuelve el problema del acceso detallado.

La próxima generación de NVLink probablemente convergerá con Infiniband, y las redes ScaleOut y ScaleUP eventualmente se fusionarán.

Agrupación de memoria para ScaleUP

Muchos modelos grandes hoy en día adolecen de la capacidad limitada de HBM (High-Bandwidth Memory). Si bien NVIDIA ha solucionado este problema conectando Grace y NVLink C2C para ampliar la memoria, el problema fundamental es que la red ScaleUP requiere agrupación de memoria.

Conclusiones

1. Cualquier empresa que desee realizar Ethernet ScaleUP debe considerar los siguientes desafíos clave:
2. La latencia no es tan crítica. Al modificar los patrones de acceso a la memoria de la GPU para alinearlos con la semántica del mensaje y luego almacenar en caché el procesamiento, se puede ocultar la latencia.
3. Las capacidades de enrutamiento dinámico y aislamiento de inquilinos de la red ScaleUP son cruciales. Se necesitan soluciones de enrutamiento efectivas, especialmente para abordar los problemas de fragmentación causados ​​por fallas en los enlaces.
4. La semántica de RDMA (acceso remoto directo a memoria) es imperfecta y simplemente copiar SHARP (Protocolo de reducción y agregación jerárquica escalable) tiene muchos inconvenientes. Se requiere una semántica Semi-Lattice que admita una serie de operaciones de efectos secundarios para lograr la idempotencia.
5. Se necesitan reenvío de múltiples rutas de tejido y control de congestión para mejorar la utilización general del tejido.
6. La agrupación de memoria a gran escala es esencial.