Modele LLM na urządzeniu na taktycznym brzegu sieci: kwantyzacja i wdrożenie

Duży model językowy wymagający punktu końcowego w chmurze jest bezużyteczny na taktycznym brzegu sieci, ponieważ sieć jest najmniej niezawodnym elementem środowiska operacyjnego. Odmawiane, zdegradowane, przerywane lub niskoprzepustowe łącze nie jest w stanie przesłać zapytania do zdalnego modelu i zwrócić odpowiedzi w czasie, jaki decyzja dopuszcza – a wysyłanie tekstu operacyjnego poza platformę tworzy zarówno sygnaturę emisji, jak i ryzyko ujawnienia danych. Alternatywą jest uruchomienie modelu tam, gdzie są dane: na urządzeniu, z wyłączonym radiem, generując każdy token lokalnie. Ten artykuł opisuje, jak to się faktycznie robi – dobór modelu, kwantyzacja, budżety sprzętowe, pamięć podręczna klucz-wartość oraz szczegóły środowiska uruchomieniowego decydujące o tym, czy inferencja on-device jest responsywna, czy bezużyteczna z powodu wolności działania.

Dlaczego on-device i co to kosztuje

Argument za inferencją on-device jest prosty: usuwa sieć ze ścieżki krytycznej. Po załadowaniu modelu do pamięci nie ma zdalnych wywołań, zależności od łącza satelitarnego lub radiomesh, ani telemetrii opuszczającej platformę. Opóźnienie staje się deterministyczne – funkcja sprzętu i modelu, a nie kwestionowanego łącza. Prompty i wyniki mogące zawierać lokalizacje, oznaczenia jednostek lub zamiary nigdy nie opuszczają urządzenia.

Kosztem jest możliwość. Model mieszczący się na jednym urządzeniu brzegowym jest znacznie mniejszy niż frontierowy model chmurowy, a model o parametrach 7B–8B jest wyraźnie mniej zdolny w rozumowaniu otwartym niż model dwa rzędy wielkości większy. Dyscypliną pracy z modelami LLM on-device jest zatem definiowanie zakresu zadań: dopasowanie wąskiego, dobrze zdefiniowanego zadania do najmniejszego modelu, który może je niezawodnie wykonywać, zamiast oczekiwania, że mały model będzie ogólnym asystentem. Streszczanie raportów kontaktowych, klasyfikowanie przychodzących wiadomości według priorytetu, ekstrakcja strukturalnych pól z tekstu swobodnego lub odpowiadanie na pytania z lokalnego zestawu dokumentów – to wszystko zadania, z którymi mały model dobrze sobie radzi. Wieloetapowe rozumowanie w obszernym, niejednoznacznym kontekście to obszar, w którym małe modele zawodzą.

Dobór modelu: mniejszy niż myślisz

Instynkt, aby załadować największy model, jaki sprzęt może fizycznie pomieścić, to najczęstszy błąd przy wdrażaniu modeli LLM na brzegu sieci. Największy model nie pozostawia żadnego zapasu pamięci na okno kontekstu, pamięć podręczną klucz-wartość ani żadne współbieżne obciążenie współdzielące urządzenie – a przy generowaniu autoregresywnym większy model oznacza mniej tokenów na sekundę. Właściwym punktem wyjścia jest najmniejsza rodzina modeli, która potencjalnie jest zdolna do wykonania zadania, zwalidowana na zestawie testowym z rzeczywistych przykładów, zanim cokolwiek innego zostanie zoptymalizowane.

Jako przybliżone mapowanie: modele o parametrach 1B–3B są odpowiednie do szablonowej ekstrakcji, klasyfikacji i krótkich transformacji; działają na skromnym sprzęcie i generują szybko. Modele 7B–8B to klasa robocza do streszczania, pytań i odpowiedzi wspomaganych wyszukiwaniem oraz ograniczonego rozumowania, mieszcząca się wygodnie na akceleratorach brzegowych średniej klasy po kwantyzacji. Powyżej mniej więcej 13B parametrów wymagania pamięciowe i przepustowościowe generalnie przekraczają to, co pojedyncze wzmocnione urządzenie brzegowe może utrzymać przy interaktywnym tempie tokenów, a marginalna poprawa możliwości rzadko uzasadnia koszty na brzegu sieci.

Kwantyzacja: centralny kompromis

