Lokalne uruchomienie dużych modeli językowych (LLM) na samej Raspberry Pi jest i może interesujące dla nerdów, ale szału z tym nie ma. A co jeśli w Malinie zainstalujemy dedykowany akcelerator AI Hailo 10H? Wtedy zaczyna się robić ciekawie.

Akcelerator Raspberry Pi AI HAT+ 2 ma na pokładzie układ Hailo 10H o wydajności 40 TOPS (INT4) oraz 8 GB pamięci RAM DDR4. Jest przeznaczony do modelu Raspberry Pi 5 i podłączamy go za pomocą slotu PCIe. Pobiera on do 3,4 W mocy (przy pełnym obciążeniu), więc jest idealnym rozwiązaniem dla użytkowników, którym zależy na niskim zużyciu energii. Oczywiście można go wykorzystać nie tylko do LLM/VLM bez potrzeby korzystania z chmury, ale i do analizy wideo, rozpoznawania mowy, czy projektów związanych z robotyką. Na tym wideo zobaczysz krótki unboxing Hailo 10H dla Raspberry Pi 5.

Instalacja AI HAT+ 2 w Raspberry Pi 5 (wideo)

Generalnie instalacja AI HAT+2 jest prosta i nie powinna nikomu sprawić większych problemów – wszelkie wątpliwości powinno rozwiać poniższe wideo.

Uruchamianie LLM na akceleratorze Hailo 10H dla Raspberry Pi

Akcelerator mamy już zainstalowany w Raspberry Pi, możemy przejść do instalacji oprogramowania.

Instalacja oprogramowania akceleratora Hailo 10H na Raspberry Pi 5 (Pi OS)

Zaraz, a nie da się tego zrobić na Ubuntu? Da się, ale Ubuntu jak na razie nie ma natywnego wsparcia Hailo 10H i wymagałoby to nieco więcej kombinacji. Na początek najlepiej więc wystartować z Raspberry Pi OS.

Cała procedura instalacji oprogramowania oraz uruchamiania modeli LLM dostępna jest na oficjalnej stronie Raspberry Pi – nie zamierzam tu jej przepisywać, więc skupię się tylko na konkretach.

Pierwszym krokiem jest sprawdzenie, czy Raspberry Pi 5 ma włączoną obsługę PCI Express 3.0. a nie 2.0. Następnie:

• Upewniamy się, że system jest zaktualizowany i instalujemy oprogramowanie Hailo 10H
• Instalujemy serwer Hailo Ollama i w trakcie decydujemy, który model chcemy wykorzystać

Gotowe do wykorzystania modele LLM dla Hailo 10H

Na stronie Hailo dostępne są gotowe modele LLM w formacie .hef (czyli w formacie wymaganym przez akcelerator Hailo). Aktualnie dla Hailo 10H znajdziemy tam:

• DeepSeek-R1-Distill-Qwen-1.5B
• Llama3.2-1B-Instruct
• Qwen3-1.7B-Instruct
• Qwen2.5-1.5B-Instruct
• Qwen2.5-Coder-1.5B-Instruct
• Qwen2-1.5B-Instruct-Function-Calling-v1
• Qwen2-1.5B Instruct

Jak widać największy model to zaledwie 1.7B – co powinno na starcie dać mi co nieco do myślenia. Okazuje się, że lista LLM do wykorzystania jest nieco inna, gdy sięgamy do niej z poziomu oprogramowania, dostępny jest również model Lllama 3.2 3B. Model możemy pobrać w trakcie instalacji oprogramowania, nie ma potrzeby robienia tego wcześniej.

• gdy model jest już pobrany, możemy zacząć z nim działać w oknie terminala
• jeśli chcemy konwersować wygodnie w oknie przeglądarki, trzeba zainstalować Dockera i OpenWeb UI – wspomniana instrukcja szczegółowo opisuje to krok po kroku

W tym momencie mamy już działający model na akceleratorze Hailo 10H. A co jeśli chcemy skorzystać z modelu, którego nie ma w Hailo Modell Zoo? Na przykład naszego Bielika?

Czy na Hailo 10H da się uruchomić Bielika i jaki model będzie odpowiedni?

