Kolejne ważne wdrożenie AI może nie działać w ogromnym klastrze chmurowym. Może działać w kamerze, robocie fabrycznym, pojeździe, urządzeniu medycznym lub terminalu sprzedażowym, gdzie przepustowość łącza, zużycie energii, opóźnienia, prywatność i koszty operacyjne mają większe znaczenie niż posiadanie możliwie największego modelu.

Ta zmiana tworzy inny rodzaj pracy związanej z AI. Zespoły nadal potrzebują twórców modeli, ale potrzebują też osób, które potrafią dopasować modele do rzeczywistego sprzętu, mierzyć jakość przy ograniczeniach, integrować natywne środowiska uruchomieniowe wnioskowania oraz decydować, kiedy mniejszy model jest wystarczająco dobry do danego zadania.

To mniej efektowna połowa wyścigu modeli: nie tylko zwiększanie inteligencji, lecz także sprawianie, by inteligencję dało się wdrożyć.

Dlaczego mniejsze modele zmieniają podejście do wdrażania

Model chmurowy może często przeznaczyć więcej mocy obliczeniowej na udzielenie odpowiedzi. System wbudowany nie może zakładać niezawodnego połączenia sieciowego, nieograniczonej baterii ani wysokiego budżetu na pojedyncze wywołanie. Robot, który czeka kilkaset milisekund na każdą decyzję dotyczącą percepcji lub sterowania, może być niebezpieczny albo nieskuteczny. Produkt, który wysyła każdy obraz lub próbkę dźwięku do API, może generować nieakceptowalne koszty związane z prywatnością i przesyłaniem danych.

Te ograniczenia zmieniają cel inżynierski. Pytanie brzmi: jaki jest najmniejszy model, który na rzeczywistym urządzeniu spełnia wymagane założenia dotyczące dokładności, opóźnienia, pamięci, energii i niezawodności?

To pytanie dotyczy znacznie więcej niż tylko urządzeń konsumenckich. Ma znaczenie dla producentów kontrolujących części na linii produkcyjnej, firm logistycznych śledzących sprzęt, szpitali przetwarzających poufne sygnały oraz dostawców oprogramowania próbujących oferować funkcje AI bez zamieniania rachunków za wnioskowanie w ich największy koszt zmienny.

Trzy techniki stojące za tą zmianą

Kwantyzacja reprezentuje wagi modelu, a czasami także aktywacje, za pomocą liczb o mniejszej precyzji. Przejście z formatów takich jak BF16 lub FP16 do reprezentacji 8-bitowych lub 4-bitowych może zmniejszyć wymagania dotyczące pamięci i poprawić przepustowość, zależnie od sprzętu i implementacji. Kompromis polega na tym, że mniejsza precyzja może obniżyć jakość lub powodować problemy numeryczne, dlatego trzeba ją testować, a nie zakładać, że jest nieszkodliwa.

Destylacja trenuje mniejszy model-ucznia tak, aby odtwarzał użyteczne zachowanie większego modelu-nauczyciela. Uczeń może uczyć się na podstawie wyników nauczyciela, sygnałów pośrednich lub przykładów specyficznych dla danego zadania. Nie musi odtwarzać wszystkich możliwości większego modelu; musi wystarczająco dobrze wykonywać docelowe zadanie.

Zoptymalizowane wnioskowanie dostosowuje wykonywanie do konkretnego środowiska uruchomieniowego i procesora. Może obejmować wybór jąder obliczeniowych, kompilację grafu, tworzenie batchy, planowanie pamięci, buforowanie oraz akcelerację właściwą dla danego sprzętu. TensorRT Model Connect firmy NVIDIA, ogłoszony w ramach publicznej wersji testowej, jest przykładem narzędzia, którego celem jest przekształcanie obsługiwanych modeli Hugging Face lub lokalnych checkpointów w kompleksowe wnioskowanie TensorRT bez pośredniego eksportu do ONNX. Wskazany obszar zastosowań obejmuje robotykę, urządzenia i obciążenia platformowe.

Techniki te wzajemnie się wzmacniają. Destylacja może stworzyć kompaktowy model; kwantyzacja może jeszcze bardziej zmniejszyć jego rozmiar; zoptymalizowane środowisko uruchomieniowe może zdecydować, czy powstały model rzeczywiście działa szybko na docelowym układzie.

Użyteczny rezultat to nie to samo co mniejszy plik

