VS Code no cluster

1. Primeiro: teste no seu computador

O cluster é para rodar o que já funciona, não para escrever e depurar o código do zero. O caminho é:

1. Desenvolva e teste no seu computador, com uma amostra pequena dos dados e poucas iterações, até o script rodar do começo ao fim sem erro.
2. Copie para o cluster (rsync / scp, ver guia) e rode de verdade com sbatch.
3. Use o VS Code no cluster (labic-job) só para o que só dá para ver lá: um erro que aparece só na GPU L40S, um caminho de dados do cluster, um ajuste rápido antes de submeter.

Uma sessão de VS Code no cluster ocupa recursos de um nó o tempo todo em que está aberta, inclusive enquanto você só lê ou digita. Quanto mais você resolve localmente, mais máquina sobra para os jobs de todo mundo, incluindo os seus.

2. Por que não no bastion

O bastion é a porta de entrada: uma máquina pequena, compartilhada por todos, feita para copiar arquivos e submeter jobs. Por isso:

• Ele não executa programas que estão no seu home (nem em /tmp). O servidor do VS Code, um conda instalado no home ou um binário compilado por você recebem Permission denied no bastion. No nó de computação, dentro de um job, tudo isso funciona normalmente.
• Continuam funcionando no bastion: ssh, scp/rsync, editores de terminal (nano, vim), python3 script.py com o Python do sistema, e todos os comandos do Slurm (sbatch, srun, squeue…).
• Uma sessão que esgota a memória é encerrada automaticamente. Cada usuário tem cerca de 1 GB no bastion; uma sessão que fica presa no limite é encerrada em menos de um minuto.

⚠️ Isso foi decidido depois de um caso real. Um VS Code rodando no bastion ficou preso no limite de memória e passou o dia relendo o próprio programa do servidor de arquivos: ~9 TB, que deixaram a rede lenta para o laboratório inteiro.

3. Login por chave

O labic-job não consegue pedir senha. No seu computador, crie uma chave e cadastre-a:

ssh-keygen -t ed25519                 # aceite o caminho padrão
ssh-copy-id -p 8888 <seu-usuario>@labic.utfpr.edu.br

No Windows, sem ssh-copy-id: copie o conteúdo de C:\Users\<você>\.ssh\id_ed25519.pub para o final de ~/.ssh/authorized_keys no bastion.

Depois, no seu computador, em ~/.ssh/config (Windows: C:\Users\<você>\.ssh\config):

Host labic
    HostName labic.utfpr.edu.br
    Port 8888
    User <seu-usuario>

Teste: ssh labic deve entrar sem pedir senha.

4. Configurar o labic-job

O VS Code conecta no bastion, que executa srun. O srun abre um job e, dentro dele, um servidor SSH seu, que roda como você e sem privilégios, e conversa pela própria conexão do srun. O VS Code roda no nó, dentro dos limites do job.

4.1 Uma vez, no bastion

Conectado ao bastion (ssh labic):

mkdir -p -m 700 ~/.ssh/labic-job && cd ~/.ssh/labic-job
ssh-keygen -q -t ed25519 -N '' -C labic-job-host -f host_key
cat > sshd_config <<EOF
HostKey $HOME/.ssh/labic-job/host_key
AuthorizedKeysFile $HOME/.ssh/labic-job/authorized_keys
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM no
PidFile none
AllowTcpForwarding local
X11Forwarding no
Subsystem sftp internal-sftp
LogLevel ERROR
EOF

E autorize a chave do seu computador. No seu computador:

cat ~/.ssh/id_ed25519.pub | ssh labic 'cat >> ~/.ssh/labic-job/authorized_keys; chmod 600 ~/.ssh/labic-job/authorized_keys'

4.2 No seu computador: ~/.ssh/config

Acrescente abaixo do Host labic, trocando <seu-usuario> nos dois lugares:

Host labic-job
    User <seu-usuario>
    ProxyCommand ssh labic srun -u -p l40s -c 4 --mem=8G -t 8:00:00 -J vscode /usr/sbin/sshd -i -f /home/<seu-usuario>/.ssh/labic-job/sshd_config
    ServerAliveInterval 30

• O -u é obrigatório. Sem ele o srun segura a saída e a conexão trava logo no início.
• O caminho do sshd_config tem que ser absoluto (/home/<seu-usuario>/…, não ~ nem $HOME).
• Sem GPU por padrão. A fila l40s tem CPU e memória de sobra para o editor; pedir 4 CPUs e 8 GB não reserva nenhuma GPU. Para alunos externos, isso custa ~0,19 hora-GPU por hora (como é calculado): um dia de 8 h gasta ~1,5 das 72.
• Com GPU, só para depurar algo que só aparece nela, e por pouco tempo. Use um segundo host, para não reservar uma GPU sem querer:

Host labic-job-gpu
    User <seu-usuario>
    ProxyCommand ssh labic srun -u -p l40s --gres=gpu:l40s:1 -c 4 --mem=16G -t 2:00:00 -J vscode /usr/sbin/sshd -i -f /home/<seu-usuario>/.ssh/labic-job/sshd_config
    ServerAliveInterval 30

Teste no terminal antes de usar o VS Code:

ssh labic-job hostname     # depois de alguns segundos, mostra o nome do nó (ex.: gpu11-r770), não "bastion"

Na primeira vez ele pergunta se você confia na chave do host labic-job: responda yes.

5. Conectar pelo VS Code

Em Preferences: Open User Settings (JSON):

"remote.SSH.connectTimeout": 120,
"remote.SSH.useLocalServer": true

O connectTimeout dá tempo para o job sair da fila. O useLocalServer reaproveita uma única conexão, e portanto um único job, para a janela toda. Depois: Remote-SSH: Connect to Host… → labic-job.

⚠️ Cada janela ocupa um job. Feche a janela quando terminar (File → Close Remote Connection). No fim do tempo (-t) o job acaba e o VS Code desconecta; "Reconnect" abre um job novo.

Para ver ou encerrar o job pelo bastion: squeue --me -n vscode / scancel --me -n vscode.

5.1 Treino longo: sbatch, não nohup

O terminal do VS Code roda dentro do job do labic-job, e esse job dura só enquanto a janela estiver conectada. Fechou a janela, caiu a rede ou o notebook dormiu: o job termina e o Slurm encerra tudo o que estava rodando nele. nohup, setsid, &, tmux e screen não adiantam.

Para algo que precisa continuar sozinho, submeta um job de verdade do próprio terminal do VS Code:

sbatch treino.sh                 # o job é independente da janela
squeue --me                      # acompanhar
tail -f slurm-<jobid>.out        # ver a saída

Assim você pode fechar o VS Code à noite: o treino segue no job dele, e os recursos do editor ficam livres para os outros.

Abra a pasta do projeto, não o home inteiro, e tire as pastas de dados e de saída da indexação. Pastas com milhares de imagens ou checkpoints deixam o VS Code lento e sobrecarregam o servidor de arquivos. Em .vscode/settings.json do projeto:

{
    "files.watcherExclude": {
        "**/data/**": true, "**/datasets/**": true, "**/output*/**": true,
        "**/checkpoints/**": true, "**/.venv/**": true, "**/wandb/**": true
    },
    "python.analysis.exclude": [
        "**/data", "**/datasets", "**/output*", "**/checkpoints", "**/.venv"
    ]
}

ℹ️ Dentro da sessão, as variáveis SLURM_* (e CUDA_VISIBLE_DEVICES) aparecem vazias. É normal: os limites de CPU, memória e GPU do job continuam valendo, porque o processo está dentro do job.

6. Problemas comuns

Dúvidas? Comece pelo guia do cluster. Problemas: suporte.labic.ct.utfpr.edu.br.