Fire-Flyer File System de DeepSeek

• Fire-Flyer File System (3FS) es un sistema de archivos distribuido de alto rendimiento para cargas de trabajo de entrenamiento e inferencia de IA, que ofrece una capa de almacenamiento compartido aprovechando SSD modernos y redes RDMA
• Su arquitectura desagregada combina el rendimiento de miles de SSD con el ancho de banda de red de cientos de nodos de almacenamiento, permitiendo que las aplicaciones accedan a los recursos de almacenamiento sin preocuparse por su ubicación
• El modelo de consistencia ofrece consistencia fuerte basada en CRAQ (Chain Replication with Apportioned Queries), y el servicio de metadatos tiene una estructura sin estado que usa como backend un almacén transaccional clave-valor como FoundationDB
• Las principales cargas de trabajo son preparación de datos, data loader, checkpointing y KVCache para inferencia; en una prueba de estrés de lectura de un clúster a gran escala registró un rendimiento de lectura agregado de aproximadamente 6.6 TiB/s
• Al compilar, por el uso histórico de std::shuffle, existen problemas de compatibilidad binaria entre versiones de compilador, por lo que se debe especificar el método g++10 o g++11 con -DSHUFFLE_METHOD y mantener la misma configuración después del despliegue del clúster

---

El problema que 3FS busca resolver

• Fire-Flyer File System (3FS) es un sistema de archivos distribuido de alto rendimiento diseñado para cubrir las necesidades de las cargas de trabajo de entrenamiento e inferencia de IA
• Usa SSD modernos y redes RDMA para ofrecer una capa de almacenamiento compartido que simplifica el desarrollo de aplicaciones distribuidas
• Al ofrecer una interfaz de archivos, no es necesario aprender una nueva API de almacenamiento aparte

Arquitectura y consistencia

• La arquitectura desagregada combina el rendimiento de miles de SSD con el ancho de banda de red de cientos de nodos de almacenamiento
  • Las aplicaciones pueden acceder a los recursos de almacenamiento sin tener que conocer su ubicación
• La consistencia fuerte se implementa con Chain Replication with Apportioned Queries (CRAQ)
  • Apunta a una estructura que simplifica el código de la aplicación y facilita el razonamiento sobre su comportamiento
• El servicio de metadatos está diseñado sin estado y usa como backend un almacén transaccional clave-valor como FoundationDB

Cargas de trabajo soportadas

• Preparación de datos

  • Organiza la salida de los pipelines de análisis de datos en una estructura jerárquica de directorios
  • Gestiona de forma eficiente grandes volúmenes de resultados intermedios

• Data loader

  • Permite el acceso aleatorio a muestras de entrenamiento en todos los nodos de cómputo, eliminando la necesidad de precargar o barajar datasets

• Checkpointing

  • Soporta checkpointing paralelo de alto rendimiento para entrenamiento a gran escala

• KVCache para inferencia

  • Ofrece mayor capacidad y alto rendimiento como alternativa rentable al caché basado en DRAM

Resultados de rendimiento

• Rendimiento pico

  • En una prueba de estrés de lectura de un clúster 3FS a gran escala, el rendimiento de lectura agregado alcanzó aproximadamente 6.6 TiB/s
  • El clúster de prueba estaba compuesto por 180 nodos de almacenamiento
    • Cada nodo de almacenamiento tenía 2 NIC InfiniBand de 200 Gbps y 16 SSD NVMe de 14 TiB
    • Se usaron más de 500 nodos cliente
    • Cada nodo cliente estaba configurado con 1 NIC InfiniBand de 200 Gbps
  • El resultado se midió con tráfico en segundo plano de trabajos de entrenamiento
  • Para benchmarks de 3FS se puede usar el motor USRBIO para fio

• GraySort

  • smallpond se evaluó con el benchmark GraySort
  • La implementación consta de dos etapas
    • Particionamiento de datos basado en shuffle usando los bits de prefijo de la clave
    • Ordenamiento dentro de cada partición
  • En ambas etapas se leen datos desde 3FS y se escriben datos en 3FS
  • Configuración del clúster de prueba:
    • 25 nodos de almacenamiento
    • 2 dominios NUMA por nodo
    • 1 servicio de almacenamiento por NUMA
    • 2 NIC de 400 Gbps por nodo
    • 50 nodos de cómputo
    • Los nodos de cómputo estaban configurados con 2 dominios NUMA, 192 núcleos físicos, 2.2 TiB de RAM y 1 NIC de 200 Gbps por nodo
  • La tarea de ordenar 110.5 TiB de datos en 8,192 particiones se completó en 30 minutos y 14 segundos
  • El rendimiento promedio fue de 3.66 TiB/min

• KVCache

  • KVCache es una técnica que, durante la inferencia de LLM, cachea en las capas del decodificador los vectores key/value de tokens anteriores para evitar cálculos redundantes
  • El cliente de KVCache usa 1 NIC de 400 Gbps por nodo
  • El rendimiento de lectura alcanzó hasta 40 GiB/s en el pico
  • Durante el mismo período también se midieron los IOPS de las operaciones de eliminación del GC

Documentación y compilación

• Documentación disponible:
  • Design Notes
  • Setup Guide
  • USRBIO API Reference
  • P Specifications
• Después de clonar el código fuente desde GitHub, se inicializan los submódulos y se aplican los parches
  • git submodule update --init --recursive
  • ./patches/apply.sh
• Los ejemplos de instalación de dependencias soportadas se proporcionan para los siguientes entornos
  • Ubuntu 20.04
  • Ubuntu 22.04
  • openEuler 2403sp1
  • OpenCloudOS 9
  • TencentOS 4
• Requisitos adicionales de compilación:
  • libfuse 3.16.1 o superior
  • FoundationDB 7.1 o superior
  • Rust toolchain mínimo 1.75.0, recomendado 1.85.0 o superior, o la versión estable más reciente
• 3FS se compila con CMake en la carpeta build
  • Los ejemplos de compiladores C/C++ son clang-14 y clang++-14
  • El tipo de build usa el ejemplo RelWithDebInfo

• Compatibilidad del algoritmo de shuffle

  • Por el uso histórico de std::shuffle, los binarios compilados con distintas versiones de compilador, como g++10 y g++11+, pueden no ser compatibles
  • Al compilar, se debe especificar -DSHUFFLE_METHOD para fijar un algoritmo de shuffle consistente
  • Los clústeres existentes deben usar el método correspondiente a la versión de compilador utilizada en el despliegue anterior
  • Los clústeres nuevos pueden elegir entre g++10 o g++11, pero después del despliegue deben mantener la misma configuración en todas las compilaciones futuras
  • Las imágenes Docker de compilación se proporcionan para TencentOS-4 y OpenCloudOS-9
  • Para ejecutar un clúster de prueba, seguir la Setup Guide
  • Los problemas se reportan en GitHub Issues