Anropa vLLM och andra OpenAI-kompatibla slutpunkter från n8n

Privata modeller hjälper bara till om dina arbetsflöden kan nå dem. n8n:s verifierade generiska väg är dess HTTP Request-nod. Den kan anropa en OpenAI-kompatibel vLLM-server eller någon annan driftsättning som faktiskt exponerar och accepterar POST /v1/chat/completions.

Den här artikeln är operatörens guide till att koppla och autentisera HTTP-anropet, sätta tidsgränser som motsvarar den uppmätta lokala inferenstiden och hålla modelltjänsten borta från osäkra nätverk.

Om du fortfarande väljer om n8n är rätt automatiseringslager, börja med n8n kontra Zapier och Make. För agentbaserade arbetsflöden ovanpå det flödet, se din första AI-agent i n8n.

En OpenAI-kompatibel slutpunkt som kan nås från internet utan autentisering är en öppen inferensproxy. Den som hittar den kan förbruka GPU-tid. Med vLLM kan en angripare dessutom nå inferens- och driftvägar som --api-key inte skyddar. Läckta prompter är en separat risk som rör loggning och åtkomstkontroll, inte en automatisk egenskap hos chattrutten. Bind tjänsten till privata nätverk. Kräv autentisering vid gatewayen. Vidarebefordra inte en port ”bara för en demo”.

Vad ”OpenAI-kompatibel” betyder här

För n8n:s ändamål är kontraktet smalt:

• Bas-URL:en pekar mot serverroten eller /v1, beroende på vad noden förväntar sig.
• Chattanrop går till /v1/chat/completions eller till motsvarande sökväg som noden lägger till.
• Begärans innehåll har formen för en chat completion: model, messages, valfri temperature, max_tokens och så vidare.
• Svaret innehåller val med meddelandeinnehåll som noden kan tolka.

Du behöver inte funktionsmässig paritet med varje OpenAI-produkt. Du behöver en rutt för chat completions vars begäran, autentisering, modellidentifierare och svarsformat du har testat från n8n.

vLLM dokumenterar detta OpenAI-kompatibla serverläge och andra körmiljöer erbjuder liknande gränssnitt. Kontrollera rutten och ett enkelt curl-anrop mot din installation innan du ansluter produktionsarbetsflöden. Gränssnittet är vanligt, men rutter, modellidentifierare, autentisering och svarskompatibilitet kan skilja sig mellan produkter och versioner.

Den verifierade n8n-vägen: HTTP Request

n8n:s aktuella förstahandsdokumentation anger ingen anpassad bas-URL för OpenAI-autentiseringsuppgiften eller noden OpenAI Chat Model. Behandla ett sådant fält i en viss n8n-version eller nod från användargemenskapen som versionsspecifikt tills du har kontrollerat det. Den dokumenterade generella vägen är noden HTTP Request, som ger tydlig kontroll över metod, URL, HTTP-huvuden, innehåll, autentisering och inställningar för omförsök.

Använd en generell bearer- eller headerbaserad autentiseringsuppgift i stället för att bädda in en hemlighet i arbetsflödet. Autentiseringsuppgiften måste innehålla ett värde som inferenstjänsten eller dess gateway faktiskt validerar. En platshållarnyckel på en slutpunkt som bara nås från det lokala nätverket är inte autentisering.

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
}

Ersätt modellsträngen med den exakta identifieraren som servern returnerar från /v1/models. Om du använder NVIDIA NemoClaws lokala vLLM-väg använder du identifieraren från den körande servern eller den valda hanterade profilen. Hanterad vLLM är ett alternativ på värdar som stöds, inte en allmän egenskap hos varje NemoClaw-installation. En vanlig Linux-installation kräver att en experimentell leverantör väljs uttryckligen. Gissa inte namnet på en modellkontrollpunkt ur minnet.

HTTP Request är också rätt reservväg när en leverantörsspecifik AI-nod inte dokumenterar en anpassad slutpunkt.

