Guia do usuário do cluster

1. Acessando o cluster

ssh -p 8888 <seu-usuario>@labic.utfpr.edu.br

No primeiro login, o sistema pede para trocar a senha temporária que o administrador te passou. Troque com calma — o Kerberos só deixa trocar a senha uma vez por hora; se errar, peça para o administrador resetar de novo em vez de ficar tentando.

Você cai direto no seu home NFS (/home/<seu-usuario>, cota padrão 100 GB), que é o mesmo em qualquer nó — o que você grava aqui aparece igual em qualquer lugar que seu job rodar.

⚠️ Você não tem shell nos nós de computação — só no bastion. Todo uso de GPU/CPU passa pelo Slurm. Isso é proposital: uma sessão SSH solta num nó não entra no cgroup do job e furaria o isolamento de GPU/CPU/memória que o escalonador garante.

🔎 O cluster registra os logins e cada programa executado (o comando completo, inclusive dentro dos jobs), visível só para a equipe técnica e apagado após 90 dias. Por isso, nunca passe senhas ou tokens na linha de comando. Detalhes no aviso de privacidade.

Transferir arquivos

scp -P 8888 arquivo.txt <seu-usuario>@labic.utfpr.edu.br:~/
rsync -avz -e 'ssh -p 8888' pasta/ <seu-usuario>@labic.utfpr.edu.br:~/pasta/
# sshfs também funciona para montar o home localmente:
sshfs -p 8888 <seu-usuario>@labic.utfpr.edu.br:/home/<seu-usuario> ~/labic-mnt

Editar com o VS Code

O bastion não executa programas do seu home (servidor do VS Code, conda, binários): eles rodam nos nós, dentro de jobs. O VS Code Remote-SSH conecta dentro de um job Slurm. Configure pelo guia VS Code no cluster, mas antes teste o código no seu computador.

2. O cluster em duas filas (partitions)

Se você não especificar --partition, o job cai em debug — 2 CPUs e nenhuma GPU. É o erro mais comum: o job roda, mas sem GPU e devagar.

2.1 Como escolher a partition

A partition é só uma opção do Slurm, --partition (ou a forma curta -p). Você pode pôr em dois lugares:

1. Dentro do script, numa linha #SBATCH no topo — o jeito recomendado, porque fica gravado junto com o job:

   #SBATCH --partition=l40s

2. Na hora de submeter, na linha de comando — útil para testar o mesmo script nas duas filas:

   sbatch --partition=debug treino.sbatch    # testa rápido, sem GPU
   sbatch --partition=l40s  treino.sbatch    # roda de verdade, com GPU

   A opção da linha de comando vence a do #SBATCH do script.

Vale igual para srun e salloc: srun --partition=l40s ....

Você escolhe a fila, não o nó: em l40s, o Slurm decide entre gpu11-r770 e gpu06 conforme o que estiver livre. Um pedido que não cabe nos limites da fila (ex.: mais de 3 GB em debug, ou mais de 2 dias em l40s) é recusado na hora do sbatch, em vez de ficar parado na fila. sinfo mostra as filas e o estado dos nós.

3. Comandos essenciais

Você vê todos os jobs do cluster no squeue, mas só consegue cancelar os seus próprios.

4. Em lote (sbatch) ou alocando na hora (srun/salloc)

• sbatch só coloca um script na fila. Você não espera — o Slurm roda quando sobrar recurso e escreve o resultado num arquivo. É o jeito certo para treinos longos.
• srun/salloc reservam o recurso pra você, na hora, como se você tivesse "logado" num pedaço do nó. A alocação fica presa ao seu terminal — ao desconectar ou terminar, o Slurm libera sozinho. Ideal para testar, debugar ou abrir um shell/Jupyter com GPU.

4.1 Em lote (sbatch) — rodar e ir embora

#!/bin/bash
#SBATCH --job-name=meu-teste
#SBATCH --partition=debug          # fila: debug (testes, sem GPU) ou l40s (GPU) — seção 2.1
#SBATCH --cpus-per-task=2
#SBATCH --mem=2G
#SBATCH --time=00:10:00
#SBATCH --output=%x-%j.out

echo "Rodando no nó: $(hostname)"
python3 meu_script.py

sbatch script.sbatch
squeue                        # acompanha
cat meu-teste-<jobid>.out      # saída, no diretório de onde você rodou o sbatch

Regras rápidas: submeta sempre do seu home NFS, nunca de /tmp (é local ao bastion e não existe nos nós); --output=%x-%j.out grava como <job>-<jobid>.out; --time é um limite e o job é morto se passar dele. Este exemplo roda em debug; para GPU, troque para --partition=l40s e acrescente --gres — o script completo está na seção 5.

4.2 Na hora, em primeiro plano (srun)

