Lokalny LLM w firmie — kiedy własny model AI ma sens i ile to kosztuje

Jeszcze dwa lata temu „własny ChatGPT na serwerze w biurze" brzmiał jak projekt dla korporacji z działem badawczym. Dziś otwarte modele językowe są na tyle dobre, a narzędzia do ich uruchamiania na tyle dojrzałe, że sensowny lokalny LLM da się postawić na jednej karcie graficznej w kilka godzin.

Coraz częściej słyszymy od klientów to samo pytanie: „Czy możemy mieć AI, ale bez wysyłania naszych danych do Ameryki?". Odpowiedź brzmi: tak. Ale zanim kupisz serwer z GPU, warto zrozumieć, co dokładnie zyskujesz, co tracisz i ile to naprawdę kosztuje.

Czym jest lokalny LLM?

LLM (Large Language Model) to model językowy — ten sam typ technologii, który stoi za ChatGPT, Claude czy Gemini. „Lokalny" oznacza, że model działa na infrastrukturze, którą kontrolujesz: na serwerze w biurze, w firmowej serwerowni albo na wynajętej maszynie w polskim lub europejskim centrum danych.

Kluczowa różnica: zapytania i dokumenty nigdy nie trafiają do zewnętrznego dostawcy AI. Model to po prostu plik z wagami (kilka do kilkuset gigabajtów), który ładujesz do pamięci karty graficznej i odpytujesz przez API — dokładnie tak, jak API komercyjnych dostawców.

Kiedy lokalny model ma sens

Z naszego doświadczenia są cztery sytuacje, w których lokalny LLM wygrywa:

1. Dane wrażliwe i regulowane. Dokumentacja medyczna, dane finansowe, umowy, dane osobowe klientów, tajemnica przedsiębiorstwa. Nawet jeśli dostawcy chmurowi oferują umowy powierzenia i serwery w UE, część firm (i ich klientów) po prostu nie chce, żeby dane opuszczały ich infrastrukturę.
2. Duży, przewidywalny wolumen. Jeśli codziennie przetwarzasz tysiące dokumentów — klasyfikacja maili, ekstrakcja danych z faktur, streszczanie zgłoszeń — koszt API rośnie liniowo. Koszt własnego serwera jest stały.
3. Praca offline lub w sieci odizolowanej. Zakłady produkcyjne, systemy przemysłowe, środowiska bez dostępu do internetu.
4. Pełna kontrola nad modelem. Wersja modelu nie zmieni się z dnia na dzień, nikt nie wyłączy Ci API, możesz dostroić model (fine-tuning) na własnych danych.

Kiedy lepiej zostać przy API

Równie ważne jest to, kiedy lokalny model nie ma sensu:

• Potrzebujesz najlepszej jakości rozumowania. Czołowe modele komercyjne wciąż wyraźnie wygrywają przy złożonej analizie, długim kontekście, programowaniu i zadaniach wieloetapowych. Otwarte modele doganiają je szybko, ale na jednej karcie graficznej nie uruchomisz odpowiednika najmocniejszego modelu z chmury.
• Wolumen jest mały. Jeśli firma wysyła kilkaset zapytań dziennie, rachunek za API wyniesie kilkadziesiąt do kilkuset złotych miesięcznie. Serwer z GPU nie zwróci się nigdy.
• Nie masz kogo przypisać do utrzymania. Lokalny model to kolejny system: aktualizacje, monitoring, kopie zapasowe, bezpieczeństwo.

Rozwiązanie pośrednie: coraz popularniejsza jest architektura hybrydowa. Dane wrażliwe przetwarza lokalny model, a zadania wymagające najwyższej jakości (bez danych osobowych) trafiają do API w chmurze. Router po drodze decyduje, gdzie wysłać zapytanie.

Jakie modele wybrać w 2026 roku?

Ekosystem otwartych modeli zmienia się co kilka tygodni, więc zamiast rankingu podajemy rodziny, które w praktyce sprawdzają się u nas i u naszych klientów:

