cuML da NVIDIA: acelere machine learning com GPU sem abandonar o scikit-learn

Por que a GPU virou o gargalo invisível do seu ML em 2026

Se você treina modelos de aprendizado de máquina com scikit-learn, provavelmente já viveu a cena: o notebook roda PCA em 40 segundos, K-Means leva minutos, e a Random Forest com 100 árvores parece não terminar nunca. Enquanto isso, a GPU do seu computador — ou do Google Colab — fica ociosa, esperando o processador resolver tudo sozinho.

O que mudou é que a NVIDIA amadureceu a resposta para esse problema: o cuML, o framework de machine learning acelerado por GPU do ecossistema RAPIDS. Há poucos anos, usar GPU para ML exigia reescrever código em CUDA ou abandonar o scikit-learn por APIs totalmente diferentes. Hoje, o cuml.accel promete acelerar scripts de scikit-learn existentes sem mudar uma linha de código — e a API nativa do cuML espelha a do scikit-learn para quem quer ir além.

Este guia percorre um fluxo de trabalho completo de ponta a ponta: aceleração transparente, interoperação entre CuPy/cuDF/cuML, benchmarks honestos de CPU contra GPU, aprendizado de manifold, inferência de florestas em alta vazão, SHAP na GPU e serialização de modelos. Tudo com o código que você pode copiar e adaptar.

Prós e contras

✅ O que você ganha

• Aceleração sem reescrever código: o cuml.accel intercepta chamadas do scikit-learn e as executa na GPU, mantendo a API que você já conhece.
• API familiar: os estimadores do cuML (PCA, KMeans, LogisticRegression, RandomForest) seguem o mesmo padrão fit/predict do scikit-learn.
• Zero-copy entre bibliotecas: dados fluem entre CuPy, cuDF e cuML sem ida e volta para a CPU (host), preservando o ganho de velocidade.
• SHAP e explicabilidade na GPU: o PermutationExplainer calcula valores SHAP acelerados, validados analiticamente.
• Inferência em alta vazão: a Forest Inference Library (FIL/nvForest) serve florestas treinadas com vazão de GPU sem retreinar.

⚠️ O que você NÃO ganha

• Ganho automático em datasets pequenos: abaixo de ~10 mil linhas, a transferência PCIe e o overhead de kernel geralmente dominam, e a CPU vence. Você precisa medir o seu caso.
• Resultados numéricos idênticos: o cuML espelha a API do scikit-learn, não a matemática exata — solvers diferentes, padrão float32 e reduções não determinísticas geram pequenas diferenças.
• Multi-GPU “de graça”: para várias GPUs ou múltiplos nós, é preciso trocar cuml.X por cuml.dask.X com um LocalCUDACluster.

Requisitos

Passo a passo

1. Configure o ambiente e instale o cuML

Primeiro, confirme que a GPU está visível e instale o cuML. No Colab, mude o runtime para GPU. O truque do pinning evita incompatibilidade de versão com o cuDF já presente:

import subprocess, sys
# Confirma a GPU
print(subprocess.run(["nvidia-smi", "--query-gpu=name,memory.total",
                      "--format=csv"], capture_output=True, text=True).stdout)

# Instala casando a linha do cuDF se ele já existir
pin = ""
try:
    import cudf
    pin = f"=={'.'.join(cudf.__version__.split('+')[0].split('.')[:2])}.*"
except Exception:
    pass
cmd = [sys.executable, "-m", "pip", "install", "-q",
       "--extra-index-url=https://pypi.nvidia.com", f"cuml-cu12{pin}"]
subprocess.run(cmd)
import cuml, cupy
print("cuml", cuml.__version__, "| cupy", cupy.__version__)

Por quê: o cuML precisa de uma linha compatível com o cuDF/cuPy já instalados no ambiente, senão você enfrenta erros de versão difíceis de diagnosticar. O --extra-index-url aponta para o repositório de pacotes da NVIDIA.

2. Acelere scikit-learn existente com cuml.accel

O caminho mais rápido para ganho é o cuml.accel: ele roda um script de scikit-learn sem modificação e troca as chamadas suportadas para a GPU. O perfil final mostra exatamente o que rodou onde:

# Script comum de scikit-learn (SEM nenhuma alteração)
# faz_blobs.py -> PCA, KMeans, NearestNeighbors, Ridge
python3 faz_blobs.py                    # CPU (stock sklearn)

# Mesmo script, acelerado:
python3 -m cuml.accel --profile faz_blobs.py   # GPU, com tabela de perfil

Por quê: o cuml.accel permite medir o ganho real antes de comprometer qualquer código. O perfil também revela fallbacks: operações sem equivalente na GPU (por exemplo, Ridge(positive=True) em certas versões) voltam silenciosamente para a CPU.

