Własny LLM w firmie to model językowy uruchomiony na GPU, nad którym masz pełną kontrolę: we własnej serwerowni, na wynajętym serwerze albo w kolokacji. Dane nie trafiają do zewnętrznego dostawcy API, a rachunek nie rośnie z każdym tokenem. Ten przewodnik prowadzi przez cztery decyzje, które trzeba podjąć, zanim pierwszy użytkownik zada modelowi pytanie.
Piszemy z perspektywy zespołu, który na co dzień utrzymuje serwery GPU w polskiej serwerowni Tier III. Stan na listopad 2026: rynek modeli otwartych zmienia się co miesiąc, sprzęt co kilka kwartałów, ale logika wyboru pozostaje ta sama. Przy każdym kroku odsyłamy do szczegółowego artykułu z serii.
Po co własny LLM w firmie, skoro jest API?
Publiczne API to najszybszy start: klucz, kilka linii kodu i prototyp gotowy. Problemy zaczynają się, gdy prototyp ma pracować na prawdziwych danych firmy. Własny model rozwiązuje kilka z nich:
- Dane zostają u Ciebie. Umowy, dokumentacja medyczna, kod źródłowy czy dane klientów nie opuszczają infrastruktury, którą kontrolujesz. W naszym przypadku to serwerownia w Polsce z certyfikatem ISO 27001.
- Przewidywalny koszt. Płacisz za sprzęt (abonament albo zakup), a nie za każde zapytanie. Kolejny użytkownik czy kolejny proces nie podnoszą rachunku, dopóki nie wyczerpiesz mocy GPU.
- Kontrola nad wersją modelu. Dostawca API może zmienić lub wycofać model, na którym zbudowałeś aplikację. Model na własnym serwerze zmienia się tylko wtedy, gdy Ty o tym zdecydujesz.
- Dostosowanie. Możesz dotrenować model (fine-tuning) na własnych danych, podłączyć go do wewnętrznych baz wiedzy (RAG) i systemów, których nigdy nie wystawiłbyś do internetu.
Są też koszty. Ktoś musi ten model uruchomić, monitorować i aktualizować. Najmocniejsze zamknięte modele bywają lepsze od otwartych w części zadań. Trzeba też z góry dobrać sprzęt, a zły dobór kosztuje. Jeśli przetwarzasz niewiele danych i nie są one wrażliwe, API może być rozsądniejszym wyborem. Szerzej o ryzyku wysyłania danych do publicznych usług piszemy w tekście o wdrożeniu lokalnych modeli LLM bez wycieku danych.
Krok 1: wybierz model pod zadanie, nie odwrotnie
Najczęstszy błąd to zaczynanie od największego modelu, o którym głośno w danym miesiącu. Lepiej zacząć od zadania: streszczanie dokumentów, odpowiadanie na pytania z bazy wiedzy, klasyfikacja zgłoszeń, generowanie kodu, transkrypcja. Dopiero potem szukasz najmniejszego modelu, który robi to wystarczająco dobrze. Modele otwarte dzielą się dziś mniej więcej na trzy grupy (stan na listopad 2026):
- Małe, 7–31B parametrów: np. Gemma 4 (12B i 31B), Qwen3.8-27B, gpt-oss-20b, Devstral Small 2 do kodu (zob. prywatny asystent AI do kodu) oraz polskie Bielik i PLLuM. Mieszczą się na jednym GPU i świetnie sprawdzają się w wąskich, dobrze zdefiniowanych zadaniach.
- Średnie, ok. 100–200B: np. gpt-oss-120b, Mistral Small 4 (119B), Mistral Medium 3.5 (128B), Llama 4 Scout (109B), Qwen3.8-Flash-Next (180B). Rozsądny kompromis między jakością a kosztem sprzętu.
- Duże modele MoE, od ok. 300B do ponad 2T: np. GLM-5.3-Flash (ok. 321B), DeepSeek-V4.1-Flash (ok. 763B), Mistral Large 4 (ok. 1T), DeepSeek-V4-Pro (ok. 1,65T), Kimi K3 (ok. 2,78T). Najwyższa jakość, ale wymagają serwera z wieloma GPU lub klastra.
Drugie kryterium to licencja. Apache 2.0 i MIT pozwalają na swobodne użycie komercyjne. Licencje własne producentów (Llama, Mistral, Kimi, część modeli Qwen i GLM) trzeba przeczytać przed wdrożeniem, bo mogą zawierać ograniczenia. Szczegółowe zestawienie z licencjami i minimalnym sprzętem znajdziesz w artykule najlepsze modele open source do self-hostingu w 2026. Jeśli pracujesz głównie po polsku, sprawdź też Bielika i PLLuM na własnym serwerze: są małe, tanie w utrzymaniu i dostrojone do polszczyzny, choć w ogólnych testach duże modele globalne zwykle wypadają lepiej.
Krok 2: policz pamięć i dobierz GPU
O tym, na jakim sprzęcie uruchomisz model, decyduje przede wszystkim pamięć GPU (VRAM). Prosta reguła: wagi ≈ liczba parametrów × bajty na parametr. W precyzji FP16/BF16 to 2 bajty, w FP8 1 bajt, w kwantyzacji 4-bitowej ok. 0,5 bajta. Do tego dochodzi pamięć kontekstu (KV cache), która rośnie z długością kontekstu i liczbą jednoczesnych użytkowników, oraz 10–20% narzutu. Modele MoE potrzebują pamięci na wszystkie parametry, mimo że przy każdym tokenie liczą tylko część z nich.
| Rozmiar modelu | FP16/BF16 | FP8 | 4-bit |
|---|---|---|---|
| 12B (np. Gemma 4 12B) | ok. 24 GB | ok. 12 GB | ok. 6 GB |
| 31B (np. Gemma 4 31B) | ok. 62 GB | ok. 31 GB | ok. 16 GB |
| 117B (gpt-oss-120b) | ok. 234 GB | ok. 117 GB | ok. 59 GB |
| 321B (GLM-5.3-Flash) | ok. 642 GB | ok. 321 GB | ok. 161 GB |
| 763B (DeepSeek-V4.1-Flash) | ok. 1 526 GB | ok. 763 GB | ok. 382 GB |
Tabela pokazuje same wagi, więc realne zapotrzebowanie jest wyższe. Kwantyzacja to najtańszy sposób na zmniejszenie sprzętu, o czym pisaliśmy w tekście o redukcji kosztów dzięki kwantyzacji. Przy wielu jednoczesnych użytkownikach liczy się nie tylko pojemność, ale też przepustowość pamięci, bo od niej zależy, ile tokenów na sekundę dostanie każdy z nich. Dotrenowanie modelu wymaga znacznie więcej pamięci niż sama inferencja.
Pełną metodę liczenia z przykładami znajdziesz w artykule ile VRAM potrzebuje model LLM, a porównanie konkretnych kart w tekście jaki GPU do LLM: B300, B200, H200, RTX PRO 6000 i Gaudi 3.
Krok 3: zdecyduj, gdzie model będzie działał
Gdy znasz zapotrzebowanie na pamięć, wybierasz formę. Wszystkie poniższe opcje działają u nas w jednej serwerowni, więc możesz zacząć od najmniejszej i rosnąć bez zmiany dostawcy.
| Opcja | Dla kogo | Zalety | Ograniczenia |
|---|---|---|---|
| VPS z GPU / gotowy pakiet GPU | start, małe modele, jeden zespół | szybkie uruchomienie, stały abonament | pamięć od 12 do 96 GB |
| Serwer GPU bare metal (do 8 GPU) | produkcja, wielu użytkowników, duże modele | cała maszyna tylko dla Ciebie, wybór kart | wyższy koszt, wymaga dobrego doboru |
| DGX Spark jako usługa | R&D, prototypy, fine-tuning do 70B | 128 GB pamięci zunifikowanej, stos NVIDIA | przepustowość 273 GB/s, nie do obsługi wielu użytkowników naraz |
| Klaster 2 lub 4 DGX Spark | praca z modelami ok. 400B lub ok. 700B | 256 lub 512 GB pamięci łącznie | to samo ograniczenie przepustowości |
| Klaster serwerów GPU | trening, największe modele, duży ruch | skalowanie, szybka sieć między węzłami | złożoność, wymaga chłodzenia cieczą |
| Kolokacja własnego sprzętu | firmy z długim horyzontem i stałym obciążeniem | sprzęt jest Twój, my dajemy zasilanie, chłodzenie, sieć i administrację | wydatek inwestycyjny na start |
Gotowe pakiety i większe konfiguracje znajdziesz na stronach DeepSeek na własnym GPU i serwery GPU. Na pakietach działa nie tylko DeepSeek, ale też Llama, Qwen, Mistral, Gemma czy Whisper. Jak działa model abonamentowy i co obejmuje cena, opisujemy w artykule GPU as a Service: wynajem serwera GPU.
DGX Spark to osobna kategoria: chip NVIDIA GB10 Grace Blackwell i 128 GB pamięci zunifikowanej w jednym urządzeniu, a w klastrze dwóch (kabel QSFP) lub czterech sztuk (przełącznik 200 GbE) odpowiednio 256 i 512 GB. Ograniczeniem jest przepustowość pamięci (273 GB/s), znacznie niższa niż w kartach z HBM, więc to sprzęt do rozwoju, prototypów i prywatnej inferencji dla małego zespołu, a nie do obsługi setek użytkowników. Szczegóły: NVIDIA DGX Spark jako usługa i klaster DGX Spark dla modeli 400B–700B.
Jeśli wolisz kupić sprzęt, jako partner Supermicro i NVIDIA dostarczamy serwery z GPU NVIDIA lub Intel Gaudi 3 i stawiamy je w kolokacji w naszej serwerowni. Biurowa serwerownia rzadko się do tego nadaje: GPU NVIDIA B300 pobiera do 1 100 W, a według Supermicro w szafie chłodzonej powietrzem zmieści się do 32 GPU B200, w chłodzonej cieczą do 96. Więcej w tekście chłodzenie serwerów GPU: powietrze czy ciecz.
Krok 4: utrzymanie, monitoring i bezpieczeństwo
Uruchomienie modelu to kilka godzin pracy. Utrzymanie go w produkcji to praca ciągła. Zaczyna się od wyboru silnika: Ollama wystarczy do testów i pojedynczego użytkownika, w produkcji z wieloma użytkownikami lepiej sprawdzają się vLLM lub SGLang, a w ekosystemie NVIDIA także NIM. Większość z nich udostępnia API zgodne z OpenAI, więc aplikacje nie muszą wiedzieć, jaki model i sprzęt stoją pod spodem. Porównanie znajdziesz w artykule Ollama, vLLM, SGLang czy NVIDIA NIM.
Lista rzeczy, które trzeba mieć pod kontrolą:
- Monitoring: obciążenie i pamięć GPU, temperatury, długość kolejki zapytań, czas odpowiedzi, błędy.
- Aktualizacje: sterowniki, CUDA, silnik inferencji i sam model, zawsze najpierw na środowisku testowym.
- Dostęp: model nie powinien mieć publicznego endpointu. Uwierzytelnianie, VPN lub reverse proxy, uprawnienia per zespół.
- Logi: zapytania użytkowników mogą zawierać dane osobowe, więc logi też podlegają RODO. Ustal, co logujesz i jak długo trzymasz.
- Kopie zapasowe: dotrenowane wagi, baza wektorowa, konfiguracja.
- Łańcuch dostaw: pobieraj modele z oficjalnych repozytoriów producentów i weryfikuj, co uruchamiasz.
Możesz robić to sam z dostępem root albo zlecić nam administrację 24/7. Jak wygląda to w praktyce, opisaliśmy w tekście o MLOps w codziennej praktyce.
Drabina sprzętowa: od prototypu do produkcji
Poniżej skrócona ścieżka od pilotażu do produkcji. Nie trzeba zaczynać od dołu, ale warto wiedzieć, gdzie jest następny szczebel.
| Szczebel | Sprzęt | Pamięć dla modelu | Typowe zastosowanie |
|---|---|---|---|
| 1 | Gotowy pakiet GPU (od RTX A2000 do 2× A40) | 12–96 GB | pilotaż, małe modele, jeden zespół |
| 2 | NVIDIA DGX Spark | 128 GB zunifikowanej | prototypy, fine-tuning do 70B, inferencja do 200B |
| 3 | Klaster 2 lub 4 DGX Spark | 256 / 512 GB | rozwój na modelach ok. 400B / ok. 700B |
| 4 | Serwer z RTX PRO 6000 Blackwell (do 8 kart) | do 768 GB GDDR7 | inferencja produkcyjna, RAG, wielu użytkowników |
| 5 | HGX B200 / HGX B300 (8 GPU) | ok. 1,4 TB / ok. 2,3 TB HBM3e | duże modele MoE, duży ruch, trening |
| 6 | Klaster HGX lub GB300 NVL72 | wiele węzłów / 72 GPU w jednej domenie NVLink | trening i największe modele w skali |
Alternatywą dla NVIDIA na szczeblach 4–5 jest Intel Gaudi 3: 8 akceleratorów po 128 GB HBM2e z wbudowaną siecią 800 GbE, obsługiwany przez PyTorch i vLLM. Opisujemy go w tekście Intel Gaudi 3 w inferencji LLM. Szczegółowe kryteria przejścia między szczeblami są w artykule DGX Spark, RTX PRO 6000 czy HGX B200.
Ile kosztuje własny LLM: jak to policzyć
Przy API koszt to liczba tokenów pomnożona przez cenę z cennika. Rośnie liniowo z użyciem i trudno go przewidzieć, zwłaszcza w RAG i u agentów, gdzie każde zapytanie niesie dużo kontekstu (więcej w tekście o tokenach w modelach językowych). Przy własnym GPU koszt jest stały: abonament albo zakup sprzętu plus kolokacja. Każde kolejne zapytanie kosztuje praktycznie zero, dopóki nie wyczerpiesz mocy maszyny.
Punkt opłacalności liczysz więc, porównując prognozowany miesięczny rachunek za API z kosztem stałym sprzętu i jego utrzymania. Dla orientacji: nasze gotowe pakiety GPU zaczynają się od 899 zł netto miesięcznie (1× RTX A2000 12 GB), przez A10 24 GB (2 999 zł), A30 24 GB (4 349 zł) i A40 48 GB (5 499 zł), do 2× A40 96 GB (8 599 zł). DGX Spark jako usługa oraz serwery Blackwell wyceniamy indywidualnie. Metodę z przykładem liczbowym opisujemy w tekście jak policzyć zwrot z wdrożenia AI, a wynajem i zakup z kolokacją porównujemy w artykule o TCO chmury i kolokacji GPU.
Zgodność: RODO, AI Act, NIS2 i DORA
Własny LLM w firmie, hostowany w polskiej serwerowni, nie zwalnia z obowiązków prawnych, ale znacząco je upraszcza. Przy RODO odpada pytanie o transfer danych poza EOG i o to, co dostawca API robi z Twoimi zapytaniami. Zostają standardowe obowiązki administratora danych: podstawa prawna, minimalizacja, retencja logów.
AI Act reguluje zastosowania, a nie miejsce hostingu. Rekrutacja czy ocena pracowników to obszary wysokiego ryzyka niezależnie od tego, gdzie działa model. Terminy części obowiązków UE zapowiadała przesunąć, więc sprawdzaj aktualny harmonogram. Dla firm objętych NIS2 lub DORA system AI staje się częścią infrastruktury ICT: wymaga oceny ryzyka, nadzoru nad dostawcami i dokumentacji na audyt. Rozwijamy to w artykule AI Act, RODO, NIS2 i DORA przy własnym modelu AI. Prowadzimy też audyty NIS2.
FAQ: najczęściej zadawane pytania
Ile kosztuje własny LLM w firmie?
Zależy od rozmiaru modelu i liczby użytkowników. Gotowe pakiety GPU, na których uruchomisz model do kilkudziesięciu miliardów parametrów, kosztują u nas od 899 zł do 8 599 zł netto miesięcznie. Serwery Blackwell i DGX Spark jako usługa to wycena indywidualna. Do tego dolicz administrację, jeśli nie robisz jej sam.
Jaki serwer do LLM wybrać na start?
Do pilotażu z małym modelem wystarczy pakiet z jedną kartą 24–48 GB. Do prototypów na większych modelach i fine-tuningu dobrze sprawdza się DGX Spark. Serwer z wieloma GPU ma sens, gdy znasz już model i spodziewaną liczbę użytkowników.
Czy własny model jest tak dobry jak komercyjne modele w chmurze?
W wąskich zadaniach na własnych danych, np. odpowiedziach z bazy wiedzy czy streszczaniu dokumentów, dobrze dobrany model otwarty zwykle wystarcza. W najtrudniejszych zadaniach ogólnych najmocniejsze modele zamknięte nadal bywają lepsze. Dlatego warto przetestować kilka modeli na własnych przykładach.
Ile VRAM potrzeba do modelu 70B?
Same wagi zajmują ok. 140 GB w FP16, ok. 70 GB w FP8 i ok. 35 GB w kwantyzacji 4-bitowej. Do tego dochodzi pamięć kontekstu zależna od liczby użytkowników oraz 10–20% narzutu.
Czy mogę uruchomić DeepSeek, Llamę albo Qwena na własnym serwerze?
Tak, wszystkie są dostępne jako modele otwarte. Warunkiem jest wystarczająca ilość pamięci GPU i zgodność z licencją: DeepSeek jest na licencji MIT, Llama i część wariantów Qwena mają licencje własne producentów.
Czy własny LLM jest zgodny z RODO?
Sam hosting nie zapewnia zgodności, ale ją ułatwia: dane nie wychodzą poza Twoją infrastrukturę w Polsce, więc nie ma transferu do zewnętrznego dostawcy. Nadal musisz zadbać o podstawę prawną, kontrolę dostępu i retencję logów.
Chcesz dobrać sprzęt do konkretnego modelu i liczby użytkowników? Zobacz serwery GPU i gotowe pakiety GPU, a potem napisz do nas: przygotujemy konfigurację, uruchomimy model testowo i wycenimy wariant docelowy.