srun sem sbatch aloca o recurso e já roda o comando ali, com a saída no seu terminal. Ao terminar, a alocação é devolvida sozinha:

srun --partition=debug --time=00:05:00 bash -c "hostname; sleep 3; echo terminei"

Para um shell interativo de verdade num nó, use --pty:

srun --partition=l40s --gres=gpu:l40s:1 --time=00:30:00 --pty bash
nvidia-smi -L
exit    # sai do shell E libera a alocação

⚠️ --pty só funciona de um terminal de verdade (sessão SSH interativa). De dentro de script/cron/automação falha com disregarding --pty option — o comando roda, mas sem shell interativo. É assim que o SSH/pty funciona, não é bug.

4.3 Reservar por um tempo (salloc)

Para segurar um pedaço do cluster e rodar vários comandos sem voltar pra fila a cada um:

salloc --partition=l40s --gres=gpu:l40s:1 --time=00:30:00
srun nvidia-smi -L        # usa a GPU já reservada, sem re-filar
srun python3 treino.py
exit                      # ou Ctrl+D — libera a alocação inteira

⚠️ Sem --time, vale o tempo padrão da fila — em l40s, 4 horas (seção 2.1). Um srun --pty/salloc esquecido aberto segura a GPU esse tempo todo. Sempre passe --time, principalmente em sessões interativas — é fácil tirar a única GPU livre do ar para os colegas.

5. Usando GPU

Sem --gres, seu job não enxerga GPU nenhuma — mesmo na fila l40s. E é silencioso: nvidia-smi responde "No devices found", sem erro. Sempre peça a GPU:

$ srun --partition=l40s --time=00:01:00 nvidia-smi -L
No devices found.

$ srun --partition=l40s --gres=gpu:l40s:1 --time=00:01:00 nvidia-smi -L
GPU 0: NVIDIA L40S (UUID: GPU-9de4e7fa-...)

#!/bin/bash
#SBATCH --job-name=job-gpu
#SBATCH --partition=l40s
#SBATCH --gres=gpu:l40s:1        # 1 GPU L40S (por nó: gpu11-r770 tem 2, gpu06 tem 4)
#SBATCH --cpus-per-task=8
#SBATCH --mem=16G
#SBATCH --time=01:00:00
#SBATCH --output=%x-%j.out

nvidia-smi -L
python3 treino.py

Cuidado com memória: o Slurm trava --mem (seu job não passa do limite), mas não considera RAM ao decidir o que cabe no nó junto com outros jobs — só conta CPUs. Peça só o que precisa e não assuma que o resto está livre.

6. Reprodutibilidade com Apptainer

O cluster não tem Docker e não tem acesso à internet. Use Apptainer (compatível com imagens Docker). Convenção: guarde suas imagens em ~/images/.

A imagem é construída no seu computador, não no cluster. Tudo o que baixa algo da internet falha no cluster: docker://..., apptainer pull, apptainer build de um .def, pip install, conda install. O fluxo é sempre: construir no seu computador → enviar o .sif → rodar no job. Você precisa do Apptainer no seu computador: no Linux, direto (instalação); no Windows, pelo WSL2 (Ubuntu); no Mac, numa VM Linux.

# no SEU computador: imagem Docker pronta (fixe a versão, nunca latest)...
apptainer pull pytorch.sif docker://pytorch/pytorch:2.5.1-cuda12.1-cudnn9-runtime
# ...ou sua própria imagem a partir de um .def (requirements.txt com versões fixas)
apptainer build --fakeroot meuapp.sif meuapp.def

# envie para o cluster
scp -P 8888 meuapp.sif <usuario>@labic.utfpr.edu.br:images/

# no cluster, dentro do job Slurm (--nv expõe os drivers NVIDIA; precisa de --gres):
apptainer exec --nv \
  --pwd /opt/app \
  --bind "$HOME/dados:/dados" \
  "$HOME/images/meuapp.sif" python3 treino.py

--pwd é importante: o Apptainer herda o diretório de onde você chamou o comando, não o WORKDIR da imagem — sem ele, imports relativos quebram silenciosamente sob sbatch.

Modelos e pesos também vêm de fora. Sem internet, o job não baixa modelos (Hugging Face, EasyOCR, torch.hub). Baixe no seu computador e envie para o cache da sua home:

# no seu computador
huggingface-cli download <org>/<modelo>
rsync -av -e "ssh -p 8888" ~/.cache/huggingface/ <usuario>@labic.utfpr.edu.br:.cache/huggingface/

# no script do job: usar o cache, sem tentar a rede
export HF_HUB_OFFLINE=1

7. Sintomas → causa

8. Suporte

Dúvidas, problemas ou pedidos de mais cota/recursos: labic@utfpr.edu.br · ou abra um chamado em suporte.labic.ct.utfpr.edu.br.