1. Guarde a mensagem e o contexto antes de reiniciar
Pare de adicionar tarefas à fila. Anote o texto exato do erro, o arquivo ou a consulta envolvidos, o número de elementos processados juntos e a etapa alcançada. O modelo estava carregando, o cálculo estava avançando ou a saída estava sendo gravada? Mantenha os ajustes em uma nota e os resultados já concluídos em sua pasta.
Uma tela travada ou um aplicativo fechado sem explicação não bastam para identificar a causa. Recupere o log dele quando existir. Uma falha de conexão, uma entrada inválida e uma memória esgotada podem produzir sintomas parecidos na interface. Se o software não informar nada, escreva "causa não determinada" e prepare um teste mínimo em vez de inventar um diagnóstico.
2. Separe memória da GPU, memória do sistema e espaço em disco
A memória da GPU serve para os elementos do cálculo na placa. A RAM do servidor e o armazenamento atendem a outras necessidades. As capacidades exibidas nas fichas de GPU da BriefGPU não descrevem a RAM ou o disco efetivamente disponíveis. Verifique o recurso mencionado pela mensagem e as informações do seu ambiente.
Em Python, MemoryError indica uma falha de alocação de memória; esse nome sozinho não indica falta de VRAM. O código ENOSPC corresponde à falta de espaço no dispositivo em questão. Essas referências orientam a busca, mas o log do aplicativo continua sendo necessário para localizar a operação.
| Observação | Primeira verificação | O que uma GPU maior não resolve sozinha |
|---|---|---|
| Mensagem CUDA out of memory durante o cálculo | Memória da placa usada, outras tarefas e tamanho do grupo | Uma incompatibilidade do software ou um arquivo corrompido |
| MemoryError durante a leitura dos arquivos | Memória do processo, quantidade de dados carregados na RAM | O carregamento de toda a pasta na memória do sistema |
| No space left on device durante uma exportação | Espaço e eventual cota da pasta de saída ou temporária | Um disco cheio ou um limite de armazenamento |
| Aplicativo fechado sem mensagem aproveitável | Log, etapa alcançada e teste em uma única entrada | Uma causa ainda desconhecida |
3. Volte a uma entrada e a um único trabalho ativo
Verifique primeiro os processamentos que você mesmo iniciou. Uma pré-visualização, uma sessão antiga ou uma segunda ferramenta ainda pode estar trabalhando. Feche corretamente as tarefas que se tornaram inúteis depois de preservar seu estado. Não encerre um processo que você não reconhece e não reinicie todo o ambiente para ganhar alguns minutos de diagnóstico.
Retome a entrada que falhou, sozinha, sem diminuir sua qualidade. Se ela passa isoladamente mas falha em grupo, o número de elementos simultâneos se torna uma pista. Reduza, por exemplo, um grupo de quatro para dois, depois para um se necessário. O número de arquivos da pasta continua o mesmo; apenas a quantidade processada ao mesmo tempo muda.
Algumas ferramentas oferecem processamento sequencial para limitar os picos de memória. O Diffusers documenta, em particular, o fatiamento da decodificação de um grupo de imagens. Essa possibilidade depende do pipeline utilizado: consulte suas opções antes de ativar um ajuste encontrado para outro modelo.
4. Reduza a carga sem perder o resultado solicitado
Se uma entrada sozinha falha, examine suas dimensões ou seu comprimento. Para uma imagem, passar de 2.048 × 2.048 para 1.024 × 1.024 divide o número de pixels por quatro. Isso não garante uma memória total dividida por quatro: o modelo e os outros elementos mantêm suas próprias necessidades. Uma redução só é aceitável se a saída conservar os detalhes necessários.
Para um assistente, diferencie os documentos fornecidos, a pergunta e a resposta gerada. O cache de geração pode consumir mais memória com um contexto longo; os mecanismos exatos dependem do modelo. Teste uma solicitação mais curta ou uma única requisição por vez. Não remova o trecho que contém a resposta e depois conclua que o problema está resolvido.
Mantenha sempre a entrada original. Nomeie a variante de teste e escreva o que ela muda. Se a ferramenta oferece um fatiamento em blocos ou a transferência de alguns elementos para a RAM, consulte a documentação e verifique as emendas, a qualidade e o tempo observado. Uma opção econômica em VRAM pode deslocar a restrição para outro lugar.
5. Não confunda memória reservada com memória útil
Com o PyTorch, a memória reservada pelo alocador e a ocupada pelos tensores são duas medidas diferentes. Esvaziar o cache não utilizado não libera os tensores ainda ativos. Portanto, um comando de limpeza não transforma uma carga grande demais em carga compatível.
Se uma reinicialização limpa da sua aplicação ajudar, execute em seguida o mesmo caso pequeno e anote o resultado. Um sucesso após reiniciar não prova por si só que um vazamento de memória foi corrigido. Se o uso aumentar a cada passagem idêntica, guarde essa observação e consulte a documentação ou o suporte do software antes de acumular reinicializações.
Exemplo: isolar o problema em uma pasta de doze imagens
Eis um cenário ilustrativo, sem medição de hardware. Uma freelancer prepara doze imagens, das quais duas têm grandes dimensões e texto fino. O processamento em grupos de quatro falha. Ela guarda a mensagem e então tenta uma das grandes imagens sozinha, na qualidade inicial. A tabela mostra como interpretar observações possíveis.
Nesse cenário, ela adota os grupos de dois somente depois de ter conferido as duas grandes imagens juntas e algumas imagens comuns. Ela verifica o texto e os contornos nos arquivos exportados. Ela não generaliza esse resultado para todos os tamanhos de imagem, todos os modelos nem outro software.
| Teste do cenário | Observação hipotética | Decisão local |
|---|---|---|
| Quatro imagens simultâneas | Falha de memória | Guardar o erro e reduzir o grupo |
| Uma grande imagem, mesmos ajustes | Saída completa e aceitável | A qualidade desejada pode passar nesse caso isolado |
| Duas grandes imagens juntas | Saídas completas e aceitáveis | Testar esse grupo em um trecho curto |
| Imagem bastante reduzida | Cálculo concluído, texto ilegível | Descartar essa redução apesar do sucesso técnico |
Quando outra capacidade se torna uma pista justificada
Compare com outra placa quando a falta de memória de GPU estiver identificada, quando o caso indispensável falhar sozinho e quando as reduções compatíveis com a sua qualidade não forem suficientes. Mantenha o software, a versão, os parâmetros e a entrada em questão: esse registro torna o próximo teste comparável. Ele não permite deduzir exatamente quantos GB adicionais serão suficientes.
Um erro ao carregar o modelo também pode limitar o interesse de reduzir o grupo: boa parte da carga existe antes da primeira entrada. As opções de precisão ou de quantização mudam as condições de execução e, às vezes, os resultados; elas exigem um teste separado. Adicionar lotes não unifica automaticamente a memória de várias placas.
Termine com um diagnóstico utilizável
Sua nota final cabe em cinco elementos: mensagem e etapa, recurso suspeito, entrada mantida, ajuste que passa ou falha, controle de qualidade realizado. Acrescente o que continua desconhecido. Se nenhum caso pequeno funcionar, pare de repetir o lote completo e peça ajuda com essas informações.
Não exclua seus únicos originais para liberar disco, não reduza vários parâmetros ao mesmo tempo e não considere uma saída parcial como sucesso. Reserve um tempo para salvar os resultados válidos. O diagnóstico deve reduzir a incerteza; ele não precisa se transformar em uma sessão interminável de ajustes.