W laptopie mam nieużywane NPU. Chcę wreszcie ustalić, czy może mi się do czegoś przydać

W swoim laptopie Lenovo Yoga Slim 7x mam oprócz standardowego CPU i GPU jeszcze jeden procesor: NPU (Neural Processing Unit), przeznaczony do energooszczędnego wykonywania obliczeń sieci neuronowych. Na co dzień ten NPU, może poza rozmywaniem tła podczas rozmowy czy indeksowaniem plików w tle, pozostaje bezczynny. Postanowiłem więc sprawdzić, co jeszcze da się z nim zrobić, jaką oferuje wydajność i czy w praktyce warto z niego korzystać.

Zacząłem od sprawdzenia, jakie modele językowe można na nim uruchomić, przez jakie narzędzia, ile zachodu wymaga przygotowanie i czy rezultat jest wart tego wysiłku. Zmierzyłem szybkość generowania, czas oczekiwania na odpowiedź oraz zachowanie przy różnych długościach wejścia i stanach zasilania. Sprawdziłem też wybrane rozmiary modeli i kwantyzacje; nie uzyskałem wiarygodnego pomiaru zużycia RAM.

Mam nadzieję, że lokalny LLM przyda się tam, gdzie połączenie z chmurą jest słabe albo nie ma go wcale, na przykład w samolocie lub w pociągu. Być może wystarczy do pomocy przy tekście, kodzie lub notatkach zapisanych na laptopie. Warto też wiedzieć, jakie zadania da się wykonać bez przesyłania promptu do zewnętrznego modelu. W takich warunkach NPU może okazać się szczególnie przydatne: powstało właśnie po to, by obliczenia sieci neuronowych wykonywać oszczędniej niż CPU i GPU, a ASUS wprost łączy je z niskim zużyciem energii i dłuższą pracą na baterii (ASUS). Sprawdziłem więc szybkość i przybliżoną moc działających konfiguracji; czasu pracy na baterii nie mierzyłem.

Nie zakładałem, że lokalny model zastąpi chmurę ani że NPU musi wygrać z CPU lub GPU. Celem było ustalenie, kiedy warto użyć NPU, którą ścieżkę wybrać i gdzie kończy się jego praktyczna użyteczność. Przewaga CPU lub GPU w konkretnym scenariuszu była równie wartościowym wynikiem.

Dodatkową motywacją jest dla mnie chęć lepszego poznania technologii i chęć poeksperymentowania z parametrami modeli.

Punktem startowym był Qwen3-4B-Instruct-2507. Następnie sprawdziłem wybrane rozmiary modeli, kwantyzacje, pojemności okna i rzeczywiste długości wejścia. Porównania dotyczą natywnego Windows ARM64 na tym laptopie.

Najważniejsze wyniki:

• Krótkie wejście, zasilacz: CPU z Q4_0 daje około 33 tok/s — najszybciej.
• Bateria + Power Saving: NPU (qairt) utrzymało około 20 tok/s — najwyższe tempo decode spośród badanych konfiguracji w tym trybie.
• Długie wejście (6180 tokenów): generacja około 33 s na NPU wobec około 86 s na CPU.
• Rozmiar modelu: 8B i 14B osiągnęły tempo użyteczne do interaktywnej pracy; 32B (około 4,8 tok/s) było dla mnie zbyt wolne do wygodnego czatu.
• NPU nie jest automatycznie najlepszym wyborem — zależy od scenariusza.

Odczyty mocy na poniższym wykresie to przybliżenia netto kanału SYS z osobnych, pojedynczych prób, z odpowiedziami różnej długości i treści. Dokładny zakres licznika i błąd pomiaru nie są ustalone. Nie są to pomiary czasu pracy na baterii ani energii jednakowego zadania.

Dłuższe wejście może zmienić wybór urządzenia. Przy 420 tokenach wejścia CPU kończył generację wcześniej: 6,69 s wobec 9,31 s na NPU. Przy 6180 tokenach NPU potrzebowało 32,96 s, a CPU 86,03 s — w tym teście NPU było około 2,6× szybsze.

1. Podstawowe informacje

1.1. Sprzęt

