Kald vLLM og andre OpenAI-kompatible slutpunkter fra n8n

Private modeller hjælper kun, hvis dine automatiseringer kan nå dem. n8ns dokumenterede generelle vej er HTTP Request-noden. Den kan kalde en OpenAI-kompatibel vLLM-server eller en anden installation, der faktisk eksponerer og accepterer POST /v1/chat/completions.

Denne artikel er en driftsvejledning: Sådan forbinder og autentificerer du HTTP-kaldet, fastsætter tidsgrænser ud fra målte svartider for lokal inferens og holder modeltjenesten væk fra netværk, du ikke har tillid til.

Hvis du stadig overvejer, om n8n er det rigtige automatiseringslag, skal du begynde med n8n vs. Zapier vs. Make. Se derefter din første AI-agent i n8n for arbejdsgange med agentegenskaber oven på denne integrationslogik.

Et OpenAI-kompatibelt slutpunkt, der kan nås fra det offentlige internet uden autentificering, fungerer som en åben inferensproxy. Alle, der finder det, kan bruge din GPU-tid. Med vLLM kan en angriber desuden nå inferens- og driftsruter, som --api-key ikke beskytter. Lækage af prompts er en særskilt risiko knyttet til logning og adgangsstyring, ikke en automatisk egenskab ved chatruten. Bind tjenesten til private netværk. Kræv autentificering ved gatewayen. Lav ikke portviderestilling ”bare til en demo”.

Hvad »OpenAI-kompatibel« betyder her

For n8ns formål er kontrakten snæver:

• Base-URL’en peger på serverens rod eller /v1, afhængigt af hvad noden forventer.
• Chat-kald rammer /v1/chat/completions (eller den ækvivalente sti, din node tilføjer).
• Anmodningsteksten har samme form som en chat completion: model, messages, eventuelt temperature, max_tokens og så videre.
• Svaret indeholder valgmuligheder med beskedindhold, som noden kan fortolke.

Du behøver ikke funktionsparitet med alle OpenAI-produktflader. Du har brug for en chat-completion-rute, hvis anmodning, autentificering, model-id og svarformat du har testet fra n8n.

vLLM dokumenterer denne OpenAI-kompatible servertilstand; andre kørselsmiljøer tilbyder lignende grænseflader. Kontrollér ruten med et eksempel på et curl-kald mod din installation, før du tilslutter produktionsarbejdsgange. Grænsefladen er fælles, men ruter, model-id’er, autentificering og svarkompatibilitet kan variere mellem produkter og versioner.

Den dokumenterede n8n-vej: HTTP Request

Den aktuelle officielle n8n-dokumentation beskriver ikke en brugerdefineret base-URL til OpenAI-legitimationsoplysningen eller OpenAI Chat Model-noden. Betragt et sådant felt i en bestemt n8n-version eller fællesskabsnode som versionsspecifikt, indtil du har kontrolleret det. Den dokumenterede generelle vej er HTTP Request-noden, som giver eksplicit kontrol over metode, URL, headere, anmodningstekst, autentificering og nodens indstillinger for genforsøg.

Brug en generel bearer- eller headerlegitimationsoplysning i stedet for at indlejre en hemmelig nøgle i arbejdsgangen. Oplysningen skal indeholde en værdi, som inferenstjenesten eller dens gateway faktisk validerer. En pladsholdernøgle ved et slutpunkt, der kun er tilgængeligt på lokalnettet, er ikke autentificering.

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
}

Erstat modelstrengen med det nøjagtige model-id fra /v1/models. Hvis du bruger NVIDIA NemoClaws lokale vLLM-vej, skal du bruge det id, som den kørende server eller den valgte administrerede profil registrerer. Administreret vLLM er en mulighed på understøttede værter, ikke en universel egenskab ved alle NemoClaw-installationer; almindelig Linux kræver et eksplicit valg af den eksperimentelle udbyder. Opfind ikke et checkpointnavn ud fra hukommelsen.

HTTP Request er også den rette udvej, når en leverandørspecifik AI-node ikke dokumenterer et brugerdefineret slutpunkt.

