Application Gateway för containrar – gateway för inferens

AI-slutsatsdragningsarbetsbelastningar fungerar inte som traditionella tillståndslösa HTTP-program. Begäranden är ofta modellspecifika, tidskrävande, dyra att hantera och känsliga för körningssignaler som acceleratortillgänglighet, ködjup, begärandeprioritet, tokenbudget och modellserverkapacitet.

Application Gateway for Containers slutsatsdragningsgateway stöder dessa arbetsbelastningar genom att integrera med Kubernetes Gateway API Inference Extension, som lägger till slutsatsmedvetna resurser i Gateway API-modellen. Med hjälp av inferensgatewayen kan du exponera lokala modellservrar via Application Gateway för containrar med modellmedveten och belastningsmedveten routning.

Inferensgatewayen är specialbyggd för att hantera stora språkmodeller (LLM) och andra slutsatsdragningsarbetsbelastningar. Den dirigerar begäranden baserat på modellserversignaler i stället för allmän belastningsutjämning, vilket minskar tiden till första token (TTFT), minskar tidsgränser under belastning och förbättrar GPU-effektiviteten. Inference gateway bygger på ingressfunktionerna i Application Gateway for Containers och gör det också möjligt att kombinera AI-arbetsbelastningar med funktioner som en brandvägg för webbapplikationer (WAF) för att skydda trafiken innan den når dina modellservrar.

Många självhostade inferenskörmiljöer, inklusive vLLM, tillhandahåller OpenAI-kompatibla HTTP-API:er som /v1/chat/completions, /v1/completions och /v1/models. OpenAI-kompatibilitet syftar på API-formatet, inte på att det är begränsat till modeller som driftas av OpenAI. Om en annan modellfamilj tillhandahålls via en körmiljö eller proxy som använder det här formatet kan Application Gateway för containrar använda fältet model i JSON-begärans brödtext för routning baserad på brödtexten.

Vad gateway-API-inferenstillägget innehåller

Gateway API Inference Extension omvandlar en gateway-API-implementering till en slutsatsdragningsgateway genom att lägga till inferensspecifika serverdels- och schemaläggningsbegrepp.

Tillägget introducerar dessa primära resurser och komponenter:

• InferencePool: En serverdelsresurs som representerar en grupp modellserverpoddar och slutpunktsväljaren som används för att välja en podd för varje slutsatsdragningsbegäran.
• InferenceObjective: En resurs som representerar mål för begärandebetjäning, till exempel prioritet, för begäranden som delar en InferencePool.
• Slutpunktsväljare (EPP): Ett tillägg som tillhandahålls av kunden och som körs i klustret och implementerar slutsatsdragningsschemaläggning. EPP tar emot begärandemetadata, poängsätter kandidatmodellserverpoddar med hjälp av konfigurerbara plugin-program (till exempel ködjup, KV-cacheanvändning och prefix-cachetillhörighet) och returnerar den valda slutpunkten. Eftersom slutpunktsval körs i EPP beror vilka routningsbeteenden som är tillgängliga på de poängsättningspluginer som din EPP aktiverar.
• Kroppsbaserad routning (BBR): En begärandeprocessor som kan inspektera en OpenAI-kompatibel begärandetext, extrahera modellnamnet och göra den tillgänglig för gatewayen X-Gateway-Model-Name som huvud för modellmedveten routning.

Application Gateway for Containers kör BBR-processorn som en hanterad del av gatewayen, så det finns inget separat innehållsbaserat routningslager att driftsätta, skala eller uppdatera. Det integreras med ett EPP som kunden tillhandahåller för att stödja routningsbeslut vid begäran. Inferensgatewayen stöder Gateway API Inference Extension API, så du kan konfigurera dessa funktioner via vanliga Gateway API-resurser, och plattformsteam kan använda en Kubernetes-intern API-modell för inferenstrafik i stället för att införa en separat ingresskonfigurationsmodell.

Så använder Application Gateway för containrar inferensresurser

Application Gateway for Containers fortsätter att använda vanliga Gateway API-resurser för konfiguration av ingress. Slutsatsdragningsbeteende aktiveras när en HTTPRoute serverdelsreferens riktar sig mot en InferencePool i stället för en Kubernetes Service.

