Jak zbudować domowe laboratorium AI: dobór sprzętu, konfiguracja środowiska i narzędzia open source

Po co w ogóle domowe laboratorium AI i dla kogo ma sens

Najczęstsze powody budowy własnego labu AI

Domowe laboratorium AI ma sens wtedy, gdy chcesz regularnie eksperymentować, a nie tylko „odpalić model raz na próbę”. To nie jest zabawka, tylko mały serwerownia w skali mieszkania.

Typowe motywacje:

• Nauka i przebranżowienie – chcesz wejść w machine learning / MLOps, przerabiasz kursy, projekty z GitHuba i potrzebujesz środowiska, które nie rozpadnie się po pierwszej aktualizacji sterowników.
• Projekty poboczne i prototypy – budujesz bota, analizę tekstu dla niszowej branży, narzędzie do sortowania dokumentów, system rekomendacji pod mały sklep.
• R&D dla małej firmy – testujesz pomysły, zanim wrzucisz je do produkcji w chmurze. Lokalne laboratorium AI to miejsce na szybkie POC bez liczenia każdej godziny GPU w fakturach.
• Prywatność i kontrola – trenujesz lub fine-tuningujesz modele na własnych danych: dokumentach, mailach, kodzie, czatach z klientami. Nie chcesz, żeby wylądowały w cudzej chmurze.
• Eksperymenty „low level” – tuning hyperparametrów, testowanie różnych formatów kwantyzacji, porównania frameworków, optymalizacje pod konkretny GPU.

Do okazjonalnego wygenerowania kilku obrazków wystarczy darmowe konto w chmurze lub aplikacja webowa. Domowy serwer AI ma sens wtedy, gdy robisz to często i chcesz swobodnie dłubać w konfiguracji.

Co realnie da się zrobić w domu, a co lepiej zostawić chmurze

Domowe laboratorium AI nie zastąpi ogromnych farm GPU, ale pozwala na zaskakująco dużo, jeśli dobrze dobierzesz cele.

Na sprzęcie domowym jesteś w stanie wygodnie ogarnąć:

• Inferencję lokalnych modeli językowych (lokalne LLM) w wersjach 3B–13B parametrów: czat, generowanie maili, streszczanie, proste narzędzia dla firmy.
• Fine-tuning / LoRA średnich modeli (np. 7B) na swoich danych tekstowych, jeśli masz sensowną kartę GPU z większym VRAM.
• Stable Diffusion i warianty – generowanie grafik, tekstur, prostych ilustracji, jeśli GPU ma odpowiedni VRAM.
• Modele klasyczne (scikit-learn, XGBoost) na danych tablicowych: scoring leadów, proste prognozy, segmentacja klientów.
• Pipeline’y MLOps dla hobbystów – monitorowanie, wersjonowanie modeli, dockerowe eksperymenty.

Do chmury lepiej oddać:

• Trening lub fine-tuning bardzo dużych modeli (dzie­siątki miliardów parametrów).
• Przetwarzanie ogromnych datasetów (gigabajty–terabajty) w rozsądnym czasie.
• Projekty, które wymagają wielu GPU naraz i klastrowania.

Dobry kompromis: rozwijasz i testujesz wszystko lokalnie, a gdy projekt dojrzeje – przenosisz jedynie produkcyjny trening lub masową inferencję do chmury.

Profile użytkowników: od totalnego startu do data scientist

Inne potrzeby ma ktoś, kto zaczyna od zera, a inne doświadczony programista.

Prosty podział:

• Totalny start – osoba, która zna podstawy obsługi komputera, ale nie programuje lub dopiero zaczyna. Cel: uruchomić lokalny czat LLM, podstawowe eksperymenty w Jupyter Notebook, generowanie obrazów bez grzebania w kernelach Linuxa.
• Programista (web / backend / devops) – zna gita, Dockera, CI/CD, ale nie ma wielkiego doświadczenia z ML. Cel: budowa API nad lokalnym modelem, integracja z istniejącą aplikacją, testowanie nowych frameworków.
• Data scientist / ML engineer – doświadczenie w ML, chęć optymalizacji i pełnej kontroli nad środowiskiem. Cel: szybkie iteracje modeli, eksperymenty z różnymi frameworkami, mały „cluster” w domu.

Dla pierwszej grupy ważniejsza jest prostota i stabilność. Dla dwóch kolejnych – elastyczność, możliwość instalacji dowolnych bibliotek i zarządzania GPU.

Minimalny cel na pierwsze 3 miesiące

Zanim zaczniesz kupować sprzęt, ustal cel na pierwsze 3 miesiące. Jeden, konkretny.

Przykłady realnych celów:

• Uruchomić lokalny czat LLM na swoim komputerze, z własnym interfejsem webowym.
• Postawić Stable Diffusion i przygotować kilka własnych presetów / workflowów dla najczęstszych zadań (np. grafiki do bloga, mockupy aplikacji).
• Zbudować pipeline: wczytanie danych → preprocessing → trening prostego modelu → zapis modelu → dockerowy serwis API.

