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 Application Gateway for Containers obsługuje te obciążenia dzięki integracji z rozszerzeniem Gateway API Inference Extension dla Kubernetes, które dodaje backendy świadome wnioskowania do modelu 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.

Elementy budulcowe bramy inferencyjnej

Brama inferencyjna łączy trzy części: implementację API bramy, która obsługuje ingress, backend InferencePool zdefiniowany przez rozszerzenie Gateway API Inference oraz endpoint picker, który wybiera pod serwera modelu dla każdego żądania. Application Gateway for Containers zapewnia pierwszą część rozwiązania oraz zarządzany procesor routingu oparty na treści żądania. Dostarczasz InferencePool i selektor endpointów w swoim klastrze.

• InferencePool: Zasób backendowy (inference.networking.k8s.io/v1) reprezentujący grupę podów serwera modelowego, port, na którym nasłuchują, oraz referencję do endpoint pickera, który wybiera pod dla każdego żądania wnioskowania.
• Endpoint Picker (EPP): Rola komponentu zdefiniowana przez Gateway API Inference Extension, który wybiera punkt końcowy dla każdego żądania. Brama wywołuje EPP, używając protokołu endpoint picker zdefiniowanego przez rozszerzenie. EPP zwraca pod serwera modelu, który powinien obsłużyć żądanie. EPP opisuje kontrakt, a nie pojedynczy produkt, a każda implementacja protokołu może wypełnić tę rolę.
• Routowanie na podstawie treści żądania (BBR): Procesor żądań, który sprawdza treść żądania zgodną z OpenAI, wyodrębnia nazwę modelu i udostępnia ją bramie jako nagłówek X-Gateway-Model-Name do routowania uwzględniającego model.

Application Gateway for Containers uruchamia procesor BBR jako zarządzaną część bramy, więc nie ma oddzielnej warstwy routowania na podstawie treści ani przetwarzania danych, którą trzeba wdrażać, skalować lub aktualizować. Ponieważ brama inferencyjna korzysta z Gateway API Inference Extension API, konfigurujesz ją za pomocą standardowych zasobów Gateway API, a zespoły platformy mogą używać natywnego modelu API Kubernetes do ruchu inferencyjnego zamiast wprowadzać osobny model konfiguracji Ingress.

Zmiany w Gateway API Inference Extension w wersji 1.6

Począwszy od wersji 1.6, projekt Gateway API Inference Extension koncentruje się na podstawowej specyfikacji: InferencePool API, protokole endpoint picker oraz testach zgodności. Komponenty specyficzne dla implementacji przeniesione do projektu llm-d:

Jeśli utworzyłeś zasoby InferenceObjective lub InferenceModelRewrite za pomocą interfejsu API inference.networking.x-k8s.io/v1alpha2, zainstaluj CRD llm-d i utwórz zasoby ponownie w wersjach API llm-d. InferencePool API się nie zmienia.

Implementacje selektora punktów końcowych

Zachowanie routingu, które otrzymujesz z elementu InferencePool, zależy od implementacji EPP, do której odwołuje się pula. Application Gateway for Containers wywołuje EPP przez standardowy protokół i nie zależy od konkretnej implementacji. Dwie implementacje są utrzymywane równolegle ze specyfikacją:

Używaj routera llm-d, gdy chcesz mieć zachowania uwzględniające obciążenie, pamięć podręczną i priorytet, opisane w tym artykule. Użyj LWEPP, aby zweryfikować, czy twoja brama, InferencePool, i serwery modeli są poprawnie podłączone z możliwie najmniejszym EPP.

Każdy InferencePool odnosi się do jednego wdrożenia EPP. Router llm-d jest zazwyczaj instalowany w każdej puli za pomocą jego wykresu Helm, który tworzy razem element InferencePool, wdrożenie EPP oraz jego konfigurację.

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. Zasoby Route skierowane do backendów Kubernetes Service nie wywołują EPP i nie otrzymują specyficznego dla wnioskowania zachowania routingu, nawet gdy Service wybiera te same pody serwera modelu.

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 celuje w InferencePool, Application Gateway for Containers wywołuje EPP puli. EPP ocenia żądanie oraz telemetrię serwera modelu oraz zwraca wybrany punkt końcowy. Korzystając z routera llm-d, EPP może również przechowywać żądanie w kolejce priorytetowej do czasu dostępności pojemności lub przepisać żądaną nazwę modelu, zanim zwróci 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. Application Gateway for Containers zapewnia modelowo świadome routowanie, podział ruchu oraz obsługę awarii. Wybór punktów końcowych, priorytet i przepisywanie modeli są realizowane w EPP, więc te zachowania zależą od implementacji EPP oraz wtyczek i funkcji, które w niej umożliwiasz.

