Nous avons un workflow sur n8n cloud qui fonctionnait correctement jusqu’à ce que nous mettions à jour vers la dernière version. Après la mise à jour, nous avons commencé à recevoir des erreurs « n8n may have run out of memory while running this execution ». Le workflow appelle des modèles d’IA plusieurs fois de suite pour générer du contenu pédagogique. Nous avons essayé de le diviser en sous-workflows plus petits et de traiter un élément à la fois, mais nous recevons toujours la même erreur de mémoire. Ce workflow fonctionnait parfaitement sur la version précédente sans aucun changement de notre côté. Pouvez-vous nous aider à comprendre ce qui a changé concernant les limites de mémoire dans cette version et ce que nous pouvons faire pour résoudre le problème ?
@Prateek_Bhardwaj quelle version as-tu utilisée et vers quelle version as-tu migré ? c’est ce qui détermine ce qui a réellement changé. la raison pour laquelle le split n’a pas aidé, c’est que n8n conserve les données de chaque item en mémoire pendant toute l’exécution, donc si les sorties de l’IA sont toujours transmises en aval ou si les sous-workflows renvoient leurs données au workflow parent, ça s’accumule indépendamment du batching. tu transmets les sorties du modèle en aval, ou tu les écris et tu les supprimes du flux ?
Cela semble être un problème de durée de vie des données, pas seulement un problème de taille de lot.
Si chaque résultat d’IA reste attaché à l’élément, la division en sous-workflows peut toujours transporter la même charge utile croissante en aval, ou renvoyer la charge utile à l’exécution parent. Le pattern que je testerais serait : écrire chaque résultat de modèle quelque part de manière durable, passer uniquement un id/statut à l’étape suivante, et supprimer les grands champs avant de continuer.
Les premiers cas que je vérifierais sont :
- le workflow parent reçoit toutes les sorties enfants en retour
- chaque élément porte les réponses du modèle précédent dans l’appel IA suivant
- une exécution échouée doit être rejouée depuis le premier appel IA
- la tentative crée un contenu généré en double parce qu’il n’y a pas d’id/statut de contenu stable
Si chaque étape lit par id et écrit un statut, la mémoire cesse de dépendre de l’historique complet de l’exécution.
Quelques éléments ont changé dans les récentes versions de n8n et affectent l’utilisation de la mémoire pour les workflows lourds en IA :
1. La sortie des nœuds IA est désormais stockée dans les données d’exécution par défaut
Dans les versions plus récentes, la sortie complète de chaque nœud IA (y compris l’historique complet des messages) est enregistrée dans le registre d’exécution. Si vous avez plusieurs appels IA en séquence, chacun accumule le contexte antérieur et tout cela se retrouve dans la charge utile d’exécution en mémoire simultanément. Sur les chaînes plus longues, cela peut représenter 10 à 50 fois l’empreinte mémoire des versions antérieures.
Correctifs pratiques à essayer dans l’ordre :
A. Diviser en sous-workflows avec élagage des données d’exécution
Au lieu d’appeler les nœuds IA séquentiellement dans un seul workflow, divisez chaque étape IA en son propre sous-workflow déclenché via le nœud Execute Workflow. Chaque exécution de sous-workflow obtient sa propre portée de mémoire et est libérée quand elle se termine. Transmettez uniquement les champs spécifiques dont vous avez besoin entre eux, et non l’élément complet.
B. Ajouter un nœud Set après chaque appel IA
Extraquez uniquement les champs dont vous avez réellement besoin (par exemple, seulement la chaîne de texte générée, pas l’ensemble du tableau de messages). Cela empêche la sortie complète de l’IA d’être transmise au contexte de mémoire du nœud suivant.
C. Vérifiez le paramètre Memory de votre nœud IA
Si vous utilisez un nœud AI Agent avec un sous-nœud Memory (Buffer Memory, Zep, etc.), vérifiez contextWindowLength ou la taille de session. Dans les versions plus récentes, la taille de la fenêtre par défaut a été augmentée, ce qui signifie que plus de tokens sont conservés en mémoire par exécution.
D. Contactez le support n8n Cloud
Si le workflow fonctionnait sur une version antérieure avec une logique identique, il pourrait s’agir d’une régression ou d’une modification du plafond de mémoire au niveau du plan. Le support n8n Cloud peut consulter les journaux d’exécution et confirmer s’il s’agit d’une modification des limites ou d’un problème de croissance de la mémoire dans le workflow lui-même. Ouvrir un ticket de support en parallèle de ces correctifs en vaut la peine.
Cela semble pouvoir être lié à un changement dans la façon dont la mémoire est gérée dans la dernière version plutôt qu’à votre workflow lui-même, d’autant plus qu’il fonctionnait avant la mise à jour. Espérons que l’équipe n8n pourra confirmer si quelque chose a changé concernant les limites de mémoire ou la gestion de l’exécution.
Je suis d’accord ici,
A. Dans les workflows d’appels LLM multiples volumineux, la séparation des préoccupations aide de bien des façons et elle résoudrait probablement le problème de mémoire que vous rencontrez.
construisez chaque étape LLM comme son propre workflow et un orchestrateur principal, en appelant ces agents comme un appel d’outil
B. Vous pouvez également ajouter un nœud set juste après le déclencheur pour structurer la sortie en aval, au lieu de plusieurs après chaque appel LLM
Il est important de distinguer deux choses différentes ici : les corrections ci-dessus (sous-workflows, nœuds Set, suppression de l’historique des messages) vont vraiment aider à réduire l’empreinte mémoire, mais ce sont vraiment des contournements pour un workflow qui était correctement dimensionné et qui ne l’est plus, sans aucun changement de votre côté. Avant de faire une intervention chirurgicale sur le workflow lui-même, je vous conseille d’identifier précisément ce qui a changé entre votre ancienne et votre nouvelle version (changelog, pas juste « dernière version ») — si c’est un changement de comportement par défaut (comme le nœud IA qui persiste maintenant la sortie complète aux données d’exécution, comme l’a mentionné pirateprentice), cela vaut la peine de le signaler directement à n8n comme une régression, car sinon tout le monde qui met à jour se heurte au même problème avec des workflows qui fonctionnaient correctement avant.