Ten cel będzie filtrem dla decyzji sprzętowych i technologicznych. Pozwoli uniknąć klasycznego problemu: dużo sprzętu, zero skończonych projektów.

Jak oszacować potrzeby: typy zadań a wymagania sprzętowe

Inferencja vs trening: dwie różne bestie

Inferencja to uruchamianie gotowego modelu: podajesz wejście, dostajesz wynik. Trening (lub fine-tuning) to uczenie modelu na nowych danych.

Z punktu widzenia domowego laboratorium AI to krytyczne rozróżnienie:

• Inferencja jest znacznie lżejsza – często da się ją odpalić na mniejszym GPU lub nawet CPU, szczególnie przy użyciu kwantyzacji.
• Trening jest zasobożerny – mocno używa GPU, VRAM, czasem też dysku (swap, logi, check­pointy). Często generuje dużo ciepła.

Jeśli chcesz głównie korzystać z modeli (lokalne LLM, Stable Diffusion) i lekko je doszlifowywać lekkimi technikami (LoRA, PEFT), Twoje potrzeby są znacznie mniejsze niż przy pisaniu modeli od zera.

Typowe scenariusze a zasoby: LLM, obrazy, tablice

Scenariusze w domowych labach AI zwykle mieszczą się w kilku kategoriach:

• Lokalne modele językowe (LLM) – czat, generowanie tekstu, streszczenia, prosta analiza dokumentów.
• Generowanie obrazów – Stable Diffusion, kontrola stylu, lekkie trenowanie LoRA pod swoje zastosowania.
• Modele klasyczne / małe modele – XGBoost, Random Forest, małe sieci neuronowe dla danych tablicowych lub prostych zadań NLP / CV.

Dla każdego z nich inne zasoby są wąskim gardłem:

• LLM: największy problem to VRAM (lub RAM przy inferencji CPU), potem prędkość pamięci, na końcu CPU. Duży model 7B+ bez kwantyzacji może być ciężki nawet dla jednej porządnej karty.
• Generowanie obrazów: GPU i VRAM są krytyczne, bo to głównie obliczenia macierzowe na tensorach. Dla płynnej pracy przy SD liczysz głównie VRAM i przepustowość GPU.
• Tablice / klasyka: CPU i RAM. GPU jest miłe, ale przy wielu klasycznych taskach to nie jest must have. Dysk i I/O mogą być istotne przy częstym wczytywaniu dużej ilości danych.

Co obciąża CPU, RAM, VRAM i dysk

Uproszczony obraz, który pomaga uniknąć błędnych zakupów:

• CPU – przygotowanie danych, przetwarzanie sekwencji, logika aplikacji, obsługa API, procesy pomocnicze (np. Jupyter, serwer HTTP). Przy inferencji LLM na CPU obciążenie jest ogromne.
• RAM – trzymanie danych w pamięci (batchy, datasetów), cache modeli przy pracy CPU, dodatkowe struktury dla pipeline’ów. Gdy RAM się kończy, system używa dysku (swap) i wszystko dramatycznie zwalnia.
• VRAM – w praktyce największe ograniczenie dla GPU do uczenia maszynowego. Modele, ich gradienty, batch danych – wszystko w VRAM. Jeśli się nie mieści, trzeba kombinować (kwantyzacja, mniejsze batch size, offload na RAM).
• Dysk – przechowywanie modeli, datasetów, logów, checkpointów. Przy słabym dysku (HDD) ładowanie modeli i danych trwa wieki. SSD, szczególnie NVMe, robi ogromną różnicę.

Prosta heurystyka: jeśli aplikacja „mieli” i nie używa mocno GPU, wąskim gardłem jest albo CPU, albo dysk. Jeśli GPU jest „na 100%” i zaczynają się błędy typu out-of-memory – zakończył się VRAM.

Macierz: „chcę robić X → potrzebuję Y”

Pomaga mieć prostą tabelę, żeby nie zgubić się w marketingu producentów:

Przykład: domowy setup do LLM vs Stable Diffusion

Przy lokalnych LLM często da się pójść w większy RAM i mniejszy VRAM, jeśli akceptujesz inferencję głównie na CPU z kwantyzacją (np. GGUF w llama.cpp). To wolniejsze, ale tańsze sprzętowo.

Dla Stable Diffusion lepiej mieć mocniejsze GPU z większym VRAM. Nawet jeśli RAM zostanie „tylko” 32 GB, praca będzie dużo przyjemniejsza niż odwrotny układ (dużo RAM, mało VRAM).

Jeśli masz budżet na jedną poważniejszą rzecz, a zależy Ci na generowaniu obrazów i eksperymentach z LLM, opłaca się celować w kartę z min. 12 GB VRAM i dołożyć RAM później.

Dobór sprzętu: CPU, GPU, RAM, dyski i zużycie prądu

Laptop czy stacjonarny „klocek” pod serwer AI

Dla domowego laboratorium AI wybór jest dość prosty: stacjonarka wygrywa w 90% przypadków.

Argumenty za stacjonarką:

• Większe i chłodniejsze GPU, często znacznie tańsze za tę samą wydajność niż wersje mobilne.
• Łatwy upgrade: można dołożyć RAM, wymienić GPU, dodać kolejny dysk.
• Lepsze chłodzenie i niższy hałas przy dużym obciążeniu.

CPU: ilość rdzeni, instrukcje i sensowne minimum

CPU nie jest pierwszą gwiazdą przy GPU do uczenia maszynowego, ale zbyt słaby procesor potrafi skutecznie zepsuć zabawę.

Założenia praktyczne:

• 6–8 rdzeni to dolna granica dla wygodnej pracy z labem AI (wliczając inne usługi w tle).
• Jeśli planujesz dużo rzeczy „klasycznych” (scikit-learn, preprocessing tekstu, ETL), 12–16 wątków robi różnicę.
• Instrukcje typu AVX pomagają przy inferencji CPU (np. llama.cpp), ale nie trzeba obsesyjnie ich ścigać – większość współczesnych CPU je ma.

Nie przepłacaj za topowy procesor, gdy masz ograniczony budżet. Średnia półka CPU + mocne GPU będzie w większości projektów znacznie lepszym wyborem niż topowy CPU i słaba karta graficzna.

GPU: gamingowe vs „pod AI”, znaczenie VRAM

Do domowego laboratorium AI najczęściej trafiają GPU gamingowe. Są tańsze, szerzej dostępne i mają dobre wsparcie w bibliotekach typu PyTorch / TensorFlow.

Kluczowe parametry z punktu widzenia AI:

Jeśli chcesz pójść krok dalej, pomocny może być też wpis: Laptop do pracy z AI: test wydajności GPU, RAM i dysków w modelach mobilnych.

Jak czytać specyfikację GPU pod kątem AI

Marketing miesza, a do AI liczy się kilka prostych rzeczy:

• VRAM – krytyczne. 8 GB to absolutne minimum, 12 GB daje oddech, 16–24 GB pozwala na poważniejsze eksperymenty (większe LLM, SD z wyższą rozdzielczością, LoRA).
• Przepustowość pamięci – wpływa na realną szybkość trenowania i inferencji. Karty z węższą szyną (np. 128-bit) często „duszą” się mimo przyzwoitego VRAM.
• Wsparcie w ekosystemie – NVIDIA CUDA ma najszersze wsparcie. AMD i Intel nadrabiają, ale częściej trzeba kombinować.
• Pobór mocy (TDP) – przekłada się na rachunki i wymagania zasilacza, a także hałas.

Przy porównywaniu dwóch kart o podobnym VRAM zwykle wygrywa ta z wyższą przepustowością pamięci i lepszym wsparciem sterowników, nawet jeśli ma nieco mniej „suchych” TFLOPS.

NVIDIA vs AMD vs Intel w domowym labie

Przy obecnym ekosystemie praktyczny wybór często wygląda tak:

• NVIDIA – najłatwiejsza droga. CUDA, cuDNN, szerokie wsparcie w PyTorch, TensorFlow, JAX, narzędziach do LLM / SD. Więcej gotowych tutoriali.
• AMD – sensowna opcja, ale wymaga więcej cierpliwości. ROCm działa, lecz nie wszystkie biblioteki i wersje są wspierane. Czasem trzeba kompilować ręcznie.
• Intel GPU – wschodzący ekosystem (oneAPI, OpenVINO). Może być ciekawą opcją pod inferencję, ale przy „klasycznym” deep learningu wsparcie jest mniej dojrzałe.

Jeśli to pierwsze poważniejsze podejście do domowego labu AI i nie chcesz walczyć z konfiguracją, NVIDIA nadal jest najbezpieczniejszym wyborem.

RAM: ile naprawdę wystarczy

Przy RAM łatwo przesadzić lub kupić zbyt mało.

• 16 GB – minimum na start dla prostych eksperymentów i jednej instancji modelu. Szybko poczujesz ograniczenia przy LLM+narzędzia w tle.
• 32 GB – rozsądne minimum dla komfortu. Pozwala trzymać kilka narzędzi, parę kontenerów Dockera i pracować z większymi zestawami danych.
• 64 GB+ – gdy trzymasz w pamięci spore bazy, uruchamiasz kilka modeli naraz, kompilujesz dużo kodu, odpalasz parę VM lub większe eksperymenty z LLM na CPU.

Dwie kości (dual channel) są lepsze niż jedna – CPU „lubi” szerszy kanał pamięci. Zostaw też wolne sloty na przyszłą rozbudowę.

Dyski: SSD, NVMe i organizacja danych

Dyski rzadko są pierwszą myślą przy AI, a potrafią blokować pracę.

• SSD NVMe na system i środowisko AI – szybkie ładowanie modeli, datasetów, start kontenerów.
• Drugi SSD / HDD na archiwalne dane, backupy, starsze checkpointy.
• Pojemność: zestaw kilkunastu–kilkudziesięciu modeli i datasetów spokojnie zjada setki GB. 1–2 TB NVMe na start często okazuje się dobrym punktem.

