Você deixa o Jupyter processando um groupby sobre um arquivo de 8 GB, sai para almoçar e volta com a célula ainda ocupada. A busca de hiperparâmetros do XGBoost entrou pela madrugada e, a cada feature nova, tudo recomeça. A conclusão parece óbvia: falta placa de vídeo. É por aí que começa a pesquisa por GPU para data science, e é aí que a maioria das listas de placas erra o alvo.

O erro é tratar ciência de dados como sinônimo de treino de rede neural. O cientista de dados passa a maior parte do tempo em leitura de arquivo, limpeza, junção de tabelas, feature engineering, gradient boosting e análise exploratória. Rede neural aparece, mas ocupa fatia menor da semana, e as duas cargas pedem decisões diferentes de VRAM, memória de sistema e disco. Antes de escolher modelo de placa, portanto, vale responder duas perguntas: no seu fluxo, a GPU adianta alguma coisa, e quanta memória isso exige?

A verdade desconfortável: boa parte do seu dia não toca na GPU

O pandas executa a maior parte das operações em uma única thread. Um merge entre tabelas grandes, um sort_values, um apply linha a linha: tudo isso ocupa um núcleo enquanto os outros ficam ociosos, e ler um CSV comprimido é trabalho de disco e de CPU. O scikit-learn segue a mesma lógica: regressão logística, árvore isolada e validação cruzada rodam em CPU sobre as bibliotecas de álgebra linear.

Antes de comprar, faça um diagnóstico de dez minutos rodando o pipeline mais pesado com três indicadores à vista. GPU perto de zero e um núcleo fixo em 100% indicam gargalo de thread única, que se resolve reescrevendo a operação. RAM cheia e paginação em disco indicam gargalo de capacidade, e mais VRAM não muda nada. A placa só entra quando a operação é paralela sobre muitas linhas e o dado cabe, inteiro ou em pedaços, na memória dela.

Onde a GPU muda o jogo em ciência de dados

O RAPIDS, da NVIDIA, é o pacote que aproxima a ciência de dados tabular da placa. O cuDF é a biblioteca de dataframes e o cuML traz os algoritmos clássicos com API parecida com a do scikit-learn: k-means, KNN, DBSCAN, PCA, floresta aleatória, regressão logística. O que mudou o jogo foi o modo acelerador do pandas, em que você mantém o mesmo código e as operações suportadas migram para a GPU, com retorno automático para a CPU quando não há versão acelerada.

Sobre magnitude de ganho, convém ser preciso. A NVIDIA publicou, em seu blog técnico sobre o cuDF, um caso próximo de 150 vezes sobre um conjunto de 5 GB, comparando uma plataforma Grace Hopper com um Xeon de servidor. É número de laboratório. Em workstation com placa de consumo e dataframe de poucos gigabytes, o realista para groupby, join e ordenação fica em torno de uma ordem de grandeza, o que já separa um café de uma tarde inteira.

Para dado tabular, porém, o maior retorno vem do gradient boosting. A documentação oficial do XGBoost descreve o caminho: device="cuda" com tree_method="hist" leva treino, predição e avaliação para a placa. A mesma fonte explica que o dataset é comprimido em formato ELLPACK, ocupando cerca de um quarto do espaço de uma matriz esparsa. LightGBM e CatBoost têm caminhos equivalentes.

A construção de histogramas paraleliza muito bem: em centenas de milhares de linhas a diferença é modesta, mas em dezenas de milhões com centenas de features a GPU transforma horas de treino em minutos. Fecham a lista as cargas de rede neural e a inferência em lote, onde a placa vira requisito, porque o modelo não carrega se não couber na memória.

Como dimensionar VRAM para ciência de dados