Kwantyzacja to technika, która sprawia, że modele LLM on-device są praktyczne. Model jest trenowany i dystrybuowany przy 16-bitowej precyzji zmiennoprzecinkowej, ale większość tej precyzji nie jest potrzebna do inferencji. Kwantyzacja ponownie koduje wagi przy niższych szerokościach bitowych – 8, 5 lub 4 bity i mniej – co proporcjonalnie zmniejsza ślad pamięciowy i zwiększa przepustowość, ponieważ czynnikiem ograniczającym generowanie jest przepustowość pamięci, a mniej bajtów na wagę oznacza mniej bajtów do przeniesienia na token.

Koszt dokładności jest nieliniowy i rozumienie jego kształtu oddziela solidne wdrożenie od kruchego. Kwantyzacja 8-bitowa jest prawie bezstratna dla niemal każdego zadania. Kwantyzacja 4-bitowa z użyciem nowoczesnego schematu K-quant (powszechnie oznaczanego Q4_K_M) typowo kosztuje 1–3 procent na testach rozumowania, zmniejszając przy tym rozmiar o połowę względem 8 bitów – to domyślny punkt optymalny dla wdrożeń brzegowych. Poniżej 4 bitów degradacja przyspiesza: wersje 3-bitowe i 2-bitowe mogą zawodzić na zadaniach rozumowania nawet wtedy, gdy nadal produkują płynny tekst, co czyni je niebezpiecznymi właśnie dlatego, że awaria nie jest oczywista przy pobieżnej lekturze.

Decydującym punktem jest to, że ten kompromis jest zależny od zadania i musi być mierzony, a nie zakładany. W przypadku zadań ekstrakcyjnych i szablonowych – wyciągnij współrzędne siatki z tej wiadomości, sklasyfikuj ten raport – model 4-bitowy działa zbliżenie do bazowego poziomu pełnej precyzji, ponieważ zadanie nie obciąża kruchych części modelu. W przypadku wieloetapowego rozumowania ta sama wersja 4-bitowa może tracić na tyle, by mieć znaczenie. Jedynym sposobem na sprawdzenie jest uruchomienie zestawu testowego przez bazę w pełnej precyzji, wersję 8-bitową i wersję 4-bitową, porównanie metryk istotnych dla zadania i zaakceptowanie najmniejszej wersji, której utrata mieści się w tolerancji operacyjnej. Wybór właściwego akceleratora brzegowego dla tego modelu to oddzielna dyscyplina – zapoznaj się z naszą analizą doboru sprzętu Edge AI dla obronności.

Kwantyzacja uwzględniająca trening a kwantyzacja post-treningowa

Większość wdrożeń brzegowych korzysta z kwantyzacji post-treningowej: bierze istniejący model i kwantyzuje wagi bezpośrednio, z opcjonalną kalibracją na małym reprezentatywnym zbiorze danych. Jest szybka, nie wymaga infrastruktury treningowej i jest wystarczająco dobra przy 4 bitach dla większości zadań. Kwantyzacja uwzględniająca trening – dostrajanie modelu z kwantyzacją symulowaną w przejściu do przodu – odzyskuje więcej dokładności przy bardzo niskich szerokościach bitowych, ale wymaga potoku treningowego i oryginalnych danych. W przypadku większości wdrożonych systemów, post-treningowa kwantyzacja 4-bitowa z kalibracją jest pragmatycznym wyborem; kwantyzację uwzględniającą trening należy zarezerwować dla przypadków, gdy operacja poniżej 4 bitów jest wymuszona limitami sprzętowymi.

Budżety sprzętowe i ściana przepustowości pamięci

Kwestia sprzętowa dla modeli LLM on-device jest zdominowana przez pamięć, nie obliczenia. Generowanie autoregresywne produkuje jeden token na raz, a wyprodukowanie każdego tokena wymaga odczytania całego zestawu wag modelu z pamięci. Przepustowość w tokenach na sekundę jest zatem ograniczona przez przepustowość pamięci podzieloną przez rozmiar modelu w bajtach znacznie częściej niż przez surową przepustowość arytmetyczną. Urządzenie z obfitą liczbą FLOPS, ale skromną przepustowością pamięci, będzie powolne przy generowaniu bez względu na swój rating obliczeniowy.

