Modele językowe AI można uruchamiać w chmurze lub lokalnie na własnym komputerze. W chmurze cała ciężka praca obliczeniowa odbywa się na serwerach dostawcy, a twój komputer wysyła tylko zapytania i odbiera gotowe odpowiedzi. Potrzebujesz wtedy jedynie przeglądarki i sensownego łącza internetowego.
Przy lokalnym LLM całość obciążeń spada na twój sprzęt: CPU, GPU, RAM i dysk. Model musi zmieścić się w pamięci, być szybko wczytywany i obsługiwany przez kartę graficzną. Jeśli konfiguracja jest za słaba, generacja tekstu staje się bardzo wolna, system zaczyna się „krztusić” lub w ogóle nie uda się wczytać modelu.
Lokalny LLM ogranicza cię fizycznymi zasobami: liczbą rdzeni, ilością VRAM i RAM, prędkością SSD oraz przepustowością magistrali. To właśnie dlatego nie każda karta graficzna „uciągnie” AI – nie chodzi o samą moc w grach, ale o połączenie pamięci, wsparcia bibliotek i przepustowości.
Co faktycznie robi GPU przy inferencji tekstu
Przy lokalnym LLM najczęstszy scenariusz to inferencja, czyli generowanie odpowiedzi na podstawie istniejącego modelu. GPU nie „uczy się” wtedy nowych rzeczy, tylko bardzo szybko wykonuje ogromne ilości mnożeń macierzy i operacji na tensora ch.
Karta graficzna ładuje parametry modelu (wagi) do pamięci VRAM i podczas tworzenia kolejnych tokenów operuje na nich podobnie jak przy renderowaniu grafiki 3D, ale bez obrazu – wszystko dzieje się na liczbach. Im więcej parametrów ma model, tym więcej danych musi zmieścić się w VRAM.
GPU przyspiesza generację tekstu nawet kilkukrotnie względem samego CPU, pod warunkiem, że większość modelu faktycznie znajduje się w pamięci karty. Jeżeli VRAM jest zbyt mały, część obliczeń spada na RAM i CPU, co drastycznie zwalnia działanie.
Scenariusze użycia: od notatek po małe projekty RAG
Lokalne LLM nie musi od razu rywalizować z największymi modelami w chmurze. Realne scenariusze na domowym PC to m.in.:
asystent do pisania i streszczania tekstów,
pomocnik programisty (kod + wyjaśnienia),
czat na dokumentach lokalnych (RAG) – np. umowy, notatki, dokumentacja,
narzędzie do generowania pomysłów, zarysów treści, planów.
Do prostego czatu z krótkim kontekstem wystarczy model 3B–7B po kwantyzacji na karcie 8–12 GB. Jeśli chcesz analizować większe pliki, łączyć wiele źródeł, czy używać dłuższych kontekstów, potrzebujesz modelu większego lub lepiej ułożonej konfiguracji – szczególnie pod kątem VRAM i RAM.
Małe projekty RAG (Retrieval-Augmented Generation) – czyli „AI na twoich dokumentach” – wymagają nie tylko samego modelu, ale też przestrzeni na wektory (embeddingi) i szybkiego dysku. Przy dużej bazie plików bottleneckiem może stać się SSD zamiast GPU.
Ograniczenia lokalnych modeli: prywatność kontra moc obliczeniowa
Lokalne LLM wygrywa prywatnością i kontrolą. Wszystkie dane zostają na twoim komputerze, możesz eksperymentować z różnymi modelami bez ograniczeń polityki dostawcy chmury, nie płacisz za API przy dużej liczbie zapytań.
W zamian płacisz w inny sposób: potrzebujesz mocnej karty graficznej, dużej ilości RAM i szybkiego dysku. Im wyższa jakość odpowiedzi i dłuższy kontekst, tym większy model i większe wymagania sprzętowe. Nawet najlepsza karta nie zmieni faktu, że lokalny LLM zazwyczaj będzie słabszy niż największe modele serwerowe – różnica dotyczy głównie jakości złożonych odpowiedzi i „rozumienia” skomplikowanych zadań.
W praktyce trzeba znaleźć balans: model, który mieści się w konfiguracji, zapewnia sensowną jakość i płynność, oraz zestaw PC, który nie zamieni każdego zapytania w 30-sekundowe czekanie na jedno zdanie.
Jak działają lokalne modele językowe od strony zasobów
Parametry modelu, kwantyzacja i formaty (GGUF, GPTQ) w prostym ujęciu
Model językowy opisuje się najczęściej liczbą parametrów – np. 7B, 13B, 34B. Parametr to jedna liczba (waga), która wpływa na to, jak model „liczy” odpowiedzi. Im więcej parametrów, tym model zwykle bardziej złożony i potencjalnie dokładniejszy, ale też cięższy sprzętowo.
Aby zmieścić duże modele na domowym GPU, stosuje się kwantyzację, czyli zapis wag w mniejszej liczbie bitów niż standardowe 16 lub 32. Przykładowo, model 7B w formacie FP16 może zajmować ~14–16 GB, a w 4-bitowym GGUF – kilka gigabajtów. Zyskujesz wtedy możliwość uruchomienia większego modelu na karcie z mniejszym VRAM kosztem niewielkiego spadku jakości.
Najpopularniejsze formaty do lokalnych LLM to:
GGUF – bardzo wygodny, obsługiwany przez llama.cpp, koboldcpp, LM Studio, wiele UI, świetny do inferencji na CPU i GPU,
GPTQ – kwantyzacja dla GPU (zwłaszcza Nvidia), używana w starszych setupach,
inne formaty (AWQ, EXL2) – bardziej specjalistyczne, często lepsze pod konkretne zastosowania lub architektury.
Dla większości osób zaczynających z lokalnym LLM sensownym wyborem są modele w formacie GGUF 4–5 bit. Dobrze balansują jakość, rozmiar i wymagania sprzętowe.
VRAM, RAM i dysk – co gdzie trafia i kiedy braknie miejsca
VRAM karty graficznej to miejsce, gdzie powinny znaleźć się wagi modelu i część buforów roboczych. Jeśli cały model mieści się w VRAM, GPU może liczyć kolejne tokeny szybko i stabilnie. Gdy VRAM jest za mały, program często częściowo przenosi obliczenia do RAM, co mocno spowalnia generację lub powoduje błędy.
RAM przechowuje model przed załadowaniem do VRAM, obsługuje struktury pomocnicze (kontekst, system operacyjny, aplikacje). Przy większych modelach i pracy równoległej (np. przeglądarka + IDE + AI) 16 GB RAM to obecnie minimum, a 32 GB jest znacznie bezpieczniejsze.
SSD NVMe odpowiada za czas ładowania modelu i obsługę dużych zbiorów danych (np. dokumenty w RAG). Model 8–15 GB z dysku talerzowego będzie ładował się dłużej i częściej powodował „zamulanie” systemu w trakcie intensywnego używania.
Znaczenie przepustowości: PCIe, prędkość SSD, magistrale
Karta graficzna komunikuje się z CPU i RAM przez magistralę PCIe. Nowoczesne karty korzystają z PCIe 4.0 x16, ale nawet PCIe 3.0 x16 jest zwykle wystarczające do lokalnego LLM, bo model zasadniczo siedzi w VRAM. Problem zaczyna się, gdy model nie mieści się na karcie i dochodzi do ciągłych transferów danych między RAM a GPU – wtedy przepustowość PCIe zaczyna mocno ograniczać wydajność.
SSD NVMe podłączone przez PCIe (zwykle 3.0 lub 4.0 x4) oferuje zdecydowanie lepszą prędkość ładowania modeli niż dyski SATA. Różnicę szczególnie widać przy większych modelach (powyżej kilku GB) i przy częstym przełączaniu się między różnymi wersjami.
W starszych płytach z ograniczoną liczbą linii PCIe trzeba uważać na obsadzenie wszystkich slotów. Karta w slocie zredukowanym do x4 może tracić trochę na przepustowości, choć w praktyce przy lokalnej inferencji różnice są mniejsze niż w zastosowaniach serwerowych.
Inferencja a trening i fine-tuning pod kątem sprzętu
Inferencja (generowanie odpowiedzi) jest znacznie lżejsza sprzętowo niż pełny trening modelu od zera. W domu skupiamy się niemal zawsze na inferencji i ewentualnie lekkim fine-tuningu (LoRA, QLoRA) na małych zbiorach danych.
Pełny trening dużego modelu wymaga wielu kart z ogromnym VRAM (40–80 GB i więcej na GPU), szybkiej sieci między nimi i wyspecjalizowanych serwerów – to poza zasięgiem przeciętnego PC. Natomiast drobny fine-tuning na 7B–13B czasem można przeprowadzić na mocniejszej karcie 24 GB, choć nawet wtedy trzeba liczyć się z długim czasem obliczeń.
Dobierając sprzęt pod lokalny LLM, zakładaj głównie inferencję i okazjonalny lekki tuning. Nie ma sensu kupować konfiguracji jak mały serwer treningowy, jeśli głównym scenariuszem jest czat i asystent kodu.
Źródło: Pexels | Autor: Andrey Matveev
Kryteria wyboru GPU do lokalnego LLM
VRAM jako parametr krytyczny
Przy AI do gier liczy się głównie moc obliczeniowa (TFLOPS) i przepustowość, ale przy lokalnym LLM najważniejszy jest VRAM. To on decyduje, jaki model w ogóle wczytasz i czy będzie działał wyłącznie na GPU.
Praktyczne poziomy pamięci dla lokalnego LLM:
6–8 GB VRAM – minimalny sens; modele 3B–7B po mocnej kwantyzacji, krótsze konteksty, raczej prostsze zastosowania,
16 GB VRAM – wygodna praca z 13B i podstawowe zabawy z większymi,
24 GB VRAM i więcej – duże modele, kilka instancji równolegle, eksperymenty pół-profesjonalne.
GPU z dużą mocą, ale małym VRAM, jak niektóre starsze karty gamingowe z 6 GB, będzie ograniczone głównie pojemnością, a nie wydajnością.
Przepustowość pamięci, szerokość szyny i cache
Sama ilość VRAM to nie wszystko. Liczy się także przepustowość pamięci (GB/s), szerokość szyny (np. 128-bit, 192-bit, 256-bit) i układ cache’ów na GPU. Te elementy wpływają na to, jak szybko karta zdoła obrabiać dane modelu podczas generacji tokenów.
Przy lokalnych LLM różnice między kartami o podobnym VRAM, ale innej przepustowości często przekładają się na różnicy rzędu kilkunastu–kilkudziesięciu procent w szybkości generacji. Dla prostego domowego użycia nie ma to kluczowego znaczenia, ale przy zawodowej pracy (np. asystent kodu używany cały dzień) każda oszczędzona sekunda się liczy.
Nowe generacje kart (np. RTX 40xx) mają często lepiej zoptymalizowane cache i jednostki Tensor, co ułatwia wykorzystanie ich potencjału przez biblioteki AI. Starsze generacje mogą mieć więcej surowej przepustowości, ale gorsze wsparcie dla nowszych narzędzi.
TDP, kultura pracy i zasilacz
Karty GPU do AI potrafią pracować pod pełnym obciążeniem przez wiele godzin. To mocno obciąża zasilacz, chłodzenie i całą obudowę. TDP (typowe zużycie energii) daje ogólne pojęcie o tym, jaką moc musi dostarczyć zasilacz i jak intensywnie będą pracować wentylatory.
GPU o TDP 150–200 W będzie dużo łatwiejsze do okiełznania niż karta 350 W+. Przy długiej pracy AI hałas i temperatury robią większą różnicę niż przy krótkich sesjach grania. Często lepiej wybrać kartę nieco słabszą, ale chłodniejszą i cichszą, niż topowego potwora, który zmienia biuro w suszarnię.
Dobry zasilacz pod lokalny LLM powinien mieć zapas mocy (nie pracować stale na 90–100% możliwości), sensowną sprawność (80+ Gold lub lepiej) i stabilną linię 12 V. Tanie jednostki z „papierowymi” parametrami to proszenie się o problemy przy długich obciążeniach.
Wsparcie bibliotek: CUDA, ROCm, Metal, DirectML
GPU do AI to nie tylko hardware. Kluczowe jest, czy biblioteki i narzędzia faktycznie obsługują daną kartę. Obecnie najbardziej dojrzałym ekosystemem w kontekście lokalnych LLM na desktopie jest Nvidia + CUDA.
Najważniejsze platformy:
CUDA / cuBLAS / TensorRT (Nvidia) – najczęściej wspierane, najlepsza kompatybilność z narzędziami typu oobabooga, text-generation-webui, LM Studio,
ROCm (AMD) – rozwija się, ale wsparcie na Windows jest ograniczone, często wymaga Linuksa i kombinowania z wersjami,
Metal (Apple) – świetne wsparcie na macOS, ale to inna platforma niż klasyczny PC,
DirectML (Windows) – próba zunifikowania obsługi różnych GPU, w praktyce mniej wydajna i dopracowana niż CUDA.
Jeżeli zależy ci na „bezproblemowym” uruchamianiu modeli i korzystaniu z najpopularniejszych GUI, wybór Nvidii znacząco upraszcza życie. AMD i Intel często wymagają cierpliwości, testowania różnych buildów i pogodzenia się z mniejszą liczbą gotowych poradników krok po kroku.
Nvidia, AMD, Intel – kto do jakiego scenariusza
Nvidia: CUDA, Tensor Cores i dojrzały ekosystem
Nvidia jest obecnie standardem w świecie lokalnych LLM na PC. CUDA i biblioteki takie jak cuBLAS, cuDNN czy TensorRT mają wsparcie w większości popularnych frameworków i interfejsów. Jeśli narzędzie „wspiera GPU”, bardzo często chodzi o GPU Nvidii.
Scenariusze użycia Nvidii: od domowego czatu po małe studio
Nvidia sprawdza się szczególnie tam, gdzie liczy się prostota uruchomienia i szerokie wsparcie narzędzi. Dla większości użytkowników PC z Windowsem jest to najbardziej przewidywalny wybór.
Typowe scenariusze, w których Nvidia daje najwięcej korzyści:
domowy czat i asystent pisania – RTX 3060 / 3060 Ti / 4060 z 12 GB VRAM spokojnie ogarnie modele 7B–13B,
asystent kodu dla programisty – RTX 3070 / 4070 i wyżej, przy pełnej integracji z narzędziami typu OpenAI kompatybilne API lokalne,
pseudo‑serwer w małej firmie – karty 24 GB (RTX 3090, 4090 lub seria profesjonalna) do kilku jednoczesnych użytkowników.
Największy atut Nvidii przy lokalnym LLM to to, że większość gotowych tutoriali, kontenerów Dockera i GUI jest testowana właśnie na tej platformie.
Słabsze strony Nvidii w zastosowaniach lokalnych
Nvidia jest mocna, ale nie zawsze najbardziej opłacalna. Karty z dużym VRAM w nowych generacjach są drogie, a ich potencjał gamingowy bywa przewymiarowany względem tego, czego wymaga sam LLM.
Do tego dochodzą:
wysokie TDP w mocniejszych modelach – 300–450 W oznacza duży zasilacz, mocne chłodzenie i większy hałas,
zajętość rynku wtórnego – popularne modele bywają mocno wyeksploatowane (kopanie, render farmy),
brak tanich kart z ogromnym VRAM w segmencie konsumenckim – powyżej 24 GB wchodzimy w serię profesjonalną z innymi cenami.
Przy czystym nastawieniu na LLM i ograniczonym budżecie konkurencja potrafi czasem zaproponować więcej VRAM za tę samą kwotę.
AMD: dużo VRAMu w dobrej cenie
Karty AMD często wygrywają stosunkiem ceny do ilości VRAM. RX 6800 / 6800 XT z 16 GB, czy nowsze RX 7800 XT to sensowne propozycje dla osób, które nie chcą przepłacać za logo Nvidii.
Najmocniejsze strony AMD przy lokalnych LLM to:
duży VRAM w średnim segmencie cenowym,
stabilny performance w FP16/FP32 przy części zadań,
lepsza opłacalność dla osób, które i tak grają i mogą korzystać z karty do obu zadań.
Przy konfiguracjach mieszanych (gry + lokalne LLM) AMD może być rozsądnym kompromisem, jeśli ktoś akceptuje trochę mniej „plug and play” po stronie AI.
Problemy i ograniczenia AMD w lokalnym LLM
Główny kłopot z AMD to oprogramowanie. ROCm formalnie wspiera część kart, ale na Windowsie działa to fragmentarycznie, a wiele gotowych projektów jest tworzonych przede wszystkim z myślą o CUDA.
Typowe niedogodności:
częstsza konieczność użycia Linuksa, aby uzyskać pełną wydajność,
mniejsza liczba gotowych buildów i poradników krok po kroku,
brak wsparcia w niektórych popularnych GUI (lub tylko częściowe).
Jeżeli ktoś traktuje komputer jak narzędzie, a nie pole do eksperymentów, Nvidia zwykle oszczędza czas. AMD jest bardziej dla osób, które lubią grzebać i nie boją się terminala.
Intel Arc i iGPU – ciekawostka czy realna opcja
Intel wchodzi na rynek GPU z serią Arc i mocniejszymi zintegrowanymi układami graficznymi. W teorii DirectML i wsparcie w ONNX Runtime pozwalają korzystać z nich do lokalnego LLM.
Plusy rozwiązań Intela:
stosunkowo niska cena GPU Arc przy sensownej wydajności w wybranych zadaniach,
zintegrowane GPU w nowych CPU – możliwość eksperymentów bez dodatkowej karty,
dynamicznie poprawiające się sterowniki.
Minusy są jednak spore: mało VRAM, niewielkie wsparcie w popularnych frameworkach i duże rozstrzały wydajności w zależności od zastosowania. Dla poważniejszej pracy z lokalnymi LLM Intel wciąż jest raczej ciekawostką niż pierwszym wyborem.
Jak dużo VRAM naprawdę potrzeba – praktyczne przykłady
Modele 3B–7B: sensowny start na słabszym GPU
Modele o wielkości 3B–7B parametrów są lekkie i dobrze nadają się na pierwsze podejścia do lokalnego LLM. Przy kwantyzacji 4–5 bit zwykle mieszczą się w 4–8 GB VRAM.
Przybliżone wymagania:
3B w 4 bit – okolice 2–3 GB VRAM,
7B w 4 bit – okolice 4–6 GB VRAM.
Na takim modelu da się prowadzić proste rozmowy, generować krótkie teksty, robić podsumowania dokumentów. Jakość w porównaniu z dużymi modelami chmurowymi będzie zauważalnie gorsza, ale do wielu zadań „offline” to wystarcza.
Modele 13B: poziom „domowy z ambicjami”
13B to obecnie popularny kompromis między jakością a wymaganiami sprzętowymi. W wersji 4–5 bit potrzebuje najczęściej 8–12 GB VRAM, zależnie od formatu i długości kontekstu.
W praktyce:
karta 8 GB – model 13B w 4 bit da się czasem upchnąć, ale z krótszym kontekstem i „na styk”,
karta 10–12 GB – stabilna praca, rozsądne konteksty (4k tokenów i więcej),
16 GB i wyżej – możliwość komfortowego użycia kilku instancji lub dłuższych kontekstów.
Jeśli ktoś chce lokalnie zastąpić większość prostych zadań, które dziś realizuje przez API, 13B na karcie 12–16 GB to rozsądne minimum.
Modele 30B i większe: VRAM robi się wąskim gardłem
Przy modelach 30B+ wymagania rosną skokowo. Nawet mocna kwantyzacja nie „magicznie” zmniejszy zapotrzebowania, bo rośnie też ilość pamięci na kontekst i bufor roboczy.
Oszacowania dla 30B w 4 bit:
jedna karta 16 GB – zwykle za mało na pełny model tylko w VRAM, wspomaganie RAM‑em i wyraźny spadek szybkości,
24 GB – granicznie, często trzeba ciąć kontekst lub sięgać po agresywne kwantyzacje,
48 GB (np. 2 × 24 GB z dzieleniem modelu) – realne środowisko do dłuższych kontekstów i stabilnej pracy.
Dla domowego użytkownika modele 30B+ mają sens tylko wtedy, gdy są bardzo konkretnie potrzebne (np. specyficzne testy jakości lub zastosowania badawcze). W typowych zadaniach biurowych dobrze przygotowane 13B radzi sobie zaskakująco dobrze.
Długi kontekst vs VRAM – mniej parametrów, więcej pamięci
Rozmiar modelu to jedno, ale długość kontekstu (np. 4k, 8k, 32k tokenów) także zużywa VRAM. Im dłuższy kontekst, tym więcej pamięci trzeba na bufory sekwencji.
Przykład praktyczny: ta sama karta z 12 GB VRAM może bez problemu obsłużyć model 13B z kontekstem 4k tokenów, ale przy 16k tokenów zacznie brakować miejsca, choć parametrów modelu się nie zmienia. Wtedy trzeba schodzić z rozmiarem modelu lub godzić się na offload do RAM i spadek wydajności.
Jeśli ktoś planuje używać LLM jako czytnika dużych dokumentów czy analizatora repozytoriów kodu, dłuższy kontekst bywa ważniejszy niż kilka dodatkowych miliardów parametrów.
Źródło: Pexels | Autor: Matheus Bertelli
Przegląd przykładowych kart – od minimum do entuzjasty
Minimalny sensowny poziom: 6–8 GB VRAM
Do podstawowych zastosowań nadają się niektóre starsze i tańsze karty:
To są konfiguracje do eksperymentów, prostych modeli 3B–7B i krótkich kontekstów. Dobry wybór, jeśli sprzęt już stoi w obudowie i nie ma budżetu na modernizację.
Rozsądny standard: 10–12 GB VRAM
Dla większości osób, które chcą korzystać lokalnie z LLM regularnie, sensownie wyglądają modele z około 12 GB VRAM:
Nvidia: RTX 3060 12 GB, RTX 4070 (12 GB), niektóre mobilne warianty z 12 GB,
AMD: RX 6700 / 6700 XT (12 GB), część mobilnych Radeonów z 12 GB.
Na takim GPU można wygodnie używać 13B, prowadzić dłuższe rozmowy i wykorzystać LLM jako pomoc w pracy (programowanie, pisanie, analizy). To aktualnie dobry punkt wejścia dla nowych zestawów.
Wyższa półka: 16–24 GB VRAM
Jeśli LLM ma być czymś więcej niż ciekawostką, 16–24 GB VRAM znacząco zwiększa komfort. Daje to możliwość pracy z większymi modelami, dłuższymi kontekstami i kilkoma instancjami jednocześnie.
To poziom dla osób, które planują korzystać z lokalnego LLM zawodowo, hostować modele dla kilku użytkowników lub testować większe architektury 30B przy mocnej kwantyzacji.
Sprzęt entuzjasty i pół‑serwer: więcej niż 24 GB VRAM
Powyżej 24 GB pojawiają się głównie karty profesjonalne oraz rozwiązania multi‑GPU. Mowa o seriach Nvidia RTX A6000, H100 w wersjach serwerowych czy specjalistycznych Radeonach Instinct.
To już obszar, gdzie:
konfiguracja wymaga znajomości Linuksa i narzędzi serwerowych,
całkowity koszt zestawu idzie w górę o rząd wielkości względem domowego PC,
zasilanie i chłodzenie przypomina mały serwerownię.
Dla pojedynczego użytkownika w mieszkaniu to zwykle przerost formy nad treścią. Mały zespół R&D czy software house może jednak na takim sprzęcie realnie testować duże modele z długim kontekstem dla kilku osób naraz.
Przykładowe konfiguracje pod lokalne LLM
Tani start – wykorzystanie istniejącego sprzętu
Jeśli w PC jest już karta 6–8 GB, można zbudować prosty zestaw do lokalnych LLM bez dużych inwestycji. Warunek: minimum 16 GB RAM i szybki SSD (NVMe, choćby 500 GB).
Układ może wyglądać tak:
CPU: 4–6 rdzeni (Ryzen 3600, i5 10. generacji i podobne),
GPU: GTX 1660 / RTX 2060 / RX 5700 8 GB,
RAM: 16 GB DDR4,
SSD: 1 × NVMe 500 GB na system + modele.
Na takim zestawie da się swobodnie testować 7B w 4–5 bitach, używać prostego asystenta tekstowego i pracować nad niewielkimi projektami.
Średni budżet – komfortowy domowy asystent
Dla kogoś, kto składa nowy komputer z myślą o LLM i innych zadaniach, sensownie jest celować w 12–16 GB VRAM i 32 GB RAM.
SSD: kilka NVMe (system, modele, dane) – łącznie 3–4 TB.
Stacja robocza dla twórcy / developera AI
Osoba, która na co dzień programuje, montuje wideo, obrabia zdjęcia i korzysta z LLM do pracy, potrzebuje uniwersalnej stacji roboczej. Nie musi to być od razu sprzęt serwerowy, ale konfiguracja powinna być odporna na obciążenie 24/7.
RAM: 64 GB DDR5 (z możliwością rozbudowy do 96/128 GB),
SSD: 2 × NVMe 2 TB (system + projekty, osobno modele i dane).
Taki zestaw „udźwignie” kilka instancji 13B, okazjonalnie 30B z offloadem, a równolegle montaż wideo czy kompilację większego projektu.
Rola CPU, RAM i dysków – cały zestaw musi być zgrany
CPU – nie tylko liczba rdzeni
LLM na GPU i tak angażuje CPU. Nawet jeśli większość obliczeń robi karta, procesor obsługuje orkiestrację, przygotowanie danych, wątki I/O i sam system.
Do pojedynczego modelu 7B–13B wystarczy 6–8 rdzeni. Powyżej tego prościej jest utrzymać płynność pracy przy kilku usługach jednocześnie.
Znaczenie ma też:
wydajność pojedynczego rdzenia – ważna w jednowątkowych fragmentach kodu i w grach (jeśli masz sprzęt „do wszystkiego”),
wsparcie instrukcji AVX2/AVX‑512 – gdy część obliczeń robi CPU (np. offload warstw, Mistral na CPU),
limity mocy i chłodzenie – długie obciążenie LLM lub treningu szybko wychodzi poza typowe „biurowe” scenariusze.
RAM – ile to „bezpieczne minimum”
System z lokalnym LLM szybko połyka pamięć. Sam model siedzi głównie w VRAM, ale buforowanie dokumentów, narzędzia, przeglądarka, IDE i baza danych też potrzebują miejsca.
Praktyczne poziomy:
16 GB – dolna granica do testów, bez większego zapasu,
32 GB – rozsądny standard do 13B i lekkiej wielozadaniowości,
64 GB – wygodne środowisko do pracy z kilkoma usługami i jednoczesnym offloadem do RAM.
Jeśli planujesz kilka usług (np. lokalny serwer LLM, wektorową bazę danych, Elasticsearch, Docker), 64 GB nie jest fanaberią.
Dyski – szybkość ma znaczenie, ale w określonych miejscach
Dysk NVMe przede wszystkim skraca czas ładowania modeli i przyspiesza pracę przy dużej liczbie plików (repozytoria, korpusy tekstowe). Gdy model już siedzi w VRAM, przepustowość dysku jest mniej istotna.
SSD NVMe / SATA 2 TB+ – modele (różne kwantyzacje, wersje), dane i wektory.
Przy częstym przełączaniu modeli (np. testy wielu wariantów 7B/13B) szybki NVMe realnie skraca czekanie – szczególnie jeśli narzędzia ładują model „od zera” przy każdej zmianie.
Źródło: Pexels | Autor: Andrey Matveev
Zasilacz, chłodzenie i obudowa – sprzęt pod ciągłe obciążenie
Zasilacz – stabilność ważniejsza niż „wat na papierze”
LLM potrafi utrzymać GPU i CPU na wysokim obciążeniu przez wiele godzin. To inny scenariusz niż chwilowe piki w grach.
Dobierając PSU, lepiej zostawić większy margines:
zestaw z pojedynczą kartą klasy 200–250 W – zasilacz 650–750 W dobrej marki,
zestaw z kartą 300–450 W (RTX 4080/4090) – zasilacz 850–1000 W z solidnym zabezpieczeniem linii 12 V.
Przy długim obciążeniu słaby zasilacz objawia się restartami, artefaktami, a niekiedy tajemniczymi błędami podczas generacji.
Chłodzenie GPU i CPU – TDP to nie teoria
Przy LLM GPU często pracuje blisko 100% przez dłuższy czas. Karta z jednym małym wentylatorem w ciasnej obudowie szybko dobije do limitów temperatury i zacznie zbijać taktowanie.
W praktyce pomaga:
wybór modeli GPU z porządnym chłodzeniem (3 wentylatory, masywny radiator),
poprawny obieg powietrza w obudowie (2–3 wentylatory z przodu, 1–2 z tyłu/góry),
dla CPU – chłodzenie powietrzne klasy „tower” lub AIO, jeśli procesor ma wysokie TDP.
Przy dłuższych zadaniach (np. generowanie dużych batchy, indeksowanie dokumentów) temperatury warto mieć na podglądzie – proste narzędzie typu HWinfo, lm-sensors w Linuksie wystarczy.
Obudowa – miejsce na długie karty i przewiew
Nowe GPU potrafią być bardzo długie i grube. W obudowie typu „mini” może fizycznie nie być na nie miejsca, a nawet jeśli wejdą, dopływ powietrza bywa słaby.
Przed zakupem karty warto sprawdzić:
długość i grubość GPU w milimetrach oraz maksymalną długość obsługiwaną przez obudowę,
czy kable zasilające da się poprowadzić bez „dociskania” bocznego panelu,
ile realnie wentylatorów da się zamontować z przodu i na górze.
Przy zestawie „pod AI” obudowa z dobrym przepływem powietrza i filtrami przeciwkurzowymi zwykle daje więcej niż designerskie szkło i LED‑y.
Oprogramowanie i środowisko – jak faktycznie wykorzystać GPU
System: Windows czy Linux pod lokalne LLM
Windows bywa wygodniejszy dla początkujących (GUI, instalatory), ale narzędzia AI często najpierw dostają pełne wsparcie na Linuksie. Zwłaszcza jeśli w grę wchodzi kilka kart, Docker, Kubernetes czy sterowniki ROCm.
Ogólny obraz:
Windows – łatwy start z Nvidia CUDA, Oobabooga, LM Studio, koboldcpp; AMD częściowo przez DirectML,
Linux – lepsze środowisko pod serwerowe zastosowania, multi‑GPU, ROCm, automatyzację i zdalny dostęp (SSH).
Dla jednej karty i prostego użycia (interfejs www, GUI) Windows jest wystarczający. Przy większych konfiguracjach Linuks zyskuje na elastyczności.
Sterowniki GPU – CUDA, ROCm, oneAPI
Żeby model faktycznie liczył na GPU, oprogramowanie musi dogadać się z odpowiednim API.
Nvidia – CUDA + cuDNN, najpełniejsze wsparcie w większości frameworków (PyTorch, TensorFlow, vLLM, llama.cpp przez cuBLAS),
AMD – ROCm (oficjalnie głównie Linux, wybrane karty), alternatywnie DirectML na Windows w niektórych aplikacjach,
Intel – oneAPI / Level Zero, wsparcie wciąż nierówne i zależne od konkretnego narzędzia.
Przed budową zestawu warto sprawdzić listę wspieranych kart i wersje sterowników wymagane przez używane środowisko (np. konkretne wydania PyTorch czy ROCm).
Narzędzia do uruchamiania lokalnych LLM
Żeby nie pisać wszystkiego od zera, najprościej oprzeć się na gotowych serwerach/launcherach. Różnią się podejściem i poziomem integracji z GPU.
Popularne opcje:
llama.cpp / llama-cpp-python – lekkie, szybkie, świetne pod kwantyzowane modele (GGUF), ma backendy dla Nvidia (CUDA), AMD (ROCm, hipBLAS), Intel (oneAPI),
LM Studio – aplikacja desktopowa z GUI (Windows, macOS), instalacja „dla nietechników”, automatyczne pobieranie modeli,
vLLM – zoptymalizowany serwer LLM dla Nvidia, świetny przy wielu równoległych zapytaniach.
Dla pojedynczego użytkownika z jedną kartą zwykle wystarczy LM Studio, text-generation-webui lub prosty launcher llamy. Przy kilku użytkownikach i automatyzacji wygodniejsze jest vLLM na Linuksie.
Formaty modeli i kwantyzacja
Format pliku modelu determinuje, czy i jak zadziała on z daną kartą. Do lokalnych zastosowań najczęściej używa się kwantyzowanych wariantów, które schodzą z dokładnością, żeby zmieścić się w VRAM.
Najczęściej spotykane formaty:
GGUF – następca GGML, flagowy format dla llama.cpp, szeroki wybór kwantyzacji (Q2–Q8),
Safetensors / FP16 – klasyczne modele dla transformers/vLLM, zwykle dużo cięższe, wymagają więcej VRAM,
AWQ, GPTQ – specjalistyczne kwantyzacje pod inferencję (częściej przy większych modelach, głównie na Nvidii).
Do codziennego użytku na karcie 8–16 GB dobrze sprawdzają się kwantyzacje 4–5 bit (np. Q4_K_M w GGUF). Przy 24 GB można myśleć o „półprecyzyjnych” modelach i większych rozmiarach parametrów.
Konfiguracja i test stabilności
Po złożeniu zestawu warto poświęcić chwilę na testy, zanim zacznie się na nim polegać w pracy.
testy syntetyczne – obciążenie GPU (FurMark, OCCT), CPU (Prime95, y-cruncher) po kilkadziesiąt minut,
test praktyczny – dłuższa sesja generacji długich tekstów lub batchowe przetwarzanie dokumentów na wybranym modelu,
monitorowanie temperatur, taktowań i ewentualnych błędów w logach.
Jeśli w trakcie długiej generacji pojawiają się losowe restarty lub błędy CUDA/ROCm bez jasnej przyczyny w kodzie, zwykle winna jest niestabilna konfiguracja: zasilacz, temperatury, zbyt agresywny undervolt/overclock.
Źródła
NVIDIA TensorRT Developer Guide. NVIDIA – Opis inferencji na GPU, optymalizacja modeli i wymagania sprzętowe
CUDA C Programming Guide. NVIDIA – Rola GPU, pamięci i przepustowości PCIe w obliczeniach równoległych
PyTorch Performance Tuning Guide. PyTorch – Zasady wykorzystania GPU, VRAM i CPU przy trenowaniu i inferencji modeli
Transformers Documentation. Hugging Face – Opis modeli LLM, liczby parametrów i wpływu rozmiaru na zasoby
llama.cpp Documentation. llama.cpp project – Praktyczne informacje o GGUF, kwantyzacji i uruchamianiu LLM lokalnie
GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers. arXiv (2022) – Artykuł o metodzie GPTQ i wpływie kwantyzacji na rozmiar modelu
PCI Express Base Specification Revision 4.0. PCI-SIG – Parametry przepustowości PCIe 3.0/4.0 istotne dla transferu CPU–GPU
NVM Express Base Specification 2.0. NVM Express, Inc. – Charakterystyka SSD NVMe i przewaga nad SATA przy dużych modelach