Hailo udostępnia nam narzędzia niezbędne do konwersji innych modeli do formatu .hef dla Hailo. Generalnie do takiego zadania nie potrzeba nam całego pakietu Hailo SDK, a jedynie kompilator (Hailo DataFlow Compiler). Dostęp do narzędzi otrzymujemy po zarejestrowaniu na stronie Hailo. Kompilator jest jednak dostępny wyłącznie w wersji na Linux x86. Oczywiście o GUI nie ma mowy, działamy w oknie terminala. Dla systemów Windows dostępne jest jedynie narzędzie HailoRT do uruchamiania gotowych modeli w formacie .hef.

Użytkownicy Windows mogą jednak po prostu skorzystać z funkcji WSL2 (uruchamianie pełnego środowiska Linux bezpośrednio na komputerze z systemem Windows). Trzeba tylko pamiętać, że kompilacja modeli LLM wymaga dużej pojemności pamięci RAM, a WSL2 nie przyznaje pliku swap dynamicznie, więc przed pracą trzeba ustawić jego odpowiednio dużą wielkość.

Sam proces konwersji modelu jest jednak skomplikowany, a i przed wyborem modelu trzeba się poważnie zastanowić.

Hailo 10H dla Raspberry Pi 5 ma na pokładzie 8 GB RAM LPDDR4X. W teorii pozwoli to na obsługę skwantyzowanych modeli 7B. No i właśnie… na konferencji NVIDIA GTC w San Jose (marzec 2026), zaprezentowano Bielik Minitron 7B (v3.0) – zoptymalizowaną i kompaktową wersję polskiego modelu. Charakteryzuje się rozmiarem 7,35 miliarda parametrów i jest o 33% mniejszy niż Bielik 11B v3.0 (na którym jest oparty), ale zachowuje około 90% jakości większego modelu, przy równoczesnym 50% szybszym wnioskowaniu. Jest moc i nie ma się czego wstydzić, nawet na tle nowych modeli Gemma.

Wydawałoby się, że model 7B powinien zadziałać na takiej konfiguracji, więc grzechem byłoby nie skorzystać z Minitrona. Mógłbym ładnie napisać, że takie założenie było błędne, ale mówiąc wprost – pomysł był głupi (i to głupi do kwadratu).

• po pierwsze: limity pamięciowe Hailo 10H i sposób alokacji podczas wnioskowania

Nawet po kwantyzacji do 4 bitów, sam model zajmie około 3,5 GB. Tu wchodzi rzeczywistość – cała na biało – i mówi nam, że podczas rzeczywistej pracy system potrzebuje znacznie więcej przestrzeni, niż to co zajmuje sam model. NPU (Neural Processing Unit) takie jak Hailo 10H, przechowują stany aktywacji w KV Cache. Rozmiar tej pamięci podręcznej rośnie liniowo wraz z długością okna kontekstowego i wielkości paczki (batch). Realnie, dla 8 GB pamięci RAM w Hailo 10H nadają się więc modele 1.5B lub 3B, a i to z ograniczonym oknem kontekstowym. W praktyce całe przetwarzanie, wagi i stany pośrednie warstw muszą się zmieścić w pamięci akceleratora.

• po drugie: problematyczna konwersja modelu Minitron

Nie załadujemy bezpośrednio modelu z Hugging Face do Hailo 10H – tu potrzebna jest konwersja. Konwersja modelu Bielik Minitron 7B  będzie trudniejsza pod kilkoma względami niż w przypadku jego poprzednika, czyli klasycznego Bielika v3. Wynika to wprost ze zmienionej struktury wewnętrznej po zastosowaniu technik miniaturyzacji we współpracy z firmą NVIDIA. W odróżnieniu od Bielika v3, wersja Minitron 7B nie była trenowana od zera jako osobny model. Jest ona wynikiem „ściśnięcia” modelu 11B (z 11,04 mld do 7,35 mld parametrów). Przycinanie strukturalne (hybrid pruning) sprawia, że macierze wag nie mają już standardowych wymiarów i dodatkowe węzły mogą sprawić parserowi Hailo duże trudności. Działania NVIDII mogły również pozostawić w modelu Minitron nietypowe operatory, a klasyczny Bielik v3 ma znacznie bardziej przewidywalną strukturę. Parser Hailo oczekuje czystego, statycznego grafu ONNX.