A regra do trabalho tabular em GPU é a folga. Um dataframe não ocupa apenas o próprio tamanho: junções, agregações e ordenações criam estruturas intermediárias que chegam a várias vezes o volume base. Planeje VRAM em torno de duas a três vezes o tamanho que a tabela ocupa em memória, que não é o tamanho do arquivo em disco: um CSV de 10 GB infla ao virar objeto, e a mesma tabela em Parquet, com colunas categóricas e float32, cai para uma fração disso. Quando não cabe, particione com Dask-cuDF, use memória gerenciada para transbordar para a RAM do sistema, ou amostre na exploração e rode completo só no final.

Modelo de linguagem segue outra aritmética. Ajuste completo acomoda pesos, gradientes, estados do otimizador e ativações ao mesmo tempo, o que multiplica várias vezes o tamanho dos pesos. LoRA e quantização derrubam esse custo e tornam viável usar modelos de 7 a 13 bilhões de parâmetros em uma placa de 24 GB. Inferência é bem mais barata, e o dimensionamento está no guia sobre quanta VRAM é preciso para rodar um LLM local. O batch size é a alavanca principal e resolve a maior parte dos estouros, ao custo de tempo.

A GPU adianta na sua tarefa?

Três perfis de configuração de GPU para data science

Escolher a placa isolada leva a máquina desequilibrada: VRAM sem RAM e sem disco rápido não entrega o que promete.

O modelo dentro de cada faixa depende de geração, largura de banda e formato físico da placa, assunto tratado no guia de placa de vídeo para workstation.

Linha de consumo ou placa profissional para este uso

Para quem trabalha sozinho, com dado tabular e ajuste eventual de modelo, a placa de consumo de topo entrega mais VRAM e mais largura de banda por real investido. Pelo critério de custo por gigabyte de memória útil, a linha de consumo ganha com folga.

A linha profissional se justifica em três situações. A primeira é densidade de VRAM, porque há um patamar de memória por placa que o consumo não oferece, e quando o modelo não cabe nenhum desconto compensa. A segunda é memória ECC, que corrige erros de bit em silêncio e pesa quando uma rotina de dias pode corromper um resultado destinado a relatório regulatório. A terceira é operação contínua com duas placas: o formato de dois slots com exaustão traseira permite empilhá-las em um chassi, coisa que uma placa de consumo de três slots transforma em projeto térmico.

CUDA, ROCm e o peso do ecossistema na decisão

O silício importa menos que a biblioteca. O ecossistema de ciência de dados em GPU nasceu sobre CUDA e segue ancorado ali: cuDF, cuML, o caminho de GPU do XGBoost e os frameworks de deep learning assumem CUDA como primeira opção, e a página de soluções de ciência de dados da NVIDIA organiza o portfólio em torno disso.

Do lado da AMD, a matriz de compatibilidade do ROCm lista suporte às linhas Instinct, às Radeon RX recentes e às Radeon PRO de workstation, com frameworks como PyTorch e JAX. É base sólida para deep learning, mas não traz equivalente maduro para dataframe em GPU nem para algoritmos clássicos acelerados. Traduzindo para a compra: se o seu trabalho é PyTorch, ROCm é viável; se é tabela grande e gradient boosting em placa, a pilha RAPIDS é território CUDA. Confira também o driver, porque a documentação do XGBoost exige um CUDA recente e uma instalação antiga bloqueia o recurso sem mensagem clara.

Máquina local ou nuvem para ciência de dados

A instância com GPU cobra por hora ligada, e o cientista de dados trabalha de forma exploratória, com a máquina acesa o dia todo. Oito horas por dia, vinte e dois dias úteis, dão cerca de 176 horas por mês. Uma instância de classe 24 GB sob demanda custa alguns dólares por hora, então o gasto mensal vai da casa das centenas de reais a vários milhares, antes de somar armazenamento persistente e tráfego de saída. Estenda por 24 a 36 meses e o total cruza o valor de uma workstation bem especificada.