Przy dużych projektach przydaje się prosty podział: system i narzędzia, katalogi użytkownika, dane i modele – każdy na osobnym wolumenie lub przynajmniej logicznie rozdzielony.

Zasilacz, obudowa, chłodzenie i hałas

Duże GPU + ciągłe obciążenie robią swoje.

• Zasilacz – markowy, z lekkim zapasem mocy (ok. 30% ponad szacowane maksimum). Dla jednej mocnej karty często wychodzi 750–850 W.
• Obudowa – przewiewna, z miejscem na długą kartę i sensownym przepływem powietrza.
• Chłodzenie CPU – porządne powietrzne chłodzenie zwykle wystarczy. Ważniejsza jest kultura pracy niż dodatkowe 5°C mniej.

Jeśli serwer stoi w pokoju, gdzie pracujesz lub śpisz, zwróć uwagę na poziom hałasu wentylatorów pod obciążeniem. Czasem warto wymienić fabryczne wentylatory na cichsze.

Zużycie prądu i planowanie pracy

Domowe laboratorium łatwo zamienia się w elektrycznego potwora, jeśli GPU chodzi non stop.

• Planuj długie treningi na godziny z niższą stawką za prąd (jeśli taryfa to umożliwia).
• Stosuj limity mocy GPU (np. nvidia-smi –power-limit), jeśli nie potrzebujesz 100% wydajności.
• Gaszenie nieużywanych kontenerów / serwisów znacząco obniża zużycie energii i temperaturę w pokoju.

W praktyce wiele zadań inferencyjnych da się odpalać na niższym limicie mocy bez dużej straty w wydajności.

Przykładowe konfiguracje sprzętowe dla różnych budżetów

Budżet „startowy”: ograniczone środki, maksymalna sensowność

Cel: poznać praktyczne ML/AI, bawić się mniejszymi LLM i Stable Diffusion w niższych ustawieniach.

• CPU: 6 rdzeni / 12 wątków (średnia półka poprzedniej generacji).
• RAM: 32 GB (2 × 16 GB).
• GPU: karta z 8–12 GB VRAM (np. poprzednia generacja gamingowa).
• Dysk: 1 TB SSD NVMe + opcjonalny tańszy HDD na archiwum.
• Zasilacz: ok. 650–750 W, markowy.

Taki zestaw pozwala na lokalny czat z modelami 3B–7B po kwantyzacji, podstawowe SD, sensowną pracę z klasycznym ML.

Laptop ma sens w dwóch rolach:

• Jako terminal do pracy (SSH, VS Code Remote), gdy serwer AI stoi w innym pokoju.
• Jako jedyne urządzenie, jeśli często się przemieszczasz i nie chcesz mieć dodatkowej skrzynki. Wtedy wybór warto oprzeć na wynikach typu Laptop do pracy z AI: test wydajności GPU, RAM i dysków w modelach mobilnych.

Dobry kompromis: stacjonarny serwer AI w domu plus lekki laptop, który łączy się do niego po SSH / przez przeglądarkę.

Środek stawki: wygodny koń roboczy

Cel: swobodna praca z SD, LoRA, eksperymenty z 7B–13B, kilka usług w tle.

• CPU: 8–12 rdzeni.
• RAM: 64 GB (4 × 16 GB lub 2 × 32 GB z możliwością rozbudowy).
• GPU: 16–24 GB VRAM (np. nowsza karta gamingowa z szerszą szyną).
• Dysk: 2 TB NVMe (system + modele) + 2 TB HDD/SSD na dane.
• Zasilacz: 750–850 W.

To rozsądny punkt równowagi: lokalny lab, kilka kontenerów Dockera, monitoring, bazy danych – wszystko może działać jednocześnie.

Wyższa półka: mini-serwer do poważniejszych eksperymentów

Cel: intensywne fine-tuning LoRA, większe modele, kilkuosobowy zespół korzystający ze wspólnego serwera.

• CPU: 12–16 rdzeni.
• RAM: 128 GB (lub więcej, jeśli robisz sporo pracy na CPU / duże in-memory pipeline’y).
• GPU: 24–48 GB VRAM (jedno mocne lub dwie mniejsze karty, zależnie od profilu zadań).
• Dysk: 2 × 2 TB NVMe (RAID1 lub osobno: system + dane), dodatkowy duży HDD na backupy.
• Zasilacz: 1000 W+ przy wielu GPU.

Na tym poziomie warto myśleć o backupach, monitoringu temperatury i wydzielonym miejscu w domu (osobne pomieszczenie, dobra wentylacja).

Recykling starego sprzętu jako węzłów pomocniczych

Starsze komputery bez sensownego GPU nadal mogą się przydać.

• Jako serwery pomocnicze do ETL, skryptów cron, hostowania bazy danych, serwisów webowych.
• Jako węzły CPU do równoległego przetwarzania danych (np. dask, Ray, joblib).
• Jako maszyny testowe do ćwiczenia konfiguracji systemu, Kubernetesa, CI.