Autentisering och nätverkskontroller som faktiskt håller

Lokalt betyder inte oautentiserat.

För vLLM är --api-key inte en säkerhetsgräns för hela HTTP-tjänsten. Den officiella säkerhetssidan dokumenterar skyddade och oskyddade uppsättningar av slutpunkter och rekommenderar nätverksisolering samt en omvänd proxy när exponering är nödvändig (vLLM:s säkerhetsriktlinjer). En API-nyckel på inferensrutter bevisar inte att varje rutt avvisar oautentiserad trafik.

Krävd basnivå: bind vLLM endast till loopback, ett container- eller klusternätverk eller ett privat gränssnitt som skyddas av en brandväggspolicy som bara tillåter proxyn eller n8n-arbetslasten. Placera Caddy, nginx, Traefik eller en motsvarande kontrollerad gateway framför tjänsten när mer än en värd måste ansluta. Terminera TLS där vägen inte redan går genom ett betrott och krypterat overlaynätverk, autentisera varje rutt du exponerar, begränsa anropsfrekvensen och storleken på begäranden och tillåt endast de nödvändiga sökvägarna. n8n kommunicerar med proxyn; klienter når inte vLLM direkt.

Använd vLLM:s --api-key som en ytterligare kontroll för de inferensslutpunkter som stöds, inte som ersättning för proxyn och brandväggen. Lagra alla autentiseringsuppgifter i n8n:s funktion för autentiseringsuppgifter eller i ett godkänt hemlighetslager, inte i vanliga arbetsflödesfält som exporteras till Git.

Gör inte:

• Bind 0.0.0.0 på en hem- eller kontors-WAN-IP ”tillfälligt.”
• Dela en tunnel-URL i Slack.
• Återanvänd en personlig OpenAI-nyckel som ”lösenord” för en lokal server som aldrig kontrollerar den. Om servern ignorerar Authorization är nyckeln bara teater.

Prompter som skickas till en lokal slutpunkt lämnar fortfarande n8n-värden och kan loggas av inferensservern, proxyn och n8n:s körningshistorik. Lokal drift minskar lagringen i tredje parts moln, men tar inte bort loggning, skärmdumpar eller operatörsåtkomst. Klassificera kundtext som potentiellt känslig eller som personuppgifter enligt din policy och tillämplig lag, och kontrollera sedan lagringstid och åtkomst.

För bredare integrationshygien, inklusive avgränsade autentiseringsuppgifter, tjänstekonton och revisionsspår, använder du mönstren i anslut AI på ett säkert sätt.

Tidsgränser och långsam inferens

Svarstiden för en lokal modell varierar kraftigt med modell, promptlängd, hårdvara, samtidighet och kallstart. Den faktiska tidsgränsen för en n8n-nod beror dessutom på noden och den installerade versionen. För noden HTTP Request omfattar den dokumenterade tidsgränsen väntan på HTTP-svarshuvuden eller början av svarets innehåll. Det bevisar inte att en strömmad eller långvarig generering är begränsad från början till slut. Ett standardvärde från en guide kan därför stoppa en fungerande körning eller lämna ett annat lager utan tydlig gräns.

Ange tidsgränser medvetet:

1. Mät ett kallt och varmt anrop med curl från n8n-värden.
2. Sätt nodens tidsgräns för det första svaret över uppmätt p95, med en motiverad marginal för belastningstoppar.
3. Samordna gränserna i arbetsflödet, proxyn, klienten och inferensservern med hela budgeten för genereringen.
4. Föredra kortare prompter och mindre max_tokens för klassificering eller dirigering; reservera långa genereringar för utkaststeg som kan fortsätta asynkront.

Om ett steg regelbundet tar mer än några minuter kan det höra hemma i en kö med asynkron fortsättning, inte i ett synkront webhooksvar.

Grundtesta från n8n-processens nätverksnamnrymd, inte bara från din egen dator. En Dockerbaserad n8n-instans kan inte nå localhost på värddatorn om du inte exponerar modellporten i det nätverket. Använd Docker-tjänstens namn, värddatorns gatewayadress eller en LAN-adress som containern kan nå.

