Self-hosted LLM w małej firmie: minimalny stack (RAG), koszty, ryzyka i dobre praktyki bezpieczeństwa

Wiele firm korzysta dziś z AI w chmurze, ale są przypadki, gdy lepiej (albo taniej) przetwarzać dane u siebie: poufne dokumenty, tajemnice handlowe, dane klientów regulowane umowami lub przepisami. Self-hosted LLM (własny model uruchamiany lokalnie lub na serwerze firmowym) daje większą kontrolę nad danymi i przewidywalne koszty. Ten przewodnik pokazuje minimalny, praktyczny zestaw komponentów (RAG), wymagania sprzętowe, koszty, ryzyka i kroki wdrożenia w MŚP.

Co to jest RAG i dlaczego ułatwia start

Retrieval-Augmented Generation (RAG) to sposób pracy modelu, w którym odpowiedzi są wspierane „ściągawką” z Twoich dokumentów. Zamiast „uczyć” model od zera, tworzysz indeks wiedzy (wektorową bazę z embeddingami), a przy każdym zapytaniu system wyszukuje właściwe fragmenty i podsuwa je modelowi do odpowiedzi. Efekt: dokładniejsze, aktualne i wyjaśnialne odpowiedzi bez kosztownego treningu.

Minimalny stack self-hosted dla MŚP

W praktyce wystarczy pięć klocków, które możesz uruchomić na jednym serwerze:

• LLM inference server — proces, który „gada” z modelem (np. przez API zgodne z OpenAI lub własny endpoint). Obsługuje przycinanie kontekstu, batching i kolejkowanie żądań.
• Model embeddingów — zamienia tekst na wektory (potrzebne do wyszukiwania podobnych fragmentów w bazie).
• Wektorowa baza danych — przechowuje embeddingi Twoich dokumentów i szybko zwraca „najbardziej podobne” kawałki.
• Indeksowanie/ingest — skrypty, które czyszczą i dzielą pliki (PDF, DOCX, e-maile), liczą embeddingi i aktualizują bazę.
• Warstwa aplikacyjna — prosty interfejs (np. chat + wyszukiwarka), logowanie i kontrola dostępu, dzienniki zapytań.

Modele: które wybrać na start (prosto i bez „sztuczek”)

Dla MŚP sensowny jest zestaw: jeden model czatowy ogólnego przeznaczenia + lekki model embeddingów. Wersje „instruct” sprawdzają się w asystentach biurowych i help deskach wewnętrznych. Jeśli pracujesz głównie po polsku, wybierz model znany z dobrej jakości w językach europejskich. Nie zaczynaj od największych możliwych wag — liczy się stabilność i koszt, a nie rekord w benchmarku.

• LLM do czatu — model 7–14B (parametrów) często wystarczy do zadań biurowych, podsumowań, Q&A z dokumentów, draftów e-maili.
• Embeddingi — mały, szybki model wielojęzyczny, który generuje stabilne wektory. Ważna jest powtarzalność, nie „poetyckość”.
• Kwoty i kontekst — ustaw twarde limity długości wejścia/wyjścia i maks. liczbę dokumentów dołączanych do odpowiedzi, by zachować przewidywalność.

Sprzęt: ile mocy naprawdę potrzeba

Najczęstsze pytanie brzmi „czy potrzebuję GPU?”. To zależy od skali i opóźnień, jakie akceptujesz:

• CPU-only — najmniejszy koszt wejścia. Model 7–8B po kwantyzacji (np. 4-bit) na współczesnym CPU potrafi obsłużyć wewnętrzne zapytania z sekundowymi–kilkusekundowymi opóźnieniami. Wystarczy dla kilku użytkowników, podsumowań i Q&A.
• 1× GPU 12–24 GB VRAM — „sweet spot” dla małego zespołu. Pozwala na szybszą inferencję modeli 7–14B, wygodny kontekst i więcej jednoczesnych zapytań.
• RAM i dysk — 32–64 GB RAM i szybki SSD NVMe (indeks + cache) poprawią responsywność. Pamiętaj o miejscu na pliki źródłowe i ich wersje.

