Usługa Application Gateway dla kontenerów — brama wnioskowania

Obciążenia wnioskowania sztucznej inteligencji nie zachowują się jak tradycyjne bezstanowe aplikacje HTTP. Żądania są często specyficzne dla modelu, długotrwałe, kosztowne do obsługi i wrażliwe na sygnały środowiska uruchomieniowego, takie jak dostępność akceleratora, głębokość kolejki, priorytet żądania, budżet tokenu i pojemność serwera modelu.

Brama wnioskowania dla usługi Application Gateway for Containers obsługuje te obciążenia dzięki integracji z rozszerzeniem platformy Kubernetes Gateway API Inference Extension, które dodaje zasoby uwzględniające wnioskowanie do modelu interfejsu Gateway API. Korzystając z bramy inferencyjnej, można udostępniać hostowane samodzielnie serwery modeli za pośrednictwem usługi Application Gateway for Containers z routingiem zależnym od modelu i obciążenia.

Brama wnioskowania jest specjalnie utworzona do obsługi dużych modeli językowych (LLM) i innych obciążeń wnioskowania. Kieruje żądania na podstawie sygnałów z serwera modeli, a nie standardowego równoważenia obciążenia, co skraca czas do otrzymania pierwszego tokenu (TTFT), zmniejsza liczbę przekroczeń limitu czasu przy obciążeniu i poprawia efektywność wykorzystania GPU. Oparta na funkcjach obsługi ruchu przychodzącego usługi Application Gateway for Containers brama inferencyjna umożliwia również łączenie obciążeń AI z funkcjami, takimi jak zapora aplikacji internetowej (WAF), aby zabezpieczyć ruch, zanim dotrze on do serwerów modeli.

Wiele własnych środowisk uruchomieniowych wnioskowania, w tym vLLM, uwidacznia interfejsy API HTTP zgodne z protokołem OpenAI , takie jak /v1/chat/completions, /v1/completionsi /v1/models. „Kompatybilność z OpenAI” odnosi się do formatu API, a nie do ograniczenia do modeli hostowanych przez OpenAI. Jeśli inna rodzina modeli jest obsługiwana za pośrednictwem środowiska uruchomieniowego lub serwera proxy korzystającego z tego formatu, usługa Application Gateway for Containers może używać model pola w treści żądania JSON na potrzeby routingu opartego na treści.

Important

Brama wnioskowania usługi Application Gateway for Containers jest obecnie dostępna w wersji zapoznawczej.
Zobacz dodatkowe warunki użytkowania dla wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta, wersji zapoznawczej lub w inny sposób nie zostały jeszcze wydane w wersji ogólnodostępnej.

Co zapewnia rozszerzenie inferencji Gateway API

Rozszerzenie inferencyjne dla Gateway API przekształca implementację Gateway API w bramę inferencyjną, dodając specyficzne dla inferencji pojęcia zaplecza i harmonogramowania.

Rozszerzenie wprowadza następujące podstawowe zasoby i składniki:

• InferencePool: zasób zaplecza reprezentujący grupę zasobników serwera modelu i selektor punktów końcowych używany do wybierania zasobnika dla każdego żądania wnioskowania.
• InferenceObjective: zasób reprezentujący cele obsługi żądań, takie jak priorytet, dla żądań korzystających ze wspólnej puli InferencePool.
• Selektor punktów końcowych (EPP): rozszerzenie dostarczone przez klienta, które działa w klastrze i implementuje planowanie wnioskowania. EPP odbiera metadane żądania, ocenia kandydujące pody serwera modelu przy użyciu konfigurowalnych wtyczek (na przykład głębokość kolejki, wykorzystanie pamięci podręcznej KV i powinowactwo do pamięci podręcznej prefiksów) i zwraca wybrany punkt końcowy. Ponieważ wybór punktu końcowego odbywa się w środowisku EPP, dostępne sposoby routowania zależą od wtyczek modułu oceniającego włączonych w twoim EPP.
• Routing oparty na treści żądania (BBR): procesor żądań, który może analizować treść żądania zgodnego z OpenAI, wyodrębniać nazwę modelu i udostępniać ją bramie jako nagłówek X-Gateway-Model-Name na potrzeby routingu zależnego od modelu.