Testuję Yoga Slim 7x ze Snapdragonem X Elite X1E-78-100 i 32 GB RAM. W jednym SOC są trzy urządzenia, na których można wykonywać obliczenia modelu.

Laptop wyposażony jest w procesor Qualcomm Snapdragon X Elite z trzema jednostkami obliczeniowymi:

• CPU - 12 rdzeni Qualcomm Oryon, podzielonych na trzy klastry po cztery rdzenie, taktowanie do 3,4 GHz przy pracy wielordzeniowej.
• GPU - zintegrowany Qualcomm Adreno X1-85, korzystający ze współdzielonej pamięci RAM, z obsługą OpenCL.
• NPU - Qualcomm Hexagon o deklarowanej wydajności do 45 TOPS (bilionów operacji na sekundę).

TFLOPS i TOPS nie da się łatwo przeliczyć na tokeny/s. Szybkość generowania zależy też od modelu, przesyłania danych z pamięci i implementacji obliczeń. Trzeba ją zmierzyć dla konkretnej konfiguracji.

x → MatMul z W → Add z b → Relu → y

Struktura pojedynczego bloku Q4_0:
[ skala: 2 bajty ] + [ 32 kody po 4 bity: 16 bajtów ]

Razem: 18 bajtów na 32 wagi. 
Daje to średnio 4,5 bitu na każdy parametr modelu.

1.5. Jak czytać czas, kontekst i pamięć

• Prefill: przetworzenie wejścia.
• TTFT: czas od rozpoczęcia żądania do pierwszego tokenu odpowiedzi.
• Decode: tempo generowania kolejnych tokenów, podawane w tok/s.

Raportowane TTFT i czasy generacji nie obejmują ładowania modelu. Krótszy TTFT nie musi oznaczać szybszego ukończenia całej odpowiedzi.

Pojemność okna to nie długość wejścia. Wejście, historia, znaczniki rozmowy i odpowiedź dzielą budżet kontekstu. KV cache przechowuje część obliczeń dla zachowanych tokenów, ale dłuższa historia nadal zwiększa koszt pamięci i uwagi. Dlatego osobno zmieniam pojemność okna, a osobno faktyczną długość promptu.

Rozmiar pliku modelu nie jest równoznaczny ze zużyciem RAM. Do wag dochodzą cache, aktywacje, bufory i pamięć systemu. Nie uzyskałem wiarygodnego pomiaru RAM.

2. Co rzeczywiście udało się uruchomić

Najpierw zweryfikowałem, czy dane środowisko jest w ogóle w stanie zainicjować model i wygenerować odpowiedź. Do finalnych pomiarów wydajności trafiły wyłącznie stabilne, w pełni działające konfiguracje.

2.1. Bilans środowisk

Przebieg i problemy z uruchamianiem

Samodzielne llama.cpp Kompilacja wersji ARM64 dla bazowego CPU zakończyła się sukcesem i działa stabilnie. Wariant z włączonym backendem ggml-hexagon wykrywa NPU, ale próba załadowania modelu kończy się błędem otwarcia sesji. Przyczyna błędu pozostaje nieznana, ale nie jest to dowód na brak sprzętowej obsługi tego modelu – ta sama ścieżka obliczeniowa zadziałała bezbłędnie przez biblioteki llama.cpp dostarczane wewnątrz GenieX.

GenieX z pluginem llama_cpp (GGUF) Zarejestrowałem lokalny plik GGUF i wykonałem próbną inicjalizację NPU. Właściwe pomiary wydajności objęły tryby: CPU, GPU, NPU oraz hybrid. W trybie hybrid rzeczywisty podział pracy między bloki SoC pozostaje z perspektywy użytkownika czarną skrzynką.

GenieX z pluginem qairt (Paczka QNN) Do testów użyłem przygotowanej paczki QNN W4A16 dla układów Snapdragon X Elite, zgodnej z pluginem qairt.

2.2. Czego nie mierzyłem

ORT rozpatrywałem jako alternatywę, ale jego sprawdzenie wymagałoby przygotowania lub pozyskania zgodnego modelu, konfiguracji generowania i zweryfikowania działania wybranej integracji. Byłby to osobny etap prac, wymagający dodatkowego czasu. Ograniczyłem więc zakres do działających konfiguracji GenieX. Brak wyników ORT jest decyzją o zakresie testów, nie dowodem, że ta droga nie działa.