• 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 wdrożenia w różnych pulach: Użyj standardowego HTTPRoute ważenia backendRefs do rozdzielenia ruchu między InferencePool backendy dla canary lub blue-green rolloutów modelu działającego na oddzielnych kapsułach.
• Przepisywanie nazw modeli w puli: Przy routerze llm-d używaj InferenceModelRewrite zasobów do mapowania nazwy modelu żądanej przez klientów na jeden lub więcej modeli docelowych obsługiwanych przez tę samą pulę, z wagami. Na przykład klienci ciągle żądają support-assistant , podczas gdy EPP wysyła 90 procent żądań do adaptera support-v1 LoRA i 10 procent do support-v2. Router zwraca w odpowiedzi żądaną przez klienta nazwę modelu.
• 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 punktację uwzględniającą wspólny prefiks w pamięci podręcznej, żądania współdzielące prefiks monitu, takie jak wypowiedzi w tej samej konwersacji, trafiają do tej samej repliki, aby zwiększyć liczbę trafień do pamięci podręcznej i obniżyć TTFT.
• Priorytet żądania i ochrona przed przeciążeniem: W routerze llm-d zdefiniuj InferenceObjective zasoby (llm-d.ai/v1), które przypisują priorytet klasie ruchu w puli, a klienci wybierają cel za pomocą nagłówka żądania x-llm-d-inference-objective. Gdy kontrola przepływu jest włączona i pula jest nasycona, EPP kolejkuje żądania w pasmach priorytetów, najpierw wysyła żądania o wyższym priorytecie i odrzuca żądania o niższym priorytecie, gdy ich pasmo jest pełne lub czas życia się kończy.
• 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 sieciowa aplikacji internetowych (WAF): Brama inferencyjna natywnie łączy się z istniejącą funkcją WAF w Application Gateway for Containers, stosując zabezpieczenia ruchu AI zanim żądania dotrą do serwerów modelu.
• Ochrona kosztownych backendów: Ponieważ polityka jest egzekwowana na zarządzanej warstwie brzegowej, nieprawidłowo uformowane lub stanowiące nadużycie żądania mogą być kontrolowane i blokowane, zanim dotrą do EPP lub zużyją ograniczone zasoby GPU.

Przykładowe scenariusze

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

• Serwowanie i wdrażanie wersji modelu: Kieruj żądania zgodne z OpenAI do elementu InferencePool według nazwy modelu. Aby wdrożyć nowy adapter LoRA na tych samych podach, użyj InferenceModelRewrite, aby przekierować część żądań do nowego adaptera. Aby wdrożyć model działający na osobnych podach, użyj ważonych HTTPRoute backendRefów na dwóch InferencePool backendach.
• Ponowne wykorzystanie kontekstu z pamięci podręcznej do wieloturowych rozmów: Włącz ocenianie uwzględniające pamięć podręczną prefiksu w routerze llm-d, aby kolejne tury rozmowy wracały do repliki, która ma już swoją pamięć podręczną KV, co zmniejsza pracę przy prefill i TTFT.
• Nadaj priorytet ruchowi wrażliwemu na opóźnienia: Zdefiniuj InferenceObjective zasoby dla obciążeń o wysokim i niskim priorytecie we współdzielonej puli. Interaktywne żądania czatu mają wysoki priorytet, podczas gdy zadania wsadowe używają niższego priorytetu, który czeka na wolną pojemność i jest odrzucany w pierwszej kolejności, gdy pula jest przesycona.

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.

Usługa InferencePool zawiera selektor poda, informacje o porcie docelowym oraz referencję do selektora punktu końcowego (endpointPickerRef). EPP wybiera punkt końcowy 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.

Element endpointPickerRef urządzenia InferencePool obsługuje następujące tryby uszkodzenia:

• FailOpen: Jeśli EPP jest niedostępny lub nie odpowiada, brama kontynuuje standardowy wybór punktów końcowych dla puli. Ten wybór zachowuje dostępność, ale powoduje utratę zachowań EPP, takich jak powinowactwo pamięci podręcznej, priorytet i przepisania modelu, dopóki EPP się nie odzyska.
• 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. Wartość domyślna to FailClose.

Jeśli twoja pula polega na InferenceModelRewrite mapowaniu nazwy modelu skierowanej do klienta na model, który serwery faktycznie ładują, żądania omijające EPP w ramach FailOpen docierają do serwera modelu z oryginalną nazwą modelu. Upewnij się, że serwery modeli mogą obsługiwać tę nazwę, lub użyj FailClose dla puli.

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. Dobierz rozmiar i monitoruj go jak krytyczny komponent aplikacji oraz uruchamiaj więcej niż jedną replikę dla pul produkcyjnych.
• Konfiguracja EPP: W routerze llm-d wtyczki scorer, ich wagi, wykrywanie nasycenia i kontrola przepływu są ustawiane w elemencie EndpointPickerConfig routera, zwykle przez wartości Helm. Niektóre funkcje, takie jak kontrola przepływu, są domyślnie ukryte za flagami funkcji i są wyłączone.
• Telemetria serwera modeli: EPP potrzebuje aktualnych metryk serwera modeli, aby podejmować trafne decyzje dotyczące routingu. Potwierdź, że Twój serwer modelu udostępnia metryki, których oczekuje konfiguracja 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. Brama i EPP nie wymagają GPU.
• 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. Router llm-d udostępnia także metryki Prometheus dotyczące harmonogramowania, kontroli przepływu i decyzji o przepisaniu modelu.

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.
• Walidacja JWT zdefiniowana przez element AuthPolicy nie jest obecnie obsługiwana na trasach, których backendem jest InferencePool.
• rozszerzenie Gateway API Inference oraz router llm-d ewoluują niezależnie od Application Gateway for Containers oraz od siebie nawzajem. Używaj wersji API i manifestów odpowiadających CRD zainstalowanym na Twoim klastrze: CRD InferencePool z Gateway API Inference Extension oraz CRD InferenceObjective i InferenceModelRewrite z wydania routera llm-d, które wdrażasz.

Następne kroki

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