Kompresję modeli należy traktować jako zadanie produktowe i systemowe, a nie sztuczkę służącą poprawianiu pozycji w rankingu. Model, który jest o 40 procent mniejszy, ale przy słabym oświetleniu pomija kluczowe obiekty, może być gorszy dla robota magazynowego. Model językowy, który jest tani w przeliczeniu na token, ale generuje niepoprawnie sformatowane dane strukturalne, może zwiększyć nakład pracy na ich naprawę w kolejnych etapach. Model działający dobrze w benchmarku może zawieść, gdy pojawią się ograniczanie częstotliwości z powodu temperatury, szum kamery, przerywana łączność lub nietypowe dane wejściowe użytkownika.

Raport Liquid AI dotyczący destylacji uwzględniającej kwantyzację dla jej małych modeli LFM2.5 jest użyteczną ilustracją tego celu. Firma poinformowała o zachowaniu od 96,5% do 97,4% wydajności BF16 przy utrzymaniu zużycia pamięci i przepustowości Q4_0. Są to dane podane przez firmę i specyficzne dla modeli; nie należy uogólniać ich na każdą architekturę. Pokazują jednak, jakiego rodzaju porównań powinni szukać praktycy: utrzymanie jakości mierzone jednocześnie z pamięcią i szybkością, a nie sam współczynnik kompresji.

W przypadku wdrożenia test akceptacyjny powinien obejmować co najmniej:

  • jakość wykonywania zadania na reprezentatywnych, trudnych przykładach;
  • szczytowe wymagania dotyczące pamięci i miejsca na dane;
  • opóźnienie pierwszej odpowiedzi i opóźnienie w stanie ustalonym;
  • przepustowość przy realistycznej współbieżności;
  • zużycie energii lub zachowanie termiczne, gdy ma to znaczenie;
  • zachowanie w przypadku błędów, gdy dane wejściowe są niekompletne, zaszumione lub odbiegają od rozkładu danych treningowych;
  • koszt i obciążenie operacyjne związane z aktualizowaniem modelu.

Dokładne metryki różnią się zależnie od produktu. Kamera może zwracać uwagę na liczbę klatek na sekundę i odsetek przeoczeń. Interfejs głosowy może koncentrować się na czasie odpowiedzi od końca do końca. Robot może uwzględniać terminy pętli sterowania i bezpieczne zachowanie awaryjne. Chodzi o powiązanie oceny modelu z fizycznymi lub finansowymi konsekwencjami awarii.

Gdzie pojawia się nowa praca

Rosnące możliwości nie ograniczają się do osób, które projektują architektury. Obejmują także kilka praktycznych ról:

  • Inżynierowie wnioskowania profilują modele na docelowych akceleratorach, dobierają środowiska uruchomieniowe, optymalizują grafy oraz diagnozują wąskie gardła związane z opóźnieniami lub pamięcią.
  • Inżynierowie kompresji modeli projektują potoki kwantyzacji i destylacji, wybierają dane kalibracyjne oraz mierzą utratę jakości w zależności od zadania i segmentu.
  • Inżynierowie brzegowego ML przygotowują modele dla środowisk mobilnych, wbudowanych, przemysłowych lub motoryzacyjnych oraz zarządzają aktualizacjami przy ograniczonej łączności.
  • Inżynierowie oprogramowania robotycznego łączą modele percepcji z czujnikami, systemami planowania i ograniczeniami bezpieczeństwa tam, gdzie kluczowe znaczenie ma czas.
  • Inżynierowie produktu uwzględniający sprzęt decydują, czy dane zadanie powinno być wykonywane na urządzeniu, na brzegu sieci czy w chmurze — oraz projektują płynne przekazywanie zadań między tymi miejscami.
  • Specjaliści ds. wdrażania i walidacji budują zestawy testów uwzględniające warunki termiczne, energetyczne, sieciowe oraz rzeczywiste warunki środowiskowe.

Praca czeka także na twórców aplikacji. Zespół produktowy może nie trenować modelu, ale nadal musi wybrać format modelu, zintegrować bibliotekę wnioskowania, obsłużyć nieobsługiwane operatory, udostępnić informacje o pewności lub zachowaniu polegającym na wstrzymaniu odpowiedzi oraz umożliwić odwracalne aktualizacje.

Podział między chmurą a brzegiem sieci staje się umiejętnością projektową