Rodzina	Rozmiary	Licencja	Mocne strony
Qwen3 (Alibaba)	od 0,6B do 235B (MoE)	Apache 2.0	Bardzo dobra jakość w stosunku do rozmiaru, dobry polski, wywoływanie narzędzi
gpt-oss (OpenAI)	20B i 120B (MoE)	Apache 2.0	Mocne rozumowanie, 20B działa na karcie 16 GB, 120B na jednym GPU 80 GB
Mistral Small (Mistral AI)	24B	Apache 2.0	Europejski dostawca, szybki, dobry do ekstrakcji danych
Gemma 3 (Google)	od 1B do 27B	Gemma Terms of Use	Multimodalność (tekst + obraz), dobre małe warianty
Llama (Meta)	od 1B do 400B+	Llama Community License	Ogromny ekosystem, dużo wersji dostrojonych
Bielik (SpeakLeash)	ok. 11B	Apache 2.0	Polski model trenowany na polskich danych — świetny w naszym języku

Kilka praktycznych uwag:

• Oznaczenie „B" to miliardy parametrów. Więcej parametrów to zwykle lepsza jakość, ale też większe wymagania sprzętowe i wolniejsze odpowiedzi.
• MoE (Mixture of Experts) oznacza, że przy każdym tokenie aktywna jest tylko część modelu. Model 120B z architekturą MoE może działać szybciej niż „gęsty" model 70B — ale nadal musi zmieścić się w pamięci w całości.
• Sprawdzaj licencję. Apache 2.0 pozwala na praktycznie dowolne użycie komercyjne. Licencje Llama i Gemma mają dodatkowe warunki, które warto przeczytać przed wdrożeniem.
• Testuj na własnych danych. Benchmarki mówią niewiele o tym, jak model poradzi sobie z Twoimi fakturami czy zgłoszeniami serwisowymi. Przygotuj 50–100 prawdziwych przykładów i porównaj modele na nich.

Ile pamięci potrzebuje model? Kwantyzacja w pigułce

Najważniejszy parametr sprzętowy to ilość pamięci VRAM na karcie graficznej. Model w pełnej precyzji (16 bitów) potrzebuje około 2 GB pamięci na każdy miliard parametrów. Model 24B zająłby więc około 48 GB — za dużo na kartę konsumencką.

Tu wchodzi kwantyzacja: zapisanie wag z mniejszą precyzją (8, 6, 5 lub 4 bity). Model skwantyzowany do 4 bitów zajmuje około 0,55–0,65 GB na miliard parametrów, a utrata jakości przy dobrych metodach kwantyzacji (np. Q4_K_M w formacie GGUF, AWQ, GPTQ) jest w większości zastosowań biznesowych niezauważalna.

Do tego trzeba doliczyć pamięć na KV cache — „pamięć roboczą" modelu, która rośnie z długością kontekstu i liczbą równoległych użytkowników. Przy długich dokumentach potrafi zająć kilka do kilkunastu gigabajtów.

Orientacyjnie (kwantyzacja 4-bitowa, umiarkowany kontekst):

Model	Pamięć na wagi	Minimalny sensowny sprzęt
7–8B	ok. 5 GB	Karta 8–12 GB, laptop z Apple Silicon
12–14B	ok. 9 GB	Karta 16 GB
20–32B	13–20 GB	Karta 24–32 GB (np. RTX 4090, RTX 5090)
70B	ok. 40 GB	2× 24–32 GB lub jedna karta 48 GB+
120B MoE	ok. 65 GB	GPU 80–96 GB lub komputer z dużą pamięcią zunifikowaną

Sprzęt: trzy realne scenariusze

Scenariusz A: Stacja robocza z jedną kartą (8–15 tys. zł za kartę)

Pojedyncza karta klasy RTX 4090 (24 GB) lub RTX 5090 (32 GB) w zwykłym komputerze. Uruchomisz na niej modele do ok. 32B w kwantyzacji 4-bitowej, z prędkością kilkudziesięciu tokenów na sekundę. Wystarczy dla zespołu kilkunastu osób korzystających z czatu i dla automatyzacji przetwarzających dokumenty w tle.

Dla kogo: małe firmy, pilotaż, przetwarzanie dokumentów wsadowo.

Scenariusz B: Mały serwer z dużą pamięcią (30–60 tys. zł)

Karta profesjonalna z 48–96 GB pamięci (np. z serii RTX PRO) albo dwie karty konsumenckie. Alternatywą są komputery z dużą pamięcią zunifikowaną — Mac Studio z procesorem Apple M-series czy kompaktowe stacje NVIDIA DGX Spark ze 128 GB pamięci. Są wolniejsze od dedykowanych kart przy generowaniu, ale pozwalają uruchomić duże modele (70B–120B) w cichej, energooszczędnej obudowie.