Autentificering og netværkskontrol, der faktisk holder

Lokalt betyder ikke uautentificeret.

For vLLM er --api-key ikke en sikkerhedsgrænse for hele HTTP-tjenesten. Den officielle sikkerhedsside dokumenterer beskyttede og ubeskyttede grupper af slutpunkter og anbefaler netværksisolering samt en omvendt proxy, når eksponering er nødvendig (vLLM’s sikkerhedsvejledning). En API-nøgle på inferensruter beviser ikke, at alle ruter afviser uautentificeret trafik.

Påkrævet grundniveau: Bind kun vLLM til loopback, et container- eller klyngenetværk eller et privat netværksinterface, som er beskyttet af en firewallregel, der kun tillader proxyen eller n8n-arbejdsbyrden. Placér Caddy, nginx, Traefik eller en tilsvarende kontrolleret gateway foran tjenesten, når mere end én vært skal oprette forbindelse. Afslut TLS dér, hvor forbindelsen ikke allerede går gennem et pålideligt krypteret overlaynetværk, autentificér alle eksponerede ruter, begræns anmodningsfrekvens og -størrelse, og tillad kun de nødvendige ruter. n8n kommunikerer med proxyen; klienter når ikke vLLM direkte.

Brug vLLMs --api-key som et ekstra værn for understøttede inferensslutpunkter, ikke som erstatning for proxy og firewall. Gem alle legitimationsoplysninger i n8ns legitimationslager eller et godkendt hemmelighedslager, ikke som klartekst i arbejdsgangsfelter, der eksporteres til Git.

Gør ikke:

• Bind 0.0.0.0 til en WAN-IP hjemme eller på kontoret ”midlertidigt”.
• Del en tunnel-URL på Slack.
• Genbrug en personlig OpenAI-nøgle som »adgangskode« til en lokal server, der aldrig kontrollerer den. Hvis serveren ignorerer Authorization, er nøglen kun et skueværn.

Prompts, der sendes til et lokalt slutpunkt, forlader stadig n8n-værten og kan blive logget af inferensserveren, proxyen og n8ns kørselshistorik. Lokal drift reducerer en tredjeparts opbevaring i skyen; den fjerner ikke logning, skærmbilleder eller operatøradgang. Klassificér kundetekst som potentielt følsomme oplysninger eller personoplysninger efter jeres politik og gældende lovgivning, og kontrollér derefter opbevarings- og adgangsreglerne.

For bredere integrationshygiejne, herunder afgrænsede legitimationsoplysninger, tjenestekonti og revisionsspor, kan du bruge mønstrene i sikker tilslutning af AI.

Tidsgrænser og langsom inferens

Svartiden for en lokal model varierer kraftigt med model, promptlængde, hardware, samtidige kald og koldstartsstatus. En n8n-nodes effektive tidsgrænse afhænger også af noden og den installerede version. For HTTP Request-noden omfatter den dokumenterede tidsgrænse ventetiden på svarheadere eller begyndelsen af svarteksten; det beviser ikke, at en streamet eller langvarig generering er begrænset fra start til slut. En standardværdi kopieret fra en vejledning kan derfor afbryde en velfungerende opgave eller efterlade et andet lag uden en klar grænse.

Fastlæg tidsgrænserne bevidst:

1. Mål et koldt og et varmt kald med curl fra n8n-værten.
2. Sæt nodens tidsgrænse for det første svar over den målte p95 med en begrundet reserve til belastningsspidser.
3. Afstem grænserne i arbejdsgang, proxy, klient og inferensserver med det samlede tidsbudget for genereringen.
4. Foretræk kortere prompts og lavere max_tokens til klassificering eller routing; reservér lange genereringer til kladdetrin, der kan fortsætte asynkront.

Hvis et trin regelmæssigt tager mere end et par minutter, hører det måske hjemme i en kø med asynkron fortsættelse, ikke i et synkront webhooksvar.

Lav en simpel funktionstest fra netværksnavnerummet for n8n-processen, ikke kun fra din bærbare computer. En n8n-container kan ikke nå localhost på værten, medmindre modelporten er gjort tilgængelig i det netværk. Brug Docker-tjenestens navn, værtens gateway-IP eller en lokalnetadresse, som containeren kan nå.