3. Jak mierzę i co porównuję

Testowałem GenieX v0.10.0 z QAIRT 2.50 i dostarczoną z nim wersją llama.cpp.

Pomiary szybkości wykonałem natywnie na Windows ARM64 przez GenieX. Dla tabel szybkości i kwantyzacji każda ukończona komórka to jedna próba rozgrzewki i pięć mierzonych. Podaję medianę. Testy pojemności okna i długości wejścia mają po trzy mierzone próby. Ustawienia to limit 128 nowych tokenów, tryb non-thinking, temperatura 0 i seed 42. W podstawowym porównaniu 4B przez llama_cpp okno miało 512 tokenów, a qairt korzystał z konfiguracji paczki. Osobne serie długości wejścia mają stałe okno 16 384 tokenów.

Każda próba jest pierwszym żądaniem w nowym procesie. Próba rozgrzewkowa może rozgrzać system i cache plików, ale nie instancję runtime’u kolejnej próby. Raportowane czasy generacji nie obejmują ładowania modelu. Ten sam tekst promptu ma 48 tokenów wejścia w llama_cpp i 61 w qairt. Obie ścieżki używają różnych artefaktów i konfiguracji, więc porównanie TTFT nie izoluje wpływu sprzętu.

Stany zasilania ustawiałem ręcznie: zasilacz, bateria oraz bateria z Power Saving.

4. Wyniki: szybkość, energia i długość wejścia

Wykresy pokazują wyniki zapisanych prób. Kreski na wykresach szybkości oznaczają minimum i maksimum, nie przedział ufności. AC oznacza zasilacz, a Power Saving to tryb oszczędzania energii.

4.1 Szybkość: 4B i trzy stany zasilania

Mediana z 5 prób po 1 próbie wprowadzającej. Wyjątek to CPU z Power Saving, gdzie próba wprowadzająca przekroczyła limit czasu. Limit odpowiedzi to 128 tokenów, bez trybu thinking. Dla llama_cpp okno ma 512 tokenów, a dla qairt wynika z paczki.

qairt miał najkrótszy TTFT: mediany 89–98 ms zależnie od stanu zasilania. CPU osiągnął 150–158 ms, NPU przez ggml-hexagon 158–187 ms, hybrid 207–220 ms, a GPU 278–291 ms. To wyniki całych ścieżek, nie samych urządzeń: qairt przetwarzał 61 tokenów wejścia, a llama_cpp 48.

4.2 Średnia moc: ile watów pokazał pomiar?

Żeby porównanie było czytelniejsze, pokazuję średnią moc netto w watach (W). Waty mówią, jak szybko zużywana jest energia, a nie ile zużyto jej na całą odpowiedź. Niższa moc nie zawsze oznacza mniejszą energię zadania, jeśli model musi pracować znacznie dłużej.

To przybliżenia kanału SYS po odjęciu osobno zmierzonego spoczynku, nie całkowity pobór laptopa z gniazdka ani pomiar samego NPU. Średnią obliczyłem z odczytanej energii i czasu uruchomienia, razem z ładowaniem modelu. Historyczne odczyty obu serii wymagały różnego przeliczenia jednostek. Dokładny zakres licznika i błąd pomiaru nie są ustalone.

Najprościej: w osobnej próbie na zasilaczu odczyt wynosił około 44 W dla CPU, 18 W dla GPU i 9 W dla qairt na NPU. Na baterii z Power Saving qairt pokazał około 4 W, a GPU około 8 W. To obiecujący kierunek dla NPU, nie prognoza czasu pracy baterii.

Każda konfiguracja ma tylko jedną próbę, a odpowiedzi różnią się długością i treścią. Dlatego nie traktuję tych liczb jako porównania kosztu jednakowego zadania. Wynik CPU z timeoutem jest osobną obserwacją, nie ukończonym testem. Seria baterii zmienia jednocześnie źródło zasilania i tryb pracy, więc nie izoluje wpływu samego Power Saving.

4.3 Wnioski: co wybrać na baterii i z Power Saving?

