Consulta SQL em GPU: 3× mais rápida e ainda assim pior

Consulta SQL em GPU pode perder para a CPU quando os dados vêm do disco. Veja quando comprimir antes de acelerar muda o resultado.

Consulta SQL em GPU perde para a CPU quando os dados estão no disco

Consulta SQL em GPU sobre dados frios, lidos do NVMe, pode ser mais lenta que a mesma consulta na CPU. Em um teste de 2026, a GPU entregou 1,76 GiB/s contra 2,04 GiB/s da CPU — uma desvantagem de cerca de 14%. O motivo não está no processador gráfico, e sim no caminho que os bytes percorrem antes de chegar até ele.

O experimento é de setembro de 2026 e usa hardware comum: uma GPU de desktop, um Xeon de 18 núcleos e um único SSD NVMe. A consulta é analítica simples — soma de uma coluna, junção com uma tabela pequena de consulta e um filtro — sobre 128 milhões de linhas, cerca de 1 GB no disco, segundo o artigo Compression-Aware GPU Buffer Management.

O ponto central: o mesmo operador, com dados já em memória, roda a 71,37 GB/s na GPU contra 23,98 GB/s na CPU. O kernel é cerca de 3× mais rápido. Mesmo assim, o pipeline completo perde, o que mostra que velocidade de kernel não prevê tempo de parede.

Para onde vai o tempo em uma consulta analítica acelerada por GPU

Quase todo o tempo de uma consulta analítica acelerada por GPU é gasto movendo bytes, não calculando. Convertendo as taxas do artigo em milissegundos para a tabela de 1 GB, o pipeline frio da CPU termina em cerca de 490 ms e o da GPU em cerca de 568 ms. Dentro desses 568 ms, o kernel roda por aproximadamente 14 ms.

Ou seja: a GPU calcula durante cerca de 2,5% da execução. Os outros 97% são dados atravessando o SSD, chegando à RAM do host e depois cruzando o barramento PCIe até a memória da placa. Um pipeline anda na velocidade do seu estágio mais lento, e nesse caso o estágio mais lento é o disco, não o processador.

Vale separar o que costuma ser confundido: o PCIe não é o vilão. O artigo estima PCIe entre 16 e 32 GB/s, cerca de dez vezes mais largo que o NVMe, que entrega aproximadamente 1,8 GB/s. O problema é a estrutura de dois saltos — leitura do disco e travessia do barramento — em um orçamento de tempo já consumido no primeiro.

Por que a GPU fica mais lenta, e não apenas empatada

O pipeline de GPU paga o disco e depois paga de novo para cruzar a placa. O caminho da CPU para na RAM; o caminho da GPU continua. É essa passada extra sobre os mesmos bytes que transforma um empate teórico em derrota real de cerca de 14% no teste de setembro de 2026.

O chef de cozinha ajuda a visualizar. Contratar um chef quatro vezes mais rápido não adianta se os legumes chegam numa caixa por hora: o gargalo está antes da faca. Aqui, o kernel ganha sua briga interna e a aplicação perde de qualquer forma.

Há um segundo argumento no mesmo artigo, mais difícil de contestar. Os autores varreram a seletividade do filtro de 1% até 90%, ou seja, o número de linhas que sobrevive ao predicado variou cerca de 90×, de aproximadamente 1,3 milhão para 121 milhões. Os três pipelines ficaram estáveis. Se o trabalho computacional cresce 90× e o tempo não se move, a computação nunca foi o que você estava esperando.

Intensidade aritmética: o que decide se a consulta é limitada por memória

Uma consulta é limitada por memória quando espera bytes chegando, não aritmética terminando. A razão que determina isso se chama intensidade aritmética, definida como a quantidade de operações realizadas para cada byte lido. Essa consulta faz uma comparação, uma busca na tabela pequena e uma soma por linha de 8 bytes — quase nada de trabalho por byte.

Com esse perfil, a máquina trabalha sob o teto de memória, não o de computação. Um modelo de roofline mostra exatamente isso: existe um ponto a partir do qual mais capacidade de cálculo não muda o resultado. Trocar por uma placa mais rápida não moveria o tempo final, porque o tempo nunca esteve no cálculo.

O único gatilho que sobra é reduzir os bytes que trafegam. Se o gargalo está no fio, envie menos pelo fio — e é aqui que a compressão entra, não como truque de GPU, mas como mudança de forma dos dados.

Bandwidth real e efetiva: como a compressão muda o jogo

A coluna do teste usa inteiros de 32 bits, mas todos os valores cabem em 16 bits. Guardar apenas os 16 bits baixos não perde informação: 1 GB vira 512 MB no disco. O SSD continua entregando cerca de 1,8 GB/s físicos, porém cada byte agora carrega o dobro de tabela — a tabela chega a 3,6 GB/s efetivos.

O artigo mantém dois conceitos separados, e vale adotar a distinção. Bandwidth real é o bytes que de fato se moveram. Bandwidth efetiva é a informação que esses bytes representavam. A compressão não acelera o disco; ela faz cada byte valer mais, como uma van que carrega a mesma quantidade de caixas com mais coisa dentro.

A objeção óbvia é o custo de descompactar. Com dados em cache, o operador da GPU rodou a 71,37 GB/s sem compressão e a 67,78 GB/s com a coluna empacotada — cerca de 5% de queda. Essa é a conta inteira do decode, e ela só é barata porque o desempacotamento acontece dentro do operador.

