Google AI Edge Gallery — modele LLM działające offline na telefonie

Pytanie od klienta brzmi zwykle tak: „a czy to może działać bez internetu i bez wysyłania naszych danych na zewnątrz?". Przy funkcjach opartych na modelach językowych odpowiedź prawie zawsze jest przecząca — model stoi u dostawcy, a aplikacja tylko go odpytuje.

Prawie, bo modele zmniejszyły się na tyle, że część z nich mieści się w telefonie. Problem polega na tym, że od stwierdzenia „to jest możliwe" do odpowiedzi „na sprzęcie twoich użytkowników to zadziała" jest daleka droga, a przejść ją można tylko przez pomiar.

Google AI Edge Gallery (github.com/google-ai-edge/gallery) jest aplikacją zbudowaną właśnie do tego: pobierasz model na urządzenie, uruchamiasz go całkowicie lokalnie i — co dla nas najważniejsze — mierzysz, jak zachowuje się na konkretnym telefonie.

Stan projektu

Dane z API GitHuba na 14 października 2026:

• 24 665 gwiazdek i 2676 forków, repozytorium założone 31 marca 2025, kod w Kotlinie, licencja Apache-2.0,
• ostatni push dzień przed napisaniem tego tekstu, wersja 1.0.19 z 2 września 2026,
• 367 otwartych zgłoszeń,
• aplikacja jest dostępna na Androida, iOS i macOS — zaczynała od samego Androida,
• wymagania systemowe: Android 12 lub nowszy, iOS 17 lub nowszy,
• a przy tym projekt sam określa się jako „eksperymentalne wydanie beta".

Commity z ostatnich dni dotyczą przywracania sesji czatu, obsługi metadanych modeli w liście dozwolonych oraz — dwa razy w tygodniu — wsparcia dla dostępności. To ostatnie jest szczegółem wartym odnotowania: przy aplikacji demonstracyjnej dostępność jest zwykle pierwszą rzeczą, którą się pomija.

Liczby, które rozstrzygają o wykonalności

Lista dozwolonych modeli jest w repozytorium jako plik JSON, wersjonowany osobno dla każdego wydania — więc da się sprawdzić dokładnie, co jest dostępne dzisiaj. Oto pełny zestaw z wersji 1.0.19, z rozmiarami pobrania:

• Gemma-4-E2B-it — 2,59 GB, kontekst 4000 tokenów, obraz i dźwięk,
• Gemma-4-E4B-it — 3,66 GB, kontekst 4000, obraz i dźwięk,
• Gemma-3n-E2B-it — 3,66 GB oraz Gemma-3n-E4B-it — 4,92 GB, kontekst 4096, obraz i dźwięk,
• Gemma3-1B-IT — 0,58 GB, kontekst 1024, tylko tekst,
• Qwen2.5-1.5B-Instruct — 1,60 GB oraz DeepSeek-R1-Distill-Qwen-1.5B — 1,83 GB, kontekst 4096, tylko tekst,
• MobileActions-270M i TinyGarden-270M — po 0,29 GB, kontekst 1024,
• oraz drobny model pomocniczy ważący 30 megabajtów.

Te liczby same w sobie są ostrzeżeniem: najlepszy dostępny model to prawie pięć gigabajtów do pobrania, a nawet nowa Gemma 4 w mniejszym wariancie to dwa i pół. Przy funkcji w aplikacji dla klienta oznacza to rozmowę o tym, czy użytkownik zgodzi się na taki transfer i czy zmieści się on w jego pamięci.

Ważniejsze jest jednak zapotrzebowanie na pamięć operacyjną. Starsza wersja listy podawała szacowane szczytowe zużycie pamięci i te wartości są pouczające: dla wariantu E2B rodziny 3n było to około 5,9 GB, a dla E4B blisko 7 GB. Dla najmniejszego modelu tekstowego — około 2,1 GB.

