Red de centro de datos de cómputo IA: cuando las GPU están ociosas, suele ser la red
Compró los aceleradores y la gráfica de utilización sigue a la mitad. Rara vez son las tarjetas: es un fabric que descarta paquetes durante la comunicación colectiva, y una sola pérdida hace que todo el trabajo espere una retransmisión. Diseñamos redes de clúster de IA según cómo se comporta realmente el trabajo: un fabric spine-leaf sin sobresuscripción, Ethernet sin pérdidas con RoCEv2, PFC y ECN ajustados para su clúster en lugar de copiados de una guía, y un plano de gestión fuera de banda que sigue respondiendo cuando el fabric no. Dimensionada honestamente desde un solo rack de 8 tarjetas hasta un despliegue multisala, y presupuestada para la óptica y las NIC, no solo los switches.
Por qué los fabrics de IA fallan de otra manera
Cuatro problemas que encontramos en casi todos los clústeres que nos llaman:
Las GPU están ociosas y nadie sabe por quéLa utilización se queda a la mitad y el fabricante dice que las tarjetas están bien. Suelen estarlo. Las tarjetas se esperan entre sí, y lo que las hace esperar es el fabric que hay entre ellas, que nadie instrumentó porque se dio por supuesto que era fontanería.
Una pérdida y la ejecución vuelve a empezarUn trabajo de entrenamiento no es un servidor web. No se degrada con elegancia: una pérdida durante una operación colectiva detiene todos los rangos hasta que llega la retransmisión, y en el peor caso una ejecución larga hay que reiniciarla desde el último punto de control. Horas de tiempo de acelerador por una sola trama descartada.
A la Ethernet corriente nunca se le pidió estoLa comunicación colectiva envía todo a la vez, a todos, en una ráfaga. Un fabric diseñado para tráfico de oficina promedio responde a eso con un búfer lleno y un descarte: se comporta exactamente como se diseñó, y ese es el problema.
Cuando el fabric se rompe, no puede entrarLa gestión viaja por el mismo fabric que se supone que debe arreglar. La noche en que se congestiona, la consola también es inalcanzable, y alguien conduce hasta el sitio para conectarse a un puerto de consola: una lección que todo el mundo aprende exactamente una vez.
Arquitectura: fabric spine-leaf sin pérdidas + gestión fuera de banda
Un fabric plano y no bloqueante construido en torno a un requisito: no descartar el paquete:
Arquitectura dibujada por AtlasCommTech siguiendo prácticas de diseño de nivel operador. Las etiquetas del diagrama se mantienen en inglés para mayor claridad técnica.
Por qué nosotros: nuestro fundador pasó 13 años dentro del ecosistema de socios de Huawei entregando redes de operador. En el mundo operador se aprende que un fabric se juzga por su peor momento, no por su media, que es exactamente la disciplina que necesita un clúster de IA, porque un trabajo de entrenamiento solo es tan rápido como su operación colectiva más lenta.
Opciones de equipamiento
La solución se dimensiona primero según sus requisitos y presupuesto: la misma arquitectura puede entregarse sobre las líneas de varios fabricantes. Le ayudamos a elegir según la disponibilidad de suministro en su país de destino, el presupuesto y los hábitos de operación de su equipo.
Huawei — líneas de campus empresarial, WAN y seguridadEcosistema maduro con una red de servicio global.
ZTE y Wantong — líneas datacom comparablesOrientación precio-rendimiento; el suministro fluye mejor en algunos mercados.
H3C — líneas de campus y centro de datosPortafolio de campus y centro de datos ampliamente desplegado.
Switches industriales Atlas — capa de acceso en escenarios industrialesNuestra propia línea industrial — compatible con la capa núcleo de cualquier marca.
Qué aporta el diseño
Seis cosas que hace un fabric de IA y que a una red de centro de datos corriente nunca se le piden:
Sin sobresuscripción en el fabricCada leaf sube a cada spine, y la capacidad de enlace ascendente iguala lo que el leaf puede recibir. La multiplexación estadística es una suposición sobre el tráfico medio, y una operación colectiva es precisamente la carga que se niega a ser media.
Transporte sin pérdidas, ajustado y no copiadoRoCEv2 con PFC por clase de prioridad y marcado ECN, con los umbrales fijados para el tamaño y el tráfico de su clúster. Una configuración de PFC copiada de una guía no es sin pérdidas: es un interbloqueo esperando la semana adecuada.
Topología plana, un salto entre leavesCualquier GPU alcanza a cualquier otra a través de exactamente un spine. La latencia es uniforme, así que el planificador de trabajos no tiene que conocer el cableado, y añadir un rack no cambia la distancia de nadie a nadie.
Puertos 100G / 400G de alta densidadCada acelerador obtiene su propio puerto de alta velocidad hacia el leaf, porque un puerto compartido hace que las tarjetas hagan cola entre sí antes de que el fabric vea siquiera el tráfico. La velocidad de puerto se elige según la disposición de NIC de su nodo, no de un catálogo.
Un plano fuera de banda que sigue respondiendoSwitches aparte, cableado aparte, direccionamiento aparte: alcanzable justo cuando el fabric no lo está. No se depura un fabric congestionado a través del fabric congestionado, y la noche en que uno lo descubre no es la noche para aprenderlo.
Instrumentado antes de que se le culpeContadores por cola, estadísticas de PFC y ECN y contadores de descartes exportados desde el primer día. Cuando la gráfica de utilización cae, la pregunta «¿fue la red?» tiene una respuesta en lugar de una discusión.
Tres tamaños, una sola lógica de diseño
Díganos el número de tarjetas, la disposición de los nodos y qué pueden alimentar y refrigerar realmente sus racks: el nivel le dice la forma del fabric:
Cifras en torno a las que diseñamos:
Cada acelerador tiene su propio puerto de alta velocidad: el colectivo va a la velocidad del rango más lento
Cero sobresuscripción entre leaf y spine: la multiplexación estadística es una suposición que esta carga rompe
La óptica y las NIC suelen costar más que los switches: un presupuesto que solo cuenta switches se queda corto antes del primer trabajo
| Nivel de escala | Sitio típico | Qué incluye el diseño |
|---|---|---|
| Rack único, desde 8 tarjetas | Un nodo o unos pocos · un piloto o un clúster de investigación pequeño · una sala | Un par de switches leaf, sin capa spine en absoluto: a este tamaño los leaves se hablan directamente y un spine es una capa comprada para el diagrama. La configuración sin pérdidas y la gestión fuera de banda siguen estando, porque es lo que hace de esto un clúster y no ocho ordenadores caros en un rack. |
| Clúster de GPU mediano | Varios racks en una sala · trabajos de entrenamiento en producción · un planificador delante | Un fabric spine-leaf completo sin sobresuscripción, un par de leaves por rack, RoCEv2 con PFC y ECN ajustados a su tráfico real y no a una plantilla, una ruta de almacenamiento separada para que las escrituras de puntos de control no choquen con el tráfico de entrenamiento, un plano fuera de banda completo y telemetría por cola exportada desde el inicio. |
| Despliegue multisala | Más racks de los que una sala puede alimentar · varias naves o edificios · tramos largos entre ellas | Un fabric por sala con una capa entre salas por encima, las distancias de los tramos determinando la elección de óptica y esa elección determinando gran parte del presupuesto, una conversación sobre ubicación de trabajos con quien opere el planificador para que un trabajo no se reparta entre salas innecesariamente, y una verificación real de potencia y refrigeración antes de dibujar la topología, porque a este tamaño el edificio decide el diseño, y no al revés. |
Roles de los equipos (categorías, no modelos)
La solución se construye con estas categorías de equipos; la marca se elige con usted en la fase de diseño. Los modelos exactos dependen del número de tarjetas, la disposición de NIC de los nodos, las velocidades de puerto y el país, así que especificamos modelos después de su lista de requisitos, no antes.
| Rol | Qué hace |
|---|---|
| Switches leaf (acceso de rack) | Un puerto de alta velocidad por acelerador, búferes lo bastante profundos para absorber una ráfaga colectiva, y la configuración sin pérdidas que realmente la sostiene. Se dimensionan según la disposición de NIC de su nodo, no según lo que quepa en un diagrama de rack. |
| Switches spine (núcleo del fabric) | Dan a cada leaf un camino de un salto hacia cualquier otro leaf sin sobresuscripción. La densidad de puertos aquí decide a cuántos racks podrá crecer el clúster, así que se dimensiona para el clúster al que se dirige, no para el que empieza. |
| Óptica y cableado | Cada enlace de alta velocidad necesita dos transceptores y un cable, y la cuenta llega a cientos rápido. El alcance, el tipo de conector y las distancias entre racks deciden la elección, y esta partida suele ser mayor que la de los switches, por eso insistimos en dimensionarla pronto. |
| Switches de gestión fuera de banda | Una red pequeña, barata y aparte que llega a cada puerto de gestión de la sala. Es el equipo menos interesante de esta página y lo primero que agradecerá, porque es el único camino de entrada la noche en que el fabric es el problema. |
| Conmutación de la ruta de almacenamiento | Las escrituras de puntos de control y las lecturas de conjuntos de datos son ráfagas a su manera, y ponerlas en las mismas colas que el tráfico de entrenamiento es como un fabric bien ajustado vuelve a descartar. Se separan por ruta o por clase de prioridad, según su cadencia de puntos de control. |
| Plataforma de telemetría / gestión | Exporta profundidad por cola, recuentos de pausas PFC, marcas ECN y descartes, para que una caída de utilización pueda atribuirse en vez de debatirse. Sin esto, la red es culpable por defecto en cada reunión, y normalmente inocente en realidad. |
Envíenos su número de tarjetas, la disposición de NIC de los nodos, los límites de potencia y refrigeración de sus racks y su cadencia de puntos de control, y la lista de modelos vendrá después. Ese orden mantiene honesto el diseño.
Notas de diseño y límites honestos
Léalo antes de comprometerse:
- En este tipo de red, la óptica y las NIC suelen costar más que los switches: no presupueste solo switches. Cada enlace de alta velocidad necesita dos transceptores y un cable, y la cuenta llega a cientos rápido. Un presupuesto construido a partir de una oferta de switches se quedará corto antes del primer trabajo, y por una cantidad que nadie querrá explicar. Dimensionamos todo en la fase de diseño para que la cifra llegue en el plan.
- La potencia y la refrigeración deciden la topología, y no al revés. A esta densidad, el límite eléctrico y térmico de un rack fija cuántos nodos caben en él, lo que fija cuántos racks necesita, lo que fija el fabric. Si sus instalaciones no pueden alimentar la disposición, ningún diseño de red la rescata: por eso la primera pregunta que hacemos es sobre su rack, no sobre su switch.
- Un fabric sin pérdidas se ajusta, no se enciende. Los umbrales de PFC y ECN dependen del tamaño de su clúster, su patrón de tráfico y sus NIC, y una configuración copiada de la guía de otro puede ser peor que ninguna configuración: convierte un descarte en un bloqueo que se propaga. Presupueste tiempo de ingeniería para ajuste y validación, no solo días de instalación.
- La política de licencias y la disponibilidad de producto difieren según la marca y el país de destino, y la óptica de alta velocidad en particular tiene su propia realidad de suministro: los plazos de algunas velocidades de puerto se miden en meses, no en semanas. Comprobamos y confirmamos ambas cosas para su país en la fase de diseño, antes de que se comprometa a nada, porque una óptica que llega después de los aceleradores es un rack de hardware ocioso.
- Si su problema de utilización no es la red, se lo diremos. La carga de datos, un planificador que empaqueta mal los trabajos, un nivel de almacenamiento insuficiente o un modelo que simplemente no paraleliza se parecen exactamente a un problema de red en la gráfica de utilización. Instrumentamos primero y concluimos después, y si el fabric resulta inocente, ese hallazgo es el entregable, no una oferta de switches.
Preguntas frecuentes
¿En qué se diferencia de su solución de centro de datos resiliente?
Compra protección contra un fallo distinto. La página de centro de datos resiliente trata de que los sistemas de negocio sigan disponibles: si muere un enlace, un switch o una sala, la aplicación sigue sirviendo a los usuarios y una breve reconvergencia es un resultado aceptable. Esta página trata de que un trabajo de entrenamiento no pierda paquetes: nada ha fallado, todo está en pie, y una sola pérdida bajo comunicación colectiva aun así detiene todos los rangos y puede costarle horas. Un diseño optimiza sobrevivir a un fallo; este optimiza un fabric que nunca descarta mientras todo funciona perfectamente. Si aloja aplicaciones de negocio, esa página es la suya.
¿De verdad puede Ethernet transportar tráfico de entrenamiento de IA?
Sí, cuando se configura para ser sin pérdidas. La Ethernet simple gestiona la congestión descartando, lo cual está bien para un servidor web y es fatal para una operación colectiva. RoCEv2 con PFC y ECN cambia ese comportamiento: el fabric aplica contrapresión y marca la congestión en lugar de descartar. La palabra importante es «configurada»: no es el protocolo el que hace el fabric sin pérdidas, es el ajuste, y el ajuste debe coincidir con su clúster. Por eso tratamos la validación como parte de la obra y no como algo que el cliente hace después.
Solo tenemos un rack. ¿Necesitamos capa spine?
No, y no se lo venderemos. Con un solo rack los leaves se hablan directamente y un spine añade coste, cableado, óptica y latencia a cambio de un diagrama que parece un clúster de verdad. Lo que sí debe comprar a ese tamaño es la configuración sin pérdidas, un puerto de alta velocidad por acelerador y el plano fuera de banda: eso es lo que convierte ocho ordenadores caros en un clúster. El spine vale su dinero cuando tiene suficientes racks para que el cableado directo entre leaves deje de escalar, y le diremos cuándo está en ese punto.
¿Podemos probar que fue la red antes de comprar nada?
Esa es la pregunta correcta para empezar, y sí. La profundidad por cola, los recuentos de pausas PFC, las marcas ECN y los contadores de descartes en el fabric existente le dirán si los aceleradores esperan a la red o a otra cosa: a menudo es la carga de datos o un planificador que empaqueta mal los trabajos, y ambos se ven idénticos en una gráfica de utilización. Preferimos hacer esa medición con usted y declarar inocente al fabric antes que venderle una reconstrucción que no arregla nada. Si resulta que la red está bien, eso es un resultado, y es más barato que la alternativa.
¿Podemos empezar pequeño y ampliar el clúster después?
Sí, y la mayoría debería, pero el crecimiento hay que diseñarlo ahora, en exactamente dos sitios. La densidad de puertos del spine decide a cuántos racks llegará el fabric, y la potencia y refrigeración de la sala deciden cuántos racks permitirá el edificio. Ambos son difíciles de cambiar después y baratos de planificar hoy. Todo lo demás —más leaves, más nodos, más óptica— es adición, no rediseño. Díganos el clúster al que se dirige, no solo el que empieza, y dimensionaremos esas dos cosas para el destino y el resto para hoy.
Envíenos su número de tarjetas y los límites de potencia de sus racks
Un ingeniero responde con un diseño de fabric, un recuento de óptica y NIC y la lista de categorías de equipos. Envíe su lista de requisitos: la lista de modelos vendrá después.
Soluciones relacionadas
Red de transporte IP gubernamentalCómo llega un clúster del sector público a sus usuarios: un anillo núcleo que transporta cada organismo como VPN aislada, con QoS que protege el tráfico que importa.
Red de fabricación inteligente (IT-OT)De dónde vienen los datos de entrenamiento: un anillo OT zonificado sobre switches industriales y una frontera con políticas que deja al MES leer la línea sin exponerla.
Red de centro de datos resilienteEl otro problema del centro de datos: sistemas de negocio que siguen disponibles ante un fallo, en lugar de un trabajo de entrenamiento que nunca pierde un paquete.