Integracja lokalnych modeli LLM z n8n: jak uruchamiać Ollama i self-hosted AI w automatyzacjach bez zewnętrznego API

Integracja lokalnych modeli LLM z n8n: jak uruchamiać Ollama i self-hosted AI w automatyzacjach bez zewnętrznego API

Lokalne modele LLM pozwalają przetwarzać dane w automatyzacjach AI bez wysyłania ich do chmury. Wystarczy serwer z Ollama, poprawnie skonfigurowany węzeł HTTP Request w n8n i świadomość ograniczeń wydajnościowych. Poniżej opisuję konkretne kroki, które stosuję przy wdrażaniu self-hosted AI w firmowych przepływach.

Kiedy self-hosted AI ma sens zamiast API w chmurze

Wybór lokalnego modelu to przede wszystkim decyzja o kontroli nad danymi. Jeśli automatyzacja przetwarza maile klientów, umowy lub dane medyczne, nawet anonimizacja przed wysyłką do OpenAI czy Claude zwiększa powierzchnię ryzyka. Lokalny LLM eliminuje konieczność przekazywania informacji do zewnętrznego operatora.

Drugi przypadek to przewidywalność kosztów. API LLM w chmurze rozlicza się per token, co przy tysiącach zapytań miesięcznie generuje niestabilne wydatki. Self-hosted AI wymaga jednorazowego nakładu na sprzęt lub wykorzystania istniejącej stacji roboczej, a potem koszt zbliża się do zera.

Jednak nie każdy scenariusz się nadaje. Lokalne modele wymagają odpowiedniej ilości RAM lub karty graficznej. Przy braku GPU czas odpowiedzi na dłuższe prompty może przekraczać 20–30 sekund, co blokuje synchroniczne przepływy n8n. Stosuję lokalne LLM tam, gdzie priorytetem jest prywatność lub stały, wysoki wolumen prostych zadań, a nie błyskawiczna odpowiedź.

Przygotowanie Ollama jako endpointu dla n8n

Zanim skonfiguruję węzeł w n8n, instaluję Ollama na docelowym serwerze i pobieram wybrany model. Przykładowo:

ollama pull llama3
ollama pull mistral

Następnie uruchamiam serwer poleceniem ollama serve. Domyślnie nasłuchuje on na porcie 11434 i adresie lokalnym 127.0.0.1. Jeśli n8n działa na tym samym hoście, wystarczy adres http://localhost:11434. Gdy n8n znajduje się w kontenerze Docker na tej samej maszynie, używam http://host.docker.internal:11434. Dla osobnych maszyn w sieci lokalnej podaję wewnętrzny IP serwera z Ollamą.

Reguła weryfikacji: przed pierwszym uruchomieniem przepływu w n8n wykonuję z poziomu hosta n8n komendę:

curl http://<adres>:11434/api/tags

Jeśli nie otrzymam listy dostępnych modeli w odpowiedzi JSON, węzeł HTTP Request również zakończy się błędem. Naprawiam połączenie sieciowe lub firewall, zanim przejdę dalej.

Konfiguracja węzła HTTP Request w n8n

W n8n nie ma dedykowanego węzła Ollama, ale węzeł HTTP Request w pełni wystarcza. Tworzę go z następującymi parametrami:

• Method: POST
• URL: http://<adres>:11434/api/generate (dla pojedynczych promptów) lub /api/chat (dla konwersacji z kontekstem)
• Authentication: No Auth (jeśli Ollama działa w zamkniętej sieci) lub Basic Auth przez reverse proxy
• Body Content Type: JSON

Dla prostych zadań automatyzacji, takich jak klasyfikacja tekstu czy ekstrakcja danych, używam /api/generate z payloadem:

{
  "model": "llama3",
  "prompt": "Wyciągnij datę i kwotę z tekstu: {{ $json.text }}",
  "stream": false
}

Ollama zwraca wtedy JSON z polem response, które mapuję w kolejnym węźle.

Gdy buduję asystenta z pamięcią rozmowy, wybieram /api/chat i formatuję body:

{
  "model": "llama3",
  "messages": [
    {"role": "system", "content": "Jesteś asystentem księgowym."},
    {"role": "user", "content": "{{ $json.question }}"}
  ],
  "stream": false
}

W tym przypadku odpowiedź znajduje się w message.content. Decyzja techniczna: używam /api/generate tylko dla jednorazowych, bezstanowych operacji. Dla wieloetapowych interakcji zawsze przechodzę na /api/chat, aby model poprawnie interpretował role systemowe i użytkownika.

Formatowanie promptów dla lokalnych modeli

Lokalne modele, zwłaszcza w wersjach 7B–8B parametrów, są bardziej wrażliwe na formę instrukcji niż największe komercyjne API. Zanim przeniosę prompt do n8n, testuję go bezpośrednio w terminalu przez ollama run llama3. Jeśli model w CLI daje poprawną odpowiedź, ale w n8n zwraca niepoprawny wynik, sprawdzam, czy nie przekazuję niechcianych znaków formatujących lub cudzysłowów.