Checklista för en korrekt bas-URL

Innan du markerar autentiseringsuppgiften som klar för produktion:

Felhanteringen för en otillgänglig slutpunkt ska vara tydlig: gör omförsök med ökande väntetid, skicka till en mänsklig kö eller stoppa körningen med ett tydligt fel. Växla inte i tysthet till ett publikt API med andra integritetsegenskaper om inte reservvägen är dokumenterad och godkänd.

Exponera aldrig utan skydd

Regeln är enkel: exponera inte vLLM direkt mot ett otryggt nätverk. Dess API-nyckel skyddar inte hela HTTP-tjänsten. Använd nätverksisolering och exponera endast nödvändiga vägar genom en autentiserad, hastighetsbegränsad gateway.

Acceptabla mönster:

• Endast loopback eller Docker-nätverk, med n8n på samma värddator eller samma överlagrade nätverk.
• LAN + brandväggens tillåtelselista för proxyn eller n8n-arbetslastens identitet eller IP-adress; kontrollera reglerna från en värd som ska nekas.
• VPN eller Tailscale/ZeroTier-meshnät; inga tjänster som lyssnar på WAN.
• Omvänd proxy med stark autentisering, TLS och hastighetsgränser om du måste betjäna flera betrodda klienter.

Oacceptabla mönster:

• Oautentiserad WAN-bindning.
• Demonstrationer med ”autentisering senare” på ett verkligt dataunderlag.
• Att dela samma oautentiserade slutpunkt med alla bärbara datorer på gästnätet.

Om du bygger en privat miljö med lokal inferens, n8n-orkestrering och ett agentsteg ska modellens bas-URL vara ett internt kontrakt. Hermes och andra körmiljöer kan peka på samma privata tjänst. När n8n anropar Hermes väljer du den autentiserade API-servern om n8n behöver resultatet, eller den HMAC-autentiserade webhookadaptern för inkommande händelser och konfigurerad leverans från Hermes. Den uppdelningen beskrivs i n8n → Hermes: API-anrop eller händelsewebhook.

En minimal privat supportväg

Illustrativt flöde du kan implementera utan att hitta på prestandasiffror:

1. En ärendewebhook når n8n.
2. Validera och maskera fälten.
3. HTTP Request anropar den privata /v1/chat/completions-slutpunkten för klassificering i JSON-format.
4. Switch-noden dirigerar efter etikett.
5. Utkast som ska lämna företagets gräns väntar på mänskligt godkännande (idempotens och mänskliga kontrollpunkter).

Det räcker för att visa att den lokala slutpunkten förtjänar sin plats innan du lägger till mer avancerade agenter.

Vad du ska verifiera vid varje ändring

Produktgränssnitt och fältnamn för autentiseringsuppgifter förändras. Den dag du levererar eller uppdaterar det här arbetsflödet:

1. Bekräfta den aktuella dokumentationen för inferensserverns OpenAI-kompatibla rutt.
2. Bekräfta att autentiseringsuppgiften i HTTP Request och nodkonfigurationen fortfarande skickar den nödvändiga autentiseringen, HTTP-huvudena och det råa JSON-formatet.
3. Kör om curl-testet och en n8n-testkörning med en testnyttolast.
4. Bekräfta att tjänsten fortfarande bara lyssnar privat (ss/lsof, brandväggsregler, ingen oväntad tunnel), att ett oautentiserat inferensanrop misslyckas och att vLLM:s dokumenterade oskyddade slutpunkter inte är nåbara över den externa gränsen.

Lokala OpenAI-kompatibla slutpunkter låter n8n använda privat inferens utan att skriva om automatiseringsflödet. Arbetet handlar inte om smart promptformulering. Det handlar om att behandla inferens som vilket annat internt API som helst: autentiserat vid den exponerade gränsen, uppmätt, medvetet loggat och oåtkomligt för obehöriga.