Vortex leva dados do S3 à GPU em uma única cópia

O problema: dois "impostos" no carregamento de dados para GPUs

Onur Satici, da SpiralDB, palestrou no QCon London 2026 sobre o Vortex, formato colunar de código aberto mantido sob a Linux Foundation. O ponto de partida: GPUs são caras e ficar ociosas gera custo de oportunidade. Ele identifica dois obstáculos no carregamento de dados para treinamento de modelos. O primeiro é o "imposto de movimento": no fluxo tradicional, com WebDataset ou MosaicML Streaming Dataset, os dados vão do S3 para NVMe, depois para RAM, são descomprimidos na CPU e enviados via PCIe à GPU. O gargalo está na descompressão em CPU e na taxa do NVMe, e a persistência em disco decorre do PyTorch usar multiprocessamento para contornar as limitações de threads do Python.

O segundo é o "imposto de decisão": ao iterar no treinamento - mudar mix de dados, curriculum ou filtros - é preciso reprocessar tudo, re-tokenizar, reembaralhar e recarregar, o que é lento.

O que é o Vortex

Vortex é um formato colunar semelhante ao Parquet, mas com diferenças: especificação mínima e extensível; separação entre tipos lógicos e físicos (a codificação em disco é desacoplada dos tipos); filosofia de fazer o mínimo possível o mais tarde possível; projeções, filtros e agregações podem ser empurrados do motor de computação para o formato; e compressão por codificações leves e em cascata, em vez de compressão em blocos. Isso preserva o significado dos dados e permite computação direta sobre dados comprimidos, incluindo acesso aleatório - algumas operações ficam mais rápidas que sobre dados descomprimidos. Comparado ao Parquet, o autor cita varreduras S3→GPU cerca de 30 vezes mais rápidas e acesso aleatório 100 vezes ou mais mais rápido.

Estrutura do arquivo: um Postscript de tamanho fixo com ponteiros, um footer funcionando como "lista de materiais" com arrays, layouts e segmentos (a maior parte do arquivo, com offset, comprimento e alinhamento - o alinhamento evita cópias ao despachar SIMD ou kernels de GPU). Layouts funcionam como plano lógico e camada de I/O para poda: cada nó da árvore indica quais segmentos ler dado um filtro. ZonedLayouts incluem zone-maps com estatísticas (mínimo, máximo) por faixa de linhas, permitindo, no exemplo citado, satisfazer uma consulta lendo o zone-map e apenas 30% dos segmentos. A compressão é "fatiável": só se descomprimem as linhas relevantes.

Arrays e codificações

Os segmentos contêm arrays Vortex, organizados em árvores. O exemplo demonstra codificação progressiva de um array de listas de strings: ListArray (valores achatados + offsets), depois codificação por dicionário (separa valores únicos das repetições), run-end encoding e bit packing - o resultado pode ocupar menos de 4 bytes. O autor distingue plano de controle (estrutura do array, usada para despachar computação) e plano de dados (bytes transferidos). Sobre dados comprimidos, computações como somar um run-end array podem ser mais rápidas que sobre dados descomprimidos.

Varredura e a cópia única até a GPU

O scan orquestra I/O e computação para mantê-las ocupadas, com uma camada de coalescência que mescla faixas de bytes próximas para pagar a latência uma vez - configuração que depende da fonte (S3 admite segmentos de 16 MB). No caminho S3→GPU, os bytes atravessam buffer de kernel, descriptografia TLS, deframing HTTP e agregação de chunks; a cópia via CUDA introduz ainda outra cópia interna por exigir buffers fixados (pinned). Cada memcpy consome núcleos de CPU que poderiam servir à orquestração e ao cálculo.

As otimizações: buffer pool com pinned buffers e eventos CUDA para reutilização; kTLS para descriptografar no kernel e eliminar uma cópia; escrever um cliente HTTP próprio que acumula os bytes direto no buffer já fixado para CUDA - chegando a uma única cópia do S3 à GPU; e, com RDMA, contornar completamente a CPU e até o hub PCIe, com o próprio GPU despachando o I/O pela placa de rede associada.

O que é possível

A demonstração processa vídeo 4K a 60 quadros por segundo (~13 Gbps, sustentando 60 Gbps ponta a ponta, com o vídeo desacelerado para exibição) diretamente do S3 à GPU, com uma cópia. Filtros e projeções personalizados - como uma expressão "quantise" com kernel próprio, ou poda por coluna booleana has_bike gerada por reconhecimento de objeto - não afetam a taxa de transferência; só os dados necessários são lidos. Como a especificação não exige que os segmentos fiquem no mesmo arquivo, é possível separar segmentos de poda (ex.: Redis, com centésimo da latência do S3) dos dados (S3). Agregações entre GPUs podem ser modeladas como varredura RDMA via NVLink, em terabits por segundo. Nas conclusões: mudar filtros e mix de dados sem reprocessar, leitura do S3 à GPU na velocidade da placa de rede (60 Gbps ou mais) e, com RDMA, no limite do PCIe - até 500 Gbps ou terabits nas versões mais novas.