Resumen

  • SoftBank reveló en JANOG58 que una comprobación NCCL de todos los enlaces encontró uno con solo una fracción no especificada del rendimiento normal, aunque el LED seguía verde, Link Status estaba UP y la potencia óptica era normal. Las señales respondían a preguntas más estrechas que la aceptación del workload.
  • El deck enumera switch, optics, NIC, fibra y suciedad en un connector como superficies de aislamiento. No identifica causa raíz, proporción exacta, contadores BER/FEC del incidente ni reparación comprobada; las cifras y sustituciones de optics de las páginas explicativas son ejemplos.
  • La autoridad para aceptar capacidad debe quedar unida a una prueba portable por enlace, evidencia de Layer 1 y repetición tras la reparación. Las rutas externas y el ASN acreditan identidad y reachability, no el rendimiento del fabric interno.

La pregunta de aceptación obliga a separar tres dueños de evidencia. SoftBank, como operador de la plataforma, puede definir la topología, ejecutar workloads y decidir cuándo admite capacidad. Los proveedores de GPU, switches, NIC y optics controlan diseño, firmware, diagnósticos y remedios de soporte. El equipo de facility controla energía, refrigeración líquida y acceso físico. Ninguno de esos papeles, por sí solo, convierte un indicador local en prueba de servicio extremo a extremo.

Yasuhiro Uchida y Chaocheng Chang presentaron el caso de SoftBank el 16 de julio de 2026, en la segunda jornada de JANOG58. La sesión oficial, Rack-Scale GPUサーバーのNW設計と運用までの苦悩, recorre la arquitectura y la operación de la primera implantación rack-scale de la compañía. El deck final tiene 56 páginas.

La observación decisiva aparece en una sola página. Se hizo un NCCL benchmark sobre todos los enlaces. Uno entregó una fracción del throughput normal. El documento no da la proporción y no dice que fuera un tercio. Al mismo tiempo, su LED estaba Green, Link Status seguía UP y la potencia óptica permanecía dentro del rango normal.

No hay contradicción entre las tres señales y la prueba de workload. Cada una mide otra cosa. El LED refleja una condición definida por el circuito de estado. Link Status muestra que la interfaz alcanzó el estado administrativo o protocolario previsto. La potencia óptica indica que la recepción no cruzó el límite configurado. Ninguna promete margen de corrección, integridad de cada lane o tasa útil para el collective.

Por eso el certificado de aceptación no debería invalidar las señales nominales. Debería registrar sus límites y añadir la pregunta que faltaba: ¿entrega cada enlace obligatorio el rendimiento reproducible que necesita el servicio?

La escala material vuelve urgente esa pregunta. La configuración GB200 NVL72 descrita contiene 18 compute trays, cuatro B200 GPU en cada uno, y nueve switch trays con dos NVSwitch por tray. Son 72 GPU y 36 CPU. El deck sitúa el consumo del rack por encima de 100 kW. La documentación de NVIDIA confirma la forma de referencia e incluye cableado pasivo de backplane, power shelves, busbar y manifolds de refrigeración líquida.

Esas fuentes describen arquitectura, no el comportamiento del enlace afectado. Aun así, explican el coste de una aceptación demasiado estrecha: un componente de red relativamente pequeño puede dejar sin rendimiento útil a aceleradores mucho más caros, mientras todo sigue instalado y alimentado.

SoftBank divide la conectividad en Compute Fabric, Converged Fabric y OOB Fabric. El primero transporta el scale-out de los GPU. El segundo lleva front-end, almacenamiento y bootstrap NCCL. El tercero soporta la gestión de switches y servers, la monitorización de facility y la gestión de NVSwitch. La separación funcional ayuda a asignar fallos; no elimina dependencias físicas, firmware o procesos comunes.

El problema de reachability de gestión deja una advertencia precisa. Usar el underlay del Compute Fabric para alcanzar loopbacks puede reducir el coste de cablear todos los puertos de management y mejorar el acceso operativo. El deck especifica que no sustituye el OOB. Si la única vía para diagnosticar el fabric depende del mismo fabric, el control queda dentro de la frontera que debe reparar.

La comprobación NCCL descubrió una frontera parecida entre estado y entrega. Un collective depende del enlace lento o degradado del grafo, no del color medio de los puertos. El inventario puede mostrar todos los GPU presentes y la ruta de management puede responder, mientras la capacidad que un tenant puede consumir queda por debajo de lo vendido.

Después de la anomalía, el deck dibuja el dominio de aislamiento: switch, optics, NIC, fibra y connector sucio. La lista no es un veredicto. Es una cadena de candidatos que puede cruzar propietarios y contratos. El error puede originarse en transmisión, recepción, lane, módulo, conector o cable y expresarse finalmente como throughput inferior.

Las páginas dedicadas a pre-FEC BER, post-FEC BER y FEC histogram presentan patrones normales y anómalos. También incluyen, dentro de diagramas explicativos, el cambio de optics. Esas páginas enseñan un método. No publican los valores que tuvo el enlace del incidente, ni afirman que entrara en los bins mostrados, ni que una sustitución concreta restaurara el rendimiento.

