Última revisão: junho de 2026
Uma referência rápida dos padrões arquiteturais que o exame NCA-ADS avalia. Leia de cima a baixo ou pule para uma seção.
Pipeline pandas existente em um CSV de 40 GB é muito lento na CPU.
Substitua pandas por cuDF; a maioria das chamadas de leitura/filtro/agrupamento/junção mantém a mesma API e executa na GPU.
Por quê: cuDF espelha a API pandas por design, então a migração é principalmente uma mudança de importação em vez de uma reescrita.
A equipe quer acelerações de GPU sem tocar no código pandas existente.
Carregue o acelerador cudf.pandas (%load_ext cudf.pandas ou python -m cudf.pandas); ele executa operações na GPU e retorna à CPU automaticamente.
Por quê: A aceleração sem alteração de código com fallback transparente para CPU mantém as operações não suportadas funcionando.
Precisa da carga columnar mais rápida de um grande conjunto de dados analíticos na GPU.
Armazene como Parquet e leia com cudf.read_parquet; o corte de colunas e o pushdown de predicados minimizam a transferência para o dispositivo.
Por quê: Parquet columnar mapeia de forma limpa para cuDF baseado em Arrow e lê muito mais rápido do que CSV orientado a linhas.
cuDF é mais lento que pandas em um arquivo de 50 MB.
Mantenha dados pequenos na CPU; a transferência host-para-dispositivo e a sobrecarga de lançamento de kernel dominam abaixo de ~1-2 GB.
Por quê: A aceleração da GPU compensa em escala; para dados minúsculos, o custo de cópia excede o ganho de computação.
Agregue bilhões de linhas por chave com múltiplas estatísticas.
Use df.groupby(key).agg({...}) em cuDF; as agregações são executadas como kernels GPU paralelos.
Limpar e normalizar uma coluna de texto de alta cardinalidade em escala de GPU.
Use o acessador .str do cuDF (lower, strip, replace, contains, split); as operações de string são aceleradas por GPU via libcudf.
Por quê: cuDF possui uma camada de string dedicada para GPU, então a limpeza de texto não precisa retornar à CPU.
Junte dois grandes DataFrames de dispositivo em uma chave compartilhada.
Use cudf.merge / df.merge com a chave de junção; as junções de hash são executadas na GPU.
Por quê: Ambos os frames já devem estar no dispositivo para evitar uma viagem de ida e volta; misturar pandas e cuDF força uma cópia no host.
O conjunto de dados possui valores ausentes que interrompem o treinamento downstream do cuML.
Use cuDF fillna/dropna e casts de dtype explícitos antes do fit; cuML espera arrays numéricos limpos no dispositivo.
Dtypes mistos/de objeto causam erros ou inchaço de memória em cuDF.
Converta para dtypes numéricos ou categóricos compactos (int32/float32, category) precocemente para diminuir o consumo de memória da GPU.
Por quê: O downcasting reduz a pressão da memória do dispositivo, o gargalo mais comum em uma única GPU.
Precisa de codificação de rótulo/one-hot para recursos categóricos antes do treinamento.
Use o dtype categórico cuDF com .cat.codes ou codificadores de pré-processamento cuML para manter os dados no dispositivo.
Precisa de matemática de array numérica bruta não exposta pela API do DataFrame cuDF.
Converta via df.values ou to_cupy() e opere com CuPy (arrays GPU compatíveis com NumPy), então traga os resultados de volta.
Por quê: cuDF e CuPy compartilham memória do dispositivo através da __cuda_array_interface__, então a conversão é de cópia zero.
Portar um script de treinamento scikit-learn para GPU.
Use estimadores cuML (LinearRegression, LogisticRegression, KMeans, RandomForest); fit/predict espelham a API sklearn.
Por quê: cuML visa compatibilidade com a API sklearn, então trocar o import geralmente é suficiente.
Árvores de aumento de gradiente em um grande conjunto de dados tabular, treinamento muito lento na CPU.
Treine XGBoost com device="cuda" (tree_method="hist"); ele consome dados cuDF/CuPy diretamente.
Por quê: O método de histograma nativo da GPU do XGBoost oferece grandes acelerações e se integra estreitamente com RAPIDS.
Clusterizar milhões de pontos rapidamente para segmentação.
Use cuML KMeans (ou DBSCAN para baseado em densidade); ambos rodam totalmente na GPU.
Reduzir dados de alta dimensão para 2D para visualização em escala.
Use cuML UMAP ou t-SNE; implementações de GPU lidam com conjuntos de dados que são impraticáveis na CPU.
Por quê: UMAP/t-SNE são computacionalmente pesados; as versões de GPU tornam as embeddings em escala interativa viáveis.
Precisa de um classificador de ensemble preciso com importâncias de features.
Use cuML RandomForestClassifier; treine em arrays de dispositivo e exporte para FIL para inferência rápida.
Implementar um modelo de árvore para pontuação em lote de alta taxa de transferência.
Carregue o modelo na Forest Inference Library (FIL) para executar previsões aceleradas por GPU em grandes lotes.
Por quê: FIL acelera a inferência para florestas XGBoost/LightGBM/cuML muito além da pontuação por árvore da CPU.
Um algoritmo de que você precisa não tem implementação cuML GPU.
Confirme a cobertura na documentação do cuML; se ausente, mantenha essa etapa no scikit-learn e acelere o restante.
Por quê: Nem todo estimador é suportado por GPU - conheça o conjunto suportado em vez de assumir paridade total.
Evite cópias silenciosas do host durante o treinamento cuML.
Passe dados de dispositivo cuDF/CuPy diretamente para fit(); a mistura de NumPy/pandas dispara uma transferência host-para-dispositivo.
O conjunto de dados é maior do que a memória de uma única GPU.
Use dask-cuDF para particionar os dados em múltiplas GPUs/nós e processar as partições em paralelo.
Por quê: Dask lida com distribuição out-of-core e multi-GPU que um único frame cuDF não consegue.
Quero usar todas as GPUs em uma máquina multi-GPU.
Inicie um LocalCUDACluster a partir de dask-cuda e conecte um Client; um worker é fixado por GPU.
Por quê: LocalCUDACluster conecta cada worker Dask a uma GPU distinta para que o agendador possa balancear o trabalho.
Construindo um pipeline Dask de várias etapas que recalcula com muita frequência.
Componha de forma "lazy" e chame .compute() uma vez no final; use persist() para armazenar intermediários reutilizados na memória da GPU.
Por quê: Dask é "lazy" - acionar o compute muito cedo ou repetidamente refaz o trabalho.
Partições enviesadas fazem com que alguns workers da GPU fiquem atrasados.
Reparticione para tamanhos balanceados e alinhe as chaves de partição com junções/agrupamentos downstream.
Por quê: Partições desiguais criam gargalos que atrasam todo o trabalho.
Manter um fluxo de trabalho ETL → treinar → pontuar totalmente na GPU.
Encadeie a preparação cuDF em cuML/XGBoost sem converter para pandas no meio, mantendo os dados residentes no dispositivo.
Por quê: Cada viagem de ida e volta para a CPU adiciona custo de transferência; permanecer no dispositivo preserva a aceleração de ponta a ponta.
Precisa de um fluxo de trabalho que seja executado de forma idêntica para revisão.
Fixe as versões RAPIDS/CUDA, defina as seeds aleatórias e parametrize as entradas para que o pipeline seja determinístico e reexecutável.
Calcular estatísticas de resumo em uma tabela de bilhões de linhas.
Use cuDF describe/mean/std/quantile e corr; as agregações são executadas como kernels da GPU.
Gráfico de dispersão de 100M pontos sobrepostos e ilegível.
Renderize com Datashader, que rasteriza os pontos na GPU em uma imagem de densidade em vez de desenhar cada marcador.
Por quê: Datashader agrega em pixels, então o custo do plot é limitado pelo tamanho da imagem, não pela contagem de pontos.
Precisa de um painel interativo de filtro cruzado sobre um enorme DataFrame de GPU.
Use cuxfilter para vincular gráficos com filtragem cruzada acelerada por GPU em dados cuDF.
Por quê: cuxfilter mantém os dados no dispositivo para que a seleção/filtragem permaneça interativa em escala.
Visualizar a distribuição de uma grande coluna numérica.
Faça o binning com cuDF/CuPy na GPU, então plote o pequeno resultado agregado com Plotly ou Matplotlib.
Por quê: Agregue primeiro na GPU; apenas o pequeno resumo precisa chegar à biblioteca de plotagem.
Avaliar relações de features antes da modelagem.
Calcule df.corr() em cuDF na GPU, então renderize a pequena matriz como um heatmap.
Quer gráficos interativos declarativos suportados por dados de GPU.
Emparelhe HoloViews/hvPlot com Datashader e cuDF para visualizações interativas de alto volume.
Justificar a aceleração da GPU para uma carga de trabalho de dados.
Use GPUs para operações massivamente paralelas a dados, limitadas pelo throughput em grandes conjuntos de dados; mantenha trabalhos pequenos, ramificados ou sensíveis à latência na CPU.
Por quê: GPUs vencem no paralelismo SIMT em muitos elementos; perdem em tarefas pequenas ou com muita lógica de controle.
Explicar como RAPIDS compartilha dados entre cuDF, CuPy e bibliotecas de ML sem cópias.
RAPIDS é construído sobre o formato de memória columnar Apache Arrow, permitindo intercâmbio de cópia zero entre bibliotecas de GPU.
Por quê: Um layout columnar compartilhado no dispositivo permite que os componentes passem dados sem serialização.
Um pipeline é acelerado por GPU, mas mal é mais rápido.
Faça o perfil do movimento de dados; cópias repetidas host↔dispositivo geralmente dominam. Mantenha os dados residentes na GPU entre as etapas.
Por quê: A transferência PCIe é o imposto oculto - minimizar cópias geralmente é o maior ganho individual.
Entender o que executa trabalho na GPU.
CUDA lança kernels em milhares de threads agrupadas em blocos/grades sob o modelo SIMT; as bibliotecas RAPIDS os encapsulam para que você raramente escreva kernels por conta própria.
A carga de trabalho apresenta erros de falta de memória em uma única GPU.
Reduza os tamanhos dos dtypes, processe em chunks ou expanda com Dask; a VRAM da GPU é muito menor do que a RAM do host.
Por quê: A memória do dispositivo é a primeira restrição na ciência de dados com GPU - projete em torno dela.
Mapear uma tarefa de ciência de dados da CPU para a biblioteca RAPIDS correta.
cuDF para DataFrames, cuML para ML, cuGraph para grafos, cuSpatial para geoespacial, Dask para escalonamento horizontal.
Precisa comparar muitas execuções de treinamento e suas métricas.
Registre parâmetros, métricas e artefatos no MLflow Tracking; consulte e compare execuções da UI.
Por quê: O rastreamento centralizado de experimentos torna os resultados reprodutíveis e comparáveis entre as execuções.
Quer painéis ao vivo e logs de experimentos compartilhados pela equipe.
Use Weights & Biases (wandb.init/log) para transmitir métricas e compartilhar painéis visuais de experimentos.
Rastrear qual modelo treinado está em staging vs. produção.
Registre versões no MLflow Model Registry e promova através de estágios com metadados.
Por quê: Um registro oferece uma única fonte de verdade para a linhagem e promoção do modelo.
Um modelo não pode ser reproduzido meses depois.
Controle as versões de dados, código, ambiente e seeds juntos; registre a configuração completa com cada execução.
Por quê: A reprodutibilidade exige a captura de todos os quatro - apenas o código não é suficiente.
Mover um modelo treinado em direção à produção.
Empacote o modelo e as dependências (por exemplo, imagem de contêiner), então exponha inferência em lote ou REST; use FIL para pontuação rápida de árvores na GPU.
Classificar nós por influência em um grafo grande.
Construa um cuGraph Graph a partir de uma lista de arestas e execute cugraph.pagerank na GPU.
Por quê: cuGraph executa PageRank, BFS e centralidade em grafos grandes demais para bibliotecas de CPU.
Encontrar clusters/comunidades em um conjunto de dados de rede.
Use componentes conectados cuGraph ou Louvain; ingira arestas de um cuDF DataFrame.
Os dados são de alta dimensão e principalmente zeros.
Use formatos esparsos de GPU (CSR/COO via CuPy sparse) em vez de arrays densos para ajustar a memória e acelerar a computação.
Por quê: O armazenamento esparso evita desperdiçar VRAM e kernels em entradas zero.
Configurar um ambiente RAPIDS funcional.
Instale via conda, pip ou Docker usando o RAPIDS Release Selector para corresponder às suas versões de CUDA/Python.
Por quê: O seletor fixa builds de pacotes compatíveis, a fonte mais comum de falhas de instalação.
A importação do RAPIDS falha ou não vê nenhuma GPU após a instalação.
Verifique se as versões do driver NVIDIA e do kit de ferramentas CUDA satisfazem os requisitos de build do RAPIDS; execute nvidia-smi para confirmar a GPU.
Por quê: A incompatibilidade de Driver/CUDA é a principal causa de erros de "nenhum dispositivo CUDA".
Quer um ambiente RAPIDS reproduzível e pré-configurado.
Puxe o contêiner RAPIDS do NVIDIA NGC; ele vem com CUDA, drivers e bibliotecas compatíveis.
Por quê: As imagens NGC removem a adivinhação de correspondência de versão e padronizam o ambiente entre as máquinas.