Ich versuche herauszufinden, warum ein Information Extractor-Knoten bei einer einzelnen Ausführung für eine einzelne Eingabe 10+ Aufrufe an ein LLM tätigt – das Problem ist, dass er die 10-fache Anzahl der benötigten Token verwendet.
Ich verwende einen Information Extractor-Knoten mit Google Gemini 2.5 Flash. Ich verwende einen ziemlich großen Prompt und übergebe viel Text als Inhalt zur Analyse (25.000+ Token für Prompt und Inhalt). Der Information Extractor-Knoten ist mit einem JSON-Schema konfiguriert.
In 99%+ der Fälle funktioniert dies perfekt. Heute habe ich 524-Fehlermeldungen als Pop-ups in der Benutzeroberfläche erhalten, und der Extractor-Knoten ruft den Gemini-Subknoten 10+ Mal auf, wodurch die Gesamtzahl der Token von 35.000 auf über 500.000 steigt.
Ich habe Wiederholungen deaktiviert und „Bei Fehler fortfahren
@am4c130d diese 524 ist ein Gateway-Timeout, Gemini hat heute einfach nicht rechtzeitig geantwortet, und die 10+ Aufrufe sind Wiederholungsversuche, die unter der Node-Level-Wiederholung abgefeuert werden, die du deaktiviert hast, sie befinden sich auf der Modellebene. Kannst du die Optionen auf deinem Gemini Chat Model-Subnode überprüfen, auf wie viel sind dort die maximalen Wiederholungsversuche eingestellt?
@am4c130d ja, das ist der Haken: n8n stellt die maxRetries des Modells nicht zur Verfügung, sodass du diese vom Node aus nicht begrenzen kannst – das sind Langchains interne Wiederholungen, die beim Timeout ausgelöst werden. Der Hebel, den du tatsächlich hast, ist der 524 selbst – ein Gateway-Timeout, der auslöst, wenn ein Aufruf zu lange läuft (um die 100s), und deine 25k-Token-Anfrage ist langsam genug, um ihn zu treffen, während Gemini heute träge ist. Falls möglich, teile den Inhalt in kleinere Durchläufe auf, damit jeder Aufruf deutlich unter diesem Limit abgeschlossen wird – kein Timeout bedeutet keine Retry-Kaskade und keinen 10x-Verbrauch. Falls es wirklich die vollständigen 25k in einem Durchgang braucht, ist die andere Route, Gemini über einen HTTP Request-Node aufzurufen, wo du Timeout und Wiederholungen selbst kontrollierst, und dann danach das JSON zu parsen.
Danke, das stimmt mit dem überein, was ich auch lese – ich werde mir den HTTP-Node ansehen, da das wahrscheinlich einfacher ist, als meine Anfrage aufzuteilen.
Danke – ich werde deine Antwort als Lösung markieren, da es die praktische Antwort ist.
Die 524 löst eine LangChain-Wiederholungskaskade aus - das ist die Grundursache, die achamm beschrieben hat. Eine zusätzliche Lösung speziell für selbst gehostetes n8n: Setzen Sie die Umgebungsvariable N8N_DEFAULT_HTTP_TIMEOUT auf einen höheren Wert (Standard ist 300000ms / 5 Min.). Wenn Ihr Reverse Proxy oder CDN ein kürzeres Timeout hat als Ihr Gemini-Aufruf dauert, wird die 524 ausgelöst, bevor n8n abgeschlossen werden kann, was Wiederholungen auslöst, bevor der erste Aufruf tatsächlich fehlgeschlagen ist. Es lohnt sich auch zu überprüfen: Wenn Sie Cloudflare nutzen, beträgt sein Standard-Gateway-Timeout 100 Sekunden, was bei ausgelasteten Tagen zu 25K-Token-Gemini-2.5-Flash-Aufrufen führen kann.
Danke – ich nutze n8n Cloud, daher wählt n8n den Proxy etc. aus. Abgesehen von Self-Host, wobei ich ein lokales Modell nutzen würde, werde ich der Lösung von @achamm folgen.