TensorFlow i Keras: Od statycznych grafów do profesjonalnej uczenia maszynowego

Era grafu statycznego i sesji, oraz powód jej istnienia

TensorFlow 1.x, wydany w 2015 roku, wymuszał na użytkownikach budowanie statycznego grafu obliczeń — każda warstwa, strata i krok optymalizacji opisane symbolicznie — a następnie otwieranie tf.Session do rzeczywistej przeprowadzania danych przez ten graf i uzyskiwania wyników. Ta dwufazowa architektura (budowanie grafu, a potem jego uruchamianie) nie była przypadkiem; istniała dlatego, że Google potrzebował trenować i dostarczać modele na dużych rozproszonych klastrach CPU, GPU oraz własnych chipów TPU. Całkowicie zdefiniowany graf jest dokładnie artefaktem, który potrzebuje rozproszonego planera: może być podzielony między urządzenia, operacje mogą być łączone w celu przyspieszenia, pamięć może być zaplanowana na czas przed reaktymalnym alokowaniem i całość może być zapisywana do pliku protocol-buffera i wysyłana do środowiska dostarczającego, które nie ma interpreta Pythona. Kosztem tego było naprawdę bolesne doświadczenie debugowania, ponieważ debugowano błąd konstrukcji grafu zamiast przeprowadzanego obliczenia.

Keras zaczęła jako oddzielna, wyższy poziom biblioteka, która siedziała na topie TensorFlow (i przez pewien okres także Theano i CNTK), oferując interfejs API dla stosowania warstw — model.add(Dense(64)) zamiast ręcznego łączenia tensorów — ukrywający większość mechanicznych szczegółów grafu statycznego i sesji od użytkownika. Popularność Kerasa była sygnałem: ergonomia podstawowej ramki miała nieocenioną wagę dla przyjęcia, a do TensorFlow 2.0 w 2019 roku Google zasiliła Keras jako oficjalny wyższy poziom API ramki, zamiast kontynuować konkurencję z nim.

Eager execution i kompromis tf.function

Największą zmianą architektoniczną w TensorFlow 2.0 było ustawienie eager execution jako domyślnej opcji: operacje teraz wykonuje się natychmiast, tensor po tensorze, dokładnie tak jak w NumPy lub PyTorch, z rzeczywistymi wartościami, które można drukować i inspekcjonować na każdym kroku. To zamknęło dziurę w debugowaniu, która była jednym z powodów, dla których wielu badaczy przeniosło się do PyTorch w międzyczasie. Ale Google nie chciała przestawić korzyści związanej z wydajnością i wdrożeniem grafu statycznego, dlatego TensorFlow 2.x oferuje dekorator tf.function jako świadomą bridge: otoczenie funkcję Pythonową @tf.function, a pierwszym razem, gdy jest wywoływana, TensorFlow śledzi operacje, które wykonuje i kompiluje je w tajny graf statyczny (używając techniki zwanej AutoGraph do konwersji sterowania programowym w Pythonie, takich jak if i while, na operacje natywne dla grafu), który następnie działa z tymi samymi korzyściami dotyczącymi dystrybucji i optymalizacji, które starożytny model grafu i sesji miał. Wartościowe wywołania dalsze z taką samą podpisem wejściowym ponownie używają kompilowanego grafu zamiast ponownego śledzenia, co daje większość szybkości grafu statycznego z doświadczeniem rozwojowym eager mode dla części przepływu pracy, gdzie najbardziej liczy debugowanie.

Co potrzebuje model produkcyjny, co notebook