För icke-slutsatsdragningsvägar behåller Application Gateway for Containers det befintliga beteendet för Gateway-API:et. Rutter som pekar mot Kubernetes-bakändar Service anropar inte inferensprocessorer och får inte inferensspecifikt routningsbeteende.

För inferensvägar samordnar kontrollplanet Gateway API och inferensresurserna samt konfigurerar dataplanet så att:

• Väljer HTTPRouteInferencePool serverdelen.
• InferencePool väljer de modellserver-poddar som tillhör poolen.
• Den EPP som är kopplad till poolen anropas vid val av slutpunkt.
• Den valda modellserverslutpunkten tar emot begäran.
• Valfri modellmedveten routning använder namnet på begärandemodellen som extraherats av BBR.

Begärandeflöde

En typisk slutsatsdragningsbegäran följer den här sökvägen. De numrerade stegen mappas till etiketterna i följande diagram:

1. Klientbegäran: En klient skickar en OpenAI-kompatibel begäran till Application Gateway for Containers-klientdelen och gatewaylyssnaren accepterar den.
2. Dirigering baserad på begärandetext (BBR): För modellmedvetna rutter inspekterar den hanterade BBR-processorn begärandetexten, extraherar modellnamnet och lägger till headern X-Gateway-Model-Name. HTTPRoute kan sedan matchas mot det värdet för att välja lämplig InferencePool.
3. Val av slutpunkt: När den matchade vägen är riktad mot en InferencePoolanropar Application Gateway for Containers EPP, som utvärderar telemetrin för begäran och modellservern och returnerar den valda slutpunkten.
4. Routning till InferencePool: Application Gateway for Containers vidarebefordrar begäran till den valda podden för modellservern, och modellserverns svar går tillbaka till klienten via gatewayen.

Routningsfunktioner

Inferensgatewayen stöder dessa routningsmönster för lokala AI-arbetsbelastningar. Val av slutpunkt körs i EPP, så det belastnings- och cachemedvetna beteendet beror på de poängsättningspluginer som din EPP aktiverar.

• Modellmedveten routning: Dirigera begäranden baserat på modellnamnet i OpenAI-kompatibla begärandeorgan, som den hanterade BBR-processorn extraherar.
• Trafikdelning och distributioner: Använd standardviktad HTTPRoutebackendRefs för att dela trafik mellan InferencePool serverdelar för kanarie- eller blågröna modelldistributioner.
• Belastningsanpassat och cacheanpassat val av slutpunkter: EPP rangordnar slutpunkter utifrån telemetri från modellservern, till exempel ködjup och KV-cacheanvändning. När EPP aktiverar prefix-cache-medveten poängsättning skickas förfrågningar som delar samma promptprefix till samma replik för att öka cacheträffarna och sänka TTFT.
• Begäransprioritet och överbelastningsskydd: Använd InferenceObjective-resurser och begäranderubriken x-gateway-inference-objective för att ange serveringsprioritet. När modellservrarna är mättade kastar EPP begäranden med lägre prioritet först för att skydda svarstidskritisk trafik.
• Motståndskraftigt slutpunktsval: Konfigurera beteendet vid EPP-fel med FailOpen eller FailClose, beroende på om tillgänglighet eller strikt slutpunktsval är viktigast för en pool.
• Gateway-API-kompatibilitet: Fortsätt att använda statusvillkor för Gateway, HTTPRoute, ReferenceGrant och Standard Gateway API för ingresskonfiguration.

Säker slutsatsdragning

Håll modellservrarna privata bakom den hanterade gatewayen och tillämpa plattformens säkerhetsfunktioner på slutsatsdragningstrafik.

• Brandvägg för webbprogram (WAF): Inferensgatewayen parar internt med den befintliga WAF-funktionen i Application Gateway för containrar och tillämpar OWASP-justerade skydd på AI-trafik innan begäranden når dina modellservrar.
• Skydd för dyra backend-tjänster: Eftersom policyn tillämpas i den hanterade edge-miljön kan felaktiga eller skadliga begäranden granskas och blockeras innan de förbrukar begränsad GPU-kapacitet.

