Lokalne LLM: jaki sprzęt i GPU naprawdę potrzebujesz

Firma prawnicza z Warszawy chciała uruchomić asystenta do analizy umów. Pierwsze pytanie było techniczne: czy serwer z kartą RTX 3090 wystarczy? Drugie, trafniejsze: jaki model w ogóle jest potrzebny do tego zadania? Odpowiedź na pierwsze zależy od odpowiedzi na drugie. Bez wymagań modelowych decyzja sprzętowa to loteria.

Poniżej opisuję, jak to połączyć — od wymagań modelu przez sprzęt, aż po realny kosztorys dla polskich firm rozważających self-hosting LLM.

Lokalne LLM można uruchomić na CPU (np. przez llama.cpp), ale prędkość generowania na samym procesorze to zwykle 2–8 tokenów na sekundę dla modelu 7B. Dla aplikacji produkcyjnych, gdzie użytkownik czeka na odpowiedź, ta wartość jest za niska: ludzka percepcja komfortu to co najmniej 20–30 tokenów na sekundę.

GPU przyspiesza inference przez równoległe mnożenie macierzy — operację, która dominuje w obliczeniach LLM. Kluczowe są jednak nie megaflopy, lecz dwie inne wartości:

VRAM (pamięć GPU) decyduje o tym, czy model w ogóle się załaduje. Jeśli model nie mieści się w VRAM, zostaje przeniesiony do RAM lub dysku, a prędkość spada o rząd wielkości. Pierwsze pytanie przy wyborze GPU to zawsze: czy cały model zmieści się w VRAM?

Memory bandwidth (przepustowość pamięci) decyduje o tym, jak szybko GPU odczytuje wagi modelu podczas generowania. Generowanie każdego tokenu wymaga przeczytania całego modelu z pamięci. Karta z przepustowością 800 GB/s generuje token szybciej niż karta z 400 GB/s przy tej samej liczbie rdzeni. Porównując GPU, sprawdzaj bandwidth, nie tylko TFLOPS.

Zapotrzebowanie na VRAM zależy od rozmiaru modelu i kwantyzacji. Kwantyzacja redukuje precyzję wag z 16 bitów do 8, 4 lub nawet 3 bitów, zmniejszając rozmiar modelu przy akceptowalnym spadku jakości.

Wartości przybliżone; rzeczywiste zapotrzebowanie różni się w zależności od długości context window i implementacji. Do powyższych wartości dolicza się bufor dla aktywacji: przy kontekście 8K to dodatkowe 1–2 GB, przy 32K to 4–8 GB. Duże konteksty szybko pochłaniają VRAM.

Rynek GPU w 2026 można podzielić na trzy klasy dla zastosowań LLM:

Karty konsumenckie (RTX seria 30xx/40xx) mają przystępną cenę, ale ograniczony VRAM (do 24 GB w RTX 3090/4090). Przepustowość RTX 4090 wynosi 1 008 GB/s, co czyni ją najszybszą dostępną kartą konsumencką dla LLM. Ograniczenie: brak wsparcia NVLink dla wielu modeli, co utrudnia łączenie kart. Cena nowej RTX 4090 to 8 000–10 000 zł.

Karty profesjonalne (RTX A-series, L40S, RTX 6000 Ada) oferują więcej VRAM (48–80 GB), ECC, wsparcie NVLink i sterowniki stabilizujące uptime. RTX 6000 Ada (48 GB VRAM, ~24 000 zł) pozwala uruchomić model 34B w pełnej precyzji lub 70B w Q4. L40S (48 GB) jest odpowiednikiem serwerowym.

Karty datacenter (H100, A100, H200) oferują największą pamięć (80–141 GB) i najwyższą przepustowość (HBM3, ~3,35 TB/s dla H100 SXM), ale ceny zaczynają się od 150 000 zł i są zazwyczaj dostępne wyłącznie w chmurze lub przez leasing.

Dla polskich firm, które chcą uruchomić modele 7B–13B do zadań RAG i klasyfikacji, RTX 4090 lub używana RTX 3090 to najlepszy stosunek ceny do możliwości. Dla modeli 70B potrzebne są dwie karty 24 GB (NVLink lub PCIe) albo jedna karta 48 GB+.

Dwie karty GPU można połączyć na dwa sposoby:

NVLink (tylko wybrane karty NVIDIA, w tym RTX 3090/4090 z odpowiednią płytą) łączy pamięć obu kart w jedną pulę. Model 70B Q4 w 2×24 GB działa jakby miał 48 GB jednolitej pamięci. Przepustowość komunikacji wynosi ~600 GB/s, więc bottleneck jest minimalny.

