Wdrażaj modele ML na produkcji z automatycznym skalowaniem

Luka wdrożenia produkcyjnego: dlaczego większość modeli ML nigdy nie opuszcza notatnika

Wytrenowany model w notatniku i model odpowiadający na bieżące żądania to różne problemy inżynieryjne. To drugie to środowisko wdrożeniowe z wymaganiami dotyczącymi dostępności, opóźnień i skalowania, i to właśnie tutaj większość modeli uczenia maszynowego na produkcji utyka.

Czego potrzeba, aby serwować model na dużą skalę (klaster, ruch przychodzący, autoskalowanie, monitoring)

Wybór modelu i trening to problemy wstępne. Klasyczną ścieżką serwowania modeli na produkcji jest oddzielny proces, proces wymagający klastra, kontrolera ruchu przychodzącego, polityki skalowania, stosu monitoringu i potoku wydań. Każda z nich to decyzja wymagająca właściciela. Data scientist, który zakończył tworzenie modelu, potrzebuje teraz sieci klastra, reguł równoważenia obciążenia i backendu metryk, zanim pierwszy użytkownik zobaczy predykcję.

Lista kontrolna: środowisko uruchomieniowe kontenerów, reguły ruchu przychodzącego, polityki skalowania, zarządzanie sekretami i danymi, przesyłanie logów, potoki wydań oraz zestaw narzędzi do utrzymania każdego z nich. Każdy element jest niezbędny, wymaga odpowiedzialności technicznej, a żadne z tych narzędzi nie ulepsza modelu.

Dla małego zespołu to tygodnie pracy, zanim pojawi się jakakolwiek wartość biznesowa, a na uruchomieniu się nie kończy. Rezultat jest znany: rozwój modelu kończy się sukcesem, wdrożenie utyka, a artefakt czeka na infrastrukturę, której nikt nie ma czasu zbudować.

Dlaczego samodzielnie skonfigurowana maszyna wirtualna + Flask + nginx ulega awarii przy rzeczywistym ruchu

Skrótem jest maszyna wirtualna z aplikacją Flask za nginxem. Działa w testach, a zawodzi na produkcji. Jeden serwer to jeden punkt awarii. Brak autoskalowania oznacza, że skok obciążenia powoduje kolejkowanie żądań, aż opóźnienie stanie się nieakceptowalne. Brak modelu rolling release oznacza, że każda nowa wersja wiąże się z przestojem.

Ukrywa to również problem kosztów: instancja działa nieprzerwanie, niezależnie od tego, czy punkt końcowy obsługuje tysiąc żądań dziennie, czy żadnego, a ktoś nadal musi aktualizować system operacyjny i odnawiać certyfikaty. Wydajne w konfiguracji, kosztowne w utrzymaniu.

Ukryty koszt bezczynnych instancji GPU w punktach końcowych u dostawców chmurowych

Zarządzane punkty końcowe wnioskowania u dużych dostawców chmurowych rozwiązują kwestię dostępności, ale utrzymują instancję obliczeniową działającą przez całą dobę. Punkt końcowy GPU dostosowany do szczytu w ciągu dnia jest nadal rozliczany o 3 nad ranem, gdy nie ma nic do obsłużenia, a czas bezczynności stanowi większość dnia.

Wykorzystanie to metryka, która ma znaczenie. Punkt końcowy obsługujący kilka tysięcy żądań dziennie na GPU dostosowanym do szczytu może wykorzystywać niewielki ułamek tego, za co płaci, każdego dnia, przez miesiące. Instancje GPU w chmurze mają sens, gdy obciążenie jest stałe, ale instancja rozliczana godzinowo jest niewłaściwą jednostką dla popytu, który pojawia się w skokach.

Rozliczanie za replikę i za minutę zamiast instancji działających w trybie ciągłym

Rozliczenie odbywa się za replikę, za minutę. Wdrożenie utrzymujące jedną replikę w nocy i osiem w południe kosztuje tyle, ile suma minut pracy każdej repliki, a nie tyle, co osiem instancji przez 24 godziny. Rozliczenie autoskalowania jest obliczane na podstawie zdefiniowanej minimalnej liczby replik, a pojemność zwiększa się tylko wtedy, gdy jest używana. Prognozowanie jest proste: podstawę stanowi minimum pomnożone przez czas, wszystko powyżej podąża za popytem, a rachunek za oprogramowanie odzwierciedla kształt krzywej obciążenia.