Małe modele nie eliminują modeli chmurowych. Sprawiają, że systemy hybrydowe stają się atrakcyjniejsze. Urządzenie może używać kompaktowego modelu do natychmiastowego wykrywania, a następnie wysyłać wybrane zdarzenia do większego modelu w celu uzyskania wyjaśnienia lub przeprowadzenia głębszej analizy. Robot może lokalnie realizować percepcję krytyczną dla bezpieczeństwa, a chmury używać do uczenia na poziomie całej floty. Produkt do obsługi klienta może kierować rutynową klasyfikację do małego modelu, a niejednoznaczne przypadki przekazywać do bardziej zaawansowanego.

Taka architektura może ograniczyć zużycie pasma i opóźnienia, ale wprowadza decyzje, za które trzeba wyraźnie przypisać odpowiedzialność. Jakie informacje są wysyłane poza urządzenie? Co dzieje się bez łączności? Która wersja modelu wygenerowała dane działanie? Czy urządzenie może bezpiecznie powrócić do poprzedniej wersji? Jak monitorować wydajność, gdy każda konfiguracja sprzętowa zachowuje się inaczej?

Są to pytania dotyczące wdrażania, a nie wyłącznie modeli. Sprzyjają profesjonalistom, którzy rozumieją zależności między uczeniem maszynowym, systemami wbudowanymi, sieciami, wymaganiami produktu i operacjami.

Praktyczna ścieżka nauki

Jeśli chcesz zająć się taką pracą, zbuduj jedno małe, ale mierzalne wdrożenie, zamiast gromadzić wyłącznie certyfikaty związane z modelami. Zacznij od zadania z jasno określonym celem, takiego jak klasyfikacja obrazów, rozpoznawanie słów kluczowych, kategoryzacja dokumentów lub kompaktowy lokalny asystent.

  1. Ustal punkt odniesienia. Zarejestruj jakość, rozmiar modelu, użycie pamięci, opóźnienie i przepustowość, korzystając z powtarzalnego zbioru testowego.
  2. Przeprowadź kwantyzację. Porównaj co najmniej jedną wersję o niższej precyzji z punktem odniesienia. Udokumentuj, które przykłady ulegają zmianie i czy błędy koncentrują się w ważnej kategorii.
  3. Wypróbuj destylację lub dostrajanie pod konkretne zadanie. Zmierz, czy mniejszy model może zachować działanie, którego produkt rzeczywiście potrzebuje.
  4. Uruchom go na docelowym sprzęcie. Test na komputerze stacjonarnym nie jest dowodem dotyczącym telefonu, mikr komputera, GPU, akceleratora ani komputera robota.
  5. Przygotuj wdrożenie. Uwzględnij wstępne przetwarzanie, przetwarzanie końcowe, metadane wersji, kontrole stanu oraz ścieżkę awaryjną.
  6. Napisz raport dotyczący kompromisów. Wyjaśnij, dlaczego wybrany model sprawdza się najlepiej pod względem jakości, opóźnienia, pamięci, energii, prywatności i kosztu — a nie tylko dlaczego ma najwyższy wynik.

Przydatne narzędzia zależą od docelowego stosu technologicznego, ale umiejętności możliwe do przeniesienia pozostają takie same: profilowanie, rozumowanie numeryczne, dobór danych, projektowanie testów, debugowanie oraz jasne komunikowanie kompromisów. Naucz się czytać graf modelu, sprawdzać obsługę operatorów, rozpoznawać przenoszenie danych w pamięci jako wąskie gardło oraz odróżniać teoretyczną moc obliczeniową od zmierzonego opóźnienia kompleksowego.

Sygnał dla kariery

Ważna zmiana w karierze polega na przejściu od pytania „Który model jest najinteligentniejszy?” do pytania „Który system zapewnia wymagany rezultat w rzeczywistych ograniczeniach?”. Duże modele pozostaną wartościowe, zwłaszcza w przypadku otwartego rozumowania i złożonego generowania. Jednak wiele zadań komercyjnych i związanych ze światem fizycznym jest na tyle wąskich, że kompaktowy, szybki i prywatny model może być lepszym produktem.

Tworzy to przestrzeń dla praktyków, którzy potrafią łączyć badania z wdrażaniem. Zwycięzcami nie zawsze będą zespoły z największym modelem. Mogą nimi być zespoły, które rozumieją zadanie, inteligentnie kompresują, uczciwie przeprowadzają testy porównawcze i dostarczają niezawodny system na dostępnym sprzęcie.

Dla kariery w AI jest to trwała lekcja: inteligencja stanowi tylko część tego, co trzeba dostarczyć. Drugą częścią jest dopasowanie jej do wymagań.