Przełóżmy to na decyzję projektową. Model, który mówi „szczyt 7 GB pamięci", nie zadziała na telefonie z 8 GB pamięci obok systemu i pozostałych aplikacji — a takie telefony to dziś górna półka, nie średnia. Funkcja offline oparta na dużym modelu jest więc funkcją dla części użytkowników, a nie dla wszystkich, i tak trzeba ją zaplanować: z wykrywaniem możliwości urządzenia i ścieżką zapasową.

Odwrotny wniosek jest równie użyteczny: modele o rozmiarze 270 megabajtów i kontekście tysiąca tokenów zadziałają praktycznie wszędzie. Nie napiszą eseju, ale do rozpoznania intencji, wyciągnięcia parametrów z polecenia albo klasyfikacji wystarczą — i to jest realny obszar zastosowań na urządzeniach.

iOS ma trzy modele, nie dziesięć

Lista dozwolonych modeli jest osobna dla iOS i różnica jest na tyle duża, że przy planowaniu projektu rozstrzyga o wyborze platformy. Na iOS dostępne są trzy modele: Gemma-3n-E2B-it (3,39 GB), Gemma-3n-E4B-it (4,65 GB) oraz Gemma3-1B-IT (0,58 GB, tu z kontekstem 4096).

Czego tam nie ma: całej rodziny Gemma 4, Qwen, DeepSeeka i — co dla zastosowań praktycznych najbardziej bolesne — obu małych modeli o 270 milionach parametrów. Wniosek jest konkretny: jeśli użytkownicy klienta pracują na iPhone'ach, wybór zawęża się do trzech pozycji, z których najmniejsza waży 580 megabajtów, a nowszej generacji modeli nie ma w ogóle. Przy aplikacji wieloplatformowej trzeba więc liczyć się z tym, że ta sama funkcja offline będzie miała inne możliwości na obu systemach.

Co można w tym zrobić

Aplikacja jest zestawem kafelków, z których każdy pokazuje inny rodzaj zastosowania:

• Czat z trybem myślenia — wieloturowa rozmowa z możliwością zobaczenia rozumowania modelu krok po kroku. Tryb myślenia działa na wybranych modelach, począwszy od rodziny Gemma 4,
• Pytanie o obraz — rozpoznawanie obiektów i opisywanie zdjęć z kamery albo galerii,
• Transkrypcja dźwięku — zamiana nagrań głosowych na tekst wraz z tłumaczeniem, w czasie rzeczywistym,
• Laboratorium promptów — pojedyncze zapytania z kontrolą parametrów, w tym temperatury i odcięcia najlepszych wyników,
• Akcje mobilne — sterowanie urządzeniem i zadania automatyczne, napędzane dostrojoną wersją modelu FunctionGemma o 270 milionach parametrów,
• Mały ogród — eksperymentalna gra, w której poleceniami w języku naturalnym sadzi się i zbiera wirtualne rośliny; ten sam dostrojony model,
• Zarządzanie modelami i test wydajności — pobieranie z listy albo wczytanie własnego modelu oraz uruchomienie pomiaru.

Dwa ostatnie kafelki są dla profesjonalisty najważniejsze, a pierwsze pięć to sposób, żeby w dziesięć minut wyrobić sobie zdanie o tym, co model tej wielkości potrafi.

Test wydajności jako narzędzie decyzyjne

To jest sekcja, dla której warto mieć tę aplikację zainstalowaną, nawet jeśli nigdy nie użyjemy jej do niczego innego.

Zanim obiecamy klientowi funkcję działającą offline, trzeba odpowiedzieć na trzy pytania: ile czasu zajmuje pierwsza odpowiedź, ile tokenów na sekundę generuje model i czy telefon tego nie odrzuci. Odpowiedzi nie da się wziąć z tabelki producenta, bo zależą od konkretnego układu, ilości pamięci, temperatury urządzenia i tego, czy używany jest procesor, czy układ graficzny — a lista modeli podaje przy każdym dopuszczalne akceleratory.