Dla kogo: firmy średniej wielkości, kilkudziesięciu użytkowników, większe modele.

Scenariusz C: Wynajęty GPU w europejskiej chmurze

Nie musisz kupować sprzętu. Serwery z GPU można wynająć na godziny lub miesiące u dostawców z centrami danych w UE (w tym w Polsce). Płacisz od kilku do kilkudziesięciu złotych za godzinę pracy karty, dane zostają w Europie, a model nadal jest „Twój" — dostawca infrastruktury nie ma do niego dostępu na poziomie aplikacji.

Dla kogo: firmy, które chcą przetestować rozwiązanie bez inwestycji albo mają zmienne obciążenie.

Oprogramowanie: jak to wszystko uruchomić

Stos technologiczny do lokalnego LLM jest dziś zaskakująco prosty. Najczęściej używamy:

• Ollama — najprostszy sposób na uruchomienie modelu. Jedna komenda pobiera model i wystawia API. Świetne na start i do pracy jednego zespołu.
• llama.cpp — silnik, na którym opiera się m.in. Ollama. Działa na CPU, GPU i Apple Silicon, obsługuje format GGUF.
• vLLM — serwer inferencji do produkcji. Dzięki technikom takim jak PagedAttention i continuous batching obsługuje dziesiątki równoległych zapytań na jednym GPU znacznie wydajniej niż Ollama.
• Open WebUI — interfejs czatu podobny do ChatGPT, z kontami użytkowników, historią rozmów i obsługą dokumentów.

Uruchomienie pierwszego modelu z Ollamą wygląda tak:

# instalacja modelu i rozmowa w terminalu
ollama run qwen3:14b

# to samo przez API zgodne z OpenAI
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3:14b",
    "messages": [{"role": "user", "content": "Streść tę umowę w 5 punktach: ..."}]
  }'

To ważne: zarówno Ollama, jak i vLLM wystawiają API zgodne z OpenAI. Oznacza to, że aplikacja napisana pod ChatGPT zwykle zadziała z lokalnym modelem po zmianie jednego adresu URL. To samo dotyczy narzędzi do automatyzacji, takich jak n8n.

RAG: jak nauczyć model wiedzy o Twojej firmie

Sam model nie wie nic o Twoich procedurach, cennikach ani dokumentacji technicznej. Najczęstszym rozwiązaniem nie jest dotrenowanie modelu, tylko RAG (Retrieval-Augmented Generation):

1. Dokumenty firmy dzielisz na fragmenty (np. po 500–1000 słów).
2. Każdy fragment zamieniasz na wektor za pomocą modelu embeddingowego (dobrze radzą sobie z polskim np. bge-m3 czy multilingual-e5).
3. Wektory zapisujesz w bazie wektorowej — Qdrant, pgvector w PostgreSQL albo Weaviate.
4. Gdy użytkownik zadaje pytanie, system wyszukuje najbardziej pasujące fragmenty i przekazuje je modelowi razem z pytaniem.
5. Model odpowiada na podstawie dostarczonych fragmentów — i może wskazać źródło.

Dobrze zrobiony RAG działa świetnie. Źle zrobiony — zwraca przypadkowe fragmenty i model „zmyśla" odpowiedź. Różnicę robią szczegóły: sposób dzielenia dokumentów, wyszukiwanie hybrydowe (wektory + słowa kluczowe), reranker, który porządkuje wyniki, i porządne testy na prawdziwych pytaniach.

Kiedy fine-tuning? Dotrenowanie modelu ma sens, gdy chcesz zmienić sposób odpowiadania — format, styl, specjalistyczny żargon — a nie dodać wiedzę. Do wiedzy służy RAG. Z techniką LoRA fine-tuning modelu 7–14B da się wykonać na jednej karcie 24 GB w kilka godzin.

Ile to kosztuje? Porównanie z API

Weźmy konkretny przykład: firma przetwarza 3 000 dokumentów dziennie (maile, zgłoszenia, faktury). Średnio 2 000 tokenów wejścia i 300 tokenów wyjścia na dokument. To około 140 milionów tokenów wejścia miesięcznie.

Wariant API: koszt zależy od wybranego modelu. Przy tanich, szybkich modelach to kilkaset złotych miesięcznie. Przy modelach z najwyższej półki — kilka tysięcy złotych miesięcznie i więcej.

