El sistema de archivos Fire-Flyer de DeepSeek

Sistema de archivos Fire-Flyer

El sistema de archivos Fire-Flyer (3FS) es un sistema de archivos distribuido de alto rendimiento diseñado para resolver los problemas de las tareas de entrenamiento e inferencia de IA. Aprovecha SSD modernos y redes RDMA para ofrecer una capa de almacenamiento compartido que simplifica el desarrollo de aplicaciones distribuidas.

Rendimiento y usabilidad

• Arquitectura desacoplada: combina el ancho de banda de red de miles de SSD y cientos de nodos de almacenamiento para que las aplicaciones puedan acceder a los recursos de almacenamiento sin depender de la localidad.
• Consistencia fuerte: implementa Chain Replication with Apportioned Queries (CRAQ) para ofrecer consistencia fuerte, haciendo que el código de las aplicaciones sea más simple y fácil de entender.
• Interfaz de archivos: se desarrolló un servicio de metadatos sin estado basado en un almacén transaccional de clave-valor (por ejemplo, FoundationDB). La interfaz de archivos es ampliamente conocida y se usa en todas partes. No hace falta aprender una nueva API de almacenamiento.

Diversas cargas de trabajo

• Preparación de datos: organiza la salida de los pipelines de análisis de datos en una estructura jerárquica de directorios y gestiona eficientemente grandes volúmenes de salidas intermedias.
• Cargador de datos: permite acceso aleatorio a las muestras de entrenamiento a través de los nodos de cómputo, por lo que no es necesario precargar ni barajar el conjunto de datos.
• Checkpointing: admite checkpointing paralelo de alta velocidad para entrenamiento a gran escala.
• KVCache para inferencia: ofrece una alternativa rentable al caché basado en DRAM, con alto rendimiento y una capacidad considerablemente grande.

Rendimiento

1. Rendimiento pico

• En una prueba de estrés de lectura a gran escala del clúster 3FS, se logró un rendimiento agregado final de lectura de aproximadamente 6.6 TiB/s.

2. GraySort

• Se evaluó usando el benchmark GraySort, que mide el rendimiento de ordenamiento de conjuntos de datos a gran escala. Ordenar 110.5 TiB de datos en 8,192 particiones tomó 30 minutos y 14 segundos, logrando un rendimiento promedio de 3.66 TiB/min.

3. KVCache

• Se usó la tecnología KVCache para optimizar el proceso de inferencia de LLM. Al almacenar en caché los vectores de clave y valor de los tokens previos de las capas del decodificador, se evita el cómputo redundante. El rendimiento pico alcanzó hasta 40 GiB/s.

Documentación

• Notas de diseño
• Guía de configuración
• Referencia de la API USRBIO
• Especificación P

Revisar el código fuente

• Puedes clonar el repositorio de 3FS en GitHub para revisar el código fuente.

Reporte de problemas

• Para reportar problemas, visita la página de issues de GitHub.

[GN⁺]

Comentarios en Hacker News

• Este diseño se presentó originalmente aquí: enlace

  • Este sistema de archivos ha sido desarrollado y utilizado durante varios años
  • Está más enfocado en el entrenamiento de modelos en comparación con los sistemas de archivos tradicionales
  • Cuando hay muchas lecturas aleatorias, la caché de lectura y el prefetch no sirven de mucho
  • Diseñaron el sistema de archivos sin esas funciones para mejorar el rendimiento

• 3FS se usa durante el entrenamiento de IA en escenarios donde los nodos de cómputo leen datos de muestras por lotes

  • Acelera el entrenamiento de modelos mediante la interacción entre cómputo de alta velocidad y almacenamiento
  • Se trata de una carga de trabajo de lecturas aleatorias a gran escala, y los datos leídos no se reutilizan en poco tiempo
  • Por lo tanto, no se puede aprovechar la "caché de lectura", y la lectura anticipada tampoco resulta útil
  • 3FS es bastante diferente de otros sistemas de archivos en su implementación

• 3FS usa AIO basado en Linux y la interfaz io_uring para completar la lectura de muestras

  • La caché de archivos no aporta ningún beneficio y consume memoria del sistema, afectando las tareas posteriores
  • Desactiva la caché de archivos y lee los datos solo en modo Direct I/O
  • Es necesario alinear el puntero del búfer, el offset y la longitud
  • Si el usuario hace la alineación, se produce una copia adicional de memoria, así que el sistema de archivos la realiza internamente
  • Optimiza el rendimiento y ofrece comodidad al usuario

• Una de las diferencias entre DeepSeek y OpenAI/Anthropic es la diferencia entre gente práctica y académicos

  • OpenAI tiene talento de nivel mundial, pero también hay personas con poca exposición técnica

• Los sistemas de archivos distribuidos se consideran uno de los tipos de software más difíciles de desarrollar

  • Hay quienes aconsejan no escribir un sistema de archivos desde cero, ni siquiera sobre FUSE
  • Mientras una empresa de Silicon Valley tendría su reunión número 100, un equipo de menos de 60 personas desarrolló un sistema de archivos paralelo de alta eficiencia

• Artículo de investigación relacionado: enlace

  • "Fire-Flyer AI-HPC: codiseño de software y hardware rentable para aprendizaje profundo"
  • Con el rápido avance del aprendizaje profundo y los grandes modelos de lenguaje, la demanda de capacidad de cómputo y ancho de banda se ha disparado
  • Presenta la arquitectura Fire-Flyer AI-HPC para reducir costos y consumo energético
  • Diseña HFReduce para acelerar la comunicación allreduce
  • Implementa varias medidas para evitar la congestión en la Computation-Storage Integrated Network

• Me preguntaba cómo logran ese rendimiento con un diseño basado en FUSE

  • FUSE se usa para gestionar metadatos, y para obtener alto rendimiento hay que enlazar una biblioteca cliente en C++
  • No es de propósito general y requiere modificar la aplicación
  • Aun así, es un enfoque inteligente, y me pregunto si la estrategia de LD_PRELOAD podría generalizarse

• OpenAI y otros también están profundamente involucrados en sus sistemas, pero es difícil ver este nivel de cuidado en otros lugares

  • Es un gran trabajo, y espero que DeepSeek haga cosas aún más impresionantes en el futuro

• Definitivamente son productivos

  • ¿Qué veremos mañana? ¿Algo como DeepSeek OS?

• No está claro dónde y cómo se quedan cortos los sistemas populares actuales

  • Me pregunto en qué se diferencia este patrón de acceso a datos de los casos de uso tradicionales

• Me pregunto si habría ventajas en portarlo a un orquestador como K8s

  • Puede ser excesivo para entrenamiento, pero KVCache podría ser útil para inferencia con múltiples réplicas

• Me pregunto si hay alguien que pueda convencerme de que esto no es síndrome NIH

  • Me pregunto por qué habría que usar esto en lugar de SeaweedFS, Ceph o MinIO