Alunos externos · disciplina

Seu saldo de horas-GPU

Como aluno(a) externo(a) de uma disciplina do LABIC, você recebe um saldo fixo para usar o cluster: 72 horas-GPU equivalentes. Esta página explica como esse saldo é contado, como acompanhá-lo e o que acontece quando ele acaba.

O essencial em 30 segundos

Você tem 72 horas-GPU equivalentes. O saldo não se renova sozinho: o que foi gasto, foi gasto.
Tudo o que você reserva conta: GPU, CPU e memória, pelo tempo que o job ficou rodando.
Um job que já está rodando nunca é interrompido por falta de saldo. Ele só começa se o --time pedido couber no que resta.
O comando saldo mostra quanto você ainda tem.
O saldo não reserva máquina. Você continua na mesma fila que todo mundo, ordenada pelo fairshare.

O que é uma hora-GPU equivalente

Para que CPU, GPU e memória caibam em um único saldo, cada recurso tem um preço na mesma moeda. Uma hora-GPU equivalente é o preço de uma GPU L40S durante uma hora:

Recurso reservado	Vale 1 hora-GPU equivalente
GPU	1 GPU por 1 hora
CPU	32 CPUs por 1 hora (ou 1 CPU por 32 horas)
Memória (RAM)	128 GB por 1 hora

Ou seja, o custo de um job por hora é:

custo/hora = GPUs  +  CPUs ÷ 32  +  GB de memória ÷ 128

Os pesos são os mesmos que o fairshare usa para todos os usuários do cluster. Ninguém paga uma tabela diferente.

Quanto cada job custa

Pedido	Custo por hora	As 72 horas rendem
`--gres=gpu:1 -c 8 --mem=12G` treino típico	1 + 0,25 + 0,09 ≈ 1,34	~53 h de job
`--gres=gpu:1 -c 4 --mem=8G` treino enxuto	1 + 0,125 + 0,06 ≈ 1,19	~60 h
`-c 16 --mem=16G` só CPU (pré-processamento)	0,5 + 0,125 ≈ 0,63	~115 h
`-p debug -c 2 --mem=2G` teste rápido, sem GPU	≈ 0,08	centenas de horas

Por que 12 GB no treino típico? O servidor gpu11-r770 tem 2 GPUs e só ~28 GB de RAM para jobs. Até ~14 GB e 24 CPUs por GPU, o job cabe nos dois servidores. Acima disso ele só roda no gpu06, e a espera tende a ser maior. Peça mais memória só se o seu código precisar.

As CPUs são entregues em pares (cada núcleo físico tem 2 threads). Pedir -c 1 reserva e cobra 2, então prefira números pares.

Como o saldo é descontado

Pelo tempo que o job realmente rodou, e não pelo --time. Um job que pediu 10 h e terminou em 2 h paga 2 h.
Pelo que foi reservado, e não pelo que foi usado. Uma GPU reservada e parada custa o mesmo que uma GPU trabalhando. Um salloc esquecido aberto consome saldo a noite inteira.
O --time decide se o job pode começar. Antes de iniciar, o Slurm confere se o job inteiro cabe no saldo disponível (--time × custo por hora). Se não couber, ele espera. É isso que garante que nenhum job é cortado no meio por falta de saldo.

Exemplo: restam 10 horas-GPU. Um job de 1 GPU, 8 CPU e 12 GB custa ~1,34 por hora. Com --time=06:00:00 ele precisa de ~8,1 e começa. Com --time=08:00:00 ele precisaria de ~10,8 e fica esperando, mesmo que fosse terminar em 3 horas.

Acompanhar o saldo

$ saldo
Cota de fulano (horas-GPU equivalentes)
  total                 72.0
  já usado              21.4
  reservado agora        3.0   (jobs rodando, pelo --time pedido)
  disponível            47.6

Reservado agora é o que os seus jobs em execução ainda podem consumir até o --time deles. Isso volta para o disponível se eles terminarem antes.

Para ver quanto custou cada job:

sacct -X -S 2026-01-01 -o JobID,JobName%20,Elapsed,AllocTRES%60

Em AllocTRES, o campo billing= é o custo por hora na unidade interna. Divida por 32 para obter horas-GPU por hora: billing=43 → ~1,34.

Quando o saldo acaba (ou não cobre o pedido)

O job não é recusado. Ele fica na fila como PENDING, com o motivo QOSGrpBillingMinutes:

$ squeue --me
  JOBID PARTITION   NAME     USER ST  TIME  NODES NODELIST(REASON)
   4711      l40s  train   fulano PD  0:00      1 (QOSGrpBillingMinutes)

Se ainda há saldo, mas não o suficiente: diminua o --time (scontrol update job <jobid> TimeLimit=04:00:00) ou peça menos CPU e memória.
Se o saldo acabou: cancele o job (scancel <jobid>) e, se precisar de mais, abra um chamado com a anuência do(a) professor(a) da disciplina.
Seus arquivos não são afetados. Seu home continua acessível mesmo com o saldo zerado.

Limites simultâneos

Além do saldo total, há um teto para o que você pode usar ao mesmo tempo. Assim o saldo de uma pessoa não ocupa um servidor inteiro de uma vez:

Limite	Valor
GPUs ao mesmo tempo	1
CPUs ao mesmo tempo	16
Memória ao mesmo tempo	64 GB
Jobs rodando / na fila	4 / 50
Duração máxima de um job	24 h

Um job que passa desses tetos fica PENDING com motivo QOSMax…. Ele não roda até você reduzir o pedido.

Como render o saldo

Teste na fila debug primeiro (sem GPU, quase de graça). Um erro de digitação descoberto depois de esperar a GPU custa caro.
Peça só o que o código usa. CPU e memória sobrando custam saldo. Confira o uso real de um job que já terminou com sacct -j <jobid> -o JobID,Elapsed,TotalCPU,MaxRSS,ReqMem.
Use um --time realista, um pouco acima do esperado. Um valor exagerado não custa saldo, mas impede o job de começar quando o saldo está no fim.
Salve checkpoints. Um treino de 24 h que cai na hora 23 sem checkpoint perde 23 horas de saldo.
Feche sessões interativas (exit no salloc) assim que terminar.
Não deixe para a véspera. O saldo garante quanto você pode usar, não quando. Perto da entrega, a fila costuma estar cheia.

Dúvidas? Comece pelo guia do cluster e pela página de fairshare. Problemas e pedidos de saldo: suporte.labic.ct.utfpr.edu.br.