La distinción es esencial para repartir responsabilidad. Un contador BER puede revelar errores antes de la corrección. FEC puede indicar cuánto margen se está consumiendo. Cambiar un módulo puede probar una hipótesis. Pero el dueño de la reparación no ha demostrado restauración hasta repetir el mismo test de todos los enlaces que descubrió el síntoma.

El registro público carece de esa secuencia before/after. Tampoco contiene causa raíz, componente culpable, throughput exacto ni impacto sobre clientes. El artículo no puede convertir un diagrama en una reparación ni una degradación en una caída de producción.

Sí puede describir el cambio operativo que SoftBank propone. El deck declara insuficiente Link UP = OK, pide comprender mejor BER y FEC, y recomienda recopilar y analizar semanal y mensualmente logs de interfaces y optics. El objetivo es buscar señales de degradación antes de esperar a interface down.

La propuesta todavía no es una capacidad predictiva probada. No se publican umbrales, periodo de retención, tasa de falsas alarmas, fallo anticipado o mejora de disponibilidad. La inferencia válida es más limitada: el operador identificó un punto ciego y eligió indicadores físicamente más cercanos al mecanismo.

También importa la unidad de servicio. El deck compara entrega por rack, tray y GPU. La conclusión declarada es que SoftBank ofrece hoy unidades rack y tray después de evaluar las compensaciones. La opción por GPU sigue siendo un diseño estudiado, no una oferta actual demostrada.

Dar todo el rack simplifica la partición, pero entrega al mismo cliente dependencias como Compute Fabric, CDU, NVSwitch, compute trays y busbar. La unidad tray puede servir a un comprador menor, aunque exige partición NVLink. Además, el proceso de gestión de NVSwitch es común en el rack; SoftBank lo identifica como single point of failure y liga un SLA superior a redundancia en rack o scalable unit.

La aceptación, por tanto, decide quién soporta el riesgo. Si el gate termina en link-up y potencia, SoftBank puede trasladar al entorno de producción una degradación que el collective revelará después. Si el gate depende de una herramienta opaca del vendor, el proveedor controla la prueba, el diagnóstico y, potencialmente, la salida. Si se usa un baseline portable y versionado, la autoridad se limita a una frontera de servicio verificable.

El coste directo recae en el operador: cableado denso, optics, switches, repuestos, laboratorio representativo, energía, refrigeración y personal capaz de cruzar límites de vendor. El coste de servicio recae en el tenant cuando un job tarda o los GPU quedan ociosos. Los compradores más pequeños no siempre pueden replicar un rack, un lab y el inventario de repuestos, por lo que dependen más del diagnóstico del integrador.

Los proveedores se benefician de las ventas de sistemas integrados y de los contratos de soporte. SoftBank se beneficia de la densidad si la capacidad aceptada aumenta de verdad. Los tenants se benefician cuando el rendimiento puede probarse y restaurarse. La integración deja de ser ventaja si cada proveedor puede afirmar que su componente está dentro de su propia especificación mientras el sistema compuesto no alcanza la tasa objetivo.

La plataforma añade otra cifra que debe mantenerse en su sitio. SoftBank declaró en diciembre de 2025 que 1.224 GPU Blackwell empezaron a operar el día 22 y que planeaba superar los 4.000. El primer número es una declaración de despliegue; el segundo, una previsión. Ninguno mide cuántos enlaces satisfacen el baseline en un momento determinado.

Tampoco cabe usar CHIE-4 para llenar el vacío. TOP500 identifica ese sistema de SoftBank como DGX B200 con InfiniBand NDR400. Su clasificación no pertenece a la plataforma GB200 NVL72 de la sesión.

Un contrafactual creíble empieza por cambiar el acta de aceptación. Cada enlace obligatorio tendría una identidad de topología y una distribución esperada de NCCL —u otro workload portable—. El expediente conservaría link state, potencia óptica, counters por lane, pre/post-FEC BER, FEC histogram, módulo, fibra, extremos switch/NIC, firmware y timestamp.

Ante una desviación, el operador cambiaría un elemento acotado cada vez y guardaría los counters anteriores y posteriores. Después reproduciría el test exacto. La evidencia distinguiría tendencia, alerta, ticket, intervención y restauración verificada. Cerrar un ticket tras sustituir una pieza no equivaldría a recuperar capacidad.

El tenant no necesita necesariamente todos los datos privados de cada vendor. Sí necesita que el service owner pueda probar el rate aceptado y el retorno al mismo rango tras la reparación. Esa obligación evita que quien vende el diagnóstico monopolice también la definición de éxito.

JANOG controla el registro de la sesión y ha hecho posible examinar estos límites. No controla la plataforma ni tiene autoridad para aceptar sus enlaces. De la misma manera, un RIR puede registrar recursos numéricos y BGP puede mostrar ASN, prefijos y rutas. Esa visibilidad prueba identidad de routing y acceso al edge; no acredita la tasa del fabric detrás del prefijo.

La enseñanza más precisa de JANOG58 no es que BER siempre sea mejor. Es que presencia administrativa, evidencia física y entrega de workload deben cerrar el mismo ciclo. La ruta externa y el ASN no certifican el tejido interno. La capacidad se acepta cuando su rendimiento puede reproducirse y repararse.

Fuentes