Wariant lokalny (scenariusz A):

• karta graficzna + komputer: ok. 18–25 tys. zł jednorazowo,
• prąd: serwer pobierający średnio 400–500 W przez całą dobę to ok. 3 500–4 500 kWh rocznie, czyli ok. 300–400 zł miesięcznie,
• wdrożenie i integracja: od kilku do kilkunastu tysięcy złotych,
• utrzymanie: kilka godzin pracy administratora miesięcznie.

Wniosek: jeśli Twoje zadania da się wykonać dobrym modelem średniej wielkości, a wolumen jest duży i stały — lokalny model zwraca się w ciągu roku, czasem szybciej. Jeśli potrzebujesz najlepszego dostępnego modelu albo wolumen jest mały — API będzie tańsze i prostsze. W praktyce o wyborze częściej decydują kwestie prawne i bezpieczeństwa niż sam rachunek.

Bezpieczeństwo i zgodność z przepisami

Lokalny model nie oznacza automatycznie bezpiecznego systemu. Na co zwracamy uwagę przy każdym wdrożeniu:

• Kontrola dostępu. API modelu nie powinno być wystawione do internetu bez uwierzytelniania. Brzmi oczywiście, a w sieci wciąż można znaleźć tysiące otwartych instancji Ollamy.
• Uprawnienia w RAG. Jeśli pracownik działu handlowego nie ma dostępu do dokumentów kadrowych, to model odpowiadający na jego pytania też nie może ich widzieć. Uprawnienia muszą być sprawdzane na etapie wyszukiwania fragmentów.
• Prompt injection. Dokument lub mail może zawierać ukryte instrukcje dla modelu („zignoruj poprzednie polecenia i…"). Model, który ma dostęp do narzędzi, musi mieć ograniczone uprawnienia.
• Logowanie i audyt. Kto, kiedy i o co pytał — to wymóg przy danych osobowych i przydatne narzędzie diagnostyczne.
• RODO i AI Act. Lokalne przetwarzanie upraszcza kwestie powierzenia danych, ale nie zwalnia z obowiązków informacyjnych, zasady minimalizacji danych i oceny ryzyka. Unijny AI Act nakłada dodatkowe obowiązki zależnie od zastosowania systemu — asystent do streszczania dokumentów to zupełnie inna kategoria niż system oceniający kandydatów do pracy.

Jak zacząć — plan pilotażu

Zamiast od razu kupować serwer, proponujemy klientom pilotaż w czterech krokach:

1. Wybierz jeden przypadek użycia z mierzalnym efektem — np. klasyfikacja przychodzących maili albo wyciąganie danych z zamówień.
2. Zbierz 100 prawdziwych przykładów z oczekiwanym wynikiem. To Twój zestaw testowy.
3. Porównaj 2–3 modele na wynajętym GPU lub na laptopie z odpowiednią ilością pamięci. Zmierz trafność, czas odpowiedzi i zużycie pamięci.
4. Policz koszty na podstawie realnego wolumenu i dopiero wtedy zdecyduj: zakup sprzętu, wynajem, API albo hybryda.

Taki pilotaż trwa zwykle 2–4 tygodnie i kosztuje ułamek wartości sprzętu. A decyzja zapada na podstawie danych, a nie artykułów w mediach.

Podsumowanie

• Otwarte modele (Qwen3, gpt-oss, Mistral, Gemma, Llama, Bielik) są dziś wystarczająco dobre do większości zadań biznesowych: ekstrakcji danych, klasyfikacji, streszczeń, asystentów wiedzy.
• Kluczowy parametr sprzętowy to pamięć VRAM. Dzięki kwantyzacji model 24–32B zmieści się na jednej karcie konsumenckiej.
• Do wiedzy o firmie używaj RAG, a nie fine-tuningu.
• Lokalny model opłaca się przy dużym, stałym wolumenie albo gdy dane nie mogą opuścić firmy. Przy małym wolumenie wygrywa API.
• Bezpieczeństwo nie przychodzi samo — kontrola dostępu, uprawnienia i audyt to obowiązek.

Chcesz sprawdzić, czy lokalny model sprawdzi się w Twojej firmie? W Nightcode projektujemy i wdrażamy rozwiązania AI on-premise — od doboru sprzętu, przez RAG na firmowych dokumentach, po integrację z systemami, których już używasz. Porozmawiajmy.