Desempenho da competição no processamento de dados de IA multimodal: por que o Daft está redefinindo o pipeline de dados

Os motores de dados tradicionais (Spark, Ray) começam a falhar ao lidar com dados multimodais como imagens, vídeos e áudios. Onde está o problema? Explosão de memória, baixa utilização da GPU, e um único computador simplesmente não dá conta.

Por que é tão difícil lidar com dados multimodais

Uma imagem JPEG compactada, uma vez decodificada, expande-se 20 vezes. Um arquivo de vídeo pode gerar milhares de quadros, cada quadro com alguns megabytes. Ao mesmo tempo, tanto a CPU quanto a GPU precisam trabalhar juntas - essa carga de computação híbrida deixa os motores tradicionais completamente confusos.

Daft vs Ray Data: qual é a diferença de desempenho?

Executando cargas de trabalho reais no mesmo cluster de GPU (8 g6.xlarge + NVIDIA L4), os resultados são bem claros:

• Transcrição de áudio (113 mil arquivos): Daft 6 minutos e 22 segundos vs Ray Data 29 minutos e 20 segundos (diferença de 4,6 vezes)
• Incorporação de Documentos (10 mil PDFs): Daft 1m54s vs Ray Data 14m32s (diferença de 7,6 vezes)
• Classificação de Imagens (800 mil): Daft 4m23s vs Ray Data 23m30s (diferença de 5,4 vezes)
• Detecção de vídeo (1000 vídeos): Daft 11 minutos e 46 segundos vs Spark 3 horas e 36 minutos (diferença de 18,4 vezes)

Por que a diferença é tão grande

1. Otimização nativa vs Escrever código próprio

Daft possui operações nativas como decodificação de imagens, incorporação de texto e chamadas LLM, todas altamente otimizadas. Ray Data depende de você para escrever funções Python usando bibliotecas como Pillow e HuggingFace - cada biblioteca tem seu próprio formato de dados, e a conversão constante é um buraco negro de desempenho.

2. Processamento em fluxo vs Acúmulo de memória

O Daft utiliza o motor de execução em fluxo (Swordfish) para manter os dados em constante movimento: a 1000ª imagem está em inferência na GPU, enquanto as imagens de 1001 a 2000 ainda estão a ser descarregadas e decodificadas. Todo o partition nunca é carregado completamente na memória.

Ray Data tende a integrar operações em uma única tarefa, o que pode levar a um aumento excessivo de memória. Você pode usar classes para evitar isso, mas assim os resultados intermediários serão materializados no armazenamento de objetos, aumentando o custo de serialização. Além disso, o armazenamento de objetos do Ray tem, por padrão, apenas 30% da memória da máquina, o que aumenta o risco de estouro.

3. Coordenação de Recursos

Daft permite que CPU, GPU e rede sejam usados em plena capacidade ao mesmo tempo. O Ray Data reserva um núcleo de CPU por padrão para operações de I/O, o que pode causar o bloqueio do processamento da CPU, sendo necessário ajustar manualmente os parâmetros para otimizar.

Como dizer casos práticos

Equipe Essential AI: Processando 23,6 bilhões de documentos da web do Common Crawl com Daft (24 trilhões de tokens), escalando para 32.000 requisições/segundo/VM, eles comentam — “Se usássemos Spark, só para instalar o JVM e ajustar os parâmetros seria um grande esforço. Daft roda localmente muito mais rápido, e escalar para várias máquinas também é muito suave.”

CloudKitchens: Decidiram transformar toda a infraestrutura ML em “DREAM Stack” (Daft + Ray + Poetry + Argo + Metaflow), porque descobriram que o desempenho e as funcionalidades do Ray Data eram insuficientes, e o Daft preencheu essa lacuna.

Engenheiro da ByteDance: Ao executar tarefas de classificação em 1,3 milhão de imagens do ImageNet, o Daft é 20% mais rápido que o Ray Data, além de ser mais eficiente em termos de recursos.

Quando usar Daft e quando usar Ray

Escolha Daft: processamento de dados multimodal, ETL complexo, preocupação com a confiabilidade e o desempenho, preferência por estilo DataFrame/SQL

Escolha Ray Data: Quer uma integração estreita com Ray Train/Ray Serve, necessita de configuração detalhada de CPU/GPU.

Números chave: Daft é de 2 a 7 vezes mais rápido em processamento multimodal, até 4 a 18 vezes mais rápido que Spark, e é estável e confiável. Se a sua carga de trabalho envolve processamento de mídia em larga escala, isso não é opcional, é obrigatório.