Como usar GPU na nuvem como sua máquina de desenvolvimento

Seu notebook tem 16 GB de RAM e uma GPU que não roda o modelo que você precisa testar. Instalar CUDA na máquina local quebrou o driver duas vezes. E o time inteiro tem ambiente diferente, então "na minha máquina funciona" virou piada interna.

A saída é parar de tratar a GPU na nuvem como um lugar onde você manda um job e passar a tratá-la como a sua máquina de desenvolvimento: você abre o VS Code e ele está lá, com o terminal, o depurador, as extensões e a placa de vídeo. O código fica no servidor; a interface fica no seu notebook.

Quando isso vale a pena

• O modelo não cabe no seu hardware. Qualquer coisa acima de 8B em precisão decente já sufoca uma GPU de notebook.
• Você precisa de CUDA sem instalar CUDA. A instância vem com driver e toolkit prontos. Se você quebrar, apaga e sobe outra em minutos.
• O time precisa do mesmo ambiente. Um script de bootstrap versionado no repositório reproduz a máquina para todo mundo.
• Treino ou processamento que leva horas. Fecha o notebook, vai almoçar, o processo continua — coisa que ssh puro não te dá sozinho (veja a seção do tmux).
• Você trabalha de lugares diferentes. O ambiente não está no equipamento; está no servidor.

Quando não vale: desenvolvimento que não usa GPU nenhuma. Para isso, uma instância de CPU custa uma fração do preço e resolve igual.

Passo 1: a chave SSH

Se você ainda não tem uma, gere. E gere uma específica para isto — chave reaproveitada de outro serviço é dor de cabeça no dia da rotação.

ssh-keygen -t ed25519 -C "dev-gpu" -f ~/.ssh/gpu_dev
cat ~/.ssh/gpu_dev.pub          # esta é a que você cola no painel

No painel, em Chaves SSH, cole a chave pública (a que termina em .pub). Ela é injetada na máquina no momento da criação — chave adicionada depois não entra numa instância que já existe.

Passo 2: subir a instância certa

Para desenvolvimento, o critério é diferente de treino: você quer VRAM suficiente e custo baixo, porque a máquina vai passar boa parte do tempo com você lendo código, não computando.

Comece pequeno. A troca de instância leva minutos e você não perde nada se o código estiver no Git — que é justamente o ponto da próxima seção.

Passo 3: conectar

Assim que a instância fica pronta, o painel mostra o usuário, o IP e a porta. Três detalhes que economizam sua manhã:

• O usuário varia. Em algumas máquinas é root, em outras ubuntu. Não chute — o painel mostra o que aquela máquina reportou.
• A porta nem sempre é 22. Copie a que está no card.
• Espere o SSH subir. A máquina aparece como pronta alguns segundos antes de o serviço aceitar conexão. Se der "connection refused", tente de novo em 30 segundos.

ssh -i ~/.ssh/gpu_dev -p PORTA USUARIO@IP

Funcionou? Grave no ~/.ssh/config e nunca mais digite isso:

Host gpu
    HostName 203.0.113.45
    User root
    Port 40123
    IdentityFile ~/.ssh/gpu_dev
    ServerAliveInterval 30
    ServerAliveCountMax 6
    StrictHostKeyChecking accept-new

Agora ssh gpu basta. O ServerAliveInterval não é enfeite: sem ele, a conexão cai sozinha quando você fica alguns minutos sem digitar, e o VS Code passa a vida reconectando.

Passo 4: VS Code de verdade, rodando lá

1. Instale a extensão Remote - SSH (Microsoft).
2. F1 → Remote-SSH: Connect to Host → gpu.
3. A primeira conexão instala o servidor do VS Code na máquina remota. Leva um minuto.
4. Abra a pasta do projeto. Terminal, depurador, extensões e Copilot passam a rodar no servidor.

É a diferença entre editar arquivo remoto e ter um ambiente remoto: python train.py no terminal integrado roda na GPU, e o depurador para no breakpoint com a placa carregada.

Confirme que a GPU está mesmo lá

nvidia-smi
python -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"

Se nvidia-smi responde mas o PyTorch diz False, é quase sempre versão de CUDA incompatível com a do PyTorch instalado — reinstale o PyTorch para a versão de CUDA que a máquina reporta, não o contrário.

Passo 5: as portas — Jupyter, TensorBoard, sua API

Não abra porta no firewall para ver um Jupyter. Use túnel SSH: o serviço fica ouvindo só em localhost na máquina remota, e aparece no seu navegador como se fosse local.

# no seu notebook
ssh -N -L 8888:localhost:8888 -L 6006:localhost:6006 -L 8000:localhost:8000 gpu

Agora localhost:8888 é o Jupyter remoto, 6006 é o TensorBoard e 8000 é a API que você está escrevendo. Nada disso está exposto na internet.

No VS Code é ainda mais simples: quando um processo abre uma porta no servidor, ele detecta e encaminha sozinho — a aba Ports mostra o que está publicado.

