Pakowanie Modeli Maszynowego Wyznaczania Klas z użyciem FastAPI i Docker dla Produkcji

Odsłona między treningiem modelu a używalnym systemem

Model wykazujący dobre wyniki w notebooku nadal nie jest gotowym systemem produkcyjnym. W organizacji, np. w aplikacji internetowej, zadaniu typu batch, serwisie innej drużyny — potrzebna jest wiarygodna i dobrze zdefiniowana metoda wysyłania nowych danych oraz otrzymywania przewidywań, bez konieczności znając sposobu treningu modelu, biblioteki użytej do jego stworzenia lub pakietów Pythona, na których się opiera. Zamykanie tej odsłony jest głównie problemem inżynieryjskiego, a nie modelowania: obwodzenie modelu w API z zdefiniowanym formatem żądania i odpowiedzi, paczowanie tego API ze swoimi dokładnymi zależnościami, aby działało tak samo wszędzie, oraz ustanowienie procesu bezpiecznego aktualizowania go przy nowych wersjach treningowych.

Służenie przewidywaniom za pomocą FastAPI

FastAPI jest nowoczesnym szablonem internetowym w języku Python, który stało się powszechnie używanym standardem do serwantowania modeli ML z trzech praktycznych powodów. Po pierwsze, używa modeli Pydantic do definiowania dokładnej struktury oczekiwanego danych wejściowych i wyjściowych, a następnie automatycznie waliduje każdą przychodzącego żądanie na podstawie tej struktury, odrzucając nieprawidłowe dane wejściowe przed dotarciem do modelu — żądanie brakujące wymagane pole lub zawierające string zamiast liczby otrzymuje jasne odpowiedź z błądami, a nie niejasny crash modelu dalej w przepływie. Po drugie, generuje automatycznie dokumentację API interaktywną (często dostarczaną jako Swagger UI, zwykle serwowana pod adresem /docs) na podstawie tych samych modeli Pydantic, co pozwala każdemu integrującemu się z usługą zobaczyć dokładnie jakie pola są wymagane bez czytania kodu źródłowego. Po trzecie, obsługuje obsługę asynchronicznych żądań, co pomaga pojedynczej usłudze obsługiwać wiele równoczesnych żądań bez blokowania, co jest ważne dla usługi, która może być często wywoływana przez inne systemy.

Minimalna API ML załaduje model treningowy raz na starcie, definiuje schemat żądania opisujący cechy wejściowe i schemat odpowiedzi opisujący przewidywanie, a następnie ekspozuje punkt końcowy POST, który przeprowadza te cechy przez model i zwraca strukturalne przewidywanie. Powszechna dodatek do tego jest punkt końcowy batch równoległy, który akceptuje listę żądań i zwraca listę przewidzin, ponieważ wywołanie wielu przewidywań w jednym wektorowym wywołaniu jest znacznie efektywniejsze niż powtarzane wywołania pojedynczych przewidywań jeden po drugim. Standardowa praktyka to oddzielny punkt końcowy check zdrowia lekcyjnego, który prosto potwierdza, że usługa działa, ponieważ infrastruktura wdrożenia zwykle potrzebuje szybkiego sposobu sprawdzania, czy instancja działająca jest zdrowa przed przekierowywaniem do niej ruchu.

Kontenerizacja za pomocą Docker

Docker pakuje API, plik z treningiem modelu i każdą zależność Pythonową w pojedynczy obraz kontenera, który działa identycznie niezależnie od instalacji oprogramowania na maszynie hostowej — rozwiązując tradycyjny problem „działa na mojej maszynie”, gdzie model zachowuje się inaczej w trybie produkcyjnym ze względu na subtelnie inną wersję biblioteki. Standardowy Dockerfile usługi ML zaczyna od niewielkiego obrazu bazowego Pythona, przenosi plik wymagania i instaluje dokładne wskazane wersje zależności, a następnie przenosi kod aplikacji oraz artefakt treningu modelu. W końcu określa polecenie, które uruchamia serwer API (zwykle Uvicorn, serwer na którym działa FastAPI) na zdefiniowanym portie.

