ARPL chce, aby llama.cpp przestał traktować każdy telefon ARM tak samo
ARPL opublikował referencyjną implementację dla Androida, która podważa podstawowe założenie stosowane w mobilnych wdrożeniach llama.cpp. Do tej pory wiele konfiguracji traktowało wyraźnie różniące się telefony ARM niemal identycznie.
Projekt odczytuje możliwości procesora i topologię rdzeni w czasie działania. Następnie rekomenduje ustawienia wątków i modyfikuje wybrane parametry kontekstu llama.cpp. Celem jest jedna kompilacja aplikacji, która dostosowuje się do telefonu, na którym działa.
To twierdzenie ma znaczenie, ponieważ sprzęt z Androidem różni się znacznie bardziej, niż sugeruje wspólna etykieta ARM64. Snapdragon 8 Elite i starszy procesor ze średniej półki udostępniają odmienne instrukcje, układy rdzeni, limity pamięci i ścieżki akceleracji.
Deweloper twierdzi, że ARPL wykrywa obsługę SDOT, I8MM i SME2, a następnie dostosowuje wykonanie do wykrytego sprzętu. Przy przygotowywaniu kontekstu llama.cpp uwzględnia też flash attention i kwantyzację pamięci podręcznej klucz-wartość.
Nie jest to jednak funkcja upstreamowa llama.cpp ani niezależnie przebadane porównanie wydajności. Publiczny wpis o ARPL opisuje niekomercyjny pokaz możliwości przetestowany na jednym wariancie Samsung Galaxy S25 Ultra.
To rozróżnienie definiuje tę historię. ARPL oferuje wiarygodną warstwę adaptacji w czasie działania, podczas gdy dowody potrzebne do potwierdzenia jego rekomendacji pozostają ograniczone.
ARPL przenosi dostrajanie urządzenia do czasu działania
Centralna zmiana w ARPL jest prosta: najpierw zbadaj telefon, a dopiero potem skonfiguruj llama.cpp, zamiast stosować wszędzie jedno ustawienie wstępne.
Publiczne wydanie obejmuje referencyjną aplikację na Androida zbudowaną w Kotlinie i Jetpack Compose. Most Java Native Interface łączy warstwę aplikacji z natywnym kodem C i C++ llama.cpp.
Według dewelopera ARPL wykonuje trzy powiązane zadania. Wykrywa dostępne rozszerzenia zestawu instrukcji, analizuje topologię CPU i modyfikuje wybrane parametry inferencji.
Rozszerzenia architektury zestawu instrukcji dodają wyspecjalizowane operacje poza podstawowym zestawem instrukcji ARM64. W przypadku lokalnych modeli językowych operacje te mogą przyspieszać typowe obliczenia macierzowe i całkowitoliczbowe.
SDOT zapewnia instrukcje iloczynu skalarnego ze znakiem, które mogą pomagać w przetwarzaniu wartości skwantyzowanych. I8MM dodaje operacje mnożenia macierzy całkowitoliczbowych zaprojektowane dla obciążeń wykorzystujących dane ośmiobitowe.
SME2 rozszerza Scalable Matrix Extension firmy Arm o dodatkowe możliwości ukierunkowane na macierze. Nie można bezpiecznie zakładać obsługi wyłącznie dlatego, że aplikacja działa na nowoczesnym systemie operacyjnym ARM64.
ARPL ma podobno odpytywać maski bitowe HWCAP, które system operacyjny udostępnia do opisu możliwości procesora. Android oficjalnie zaleca getauxval() z AT_HWCAP i AT_HWCAP2 do tego rodzaju inspekcji w czasie działania.
Wytyczne dotyczące funkcji CPU wyjaśniają również ważne ograniczenie. Niektóre starsze urządzenia nieprawidłowo raportowały możliwości, więc zwrócona flaga nie jest absolutną gwarancją.
Google utrzymuje oddzielną bibliotekę funkcji CPU z poprawkami specyficznymi dla urządzeń, dotyczącymi znanych błędów raportowania. Ta historia pokazuje, dlaczego wykrywanie w czasie działania wymaga defensywnych kontroli i testów na rzeczywistych urządzeniach.
Drugim źródłem danych ARPL jest topologia CPU. Procesory mobilne często dzielą rdzenie na klastry o różnych charakterystykach wydajności, efektywności, częstotliwości i zachowania termicznego.
Surowa liczba rdzeni nie oddaje tych różnic. Przydzielanie pracy do każdego aktywnego rdzenia może tworzyć narzut planowania lub wciągać wolniejsze rdzenie do operacji wrażliwej na opóźnienia.
Wydanie rekomenduje zatem liczbę wątków opartą na wykrytych klastrach, a nie wyłącznie na łącznej liczbie logicznych rdzeni. Ta rekomendacja jest przekazywana do llama.cpp przez natywny most.
Trzecie zadanie dotyczy konfiguracji kontekstu. Deweloper twierdzi, że ARPL może modyfikować ustawienia flash attention i kwantyzacji pamięci podręcznej KV zgodnie z dostępnym sprzętem.
Flash attention reorganizuje obliczenia uwagi, aby ograniczyć ruch pamięci. Pamięć podręczna KV przechowuje klucze i wartości uwagi wygenerowane dla wcześniejszych tokenów, unikając powtórnych obliczeń podczas generowania.
Kwantyzacja tej pamięci podręcznej może zmniejszyć zużycie pamięci, lecz obsługa backendu i kompromisy jakościowe są różne. Konfiguracja, która oszczędza pamięć na jednej ścieżce wykonania, może zawieść lub spowolnić inną.
ARPL próbuje ukryć te wybory za polityką świadomą sprzętu. Deweloper aplikacji miałby zażądać odpowiedniej konfiguracji, zamiast utrzymywać rosnącą listę ustawień wstępnych dla urządzeń.
Zmienia to miejsce, w którym znajduje się logika optymalizacji. Flagi czasu kompilacji nadal określają, które kernele istnieją, ale wykrywanie w czasie działania decyduje, które dostępne ścieżki wydają się odpowiednie dla bieżącego telefonu.
ARPL nie dodaje magicznie nieobsługiwanych instrukcji do istniejącego pliku binarnego. Odpowiednia implementacja musi już zawierać zgodne ścieżki kodu i zachowywać bezpieczną bazę.
To rozróżnienie jest kluczowe. Wykrywanie może wybrać daną możliwość, ale nie może zastąpić kerneli, obsługi kompilatora, integracji backendu ani testów poprawności wymaganych do użycia tej możliwości.
Telefony ARM współdzielą ABI, a nie profil wydajności
Presja dotyczy deweloperów, którzy chcą jednego pakietu Androida bez akceptowania jednej konfiguracji opartej na najniższym wspólnym mianowniku.
Interfejs binarny aplikacji ARM64 w Androidzie pozwala oprogramowaniu kierować się do szerokiej rodziny urządzeń. Ta warstwa kompatybilności upraszcza dystrybucję, lecz nie czyni bazowych systemów jednolitymi.
System operacyjny może raportować skonfigurowaną i aktywną liczbę procesorów. Te sumy nadal niewiele mówią o granicach klastrów, relacjach pamięci podręcznej, utrzymywanej częstotliwości czy koszcie przechodzenia między klastrami.
Mobilne zachowanie termiczne dodatkowo komplikuje stałe ustawienie liczby wątków. Konfiguracja, która prowadzi w krótkim benchmarku, może stracić wydajność po nagrzaniu urządzenia.
Zadania w tle, polityki planowania producentów, stan baterii i konstrukcja chłodzenia również wpływają na wyniki. Dwa telefony wykorzystujące ten sam procesor mogą zatem zachowywać się inaczej przy długotrwałej inferencji.
Snapdragon 8 Elite uwidacznia ten problem, ponieważ łączy CPU Oryon firmy Qualcomm z grafiką Adreno i akceleracją Hexagon. Każda ścieżka stawia inne wymagania dotyczące integracji i pamięci.
llama.cpp dokumentuje obecnie opcje CPU, Adreno OpenCL i Hexagon dla urządzeń Snapdragon. Jego backend Snapdragon nadal opisuje ścieżkę Hexagon jako eksperymentalną.
Te szersze prace nad backendami są odrębne od ARPL. Pokazują, że mobilna optymalizacja wykracza poza wybór instrukcji CPU lub liczenie rdzeni.
Aplikacja musi zdecydować, gdzie wykonują się warstwy modelu, jakie formaty pamięci akceptuje każdy backend oraz czy transfery danych nie niwelują teoretycznych zysków z akceleracji.
Obecne wydanie ARPL obejmuje jedynie część tego systemu. Jego deweloper wyraźnie twierdzi, że heterogeniczny podział pracy między CPU, GPU i NPU jest nadal w toku.
Dostępna wersja skupia się zamiast tego na wykrywaniu instrukcji, rekomendacjach dotyczących wątków CPU i parametrach kontekstu. Ten węższy zakres ułatwia ocenę projektu.
Zapobiega to również mylącemu wnioskowi. ARPL nie jest obecnie automatycznym planistą, który rozdziela model językowy między wszystkie silniki obliczeniowe Snapdragona.
Jego krótkoterminowa wartość polega na ograniczaniu oczywistych niedopasowań. Starszy telefon nie powinien dziedziczyć założeń zaprojektowanych wokół nowszego procesora o innych instrukcjach i rdzeniach.
Z kolei obecny flagowiec nie powinien być zawsze ograniczany do najbezpieczniejszej konfiguracji wymaganej przez najstarsze obsługiwane urządzenie.
Deweloperzy już rozwiązują ten problem za pomocą wariantów kompilacji, list dozwolonych urządzeń, skryptów benchmarkowych i menu konfiguracji. Każde podejście ma swoje koszty.
Warianty kompilacji zwiększają złożoność pakowania i testowania. Listy dozwolonych urządzeń szybko się starzeją, zwłaszcza gdy producenci wypuszczają modele regionalne lub zmieniają zachowanie termiczne poprzez aktualizacje oprogramowania.
Ręczne sterowanie przenosi złożoność na użytkowników, którzy często nie mają wystarczających informacji, aby dobrze wybrać. Statyczne ustawienia domyślne unikają tego obciążenia, ale pozostawiają niewykorzystaną wydajność lub pojemność pamięci.
Adaptacja w czasie działania oferuje inną drogę. Jeden pakiet może zbierać sygnały, wybierać konserwatywną politykę i zachowywać rozwiązania awaryjne, gdy optymalizacja zawiedzie.
Podejście to przypomina negocjowanie możliwości w innych obszarach oprogramowania systemowego. Program pyta, co obsługuje środowisko, zanim zdecyduje się na wyspecjalizowaną ścieżkę wykonania.
Dostrajanie inferencji jest jednak trudniejsze niż sprawdzenie, czy dana instrukcja istnieje. Najlepsza konfiguracja zależy od modelu, długości promptu, alokacji kontekstu, backendu i fazy obciążenia.
Przetwarzanie promptu wykonuje znaczną ilość równoległych obliczeń na tokenach wejściowych. Generowanie autoregresyjne tworzy tokeny sekwencyjnie i może inaczej reagować na liczbę wątków lub odciążanie obliczeń.
Ustawienie, które poprawia przetwarzanie promptu, może obniżyć szybkość generowania. Najlepsza odpowiedź może również zmieniać się wraz z rozrostem kontekstu i zużywaniem większej ilości pamięci przez pamięć podręczną KV.
Oznacza to, że polityka ARPL potrzebuje czegoś więcej niż faktów o sprzęcie. Ostatecznie potrzebuje decyzji świadomych obciążenia albo starannie dobranych ustawień domyślnych, które zachowują się akceptowalnie w typowych przypadkach.
Projekt wywiera presję na statyczną konfigurację, ponieważ ujawnia, jak wiele informacji ignorują te ustawienia wstępne. Nie dowodzi jeszcze, że jedna polityka czasu działania może konsekwentnie wybierać optimum.
Dlaczego więcej wątków może spowolnić llama.cpp
Najmocniejszy argument ARPL głosi, że wydajność mobilnej inferencji zależy od topologii, a nie od największej liczby wątków raportowanej przez urządzenie.
Heterogeniczny CPU nie zachowuje się jak zbiór wymiennych pracowników. Rdzenie mogą różnić się częstotliwością, dostępem do pamięci podręcznej, efektywnością i bliskością innych zasobów obliczeniowych.
Dodanie wątku może zwiększyć ilość pracy równoległej, ale zwiększa też koordynację. Wątki mogą rywalizować o przepustowość pamięci, migrować między rdzeniami lub czekać na pracę wykonaną w innym klastrze.
Inferencja modeli językowych często obciąża przesyłanie danych w pamięci. Skwantyzowane wagi zmniejszają wymagania dotyczące magazynowania, ale procesor nadal musi odczytywać, rozpakowywać i łączyć duże ilości danych.
Gdy ograniczeniem staje się przepustowość pamięci, dodatkowe wątki nie gwarantują wyższej przepustowości. Mogą zwiększać narzut bez dostarczania większej ilości użytecznych danych do jednostek arytmetycznych.
Eksperymenty społeczności ilustrują ten problem, choć nie potwierdzają samego ARPL. Jeden test Snapdragona 8 Elite korzystał z backendu Adreno OpenCL llama.cpp i porównywał kilka układów wątków CPU.
Tester początkowo opisał sześć wątków rdzeni wydajnościowych jako optymalne. Późniejsze, bardziej systematyczne pomiary nieznacznie wskazały na przewagę czterech przypiętych wątków podczas generowania tokenów.
W zgłoszonym eksperymencie cztery wątki osiągnęły 31,4 tokena na sekundę w teście generowania 128 tokenów. Sześć wątków osiągnęło 30,5 tokena na sekundę przy większej zmienności.
Liczby te odnoszą się wyłącznie do tego urządzenia, modelu, kompilacji, sterownika i konfiguracji. Pomiary wątkowania pozostają wynikami społeczności, a nie standaryzowanymi niezależnymi testami.
Mimo to zmiana we własnym wniosku testera wspiera założenie ARPL. Wiarygodna konfiguracja może przestać wyglądać na optymalną, gdy pomiary obejmą alternatywne układy klastrów.
Podkreśla to również ryzyko automatycznych rekomendacji. Odczyt topologii opisuje procesor, ale nie mierzy bezpośrednio najlepszej polityki planowania.
ARPL musi przełożyć fakty, takie jak przynależność do klastra i dostępne instrukcje, na rekomendację dotyczącą wątków. W tym przekładzie pojawia się osąd inżynierski.
Polityka może faworyzować rdzenie wysokowydajne i unikać rdzeni energooszczędnych podczas interaktywnego generowania. Inna polityka może wykorzystywać więcej rdzeni do przetwarzania promptu, a następnie zmniejszać liczbę wątków podczas generowania.
Warunki termiczne mogą odwrócić te preferencje podczas dłuższych sesji. Telefon z lepszym chłodzeniem może utrzymać konfigurację, która w cieńszym urządzeniu szybko ulega ograniczeniu termicznemu.
Planowanie zadań w Androidzie również ogranicza, jak stanowczo aplikacja może kontrolować rozmieszczenie pracy. Powinowactwo wątków może ukierunkować wykonanie, ale nadal znaczenie mają zasady systemu operacyjnego i ograniczenia urządzenia.
Benchmarki w czasie działania mogłyby dostarczyć kolejnego sygnału. Krótki test kalibracyjny mógłby porównać konfiguracje na rzeczywistym urządzeniu przed wybraniem jednej z nich.
Kalibracja opóźnia jednak uruchomienie, zużywa energię i grozi optymalizowaniem pod syntetyczny test. Wyniki zapisane w pamięci podręcznej mogą stać się nieaktualne po aktualizacjach systemu operacyjnego lub aplikacji.
Rekomendacja oparta na regułach jest szybsza i bardziej przewidywalna. Wymaga też szerokiej macierzy testów urządzeń, aby wykazać, że jej reguły dają się uogólnić.
To mechanizm leżący u podstaw ARPL. Wykrywanie zbiera wiarygodne fakty, a polityka przekształca je w ustawienia mające konsekwencje dla wydajności.
Pierwsza część opiera się na ustalonych interfejsach Androida. Druga pozostaje najsłabiej niezależnie zweryfikowanym elementem projektu.
To rozdzielenie daje programistom użyteczny sposób oceny repozytorium. Mogą ocenić dokładność wykrywania bez akceptowania każdej rekomendacji strojenia.
Mogą również rejestrować konfigurację wybraną przez ARPL obok wyników benchmarków. Ujawniłoby to, czy rekomendacja poprawia szybkość przetwarzania promptów, szybkość generowania, zużycie pamięci i zachowanie termiczne przy długotrwałym obciążeniu.
Taka instrumentacja ma większe znaczenie niż pojedynczy głośny wynik. Tuner działający w czasie działania zasługuje na zaufanie, gdy jego wybory pozostają wyjaśnialne i odwracalne.
Strojenie kontekstu to obszar, w którym ryzyko się kumuluje
Dobór wątków jest stosunkowo ograniczony, ale automatyczne zmiany w flash attention i formatach pamięci podręcznej KV mogą wpływać na kompatybilność, pamięć i jakość wyników.
Projekt llama.cpp obsługuje wiele backendów sprzętowych. Dokumentacja kompilacji dla Androida obejmuje natywną kompilację, podczas gdy szersze wsparcie funkcji różni się między ścieżkami CPU i akceleratorów.
Przewodnik kompilacji dla Androida potwierdza, że programiści mogą kompilować projekt za pomocą Android NDK. Nie obiecuje jednak identycznego działania na każdym telefonie.
Flash attention może zmniejszyć ruch pamięci, obliczając uwagę w kafelkowanych operacjach. To, czy pomaga, zależy od backendu, obsługiwanych formatów danych, długości sekwencji i dostępnych kerneli.
Kwantyzacja pamięci podręcznej KV zmniejsza pamięć wykorzystywaną do przechowywanych kluczy i wartości. Ta oszczędność może umożliwić dłuższy kontekst lub pozostawić więcej pamięci na wagi modelu.
Może też wprowadzać dodatkową pracę związaną z dekwantyzacją i zmiany numeryczne. Niektóre kombinacje formatów wymagają wyspecjalizowanych kerneli, podczas gdy nieobsługiwane kombinacje mogą przejść na rozwiązanie zastępcze lub zakończyć się błędem.
Publiczna macierz funkcji llama.cpp wymienia flash attention i kwantyzację pamięci podręcznej dla głównych backendów. Macierz pokazuje również obszary częściowo obsługiwane lub niepewne.
Ta zmieniająca się powierzchnia wsparcia wywiera presję związaną z wersjonowaniem na ARPL. Rekomendacja poprawna dla jednej rewizji llama.cpp może stać się zbędna lub niekompatybilna po zmianie upstream.
Różnice między backendami sprawiają, że globalne reguły są szczególnie niebezpieczne. Ścieżki CPU, Vulkan, OpenCL i Hexagon niekoniecznie obsługują te same typy pamięci podręcznej lub implementacje attention.
Jeden eksperyment OpenCL z 2026 roku na Snapdragon 8 Elite opisywał dodanie ścieżek kwantyzowanej pamięci podręcznej do forka Adreno. Autor przedstawił tę pracę jako eksperyment, a nie ukończony wkład do projektu.
W przypadku kontekstu 64K w tej konfiguracji zgłoszona pamięć podręczna F16 KV zajmowała 1 054 MiB. Q4_0 i IQ4_NL miały według raportu zajmować po 296 MiB.
Ten sam autor ostrzegł, że testy obejmowały proste prompty, a nie rygorystyczną ocenę dokładności przy długim kontekście. Eksperyment z kwantyzowaną pamięcią podręczną pokazuje więc potencjał, a nie ogólną niezawodność.
Pokazuje też, dlaczego automatyczna polityka jest atrakcyjna. Użytkownicy nie powinni musieć rozumieć kerneli backendu tylko po to, by wybrać format pamięci podręcznej mieszczący się w ich telefonie.
Ukrycie złożoności nie usuwa jednak problemu. ARPL musi znać aktywny backend, obsługiwane operacje, architekturę modelu, dostępną pamięć i żądany kontekst.
Same flagi ISA sprzętu nie odpowiadają na wszystkie te pytania. Procesor może obsługiwać instrukcję, podczas gdy wybrany backend llama.cpp nigdy z niej nie korzysta.
Podobnie telefon może udostępniać wydajny GPU, ale jego sterownik, wersja Androida lub zachowanie pamięci mogą sprawić, że konkretna ścieżka będzie zawodna.
Publiczny opis nie zawiera pełnej metodologii benchmarków, macierzy urządzeń ani specyfikacji obsługi błędów. Wskazuje, że testy przeprowadzono na Samsungu S25 Ultra, model SM-S938B.
Jeden testowany telefon nie może potwierdzić kompatybilności między urządzeniami z Snapdragon 8 Elite, a tym bardziej ze starszymi procesorami Qualcomm, MediaTek, Samsung lub Google.
Licencja PolyForm Noncommercial nakłada dodatkowe ograniczenie. Zezwala na inspekcję i użycie niekomercyjne na określonych warunkach, ale nie jest konwencjonalną liberalną licencją open source.
Zespoły tworzące aplikacje komercyjne musiałyby przeanalizować te warunki przed integracją kodu. Mogą zamiast tego przeanalizować podejście i wdrożyć osobną warstwę polityki.
Z ogłoszenia nadal nie wynika jasno relacja repozytorium z upstream. Nie ma dowodów, że opiekunowie llama.cpp przyjęli interfejs lub rekomendacje ARPL.
Nie umniejsza to jego wartości jako prototypu. Ogranicza jednak pewność, z jaką programiści powinni traktować jego ustawienia domyślne jako część platformy llama.cpp.
Ostrożna integracja powinna zachować obserwowalność każdej optymalizacji. Logi powinny rejestrować wykryte funkcje, wybrane wątki, formaty pamięci podręcznej, status flash attention i zdarzenia przejścia awaryjnego.
Powinna też oferować tryb bezpieczny wyłączający zmiany polityki. Użytkownicy i testerzy potrzebują punktu odniesienia do diagnozowania awarii, regresji lub nieoczekiwanych wyników.
Wreszcie rekomendacje powinny być wersjonowane. Politykę powiązaną z konkretną rewizją llama.cpp łatwiej odtworzyć niż cichą konfigurację zmieniającą się między aktualizacjami.
Obietnicą ARPL jest automatyzacja bez strojenia dla każdego urządzenia. Jej bezpośrednim wyzwaniem jest udowodnienie, że automatyzacja pozostaje zachowawcza, gdy informacje są niepełne.
Wykrywanie w czasie działania konkuruje ze statycznymi profilami urządzeń
Główna rywalizacja nie toczy się między ARPL a inną firmą; chodzi o wykrywanie możliwości w czasie działania kontra statyczna konfiguracja przypisana do konkretnego urządzenia.
Statyczne profile mają jedną dużą przewagę. Programiści mogą przeprowadzić benchmark znanego urządzenia, zatwierdzić konfigurację i wdrożyć dokładnie ten zestaw.
W przypadku ograniczonej floty sprzętowej takie podejście może być skuteczne. Aplikacja korporacyjna wdrożona na kilku zarządzanych urządzeniach może nie potrzebować ogólnej polityki działania.
Profile ułatwiają również odtwarzanie regresji. Testerzy wiedzą, które ustawienia powinny pojawić się na każdym obsługiwanym telefonie.
Ich słabością jest utrzymanie. Modele Androida szybko się mnożą, warianty regionalne się różnią, a aktualizacje systemu mogą zmieniać sterowniki lub zachowanie planowania zadań.
Nazwa urządzenia jest też niedoskonałym wskaźnikiem możliwości. Różne produkty mogą współdzielić układ krzemowy, podczas gdy produkty o podobnych nazwach marketingowych mogą zawierać inne komponenty.
Wykrywanie możliwości pozwala uniknąć tego problemu z nazewnictwem. Pyta system operacyjny, które funkcje są dostępne, zamiast wnioskować o nich z etykiety modelu.
Daje to wykrywaniu w czasie działania czystszą podstawę do wyboru ISA. Zmniejsza również presję na aktualizowanie listy dozwolonych urządzeń za każdym razem, gdy pojawia się kolejny telefon.
Wykrywanie topologii opiera się na tej samej logice, ale wymaga większej interpretacji. Informacje o klastrach opisują strukturę, podczas gdy użyteczna rekomendacja liczby wątków zależy od obserwowanego zachowania obciążenia.
Statyczne strojenie może zakodować te obserwacje dla każdego przetestowanego urządzenia. ARPL próbuje uogólnić je do reguł działających, zanim urządzenie otrzyma indywidualną uwagę.
Najlepszy system produkcyjny może łączyć obie metody. Wykrywanie w czasie działania może zapewniać ustawienie domyślne, a zweryfikowane nadpisania dla urządzeń mogą obsługiwać znane wyjątki.
Taki system nadpisań nie unieważniałby idei ARPL. Uznawałby, że raportowanie sprzętu Androida i zachowanie wydajnościowe zawierają przypadki brzegowe.
Własne wytyczne Google dotyczące funkcji CPU wskazują na ten hybrydowy model. Standardowa inspekcja HWCAP zapewnia podstawowy sygnał, a wiedza specyficzna dla urządzenia rozwiązuje problem błędnych raportów.
Inna konkurencyjna ścieżka przenosi wykonanie z CPU. Qualcomm i współtwórcy llama.cpp rozwijają backendy Adreno i Hexagon, ukierunkowane na wyspecjalizowane procesory.
CPU Oryon firmy Qualcomm nadal ma znaczenie, ponieważ część operacji modelu pozostaje na CPU. Rezerwa w postaci CPU zapewnia też szeroko dostępne rozwiązanie, gdy akceleratory zawodzą.
Przyszły harmonogram dzielący pracę między CPU, GPU i NPU sprawiłby jednak, że liczba wątków byłaby tylko jednym elementem większej decyzji.
Deweloper ARPL już wskazuje heterogeniczny podział pracy jako niedokończony. To przyznanie słusznie zawęża oczekiwania wobec obecnego wydania.
Własne narzędzia Qualcomm oferują inną ścieżkę dla programistów ukierunkowanych na jego sprzęt. GenieX, AI Hub i Qualcomm AI Runtime korzystają z bardziej zależnej od dostawcy integracji.
llama.cpp odpowiada na inny cel: przenośne lokalne wnioskowanie w wielu systemach i backendach. ARPL próbuje zachować tę przenośność, jednocześnie pozyskując więcej informacji specyficznych dla urządzenia.
Tworzy to trwały kompromis. Runtime’y dostawców mogą udostępniać wyspecjalizowane możliwości, podczas gdy przenośne runtime’y korzystają ze wspólnych formatów i szerszego zasięgu sprzętowego.
ARPL znajduje się pomiędzy tymi podejściami. Zachowuje llama.cpp jako silnik wnioskowania, ale dostarcza warstwę adaptacyjną dopasowaną do telefonów ARM.
Ta pozycja staje się użyteczna, jeśli polityka pozostaje przejrzysta. Tuner typu czarnej skrzynki odtworzyłby nieprzejrzystość, z którą programiści często spotykają się w stosach dostawców.
Czytelny silnik rekomendacji może natomiast dokumentować, dlaczego ustawienie się zmieniło. Może też pozwolić opiekunom upstream kwestionować założenia za pomocą danych z benchmarków.
Publiczne wydanie projektu tworzy konkretne miejsce dla tej dyskusji. Przed wdrożeniem potrzebuje wkładów z urządzeń wykraczających poza jeden flagowy model Samsunga.
Trzy testy zdecydują, czy ARPL da się uogólnić
ARPL potrzebuje teraz dowodów, że wykrywane przez niego możliwości prowadzą do lepszych decyzji na różnych urządzeniach, przy różnych obciążeniach i rewizjach llama.cpp.
Pierwszym sygnałem jest odtwarzalny pakiet benchmarków na wielu urządzeniach. Powinien obejmować obecne flagowce, starsze telefony premium i procesory ze średniej półki od wielu dostawców.
Każde urządzenie powinno porównywać neutralną bazę llama.cpp z rekomendacją ARPL. Testy powinny raportować przetwarzanie promptów, generowanie tokenów, zużycie pamięci, energii i zachowanie termiczne przy długotrwałym obciążeniu.
Pakiet musi rozdzielać wykonanie wyłącznie na CPU od ścieżek OpenCL, Vulkan i Hexagon. Łączenie backendów zacierałoby obraz tego, czy zyski pochodziły ze strojenia topologii, czy ze zmian w akceleratorach.
Wyniki powinny również uwzględniać zmienność między powtarzanymi uruchomieniami. Niewielka średnia poprawa ma mniejsze znaczenie, gdy opóźnienia stają się niestabilne lub telefon szybko ogranicza wydajność termicznie.
Jeśli ARPL konsekwentnie przewyższa rozsądne ustawienia domyślne w całej tej macierzy, jego ogólna polityka zyska wiarygodność. Częste wyjątki przemawiałyby za hybrydowym projektem z przetestowanymi nadpisaniami.
Drugim sygnałem jest śledzenie kompatybilności z upstream llama.cpp. Projekt zmienia się szybko, w tym w zakresie wsparcia backendów, struktur kontekstu i implementacji pamięci podręcznej.
ARPL potrzebuje automatycznych testów względem określonych rewizji llama.cpp. Testy te powinny wykrywać sytuacje, w których łatka celuje w usunięty parametr lub wybiera nieobsługiwany format.
Dyskusja z upstream lub zaakceptowany interfejs wzmocniłyby kierunek projektu. Wskazywałyby, że opiekunowie postrzegają politykę działania jako wspólny problem.
Brak wdrożenia upstream nie podważyłby automatycznie wiarygodności ARPL. Oznaczałby natomiast, że zespoły tworzące aplikacje same ponoszą większą odpowiedzialność za integrację i regresje.
Trzecim sygnałem są postępy w heterogenicznym harmonogramowaniu. Użyteczny prototyp powinien pokazać, jak dane o topologii CPU współdziałają z odciążaniem obliczeń na GPU lub NPU.
W ramach tych prac trzeba mierzyć transfery i synchronizację, a nie jedynie potwierdzać, że każdy procesor potrafi wykonać operację modelu. Przyspieszenie mobilne może tracić wartość, gdy dominują koszty koordynacji.
Równie istotna będzie jasna obsługa błędów. Harmonogram powinien w przewidywalny sposób przechodzić na rozwiązanie zapasowe, gdy sterownik odrzuci operację lub zawiedzie przydział pamięci.
Jeśli ARPL dostarczy te trzy sygnały, stanie się czymś więcej niż interesującą prezentacją Snapdragon 8 Elite. Zaoferuje testowalną architekturę adaptacyjnego wnioskowania na Androidzie.
Jeśli dowody pozostaną ograniczone do jednego telefonu i usprawnień raportowanych przez deweloperów, zespoły powinny traktować to jako kod badawczy. Techniki wykrywania mogą mimo to pomóc w ich własnych implementacjach.
Dla deweloperów oceniających dziś to wydanie praktycznym kolejnym krokiem jest kontrolowane porównanie. Należy zapisać wybrane ustawienia, zachować stałą wartość bazową i przetestować obciążenia, które użytkownicy faktycznie uruchamiają.
Zespoły powinny przechowywać te obserwacje obok wersji modeli, szczegółów urządzeń i ustawień kompilacji. Przeszukiwalna baza wiedzy inżynierskiej może zapobiec temu, by obiecujące wyniki stały się niemożliwą do zweryfikowania wiedzą przekazywaną z ust do ust.
Szersze pytanie nie brzmi już, czy telefony z Androidem różnią się na tyle, by uzasadniać adaptacyjną konfigurację. Zdecydowanie tak jest.
Pytanie brzmi, czy polityka ARPL potrafi przełożyć dokładne wykrywanie sprzętu na konsekwentnie lepsze wybory w llama.cpp. Odpowiedź przyniosą przejrzyste benchmarki, szersza gama urządzeń i testy zgodności z upstream.