W praktyce warto zacząć na istniejącym serwerze (VM lub bare-metal), a dopiero przy rosnącym użyciu przejść na kartę GPU lub serwer zewnętrzny w Twojej kontroli.

Koszty: realne widełki dla pilotażu

Szacunkowo (porządek wielkości): jednorazowo 0–3000 zł (jeśli kupujesz używaną kartę GPU), miesięcznie kilkadziesiąt–kilkaset zł za prąd i utrzymanie. Oprogramowanie open-source (serwer inferencji, konektory do RAG, wektorowa baza) zwykle jest bezpłatne, a jeśli skorzystasz z komercyjnego wsparcia lub gotowych kontenerów, dolicz abonament. Najważniejsze: policz alternatywę w chmurze (koszt tokenów + transfer) przy Twoim wolumenie zapytań — bywa, że self-host opłaca się już od kilkunastu tysięcy zapytań miesięcznie.

Bezpieczeństwo: standardy „must have” dla self-hosted

AI nie zwalnia z higieny IT. Zadbaj o podstawy:

• Segmentacja sieci i zero trust — serwer LLM i wektorowa baza w podsieci bez dostępu z internetu; ruch tylko przez reverse proxy z TLS, a najlepiej przez VPN.
• Uwierzytelnianie i autoryzacja — SSO (np. przez firmowy IdP), role i uprawnienia na poziomie indeksu (np. dział HR widzi tylko swoje dokumenty).
• Dzienniki i alerty — zapisuj zapytania i odpowiadające im źródła; włącz alerty na nietypowe użycie (hurtowe exporty, zapytania masowe poza godzinami).
• Red teaming promptów — przygotuj testy „złośliwych” poleceń (ujawnij poufne, pomiń politykę, podaj hasła) i upewnij się, że warstwa aplikacyjna to blokuje.
• Sanity checks — zanim odpowiedź trafi do użytkownika, sprawdź, czy nie zawiera wrażliwych danych lub treści wykraczających poza politykę.
• Kopia zapasowa — regularny backup indeksu i metadanych (nie tylko plików źródłowych). Testuj odtwarzanie.

Jakość odpowiedzi: co ma największy wpływ

Najczęściej nie model jest „winny”, tylko dane i parametry RAG:

• Chunking — dziel dokumenty na sensowne fragmenty (np. 400–800 słów) z niewielką zakładką, by nie urywać zdań.
• Top-k i próg podobieństwa — zbyt mało dokumentów = puste odpowiedzi; zbyt dużo = rozwodnienie. Znajdź balans (np. 3–5 fragmentów).
• Źródła w odpowiedzi — pokazuj listę fragmentów, na których oparto odpowiedź. To zwiększa zaufanie i ułatwia poprawki.
• Aktualizacja indeksu — nawet najlepszy system zardzewieje bez regularnego reindeksowania nowych materiałów.

Wektorowa baza: co wybrać i jak ustawić

Do małych wdrożeń sprawdzi się lekka baza wektorowa lub rozszerzenie w PostgreSQL. Kluczowe ustawienia to metryka podobieństwa (np. cosine) i wielkość indeksu. Prowadź wersjonowanie indeksów (np. v1, v2), by móc wrócić do poprzednich parametrów bez „grzebania” w produkcji.

Operacje i monitoring: trzy proste wskaźniki

Na początek wystarczy prosty pulpit: wykorzystanie CPU/GPU i RAM, czas odpowiedzi (p50/p95) oraz odsetek zapytań bez wyników z RAG (brak trafień). Jeśli p95 rośnie, najpierw sprawdź indeks (rozmiar, fragmenty), dopiero potem dokładaj sprzęt.

Ryzyka i jak je ograniczać

• Halucynacje — wymuś, by odpowiedź opierała się wyłącznie na zwróconych źródłach; w braku źródeł wyświetl komunikat „brak danych”.
• Wycieki danych — logowanie i maskowanie; zakaz kopiowania całych dokumentów przez interfejs końcowy.
• Vendor lock-in — trzymaj warstwę aplikacji na standardowym API (np. styl „OpenAI-compatible”), a modele i bazy definiuj w konfiguracji.
• RODO i zgodność — określ podstawę przetwarzania, retencję i prawo do bycia zapomnianym dla danych w indeksie.

