Voce clicou em gerar, a barra andou dois passos e o console cuspiu CUDA out of memory. Antes de sair trocando de placa, entenda o que essa mensagem realmente diz.
Resposta rapida: o erro significa que o alocador da GPU nao conseguiu reservar um bloco de memoria do tamanho pedido, e nao necessariamente que a placa esta cheia. As duas alavancas maiores sao resolucao e batch size. Depois vem offload de modelo, atencao eficiente, tiling de VAE, pesos em fp16 ou quantizados, e fechar tudo que disputa a GPU.
O que a mensagem CUDA out of memory realmente significa
A leitura literal engana. Quando o driver recusa uma alocacao, ele nao esta dizendo apenas que a VRAM acabou. Ele esta dizendo que, no momento exato em que o modelo pediu um bloco contiguo de memoria de um determinado tamanho, o alocador nao encontrou espaco livre suficiente em sequencia para entregar esse bloco.
Isso muda tudo na hora de diagnosticar. Existem casos em que o monitor mostra memoria livre e mesmo assim a geracao quebra. A memoria livre esta la, mas picotada em pedacos pequenos espalhados, e o tensor que precisa nascer exige um pedaco unico e grande. E o mesmo problema de estacionar um onibus num estacionamento cheio de vagas de moto: soma de espaco livre nao e espaco util.
A consequencia pratica: nem todo erro se resolve liberando um pouco de memoria. Alguns se resolvem reduzindo o tamanho do maior bloco que o pipeline pede em qualquer instante. Outros se resolvem simplesmente reiniciando o processo para que o alocador comece com um mapa limpo. Saber qual dos tres casos voce tem economiza horas.
Pico de memoria e nao memoria media
Uma geracao nao consome VRAM de forma constante. Ela tem picos. O carregamento dos pesos e um pico. Cada passo de amostragem tem seu proprio pico de ativacoes. A decodificacao final pelo VAE costuma ser o maior pico de todos, e por isso e comum a imagem quase terminar e o erro aparecer bem no fim, quando o preview ja apareceu na tela. Se o seu erro sempre acontece no ultimo instante, o suspeito numero um e o VAE, nao o modelo.
Onde a VRAM vai parar
Para escolher a correcao certa, voce precisa saber quem esta comendo a memoria. Sao basicamente quatro consumidores, e eles se comportam de formas bem diferentes.
Pesos do modelo
Os pesos sao o custo fixo. Eles entram na VRAM quando o modelo carrega e ficam la enquanto voce gerar. O tamanho depende de duas coisas: quantos parametros o modelo tem e em qual precisao ele esta armazenado. Modelos de classe XL sao sensivelmente mais pesados que os modelos da geracao 1.x, e os modelos de video ou os checkpoints mais modernos de arquitetura maior sao mais pesados ainda. Precisao de meia palavra, o famoso fp16, ocupa metade do que a precisao completa ocupa. Formatos quantizados, incluindo os pacotes estilo GGUF, comprimem mais ainda em troca de uma perda de qualidade que na maioria dos casos e pequena.
Latentes
O latente e a imagem em processamento no espaco comprimido. O custo dele escala aproximadamente com a quantidade de pixels da imagem final. E aqui esta a parte que a maioria das pessoas subestima: dobrar largura e altura ao mesmo tempo nao dobra o custo, quadruplica. Sair de um quadrado padrao para o dobro em cada lado significa quatro vezes mais area, e o latente acompanha essa area. Quem tenta gerar direto em resolucoes grandes numa placa modesta bate no teto quase sempre por causa disso.
Ativacoes de atencao
Durante a amostragem, os blocos de atencao criam matrizes intermediarias temporarias. Em implementacoes ingenuas, esse custo cresce muito rapido conforme a imagem fica maior, porque a atencao compara posicao com posicao. E justamente esse componente que as implementacoes modernas de atencao eficiente atacam, reescrevendo a operacao para nao materializar a matriz inteira de uma vez.
Passes empilhados
Upscaler, ControlNet, adaptadores de identidade de rosto, refinadores, tudo isso adiciona modelo extra e ativacoes extras. O ponto perigoso e que eles somam no mesmo instante. Um ControlNet ativo mais um refinador mais um upscale no mesmo fluxo transformam um pipeline que cabia numa placa em outro que nao cabe, sem que voce tenha mudado o checkpoint principal.
Resolucao e batch: as duas alavancas que mais importam
Se voce vai mudar uma coisa so, mude a resolucao. Se vai mudar duas, mude resolucao e batch size.
A regra basica que resolve a maioria dos casos e gerar na resolucao nativa do modelo e depois ampliar. Cada familia de modelo foi treinada em torno de um tamanho de referencia, e gerar acima desse tamanho nao so custa mais memoria como costuma degradar a composicao, produzindo corpos duplicados e enquadramentos estranhos. Voce paga caro em VRAM para receber um resultado pior. Gerar no tamanho nativo e ampliar depois e mais barato e quase sempre entrega mais detalhe.
Batch size e o segundo item. Batch size dois significa dois latentes vivos ao mesmo tempo, com todas as ativacoes correspondentes. Coloque batch size em um e faca varias execucoes seguidas em vez de uma execucao gorda. Voce perde um pouco de eficiencia de tempo e ganha estabilidade. Preste atencao para nao confundir batch size com batch count: contagem executa em sequencia e e barata em memoria, tamanho executa em paralelo e e cara.
Proporcao tambem conta. Um retrato bem alongado ou um panorama muito largo tem mais pixels que um quadrado equivalente. Se voce esta no limite, um formato menos extremo pode ser a diferenca entre gerar e travar. Quem usa uma placa de entrada como as de doze gigabytes anunciados encontra esse teto o tempo todo, e vale ler o guia de como rodar Stable Diffusion numa RTX 3060 para calibrar expectativa de tamanho antes de brigar com o erro.
Modos de pouca VRAM e offload
As interfaces populares oferecem modos que trocam velocidade por memoria. Eles funcionam movendo partes do pipeline entre a VRAM e a memoria do sistema conforme a necessidade.
O modo intermediario, conhecido como medvram nas interfaces derivadas do webui classico, mantem o componente ativo na GPU e descarrega os demais para a RAM. Voce perde algum tempo com as transferencias, mas o pico cai bastante. O modo agressivo, o lowvram, fatia ainda mais o carregamento e move quase tudo, permitindo rodar modelos que de outra forma nem carregariam. O custo em velocidade e real e pode ser grande.
Nos pipelines por codigo existe o offload sequencial de CPU, que descarrega submodulo por submodulo. E o ajuste mais economico em memoria e o mais lento em relogio. Existe tambem o offload de modelo inteiro, menos radical, que troca blocos maiores e sofre menos com a ida e volta constante pelo barramento.
Uma observacao honesta sobre esses modos: eles dependem de voce ter RAM de sistema sobrando. Descarregar para a RAM quando a RAM tambem esta apertada troca um erro de CUDA por swap em disco, e ai a geracao fica tao lenta que parece travada. Se a maquina tem pouca memoria principal, feche programas antes de ativar offload agressivo.
Atencao eficiente
Ative a implementacao eficiente de atencao disponivel no seu ambiente, seja xformers ou o caminho nativo de atencao escalada do framework. Esse e um dos poucos ajustes que costuma reduzir memoria e ainda melhorar o tempo de geracao. O fatiamento de atencao, o attention slicing, e a versao mais conservadora: divide o calculo em pedacos e baixa o pico com um custo modesto de velocidade.
Tiling e slicing de VAE
Se o erro aparece na decodificacao final, ative tiling ou slicing de VAE. Tiling decodifica a imagem em quadrados e depois costura, com sobreposicao para esconder as emendas. Slicing decodifica um item por vez quando ha varios. Sao ajustes que praticamente eliminam a classe de erro que acontece no ultimo segundo. Em imagens muito grandes o tiling pode deixar uma leve diferenca de tom entre blocos em areas de degrade suave, e a solucao e aumentar a sobreposicao.
Precisao dos pesos: fp16 e quantizacao
Carregar em meia precisao e o padrao sensato em praticamente qualquer placa moderna. A diferenca visual em relacao a precisao completa e desprezivel para geracao de imagem e a economia de memoria e imediata. Se voce esta rodando em precisao completa sem uma razao especifica, esse e um ganho gratuito.
Um passo alem estao os pesos quantizados. A comunidade distribui variantes comprimidas dos modelos mais pesados, inclusive em formatos empacotados estilo GGUF, justamente para permitir que placas menores rodem arquiteturas grandes. A troca e clara: cabe na memoria, custa um pouco de fidelidade e, dependendo do formato, pode ser mais lento porque exige descompactar durante o calculo. Para modelos de nova geracao numa placa de entrada, muitas vezes e a unica forma de participar da festa.
O mesmo raciocinio vale para os componentes acessorios. Codificadores de texto e VAEs tambem tem versoes em precisao reduzida. Trocar um VAE pesado por uma versao mais enxuta as vezes resolve sozinho o erro que aparecia no fim. Quem baixa esses arquivos de repositorio publico se orienta bem com o tutorial de Civitai em portugues, que explica como identificar variante e precisao antes de baixar o arquivo errado.
Feche quem esta roubando sua GPU
Antes de mexer em qualquer parametro, olhe quem mais esta usando a placa. Isso e chato e obvio, e resolve uma quantidade absurda de casos.
O navegador e o principal culpado. Aceleracao de hardware ligada com muitas abas abertas, video rodando, uma videochamada esquecida em segundo plano, tudo isso reserva VRAM. Jogos e launchers mantem memoria alocada mesmo minimizados. Programas de edicao de video e de modelagem seguram buffers grandes. Ate o proprio ambiente grafico do sistema consome uma fatia fixa, especialmente com monitores de alta resolucao ou multiplos monitores.
Ha um caso especial que confunde muita gente: rodar a interface de geracao num navegador na mesma maquina que gera. A aba que mostra o preview esta usando a mesma placa que produz a imagem. Fechar abas pesadas ou desligar aceleracao de hardware no navegador durante sessoes longas de geracao libera espaco util.
Outro caso: processos zumbis. Uma execucao anterior que quebrou pode continuar segurando a memoria. Se o monitor mostra a VRAM ocupada mas nenhuma geracao esta rodando, existe um processo pendurado. Encerre o processo do servidor de geracao e suba de novo.
Fragmentacao: por que reiniciar funciona
Aqui fica a explicacao do conselho mais desmoralizado da internet, que e reiniciar. No contexto de VRAM ele tem base tecnica real.
Durante uma sessao longa, voce troca de checkpoint, altera resolucao, liga e desliga extensoes, gera em tamanhos diferentes. Cada mudanca dessas aloca e libera blocos de tamanhos variados. Com o tempo a memoria vira um mosaico de espacos livres pequenos entre blocos ocupados. Somados, sobram muitos gigabytes livres. Contiguos, sobra pouco. Ai a proxima alocacao grande falha mesmo com o monitor mostrando folga.
O sintoma classico e este: a mesma configuracao que gerou dez imagens sem problema comeca a falhar sem que voce tenha mudado nada. Nao mudou mesmo. O que mudou foi o mapa da memoria. Reiniciar o processo devolve um espaco limpo e a mesma configuracao volta a funcionar.
Duas praticas reduzem a frequencia disso. Primeira: use a funcao de liberar memoria da interface entre lotes, se ela existir. Segunda: nao troque de checkpoint dezenas de vezes na mesma sessao. Agrupe o trabalho por modelo, gere tudo daquele modelo, depois troque. Fluxos com muitos nos e trocas dinamicas, como os grafos avancados descritos no tutorial de ComfyUI em portugues, se beneficiam especialmente dessa disciplina de agrupar.
Gerar pequeno e ampliar em blocos
Essa e a tecnica que mais entrega resultado por VRAM gasta, e merece ser o seu fluxo padrao e nao um plano B.
O processo tem tres etapas. Primeiro, gere na resolucao nativa do modelo, com batch size um, ate ter uma composicao que preste. Nao gaste memoria ampliando imagens que voce vai descartar. Segundo, amplie a imagem escolhida com um ampliador dedicado. Terceiro, se quiser detalhe real e nao apenas mais pixels, passe um refinamento de imagem para imagem em blocos, o famoso upscale em tiles, que processa a foto em pedacos e nunca segura a imagem inteira em memoria de uma vez.
Nesse refinamento por blocos, dois controles decidem o resultado. O tamanho do bloco define o pico de memoria: blocos menores cabem em placas menores, blocos maiores mantem mais coerencia interna. Sempre com alguma sobreposicao entre blocos, senao aparecem emendas visiveis. O outro controle e a forca de denoise, e aqui a regra e ser conservador: valores baixos adicionam textura e nitidez preservando a imagem, valores altos fazem cada bloco inventar conteudo proprio e voce termina com um rosto diferente em cada quadrante. Comece baixo e suba pouco a pouco ate achar o ponto.
Uma dica que evita frustracao: refino em blocos com prompt generico funciona melhor que com prompt detalhado. Se o prompt descreve um rosto, cada bloco vai tentar desenhar um rosto, inclusive o bloco que contem so a parede do fundo.
Diagnostico rapido: tabela de sintomas e checklist
Tabela de sintomas
| Sintoma | Causa provavel | Correcao |
|---|---|---|
| Falha logo ao carregar o modelo | Pesos nao cabem na precisao atual | Carregar em fp16 ou usar variante quantizada |
| Falha no ultimo passo, com preview ja visivel | Pico da decodificacao do VAE | Ativar tiling ou slicing de VAE, ou VAE mais leve |
| Falha so em resolucoes altas | Latente e ativacoes escalam com a area | Gerar em tamanho nativo e ampliar em blocos |
| Falha ao gerar varias imagens de uma vez | Batch size acima de um | Batch size um e aumentar a contagem de execucoes |
| Funcionava e parou sem mudar nada | Fragmentacao apos sessao longa | Reiniciar o processo de geracao |
| Monitor mostra VRAM ocupada sem gerar nada | Processo antigo pendurado ou navegador | Encerrar processos e fechar abas pesadas |
| So falha com ControlNet ou refinador ligado | Passes extras somando no mesmo instante | Rodar as etapas separadas e em sequencia |
| Falha em modelo de video mas nao em imagem | Varios quadros de latente simultaneos | Menos quadros por clipe e resolucao menor |
Checklist de diagnostico, do mais rapido ao mais lento
- Olhe o uso atual da GPU antes de gerar. Se ja tem consumo alto com nada rodando, o problema nao e o seu prompt.
- Feche navegador, jogos, launchers e editores. Repita a geracao sem mudar mais nada.
- Confirme o batch size. Coloque em um e teste.
- Volte para a resolucao nativa do modelo. Se funcionar, voce achou a causa.
- Reinicie o processo de geracao para limpar a fragmentacao.
- Ative atencao eficiente e tiling de VAE. Sao ajustes baratos e de alto retorno.
- Confirme que os pesos carregam em meia precisao e nao em precisao completa.
- Desligue extensoes acessorias uma a uma. ControlNet, adaptadores, refinadores.
- Ative o modo de pouca VRAM da sua interface, comecando pelo intermediario.
- Troque por uma variante quantizada do modelo, se existir.
- Divida o fluxo em etapas salvas em disco: gere, salve, feche, amplie em outra execucao.
- So depois de tudo isso, considere alugar GPU na nuvem para esse trabalho especifico.
Quando a placa realmente nao da conta
Existe um ponto em que insistir e desperdicio de tempo. Reconhecer esse ponto e mais util do que qualquer truque.
Se voce precisa treinar um LoRA de qualidade, gerar video em resolucao decente, rodar os modelos de arquitetura maior sem quantizacao agressiva, ou processar lotes grandes com prazo, uma placa de entrada vai brigar contra a fisica. Da para arrancar resultado com offload e tiling, mas a geracao pode passar a levar tantos minutos que o fluxo criativo morre. Trocar dez segundos por varios minutos por imagem nao e vitoria.
Nesse cenario, alugar GPU por hora e a resposta honesta. Custa dinheiro, mas voce paga so pelas horas que usar e nao precisa comprar hardware. O caminho pratico esta no tutorial de RunPod em portugues, que cobre subir o ambiente, transferir seus modelos e desligar a maquina para nao continuar pagando por ociosidade. Para quem treina, o mesmo raciocinio aparece no guia de treinar LoRA em portugues: treinamento castiga a memoria bem mais que inferencia, e resolucao de treino e tamanho de lote sao os mesmos vilaes de sempre.
Geracao de video merece um paragrafo proprio, porque e onde a VRAM some mais rapido. Um clipe curto e uma pilha de quadros de latente vivos ao mesmo tempo, e o custo cresce com a quantidade de quadros e com a resolucao ao mesmo tempo. Numa placa modesta, clipes curtos e pequenos ja consomem tudo. As opcoes que rodam melhor em hardware limitado aparecem no comparativo de geradores de video por IA, incluindo os que rodam na nuvem sem exigir nada da sua maquina.
Ajustes que compensam por interface
Interfaces diferentes expoem os mesmos conceitos com nomes diferentes, o que confunde na hora de seguir tutorial.
Nas interfaces do tipo webui, os modos de pouca VRAM sao ligados por argumento de inicializacao, e existem opcoes separadas para atencao eficiente e para tratamento do VAE. A distribuicao mais otimizada dessa familia costuma ser mais economica em memoria que a original, e o passo a passo esta no guia do Stable Diffusion Forge em portugues. Migrar de uma instalacao antiga para uma dessas ja pode resolver o erro sem tocar em nenhum parametro criativo.
Em ambientes de grafo por nos, o controle e mais fino e mais exigente. Voce define explicitamente quando carregar e descarregar componentes, e um grafo mal montado mantem tres modelos na memoria porque os nos ficaram conectados sem necessidade. A vantagem e que voce consegue montar cadeias sequenciais que jamais teriam todos os modelos vivos ao mesmo tempo, algo que uma interface fechada nao permite.
Ha ainda o caminho de nao usar a sua GPU. Servicos que geram no servidor deles removem a variavel VRAM por completo, ao preco de aceitar as regras e os limites de cada plataforma. As alternativas nesse formato estao mapeadas na lista de geradores realistas por IA, util quando voce so quer o resultado e nao um projeto de infraestrutura.
Erros que parecem falta de memoria e nao sao
Nem toda quebra durante a geracao e um problema de VRAM, e tratar tudo como VRAM leva voce a reduzir resolucao para sempre sem motivo.
Travamento sem mensagem, com o programa fechando sozinho, pode ser falta de RAM de sistema e nao de memoria de video, especialmente com offload agressivo ligado. Reinicializacao de driver no meio da geracao aponta para instabilidade termica ou de alimentacao, nao para alocacao. Lentidao extrema sem erro nenhum geralmente e swap em disco, que e o sistema empurrando dados para o armazenamento porque a RAM acabou.
Vale o diagnostico separado: se o erro so acontece em uma resolucao especifica e sempre no mesmo ponto, e memoria. Se acontece em momentos aleatorios e com configuracoes diferentes, procure temperatura, fonte, driver ou RAM. Consertar a coisa errada e o motivo de tanta gente concluir que precisa trocar de placa quando nao precisa.
Uma ultima checagem que passa despercebida: espaco em disco. Cache de modelos, arquivos temporarios e a propria memoria virtual precisam de disco livre. Um disco cheio produz falhas estranhas durante o carregamento que nada tem a ver com a GPU.
Perguntas frequentes
O erro de CUDA sem memoria significa que minha placa e fraca demais?
Nem sempre. Significa que o pedido de memoria daquele instante nao coube. A mesma placa que falhou pode gerar sem problema em resolucao nativa, com batch um e tiling de VAE ligado. So depois de aplicar essas correcoes voce sabe se o limite e real.
Por que ha memoria livre no monitor e o erro aparece mesmo assim?
Porque a alocacao precisa de um bloco contiguo. A memoria livre pode estar picotada em pedacos pequenos apos uma sessao longa com trocas de modelo e resolucao. Reiniciar o processo reorganiza o espaco e frequentemente resolve.
Qual ajuste devo tentar primeiro?
Reduzir a resolucao para o tamanho nativo do modelo e colocar batch size em um. Sao os dois controles com maior impacto e nenhum custo de instalacao. Se resolver, voce ja sabe que o caminho e gerar pequeno e ampliar depois.
Modo lowvram deixa a imagem pior?
Nao. Offload muda onde os pesos ficam guardados, nao o calculo. A imagem sai igual, so demora mais por causa das transferencias entre memoria do sistema e memoria da placa. Quem muda qualidade e a quantizacao dos pesos, que e outra coisa.
Vale a pena usar pesos quantizados?
Vale quando o modelo nao cabe de outro jeito. A perda costuma ser sutil em geracao de imagem e a diferenca entre rodar e nao rodar e absoluta. Se o modelo ja cabe confortavelmente em meia precisao, nao ha motivo para quantizar.
Por que o erro acontece bem no fim, depois do preview aparecer?
Porque a decodificacao final do VAE e o maior pico do fluxo. Ativar tiling ou slicing de VAE ataca exatamente esse momento e costuma eliminar essa variante do erro sem que voce precise mexer em resolucao.
Fechar o navegador ajuda mesmo?
Ajuda, e mais do que parece. Aceleracao de hardware, videos e abas pesadas reservam memoria de video. Se voce roda a interface de geracao no proprio navegador, ele disputa a placa com o modelo enquanto voce gera.
Quando devo desistir da placa local e alugar GPU na nuvem?
Quando o trabalho exige treino, video mais longo ou modelos grandes sem quantizacao, e cada imagem passou a levar minutos demais mesmo com todas as correcoes aplicadas. Alugar por hora custa dinheiro, mas evita comprar hardware para uma necessidade pontual.