To dobry sposób, by nie przepłacać za „wszystko w jednym”, gdy GPU i tak będzie siedzieć w jednym, głównym serwerze.

Wybór systemu operacyjnego i podstawowe narzędzia systemowe

Linux, Windows, macOS – praktyczne porównanie

Do domowego labu AI zwykle wygrywa Linux, ale inne opcje też mają swoje miejsce.

• Linux – najlepsze wsparcie sterowników GPU pod AI, łatwa automatyzacja, serwerowy profil pracy. Dobra baza pod Docker, Kubernetesa, narzędzia CLI.
• Windows – wygodny dla osób przyzwyczajonych do tej platformy. Z WSL2 da się zbudować sensowny lab, choć sterowniki GPU i integracja czasem sprawiają kłopoty.
• macOS – świetny jako laptop/terminal, szczególnie na Apple Silicon (M1/M2/M3). Do głównego serwera AI rzadziej spotykany, ze względu na GPU i koszty.

Popularna kombinacja: serwer z Linuxem + laptop na Windows lub macOS jako terminal z VS Code / SSH.

Popularne dystrybucje Linux do AI

Nie trzeba kombinować – proste, mainstreamowe dystrybucje zwykle wystarczą.

• Ubuntu LTS – najczęstszy wybór. Dobre wsparcie sterowników NVIDIA, masa tutoriali.
• Debian – stabilność ponad wszystko, kosztem nieco starszych pakietów.
• Fedora – nowsze wersje pakietów, dobre dla osób lubiących świeższe środowisko.

Na starcie wystarczy jedna, popularna dystrybucja. Najwięcej problemów generuje mieszanie egzotycznych rozwiązań, nie sam Linux.

Podstawowa konfiguracja systemu pod serwer AI

Po instalacji systemu warto od razu ustawić kilka rzeczy:

• Aktualizacja systemu i podstawowych pakietów.
• Instalacja sterowników GPU (NVIDIA: oficjalne repo lub instalator, AMD: ROCm zgodny z wersją systemu).
• Utworzenie konta użytkownika do pracy (bez logowania się ciągle na root).
• Konfiguracja SSH (klucze zamiast haseł, niestandardowy port, jeśli wystawiasz maszynę poza dom).

Na tym etapie system nie musi być „idealny” – ważne, by był przewidywalny i powtarzalny. Resztę procesów (modele, serwisy) i tak opakujesz w kontenery lub wirtualne środowiska.

Narzędzia systemowe, które ułatwiają życie

Kilka drobiazgów potrafi mocno uprościć codzienną pracę:

• htop / btop – monitorowanie CPU, RAM i procesów.
• nvtop, nvidia-smi – podgląd obciążenia GPU, VRAM, temperatur.
• tmux / screen – podtrzymywanie sesji terminalowych (np. treningi) po rozłączeniu SSH.
• rsync – synchronizacja danych między maszynami i backupy.
• git – wersjonowanie kodu i konfiguracji.

Przy serwerze, który działa 24/7, sens ma też prosty monitoring (np. Prometheus + Grafana) albo lekkie narzędzia typu Netdata.

Menedżer środowisk i zależności: conda, venv, Docker

Po co w ogóle izolować środowiska

Różne projekty mają różne wersje Pythona, PyTorch, sterowników, bibliotek systemowych. Mieszanie tego w jednym globalnym środowisku kończy się błędami nie do odtworzenia.

Izolacja środowisk daje:

• możliwość testowania różnych wersji frameworków bez psucia innych projektów,
• powtarzalność – nowa maszyna w labie dostaje dokładnie to samo środowisko,
• łatwiejsze czyszczenie – stare środowisko można po prostu usunąć.

venv: najprostsze wirtualne środowiska Pythona

venv to wbudowany mechanizm Pythona do tworzenia izolowanych środowisk.

• Plusy: wbudowane, lekkie, proste.
• Minusy: nie zarządza pakietami systemowymi ani różnymi wersjami Pythona.

Przykładowy workflow:

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Dobre dla mniejszych projektów, API, skryptów narzędziowych, gdzie zależności są umiarkowane.

conda / mamba: cięższa, ale wygodna artyleria

conda (i szybsza mamba) łączy zarządzanie środowiskami Pythona i pakietami systemowymi (np. różne wersje bibliotek C).

• Plusy: obsługa wielu wersji Pythona, integracja z CUDA toolkit, gotowe pakiety binarne.
• Minusy: spore zużycie dysku, wolniejsze operacje (mamba ten problem znacznie zmniejsza).

Typowe użycie przy AI:

mamba create -n lab-ai python=3.11 pytorch torchvision pytorch-cuda=12.1 -c pytorch -c nvidia
mamba activate lab-ai

W większości projektów deep learningowych na początku wygodniej pracuje się z conda/mamba niż z gołym venv.

Docker: kontenery jako jednostka projektu

Kontenery jako standardowy sposób pakowania projektów

Docker traktuj jak „pudełko” z całym środowiskiem: systemem, bibliotekami, serwerem modelu. Na serwerze wystarczy Docker i sterowniki GPU, reszta siedzi w obrazie.