Tjekliste for en sikker base-URL

Før du markerer legitimationsoplysningen som klar til produktion:

Fejlhåndteringen for et utilgængeligt slutpunkt skal være eksplicit: Prøv igen med stigende ventetid, send opgaven til en menneskelig kø, eller lad kørslen fejle tydeligt. Skift ikke ubemærket til et offentligt API med andre privatlivsvilkår, medmindre den reservevej er dokumenteret og godkendt.

Eksponér aldrig uden adgangskontrol

Reglen er enkel: Eksponér ikke vLLM direkte mod et netværk, du ikke har tillid til. API-nøglen beskytter ikke hele HTTP-tjenesten. Brug netværksisolering, og eksponér kun nødvendige ruter gennem en autentificeret gateway med frekvensbegrænsning.

Forsvarlige mønstre:

• Kun loopback eller Docker-netværk, med n8n på samme vært eller overlaynetværk.
• Lokalnet + firewalltilladelsesliste for proxyen eller n8n-arbejdsbyrdens identitet/IP; kontrollér reglerne fra en afvist vært.
• VPN eller Tailscale/ZeroTier-mesh; ingen tjenester, der lytter på WAN’et.
• Reverse proxy med stærk autentificering, TLS og frekvensbegrænsning, hvis flere betroede klienter skal betjenes.

Uforsvarlige mønstre:

• Uautentificeret binding til WAN’et.
• Demoer med ”autentificering senere” på et rigtigt datasæt.
• Det samme uautentificerede slutpunkt delt med alle bærbare computere på gæste-wi-fi.

Hvis du bygger en privat teknologistak med lokal inferens, n8n-orkestrering og et agenttrin, skal modellens base-URL forblive en intern kontrakt. Hermes og andre kørselsmiljøer kan pege på den samme private tjeneste. Når n8n kalder Hermes, skal du vælge den autentificerede API-server, hvis n8n skal bruge resultatet, eller HMAC-webhookadapteren til indgående hændelser og konfigureret levering fra Hermes. Forskellen behandles i n8n → Hermes: API-kald eller hændelseswebhook.

En minimal privat vej til supportsager

Et illustrativt forløb, du kan implementere uden at opfinde ydelsestal:

1. Et webhook for supportsager rammer n8n.
2. Validér felterne, og fjern følsomme oplysninger.
3. HTTP Request kalder det private /v1/chat/completions-slutpunkt og beder om klassificering som JSON.
4. En Switch-node dirigerer efter mærkat.
5. Udkast, der forlader virksomhedsgrænsen, afventer menneskelig godkendelse (idempotens og menneskelige godkendelser).

Det er nok til at vise, om det lokale slutpunkt fortjener sin plads, før du tilføjer mere avancerede agenter.

Hvad du skal kontrollere på redigeringsdagen

Produktgrænseflader og feltnavne til legitimationsoplysninger ændrer sig. Den dag, du udgiver eller opdaterer denne arbejdsgang:

1. Kontrollér den aktuelle dokumentation for inferensserverens OpenAI-kompatible rute.
2. Kontrollér, at HTTP Request-legitimationsoplysningen og nodekonfigurationen stadig sender den påkrævede autentificering, de rette headere og ubehandlet JSON i korrekt form.
3. Kør curl igen og én n8n-testkørsel med en nyttelast, der ikke stammer fra produktion.
4. Kontrollér, at tjenesten stadig kun lytter privat (ss/lsof, firewallregler og ingen uventet tunnel), at en uautentificeret inferensanmodning fejler, og at vLLMs dokumenterede ubeskyttede slutpunkter ikke kan nås på tværs af den ydre grænse.

Lokale OpenAI-kompatible slutpunkter giver n8n mulighed for at bruge privat inferens uden at omskrive automatiseringsgrafen. Arbejdet handler ikke om smarte prompts. Det handler om at behandle inferens som ethvert andet internt API: autentificeret ved den eksponerede grænse, målt, bevidst logget og utilgængeligt for uvedkommende.