Temos um workflow no n8n cloud que estava funcionando bem até atualizarmos para a versão mais recente. Depois da atualização, começamos a receber erros “n8n may have run out of memory while running this execution”. O workflow chama modelos de IA várias vezes em sequência para gerar conteúdo de aprendizado. Tentamos dividi-lo em sub-workflows menores e processar um item por vez, mas continuamos recebendo o mesmo erro de memória. Este workflow estava funcionando perfeitamente na versão anterior sem nenhuma alteração da nossa parte. Você pode nos ajudar a entender o que mudou com os limites de memória nesta versão e o que podemos fazer para corrigir?
@Prateek_Bhardwaj de qual versão você saiu e para qual? isso determina o que realmente mudou. a razão pela qual dividir não ajudou, porém, é que o n8n mantém os dados de cada item na memória durante toda a execução, então se as saídas da IA ainda forem passadas para baixo ou os sub-workflows retornarem seus dados ao workflow pai, isso se acumula independentemente do agrupamento. você está passando os outputs do modelo adiante, ou está escrevendo-os e removendo-os do fluxo?
Isso parece ser um problema de ciclo de vida dos dados, não apenas um problema de tamanho de lote.
Se cada saída de IA permanece anexada ao item, dividir em sub-workflows ainda pode carregar a mesma carga útil crescente para os passos seguintes, ou devolver a carga útil para a execução pai. O padrão que eu testaria é: escrever cada saída do modelo em algum lugar durável, passar apenas um id/status para o próximo passo e descartar os campos grandes antes de continuar.
Os primeiros casos que eu verificaria são:
- o workflow pai recebe todas as saídas dos workflows filhos
- cada item carrega respostas de modelos anteriores para a próxima chamada de IA
- uma execução falhada tem que ser reproduzida desde a primeira chamada de IA
- retry cria conteúdo gerado duplicado porque não há um id/status de conteúdo estável
Se cada passo lê por id e escreve um status, a memória deixa de depender do histórico completo da execução.
Algumas coisas mudaram nas versões recentes do n8n que afetam o uso de memória para workflows com IA:
1. A saída do nó de IA agora é armazenada nos dados de execução por padrão
Nas versões mais recentes, a saída completa de cada nó de IA (incluindo todo o histórico de mensagens) é salva no registro de execução. Se você tiver várias chamadas de IA em sequência, cada uma acumula o contexto anterior e tudo isso acaba na carga útil de execução na memória simultaneamente. Em cadeias mais longas, isso pode ser 10-50x a pegada de memória das versões antigas.
Correções práticas para tentar na ordem:
A. Dividir em sub-workflows com limpeza de dados de execução
Em vez de chamar nós de IA sequencialmente em um workflow, divida cada etapa de IA em seu próprio sub-workflow acionado via o nó Execute Workflow. Cada execução de sub-workflow obtém seu próprio escopo de memória e é liberada quando termina. Passe apenas os campos específicos que você precisa entre eles, não o item completo.
B. Adicione um nó Set após cada chamada de IA
Extraia apenas os campos que você realmente precisa (por exemplo, apenas a string de texto gerada, não a matriz de mensagem inteira). Isso evita que a saída de IA completa seja transmitida para o próximo contexto de memória do nó.
C. Verifique sua configuração de Memória do nó de IA
Se você estiver usando um nó AI Agent com um sub-nó de Memória (Buffer Memory, Zep, etc.), verifique o contextWindowLength ou o tamanho da sessão. Nas versões mais recentes, o tamanho padrão da janela foi aumentado, o que significa que mais tokens são mantidos na memória por execução.
D. Entre em contato com o suporte do n8n Cloud
Se o workflow estava funcionando em uma versão anterior com lógica idêntica, isso pode ser uma regressão ou uma mudança de limite de memória no nível do plano. O suporte do n8n Cloud pode ver os logs de execução e confirmar se é uma mudança de limite ou um problema de crescimento de memória no próprio workflow. Abrir um ticket de suporte juntamente com essas correções vale a pena.
Parece que isso pode estar relacionado a uma mudança na forma como a memória é gerenciada na versão mais recente, em vez de no seu fluxo de trabalho em si, especialmente porque estava funcionando antes da atualização. Esperamos que a equipe n8n possa confirmar se algo mudou com os limites de memória ou manipulação de execução.
Concordo aqui,
A. Em grandes workflows com múltiplas chamadas LLM, a separação de responsabilidades ajuda de muitas formas e provavelmente resolveria o problema de memória que você está vendo.
construa cada etapa LLM como seu próprio workflow e um orquestrador principal, chamando esses agentes como uma ferramenta
B. Você também pode adicionar um nó set logo após o gatilho para estruturar a saída downstream, em vez de múltiplos após cada chamada LLM
Vale a pena separar duas coisas diferentes aqui: os ajustes acima (sub-workflows, nós Set, trimagem do histórico de mensagens) realmente ajudarão a reduzir o uso de memória, mas na verdade são soluções alternativas para um workflow que costumava ter o tamanho correto e agora não tem, sem nenhuma mudança da sua parte. Antes de fazer uma cirurgia no próprio workflow, eu identificaria exatamente o que mudou entre sua versão antiga e nova (changelog, não apenas “latest”) — se for uma mudança de comportamento padrão (como o nó de IA agora persistindo a saída completa nos dados de execução, como pirateprentice mencionou), vale a pena relatar isso diretamente à n8n como uma regressão, já que caso contrário todos que atualizam enfrentam o mesmo problema com workflows que anteriormente funcionavam bem.