Usługa Application Gateway dla kontenerów uruchamia procesor BBR jako zarządzaną część bramy, więc nie ma oddzielnej warstwy routingu opartego na treści żądania, którą trzeba osobno wdrażać, skalować i aktualizować. Integruje się z dostarczonym przez klienta rozwiązaniem EPP, aby wspierać podejmowanie decyzji dotyczących trasowania w czasie przetwarzania żądania. Brama inferencyjna obsługuje API rozszerzenia inferencji Gateway API, dzięki czemu można konfigurować te funkcje za pomocą standardowych zasobów Gateway API, a zespoły platformowe mogą korzystać z natywnego dla Kubernetes modelu API do obsługi ruchu inferencyjnego zamiast wprowadzać oddzielny model konfiguracji ruchu ingress.

Jak usługa Application Gateway dla kontenerów używa zasobów wnioskowania

Usługa Application Gateway for Containers nadal używa standardowych zasobów interfejsu Gateway API do konfiguracji ruchu przychodzącego. Mechanizm wnioskowania jest aktywowany, gdy odwołanie do zaplecza HTTPRoute wskazuje na InferencePool zamiast zasobu Kubernetes Service.

W przypadku tras, które nie obsługują inferencji, usługa Application Gateway for Containers zachowuje dotychczasowe działanie interfejsu Gateway API. Ścieżki kierowane do backendów Kubernetes Service nie wywołują procesorów inferencyjnych i nie korzystają z zachowania routingu specyficznego dla inferencji.

W przypadku ścieżek inferencji płaszczyzna sterowania synchronizuje zasoby Gateway API i inferencji oraz programuje płaszczyznę danych w taki sposób, aby:

• Element HTTPRoute wybiera InferencePool zaplecze.
• InferencePool wybiera zasobniki serwera modelu należące do puli.
• EPP skojarzony z pulą jest wywoływany w celu wybrania punktu końcowego.
• Wybrany punkt końcowy serwera modelu odbiera żądanie.
• Opcjonalny routing uwzględniający model używa nazwy modelu wyodrębnionej z żądania przez BBR.

Przepływ żądania

Typowe żądanie wnioskowania jest zgodne z tą ścieżką. Ponumerowane kroki odpowiadają etykietom na poniższym diagramie:

1. Żądanie klienta: klient wysyła żądanie zgodne z interfejsem OpenAI do frontonu usługi Application Gateway for Containers, a odbiornik bramy go akceptuje.
2. Routing oparty na treści żądania (BBR): w przypadku tras uwzględniających model zarządzany procesor BBR sprawdza treść żądania, wyodrębnia nazwę modelu i wstawia nagłówek X-Gateway-Model-Name. Następnie HTTPRoute może dopasować się do tej wartości, aby wybrać odpowiednią InferencePool.
3. Wybór punktu końcowego: Gdy dopasowana trasa jest kierowana do InferencePool, usługa Application Gateway for Containers wywołuje mechanizm EPP, który ocenia żądanie i telemetrię serwera modelu oraz zwraca wybrany punkt końcowy.
4. Kierowanie do puli inferencyjnej: usługa Application Gateway for Containers przekazuje żądanie do wybranego poda serwera modelu, a odpowiedź serwera modelu wraca do klienta przez bramę.

Możliwości routingu

Brama wnioskowania obsługuje te wzorce routingu dla obciążeń sztucznej inteligencji hostowanych samodzielnie. Wybór punktu końcowego odbywa się w EPP, więc sposób uwzględniania obciążenia i pamięci podręcznej zależy od wtyczek oceniających włączonych w danym EPP.