Stawki orientacyjne: Procesor tylko od 0,04 € za rdzeń na godzinę w przypadku klasycznych modeli, takich jak scikit-learn lub XGBoost; GPU L4 od 0,91 € za replikę na godzinę w przypadku wnioskowania 7B, wizji i klasyfikacji; GPU A100 około 1,52 € do 1,85 € dla modeli od 7B do 30B; GPU H100 PCIe od 3,10 € dla większych modeli i długich okien kontekstowych. Potwierdź aktualne stawki na stronie z cennikiem.

Skalowanie do zera przy spadku ruchu, skalowanie w górę przy rzeczywistych skokach obciążenia

Skalowanie do zera jest ogólnie dostępne: wdrożenie automatycznie zmniejsza liczbę replik do zera, gdy nikt z niego nie korzysta, a koszt w stanie bezczynności wynosi zero. To kluczowa różnica ekonomiczna między skalowalnym zarządzanym punktem końcowym a stałą instancją, którą zarządzasz samodzielnie. Wiąże się to z uczciwym kompromisem. Powrót z zera oznacza zimny start podczas uruchamiania kontenera i ładowania wag, więc pierwsze żądanie po okresie bezczynności jest powolne. W przypadku zadania wsadowego lub narzędzia wewnętrznego jest to akceptowalne. W przypadku aplikacji skierowanej do użytkownika z określonym budżetem opóźnień należy zachować minimum jedną replikę i zaakceptować koszt minimalny.

Skalowanie statyczne a autoskalowanie (CPU/RAM) a autoskalowanie oparte na niestandardowych metrykach

Trzy strategie skalowania, a wybór zależy od charakterystyki ruchu.

Sondy gotowości i aktualizacje typu rolling upgrade bez przestojów

Sonda gotowości to ścieżka HTTP, którą platforma odpytuje przed wysłaniem ruchu do repliki. W ten sposób zapewniasz, że model jest gotowy: skieruj ją na swoją ścieżkę /health, a punkt końcowy nie przekieruje żadnego żądania, dopóki model nie zostanie załadowany. Bez niej replika przyjmuje żądanie w trakcie ładowania wag i zwraca błąd, który Twój klient widzi jako nieudane żądanie.

Aktualizacje kroczące wykorzystują tę samą kontrolę. Wypchnij nową wersję i zastosuj aktualizację, a nowe repliki przejdą test gotowości, zanim stare zostaną wycofane. Użytkownicy nie widzą żadnych nieudanych żądań, a wersja, której sonda nie powiodła się, nigdy nie otrzymuje ruchu. Każda wersja jest adresowalna, więc codzienne wydania i awaryjne wycofywanie zmian korzystają z tego samego mechanizmu.

Monitorowanie na żywo GPU, CPU i sieci dla każdej repliki

Panel sterowania udostępnia zestaw metryk na żywo dla każdej repliki: metrykę GPU, metrykę pamięci i metrykę sieci, każdą przypisaną do jednej repliki, a nie uśrednioną, wraz z logami aplikacji w Panelu sterowania.

Ten zestaw odpowiada na pytania, czy wdrożenie jest sprawne, czy metryka skalowania jest wyzwalana i jaki jest poziom opóźnień. Nie odpowiada on na pytanie, czy przewidywania są nadal poprawne. Do tego potrzebujesz zdefiniowanej przez siebie metryki aplikacji, przy czym dokładność na próbce z etykietami jest zazwyczaj wybieraną opcją. Zespoły utrzymujące modele w środowisku produkcyjnym zazwyczaj współdzielą jeden pulpit nawigacyjny między działem nauki o danych a inżynierią platformy, dzięki czemu obie strony widzą te same liczby. Ta funkcja monitorowania jest standardem w każdej aplikacji.

Krok 1: Zapakuj model w obraz Docker (lub użyj gotowego)

Konteneryzacja jest warunkiem wstępnym, a nie opcjonalnym dodatkiem. Obraz kontenera może pochodzić z Docker Hub, z Managed Private Registry lub z GitHub Packages. Liczą się trzy wymagania: utwórz katalog roboczy w pliku Dockerfile, ustaw cel na linux/amd64 i obsługuj port 8080, chyba że jawnie zadeklarujesz inny, tak jak robi to vLLM na 8000.

Zespoły bez doświadczenia w konteneryzacji mogą zacząć od katalogu gotowych obrazów OVHcloud z zainstalowanymi już PyTorch, TensorFlow, HuggingFace lub FastAI. To zmniejsza nakład pracy, ale nie eliminuje wymogu. Wdrażanie uczenia maszynowego w ten sposób jest wydajnym ustawieniem domyślnym dla większości aplikacji, a wdrażanie modeli ML bezpośrednio z obrazu katalogowego jest jeszcze szybsze, a utrzymywanie własnej warstwy bazowej rzadko jest opłacalne na wczesnym etapie.