Samo odłączenie zasilacza nie zmieniło mocno szybkości w tym krótkim teście: decode różnił się o mniej niż 1% dla CPU i obu ścieżek NPU, o około 4,6% dla GPU i 4,1% dla hybrid.

W tym teście z Power Saving wybrałbym NPU ze względu na szybkość generowania. qairt utrzymał około 20,4 tok/s, a ggml-hexagon 16,7 tok/s. GPU spadło do 13,6 tok/s, hybrid do 11,3 tok/s, a CPU nie ukończył próby wprowadzającej w limicie 15 minut. Podczas tej próby obserwowałem pracę 8 z 12 wątków, ale nie ustaliłem przyczyny opóźnienia.

NPU miało więc najwyższe tempo decode spośród badanych konfiguracji w tym trybie, choć nie było jedynym działającym wyborem: GPU nadal generowało tekst. Niższy przybliżony odczyt mocy qairt w osobnej, pojedynczej próbie jest obiecującą obserwacją, ale nie dowodem mniejszej energii jednakowego zadania ani dłuższej pracy na baterii. Rekomendację opieram przede wszystkim na utrzymanej szybkości w Power Saving.

4.4 Kwantyzacja: 4B na CPU i NPU przez ggml-hexagon

Zasilacz, krótki prompt, mediana z 5 prób. Na wykresie decode, czyli tempo generowania kolejnych tokenów.

Osobna paczka qairt QNN W4A16 osiągnęła 21,3 tok/s. Nie umieszczam jej w tej samej serii kwantyzacji GGUF.

Q4_0 był na CPU około 3,2 razy szybszy niż F16 w decode i ponad 12 razy w prefillu. NPU miało wolniejszy decode dla wszystkich tych GGUF, ale mniejsze różnice prefillu między kwantyzacjami. To wynik tego modelu i buildu, nie ogólna hierarchia schematów. W tej serii mierzyłem szybkość, nie jakość odpowiedzi.

4.5 Liczba parametrów: od 1.7B do 32B na CPU

Zasilacz, Q4_K_M, non-thinking, po 5 mierzonych prób.

• To oryginalny Qwen3 z przełączanym thinking/non-thinking, tutaj z wyłączonym thinking. 4B-2507 to inny checkpoint, więc nie wchodzi wprost w tę serię. Co z tego jest praktyczne?

• 1.7B: największy zapas szybkości. Warto zacząć od niego przy prostych, wąskich zadaniach, ale sprawdzić, czy jakość wystarcza.

• 8B: około 18 tok/s przy krótkim wejściu to rozsądny punkt startowy do interaktywnej pracy.

• 14B: około 10,5 tok/s, czyli wolniejsza, ale nadal sensowna opcja, jeśli większy model daje lepszy wynik w konkretnym zadaniu.

• 32B: około 4,8 tok/s. Sam decode 128 tokenów zajmuje orientacyjnie 27 s. W tym teście było to dla mnie zbyt wolne do wygodnego, interaktywnego czatu. Nie wyklucza to zastosowań wsadowych, jeśli dłuższe oczekiwanie jest akceptowalne, a jakość odpowiedzi uzasadnia wybór większego modelu; tego tutaj nie oceniałem.

32B jest największym modelem, dla którego uzyskałem wynik w tej serii, nie ustalonym limitem tego laptopa. Te próby mają krótkie wejście i okno 512 tokenów. Szybkość nie dowodzi jakości, a dłuższy dokument może znacznie zmienić responsywność.

4.6 Pojemność okna i rzeczywista długość wejścia

Zmiana pojemności okna przy krótkim prompcie (CPU, AC)

Zmieniałem pojemność okna, zostawiając 52 tokeny wejścia i 128 tokenów odpowiedzi. Historia rosła więc do około 180 pozycji, nie do 65k czy 262k. Poniżej mediany TTFT z trzech prób na komórkę.

Przy większych limitach TTFT wzrastał, ale nie monotonicznie. Nie ustaliłem przyczyny ani praktycznego limitu długości dokumentu: ten test nie zapełniał okna.

Dłuższe wejście przy stałym oknie (4B Q4_0, CPU i NPU)