• Routing zależny od modelu: Kieruj żądania na podstawie nazwy modelu w treściach żądań zgodnych z interfejsem API OpenAI, którą wyodrębnia zarządzany procesor BBR.
• Podział ruchu i wdrażanie: użyj standardowego HTTPRoute ważenia backendRefs, aby podzielić ruch między InferencePool backendy na potrzeby wdrożeń modeli typu canary lub blue-green.
• Wybór punktów końcowych z uwzględnieniem obciążenia i pamięci podręcznej: EPP ocenia punkty końcowe na podstawie telemetrii serwera modelu, takiej jak głębokość kolejki i wykorzystanie pamięci podręcznej KV. Gdy EPP włącza ocenianie uwzględniające pamięć podręczną dla prefiksów, żądania, które współdzielą ten sam prefiks monitu, są kierowane do tej samej repliki, aby zwiększyć liczbę trafień w pamięci podręcznej i obniżyć TTFT.
• Ochrona priorytetu żądania i przeciążenia: użyj InferenceObjective zasobów i nagłówka x-gateway-inference-objective żądania, aby przypisać priorytet obsługi. Gdy serwery modeli są przeciążone, EPP najpierw odrzuca żądania o niższym priorytecie, aby chronić ruch wrażliwy na opóźnienia.
• Odporne wybieranie punktu końcowego: Skonfiguruj zachowanie w przypadku awarii EPP za pomocą FailOpen lub FailClose, w zależności od tego, czy ważniejsza dla puli jest dostępność, czy ścisły wybór punktu końcowego.
• Zgodność z Gateway API: Kontynuuj używanie elementów Gateway, HTTPRoute, ReferenceGrant oraz standardowych warunków stanu Gateway API do konfiguracji ruchu wejściowego.

Bezpieczne wnioskowanie

Zachowaj prywatne serwery modelu za bramą zarządzaną i zastosuj możliwości zabezpieczeń platformy do wnioskowania ruchu.

• Zapora aplikacji internetowej (WAF): brama inferencyjna jest natywnie zintegrowana z istniejącą funkcją WAF w usłudze Application Gateway for Containers, stosując zabezpieczenia zgodne z wytycznymi OWASP do ruchu AI, zanim żądania dotrą do serwerów modeli.
• Ochrona kosztownych systemów backendowych: ponieważ polityki są egzekwowane na zarządzanej warstwie brzegowej, nieprawidłowe lub nadużyciowe żądania mogą zostać przeanalizowane i zablokowane, zanim zużyją ograniczone zasoby GPU.

Przykładowe scenariusze

W poniższych scenariuszach przedstawiono typowe sposoby korzystania z bramy wnioskowania:

• Udostępniaj i wdrażaj wersje modeli: Kieruj żądania zgodne z OpenAI do modelu o nazwie InferencePool, a następnie użyj ważonych odwołań backendRefs HTTPRoute, aby przekierować część ruchu do nowej wersji modelu na potrzeby testów kanarkowych przed pełnym wdrożeniem.
• Nadaj priorytet ruchowi wrażliwemu na opóźnienia: Zdefiniuj InferenceObjective zasoby dla obciążeń o wysokim i niskim priorytecie we współdzielonej puli. Żądania interaktywnego czatu mają cel o wysokim priorytecie, podczas gdy zadania wsadowe mają niższy priorytet, z którego rezygnuje się w pierwszej kolejności, gdy pula osiąga limit.

InferencePool w porównaniu z usługą

Obiekt Kubernetes Service pozostaje właściwą abstrakcją backendu dla standardowego ruchu aplikacyjnego. Użyj elementu InferencePool , gdy zaplecze jest grupą zasobników serwera modelu, które wymagają wyboru punktu końcowego specyficznego dla wnioskowania.

Typ zaplecza	Użyj dla	Sposób trasowania
Service	Standardowe zaplecza HTTP, gRPC i aplikacji	Brama kieruje ruch do punktów końcowych usługi przy użyciu standardowego mechanizmu równoważenia obciążenia.
InferencePool	Pody lokalnie hostowanego serwera modeli	Brama wywołuje skonfigurowany EPP, a następnie kieruje żądanie do wybranego punktu końcowego serwera modelu.