Passo 6: sobreviver à desconexão

Este é o erro que todo mundo comete uma vez. Você inicia um treino de 6 horas pelo terminal, o Wi-Fi oscila, a sessão SSH morre — e o processo morre junto. Seis horas perdidas.

Rode qualquer coisa longa dentro do tmux:

tmux new -s treino        # cria a sessão
python train.py           # roda dentro dela
# Ctrl+B, depois D        → desanexa (o processo continua)

tmux attach -t treino     # volta, de qualquer lugar
tmux ls                   # lista o que está rodando

Com o tmux, fechar o notebook é irrelevante. A sessão vive na máquina remota até ela ser desligada.

Passo 7: não perder o trabalho

Um fluxo que funciona bem:

• Código: Git, sempre. Configure a sua chave de deploy ou token no primeiro bootstrap.
• Dados e pesos: baixe por script, não por upload manual. Se o script reconstrói, a máquina é reproduzível.
• Resultados: rsync para a sua máquina ao fim de cada rodada.

# trazer resultados para o notebook
rsync -avz --progress gpu:/workspace/saidas/ ./saidas/

# levar um dataset local para o servidor
rsync -avz --progress ./dados/ gpu:/workspace/dados/

Bootstrap: a máquina montada em um comando

Guarde este arquivo no repositório. Ele é o que torna o ambiente reproduzível para o time inteiro:

#!/usr/bin/env bash
# bootstrap.sh — roda uma vez em cada instância nova
set -euo pipefail

apt-get update -qq && apt-get install -y -qq git tmux htop rsync build-essential

git config --global user.name  "Seu Nome"
git config --global user.email "voce@empresa.com"

python -m venv /workspace/.venv
source /workspace/.venv/bin/activate
pip install -U pip wheel
pip install -r /workspace/projeto/requirements.txt

cat >> ~/.bashrc <<'EOF'
source /workspace/.venv/bin/activate
cd /workspace/projeto
alias gpu='watch -n1 nvidia-smi'
EOF

echo "pronto. 'tmux new -s dev' para começar."

Instância nova: git clone, bash bootstrap.sh, e você está trabalhando em três minutos.

Passo 8: a disciplina de custo

Aqui mora a diferença entre R$ 200 e R$ 1.700 por mês. A cobrança é por hora ligada, não por trabalho feito — GPU parada aquecendo o datacenter custa igual a GPU treinando.

Três regras que resolvem:

• Desligue ao sair. Se o bootstrap está versionado e o código está no Git, subir de novo é barato em tempo e você economiza 70% da conta.
• Máquina parada também custa. Instância desligada continua ocupando disco, e o disco é cobrado. Se você não vai voltar em alguns dias, apague em vez de só parar.
• Nem toda instância hiberna. Parar e voltar depois é um recurso que depende da máquina; o painel só mostra o botão onde ele realmente existe. Onde não existe, o fluxo é apagar e recriar — mais um motivo para o bootstrap em script.

Dois ambientes que valem montar

Desenvolvimento com LLM local

Se o que você está escrevendo consome um LLM, tem duas opções e elas não competem:

• Durante o desenvolvimento: use a API por token. Custa frações de centavo por chamada, não ocupa VRAM e você não gasta tempo servindo modelo. O gpub-fast sai por R$ 0,49 por milhão de tokens de entrada.
• Quando precisa do modelo local: suba o vLLM na mesma máquina, aponte o cliente para localhost:8000/v1 e siga. Como a interface é compatível com a da OpenAI nos dois casos, muda uma variável de ambiente.

BASE_URL = os.getenv("LLM_BASE_URL", "https://gpubrasil.com.br/v1")
API_KEY  = os.getenv("LLM_API_KEY",  os.getenv("GPUBRASIL_API_KEY"))
cliente  = OpenAI(base_url=BASE_URL, api_key=API_KEY)

# local:  LLM_BASE_URL=http://localhost:8000/v1 LLM_API_KEY=nao-importa python app.py
# nuvem:  python app.py

Contêineres, se o seu projeto usa

Em instância de máquina virtual você tem Docker e pode usar --gpus all normalmente. Em instância de contêiner, você já está num contêiner — nesse caso instale as dependências direto, sem tentar Docker dentro de Docker. O tipo aparece no card da instância.

Problemas comuns e a causa real

Conclusão

Desenvolvimento remoto com GPU deixou de ser gambiarra: com Remote-SSH, tmux e um bootstrap versionado, o ambiente é melhor que o local — mais potente, reproduzível e descartável quando quebra.

O que faz a diferença entre economia e desperdício não é técnico, é hábito: código no Git, ambiente em script, máquina desligada quando você não está usando. Com isso, um ambiente com GPU de verdade custa menos que um almoço por dia de trabalho.

Continue: um copiloto de código para o time · JupyterLab em 1 clique · servir o seu modelo com vLLM