Na zasilaczu, z profilem maksymalnej wydajności, zostawiłem okno 16 384 tokenów i zwiększałem długość syntetycznego wejścia z powtarzanych akapitów. Najpierw wykonałem serię CPU, potem NPU przez GenieX llama_cpp, czyli ggml-hexagon, nie qairt. Użyłem tego samego zarejestrowanego Qwen3-4B-Instruct-2507 Q4_0, identycznych promptów, temperatury 0 i trzech mierzonych prób na komórkę, po jednej próbie wprowadzającej. Każda próba to nowy proces, a każda odpowiedź miała dokładnie 128 raportowanych tokenów i kończyła się limitem długości.

Cała generacja to mediana całkowitego czasu generacji raportowanego przez silnik, bez ładowania modelu, nie suma median innych metryk. Prefill CPU wyniósł odpowiednio 211,2, 182,1 i 94,9 tok/s, a NPU 640,9, 577,1 i 376,4 tok/s.

Przy dłuższym wejściu NPU może być szybsze od CPU. Dla 6180 tokenów wejścia i 128 tokenów odpowiedzi generacja trwała około 33 s na NPU wobec 86 s na CPU. Przy najkrótszym wejściu wcześniej kończył CPU. Wybór zależy więc również od długości wejścia i odpowiedzi.

To dwa osobne wyniki: przewagę szybkości dłuższego wejścia zmierzyłem przez ggml-hexagon, a niższą moc w innej serii przez qairt. Nie zmierzyłem mocy ani energii tego testu dłuższego wejścia.

Pomiędzy krańcami decode CPU spadł o około 77%, a NPU o 48%. Nie przypisuję spadku jednemu mechanizmowi: wejście jest syntetyczne, serie szły od najkrótszej, bez rejestracji temperatury i taktowania. Nie zmierzyłem tu energii ani jakości pracy z dokumentami.

5. Co wybrać do konkretnego zastosowania

5.1 Praktyczne wnioski na podstawie tych prób

Nie wybierałbym jednej konfiguracji do wszystkiego. Najpierw ustaliłbym, czy ważniejsze są szybkość odpowiedzi, praca na baterii, długość dokumentu czy możliwości większego modelu. Poniższe propozycje są punktem startowym do własnych zadań, nie rankingiem jakości modeli ani gwarancją zachowania każdej aplikacji.

5.2 Moje podsumowanie

NPU okazało się użyteczne i będę sprawdzał je dalej. Nie jest jednak automatycznie najlepsze tylko dlatego, że zostało zaprojektowane do obliczeń sieci neuronowych:

• Krótkie wejście i zasilacz: CPU z Q4_0 dawało najwyższe tempo decode badanego 4B. Do szybkiej odpowiedzi nie muszę na siłę używać NPU.
• Power Saving: NPU zachowało responsywność lepiej niż GPU i hybrid. Dlatego qairt jest dla mnie pierwszym kandydatem do generowania w tym trybie. Niższy przybliżony odczyt SYS w osobnej próbie jest dodatkową obserwacją, nie potwierdzeniem dłuższej pracy na baterii.
• Dłuższe wejście: ggml-hexagon potrafił wygrać z CPU czasem całej odpowiedzi. Benchmark krótkiego pytania nie wystarcza do wyboru konfiguracji dla dokumentów.
• Wielkość modelu: 8B i 14B wyglądają rozsądnie pod względem szybkości. 32B (około 4,8 tok/s) było dla mnie zbyt wolne do wygodnego czatu, ale może być przydatne w zadaniach wsadowych. Więcej parametrów ma sens tylko wtedy, gdy poprawia wynik konkretnego zadania; jakość trzeba sprawdzić osobno.

Następny krok to sprawdzić, czy wybrane modele rzeczywiście radzą sobie z realnymi zadaniami: poprawianiem tekstu, streszczaniem notatek, wydobywaniem informacji z dokumentów albo pomocą przy kodzie.

Chcę też sprawdzić, jak przełożyć działające konfiguracje na codzienne użycie, np. w LM Studio, Ollamie lub AnythingLLM.

LLM nie wyczerpuje też możliwych zastosowań NPU. Transkrypcja nagrań czy przetwarzanie obrazu to kolejne kierunki do sprawdzenia, z innymi modelami i wymaganiami.