Budowa klastra obliczeniowego z Raspberry Pi pod AI: sensowny eksperyment czy strata czasu

Dlaczego w ogóle ktoś chce budować klaster AI z Raspberry Pi?

Motywacje: od domowego „superkomputera” po projekt dyplomowy

Budowa klastra obliczeniowego z Raspberry Pi pod AI kusi z kilku powodów naraz. Po pierwsze, jest to bardzo namacalny projekt: z pudełka po butach, kilku płytek i switcha sieciowego nagle powstaje coś, co wygląda jak miniaturowe data center. Po drugie, Raspberry Pi jest stosunkowo tanie i powszechnie dostępne, więc wiele osób traktuje taki klaster jako przystępne wejście w świat obliczeń rozproszonych. Po trzecie, hasło „klaster AI” dobrze prezentuje się w opisie projektu na studia, w portfolio czy na LinkedIn – to widać od razu lepiej niż kolejny „todo app” w React.

Dla części osób motywacją jest także pełna kontrola nad środowiskiem. Klaster Raspberry Pi stoi fizycznie na biurku, można go dotknąć, przepiąć kable, obserwować diody LED. To zupełnie inne doświadczenie niż bezosobowa chmura. W edukacji ma to duże znaczenie: studenci widzą, że za słowem „klaster” stoi faktyczna infrastruktura, a nie magiczne API w konsoli AWS.

Trzecia grupa to entuzjaści DIY i hardware’u, którzy po prostu szukają ambitniejszego projektu weekendowego. Dla nich klaster to naturalny kolejny krok po „inteligentnym domu” czy pojedynczym serwerku domowym. Dodanie etykiety „pod AI” to często sposób, aby nadać projektowi dodatkową powagę – choć nie zawsze idzie za tym rzeczywista analiza sensowności obliczeniowej.

Mity: „prawie jak data center” kontra rzeczywistość

Wokół konstrukcji typu „klaster Raspberry Pi pod AI” narosło kilka mitów. Najczęstszy: wystarczy połączyć kilkanaście malinek, aby uzyskać moc „prawie jak mały serwer w data center”. W praktyce sumaryczna moc CPU takiego klastra jest niewielka w porównaniu z jedną współczesną kartą GPU, a ograniczenia pamięci, sieci i I/O powodują, że zysk ze skalowania rozkłada się w czasie szybciej niż entuzjazm konstruktora.

Drugi mit to przeświadczenie, że samo słowo „klaster” automatycznie oznacza drastyczny skok wydajności. Tymczasem klaster jest narzędziem – jeśli aplikacja nie została napisana lub skonfigurowana tak, aby wykorzystywać równoległość i rozproszenie, zysk będzie symboliczny, czasem wręcz ujemny (narzut na komunikację między węzłami potrafi zjeść większość zysków).

Trzeci mit dotyczy samej sztucznej inteligencji: panuje przekonanie, że „AI to po prostu sporo mnożeń i dodawań, więc więcej małych CPU = dużo AI”. Z punktu widzenia teorii to nie jest całkiem nieprawda, ale w praktyce współczesne biblioteki deep learning są optymalizowane pod konkretne architektury (GPU, TPU, NPU). Przerzucenie ich na klaster małych CPU bez odpowiednich usprawnień rzadko kończy się spektakularnym sukcesem, zwłaszcza gdy celem jest trenowanie modeli.

Raspberry Pi Cluster jako narzędzie popularyzacji obliczeń rozproszonych

Przy całej swojej ograniczonej mocy, projekty klastra Raspberry Pi mają jedną ogromną zaletę: są znakomitym narzędziem popularyzacji obliczeń rozproszonych. Pokazanie na warsztatach lub konferencji mini‑racka z dwudziestoma malinkami działa na wyobraźnię znacznie mocniej niż slajd z diagramem Kubernetesa. Do tego można pokazać w praktyce:

• jak działa komunikacja między węzłami (MPI, REST, gRPC),
• jak rozdzielane są zadania i jak zachowuje się system przy awarii jednego z nich,
• jak skalowanie w poziomie wpływa na czas wykonania zadań,
• jak działają proste schedulery zadań i load‑balancery.

Tego typu projekty są bezpiecznym poligonem doświadczalnym. Można eksperymentować z konfiguracją sieci, systemami plików rozproszonych, konteneryzacją, nie ryzykując dużych kosztów ani katastrofy produkcyjnej. Z punktu widzenia nauki i zrozumienia koncepcji klastra, Raspberry Pi jest często strzałem w dziesiątkę.

AI jako katalizator mody na domowe „serwerownie”

Rozwój sztucznych sieci neuronowych i spektakularne sukcesy AI (od rozpoznawania twarzy po modele językowe) rozbudziły oczekiwania hobbystów i studentów. Skoro wielkie firmy budują ogromne klastry GPU do trenowania modeli, naturalną reakcją jest próba zbudowania „mini wersji” u siebie. Raspberry Pi, jako najbardziej znany mini‑komputer, od razu wpada tu w oko.

W efekcie powstała cała subkultura domowych „serwerowni AI” zbudowanych na Raspberry Pi: od kilku węzłów rozsypanych po biurku po starannie zorganizowane struktury przypominające małe racki. Wizualnie robi to znakomite wrażenie, a funkcjonalnie – może mieć sens, o ile cel jest jasno zdefiniowany. Jeśli celem jest demonstracja koncepcji, edukacja czy eksperyment z inferencją małych modeli, klaster Raspberry Pi potrafi dać sporo satysfakcji. Jeśli oczekiwania są zbliżone do „zastąpię sobie GPU‑kę” – czeka rozczarowanie.

Wymagania AI a możliwości Raspberry Pi – zderzenie oczekiwań z fizyką

Jakich zasobów potrzebuje trenowanie sieci neuronowej

Trenowanie nowoczesnych sieci neuronowych, nawet tych średniej wielkości, to proces bardzo zasobożerny. Kluczowe składniki to:

• Moc obliczeniowa – ogromna liczba operacji macierzowych i wektorowych (FLOPS). Dlatego praktycznie cały przemysł AI oparł się na GPU, TPU i innych układach wyspecjalizowanych w obliczeniach równoległych.
• Pamięć RAM / VRAM – modele i batch danych muszą zmieścić się w pamięci. Nawet stosunkowo niewielki model CNN może potrzebować kilkunastu gigabajtów RAM przy treningu na większych obrazach i rozsądnym batch size.
• Przepustowość I/O – dane treningowe trzeba nieustannie ładować z dysku, przetwarzać, buforować. Słabe I/O potrafi skutecznie „zadusić” nawet mocny procesor.
• Szybka komunikacja między węzłami – przy trenowaniu rozproszonym gradienty i parametry modelu latają między maszynami bez przerwy. Duże opóźnienia i niska przepustowość sieci bardzo szybko niszczą skalowalność.

Kluczowa różnica między treningiem a inferencją: trening zwykle wymaga znacznie więcej zasobów. Inferencja (wykonanie obliczeń na gotowym modelu) może być dużo lżejsza, szczególnie jeśli model został zredukowany (quantization, pruning) i zoptymalizowany do pracy na CPU.

Trening vs inferencja, małe modele vs potwory typu LLM

Aby zrozumieć sensowność klastra Raspberry Pi pod AI, trzeba rozdzielić kilka klas zadań:

• Małe modele: klasyfikacja prostych obrazów (np. 32×32), proste sieci MLP, niewielkie CNN, skromne modele NLP (np. intenty w chatbotach). Trening takich modeli na CPU jest możliwy, choć bywa żmudny.
• Średnie modele: typowe CNN do rozpoznawania obrazów w rozdzielczości kilkuset pikseli, sensowne modele NLP bazujące na LSTM/GRU, lekkie transformatory. Tu zaczynają się wymagania pamięciowe i potrzeba przyspieszaczy (GPU).
• Duże modele: nowoczesne LLM, bardzo głębokie CNN, wielomodalne architektury. Te projekty zakładają użycie GPU/TPU praktycznie od pierwszego slajdu w specyfikacji.

