La competencia en el rendimiento del procesamiento de datos multimodal de IA: por qué Daft está redefiniendo los pipelines de datos

Los motores de datos tradicionales (Spark, Ray) comienzan a fallar al procesar datos multimodales como imágenes, videos y audios. ¿Cuál es el problema? Explosión de memoria, baja utilización de la GPU, y una sola máquina no puede soportarlo.

¿Por qué es tan difícil masticar los datos multimodales?

Una imagen JPEG comprimida, una vez decodificada, se expande 20 veces. Un archivo de video puede generar miles de fotogramas, cada uno de varios megabytes. Al mismo tiempo, CPU y GPU deben trabajar juntos: esta carga de cálculo híbrida deja completamente atón motores tradicionales.

Daft vs Ray Data: ¿Cuánto difieren en rendimiento?

Al ejecutar cargas de trabajo reales en el mismo clúster de GPU (8 g6.xlarge + NVIDIA L4), los resultados son muy claros:

• Transcripción de audio (113,000 archivos): Daft 6 minutos 22 segundos vs Ray Data 29 minutos 20 segundos (diferencia de 4.6 veces)
• Incorporación de documentos (10,000 PDF): Daft 1 minuto 54 segundos vs Ray Data 14 minutos 32 segundos (diferencia de 7.6 veces)
• Clasificación de imágenes (800,000 imágenes): Daft 4 minutos 23 segundos vs Ray Data 23 minutos 30 segundos (diferencia de 5.4 veces)
• Detección de video (1000 videos): Daft 11 minutos 46 segundos vs Spark 3 horas 36 minutos (diferencia de 18.4 veces)

¿Por qué la diferencia es tan grande?

1. Optimización nativa vs escribir código por uno mismo

Daft incorpora operaciones nativas como decodificación de imágenes, incrustación de texto y llamadas a LLM, todo ello altamente optimizado. Ray Data depende de que escribas funciones en Python utilizando bibliotecas como Pillow y HuggingFace; cada biblioteca tiene su propio formato de datos, y la conversión entre ellos es un agujero negro de rendimiento.

2. Procesamiento en flujo vs Acumulación en memoria

Daft utiliza el motor de ejecución en streaming (Swordfish) para mantener los datos en movimiento: la imagen 1000 se está inferiendo en la GPU, y las imágenes de la 1001 a la 2000 aún se están descargando y decodificando. La partición completa nunca se cargará completamente en la memoria.

Ray Data tiende a fusionar operaciones en una sola tarea, lo que puede llevar a un aumento desmedido de la memoria. Puedes usar clases para evitarlo, pero eso materializará los resultados intermedios en el almacenamiento de objetos, aumentando así el costo de serialización. Además, el almacenamiento de objetos de Ray por defecto solo utiliza el 30% de la memoria de la máquina, lo que conlleva un alto riesgo de sobrecarga.

3. Coordinación de recursos

Daft permite que la CPU, GPU y la red funcionen al máximo al mismo tiempo. Ray Data reserva un núcleo de CPU para operaciones de I/O por defecto, lo que puede provocar que el trabajo de procesamiento de la CPU se bloquee, requiriendo ajustes manuales para optimizar.

Cómo se dice un caso práctico

Equipo de Essential AI: Procesando 23.6 mil millones de documentos web de Common Crawl (24 billones de tokens) con Daft, escalando a 32,000 solicitudes/segundo/VM, su evaluación es: “Si usas Spark, solo la instalación de JVM y la optimización de parámetros requieren mucho esfuerzo. Daft se ejecuta mucho más rápido localmente y escalar a múltiples máquinas es muy fluido.”

CloudKitchens: Decidieron convertir toda la infraestructura de ML en “DREAM Stack” (Daft + Ray + Poetry + Argo + Metaflow), porque descubrieron que el rendimiento y las funcionalidades de Ray Data no eran suficientes, y Daft llenó ese vacío.

Ingeniero de ByteDance: Ejecutando una tarea de clasificación en 1.3 millones de imágenes de ImageNet, Daft es un 20% más rápido que Ray Data, y además utiliza menos recursos.

¿Cuándo usar Daft y cuándo usar Ray?

Elija Daft: procesamiento de datos multimodal, ETL compleja, se preocupa por la fiabilidad y el rendimiento, le gusta el estilo DataFrame/SQL

Seleccionar Ray Data: Integración estrecha con Ray Train/Ray Serve, necesita configuración detallada de CPU/GPU.

Números clave: Daft es de 2 a 7 veces más rápido en el procesamiento multimodal, de 4 a 18 veces más rápido que Spark, y además es estable y confiable. Si tu carga de trabajo implica el procesamiento de medios a gran escala, esto no es una opción, es una necesidad.