CapordiaDefinir o que o calendário deve proteger
Comece pela decisão que não poderá mais esperar: uma revisão de resultados, uma transferência para outra equipe ou o fim do período de locação. Nomeie, para cada projeto, a pessoa habilitada a aceitar o seu resultado. Uma data de entrega não é simplesmente uma data de fim do cálculo: a revisão e a recuperação dos arquivos já devem ter o seu lugar nela.
Distinga em seguida a disponibilidade da máquina e a das pessoas. Um cálculo pode às vezes avançar à noite, mas a sua equipe pode exigir presença para um primeiro lançamento ou uma validação. Escreva essa restrição em vez de contar todas as horas do pacote como horas de trabalho intercambiáveis. O calendário é uma convenção interna a confirmar, não um compromisso de fornecimento da Capordia.
Coletar uma estimativa utilizável, com a sua origem
Para cada trabalho, anote as entradas esperadas, a hora em que estarão realmente prontas, o número de placas simultâneas, a memória por placa e as necessidades de transferência. Adicione uma estimativa de ocupação do recurso desde o início do carregamento até a sua liberação. Separe as tarefas de preparação que podem ser feitas antes dessa ocupação: isso evita reservar uma placa durante uma espera administrativa.
Indique se a estimativa vem de um teste comparável, de uma extrapolação ou de uma simples hipótese. Uma duração antiga só é comparável se os dados, versões, ajustes e recursos úteis forem suficientemente próximos. Na ausência de medição, marque uma faixa a validar; não exiba uma precisão ao minuto que sugeriria uma medição. Reserve um pequeno teste de qualificação quando o seu resultado mudar a escolha do calendário.
Passar do volume total para os horários realizáveis
Some as ocupações previstas para identificar uma sobrecarga evidente e, em seguida, coloque cada trabalho em uma linha do tempo. Um processamento indivisível de quatro horas não cabe em dois intervalos de duas horas, a menos que uma interrupção e uma retomada tenham sido validadas. Dois trabalhos que exigem simultaneamente o mesmo disco ou a mesma pessoa também podem se atrapalhar mesmo quando ainda resta uma placa disponível.
A documentação do Slurm mostra por que o preenchimento dos horários depende das durações e dos recursos solicitados: uma tarefa de menor prioridade pode iniciar se não atrasar o início previsto de uma tarefa prioritária. Essa lógica ajuda a ler o seu plano; ela não anuncia a presença do Slurm em uma oferta Capordia. Qualquer uso de um agendador pressupõe a sua configuração real e uma política decidida pela sua equipe.
Exemplo fictício: três projetos em dois dias
A equipe fictícia «Bureau des tracés» dispõe, para este exercício, de uma única placa utilizável das 9h às 17h durante dois dias D1 e D2. Nenhum processamento compartilha a placa e cada ocupação inclui carregamento, cálculo e exportação. As durações seguintes são hipóteses pedagógicas: elas não provêm nem de uma GPU do catálogo nem de um benchmark. A preparação comum ocupa uma hora no início do D1.
Atlas requer quatro horas e deve ser entregue antes do D2 às 13h. Balise requer três horas; suas entradas chegam no D1 às 11h e sua entrega está prevista para o D1 às 18h. Cadastre requer cinco horas; ele fica pronto no D2 às 9h e deve ser entregue antes das 18h. A necessidade é de 4 + 3 + 5 = 12 horas. Com uma hora comum e três horas deixadas livres, o plano usa as dezesseis horas abertas.
| Horário | Ocupação prevista | Duração | Condição |
|---|---|---|---|
| D1, 9h–10h | Preparação e controle comuns | 1 h | Entradas e versões disponíveis |
| D1, 10h–14h | Atlas | 4 h | Trabalho pronto às 10h |
| D1, 14h–17h | Balise | 3 h | Entradas recebidas às 11h |
| D2, 9h–14h | Cadastre | 5 h | Entradas recebidas às 9h |
| D2, 14h–17h | Reserva não atribuída | 3 h | Margem disponível apenas no D2 |
Colocar a margem antes do risco que ela deve absorver
As três horas livres representam 25% das doze horas de trabalho. Esse percentual, no entanto, não basta para proteger Balise: a sua margem fica no dia seguinte à sua entrega. Se Atlas levar cinco horas em vez de quatro, Balise não pode terminar antes das 17h na janela permitida. O plano se sustenta no papel, mas o seu primeiro dia continua frágil. Essa leitura é mais útil do que uma simples taxa média de preenchimento.
A equipe pode então deslocar Atlas em parte ou na totalidade para outra janela apenas se as suas restrições o permitirem, obter uma janela adicional ou reduzir um escopo aceito. Uma segunda placa é uma opção a examinar, não a conclusão automática: ela deve estar disponível, ser compatível e vir acompanhada dos recursos de host necessários. Sem solução validada, o responsável altera o compromisso do projeto antes do lançamento, em vez de chamar de «margem» uma reserva inutilizável.
Arbitrar um conflito com uma regra anunciada
Prepare a arbitragem antes que dois responsáveis reivindiquem o mesmo horário. Uma regra simples pode priorizar primeiro um prazo externo confirmado, depois um trabalho cujas entradas estão prontas, e por fim a antiguidade da solicitação. Especifique quem pode abrir exceção a essa regra e qual equipe arcará com o deslocamento. Uma urgência deve ter uma consequência explícita no plano, e não se tornar uma nova prioridade permanente para quem a solicitou.
Mantenha o cronograma de referência e o motivo das mudanças: entrada que chegou tarde, duração observada mais longa ou escopo ampliado. O guia sobre a fila de trabalhos trata da decisão do próximo lançamento; o cronograma, por sua vez, protege os prazos de vários projetos. A articulação entre eles permite explicar por que uma GPU momentaneamente livre não está necessariamente disponível para um longo processamento adicional.
Verificar o plano e revisá-lo com os desvios corretos
Releia um dia avançando de horário em horário. Cada início deve ter suas entradas, seus acessos, sua capacidade de memória e seu responsável disponíveis. Controle a transferência final e o tempo de revisão antes da entrega. Em seguida, simule o atraso mais plausível e verifique qual margem realmente o absorve. Se um único desvio fizer perder um prazo importante, apresente o plano como condicional.
Após uma execução real, distinga espera antes do início, ocupação da GPU e prazo até o resultado aceito. Corrija a próxima estimativa com essa decomposição. Um atraso de transferência não justifica por si só uma GPU mais potente; uma preparação manual esquecida não se corrige aumentando a margem do cálculo. O acompanhamento deve ajudar a eliminar a causa do desvio, não a procurar um responsável a partir de um total isolado.
Relacionar o cronograma ao pacote sem confundir as unidades
Um dia de oito horas neste exemplo é uma janela de organização, não uma tarifa de oito horas. O catálogo Capordia oferece períodos fixos de 3, 7 ou 30 dias e preços por lote completo. Verifique separadamente a duração da locação, o número de GPUs do lote e o cronograma de trabalho. Uma GPU adicional não elimina nem a preparação nem a validação humana.
O entregável útil é um cronograma aprovado com suas premissas, suas margens posicionadas e suas decisões em caso de desvio. Ele ainda precisa ser confirmado com os recursos efetivamente fornecidos e um teste representativo. Não transforme nem as dezesseis horas do exercício nem seu percentual de reserva em prazo garantido ou em regra universal de dimensionamento.
Perguntas para decidir
Posso dividir as horas previstas pelo número de GPUs?
Somente se os trabalhos puderem avançar em paralelo e se os outros recursos permitirem. Um processamento indivisível, uma dependência ou uma etapa de revisão pode limitar o cronograma. Deixe essas restrições visíveis antes de converter horas totais em número de GPUs.
Qual margem deve ser reservada?
A margem depende dos desvios plausíveis e de sua posição no cronograma. As três horas do exemplo são fictícias e não protegem todos os prazos. Coloque uma reserva antes da entrega que ela deve assegurar e, em seguida, justifique-a com suas observações.
O planejamento substitui a conferência da máquina?
Não. Ele pressupõe recursos e uma aplicação utilizáveis. A conferência deve verificar essa hipótese antes de considerar os horários como aproveitáveis. Se uma condição permanecer desconhecida, o cronograma deve manter um status provisório e uma decisão de contingência.