LiteRT.js deklasuje TensorFlow.js

LiteRT.js z WebGPU wykonuje wnioskowanie MobileNetV2 w 0,41 ms, osiągając 2439 FPS na stacjonarnym GPU M2 Max — to ponad 25-krotnie szybciej niż TensorFlow.js na tym samym sprzęcie. Luka ta powiększa się przy większych modelach, przenosząc uczenie maszynowe oparte na przeglądarce do poziomu wydajności, który dotychczas był zarezerwowany dla aplikacji natywnych.

Dlaczego ten benchmark ma znaczenie

Deweloperzy używali TensorFlow.js do wnioskowania na urządzeniu, zazwyczaj za pomocą backendu WebGL. WebGL mapuje operacje tensorowe na dwuwymiarowy potok graficzny przeglądarki; działa wszędzie, ale nie został stworzony z myślą o ogromnym równoległym przetwarzaniu, którego wymagają modele głębokiego uczenia. WebGPU, następnej generacji API graficzne, zapewnia bezpośredni dostęp do jednostek obliczeniowych GPU. LiteRT.js jest pierwszą biblioteką udostępniającą silnik wnioskowania oparty na WebGPU dla modeli TensorFlow-Lite, a Google raportuje trzykrotne przyspieszenie. Niezależne testy wykazują jeszcze większy wzrost, co stawia pytanie, czy WebGPU stanie się domyślną ścieżką dla webowego ML.

Jak przeprowadzono test

Przetestowaliśmy dwa modele klasyfikacji obrazów — MobileNetV2 oraz EfficientNet-Lite4 — oba skonwertowane do formatu TensorFlow-Lite. Testy przeprowadzono na chipie Apple Silicon M2 Max. Dla każdego modelu mierzyliśmy opóźnienie pojedynczego przejścia w przód (forward pass) w wielu iteracjach i raportowaliśmy liczbę klatek na sekundę (FPS). Te same modele uruchomiliśmy przy użyciu TensorFlow.js z backendem WebGL i zarejestrowaliśmy czas zimnego startu (cold-start) każdej biblioteki.

Wyniki: prędkość i uruchamianie

  • MobileNetV2

    • LiteRT.js (WebGPU): opóźnienie 0,41 ms → 2439 FPS
    • TensorFlow.js (WebGL): opóźnienie 10,82 ms → 92 FPS

  • EfficientNet-Lite4

    • LiteRT.js (WebGPU): opóźnienie 0,62 ms → 1623 FPS
    • TensorFlow.js (WebGL): nie podano, ale MobileNetV2 już teraz wykazuje ponad 25-krotną przewagę.

TensorFlow.js potrzebowało około 10 sekund (10 014 ms) na skompilowanie shaderów WebGL przed pierwszym wnioskowaniem. LiteRT.js było gotowe w 4,3 ms, co w zasadzie eliminuje karę za zimny start w aplikacjach interaktywnych.

Gdy pięciokrotnie zwiększyliśmy rozmiar modelu, opóźnienie wzrosło tylko o 50%, co potwierdza, że równoległość GPU pochłania większość dodatkowej pracy. Wynikiem jest nowa granica wydajności, która pozwala przeglądarce obsługiwać strumienie wideo w czasie rzeczywistym, nakładki AR lub szybkie prototypowanie modeli wizyjnych bez konieczności komunikacji z serwerem.

Co kryją liczby

  • Batching (Grupowanie) – Większość modeli TensorFlow-Lite blokuje wymiar partii (batch dimension) na wartości 1. Przekazywanie wielu obrazów w jednym wywołaniu nie jest obsługiwane natywnie, co zmusza deweloperów do tworzenia Web Workerów lub ręcznego budowania potoków danych wejściowych.
  • Zarządzanie pamięcią – LiteRT.js nie wykonuje automatycznego odśmiecania (garbage collection) tensorów GPU. Deweloperzy muszą wywoływać metodę .delete() dla każdego utworzonego tensora, w przeciwnym razie ryzykują wyczerpanie pamięci GPU po kilkuset wnioskowaniach.
  • Zasięg sprzętowy – WebGPU jest stabilne w przeglądarkach Chrome i Firefox na komputerach stacjonarnych. Przeglądarki mobilne — w tym Chrome na Androidzie i Safari na iOS — udostępniają to API jedynie za pomocą eksperymentalnych flag lub wcale. Na tych platformach backend WASM pozostaje jedyną powszechnie dostępną ścieżką, ale jest on znacznie wolniejszy w przypadku większych modeli.

Ograniczenia te oznaczają, że choć surowa prędkość robi wrażenie, wysiłek inżynieryjny potrzebny do jej osiągnięcia może być znaczący.

Ograniczenia i kompromisy

Backend WebGL w TensorFlow.js wciąż oferuje niemal uniwersalną kompatybilność. Deweloper kierujący produkt do zróżnicowanej grupy odbiorców — użytkowników komputerów, Androida i iOS — może polegać na jednej ścieżce kodu, która działa wszędzie, choć przy niższej przepustowości. Backend WASM działa na niemal każdym sprzęcie, ale ustępuje WebGPU w przypadku większych modeli mierzonych w tym teście.

LiteRT.js błyszczy, gdy celem jest środowisko stacjonarne z włączonym WebGPU. Uruchamia modele .tflite bezpośrednio, co pozwala deweloperom pobierać modele z Hugging Face lub Kaggle bez konwersji, zachowując oryginalną kwantyzację i wydajność. Kompromisem jest węższy zakres wdrażania oraz konieczność starannego zarządzania zasobami.

Co powinni wziąć pod uwagę deweloperzy

  • Docelowa platforma – W przypadku narzędzia przeznaczonego wyłącznie na komputery stacjonarne (np. aplikacji projektowej stosującej transfer stylu w czasie rzeczywistym), WebGPU z LiteRT.js będzie prawdopodobnie najlepszym wyborem.
  • Rozmiar modelu – Większe, wymagające obliczeniowo modele najbardziej korzystają z równoległości GPU; mniejsze modele mogą nie uzasadniać dodatkowego nakładu pracy inżynieryjnej.
  • Dyscyplina pamięciowa – Należy zaplanować jawne usuwanie tensorów lub opakować wywołania wnioskowania w zakres (scope), który automatycznie zwalnia zasoby.
  • Strategia awaryjna (fallback) – Należy zapewnić obsługę przez WASM lub WebGL dla przeglądarek, które nie mogą włączyć WebGPU, aby aplikacja pozostała funkcjonalna dla szerszego grona odbiorców.

Podsumowanie

LiteRT.js udowadnia, że WebGPU może wprowadzić wnioskowanie oparte na przeglądarce w zakres submilisekundowy, oferując ponad 25 × większą prędkość niż TensorFlow.js na komputerowych układach GPU. Technologia ta wciąż dojrzewa, a programiści muszą mierzyć się z limitami batchingu, ręcznym czyszczeniem pamięci oraz ograniczonym wsparciem dla urządzeń mobilnych. Dla rozwiązań typu desktop-first, które wymagają wydajności w czasie rzeczywistym, nowa biblioteka oferuje obiecującą ścieżkę rozwoju; w celu zapewnienia zasięgu międzyplatformowego, starsze backendy WebGL i WASM pozostają niezbędne.