Praktyczny sposób pracy, który bym zastosował: bierzemy dwa albo trzy telefony reprezentujące sprzęt użytkowników klienta, pobieramy na nie kandydujące modele i uruchamiamy pomiar. Wynik jest liczbą, którą można wstawić do oferty — albo argumentem, żeby funkcji offline nie obiecywać. Kilkanaście minut pracy zamiast tygodnia prototypowania i późniejszego tłumaczenia się.

Możliwość wczytania własnego modelu domyka to: jeśli klient ma model dostrojony pod swoją dziedzinę, można sprawdzić go na docelowym sprzęcie bez pisania ani linii aplikacji.

Umiejętności agenta i wczytywanie ich z adresu

Nowsza funkcja zamienia model z rozmówcy w narzędzie działające: umiejętności agenta dokładają możliwości takie jak sięganie do Wikipedii dla oparcia odpowiedzi na faktach, interaktywne mapy i karty podsumowań wizualnych.

Jest tu jednak szczegół, który wymaga świadomości: umiejętności można wczytywać z adresu URL, a społeczność wymienia się nimi w dyskusjach na GitHubie. Połączmy to z faktem, że osobny kafelek daje modelowi sterowanie urządzeniem — i wniosek jest oczywisty: wczytanie umiejętności z nieznanego adresu to wpuszczenie cudzej definicji zachowania do agenta mającego dostęp do telefonu. Przy zabawie własnym urządzeniem to sprawa gustu; przy telefonie służbowym z dostępem do poczty firmowej — już nie.

Wywoływanie funkcji na urządzeniu

Repozytorium ma osobny przewodnik pokazujący, jak wyjść poza dostarczone demonstracje — i jest to najbardziej techniczna, a zarazem najbardziej przydatna część projektu, jeśli myślimy o własnym wdrożeniu.

Mechanizm jest oparty na adnotacjach i będzie znajomy każdemu, kto pracował z wywoływaniem funkcji przez model w chmurze. Definiuje się zestaw narzędzi, w którym każda metoda dostaje opis dla modelu, a jej parametry — własne opisy:

class MobileActionsTools(val onFunctionCalled: (Action) -> Unit) : Toolset {

  /** Opis dla modelu. */
  @Tool(description = "Description of what this function does")
  fun newCustomFunction(
    @ToolParam(description = "Description of the parameter") param: String
  ): Map<String, String> {
    onFunctionCalled(NewCustomAction(param = param))
    return mapOf("result" to "success")
  }
}

Reszta to zdefiniowanie typu akcji i klasy opisującej nazwę funkcji wraz z parametrami, ikoną i sposobem obsługi w aplikacji. Całość mieści się w kilku plikach i jest do przeczytania w kwadrans.

Przewodnik stawia przy tym jedno zdanie, które warto potraktować poważnie: do budowy wyspecjalizowanych agentów zaleca dostrojenie własnej wersji modelu, a nie tylko dołożenie funkcji. Ma to sens przy modelu o 270 milionach parametrów — na takiej skali dostrojenie pod konkretny zestaw funkcji jest tanie i daje różnicę większą niż jakiekolwiek majstrowanie przy promptach. Widać to zresztą w samej aplikacji: oba kafelki z akcjami stoją na dostrojonych wersjach tego samego małego modelu, a nie na dużym modelu ogólnym.

MCP na telefonie i granica prywatności

Aplikacja obsługuje Model Context Protocol, i to w sposób opisany rzetelnie. Uzasadnienie w dokumentacji jest trafne: model na urządzeniu jest szybki i prywatny, ale z natury nie ma dostępu do danych w czasie rzeczywistym ani do usług sieciowych. MCP domyka tę lukę standardowym protokołem.

Implementacja obejmuje dynamiczne wykrywanie narzędzi (aplikacja czyta schematy z serwerów), wstrzykiwanie opisów narzędzi do kontekstu modelu oraz — co najważniejsze — szczegółową kontrolę uprawnień: pytanie przy każdym wywołaniu oraz przełączane reguły „zawsze zezwalaj". Integracja jest oznaczona jako eksperymentalna.