Przy użyciu /api/generate Ollama nie dodaje automatycznie szablonu rozmowy – muszę samodzielnie dołączyć tagi specyficzne dla modelu, jeśli wymaga tego architektura. Przy /api/chat Ollama aplikuje wewnętrzny szablon konwersacji automatycznie, co zmniejsza ryzyko błędów.

Przykład weryfikacji: jeśli model zwraca pustą odpowiedź lub powtarza prompt, zwiększam parametr temperature do 0.7 i dodaję wyraźną instrukcję w języku polskim lub angielskim, w zależności od tego, na jakim języku model był trenowany. Nie zakładam, że lokalny model zrozumie kontekst biznesowy bez jasnego opisu zadania.

Ograniczenia wydajnościowe i jak je łagodzić w przepływie

Największym wyzwaniem przy lokalnych LLM w n8n jest czas odpowiedzi. Na procesorze bez wsparcia GPU generowanie 500-tokenowej odpowiedzi może trwać kilkadziesiąt sekund. Standardowy timeout węzła HTTP Request w n8n wynosi 60 sekund – w niektórych przypadkach muszę go zwiększyć w ustawieniach węzła.

Jeśli przepływ wymaga obsługi wielu zapytań jednocześnie, Ollama domyślnie kolejkuje je sekwencyjnie. Wysłanie dziesięciu równoległych żądań z n8n nie przyspieszy przetwarzania, a może przepełnić pamięć. Stosuję wtedy węzeł Split In Batches z rozmiarem partii równym 1 lub dodaję węzeł Wait z opóźnieniem między zapytaniami.

Decyzja infrastrukturalna: dla środowisk produkcyjnych z wysokim ruchem nie polegam na CPU. Wdrażam Ollama na serwerze z kartą NVIDIA i włączonym CUDA, co skraca czas odpowiedzi do 2–5 sekund. Jeśli budżet nie pozwala na GPU, ograniczam zadania do krótkich podsumowań tekstu poniżej 200 słów i akceptuję dłuższe oczekiwanie.

Bezpieczeństwo endpointu lokalnego

Ollama domyślnie nie wymaga klucza API i nie posiada wbudowanego HTTPS. Gdy muszę udostępnić port 11434 poza localhost, stawiam przed nim reverse proxy (np. Nginx lub Traefik) z ograniczeniem dostępu do adresów IP sieci wewnętrznej. Nie wystawiam bezpośredniego endpointu Ollamy na publiczny internet.

W n8n nie zapisuję adresu IP Ollamy wprost w polu URL węzła, jeśli planuję przenosić przepływ między środowiskami. Zamiast tego używam zmiennych środowiskowych n8n, np. ${OLLAMA_BASE_URL}, co ułatwia migrację z maszyny deweloperskiej na produkcyjną.

Reguła weryfikacji: przed wdrożeniem sprawdzam z poziomu serwera, które adresy mają dostęp do portu 11434. Jeśli netstat lub ss pokazuje nasłuchiwanie na 0.0.0.0:11434, a nie powinien – natychmiast poprawiam konfigurację firewalla.

Checklist wdrożeniowa

Przed uruchomieniem automatyzacji na produkcję weryfikuję:

1. Połączenie sieciowe: curl z hosta n8n zwraca listę modeli bez błędów.
2. Wybór endpointu: używam /api/chat dla konwersacji i /api/generate dla pojedynczych zadań.
3. Jakość promptu: ten sam prompt testowany w CLI daje powtarzalny, poprawny wynik.
4. Timeout: węzeł HTTP Request ma ustawiony limit czasu powyżej szacunkowego czasu generowania na danym sprzęcie.
5. Ograniczenie równoległości: przepływ nie wysyła dziesiątek zapytań jednocześnie bez kolejkowania.
6. Dostępność zasobów: serwer ma wolne minimum 8–16 GB RAM (w zależności od modelu) i nie dzieli zasobów z innymi ciężkimi usługami w godzinach szczytu.
7. Sieć: endpoint Ollamy dostępny tylko z wewnętrznych adresów IP lub przez VPN.

Lokalne modele LLM w połączeniu z n8n dają pełną autonomię w przetwarzaniu danych przez AI. Wymagają jednak bardziej świadomego podejścia do infrastruktury niż gotowe API w chmurze. Jeśli rozważasz wdrożenie self-hosted AI w swojej firmie i nie wiesz, jak dobrać model czy zaplanować architekturę połączenia z istniejącymi automatyzacjami – pomagam w projektowaniu i wdrażaniu takich rozwiązań. Tworzę dedykowane przepływy n8n, w których dane pozostają pod pełną kontrolą, a automatyzacje realizują konkretne zadania biznesowe bez zbędnego ryzyka wycieku informacji.