PCIe (standardowe wielokartowe konfiguracje) nie łączy pamięci. Model musi mieścić się na jednej karcie lub być dzielony z transferem przez magistralę PCIe (16 GB/s), co drastycznie spowalnia inference. Konfiguracje PCIe multi-GPU są użyteczne do throughput (wiele zapytań równolegle na różnych kartach), nie do pracy z jednym dużym modelem.

Dla systemu produkcyjnego obsługującego wiele równoległych zapytań konfiguracja 2–4 kart PCIe na tym samym modelu pozwala zwiększyć liczbę obsługiwanych zapytań na sekundę bez skalowania VRAM. Każda karta obsługuje własną instancję modelu; llm-router rozdziela ruch.

CPU i RAM odgrywają rolę drugoplanową, ale nie marginalną.

RAM systemowy potrzebny jest do załadowania modelu do VRAM (model jest najpierw wczytywany do RAM, potem kopiowany do GPU) oraz do obsługi warstwy orkiestracji: serwera API, RAG pipeline'u, preprocesingu zapytań. Minimum to dwukrotność VRAM, praktycznie: 64 GB dla konfiguracji jedno-kartowej, 128 GB dla multi-GPU.

CPU jest bottleneckiem tylko przy pracy w trybie CPU-only (bez GPU) lub przy intensywnym przetwarzaniu wstępnym (tokenizacja dużych dokumentów, embedding na CPU). Do obsługi serwera API przy GPU-accelerated inference wystarcza dowolny nowoczesny procesor klasy server (np. AMD EPYC, Intel Xeon) lub desktop (AMD Ryzen 9, Intel Core i9). Liczba rdzeni ma znaczenie dla równoległości API, nie dla prędkości generowania.

Dysk SSD NVMe przyspiesza ładowanie modelu przy starcie serwera. Model 7B to plik ~4 GB, a modele 70B to 40 GB. Ładowanie z dysku HDD może zajmować kilka minut, z NVMe — kilkanaście sekund. Dla systemów z wieloma modelami przełączanymi dynamicznie (jak nasz OpenClaw router) szybki dysk redukuje czas gotowości.

Fine-tuning i kwantyzacja to dwa sposoby na optymalizację modelu pod kątem sprzętowym. Kwantyzacja jest prostszą ścieżką dla większości wdrożeń.

Najpopularniejszy format w 2026 to GGUF z kwantyzacją Q4_K_M lub Q5_K_M (obsługiwany przez llama.cpp, Ollama, LM Studio). Q4_K_M redukuje VRAM o ~72% względem BF16 przy utracie jakości rzędu 1–3% na benchmarkach ogólnych. Dla zadań specjalistycznych (prawo, finanse, medycyna) warto testować empirycznie — degradacja bywa wyższa dla niszowych domein niż wskazują benchmarki ogólne.

GPTQ i AWQ to formaty kwantyzacji dla kart NVIDIA działające na poziomie jądra GPU, szybsze od GGUF przy tym samym VRAM, ale wymagające kompilatora i większej konfiguracji. Użyteczne dla produkcyjnych serwerów NVIDIA.

bitsandbytes 4-bit (QLoRA) używa się przy fine-tuningu na GPU z ograniczonym VRAM, nie do serwowania. Nie mieszać z formatami inference.

Zasada praktyczna: zaczynaj od Q4_K_M, testuj jakość na swoim zestawie pytań, i awansuj do Q5 lub Q8 tylko jeśli widzisz mierzalny spadek trafności. Dla modeli 7B różnica między Q4 a Q8 jest zwykle minimalna na zadaniach biznesowych.

Decyzja o lokalnym LLM jest decyzją finansową, nie tylko techniczną. Zestawienie dla typowego polskiego wdrożenia:

Konfiguracja produkcyjna dla modelu 13B: serwer z RTX 4090 (9 000 zł), 128 GB RAM (3 000 zł), AMD Ryzen 9 + płyta + zasilanie (5 000 zł), NVMe 2 TB (800 zł). Łącznie sprzęt: ~18 000–22 000 zł jednorazowo. Do tego trzeba doliczyć czas konfiguracji i administracji (zwykle 2–4 dni pracy inżynierskiej na start, 1–2 godziny tygodniowo utrzymania).

Zużycie energii RTX 4090 to ~350–400 W przy pełnym obciążeniu. Przy polskich stawkach prądu (ok. 0,80 zł/kWh) i 8 godzinach pracy dziennie to ok. 65–75 zł miesięcznie.

Porównanie z API w chmurze: przy 100 000 krótkich zapytań miesięcznie (input ~200 tokenów, output ~300 tokenów) koszt API modelu klasy GPT-4o wynosi ok. 1 500–3 000 zł miesięcznie. Lokalny LLM klasy 13B obsługi tych samych zapytań kosztuje tylko energię elektryczną (kilkadziesiąt złotych) po zwrocie inwestycji sprzętowej.