Praktyka jest mniej wygodna i warto ją znać, zanim ktoś spróbuje. Większość serwerów MCP obsługuje wyłącznie transport przez standardowe wejście i wyjście, bo zakłada, że serwer i klient pracują na tej samej maszynie — co dla aplikacji mobilnej nie działa. Trzeba więc przestawić serwer na transport strumieniowy po HTTP, a dokumentacja podaje konkretne obejście przez narzędzie pośredniczące. Do tego aplikacja wymaga publicznie osiągalnego adresu, więc lokalny serwer trzeba wystawić tunelem.

I tu warto nazwać rzecz, której dokumentacja nie podkreśla, choć jej nie ukrywa: w momencie dodania serwera MCP kończy się właściwość „nic nie opuszcza urządzenia". Wnioskowanie nadal dzieje się lokalnie, ale wywołania narzędzi lecą do zewnętrznej usługi przez publiczny adres. To nie jest wada — narzędzia są z definicji zewnętrzne — ale jeśli argumentem za rozwiązaniem lokalnym była prywatność, trzeba wiedzieć, gdzie ta granica przebiega.

Czym ta aplikacja nie jest

Najważniejsze rozgraniczenie i najczęstsze nieporozumienie. To nie jest biblioteka do wbudowania w aplikację klienta. To galeria — środowisko do sprawdzania i porównywania.

Do wdrożenia funkcji na urządzeniu służą narzędzia, do których projekt odsyła: Google AI Edge jako zestaw API, LiteRT jako lekkie środowisko uruchomieniowe modeli oraz osobny projekt LiteRT-LM; modele w liście dozwolonych wskazują przy tym na API wnioskowania MediaPipe. Pobieranie i odnajdywanie modeli idzie przez Hugging Face i społeczność publikującą tam wersje przygotowane pod LiteRT.

Kod aplikacji ma natomiast osobną wartość: skoro jest na Apache-2.0, to jest to czytelny, produkcyjny przykład tego, jak się to robi — od pobierania i weryfikacji modeli, przez zarządzanie sesją czatu, po obsługę uprawnień narzędzi. Przy pisaniu własnej integracji jest to lepsze źródło niż dokumentacja.

Detal dla kogoś, kto chce zbudować aplikację lokalnie: potrzebna jest własna aplikacja developerska w Hugging Face i wpisanie jej identyfikatora oraz adresu przekierowania w konfiguracji projektu, bo bez tego pobieranie modeli nie zadziała.

Pułapki

• Rozmiary pobrania od 0,29 do 4,92 GB — funkcja offline zaczyna się od rozmowy o transferze i miejscu na urządzeniu,
• Szczytowe zużycie pamięci w okolicach 6–7 GB dla większych modeli. To wyklucza większość telefonów w rękach użytkowników,
• Kontekst 1024 tokenów w małych modelach — mieści się w nim krótkie polecenie, nie dokument,
• Lista modeli na iOS jest znacznie krótsza niż na Androidzie i nie zawiera najnowszej generacji,
• „Eksperymentalne wydanie beta" według samego projektu, przy 367 otwartych zgłoszeniach,
• Umiejętności wczytywane z adresu URL obok kafelka sterującego urządzeniem — połączenie wymagające ostrożności,
• MCP jest eksperymentalny, wymaga transportu strumieniowego po HTTP i publicznie osiągalnego adresu serwera,
• Dodanie MCP kończy pełną lokalność — wywołania narzędzi opuszczają urządzenie,
• To nie jest biblioteka; do wdrożenia służą LiteRT, LiteRT-LM i API MediaPipe,
• Budowanie lokalnie wymaga własnej aplikacji OAuth w Hugging Face,
• Modele mają własne licencje — o czym w ostatnim akapicie, bo to najważniejsze zastrzeżenie przy zastosowaniu komercyjnym.

Gdzie to ma sens w naszej pracy