Krok 2: Skonfiguruj zasoby, skalowanie i dostęp za pomocą Panelu sterowania, interfejsu API lub interfejsu wiersza poleceń ovhai

Utwórz wdrożenie z poziomu Panelu sterowania, API lub interfejsu wiersza poleceń ovhai. Wybierz zasoby obliczeniowe, ustaw strategię skalowania, skieruj sondę gotowości na ścieżkę i port sprawdzania stanu, a następnie określ sposób uzyskiwania dostępu do punktu końcowego.

W kwestii dostępu obowiązuje jedna zasada: publiczny punkt końcowy służy wyłącznie do testów. Wdrożenia produkcyjne wykorzystują ograniczony dostęp, z poświadczeniami użytkownika AI Platform lub tokenem oraz zasadami dostępu, które utrzymujesz samodzielnie. Każdy punkt końcowy znajduje się również za natywną ochroną przed atakami DDoS, a każdy punkt końcowy przechowuje własne poświadczenia.

ovhai app run --gpu 1 --default-http-port 8080 \
  --probe-path /health \
  --unsecure-http false \
  my-registry/my-model-server:v2

Krok 3: Wybierz odpowiednią strategię skalowania dla swojego wzorca ruchu

Dopasuj zasady do obciążenia. Stałe ocenianie wewnętrzne: statyczne, jedna lub dwie repliki, wydajne ustawienie domyślne dla aplikacji wewnętrznych i narzędzi o niskim natężeniu ruchu. Interfejs API skierowany do klienta z codziennymi szczytami: automatyczne skalowanie w oparciu o metrykę wykorzystania, minimum jedna replika, aby uniknąć zimnych startów. Okazjonalne ocenianie wsadowe: automatyczne skalowanie ze skalowaniem do zera. Praca wsadowa to obszar, w którym ta decyzja jest najłatwiejsza, ponieważ nikt nie obserwuje paska postępu. Każde uruchomienie wsadowe to koszt, który już wyceniłeś.

Ustaw maksimum w sposób przemyślany. Ogranicza to jednocześnie przepustowość i rachunek, a górny limit wynosi 10 replik na aplikację.

Krok 4: Monitoruj wnioskowanie za pomocą pulpitu nawigacyjnego i architektury referencyjnej MKS

Zacznij od wbudowanego pulpitu nawigacyjnego dla metryk zasobów i logów. W przypadku percentyli opóźnień, przepustowości lub dokładności na poziomie modelu, dodaj zewnętrzny stos: Zarządzana usługa Kubernetes uruchamiająca Prometheus i Grafana, pobierająca dane z Twojego punktu końcowego. OVHcloud publikuje to jako architekturę referencyjną.

Dwie rzeczy do ciągłego monitorowania: sygnały infrastruktury, które informują, czy skalowanie działa, oraz wydajność modelu w środowisku produkcyjnym, która informuje, czy model nadal wykonuje swoją pracę. Monitorowanie wydajności w drugim przypadku pozwala wykryć cichą regresję, a metryki wydajności z zestawu danych treningowych Cię przed tym nie ostrzegą. Dryft pojawia się w drugim przypadku na długo przed pierwszym. Wyeksportuj tydzień metryk online do pliku przed optymalizacją progu, upewniając się, że zmiana jest zgodna z zaobserwowanym obciążeniem. Ustaw alert dla każdego z nich, aby upewnić się, że regresja zostanie wykryta dzięki Twoim własnym spostrzeżeniom, a nie przez klienta, upewnij się, że próg opiera się na rzeczywistej linii bazowej i upewnij się, że ma właściciela.

Krok 5: Wypchnij nową wersję za pomocą aktualizacji kroczącej bez przestojów

Zbuduj i wypchnij nową wersję, a następnie uruchom ovhai app update lub zastosuj zmianę z poziomu Panelu sterowania. Platforma uruchamia nowe repliki, czeka na gotowość, przekierowuje ruch i wycofuje stare. Brak przestojów, brak okna serwisowego.

Dockerfile to kod: przechowuj go w systemie kontroli wersji i aktualizuj bazę, ponieważ nieaktualna warstwa bazowa jest częstą przyczyną nieudanego wdrożenia. Używaj wersjonowanych tagów zamiast wielokrotnego używania latest. Kontrola wersji dla każdej wersji sprawia, że wycofanie zmian jest operacją wykonywaną jednym poleceniem, a nie dochodzeniem.

Dlaczego CPU/RAM to słaby wskaźnik obciążenia LLM