3. Use a API nativa e o zero-copy entre CuPy, cuDF e cuML

Para pipelines 100% na GPU, trabalhe com a API nativa. O ponto central é controlar onde os dados vivem:

from cuml.decomposition import PCA
import cuml

pca = PCA(n_components=3).fit(X)          # X é um CuPy array
print(type(pca.transform(X)))             # -> cuPy.ndarray (fica na GPU)

with cuml.using_output_type("numpy"):     # só dentro do contexto
    print(type(pca.transform(X)))         # -> numpy.ndarray (copia p/ CPU)

# Regra de ouro: mantenha output_type como CuPy/cuDF dentro do pipeline.
# Converter para NumPy a cada passo força cópia device->host e some o ganho.

Por quê: cada conversão de CuPy para NumPy é uma cópia da GPU para a CPU. Em um pipeline com várias etapas, essas cópias podem anular todo o speedup — o gargalo vira o barramento, não a computação.

4. Meça CPU vs GPU com sincronização correta

Um benchmark honesto exige sincronizar a GPU antes de parar o cronômetro — senão você mede o tempo de “agendar” o trabalho, não de executá-lo:

import cupy as cp, time
class Timer:
    def __enter__(self):
        cp.cuda.runtime.deviceSynchronize()  # limpa a fila antes
        self.t0 = time.perf_counter()
        return self
    def __exit__(self, *exc):
        cp.cuda.runtime.deviceSynchronize()  # espera a GPU terminar
        self.dt = time.perf_counter() - self.t0
        return False

Por quê: operações de GPU são assíncronas por padrão. Sem o deviceSynchronize(), o cronômetro registra valores enganosamente baixos e o benchmark vira ficção. Compare PCA, K-Means, vizinhos mais próximos, regressão logística, Random Forest e DBSCAN nas duas versões.

5. Pipeline de manifold e clustering: UMAP → HDBSCAN

Para dados não supervisionados, reduza a dimensionalidade com UMAP (avaliado pela métrica de trustworthiness) e então agrupe com HDBSCAN na GPU:

from cuml.manifold import UMAP
from cuml.metrics import trustworthiness
from cuml.cluster import HDBSCAN

emb = UMAP(n_neighbors=15, min_dist=0.1, random_state=42).fit_transform(X)
tw = trustworthiness(X[:5000], emb[:5000], n_neighbors=10)  # qualidade

hdb = HDBSCAN(min_cluster_size=50, min_samples=10).fit(emb)
labels = hdb.labels_   # -1 marca pontos de ruído (outliers)

Por quê: a trustworthiness diz se o embedding preservou a vizinhança local — é como você escolhe entre configurações de UMAP em vez de “olhar o gráfico e achar bonito”. O HDBSCAN separa automaticamente clusters do ruído, sem precisar chutar o número de grupos.

6. Acelere a inferência de florestas com FIL/nvForest

Treinar no scikit-learn e servir na GPU é um padrão poderoso: o mesmo artefato, com vazão de GPU e sem retreino:

from cuml.fil import ForestInference
# sk_model é uma RandomForest treinada no scikit-learn (CPU)
fil = ForestInference.load_from_sklearn(sk_model, output_class=True)
fil.optimize(batch_size=X_gpu.shape[0])   # ajusta layout ao batch
probs = fil.predict_proba(X_gpu)          # vazão de GPU

Por quê: a FIL é a peça que importa em produção: você já tem um modelo treinado e validado; a única necessidade é servir previsões rápido. Em builds novos, a NVIDIA aponta para a biblioteca independente nvForest.

7. SHAP na GPU, validado analiticamente

Explicar o modelo também pode ser acelerado:

from cuml.explainer import PermutationExplainer
expl = PermutationExplainer(model=model.predict, data=background, random_state=42)
shap_values = expl.shap_values(to_explain)
# Para um modelo linear, compare com a solução analítica:
#   shap = (x - média(background)) * coef

Por quê: o SHAP por permutação é baseado em amostragem, então um resíduo pequeno contra a solução analítica é esperado — o que importa é o padrão bater. Isso dá confiança de que a atribuição está correta antes de confiar nela para decisões.

8. Busca de hiperparâmetros com scikit-learn na GPU

Estimadores do cuML funcionam dentro dos meta-estimadores do scikit-learn:

from sklearn.model_selection import RandomizedSearchCV
from cuml.ensemble import RandomForestClassifier as cuRF

search = RandomizedSearchCV(cuRF(random_state=42), param_distributions={
    "n_estimators": [50, 100, 200], "max_depth": [8, 12, 16]},
    n_iter=8, cv=3, random_state=42)