Dla usługi ze wsparciem infrastruktury — np. bazę danych do rejestrowania przewidywań — plik docker-compose definiuje wiele kontenerów (serwis API, instancję PostgreSQL) jako pojedynczy zestaw, łącząc ich sieć, zmienne środowiskowe i przechowywanie trwałe w jednym pliku konfiguracyjnym. Dzięki temu cała stosowna infrastruktura może być uruchomiona lub zatrzymana za pomocą jednego polecenia, a nie przez manualne koordynowanie wielu osobnych kontenerów.

Rozpuszczanie aktualizacji bez przerywania działania

Jednocześnie z zapewnieniem ciągłości usługi, problem polega naaktualizowaniu modelu bez przerwy ruchu. Dwa popularne strategie rozwiązywania tego problemu to: wdrożenie blue-green, które uruchamia dwie pełne i niezależne środowiska równolegle — obecnie działającą wersję "blue" oraz nowo wdrożoną wersję "green". Po tym, jak green zostanie zatwierdzone jako poprawna, całe ruch jest przekierowywane do niego, zachowując blue dostępne na krótko jako opcja odwracania się do niej, jeśli coś pójdzie źle. W drugim podejściu, canaryjska wersja, ruch jest powoli przekierowywany, zaczynając od przesyłki około dziesięciu procent ruchu do nowej wersji, monitorując jej zachowanie w porównaniu z starszą wersją i tylko zwiększając ten procent, jeśli nowa wersja będzie nadal wykonywać się dobrze. To ogranicza promień eksplozji złego wdrożenia do małej części ruchu, a nie do każdego użytkownika naraz.

Obie strategie opierają się na możliwości uruchamiania jednocześnie dwóch wersji modelu i porównywania ich zachowania, co zależy od tego, aby model, jego pipeline przetwarzania danych oraz zależności były pakowane razem deterministycznie — dokładnie to, dla czego istnieje konteneryzacja. Wdrożenie nagojonego pliku modelu bez takiego pakowania sprawia, że jest trudniej zapewnić, że "wersja A" i "wersja B" różnią się tylko w zamierzonej manierze.

Automatyzacja płytki i monitorowanie statków

Płytka CI/CD (Continuous Integration / Continuous Deployment) automatyzuje kroki między zmianą kodu a aktualizacją w produkcji: gdy kod jest wysłany, przepływ pracy automatyczny instaluje zależności, uruchamia zestaw testów i — jeśli testy są zaliczone i zmiana dotarła do głównego pnia — tworzy nową obraz kontenera i wdraża ją. To usuwa ręczne, pełne błędów kroki wdrożenia i zapewnia, że każda wdrożona wersja przeszła te same sprawdzania, zamiast polegać na osobie, aby pamiętała o uruchomieniu testów przed wysłaniem.

Po uruchomieniu usługi ML potrzebuje ona monitorowania poza prostą dostępność. Czas odpowiedzi na przewidywania i ilość żądań są śledzone jak dla dowolnej innej usługi internetowej. W szczególności dla ML, monitorowanie przemieszczania się danych porównuje rozkład statystyczny cech przychodzących żądań z rozkładem, na którym model był treningowy; zwiększona różnica wskazuje, że świat zmienił się od czasu treningu i założenia modelu mogą już nie być prawdziwe, nawet jeśli sam usługa technicznie jest zdrowa i zwraca odpowiedzi bez błędu. Zapisanie każdego przewidywania, wraz z cechami wejściowymi, które je wygenerowały, jest to, co pozwala na takie monitorowanie po fakcie, a także to, co dostarcza etykietowane dane potrzebne do przyszłego ponownego treningu.

Często zadawane pytania

Wypróbuj na żywo

Wszystko powyżej działa bezpośrednio w Twojej przeglądarce — otwórz Packaging Machine Learning Models with FastAPI and Docker for Production i zmieniaj parametry podczas działania. Nic nie jest instalowane ani przesyłane na serwer, cały model działa w jednej karcie.