Exempelscenarier

Följande scenarier visar vanliga sätt att använda inferensgatewayen:

• Hantera och distribuera modellversioner: Dirigera OpenAI-kompatibla begäranden till ett InferencePool efter modellnamn och använd sedan viktade HTTPRoute backendRefs för att flytta en procentandel trafik till en ny modellversion för kanarietestning innan du slutför distributionen.
• Prioritera svarstidskritisk trafik: Definiera InferenceObjective resurser för arbetsbelastningar med hög prioritet och låg prioritet i en delad pool. Interaktiva chattbegäranden har högsta prioritet, medan batchjobb använder en lägre prioritet som prioriteras bort först när poolen är fullt belastad.

InferencePool jämfört med Tjänst

En Kubernetes Service förblir rätt backend-abstraktion för standardprogramtrafik. Använd en InferencePool när backenden är en grupp av modellserverpoddar som behöver inferensspecifikt val av slutpunkt.

En InferencePool innehåller en poddväljare, målportinformation och en referens för slutpunktsväljaren. EPP ansvarar för att välja slutpunkten för en begäran. En enda EPP är associerad med en enda pool.

Beteende vid fel

Routning av inferens sker vid begärandetillfället, så felläget för slutpunktsväljaren är viktigt.

InferencePool slutpunktsväljarereferenser stöder följande fellägen:

• FailOpen: Om EPP inte är tillgänglig eller inte svarar kan gatewayen fortsätta med standardval av slutpunkter för poolen. Det här valet bevarar tillgängligheten men kan minska routningskvaliteten.
• FailClose: Om EPP inte är tillgänglig eller inte svarar avvisar gatewayen begäran. Det här valet förhindrar att trafik skickas utan det beslut om slutpunktsval som krävs.

För modellmedveten routning som är beroende av parsning av begärandetexten föredrar Application Gateway for Containers korrekthet. Om modellnamnet inte kan extraheras för en rutt som kräver BBR, avvisas förfrågan i stället för att tyst dirigeras till fel modellbackend.

Operativa överväganden

Planera för följande överväganden när du kör slutsatsdragningsarbetsbelastningar bakom Application Gateway för containrar:

• EPP-kapacitet: EPP ligger i sökvägen för begäranden till InferencePool backend-tjänster. Dimensionera och övervaka den som en kritisk applikationskomponent.
• Modellservertelemetri: EPP behöver nya modellservermått för att fatta beslut om routning av hög kvalitet. Bekräfta att modellservern stöder de mått som förväntas av DIN EPP-konfiguration.
• GPU-kapacitet och schemaläggning: Modellserverpoddar kräver ofta GPU-nodpooler, enhets plugin-program och autentiseringsuppgifter för modellnedladdning.
• Autoskalning: Skala modellserverpoddar baserat på inferenssignaler som ködjup och användning av KV-cache med hjälp av Horizontal Pod Autoscaler eller KEDA. Autoskalning lägger till kapacitet när efterfrågan växer, medan EPP dirigerar runt repliker som redan är mättade.
• Direktuppspelningssvar: Många arbetsbelastningar för chattens slutförande använder server-skickade händelser. Verifiera strömningsbeteende vid testning av svarstid från slutpunkt till slutpunkt och tidsgränsinställningar.
• Observerbarhet: Övervaka gateway- och HTTPRoute-status, InferencePool-status, EPP-hälsa, modellserverberedskap och modellservermått som aktiva begäranden och ködjup.

Limitations

Inferensgatewayen fokuserar på självhanterade slutsatsdragningsarbetsbelastningar som körs på Kubernetes. Routning direkt till offentliga eller hanterade modellproviderslutpunkter ligger utanför omfånget för den här integreringen.

Inferenstillägget för gateway-API:et utvecklas oberoende av Application Gateway för containrar. Använd API-versioner och manifest som överensstämmer med de CRD:er för inferenstillägget som är installerade i ditt kluster.

Nästa steg

• Konfigurera inferensgateway för Application Gateway for Containers
• Application Gateway för containrar-komponenter
• Dokumentation för inferenstillägget till Gateway API