Obiekt InferencePool zawiera selektor poda, informacje o porcie docelowym oraz odwołanie do mechanizmu wyboru punktów końcowych. EPP jest odpowiedzialny za wybór punktu końcowego dla żądania. Pojedyncza grupa EPP jest skojarzona z jedną pulą.

Zachowanie w przypadku awarii

Trasowanie inferencji odbywa się w czasie obsługi żądania, więc sposób awarii mechanizmu wyboru punktu końcowego ma znaczenie.

InferencePool Odwołania do selektora punktów końcowych obsługują następujące tryby awarii:

• FailOpen: Jeśli EPP jest niedostępne lub nie odpowiada, brama może kontynuować standardowy wybór punktu końcowego dla puli. Ten wybór zachowuje dostępność, ale może zmniejszyć jakość routingu.
• FailClose: jeśli EPP jest niedostępny lub nie odpowiada, brama odrzuca żądanie. Ten wybór uniemożliwia wysyłanie ruchu bez wymaganej decyzji wyboru punktu końcowego.

W przypadku routingu uwzględniającego model, który opiera się na analizie treści żądania, usługa Application Gateway for Containers priorytetowo traktuje poprawność. Jeśli dla trasy wymagającej BBR nie można wyodrębnić nazwy modelu, żądanie zostanie odrzucone, zamiast zostać po cichu przekierowane do backendu niewłaściwego modelu.

Zagadnienia operacyjne

Uwzględnij poniższe kwestie przy planowaniu uruchamiania obciążeń związanych z inferencją za bramą Application Gateway for Containers:

• Wydajność EPP: EPP znajduje się w ścieżce żądania dla backendów InferencePool. Umożliwia ustawianie rozmiaru i monitorowanie go w taki sposób, jak krytyczny składnik aplikacji.
• Telemetria serwera modeli: EPP potrzebuje aktualnych metryk serwera modeli, aby podejmować trafne decyzje dotyczące routingu. Upewnij się, że serwer modelu obsługuje metryki oczekiwane przez konfigurację EPP.
• Wydajność i planowanie GPU: pody serwera modeli często wymagają pul węzłów GPU, wtyczek urządzeń i poświadczeń do pobierania modeli.
• Automatyczne skalowanie: skaluj zasobniki serwera modeli na podstawie sygnałów inferencyjnych, takich jak długość kolejki i wykorzystanie pamięci podręcznej KV, przy użyciu Horizontal Pod Autoscaler lub KEDA. Automatyczne skalowanie zwiększa zasoby wraz ze wzrostem zapotrzebowania, podczas gdy EPP omija repliki, które są już przeciążone.
• Odpowiedzi strumieniowane: wiele zadań związanych z generowaniem odpowiedzi czatu korzysta ze zdarzeń przesyłanych przez serwer. Zweryfikuj zachowanie przesyłania strumieniowego podczas testowania kompleksowego opóźnienia i ustawień limitu czasu.
• Monitorowanie: Monitoruj stan Gateway i HTTPRoute, stan InferencePool, stan EPP, gotowość serwera modeli oraz metryki serwera modeli, takie jak aktywne żądania i długość kolejki.

Ograniczenia

Brama wnioskowania koncentruje się na obciążeniach wnioskowania samodzielnie uruchomionych na platformie Kubernetes. Kierowanie bezpośrednio do publicznych lub zarządzanych punktów końcowych dostawcy modeli wykracza poza zakres tej integracji.

Rozszerzenie inferencji interfejsu Gateway API rozwija się niezależnie od usługi Application Gateway for Containers. Użyj wersji interfejsu API i manifestów, które pasują do rozszerzeń wnioskowania zainstalowanych w klastrze.

Następne kroki

• Skonfiguruj bramę wnioskowania Application Gateway for Containers
• Składniki usługi Application Gateway dla kontenerów
• Dokumentacja rozszerzenia inferencji Gateway API