Praktyczny minimum dla responsywnego modelu klasy 7B to około 8 GB pamięci dostępnej dla akceleratora inferencji i wystarczająca przepustowość do utrzymania 10–20 tokenów na sekundę. Jetson Orin NX w konfiguracji 8GB lub 16GB mieści się dokładnie w tym zakresie, podobnie jak mały wzmocniony system x86 ze zintegrowanym lub dedykowanym GPU. Inferencja wyłącznie na CPU jest w pełni możliwa dla modeli 1B–3B i produkuje kilka tokenów na sekundę przy modelach 7B – akceptowalne dla wsadowego streszczania bez oczekującego operatora, nieakceptowalne dla zastosowań interaktywnych. Prefill (przetwarzanie promptu) i dekodowanie (generowanie odpowiedzi) mają różne wąskie gardła: prefill jest ograniczony obliczeniowo i równoległy, dekodowanie jest ograniczone przepustowością i sekwencyjne, dlatego muszą być mierzone osobno przy wymiarowaniu sprzętu.

Pamięć podręczna klucz-wartość: ukryty koszt pamięci

Rozmiar wag to koszt pamięci, który wszyscy uwzględniają w budżecie; pamięć podręczna klucz-wartość (KV) to ta, która zaskakuje zespoły. Podczas generowania model buforuje klucze i wartości uwagi dla każdego już przetworzonego tokena, aby ich nie przeliczać ponownie, a ta pamięć podręczna rośnie liniowo wraz z długością kontekstu. Dla modelu 7B przy precyzji 16-bitowej pamięć podręczna KV kosztuje około 0,5 MB na token, więc kontekst o długości 8 000 tokenów dodaje około 4 GB na wagi – często więcej niż same skwantyzowane wagi. Na ograniczonym sprzęcie to pamięć podręczna KV, a nie wagi, ogranicza użyteczną długość kontekstu. Kwantyzacja pamięci podręcznej KV do 8 lub 4 bitów zmniejsza to o połowę lub trzy czwarte i często decyduje o tym, czy budżet kontekstu jest wykonalny, czy kończy się błędem braku pamięci. Wniosek jest taki, aby ustawić długość kontekstu na najmniejszą wartość, jakiej zadanie potrzebuje, a nie największą, jaką model obsługuje.

Środowisko uruchomieniowe, pakowanie i zweryfikowane działanie offline

Środowisko uruchomieniowe on-device to warstwa ładująca skwantyzowane wagi, zarządzająca pamięcią podręczną KV i udostępniająca interfejs generowania aplikacji. Silnik oparty na llama.cpp jest powszechnym wyborem, ponieważ uruchamia skwantyzowany format GGUF bezpośrednio, obsługuje back-endy CPU i akceleratora, i ma mały ślad zależności odpowiedni dla wzmocnionego obrazu systemu. Niezależnie od środowiska uruchomieniowego, model powinien być przypięty w pamięci po pierwszym załadowaniu, aby koszt ładowania trwający kilka sekund był ponoszony raz, a nie przy każdym żądaniu, a aplikacja powinna traktować opóźnienie generowania jako metrykę pierwszej klasy prezentowaną operatorowi.

Pakowanie to obszar, w którym twierdzenia o działaniu on-device są weryfikowane lub obalane. Plik modelu, środowisko uruchomieniowe, tokenizer i szablony promptów muszą być obecne w obrazie urządzenia – nic nie jest pobierane w czasie działania. Jedynym uczciwym testem działania offline jest uruchomienie całego przepływu pracy z wyłączonym radiem, w trybie samolotowym lub w izolowanej sieci i potwierdzenie, że system startuje i odpowiada bez dostępnego punktu końcowego. Wszelkie ukryte wywołania – pobieranie tokenizera, sygnał telemetryczny, sprawdzenie licencji – muszą zostać znalezione i usunięte, ponieważ na brzegu sieci zawiodą po cichu, zabierając ze sobą całą możliwość. Aktualizacje modelu są dostarczane nośnikiem fizycznym lub przez uwierzytelnioną synchronizację lokalną, nigdy przez założoną łączność.

Modele LLM on-device poszerzają też powierzchnię ataku w sposób, w jaki model chmurowy tego nie robi, ponieważ wagi, prompty i wszelkie korpusy do wyszukiwania żyją na urządzeniu, które może zostać przechwycone. Wstrzykiwanie promptów przez pozyskane dokumenty, eksfiltracja danych przez spreparowane wyniki i manipulowanie plikiem modelu – wszystko to jest w zakresie i musi być uwzględnione w projekcie. Temat ten jest szczegółowo omówiony w naszym przewodniku po bezpieczeństwie modeli LLM dla systemów AI w obronności.