GPU para seus projetos · pagamento em cripto sem KYC Como alugar
Português
Abrir o console
Guia prático / KERNODECK

Um processo encerrado ainda não é um resultado aceito.

Antes de um processamento longo, fixe suas entradas, seu destino, seus eventos de progresso e seu critério de sucesso. Se você dispõe de um shell remoto, separe a sessão de conexão do processo de cálculo. Ao final, examine o código de retorno e depois os próprios resultados: um comando sem erro não demonstra nem que todos os dados foram processados nem que as saídas são utilizáveis.

8 min de leitura · Guia para desenvolvedores

1. Distinguir quatro estados que a tela mistura

Uma conexão aberta prova apenas que você ainda pode dialogar com a máquina. Um terminal visível pode hospedar um shell cujo cálculo já terminou. Por outro lado, perder a conexão não permite concluir que o processo parou. Portanto, comece dando um nome à execução e ao local onde encontrar seus rastros.

Acompanhe separadamente a existência do processo, seu progresso de negócio e a aceitação do resultado. O número de linhas em um log não é um contador de dados bem-sucedidos: um programa pode repetir o mesmo aviso. Uma saída parcial pode ser legível e ainda assim estar incompleta.

Esse método pressupõe que você recebeu e verificou os meios de acesso necessários. Ele não promete um protocolo de acesso específico nem uma conservação automática dos arquivos. As ferramentas e destinos disponíveis devem ser verificados no ambiente efetivamente fornecido.

Role a tabela para ler todas as colunas.
Cada observação responde a uma pergunta diferente.
ObservaçãoO que ela indicaO que ela não demonstra
Conexão ativaO canal responde.O cálculo avança.
Processo presenteUma execução ainda existe.Ela processa os itens corretos.
Contador validado em altaUnidades previstas foram concluídas.Todo o corpus foi concluído.
Código de retorno igual a zeroO programa anuncia uma terminação normal.O resultado respeita seu contrato.
Saídas controladas e recuperadasOs critérios escolhidos foram verificados.Uma qualidade além desses critérios.

2. Preparar uma execução identificável antes de desanexá-la

Controle os dados, a configuração efetiva e uma primeira passagem curta da aplicação. O diagnóstico de GPU responde a outra pergunta: o backend sabe executar um cálculo? Ele não valida o carregamento completo do corpus nem a lógica do seu programa. Faça essas verificações antes de iniciar uma duração importante.

Escolha um identificador de execução e uma pasta nova. Guarde o comando sem segredo, a versão do código, a identidade das entradas e o resultado esperado. Preveja onde escrever os logs e onde recuperar os arquivos. Dois lançamentos não devem escrever simultaneamente na mesma pasta.

Para um trabalho dividido em partições independentes, decida quando uma partição se torna concluída: cálculo finalizado, arquivo fechado, conteúdo verificado e estado registrado. Um arquivo em processo de escrita não deve ter o mesmo significado que um resultado aceito. Verifique também o espaço realmente utilizável antes de começar.

3. Manter um terminal recuperável quando o contexto permite

Se o ambiente oferece um shell Unix e tmux, esse multiplexador permite desanexar um terminal e reencontrá-lo após uma reconexão. Ele protege esse percurso contra a perda do cliente de conexão; não é um mecanismo de retomada após reinicialização da máquina ou destruição do processo.

Os comandos abaixo são didáticos e não são executados. Eles pressupõem Bash, tmux e seu próprio programa tratamento.py, com as opções mostradas; esse arquivo não é um recurso fornecido. Verifique primeiro seu comando curto e use um nome de sessão distinto para não confundir dois cálculos.

Crie a sessão e depois execute o segundo bloco dentro dela. A criação da pasta falha se ela já existir, o que evita reutilizar silenciosamente seus logs. O código de retorno é preservado se o shell chegar à etapa de escrita; uma interrupção abrupta pode impedir a criação desse arquivo. Portanto, a ausência de código não é um sucesso implícito.

Com os atalhos padrão, desanexe com Ctrl-b e depois d. Após a reconexão, liste as sessões e reanexe a correta. O shell pode continuar visível mesmo que o programa tenha terminado: consulte o log e o código registrado. Não inicie imediatamente uma segunda cópia só porque seu terminal antigo desapareceu.

Criar uma sessão — comandos didáticos
tmux new -s campagne-a
Dentro da sessão — exemplo a adaptar, não executado
mkdir -p runs
mkdir runs/campanha-a && (
  code_retour=0
  python -u tratamento.py --config config.toml --output runs/campanha-a \
    > runs/campanha-a/execution.log 2>&1 || code_retour=$?
  printf '%s\n' "$code_retour" > runs/campanha-a/exit-code.txt
  exit "$code_retour"
)
Após a reconexão — reencontrar a sessão
tmux ls
tmux attach -t campagne-a

4. Contar trabalho aceito, não apenas atividade

