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

Opublikowano: 12 marca 2026 | Czas czytania: 14 min | Autor: Nightcode

> Dane nie mogą wyjść poza firmę, a rachunki za API rosną z miesiąca na miesiąc? Lokalny model językowy bywa świetnym rozwiązaniem — ale nie zawsze. Sprzęt, modele, koszty i architektura bez marketingowej waty.

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:

```bash
# 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](https://www.nightcode.pl/darmowa-konsultacja).