TL;DR: zostawiamy mrzonki o wykorzystaniu Bielika Minitron 7B na Hailo 10H i bierzemy na warsztat najmniejszego Bielika 1.5B v3. Ta wersja dodatkowo oparta jest o Qwen (a nie o Mistral jak pozostałe), o którym wiemy, że działa na Hailo 10H, więc i Bielik 1.5B powinien. Wymagana jest rejestracja i stworzenie tokena na Hugging Faces, by otrzymać dostęp do modelu.

Dobra, ale są trzy wersje tego modelu: Instruct, Instruct FP8 Dynamic i Instruct GGUF. Którą wybrać? Nieoczywistym, ale najlepszym dla nas wyborem jest Instruct. Parser Hailo może robić problemy w przypadku FP8 Dynamic, a jeszcze większe przy GGUF. Żeby pobrać model z Hugging Face potrzebny jest dostęp, ale wymaga się od nas tylko kliknięcia zgody i wygenerowania tokena.

Konwersja modelu z Hugging Face na format Hailo 10H

Procedura wymaga od nas kilku kroków – czeka nas konwersja do ONNX, uproszczenie samego modelu, następnie konwersja do HAR, kalibracja INT4 i dopiero na koniec wygenerowanie pliku .hef. Skomplikowane, ale da się ogarnąć, prawda? No cóż… Jak na razie mi się to nie udało, ale próby wciąż trwają. Najwięcej problemów sprawia mi parser Hailo, który sypie błędami i najchętniej po prostu poczekałbym na jego kolejną wersję. Co jednak dokładnie trzeba zrobić?

Konwersja modelu Hugging Face na ONNX i jego uproszczenie

Gdy mamy pobrany model z Hugging Face konwersja do ONNX będzie pierwszym i najprostszym krokiem. Sama prosta konwersja nie załatwia jeszcze sprawy, bo parser Hailo nie przełknie takiego pliku. Trzeba go uprościć i to poważnie – zwykłe uproszczenie modelu tu nie wystarczy. Nie będę pisał „co należy tu zrobić” bo sam jeszcze tu nie osiągnąłem pełnego sukcesu, ale opisałem tu moje działania. Z czym były problemy?

Przede wszystkim w warstwie Gather w węźle osadzeń – natrafiłem na błędy typowania danych wejściowych (INT64 vs float), czy błędy związane z niestandardowymi operacjami 1D (IndexError w conv1x1_dense). Próbowałem agresywnego obcięcia precyzji wag z 32-bitowych na 16-bitowe (Float16) z wyłączeniem wnioskowania kształtów, by ominąć twardy limit 2 GB narzucany przez format Protobuf w trakcie ładowania modelu do pamięci (choć alternatywą jest tu zapis wag do zewnętrznego pliku). Potem w ruch poszło narzędzie Transformers Optimizer (wbudowane w bibliotekę ONNX Runtime), które zidentyfikowało zagnieżdżenia węzłów typowe dla tej architektury (jak bloki Attention, LayerNorm czy GELU) i zredukowało je do pojedynczych bloków.

Wygenerowanie pliku HAR

Kiedy mamy już uproszczony model ONNX możemy sięgnąć po parser (Hailo DataFlow Compiler). Opisywane powyżej kroki pozwoliły w końcu na wygenerowaniu pliku HAR przy opcji odcięcia niekompatybilnych węzłów początkowych i końcowych, pozostawiając do translacji samo kompatybilne jądro sieci neuronowej.

Mimo że upewniłem się, że plik ONNX ma wejścia w poprawnym dla NLP typie INT64, wewnętrzny interpreter Hailo SDK (konkretnie ONNXRuntimeError : 10 : INVALID_GRAPH) zgłaszał błędnie, że typem jest tensor(float), co uniemożliwiało kompilatorowi zrozumienie osadzeń modelu. Jak przyznali na forach inżynierowie Hailo, jest to błąd ich modułu shape inference.

Jeśli parser mieli godzinami, zużywa ogromne zasoby RAM i swap, a równocześnie używa przy konwersji tylko jednego rdzenia – to znaczy, że ma problem i konwersja najprawdopodobniej zakończy się błędem. Wynikowy plik .har posłuży jako szkielet struktury dla kompilatora przed ostateczną kalibracją i kwantyzacją do formatu .hef.

Strojenie INT4 i zapis .hef

