El rediseño de BLOB de Meta reduce la inactividad de GPU por latencia de almacenamiento

Meta Engineering publicó esta semana un desglose minucioso de cómo rediseñó su arquitectura de almacenamiento BLOB para soportar ejecuciones de entrenamiento abarcando cientos de miles de GPUs en clusters de escala exabyte. El post, redactado por Sidharth Bajaj y Venkatraghavan Srinivasan, ofrece uno de los relatos públicos más operacionalmente específicos de lo que requiere el almacenamiento a escala ML y por qué el almacenamiento de objetos convencional falla en esa carga de trabajo.

La arquitectura se superpone en Tectonic, un fabric de almacenamiento multi-tenant regional que utiliza codificación de borrado entre capas HDD y flash con colocación de datos inteligente y consciente de I/O. Sobre ella se encuentran capas de almacenamiento BLOB exponiendo un fabric globalmente escalable con tradeoffs de durabilidad versus disponibilidad configurables. Meta expone tres clases de API: almacenamiento de objetos, sistemas de archivos e interfaces de dispositivo en bloque. El entrenamiento Llama originalmente se ejecutaba directamente en un filesystem similar a NFS de Tectonic; la pila moderna migra a la interfaz BLOB para unificar el acceso a data lakes masivos junto con rutas de rendimiento respaldadas por flash.

El problema central es el bloqueo de GPU por picos de latencia de almacenamiento. Durante el entrenamiento, cientos de miles de GPUs procesan lotes de dataset en lockstep; cada N pasos la flota completa sincroniza estado. Una GPU bloqueada sostiene la línea. El dataloader en cada host GPU prefetch del siguiente lote mientras la GPU procesa el actual—superposición completa de computación/I/O, cero ciclos inactivos. Cuando la latencia de búsqueda de almacenamiento excede esa ventana de prefetch, la GPU espera. Meta identifica los cuellos de botella de almacenamiento como un contribuyente primario a la inactividad de GPU, impactando directamente el costo de entrenamiento y time to market.

La pila BLOB heredada hizo el bloqueo estructural. Una llamada getObject("/bucket/path") desencadenaba búsquedas de metadatos secuenciales en tres capas con estado—namelayer, volumeslayer, containerlayer—antes de resolver a una tupla (blockId, offset, size) que Tectonic podría servir. Las búsquedas individuales cruzaban regiones; las latencias agregadas rutinariamente alcanzaban cientos de milisegundos. Cualquier respuesta lenta bloqueaba la GPU. Las capas se acumulaban como servicios-sobre-servicios, cada una manteniendo su propio almacén de metadatos—aceptable cuando el cuello de botella era tiempo de búsqueda HDD, catastrófico cuando los datos residen en flash con latencia esperada de milisegundos de un dígito.

Tres suposiciones heredadas ya no se mantienen: optimización de costo-por-byte de la era HDD (las cargas de trabajo AI priorizan IOPS sobre bytes), replicación global-por-defecto (construida para durabilidad contra cortes regionales, no throughput de entrenamiento) y tolerancia de latencia tolerante (las cargas de trabajo web absorben tail latency; el entrenamiento a escala no puede). La nueva arquitectura apunta a latencias pMax acotadas, no medianas. La latencia mediana es irrelevante cuando un único outlier bloquea un job de 100,000 GPUs.

La segunda prioridad es velocidad de investigación. Conforme los clusters de GPU se vuelven geo-distribuidos y los tamaños de dataset crecen, los investigadores gastan tiempo desproporcionado moviendo datos entre regiones en lugar de ejecutar experimentos. La pila de almacenamiento rediseñada reduce esta fricción haciendo la capa BLOB globalmente uniforme—ocultando límites regionales del flujo de trabajo de investigación—mientras optimiza físicamente la colocación de datos para localidad de I/O.

El rendimiento de computación AI se ha triplicado aproximadamente cada dos años; el almacenamiento y el ancho de banda de interconexión crecieron más lentamente. Esa brecha estructural se amplia continuamente, significando que las decisiones de arquitectura de almacenamiento se componen. Los equipos que eligen entre NFS-on-Tectonic, BLOB unificado y acceso de bloque direto apuestan por cuál carga de trabajo domina: si las lecturas de checkpoint crean cuello de botella, el fanout de metadatos en BLOB heredado es el enemigo; si el throughput de carga de datos crea cuello de botella, el tiering flash y la profundidad de prefetch importan más que el conteo de lookup.

La capa de metadatos es el botón de utilización de GPU que nadie reporta en un benchmark.