Podstawowe zalety:

• powtarzalność – ten sam obraz działa tak samo na desktopie i serwerze,
• izolacja – różne projekty mogą mieć różne wersje CUDA, Pythona, systemu,
• łatwe wdrażanie – wystarczy docker run ... z odpowiednimi portami i wolumenami.

Przykład minimalnego Dockerfile dla API z modelem:

FROM pytorch/pytorch:2.2.0-cuda12.1-cudnn8-runtime

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
CMD ["python", "serve.py"]

Do korzystania z GPU na hoście z NVIDIA dochodzi jeszcze konfiguracja pluginu nvidia-container-toolkit i uruchamianie kontenera z flagą --gpus all.

Kiedy co wybrać: venv vs conda vs Docker

Nie ma sensu używać najcięższego narzędzia do wszystkiego. Prosty podział:

• venv – małe projekty, skrypty, narzędzia CLI, brak CUDA.
• conda/mamba – praca badawcza, eksperymenty, lokalny trening z GPU.
• Docker – serwisy wystawione na sieć, współdzielone środowiska, kilka osób na jednym serwerze.

Częsty układ w domowym labie: lokalnie kod + conda, na serwerze gotowy obraz Dockera z API modelu.

Kluczowe biblioteki i frameworki: od PyTorch po ekosystem Hugging Face

PyTorch jako główny „silnik” obliczeń

Większość otwartych modeli i przykładów korzysta z PyTorch. Ułatwia to życie: jedna główna biblioteka, masa tutoriali, dobre wsparcie GPU.

Do typowego labu wystarczy:

• torch + torchvision (CV) + torchaudio (audio),
• instalacja dopasowana do CUDA na twojej karcie (przez conda albo oficjalne koło pip).

Dla prostych zadań CPU też wystarczy, ale GPU daje wielokrotny przyspieszacz nawet przy małych modelach.

JAX i inne alternatywy

JAX bywa ciekawy przy badaniach nad nowymi architekturami, gradientami, optymalizacją. W domowym labie pojawia się rzadziej, głównie gdy ktoś świadomie wybiera ten ekosystem.

TensorFlow w projektach produkcyjnych nadal żyje, ale w świecie open source i LLM rządzi PyTorch. Jeżeli nie masz specjalnych powodów, nie rozpraszaj się na wiele frameworków naraz.

Ekosystem Hugging Face: modele, tokenizery, pipeline’y

Hugging Face to centrum gotowych modeli, kodu i narzędzi. Do domowego labu kluczowe są trzy elementy:

• transformers – ładowanie i używanie LLM, modeli do NLP, wizji, audio,
• datasets – pobieranie, przetwarzanie i caching zbiorów danych,
• huggingface_hub – obsługa logowania, pobierania i wersjonowania modeli.

Minimalny przykład użycia lokalnego modelu tekstowego:

from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "TinyLlama/TinyLlama-1.1B-Chat-v1.0"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype="auto",
    device_map="auto"
)

inputs = tokenizer("Hello, how are you?", return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_new_tokens=50)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Przy większych modelach dochodzi jeszcze kwantyzacja (bitsandbytes, GPTQ, AWQ) albo ładowanie przez biblioteki specjalistyczne (llama.cpp, vLLM).

W tym miejscu przyda się jeszcze jeden praktyczny punkt odniesienia: Open source w IoT: najlepsze narzędzia do budowy prywatnego smart domu.

Biblioteki do klasycznego ML i przetwarzania danych

Nawet gdy skupiasz się na LLM, przydaje się podstawowy zestaw narzędzi do danych:

• numpy, pandas – obróbka tabelaryczna, szybkie prototypy,
• scikit-learn – klasyfikacja, regresja, metryki, train/test split,
• matplotlib / seaborn – proste wykresy, diagnostyka.

Do pracy z większymi zbiorami możesz dołożyć polars albo dask, ale na start wystarcza klasyka.

Narzędzia do trenowania i fine-tuningu

Trenowanie od zera w domu rzadko ma sens, ale fine-tuning i LoRA już tak. Kilka praktycznych bibliotek:

• peft – LoRA i inne metody parameter-efficient fine-tuning na modelach Hugging Face,
• trl – RLHF, SFT, DPO i podobne podejścia do dostrajania zachowania modeli,
• accelerate – uproszczone zarządzanie device’ami, mieszana precyzja, multi-GPU.

Dla Stable Diffusion przydają się narzędzia LoRA/finetune specyficzne dla danego UI (np. pakiety w Automatic1111, ComfyUI) lub biblioteki pokroju diffusers.

Open source narzędzia do lokalnych LLM i generowania obrazów

Llama.cpp i pochodne: lekkie LLM na CPU i małe GPU

llama.cpp pozwala uruchamiać modele w formacie GGUF na CPU i GPU, z różnymi stopniami kwantyzacji. Dobra opcja na słabszy sprzęt i eksperymenty offline.

Podstawowy workflow:

• pobranie skwantyzowanego modelu GGUF (np. z Hugging Face),
• kompilacja llama.cpp z obsługą twojej platformy (OpenBLAS, CUDA, Metal),
• uruchomienie main z odpowiednimi parametrami kontekstu i wątków.

Dla wygody można użyć jednego z webowych interfejsów opartych o llama.cpp (np. text-generation-webui z backendem, czy wbudowanych frontów w projektach desktopowych).

Ollama i proste zarządzanie lokalnymi modelami

Ollama to „menedżer” LLM na desktopie/serwerze. Instalujesz binarkę, a modele pobierasz jedną komendą, np. ollama pull llama3. Uruchamia lokalne API HTTP, z którego może korzystać dowolny klient.

Zalety w domowym labie:

• łatwa instalacja na macOS, Linux, czasem Windows,
• proste aktualizacje modeli,
• wbudowany mechanizm kwantyzacji i wybierania wariantów.

Dla osoby nietechnicznej Ollama bywa najprostszą bramą do lokalnych LLM. Dla bardziej zaawansowanych to wygodny backend, na którym buduje się własne UI lub integracje.

Serwery LLM oparte o Hugging Face i vLLM

Jeśli masz mocniejsze GPU, sens ma serwowanie modeli przez biblioteki zoptymalizowane pod throughput:

• text-generation-inference (TGI) od Hugging Face – gotowy serwer LLM w Dockerze,
• vLLM – biblioteka/serwer z efektywnym zarządzaniem KV cache, służy do obsługi wielu równoległych zapytań.

Typowy scenariusz: serwer na Linuxie z Dockerem, kontener TGI z jednym większym modelem, do tego małe API proxy i prosty front-end webowy. Domowy „ChatGPT” na własnej infrastrukturze.

Stable Diffusion: UI, backendy i modele

Do generowania obrazów domowe laby najczęściej używają Stable Diffusion. Kilka popularnych interfejsów:

• Automatic1111 webui – klasyka, masa rozszerzeń, LoRA, ControlNet,
• ComfyUI – podejście „node graph”, większa elastyczność pipeline’ów,
• InvokeAI – bardziej uporządkowany interfejs, dobre zarządzanie workflow.

Na backendzie i tak zwykle siedzi diffusers lub pokrewne biblioteki. Podstawowy wymóg: karta z sensownym VRAM (8–12 GB to komfortowe minimum dla nowszych checkpointów).

Narzędzia do zarządzania wieloma modelami i interfejsami

Gdy w labie pojawia się kilka modeli i UI, przydaje się „warstwa organizacyjna”:

• text-generation-webui – jedno UI do wielu backendów (llama.cpp, transformers, GPTQ, AWQ),
• lokalne reverse proxy (np. nginx, caddy) – wygodne adresy URL dla poszczególnych usług,
• narzędzia do notatek i promptów (np. Obsidian, wiki) – spis konfiguracji, presetów, dobrych ustawień.

W praktyce jeden porządnie skonfigurowany webui (dla tekstu) i jedno dla SD wystarczą na długo. Reszta to głównie porządek w folderach modeli i backupach.

Logowanie, wersjonowanie i obserwacja eksperymentów

Przy większej liczbie eksperymentów łatwo się zgubić. Kilka lekkich narzędzi:

• Weights & Biases albo MLflow – logowanie metryk, hyperparametrów, artefaktów,
• TensorBoard – szybki podgląd lossów, obrazów, embeddingów,
• proste skrypty w Pythonie zapisujące configi i wyniki w yaml/json.

Nawet w domowym labie spójne nazewnictwo eksperymentów i katalogów robi ogromną różnicę, szczególnie gdy wracasz do projektu po kilku miesiącach.

Najczęściej zadawane pytania (FAQ)

Po co w ogóle budować domowe laboratorium AI, skoro są darmowe narzędzia w chmurze?

Domowe laboratorium AI ma sens wtedy, gdy regularnie eksperymentujesz z modelami, a nie tylko uruchamiasz je okazjonalnie. Daje stałe, przewidywalne środowisko, które nie znika po zakończeniu darmowego triala ani nie zmienia się przy każdej aktualizacji usługi.

Lokalny lab jest też lepszy, gdy pracujesz na prywatnych danych (maile, dokumenty, kod) i nie chcesz ich wysyłać do zewnętrznej chmury. Sprawdza się również przy R&D dla małych firm, gdzie dużo testujesz lokalnie, a do chmury przenosisz tylko gotowe, produkcyjne rozwiązania.

Jaki minimalny sprzęt potrzebuję, żeby uruchomić lokalny czat z modelem LLM?

Dla modeli 3B–7B w wersjach skwantowanych sensownym minimum jest CPU 6–8 rdzeni, 32 GB RAM i szybki dysk SSD. GPU z 8–12 GB VRAM nie jest obowiązkowe, ale bardzo przyspiesza pracę i odciąża RAM.

Przy braku dedykowanego GPU inferencja pójdzie na CPU i RAM będzie wąskim gardłem, więc nie schodź poniżej 32 GB, jeśli chcesz normalnie pracować, a nie czekać minutami na odpowiedzi modelu.