A opção Python -u remove o buffering de suas saídas padrão e de erro. Ela ajuda a ver as mensagens emitidas, mas não cria eventos de progresso na aplicação. Uma biblioteca ou uma etapa silenciosa ainda pode exigir uma observação própria.

Defina fases compreensíveis: leitura, preparação, cálculo, escrita, verificação. Adicione um contador cuja unidade seja estável, além de um total quando ele for conhecido. Se você conta partições aceitas, não passe para um contador de linhas lidas no meio do log sem mudar seu nome.

O exemplo didático a seguir trata de oito partições de quinhentos elementos, ou seja, quatro mil elementos. No instante ilustrado, apenas cinco partições são aceitas. A sexta é parcial e não deve inflar o total. Os números mostram uma regra de contagem; eles não descrevem nenhuma execução da Kernodeck.

Role a tabela para ler todas as colunas.
Instantâneo didático não executado: cinco partições aceitas de oito.
PartiçõesEstadoElementos contados como aceitosDecisão
1 a 5Verificadas2 500Conservar suas identidades e resultados.
6Escrita parcial0Não anunciar essa partição como concluída.
7 e 8A tratar0Permanecer na lista de trabalho.
ConjuntoIncompleto2.500 de 4.000Não aceitar a pasta final.

5. Examinar um silêncio ou uma interrupção sem criar duplicata

Quando nenhum contador se move, identifique a última fase conhecida e sua última unidade concluída. Verifique se o processo existe, se uma mensagem de erro apareceu e se o destino continua utilizável. Um início lento do modelo e um loop travado podem produzir a mesma tela imóvel; o contexto decide a próxima verificação.

Prepare a parada voluntária na sua aplicação: solicitação de parada, fim de uma unidade segura, gravação de estado e depois saída. Os sinais e interrupções dependem do sistema. O Python não consegue interceptar SIGKILL, e um handler Python pode esperar o fim de uma chamada nativa longa antes de ser executado. Portanto, um salvamento na parada não substitui salvamentos periódicos.

Após uma perda de conexão, reencontre primeiro a sessão e a execução existentes. Após uma parada confirmada, determine o que está completo e o que está parcial. Para um treinamento, a retomada exige os estados detalhados do modelo e da otimização; o guia dedicado verifica esse caso em um novo processo.

6. Retomar apenas o que o contrato permite

Em nosso exemplo, a retomada por partição pressupõe que cada partição é independente e que a entrada, o código e a configuração permanecem idênticos. Ela pode conservar os cinco resultados validados e recalcular o sexto inteiramente antes de prosseguir com os dois seguintes. Se essas premissas não se sustentarem, esse atalho não se justifica.

Não adicione simplesmente as novas linhas ao arquivo parcial. Você correria o risco de produzir duplicatas ou de misturar duas configurações. Use os identificadores esperados para distinguir completo, incompleto e ausente. Conserve o estado anterior como elemento de explicação, com um destino separado para a nova tentativa.

Verifique sua estratégia em uma interrupção controlada antes de depender dela para um processamento grande. O critério é a equivalência das saídas úteis segundo o seu contrato, não a identidade das mensagens de progresso. Treinamentos, cálculos com efeitos externos e processamentos distribuídos exigem outras garantias além deste exemplo de partições independentes.

7. Aceitar e recuperar o resultado antes de encerrar o trabalho

Comece pelo código de retorno, depois confronte as saídas com o manifesto de entrada. Para o nosso exemplo, aguarde as oito partições e os quatro mil identificadores previstos, sem falta nem duplicata. Controle o formato, as dimensões e os valores pertinentes; ler um arquivo não demonstra que ele contém o resultado correto.

Recupere as saídas aceitas, a configuração autorizada, as versões e o relatório de controle. Compare os tamanhos e, se necessário, as impressões digitais entre origem e cópia. Uma impressão digital idêntica ajuda a verificar a transferência dos bytes; ela não prova nem a qualidade do modelo nem a procedência legítima do arquivo.

Por fim, abra um resultado a partir do seu destino de conservação, com a ferramenta que o utilizará. Preveja esta etapa antes do fim do seu acesso ao processamento. O trabalho está terminado quando o resultado controlado é recuperável e interpretável, não quando a última porcentagem atingiu cem.

Suas perguntas

Fechar uma conexão remota sempre interrompe o processamento?

Não: isso depende de como o processo foi iniciado. Uma sessão tmux permite desacoplá-lo do terminal cliente, se essa ferramenta estiver disponível. Após reconectar, procure primeiro a execução existente antes de iniciar outra.

Um código de retorno igual a zero é suficiente para validar meu resultado?

Não. Ele indica que o programa anuncia uma terminação normal. Verifique também a completude dos identificadores, o formato e os critérios de negócio previstos. Um programa pode terminar normalmente após ter processado um subconjunto errado.

Um log imóvel significa que a GPU está travada?

Não necessariamente. O programa pode estar preparando dados, aguardando uma escrita ou não emitindo progresso. Identifique a fase e o estado do processo antes de decidir por uma interrupção. Um contador de negócio explícito é mais útil do que a mera presença de mensagens.