Raspberry Pi może mieć sens przy małych modelach i częściowo przy inferencji średnich modeli (po silnej optymalizacji). Próba trenowania średnich i dużych modeli na klastrze złożonym z wielu Pi jest zderzeniem z fizyką i charakterystyką bibliotek AI – w praktyce czas treningu liczony jest często w dniach lub tygodniach, podczas gdy na pojedynczym GPU może chodzić o godziny.

Charakterystyka Raspberry Pi – CPU ARM, pamięć, brak GPU

Standardowe Raspberry Pi (szczególnie generacje 3 i 4) wyposażone jest w procesory ARM o relatywnie niskim TDP i ograniczonej liczbie rdzeni. Typowe parametry:

• 4–8 rdzeni ARM, częstotliwość w okolicach 1–2 GHz,
• pamięć RAM: 2–8 GB, dzielona z GPU,
• zintegrowane, bardzo proste GPU, nieprzystosowane do trenowania sieci neuronowych w sensownym tempie,
• interfejs sieciowy zwykle 1 Gbit/s (lub wolniejszy w starszych modelach),
• główny nośnik danych: karta microSD lub dysk USB.

Same liczby nie brzmią tragicznie, ale trzeba je zestawić z realnymi wymaganiami bibliotek deep learning, które powstawały głównie z myślą o procesorach x86 z dużą ilością RAM i mocnych kartach GPU. Raspberry Pi nadrabia niską ceną i energooszczędnością, ale w kategorii „surowa moc obliczeniowa do trenowania AI” wypada blado.

Prosty przykład: trening małej sieci na Raspberry Pi vs GPU

Wyobraźmy sobie niewielką konwolucyjną sieć neuronową do rozpoznawania prostych obrazków (np. dane w stylu CIFAR‑10): kilkanaście warstw, kilka milionów parametrów. Na współczesnej karcie GPU z biblioteka typu PyTorch czy TensorFlow taki model potrafi wyszkolić się w sensownym czasie – często w granicach kilkunastu–kilkudziesięciu minut lub paru godzin, zależnie od parametrów.

Ten sam model uruchomiony na pojedynczym Raspberry Pi nagle zaczyna liczyć epo­ki wyraźnie dłużej. Mówimy o czasie liczonym w godzinach lub dniach, a przy zwiększeniu rozmiaru danych – o jeszcze dłuższych przebiegach. Dodanie kilku kolejnych Pi i próba trenowania rozproszonego najczęściej nie poprawi sytuacji proporcjonalnie do liczby węzłów; dochodzi narzut komunikacji, ograniczenia sieci i I/O.

W praktyce taka różnica prowadzi do zmian w sposobie pracy. Na GPU można iteracyjnie eksperymentować z architekturą, hiperparametrami, augmentacją danych. Na Raspberry Pi każdy poważniejszy eksperyment jest decyzją „na noc”, a większe zmiany w modelu zaczynają być trudne do przetestowania w rozsądnym czasie. To jeden z głównych powodów, dla których klaster Raspberry Pi rzadko bywa sensowną platformą do realnego trenowania modeli AI.

Architektura klastra z Raspberry Pi – z czego to się składa

Wybór platformy: Raspberry Pi i alternatywy

Najpierw trzeba ustalić, na czym w ogóle budować klaster. Najbardziej oczywista opcja to:

• Raspberry Pi 4 lub 5 – obecnie najczęściej wybierane, dzięki większej ilości RAM (do 8 GB) i lepszym interfejsom niż stare „trójki”. Jeśli projekt ma mieć cokolwiek wspólnego z AI, lepiej od razu celować w wariant 8 GB.
• Raspberry Pi 3 – do prostych eksperymentów z MPI, Kubernetesa w wersji light (k3s) czy testów sieciowych – tak, ale pod AI będzie to raczej demonstracja cierpliwości niż mocy obliczeniowej.