Dois argumentos pesam ainda mais em decisão corporativa. O primeiro é previsibilidade: a fatura de nuvem varia com uso, câmbio e reajuste, enquanto um ativo comprado é linha fixa de orçamento. O segundo é soberania de dado, porque base de saúde, dado financeiro e cadastro sujeito à LGPD trazem um custo de conformidade que costuma anular a economia de tirar o dado da instituição, tese desenvolvida no guia de workstation para inteligência artificial. O arranjo que funciona não é escolher um lado: máquina local para o ciclo diário e nuvem para o pico.

Quatro erros que estragam o investimento

Quatro descuidos aparecem com frequência e todos custam desempenho que já foi pago:

• Placa de topo com 32 GB de RAM. Se o dataframe não cabe na memória do sistema, você nem consegue montá-lo para enviar à GPU. Mantenha a RAM em pelo menos o dobro da VRAM, e o quádruplo em trabalho tabular pesado. Onde alocar cada real está no artigo sobre CPU ou GPU para machine learning.
• Ignorar o disco. Dataset de centenas de gigabytes em SSD SATA ou em pasta de rede transforma cada época e cada releitura em espera. NVMe é requisito, não luxo.
• Esquecer fonte e refrigeração. Placas de topo têm picos transientes acima do consumo nominal: fonte apertada derruba a máquina no meio de um treino de doze horas e refrigeração curta reduz a frequência.
• VRAM demais e processador de menos. Leitura e feature engineering continuam em CPU, e uma GPU esperando o pandas é dinheiro parado. O panorama de prioridades está no guia sobre o que priorizar em hardware para IA e ciência de dados.

Configuração Zenion recomendada

A Zenion parte do fluxo antes da peça: quais bibliotecas você usa, o tamanho real das suas tabelas em memória, com que frequência aparece treino de rede neural e se o dado pode sair da instituição. A partir daí, três pontos de partida:

Em todos os casos a montagem inclui validação térmica sob carga real, fonte com folga para transiente e o ambiente de CUDA configurado, para que a máquina chegue rodando o seu pipeline e não um instalador.

Perguntas frequentes

Preciso de placa de vídeo dedicada para estudar ciência de dados?

Para aprender pandas, SQL, estatística e scikit-learn, um bom processador e RAM suficiente resolvem. A GPU passa a fazer diferença com gradient boosting em base grande, embeddings ou deep learning, e aí uma placa de 8 a 12 GB já abre a maior parte dos exercícios.

Quanta VRAM é suficiente para data science?

Para trabalho tabular com cuDF e boosting, a faixa de 12 a 24 GB atende a maioria dos casos, e 24 GB é o patamar prático para ajustar modelos de linguagem com LoRA e quantização. Treino completo e visão em alta resolução pedem 48 GB ou mais.

GPU acelera o pandas?

Não diretamente, porque o pandas roda majoritariamente em uma única thread de CPU. O que acelera é o cuDF do RAPIDS, com um modo que executa o mesmo código em GPU e volta para a CPU quando a operação não tem versão acelerada.

Placa de vídeo AMD serve para ciência de dados?

Serve para deep learning em PyTorch e JAX nas GPUs listadas na matriz de compatibilidade do ROCm, da AMD. O ponto fraco é o ecossistema de dataframe e de algoritmos clássicos acelerados, dominado por CUDA, então para trabalho tabular o caminho NVIDIA tem bem menos atrito.

Vale mais a pena investir em GPU ou em mais RAM?

Depende de onde o processo trava. Se a máquina pagina em disco ou você reduz amostra para carregar a base, RAM vem primeiro. Se a base já cabe e o tempo se concentra em treino ou inferência, a GPU rende mais.

Se você já sabe onde o seu pipeline trava e quer traduzir isso em uma configuração fechada, a equipe da Zenion faz esse dimensionamento a partir das bibliotecas e do volume de dado que você usa de verdade. Vale abrir a conversa com o pipeline em mãos, e não com uma lista de placas.