O valor de 16 bits é alargado para 32 bits em um registrador, usado pela aritmética e descartado. Nenhuma cópia descomprimida é escrita na memória. Uma etapa separada que materializasse os dados devolveria exatamente a bandwidth que o empacotamento acabou de comprar.

Fusão do decode no operador e o limite da compressão

Fundir o decode no operador levou o pipeline de GPU de 1,76 para 3,28 GiB/s, cerca de 60% acima da CPU. O mesmo silício participou da execução perdedora e da vencedora; a única variável alterada foi o formato dos dados ao sair do disco.

O ganho não é exclusivo da GPU. A linha da CPU na coluna empacotada subiu de 23,98 para 32,60 GB/s, pelo mesmo motivo: lê metade dos bytes para responder à mesma pergunta. A GPU ganha mais porque tinha ciclos ociosos disponíveis para gastar no decode — uma troca entre computação parada e largura de banda.

Essa troca tem teto. Os autores testaram também um empacotamento de 12 bits, mais agressivo que o de 16. Com dados em cache, ele ficou em 212 GB/s contra 217 GB/s sem compressão alguma, ou seja, ligeiramente mais lento que não fazer nada. A aritmética de posicionamento de bits no laço interno custa quase o que os bytes economizados valem.

A lição, nas palavras do próprio artigo, é que a taxa de compressão sozinha não prevê bandwidth efetiva. O codec precisa ser barato de decodificar, não apenas pequeno.

Coprocessamento CPU/GPU: dividir o scan em vez de escolher

Em vez de escolher um processador, o experimento dividiu o scan entre os dois. Cerca de 40% das linhas foram para a CPU, lendo dados sem compressão na RAM, e 60% para a GPU, lendo a cópia empacotada na placa. Somando as duas somas parciais, o resultado chegou a 3,76 GiB/s, cerca de 15% acima da GPU sozinha.

O modelo dos autores previu o ponto de equilíbrio em 38%, e o melhor medido foi 40%. Os dois processadores não competem pela consulta: são duas faixas de larguras diferentes, e você quer as duas cheias.

Esse equilíbrio se move com o codec. Quanto mais apertada a compressão, mais a divisão ideal desliza de volta para a GPU, porque com payload pequeno o bastante o disco volta a dominar o caminho.

A tabela abaixo resume como cada configuração se comportou no mesmo hardware, com a mesma consulta e a mesma tabela de 1 GB, conforme o artigo de 2026.

Configuração	Throughput	Observação
CPU, coluna sem compressão, disco frio	2,04 GiB/s	Cerca de 490 ms de ponta a ponta
GPU, coluna sem compressão, disco frio	1,76 GiB/s	Cerca de 568 ms; kernel em ~14 ms
GPU, coluna de 16 bits, decode fundido	3,28 GiB/s	Cerca de 60% acima da CPU
CPU + GPU, divisão 40/60	3,76 GiB/s	Cerca de 15% acima da GPU sozinha

Escopo: quando o resultado do benchmark não se transfere

Todos esses números vêm de um artigo, uma consulta, uma tabela e uma estação de trabalho com placa de médio porte e um único NVMe. Mudar qualquer um desses elementos pode mudar o ranking. Se os dados já estiverem na memória da GPU e permanecerem lá, o problema de carregamento que este teste mede simplesmente não existe.

Há uma linha de trabalho que ataca justamente esse cenário. O Sirius, motor SQL nativo de GPU apresentado no CIDR 2026, relata eficiência de custo 8,3× melhor em consultas TPC-H quando acoplado ao DuckDB. Os dois resultados podem ser verdadeiros porque respondem a perguntas diferentes: o Sirius mede a GPU depois que o sistema foi construído em volta dela; o experimento de Bamberg mede o que acontece quando os dados começam frios no disco.

A restrição também aparece fora desse trabalho. Um artigo de 2025 sobre análise SQL sobre dados comprimidos chega à mesma exigência: para não pagar decodificação caro, os operadores precisam trabalhar diretamente sobre dados comprimidos.

Perguntas frequentes sobre consulta SQL em GPU

• Vale a pena rodar consulta SQL em GPU? Depende de onde os dados estão e em que formato chegam. Com dados frios no NVMe e sem compressão, um teste de 2026 mediu a GPU como cerca de 14% mais lenta que a CPU. Com coluna de 16 bits e decode fundido no operador, o mesmo hardware passou a superar a CPU em cerca de 60%.

• Por que a GPU fica lenta se o kernel dela é 3× mais rápido? Porque o kernel responde por uma fração mínima do tempo total. Nesse teste, ele rodou por cerca de 14 ms dentro de uma execução de aproximadamente 568 ms. O restante foi gasto movendo bytes do SSD para a RAM do host e depois pelo PCIe.

• Compressão é um truque só para GPU? Não. A linha da CPU também melhorou, de 23,98 para 32,60 GB/s, porque passou a ler menos bytes para responder à mesma pergunta. A GPU ganha mais apenas porque tinha mais ciclos ociosos para gastar no decode.

• Mais compressão é sempre melhor? Não. O empacotamento de 12 bits ficou em 212 GB/s contra 217 GB/s da coluna sem compressão alguma. O custo da aritmética de bits no laço interno pode anular os bytes economizados, então o codec precisa ser barato de decodificar.

• Preciso escolher entre CPU e GPU para o scan? Não necessariamente. Dividir o scan em 40% para a CPU e 60% para a GPU chegou a 3,76 GiB/s, cerca de 15% acima da GPU sozinha. O ponto de equilíbrio se desloca conforme o codec muda.

Source video