Na horyzoncie są również alternatywy:

• Rock Pi, Odroid, Orange Pi – różne mini‑płytki z ARM, czasem z lepszym CPU lub większą ilością RAM, choć bywa różnie z jakością wsparcia software’owego.
• NVIDIA Jetson Nano / Xavier / Orin – to już nie są „zwykłe malinki”, ale SBC z dedykowanym GPU do AI. Jeśli celem jest poważniejszy inference lub trening małych modeli na brzegu sieci, Jetson jest o kilka klas bardziej sensowny niż czyste Raspberry Pi, ale kosztuje odpowiednio więcej.

Decydując się na stricte „klaster Raspberry Pi pod AI”, warto od początku uczciwie założyć, że platforma służy głównie do:

• nauki obliczeń rozproszonych,
• testowania i orkiestracji usług wokół modelu,
• inferencji małych, silnie zoptymalizowanych modeli.

Topologia sieci: switch, okablowanie i adresacja IP

Każdy klaster zaczyna się od sieci. Przy kilku–kilkunastu Raspberry Pi typowa konfiguracja wygląda tak:

• Switch – najprostszy gigabitowy switch 8–24‑portowy w zupełności wystarczy. Korzystanie z Wi‑Fi dla obliczeń rozproszonych jest proszeniem się o nieprzewidywalne opóźnienia i problemy.
• Okablowanie – zwykłe kable Ethernet kategorii 5e/6, byle nie najtańsze no‑name, bo potrafią płatać figle przy większych prędkościach i dłuższych odcinkach.
• Adresacja IP – zwykle jedna podsieć z DHCP (router domowy) oraz dodatkowo rezerwacje DHCP lub statyczne adresy IP dla poszczególnych węzłów.

Przy poważniejszym podejściu można rozważyć proste VLAN‑y (np. oddzielenie ruchu zarządzającego od danych) lub osobny router z bardziej zaawansowaną konfiguracją, ale dla eksperymentów edukacyjnych nie jest to konieczne. Znacznie ważniejsze jest, aby:

• każdy węzeł był osiągalny po SSH,
• znana była jego rola (master/worker),
• DNS lub plik /etc/hosts pozwalał łatwo identyfikować węzły po nazwie (np. pi‑node01, pi‑node02).

Porządne nazewnictwo i prosty system zarządzania (np. tagi w Ansible, labelki w Kubernetesie, grupy w MPI) oszczędzają wielu drobnych irytacji. Gdy po kilku miesiącach wrócisz do klastra, świadomość, że pi‑node07 to zawsze węzeł z czujnikami, a pi‑node10 jest zarezerwowany pod inference, bywa na wagę złota.

Nad samą siecią można jeszcze zapanować poprzez monitoring. Nawet bardzo prosty stack typu Prometheus + Grafana, albo lekkie narzędzia w rodzaju Netdata, wystarczą, żeby zauważyć, że ruch między dwoma węzłami nagle skacze do maksimum i dławi obliczenia. Dla eksperymentów z AI to dobry pretekst, by zobaczyć, jak zachowuje się rozproszona inferencja, gdy łącze zaczyna być wąskim gardłem.

W praktyce wiele osób zaczyna od totalnie płaskiej sieci z jednym switchem, a potem, gdy pojawi się więcej węzłów i usług, dodaje odseparowaną sieć „roboczą” tylko do ruchu między Pi. To rozsądna droga: najpierw po prostu uruchomić klaster, dopiero później poprawiać topologię, gdy realne obciążenia pokażą, gdzie coś skrzypi.

Na koniec rozsądnie jest pomyśleć o backupie i awarii sieci. Kopia konfiguracji routera/switcha, zapisany plik z mapą IP i nazw hostów, notatka które porty do czego służą – to drobiazgi, ale gdy po nieudanym update firmware switch nagle zapomni ustawień, zamiast szukać „co gdzie było”, po prostu odtwarzasz stan i wracasz do zabawy z modelami.