Private Modelle sind nur dann hilfreich, wenn Ihre Automatisierungen sie erreichen können. Der dokumentierte allgemeine Weg in n8n ist der HTTP Request-Node. Er kann einen OpenAI-kompatiblen vLLM-Server oder eine andere Bereitstellung aufrufen, die POST /v1/chat/completions tatsächlich bereitstellt und annimmt.
Dieser Betriebsleitfaden zeigt, wie Sie den HTTP-Aufruf konfigurieren, authentifizieren und mit Zeitlimits versehen, die auf Messungen der lokalen Inferenz beruhen. Außerdem bleibt der Modelldienst von nicht vertrauenswürdigen Netzwerken getrennt.
Wenn Sie noch prüfen, ob n8n die richtige Automatisierungsschicht ist, beginnen Sie mit n8n im Vergleich zu Zapier und Make. Für agentenbasierte Workflows auf dieser Grundlage lesen Sie Ihr erster KI-Agent in n8n.
Ein OpenAI-kompatibler Endpunkt, der aus dem öffentlichen Internet ohne Authentifizierung erreichbar ist, dient als offener Inferenz-Proxy. Jeder, der ihn findet, kann GPU-Zeit verbrauchen. Bei vLLM können Angreifer möglicherweise auch Inferenz- und Betriebsrouten erreichen, die
--api-keynicht schützt. Das Offenlegen von Prompts ist ein eigenes Risiko der Protokollierung und Zugriffskontrolle, keine automatische Eigenschaft der Chat-Route. Binden Sie den Dienst an private Netzwerke, verlangen Sie Authentifizierung am Gateway und richten Sie nicht „nur für eine Demo“ eine Portweiterleitung ein.
Was „OpenAI-kompatibel“ hier bedeutet
Für n8n-Zwecke ist der Vertrag eng gefasst:
- Die Basis-URL verweist auf die Serverwurzel oder auf
/v1, je nachdem, was der Node erwartet. - Chat-Aufrufe werden an
/v1/chat/completionsgesendet oder an den entsprechenden Pfad, den Ihr Node anhängt. - Der Anfragekörper entspricht einer Chat Completion und enthält
model,messagessowie optionaltemperature,max_tokensund weitere Felder. - Die Antwort enthält
choicesmit Nachrichteninhalt, den der Node auswerten kann.
Sie benötigen keine Funktionsgleichheit mit jeder OpenAI-Produktoberfläche. Entscheidend ist eine Chat-Completion-Route, deren Anfrage, Authentifizierung, Modellkennung und Antwortstruktur Sie aus n8n heraus getestet haben.
vLLM dokumentiert diesen OpenAI-kompatiblen Servermodus; andere Laufzeitumgebungen bieten ähnliche Schnittstellen an. Prüfen Sie die Route und einen beispielhaften curl-Aufruf gegen Ihre Installation, bevor Sie Produktiv-Workflows anschließen. Die Schnittstelle ist verbreitet, doch Routen, Modellkennungen, Authentifizierung und Antwortkompatibilität können sich je nach Produkt und Version unterscheiden.
Der dokumentierte n8n-Weg: HTTP Request
Die aktuelle offizielle n8n-Dokumentation weist weder für die OpenAI-Zugangsdaten noch für den OpenAI Chat Model-Node eine benutzerdefinierte Basis-URL nach. Behandeln Sie ein solches Feld in einer bestimmten n8n-Version oder einem Community-Node als versionsspezifisch, bis Sie es selbst geprüft haben. Der dokumentierte allgemeine Weg ist der HTTP Request-Node. Er gibt Ihnen ausdrückliche Kontrolle über Methode, URL, Header, Anfragekörper, Authentifizierung und die Einstellungen für Wiederholungsversuche.
Verwenden Sie generische Bearer- oder Header-Zugangsdaten, statt ein Geheimnis direkt in den Workflow einzutragen. Die Zugangsdaten müssen einen Wert enthalten, den der Inferenzdienst oder sein Gateway tatsächlich prüft. Ein Platzhalterschlüssel an einem nur im LAN erreichbaren Endpunkt ist keine Authentifizierung.
POST http://10.0.0.20:8000/v1/chat/completions
Content-Type: application/json
Authorization: Bearer <secret>
{
"model": "installer-recommended-local-model",
"messages": [
{ "role": "system", "content": "Classify the ticket. Reply with JSON only." },
{ "role": "user", "content": "{{ $json.body }}" }
],
"temperature": 0
}
Ersetzen Sie die Modellzeichenfolge durch die exakte Kennung, die /v1/models meldet. Wenn Sie den lokalen vLLM-Pfad von NVIDIA NemoClaw verwenden, übernehmen Sie die Kennung des laufenden Servers oder des gewählten verwalteten Profils. Verwaltetes vLLM ist eine Option auf unterstützten Hosts, keine allgemeine Eigenschaft jeder NemoClaw-Installation; unter generischem Linux muss ein experimenteller Modus oder Anbieter ausdrücklich ausgewählt werden. Erfinden Sie keinen Checkpoint-Namen aus dem Gedächtnis.
HTTP Request ist auch die richtige Ausweichlösung, wenn ein herstellerspezifischer KI-Node keinen benutzerdefinierten Endpunkt dokumentiert.
Belastbare Authentifizierung und Netzwerkkontrollen
Lokal bedeutet nicht ohne Authentifizierung.
Bei vLLM bildet --api-key keine Sicherheitsgrenze für den gesamten HTTP-Dienst. Die offizielle Sicherheitsseite dokumentiert geschützte und ungeschützte Gruppen von Endpunkten und empfiehlt Netzwerkisolation sowie einen Reverse Proxy, wenn Zugriff von außen erforderlich ist (vLLM-Sicherheitshinweise). Ein API-Schlüssel für Inferenzrouten belegt nicht, dass jede Route nicht authentifizierte Anfragen ablehnt.
Erforderliche Grundlage: Binden Sie vLLM nur an Loopback, ein Container- oder Cluster-Netzwerk oder eine private Schnittstelle. Eine Firewall-Regel darf ausschließlich dem Proxy oder der n8n-Workload Zugriff geben. Schalten Sie Caddy, nginx, Traefik oder ein gleichwertiges kontrolliertes Gateway vor, wenn mehrere Hosts zugreifen müssen. Terminieren Sie TLS, sofern der Pfad nicht bereits über ein vertrauenswürdiges verschlüsseltes Overlay läuft. Authentifizieren Sie jede freigegebene Route, begrenzen Sie Anfragerate und Anfragegröße und erlauben Sie nur die benötigten Pfade. n8n kommuniziert mit dem Proxy; Clients erreichen vLLM nicht direkt.
Verwenden Sie --api-key von vLLM als zusätzliche Kontrolle für unterstützte Inferenz-Endpunkte, nicht als Ersatz für Proxy und Firewall. Speichern Sie alle Zugangsdaten in n8n Credentials oder einem genehmigten Secretspeicher, nicht in unverschlüsselten Workflow-Feldern, die nach Git exportiert werden.
Nicht tun:
0.0.0.0„vorübergehend“ an eine WAN-IP zu Hause oder im Büro binden.- Eine Tunnel-URL in Slack teilen.
- Einen persönlichen OpenAI-Schlüssel als „Passwort“ für einen lokalen Server wiederverwenden, der ihn nicht prüft. Ignoriert der Server
Authorization, ist der Schlüssel wirkungslos.
An einen lokalen Endpunkt gesendete Prompts verlassen weiterhin den n8n-Host und können vom Inferenzserver, vom Proxy und in der n8n-Ausführungshistorie protokolliert werden. Lokales Hosting verringert die Speicherung durch externe Cloud-Anbieter, beseitigt aber weder Protokollierung und Screenshots noch den Zugriff durch Betriebspersonal. Behandeln Sie Kundentexte gemäß Ihren Richtlinien und dem geltenden Recht als potenziell vertrauliche oder personenbezogene Daten und prüfen Sie Aufbewahrungsfristen und Zugriffsrechte.
Für eine umfassendere Integrationshygiene mit eng begrenzten Zugangsdaten, Dienstkonten und Audit-Trails verwenden Sie die Muster aus KI sicher anbinden.
Timeouts und langsame Inferenz
Die Latenz lokaler Modelle schwankt stark mit Modell, Prompt-Länge, Hardware, Parallelität und Kaltstart. Das wirksame Zeitlimit eines n8n-Nodes hängt außerdem vom Node und der installierten Version ab. Beim HTTP Request-Node umfasst das dokumentierte Zeitlimit das Warten auf die Antwort-Header oder den Beginn des Antwortkörpers. Es belegt nicht, dass eine gestreamte oder lang laufende Generierung durchgängig begrenzt ist. Ein aus einem Tutorial übernommener Standardwert kann daher einen intakten Auftrag abbrechen oder eine andere Schicht ohne eindeutige Obergrenze lassen.
Legen Sie Timeouts bewusst fest:
- Messen Sie einen Aufruf im kalten und warmen Zustand mit curl vom n8n-Host aus.
- Legen Sie das Zeitlimit des Nodes für die erste Antwort oberhalb des gemessenen p95 fest und begründen Sie den Puffer für Lastspitzen.
- Stimmen Sie die Grenzen von Workflow, Proxy, Client und Inferenzserver auf das gesamte Zeitbudget der Generierung ab.
- Bevorzugen Sie kürzere Prompts und kleinere
max_tokensfür Klassifizierung oder Routing; reservieren Sie lange Generierungen für Entwurfsschritte, die asynchron fortgesetzt werden können.
Wenn ein Schritt routinemäßig einige Minuten überschreitet, gehört dieser Schritt möglicherweise in eine Warteschlange mit asynchroner Fortsetzung, nicht in eine synchrone Webhook-Antwort.
Führen Sie den Smoke-Test aus dem Netzwerk-Namespace des n8n-Prozesses aus, nicht nur von Ihrem Laptop. n8n in Docker erreicht
localhostdes Hosts nur, wenn der Modellport in dieses Netzwerk veröffentlicht wurde. Verwenden Sie den Docker-Dienstnamen, die Host-Gateway-IP oder eine LAN-Adresse, die der Container erreichen kann.
Checkliste für eine saubere Basis-URL
Bevor Sie die Zugangsdaten als produktionsreif einstufen:
| Prüfung | Bestehensbedingung |
|---|---|
| Erreichbarkeit | Die n8n-Laufzeit erreicht die dokumentierte Zustandsroute und den authentifizierten Endpunkt /v1/models, ohne das private Netzwerk zu verlassen |
| Pfad | /v1/chat/completions gelingt mit einer winzigen Nutzlast |
| Auth | Unauthentifizierte Inferenz wird abgelehnt; keine ungeschützte vLLM-Route ist außerhalb der vorgesehenen privaten Grenze erreichbar |
| Modell-ID | Exakte Zeichenfolge stimmt mit der vom Server ausgegebenen Kennung überein |
| TLS | Erforderlich, wenn der Pfad durch nicht vertrauenswürdige Netzwerke führt |
| Protokollierung | Prompt- und Antwortprotokollierung ist beabsichtigt und zeitlich begrenzt |
| Ausfall | Der Workflow verhält sich eindeutig, wenn der Endpunkt nicht verfügbar ist |
| Zeitlimit | Grenzen für die erste Antwort und den gesamten Ablauf beruhen auf Messungen aus der n8n-Laufzeit |
Das Verhalten bei einem ausgefallenen Endpunkt muss eindeutig sein: Wiederholungsversuch mit Backoff, Weiterleitung an eine menschliche Warteschlange oder klarer Abbruch des Laufs. Wechseln Sie nicht unbemerkt zu einer öffentlichen API mit anderen Datenschutzbedingungen, sofern dieser Fallback nicht dokumentiert und genehmigt ist.
Niemals ohne vorgeschaltete Schutzschicht freigeben
Die Regel ist einfach: Geben Sie vLLM niemals direkt in einem nicht vertrauenswürdigen Netzwerk frei. Der API-Schlüssel schützt nicht den gesamten HTTP-Dienst. Isolieren Sie das Netzwerk und stellen Sie nur die erforderlichen Pfade über ein authentifiziertes Gateway mit Ratenbegrenzung bereit.
Akzeptable Muster:
- Nur Loopback oder Docker-Netzwerk, n8n auf demselben Host oder Overlay.
- LAN mit Firewall-Allowlist für die Identität oder IP des Proxys beziehungsweise der n8n-Workload; prüfen Sie die Regeln von einem nicht zugelassenen Host aus.
- VPN oder Tailscale/ZeroTier-Mesh ohne WAN-Listener.
- Reverse Proxy mit starker Authentifizierung, TLS und Ratenbegrenzung, wenn mehrere vertrauenswürdige Clients zugreifen müssen.
Inakzeptable Muster:
- Unauthentifizierte WAN-Bindung.
- Demos nach dem Motto „Authentifizierung später“ mit echten Daten.
- Denselben unauthentifizierten Endpunkt mit jedem Laptop im Gast-WLAN teilen.
Wenn Sie einen privaten Stack aus lokaler Inferenz, n8n-Orchestrierung und einem Agentenschritt aufbauen, behandeln Sie die Basis-URL des Modells als internen Vertrag. Hermes und andere Laufzeitumgebungen können denselben privaten Dienst nutzen. Ruft n8n Hermes auf, verwenden Sie den authentifizierten API-Server, wenn n8n das Ergebnis benötigt. Für Ereigniseingang und eine konfigurierte Zustellung durch Hermes verwenden Sie dagegen den HMAC-Webhook-Adapter. Diese Trennung erläutert n8n → Hermes: API-Aufruf oder Ereignis-Webhook.
Ein minimaler privater Support-Pfad
Ein beispielhafter Ablauf, den Sie ohne erfundene Leistungswerte umsetzen können:
- Ein Ticket-Webhook erreicht n8n.
- Felder validieren und vertrauliche Angaben entfernen.
- HTTP Request ruft den privaten
/v1/chat/completions-Endpunkt für Klassifizierungs-JSON auf. - Ein Switch-Node verzweigt anhand des Labels.
- Entwürfe, die die Unternehmensgrenze verlassen, warten auf eine menschliche Freigabe.
Das reicht aus, um zu prüfen, ob der lokale Endpunkt seinen Platz rechtfertigt, bevor Sie komplexere Agenten ergänzen.
Was Sie am Tag der Bereitstellung prüfen sollten
Produktoberflächen und Feldnamen für Zugangsdaten ändern sich. Prüfen Sie deshalb am Tag der Bereitstellung oder Aktualisierung:
- Bestätigen Sie die Live-Dokumentation für die OpenAI-kompatible Route Ihres Inferenz-Servers.
- Prüfen Sie, ob die HTTP Request-Zugangsdaten und die Node-Konfiguration weiterhin die erforderliche Authentifizierung, die Header und die unveränderte JSON-Struktur senden.
- Führen Sie curl und eine n8n-Testausführung mit einer nicht produktiven Nutzlast erneut aus.
- Prüfen Sie, ob der Listener weiterhin privat ist (
ss/lsof, Firewall-Regeln, kein unerwarteter Tunnel), ob eine nicht authentifizierte Inferenzanfrage fehlschlägt und ob die dokumentierten ungeschützten vLLM-Endpunkte jenseits der externen Grenze unerreichbar sind.
Lokale OpenAI-kompatible Endpunkte ermöglichen n8n private Inferenz, ohne den Automatisierungsablauf neu zu schreiben. Entscheidend ist nicht besonders cleveres Prompting. Behandeln Sie Inferenz wie jede andere interne API: Authentifizierung an der freigegebenen Grenze, gemessene Zeitlimits, bewusst gewählte Protokollierung und kein Zugriff für Unbefugte.