• Odpowiedź na pytanie klienta „czy da się bez chmury". Zamiast opinii — pomiar na jego sprzęcie, w kwadrans,
• Wybór modelu przed rozpoczęciem projektu. Dziesięć modeli o różnym rozmiarze i możliwościach, sprawdzalnych obok siebie na tym samym urządzeniu,
• Ocena małych modeli do zadań wąskich. Rozpoznanie intencji, wyciągnięcie parametrów, klasyfikacja zgłoszenia — tu modele o 270 milionach parametrów wystarczają i działają wszędzie,
• Prototyp funkcji multimodalnej. Zdjęcie towaru, opis usterki nagrany głosem, transkrypcja z tłumaczeniem — wszystko sprawdzalne bez pisania aplikacji,
• Kod jako materiał źródłowy. Przy pisaniu własnej integracji z LiteRT jest to najlepsza dostępna próbka,
• Argument w rozmowie o prywatności. Klientowi z wymogiem nieopuszczania danych da się pokazać działający model na jego telefonie, w trybie samolotowym. To przekonuje skuteczniej niż każda prezentacja.

Podsumowanie

• Modele językowe działające w pełni na telefonie, na Androidzie, iOS i macOS,
• Dziesięć modeli w aktualnej liście, od 0,29 do 4,92 GB, w tym Gemma 4 z obsługą obrazu i dźwięku,
• Szczytowe zużycie pamięci decyduje o wykonalności — sprawdź je przed obietnicą,
• Test wydajności na docelowym sprzęcie to najważniejsza funkcja tej aplikacji,
• Można wczytać własny model i zmierzyć go bez pisania kodu,
• Tryb myślenia, pytanie o obraz, transkrypcja z tłumaczeniem i laboratorium promptów pokrywają typowe zastosowania,
• Dwa modele o 270 milionach parametrów obsługują sterowanie urządzeniem — realny obszar dla małych modeli,
• iOS ma tylko trzy modele i żadnego z rodziny Gemma 4 ani z małych — to zmienia plan przy aplikacji wieloplatformowej,
• Wywoływanie funkcji jest oparte na adnotacjach, a przewodnik zaleca dostrojenie własnego małego modelu,
• MCP jest obsługiwany, ale eksperymentalnie i za cenę wyjścia poza urządzenie,
• Umiejętności z adresu URL wymagają ostrożności,
• To galeria, nie biblioteka — do wdrożenia LiteRT i MediaPipe,
• Aplikacja jest na Apache-2.0, ale modele mają własne warunki.

Licencja: sama aplikacja jest na Apache-2.0 — wolno używać komercyjnie, modyfikować, wpinać we własne produkty i redystrybuować, przy zachowaniu noty licencyjnej, pliku NOTICE, jeśli występuje, i odnotowaniu istotnych zmian w modyfikowanych plikach; dochodzi do tego jawna licencja patentowa od kontrybutorów. Dla kodu Kotlina i Swifta, który chcemy czytać albo z którego chcemy zapożyczyć rozwiązania, sytuacja jest więc czysta. I na tym kończy się to, co obejmuje ta licencja. Najważniejsze zastrzeżenie przy jakimkolwiek zastosowaniu komercyjnym brzmi: wagi modeli nie są objęte licencją aplikacji. Każdy z dziesięciu modeli w liście dozwolonych ma własne warunki — rodzina Gemma jest udostępniana na osobnych warunkach użytkowania Gemma, zawierających zasady dopuszczalnego użycia, a modele Qwen i DeepSeek mają jeszcze inne licencje, ustalane u ich wydawców. Praktyczny wniosek dla projektu klienckiego jest jednoznaczny: zanim obiecamy funkcję opartą na konkretnym modelu, trzeba przeczytać licencję tego modelu — nie licencję aplikacji, w której go zobaczyliśmy. Dotyczy to zwłaszcza sytuacji, w której model miałby zostać dołączony do aplikacji dystrybuowanej w sklepie albo dostrojony na danych klienta. Osobno warto pamiętać, że pobieranie modeli idzie przez Hugging Face, więc obowiązują też warunki tej platformy, a budowanie aplikacji lokalnie wymaga własnej aplikacji developerskiej po jej stronie.