search.fit(X, y)   # cada fit leva segundos, não minutos

Por quê: como cada ajuste na GPU leva segundos em vez de minutos, você pode se dar ao luxo de explorar um espaço de busca real em vez de chutar um único hiperparâmetro.

9. Serialize e leve o modelo da GPU para a CPU

O cuML usa cloudpickle internamente, então modelos treinados sob cuml.accel podem ser carregados e usados pelo scikit-learn comum em máquinas sem GPU:

import pickle
pickle.dump(model, open("cuml_rf.pkl", "wb"))
restored = pickle.load(open("cuml_rf.pkl", "rb"))
# ⚠️ Segurança: nunca faça unpickle de modelo de fonte não confiável

Por quê: essa portabilidade GPU→CPU é o que torna o cuML viável em produção: treine na GPU, sirva onde for necessário. A ressalva de segurança é real — arquivos .pkl executam código ao carregar.

Tabela comparativa: CPU vs GPU vs alternativas

Casos de uso reais

• Fraude e risco em tempo real: servir uma Random Forest de risco com FIL na GPU mantém a latência baixa em alto volume de transações.
• Segmentação de clientes: UMAP + HDBSCAN em milhões de registros de comportamento, em vez de K-Means lento na CPU.
• Churn e explicação: treinar regressão logística e gerar SHAP na GPU para justificar cada previsão ao time de negócio.
• Busca de hiperparâmetros: varrer centenas de combinações de Random Forest em minutos, não em horas.
• Pesquisa científica: PCA e vizinhos mais próximos em datasets de genômica ou visão que não cabem confortavelmente na RAM da CPU.
• Prova de conceito rápida: validar uma hipótese de ML em Colab com GPU sem escrever CUDA nem migrar para um framework de deep learning.

Comparação de custo

Troubleshooting: erros comuns

• ❌ “No NVIDIA GPU found” → a GPU não está visível. No Colab, troque para Runtime → Change runtime type → GPU. No Linux local, verifique com nvidia-smi.
• ❌ Erro de versão ao importar cuml (cuDF incompatível) → instale o cuML casado com a linha do cuDF já presente (cuml-cu12==X.Y.*), não a versão mais nova isolada.
• ❌ Benchmark mostra GPU “mais lenta” em tudo → provavelmente seu dataset é pequeno demais; abaixo de ~10 mil linhas o overhead de transferência domina. Aumente os dados ou assuma que a CPU é a escolha certa.
• ❌ Speedups irreais (100x+) → faltou deviceSynchronize() antes de parar o cronômetro; você mediu o agendamento, não a execução.
• ❌ Diferenças numéricas pequenas vs scikit-learn → esperado: solvers diferentes, padrão float32 e reduções não determinísticas. Não é bug, mas valide a acurácia no seu caso.
• ❌ cuml.fil indisponível no build → em stacks novos, use a biblioteca standalone nvForest no lugar da ForestInference.
• ❌ Memória estourando ao converter CuPy→NumPy → você está copiando da GPU para a CPU a cada etapa; mantenha output_type como CuPy/cuDF dentro do pipeline.

FAQ

• Preciso saber CUDA para usar cuML? Não. A API espelha o scikit-learn e o cuml.accel acelera código existente sem mudanças.
• cuML substitui o scikit-learn? Não totalmente. Ele cobre os algoritmos clássicos de ML; para o resto, convivem lado a lado no mesmo script.
• Funciona em AMD ou Apple Silicon? Não. O cuML exige GPU NVIDIA com driver compatível.
• Vou ganhar velocidade em qualquer dataset? Não. Em dados pequenos a CPU vence. O ganho aparece em datasets médios e grandes — meça o seu.
• Posso treinar na GPU e servir na CPU? Sim. O pickle/cloudpickle permite carregar o modelo em máquina sem GPU.
• Qual a diferença entre cuML e RAPIDS? O RAPIDS é o ecossistema completo (cuDF, cuGraph, cuML); o cuML é o componente de machine learning.

O que esperar daqui para frente

O movimento é claro: a NVIDIA está tornando a aceleração por GPU uma camada invisível — o cuml.accel é a ponta desse processo, com a nvForest assumindo a inferência de árvores e o dask-cuda cobrindo múltiplas GPUs. Para quem trabalha com machine learning clássico no Brasil, a implicação prática é que o custo de experimentar com GPU despencou: dá para começar no Colab gratuito e escalar quando o dataset pedir, sem reescrever a lógica do zero. Quem dominar essa ponte entre scikit-learn e GPU vai se mover mais rápido que quem insistir só na CPU.