Plan wdrożenia na 30 dni (dla zespołu 2–3 osób)

Tydzień 1: wybór use case (np. Q&A z regulaminów i umów), inwentaryzacja źródeł, decyzje o dostępie (RBAC), wybór modelu i bazy wektorowej. Przygotuj środowisko (VM/serwer, kontenery).

Tydzień 2: ingest pierwszych plików (PDF/DOCX/HTML), czyszczenie, chunking, liczenie embeddingów, budowa indeksu v1. Uruchom czat i logowanie. Testy jakości (top-k, progi podobieństwa).

Tydzień 3: hardening bezpieczeństwa (TLS, SSO, segmentacja), red teaming promptów, alerty. Warsztat z użytkownikami: pytania kontrolne, jak cytować źródła, kiedy system mówi „nie wiem”.

Tydzień 4: pilotaż na ograniczonej grupie (np. 10 osób), poprawki promptów i parametrów RAG, przegląd dzienników, decyzja o ewentualnym GPU. Dokument „operacje i utrzymanie”.

Checklisty „przed produkcją”

• Dane — lista źródeł, retencja, klauzule prawne, wersjonowanie indeksu.
• Model — rozmiar, języki, limity kontekstu, prędkość; testy halucynacji na Twoich dokumentach.
• Bezpieczeństwo — TLS, SSO, RBAC, backup, dzienniki, alerty, test ucieczki danych.
• Użyteczność — źródła w odpowiedzi, przycisk „pokaż fragment”, jasny komunikat „nie wiem”.

Kiedy self-hosted, a kiedy chmura

Self-hosted ma sens, gdy masz wrażliwe dane, stabilny i przewidywalny wolumen zapytań, potrzebę pracy offline lub integracji z systemami bez dostępu do internetu. Chmura wygrywa, gdy kluczowa jest elastyczna skala, minimalny wysiłek operacyjny i dostęp do najnowszych, bardzo dużych modeli. W wielu firmach najlepiej działa hybryda: bieżące dokumenty lokalnie, a rzadkie, „ciężkie” zadania — przez API w chmurze.

Najczęstsze błędy i jak ich uniknąć

• „Zacznijmy od największego modelu” — większy nie znaczy lepszy; najpierw popraw dane i parametry RAG.
• Brak logowania i audytu — nie wiesz, co użytkownicy pytają i kiedy system zawodzi.
• Indeks „na wieczność” — bez reindeksowania jakość spada wraz z aktualizacją treści.
• Brak polityki dostępu — każdy widzi wszystko; ryzyko wycieków i błędnych odpowiedzi.

Podsumowanie

Self-hosted LLM nie wymaga farmy serwerów ani zespołu naukowców. Dla MŚP wystarczy lekki stack RAG, rozsądny model 7–14B, mała baza wektorowa i dyscyplina operacyjna. Zacznij od jednego procesu (np. Q&A na dokumentach działu), dopracuj parametry i bezpieczeństwo, a dopiero potem skaluj. Efektem jest szybszy dostęp do wiedzy, mniejsze ryzyko prawne i przewidywalny koszt utrzymania.

Źródła

https://owasp.org/www-project-top-10-for-large-language-model-applications/ — OWASP: najczęstsze zagrożenia dla aplikacji opartych na LLM i wskazówki zabezpieczeń

https://www.nist.gov/itl/ai-risk-management-framework — NIST AI RMF: ramy zarządzania ryzykiem w projektach AI

https://www.postgresql.org/docs/current/pgvector.html — pgvector: wektorowe wyszukiwanie w PostgreSQL

https://qdrant.tech/documentation/ — Qdrant: dokumentacja bazy wektorowej i przykłady wdrożeń

https://milvus.io/docs — Milvus: dokumentacja i dobre praktyki indeksowania

https://llama.cpp.ai — llama.cpp: uruchamianie modeli na CPU/GPU, kwantyzacja i wymagania

https://vllm.ai — vLLM: szybki serwer inferencji i zarządzanie kontekstem

https://python.langchain.com/docs — LangChain: łączenie RAG, indeksów, modeli i aplikacji

https://www.deeplearning.ai/the-batch/ — The Batch: praktyczne materiały o RAG i jakości odpowiedzi