Próg rentowności lokalnego LLM wobec API chmurowego: przy 100 000 zapytań miesięcznie sprzęt zwraca się w 6–12 miesięcy. Poniżej 20 000 zapytań miesięcznie API chmurowe jest zwykle tańsze po uwzględnieniu czasu administracji. Precyzyjny kosztorys dla Twojego zakresu wygeneruje kalkulator inference.

Dla wielu polskich firm kwestia sprzętowa jest wtórna wobec regulacyjnej. RODO nakłada obowiązek kontroli nad danymi osobowymi przetwarzanymi przez systemy AI. Jeśli zapytania kierowane do LLM zawierają dane osobowe (imiona klientów, PESEL, adresy), wysyłanie ich do zewnętrznego API cloudowego wymaga m.in.:

• podpisania umowy powierzenia przetwarzania danych (DPA) z dostawcą API,
• weryfikacji, że serwery dostawcy są w EOG lub że istnieje odpowiednia podstawa transferu do krajów trzecich,
• przeprowadzenia DPIA, jeśli przetwarzanie jest wysokiego ryzyka.

Self-hosting eliminuje te wymagania dla warstwy generowania: LLM działa na własnej infrastrukturze, dane nie opuszczają firmy. To podejście opisujemy szerzej w artykule o self-hosted LLM a RODO. Niezależnie od wyboru sprzętowego, PII powinno być maskowane przed wysłaniem do modelu — to zasada obowiązująca zarówno przy lokalnym LLM, jak i API.

Opisz swój przypadek użycia lokalnego LLM (branża, typ zapytań, szacowany wolumen, wrażliwość danych), a model dobierze konfigurację sprzętową i wskaże optymalną kwantyzację (playground: PII maskowane, zero retencji):

RTX 4090 z 24 GB VRAM obsługuje modele do około 13B w pełnej precyzji lub modele do 34B w kwantyzacji Q4. Dla większości zastosowań biznesowych — asystenci RAG, klasyfikacja dokumentów, odpowiedzi na FAQ — model 7B lub 13B jest wystarczający, a RTX 4090 generuje go z prędkością 50–80 tokenów na sekundę. Jeśli potrzebujesz modelu 70B (np. do bardziej złożonego rozumowania), potrzebujesz albo dwóch kart NVLink, albo karty 48 GB+.

Model 70B w kwantyzacji Q4_K_M zajmuje około 40–42 GB VRAM. Do tego dochodzi bufor dla kontekstu: przy oknie 8K to 2–4 GB, przy 32K to 8–12 GB. Minimalny sprzęt to dwie karty RTX 3090/4090 połączone NVLink (łącznie 48 GB) lub jedna karta profesjonalna 48 GB, np. RTX 6000 Ada lub L40S. Konfiguracja dwukartowa PCIe nie łączy pamięci, więc model 70B Q4 nie zmieści się na 2×24 GB bez NVLink.

Tak, narzędzia takie jak llama.cpp pozwalają uruchomić LLM wyłącznie na CPU. Prędkość generowania wynosi jednak 2–8 tokenów na sekundę dla modeli 7B, co dla aplikacji produkcyjnych (chat, asystent) jest zbyt wolne. Tryb CPU jest użyteczny do testowania, prototypowania i zadań wsadowych bez wymagań czasowych (np. overnight batch summarization). Dla produkcyjnego throughput GPU jest konieczny.

Q4_K_M redukuje VRAM o ponad połowę względem pełnej precyzji przy utracie jakości 1–3% na benchmarkach ogólnych. Q8 redukuje VRAM o ~50% przy stracie poniżej 1%. Zalecany punkt startowy to Q4_K_M: mieści więcej modelu w dostępnym VRAM i w większości zadań biznesowych różnica jakości jest nieistotna. Awansuj do Q5 lub Q8 tylko wtedy, gdy zmierzysz konkretny spadek trafności na własnym zestawie testowym, nie na podstawie abstrakcyjnych benchmarków. Wybór modelu bazowego i kwantyzacji opisuje artykuł o kosztach local vs API LLM.

Najpopularniejsze opcje w 2026 to: Ollama (najprostsza instalacja, API kompatybilne z OpenAI, obsługuje GGUF), vLLM (produkcyjny serwer dla GPTQ/AWQ, optymalizowany pod throughput, wymaga CUDA), llama.cpp z serwerem HTTP (elastyczny, obsługuje CPU i GPU, format GGUF) i LM Studio (interfejs graficzny dla prototypowania). Dla środowisk produkcyjnych Ollama lub vLLM z llm-routerem do zarządzania ruchem i fallback do chmury przy przeciążeniu to sprawdzony wzorzec. Szczegóły architektury opisuje artykuł o firmowym GPT na bazie wiedzy.