Cómo Daft reinventa la canalización de datos para cargas de trabajo multimodales: una arquitectura completa y análisis de rendimiento

La explosión de aplicaciones de IA multimodal ha puesto al descubierto brechas críticas en la infraestructura tradicional de procesamiento de datos. Cuando Spark y Ray Data abordan decodificación de imágenes, transcripción de audio y extracción de cuadros de video, sus arquitecturas rígidas se desploman. La memoria se inflama de manera impredecible, los ciclos de GPU permanecen ociosos durante cuellos de botella en I/O, y los clústeres acumulan ineficiencias masivas. Daft representa un replanteamiento fundamental de cómo los sistemas distribuidos de datos deben manejar demandas heterogéneas de cómputo.

¿Qué hace diferente al procesamiento de datos multimodal?

Los motores tradicionales de pipelines de datos fueron diseñados para agregaciones SQL y uniones de tablas. Las cargas de trabajo multimodales operan en una dimensión completamente distinta:

Inflación de memoria: Un archivo JPEG se multiplica por 20 una vez descomprimido. Un video de 2 horas se decodifica en miles de cuadros individuales, cada uno consumiendo megabytes. El pipeline de datos debe anticipar estas explosiones y gestionarlas dinámicamente.

Requisitos fragmentados de cómputo: Las cadenas de procesamiento demandan saturación simultánea de CPU, GPU y red. Una sola carga incluye descarga, decodificación, remuestreo, extracción de características, normalización, inferencia y clasificación — operaciones que estresan diferentes componentes hardware en distintas fases.

Demandas de escala: Las cargas de trabajo recientes en producción han alcanzado proporciones asombrosas: Common Voice 17 contiene 113,800 archivos de audio; Common Crawl tiene 10,000 PDFs; ImageNet abarca 803,580 imágenes; Hollywood2 incluye 1,000 videos. La infraestructura del pipeline de datos debe escalar sin problemas en todos ellos.

Arquitectura de streaming de Daft: rompiendo el cuello de botella

Daft reestructura fundamentalmente cómo fluye la data a través de un sistema distribuido. Su motor de ejecución en streaming Swordfish trata los datos como en perpetuo movimiento en lugar de lotes estáticos en memoria.

Modelo de flujo continuo: Para una partición que contiene 100,000 imágenes, las primeras 1,000 se mueven inmediatamente a inferencia en GPU mientras el siguiente lote se descarga o decodifica. Nunca un punto intermedio de materialización bloquea el pipeline. El sistema mantiene un movimiento constante en todas las etapas de procesamiento.

Retroalimentación inteligente (Backpressure): Cuando la inferencia en GPU se vuelve el factor limitante, las operaciones upstream se regulan automáticamente. Este enfoque de memoria acotada previene el consumo descontrolado de memoria que aqueja a sistemas competidores.

Particionamiento adaptativo: Operaciones intensivas en memoria como url_download y image_decode ajustan automáticamente sus tamaños de lote en tiempo real. El sistema sacrifica paralelismo granular por una sobrecarga de memoria predecible y un rendimiento sostenido.

Coordinación distribuida vía Flotilla: Cada nodo del clúster ejecuta un trabajador Swordfish, permitiendo que el modelo en streaming escale horizontalmente sin comprometer la arquitectura. Los mismos principios de eficiencia aplican ya sea procesando terabytes localmente o petabytes en un clúster.

La pipeline de datos de Daft además ofrece capacidades nativas específicas para operaciones multimodales: primitivas de codificación/decodificación/corte/reescalado de imágenes, capas de incrustación de texto e imagen, integraciones con LLM, tokenización, operaciones de similitud coseno, manejo de URLs y conversiones de video a cuadros, todo como expresiones de primera clase en lugar de funciones externas en Python.

Enfoque de Ray Data: compromisos en generalidad

Ray Data se construye sobre el framework distribuido de Python de Ray, exponiendo abstracciones de menor nivel. Los usuarios componen operaciones mediante funciones map_batches aplicadas a lotes de PyArrow o DataFrames de pandas.

Dentro de operaciones secuenciales, Ray Data las fusiona en tareas únicas — una optimización que resulta contraproducente en cargas de trabajo multimodales. Sin una afinación manual cuidadosa del tamaño de bloques, el consumo de memoria se dispara de forma impredecible. Los usuarios pueden materializar intermedios en el almacén de objetos de Ray envolviendo lógica en clases, pero esto implica sobrecarga de serialización y copias de memoria. Dado que el almacén de objetos de Ray por defecto solo usa el 30% de la memoria del sistema, se vuelve inevitable el spilling a disco.

La flexibilidad de la pipeline de datos tiene un costo en previsibilidad y eficiencia.

La realidad del rendimiento: los números

Benchmark en infraestructura idéntica (8 instancias g6.xlarge de AWS, cada una con GPUs NVIDIA L4, 4 vCPUs, 16 GB de memoria, 100 GB EBS) revelan diferencias marcadas:

Daft ejecuta pipelines de audio entre 4.6 y 29 veces más rápido que las alternativas. El procesamiento de documentos acelera entre 4.2 y 7.6 veces. La clasificación de imágenes muestra mejoras de 5.4 a 10.3 veces. Las cargas de video revelan la brecha más dramática: Daft termina en 11m 46s mientras Spark requiere 3h 36m — una diferencia de 18.4 veces.

¿Por qué la brecha de rendimiento?

Operaciones nativas multimodales vs UDFs externas: Daft implementa decodificación de imágenes, inferencia de incrustaciones y extracción de cuadros de video como expresiones internas optimizadas. Ray Data obliga a los usuarios a escribir UDFs en Python que invocan Pillow, NumPy, Hugging Face y otras librerías. Cada librería mantiene su propio formato de datos, generando movimientos y serializaciones innecesarias.

Modelo de memoria en streaming vs materialización: Daft transmite datos de forma asíncrona desde almacenamiento en la nube a través de CPUs hacia memoria GPU y de regreso a la salida. Ninguna partición se materializa completamente en un buffer intermedio. La fusión de operaciones en Ray Data causa picos de memoria a menos que los usuarios optimicen manualmente el tamaño de bloques, y las soluciones alternativas introducen penalizaciones de serialización.

Estrategia de saturación de recursos: Daft pipelinea todo el procesamiento dentro de un único trabajador Swordfish con gestión unificada de recursos. Descargas, preprocesamiento en CPU, inferencia en GPU y carga de resultados fluyen por el mismo contexto de ejecución, manteniendo saturados CPU, GPU y red constantemente. Ray Data reserva núcleos CPU dedicados para operaciones I/O intensivas por defecto, dejando núcleos infrautilizados para cómputo. Lograr una distribución óptima de recursos requiere ajuste manual fraccional de CPU.

¿Qué sistema para qué escenario?

Daft destaca cuando:

• Procesa conjuntos de datos multimodales (imágenes, video, audio, documentos, incrustaciones)
• Priorizan fiabilidad y rendimiento predecible sin sobrecarga de ajuste
• Construyen transformaciones complejas en pipelines de datos con joins, filtros y agregaciones
• Equipos acostumbrados a semánticas DataFrame/SQL

Ray Data sigue siendo valioso cuando:

• La integración profunda con el ecosistema Ray es esencial (Ray Train para entrenamiento distribuido, Ray Serve para despliegue de modelos)
• El control granular de asignación de CPU/GPU por operación justifica la complejidad adicional

Validación en producción

Prueba de escala de AI de Essential: Tim Romanski y su equipo taxonomizaron 23.6 mil millones de documentos web de Common Crawl (24 billones de tokens) usando Daft, escalando a 32,000 solicitudes por segundo por VM. Su evaluación: “Llevamos Daft al límite y está probado en batalla. Si tuviéramos que replicar esto en Spark, necesitaríamos configuración JVM, gestión de classpath y solución de problemas extensa solo para lanzar. El tiempo de ejecución en Daft fue drásticamente menor, y escalar desde desarrollo local a clústeres requirió cambios arquitectónicos mínimos.”

Reconstrucción de infraestructura de CloudKitchens: Este equipo reestructuró toda su plataforma de ML en torno a la pila “DREAM” (Daft, Ray, poetry, Argo, Metaflow). Su equipo de infraestructura identificó limitaciones específicas de Ray Data durante la evaluación: cobertura incompleta de DataFrame/ETL y rendimiento subóptimo. Eligieron Daft para complementar la capa de cómputo de Ray, destacando “Daft llena los vacíos de Ray Data proporcionando APIs completas de DataFrame” y “entregó una ejecución más rápida que Spark consumiendo menos recursos en nuestras pruebas.”

Validación a gran escala de ByteDance: Al evaluar clasificación de imágenes en 1.28 millones de muestras de ImageNet, los ingenieros de ByteDance observaron que Daft mantenía aproximadamente un 20% más de rendimiento que Ray Data. Su análisis técnico destacó “excelente rendimiento de ejecución y eficiencia de recursos” además de “procesamiento en streaming sin fisuras de conjuntos de datos de imágenes a gran escala.”

Mirando hacia adelante

El panorama del pipeline de datos está en plena transformación estructural. Las cargas de trabajo multimodales exponen decisiones arquitectónicas que funcionaron para análisis tradicionales pero fallan bajo presión de cómputo heterogéneo. La filosofía de diseño de Daft — streaming continuo, operaciones nativas multimodales, gestión adaptativa de recursos y ejecución unificada en clúster — no representa una optimización incremental sino un reinicio de categoría. Las organizaciones que procesan imágenes, audio, documentos y video a escala descubren que rearquitectar siguiendo estos principios ofrece mejoras de rendimiento de 2 a 7 veces sin sacrificar fiabilidad ni requerir una profunda experiencia en infraestructura.