Model, który uzyskuje dobry wynik na zatrzymywanej zestawce w notebooku Jupyter, jest artefaktem badań, a nie systemem produkcyjnym. Przestrzeń między tymi dwoma jest miejscem, gdzie większość streszczonego wysiłku inżynierskiego zespołu ML spadza. Pierwszym wymaganiem jest stabilny, wersjonowany format serjalizacji: format SavedModel TensorFlow połącza graf obliczeń, wagę nauczoną i metadane dotyczące podpisów wejściowych i wyjściowych w pojedynczą folder, który można załadować przez całkowicie inną proces – kontener serwowania napisany w C++ dla minimalnej opóźnienia, aplikację mobilną poprzez TensorFlow Lite, a przeglądarkę poprzez TensorFlow.js - bez potrzeby oryginalnego kodu nauczania Pythonowego. Ta dekouplacja między tym, jak model jest trenowany, a tym, jak jest serwowany, to jedno najważniejsze wymaganie produkcyjne, którego proces pracy notebooka nie dostarcza naturalnie.

Drugi wymagania są warstwą serwantową, która może obsługiwać rzeczywiste cechy ruchu sieci, których trenowanie nigdy nie musi było z nim lizać: grupowanie żądań przychodzących w różnych czasach do efektywnych partii GPU bez tego, aby każdy indywidualny żądanie czekało za długo, uruchamianie wielu wersji modelu obok siebie tak, aby nowy model mógł być przetestowany A/B lub powolnie wprowadzony przeciwko bieżącemu, a także ekspozycja metryk (percentyle opóźnienia żądań, stopy błędów, odchyleń rozkładu prognozy), które inżynier na stażu może rzeczywiście nadzorować. TensorFlow Serving jest zbudowany exactly dla tego i świadomie nie dostarcza żadnych konvenijensów treningowych (brak systemu zwrotnego wywołań Pythonowych, brak łatwego rysowania), ponieważ serwant produkcyjny optymalizuje się dla zupełnie innej zestawu ograniczeń: przewidywalne niskie opóźnienia, wysoka przepustowość i operacyjna obserwowalność, a nie szybkość iteracji.

Kwantyzacja, wycinań i model sformatowany przez sprzęt

Produkcja wymaga często zredukowania modelu, nie tylko jego paczki. Przykładowo, narzędzia TensorFlow do tego ilustrują ogólny fakt dotyczący produkcji uczenia maszynowego: model treningowy najlepiej działający rzadko jest tym, który chcesz uruchomić podczas inferencji na ograniczonej sprzętowo maszynie. Po-treningowa kwantyzacja konwertuje 32-bitowe wartości zmiennoprzecinkowe modelu do 8-bitowych liczb całkowitych, co zmniejsza rozmiar pliku modelu o około 4 razy i może znacząco przyspieszyć inferencję na sprzęcie obsługującym efektywne arytmetykę całkowitych, z utratą małej, zwykle akceptowalnej dokładności spowodowanej przez gęstszy opis liczbowy straconego precyzji w wartościach wag. Wycinań idzie dalej, identyfikując i zerując połączenia, których wagi są bliskie zera, że usunięcie ich barely zmienia wyjście modelu, a następnie używając reprezentacji macierzy rzadkich do pomijania całkowicie wynikowej obliczania.

Oba te techniki istnieją dlatego, że cel wdrożenia często nie jest GPU centrum danych z bogatą pamięcią i energią, ale telefon, komputer wbudowany w samochód lub czujnik wbudowany o budżecie energii i pamięci mierzonej miliwattami i megabajtami. Model treningowy bez żadnego uwzględnienia tego celu prostym jest nie pasować do niego. Jest to prawdziwie inny problem optymalizacji niż ten rozwiązany podczas treningu — podczas treningu szukasz wag, które minimalizują funkcję straty; podczas optymalizacji wdrożeniowej szukasz wersji tych wag lub struktury architektury sama, która zachowuje większość dokładności podczas dopasowania budżetu sprzętowego, który nie ma nic wspólnego z funkcją straty wcale.

Często zadawane pytania

Wypróbuj na żywo

Wszystko powyżej działa bezpośrednio w Twojej przeglądarce — otwórz TensorFlow and Keras: From Static Graphs to Production-Grade Deep Learning i zmieniaj parametry podczas działania. Nic nie jest instalowane ani przesyłane na serwer, cały model działa w jednej karcie.