Krytycznym warunkiem dla kompilatora jest zestaw danych (dataset) używany do strojenia biasu oraz zbierania statystyk dla wag. W przypadku macierzy transformerowych z LLM, kompilator bez ostrzeżenia porzuci kwantyzację wag INT4 i wyzeruje optymalizację, jeśli nie dostarczysz mu dokładnie minimum 1024 próbek danych (tekstów przepuszczonych przez tokenizer). Mniejsza liczba przerywa proces wymagany do utrzymania precyzji odpowiedzi tekstowych modelu.

Jakby tego było mało, wchodzi tu również sprzętowa weryfikacja zasobów przeprowadzana przez Keras (silnik wbudowany w Hailo SDK).

• Modele językowe wymagają tzw. strojenia Mixed Precision do 4-bitowych wag z zachowaniem 8-bitowych aktywacji (W4A8), co kompilator Hailo optymalizuje na macierzach wbudowanych w transformery.
• Jeśli kompilator wykryje, że pracujesz na samym procesorze (np. na domowym PC bez dedykowanej karty NVIDIA/CUDA), wyświetli komunikat o obniżeniu optymalizacji: [warning] Reducing optimization level to 0 (...) no available GPU.
• W ramach zabezpieczenia przed przekroczeniem pamięci RAM hosta, silnik cicho obcina flagi zapisu wag (Ratio of weights in 4bit is 0.00). Wygenerowany HEF będzie ważył zaledwie około 400 KB, ponieważ Hailo zapisuje jedynie pusty szkielet połączeń NPU bez samych parametrów modelu.

Gdy już uda się zmusić system (często wyłączając auto-downgrade i stosując tzw. „monkey-patche”) do uwzględnienia wag w pliku, cały proces kompresji wywraca się z powodu niezgodności typu danych.

Bielik 1.5B na Hailo 10H powinien działać, ale lokalna konwersja jest problematyczna

Proces, z którym walczyłem, obnażył systemowe braki oficjalnego zestawu narzędzi Hailo Dataflow Compiler. Z powodu tych skumulowanych usterek lokalna kompilacja plików LLM .onnx do postaci .hef  jest oficjalnie uznawana za trudną i obarczoną błędami systemowymi, wymagającą poprawek ze strony oficjalnego wsparcia Hailo.

Nie będę udawał, że jestem jakimś wyjątkowym specjalistą od modeli LLM, ale moje próby konwersji Bielika na format Hailo 10H rozbijały się o ewidentne limity i błędy samego oprogramowania producenta układu – co przyznają na forach sami inżynierowie Hailo. Nie mówię, że nie da się tego zrobić z aktualną wersją kompilatora, ale jest to proces który mnie pokonał.

Jeśli nie chcesz spędzać długich dni na własnoręcznych próbach konwersji modeli do formatu .hef, musisz polegać na bazie LLM przygotowanej przez Hailo, a ta na razie jest niewielka. Najlepszym posunięciem jakie mogłoby zrobić Hailo, to udostępnienie kolejnych gotowych modeli .hef – a zwłaszcza Gemma 4 E2B, no i oczywiście Bielik 1.5B v3. Nie pogardziłbym też modelem Bielik Minitron 3B – bo o tyle hipotetycznie dałoby się skompresować aktualnie istniejący model 4.5B v3.

Oczywiście musimy pamiętać, że AI HAT+2 z Hailo 10H to wciąż mini akcelerator AI o bardzo małym zużyciu energii – w przypadku dużych modeli językowych nie należy się po nim spodziewać cudów.

Temat uruchomienia Bielika na Hailo 10H pozostawiam więc na razie otwarty i czekam na kolejną wersję Hailo DataFlow Compiler, bo nie ukrywam, że na myśl o aktualnej na usta cisną mi się wyrażenia powszechnie uważane za niecenzuralne.

FAQ

Ile kosztuje Raspberry Pi AI HAT+ 2 (Hailo 10H)?

Niestety podwyżki nie ominęły i tego segmentu – zwłaszcza, że na pokładzie tego akceleratora znajduje się 8 GB RAM. Aktualna cena to ponad 800 zł (niedawno było to nieco ponad 600 zł).

Jakiego modelu Raspberry użyłem na potrzeby tego testu?

Raspberry Pi 5 w wersji 8 GB (@2,8 GHz) z dyskiem SSD SATA podłączonym do USB 3.0 (Raspberry Pi OS).

Materiał powstał we współpracy ze sklepem Botland.