Wnioskowanie w uczeniu głębinowym to obciążenie obliczeniowe z kolejką, a nie pętla ograniczona przez procesor, więc standardowa praktyka skalowania w oparciu o sprzęt zawodzi. Serwer LLM grupuje współbieżne żądania na GPU. Wykorzystanie procesora pozostaje niskie, podczas gdy kolejka rośnie, więc ten próg uruchamia się późno lub wcale. Sygnał, który Cię interesuje, to liczba żądań w toku, a metryka sprzętowa nie jest w stanie tego wykryć.

Skalowanie w oparciu o vllm:num_requests_running z użyciem Prometheusa i Grafany w MKS

vLLM udostępnia vllm:num_requests_running w swoim punkcie końcowym metryk. Pobieraj je za pomocą Prometheusa i skaluj automatycznie w oparciu o tę wartość zamiast używać proxy sprzętowego. Repliki pojawiają się, gdy rośnie rzeczywista współbieżność, i znikają, gdy kolejka się opróżnia, utrzymując opóźnienia w założonym budżecie bez nadmiernego udostępniania zasobów.

Ogólnie dostępne i udokumentowane jako architektura referencyjna. Wymaga to Prometheusa i Grafany obok wdrożenia, więc traktuj to jako podejście zaawansowane, a nie domyślne.

Czas konfiguracji, koszty przestoju i wiedza operacyjna

Samodzielne zarządzanie inferencją oznacza konieczność przygotowania klastra, pul węzłów, kontrolera ruchu przychodzącego (ingress) oraz horyzontalnego autoskalera, co zazwyczaj zajmuje od jednego do dwóch tygodni, a także wymaga wiedzy z zakresu DevOps i MLOps do utrzymania systemu w działaniu. Samodzielnie odpowiadasz za polityki skalowania, potoki wdrożeniowe, pliki manifestów i strategie monitorowania, i odpowiadasz za nie również po uruchomieniu. Najlepsze praktyki w tej dziedzinie są udokumentowane, a narzędzia dojrzałe, jednak w tej branży udokumentowana praktyka nie oznacza solidnie działającego systemu. Węzeł GPU zazwyczaj działa w sposób ciągły, nawet przy zerowym ruchu.

AI Deploy wymaga jednego obrazu i jednego polecenia. Konfiguracja zajmuje mniej niż godzinę, wystarczy sama wiedza z zakresu MLOps, a skalowanie do zera całkowicie eliminuje koszty przestoju.

Ceny i liczby mają charakter orientacyjny. Przed publikacją sprawdź aktualne stawki na stronie cennika OVHcloud.

Brak narażenia na ustawę CLOUD Act w przypadku danych wnioskowania

Dane treningowe to nie jedyny wrażliwy wkład. Każde żądanie do punktu końcowego produkcji zawiera dane użytkownika lub firmy, każde żądanie jest gdzieś rejestrowane, każde żądanie jest wkładem, którego nie wybrałeś, a ruch w punkcie końcowym jest ciągły, a nie jednorazowy. Jeśli punkt końcowy działa u dostawcy z siedzibą w USA, dane te podlegają jurysdykcji USA, niezależnie od regionu, w którym są hostowane.

OVHcloud jest firmą europejską, bez amerykańskiej spółki matki i bez strukturalnego narażenia na ustawę CLOUD Act. Dane wnioskowania pozostają w jurysdykcji UE zgodnie z prawem UE.

RODO, HDS i ISO 27701 dla regulowanych obciążeń roboczych

OVHcloud posiada certyfikaty ISO 27001, ISO 27017, ISO 27018 i ISO 27701, posiada certyfikat SOC 2 oraz certyfikat HDS dla danych medycznych we Francji, co jest istotne w przypadku wnioskowania medycznego. Przetwarzanie wewnątrz UE upraszcza ocenę skutków dla ochrony danych (DPIA), a zobowiązania dotyczące prywatności danych, które złożyłeś swoim użytkownikom, stają się łatwiejsze do udowodnienia. Wsparcie techniczne może odpowiedzieć na pytanie dotyczące prywatności bez eskalacji.

Jedna granica, którą należy jasno określić: AI Deploy dostarcza suwerenną infrastrukturę serwującą. Obowiązki wynikające z unijnego aktu o sztucznej inteligencji (EU AI Act) na poziomie modelu, karty modelu, logi audytowe oraz wykrywanie stronniczości pozostają Twoją odpowiedzialnością jako twórcy systemu. Suwerenna infrastruktura wspiera zgodność z przepisami; nie zapewnia jej jednak automatycznie.