Czy do domowego laboratorium AI muszę mieć mocne GPU, czy wystarczy CPU?

Do prostych eksperymentów, modeli klasycznych (XGBoost, Random Forest) i małych LLM na CPU wystarczy szybki procesor i dużo RAM. Do generowania obrazów (Stable Diffusion) i komfortowej pracy z modelami językowymi GPU z sensownym VRAM jest praktycznie konieczne.

Prosty podział: jeśli planujesz głównie inferencję małych modeli i klasyczne ML na tablicach – możesz zacząć bez GPU. Jeśli chcesz Stable Diffusion, fine-tuning LoRA i szybką inferencję LLM 7B+, zainwestuj w GPU z min. 8–12 GB VRAM.

Co lepiej robić lokalnie, a co od razu przerzucić do chmury?

Lokalnie sprawdza się inferencja średnich modeli językowych (3B–13B), Stable Diffusion, trenowanie lekkich LoRA, a także klasyczne modele ML na danych tablicowych. Tu wystarczy jedna porządna maszyna i możesz eksperymentować bez liczenia każdej godziny GPU.

Do chmury warto oddać trening lub fine-tuning bardzo dużych modeli (dziesiątki miliardów parametrów), przetwarzanie ogromnych datasetów oraz projekty wymagające kilku GPU i klastrowania. Dobry układ: rozwijasz i testujesz wszystko w domu, a do chmury idzie tylko ciężki trening lub masowa inferencja.

Jak oszacować, czy bardziej ogranicza mnie CPU, RAM, VRAM czy dysk?

Jeśli aplikacja mocno zużywa CPU, a GPU się nudzi, wąskim gardłem jest procesor lub dysk (przy wolnym HDD). Gdy RAM się kończy i system zaczyna ostro korzystać ze swapu, wszystko zwalnia niezależnie od reszty sprzętu.

Przy pracy z GPU najczęściej ograniczeniem jest VRAM: gdy zaczynają się błędy typu out-of-memory, model lub batch danych po prostu się nie mieszczą. Przy powolnym ładowaniu modeli i danych problemem zwykle jest wolny dysk – tu SSD NVMe robi ogromną różnicę.

Jaki cel ustawić sobie na pierwsze 3 miesiące budowy domowego labu AI?

Najlepiej wybrać jeden konkretny, mierzalny cel zamiast „nauczyć się AI”. Przykłady: postawić lokalny czat LLM z prostym interfejsem webowym albo uruchomić Stable Diffusion i przygotować kilka gotowych workflowów do swoich zadań (np. grafiki na bloga).

Dobrym celem jest też pełny, ale prosty pipeline: wczytanie danych, preprocessing, trening modelu, zapis i wystawienie go jako dockerowy serwis API. Taki jeden projekt dużo lepiej prowadzi decyzje sprzętowe niż kupowanie mocnej maszyny „na wszelki wypadek”.

Jakie środowisko jest lepsze na start: Windows, Linux czy może tylko Docker?

Dla totalnego startu często wygodniejszy jest Windows z WSL lub gotowymi paczkami typu „one-click installer” do Stable Diffusion czy lokalnych LLM. Daje mniej tarcia na początku i pozwala skupić się na efektach, a nie na konfiguracji systemu.

Dla programistów i data scientistów lepszy będzie Linux (natywnie lub jako główny system) plus Docker do izolowania eksperymentów. Ułatwia to zarządzanie sterownikami GPU, bibliotekami ML i późniejsze przenoszenie projektów na serwery czy do chmury.

Najważniejsze wnioski

• Domowe laboratorium AI ma sens przy regularnych eksperymentach i długoterminowej pracy z modelami, a nie do okazjonalnego generowania obrazków czy jednorazowego testu LLM.
• Główne motywacje to: nauka i przebranżowienie, prototypowanie projektów pobocznych, R&D dla małych firm, ochrona prywatnych danych oraz eksperymenty niskopoziomowe z modelami i infrastrukturą.
• Na sprzęcie domowym da się komfortowo robić inferencję średnich LLM (3B–13B), lekkie fine-tuning/LoRA, Stable Diffusion, klasyczne modele ML i hobbystyczne pipeline’y MLOps; ciężki trening dużych modeli i przetwarzanie ogromnych datasetów lepiej oddać do chmury.
• Rozsądnym podejściem jest rozwój i testy lokalnie, a dopiero dojrzałe projekty (produkcja, masowa inferencja, trening dużych modeli) przenosić do chmury, żeby nie przepalać budżetu na GPU.
• Różne profile użytkowników (totalny start, programista, data scientist/ML engineer) mają inne priorytety: od maksymalnej prostoty i stabilności po pełną elastyczność i granularną kontrolę nad GPU i środowiskiem.
• Przed zakupem sprzętu kluczowe jest ustalenie jednego, konkretnego celu na pierwsze trzy miesiące (np. lokalny czat LLM z własnym UI albo prosty pipeline treningu modelu), żeby uniknąć scenariusza „dużo sprzętu, zero gotowych projektów”.