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 inferensgateway stödjer dessa arbetsbelastningar genom att integreras med Kubernetes Gateway API Inference Extension, som lägger till inferensmedvetna backends till 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.

Byggstenarna i inferensgatewayen

En inferensgateway kombinerar tre delar: en gateway-API-implementation som hanterar ingress, en InferencePool backend definierad av Gateway API Inference Extension, och en endpoint picker som väljer en modellserverpod för varje förfrågan. Application Gateway for Containers tillhandahåller den första komponenten och en hanterad innehållsbaserad routningsprocessor. Du tillhandahåller InferencePool och endpointväljaren i ditt kluster.

• InferencePool: En backendresurs (inference.networking.k8s.io/v1) som representerar en grupp modellserverpoddar, porten de används på, och en referens till endpoint pickern som väljer en pod för varje inferensförfrågan.
• Endpoint Picker (EPP): Den roll, definierad av Gateway API Inference Extension, som komponenten har när den väljer en endpoint för varje förfrågan. Gatewayen anropar EPP genom att använda endpoint picker-protokollet som definieras av tillägget. EPP returnerar modellserverpodden som ska hantera förfrågan. EPP beskriver ett kontrakt, inte en enskild produkt, och vilken implementation av protokollet som helst kan fylla rollen.
• Kroppsbaserad routing (BBR): En requestprocessor som inspekterar en OpenAI-kompatibel requestbody, extraherar modellnamnet och gör den tillgänglig för gatewayen som X-Gateway-Model-Name header för modelmedveten routing.

Application Gateway for Containers kör BBR-processorn som en hanterad del av gatewayen, så det finns inget separat lager för innehållsbaserad routning eller för bearbetning av nyttolast att distribuera, skala eller patcha. Eftersom inferensgatewayen använder Gateway API Inference Extension API, konfigurerar du den via standardresurser för Gateway API, och plattformsteam kan använda en Kubernetes-native API-modell för inferenstrafik istället för att införa en separat ingresskonfigurationsmodell.

Ändringar i Gateway API Inference Extension v1.6

Från och med v1.6 fokuserar Gateway API Inference Extension-projektet på kärnspecifikationen: InferencePool API:et, endpoint picker-protokollet och konformitetstester. Implementeringsspecifika komponenter flyttades till projektet llm-d:

Om du har skapat InferenceObjective eller InferenceModelRewrite resurser med API:et inference.networking.x-k8s.io/v1alpha2 , installera llm-d CRD:erna och återskapa resurserna med llm-d API-versionerna. API:et InferencePool ändras inte.

implementeringar av Endpoint picker

Routingbeteendet du får från en InferencePool beror på vilken EPP-implementation poolen refererar till. Application Gateway for Containers anropar EPP via standardprotokollet och är inte beroende av en specifik implementation. Två implementationer underhålls parallellt med specifikationen:

Använd llm-d-routern när du vill ha de lastmedvetna, cache-medvetna och prioriteringsmedvetna beteenden som beskrivs i denna artikel. Använd LWEPP för att verifiera att din gateway, InferencePool, och modellservrar är korrekt anslutna med minsta möjliga EPP.

Varje InferencePool hänvisar till en EPP-distribution. llm-d router installeras vanligtvis per pool genom att använda dess Helm chart, som skapar InferencePool, EPP-deploymenten och dess konfiguration tillsammans.

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 riktar sig mot Kubernetes-backends Service anropar inte EPP och får inte inferensspecifik routing, även när Service väljer samma modellserverpoddar.

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 rutten riktar in sig på en InferencePool, anropar Application Gateway for Containers poolens EPP. EPP utvärderar förfrågan och modellservertelemetrin och returnerar den valda ändpunkten. Genom att använda llm-d-routern kan EPP även hålla förfrågan i en prioritetskö tills kapacitet är tillgänglig, eller skriva om det begärda modellnamnet innan den returnerar en endpoint.
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. Application Gateway for Containers erbjuder modellmedveten routing, trafikdelning och felhantering. Endpoint-val, prioritet och modellomskrivningar körs i EPP, så dessa beteenden beror på EPP-implementeringen och de plugins och funktioner du aktiverar i den.

• Modellmedveten routning: Dirigera begäranden baserat på modellnamnet i OpenAI-kompatibla begärandeorgan, som den hanterade BBR-processorn extraherar.
• Trafikdelning och utrullningar över pooler: Använd standardviktad HTTPRoute routning backendRefs för att dela trafiken över InferencePool backends för kanarie- eller blågröna utrullningar av en modell som körs på separata poddar.
• Modellomskrivningar inom en pool: Med llm-d-routern använder InferenceModelRewrite du resurser för att mappa modellnamnet som klienterna begär till en eller flera målmodeller som betjänas av samma pool, med vikter. Till exempel fortsätter klienter att begära support-assistant medan EPP skickar 90 procent av förfrågningarna till LoRA-adaptern support-v1 och 10 procent till support-v2. Routern returnerar klientens önskade modellnamn i svaret.
• 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, går förfrågningar som delar ett promptprefix, såsom turer i samma konversation, till samma replika för att höja cache-träffar och sänka TTFT.
• Förfrågningsprioritet och överbelastningsskydd: Med llm-d-routern definierar du InferenceObjective resurser (llm-d.ai/v1) som tilldelar en prioritet till en trafikklass i en pool, och låter klienter välja ett objektiv med x-llm-d-inference-objective request-header. När flödeskontroll är aktiverad och poolen är mättad, köar EPP förfrågningar i prioritetsband, skickar först ut förfrågningar med högre prioritet och gör sig av med lägre prioritetsförfrågningar när deras band är fullt eller deras time-to-live löper ut.
• 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 webbapplikationer (WAF): Inferensgatewayen integreras sömlöst med den befintliga WAF-funktionen i Application Gateway for Containers och tillämpar skydd på AI-trafik innan förfrågningar når dina modellservrar.
• Skydd för dyra backends: Eftersom policyn tillämpas vid den hanterade edge-noden kan felaktiga eller missbrukande förfrågningar inspekteras och blockeras innan de når EPP eller förbrukar knapp GPU-kapacitet.

Exempelscenarier

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

• Servera och rulla ut modellversioner: Dirigera OpenAI-kompatibla förfrågningar till ett InferencePool efter modellnamn. För att rulla ut en ny LoRA-adapter på samma pods, använd en InferenceModelRewrite-distribution för att flytta en procentandel av förfrågningarna till den nya adaptern. För att rulla ut en modell som körs på separata poddar, använd viktade HTTPRoute backendRefs över två InferencePool backends.
• Återanvänd cachad kontext för konversationer med flera turer: Aktivera prefix-cache-aware poängsättning i llm-d-routern så att uppföljande turer i en konversation återgår till replikan som redan innehåller dess KV-cache, vilket minskar prefill-arbete och TTFT.
• Prioritera svarstidskritisk trafik: Definiera InferenceObjective resurser för arbetsbelastningar med hög prioritet och låg prioritet i en delad pool. Interaktiva chattförfrågningar har hög prioritet, medan batchjobb använder en lägre prioritet som väntar på ledig kapacitet och kopplas bort först när poolen är mättad.

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 tjänst InferencePool inkluderar en podväljare, information om målport och en endpoint picker-referens (endpointPickerRef). EPP väljer endpoint för en förfrågan. 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.

endpointPickerRef på en InferencePool stöder dessa fellägen:

• FailOpen: Om EPP inte är tillgänglig eller inte svarar fortsätter gatewayen med standardval av endpoint för poolen. Detta val bevarar tillgängligheten men EPP-beteenden såsom cacheaffinitet, prioritet och modellomskrivningar går förlorade tills EPP återhämtar sig.
• 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. FailClose används som standard.

Om din pool förlitar sig på InferenceModelRewrite att mappa ett klientriktat modellnamn till en modell som servrarna faktiskt laddar, når förfrågningar som kringgår EPP under FailOpen modellservern med det ursprungliga modellnamnet. Se till att modellservrarna kan hantera det namnet, eller använd FailClose för poolen.

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, och kör mer än en replika för produktionspooler.
• EPP-konfiguration: Med llm-d-routern anges scorer-plugins, deras vikter, mättnadsdetektion och flödeskontroll i routerns EndpointPickerConfig, vanligtvis via Helm-värden. Vissa funktioner, som flödeskontroll, finns bakom funktionsflaggor och är avstängda som standard.
• Modellservertelemetri: EPP behöver nya modellservermått för att fatta beslut om routning av hög kvalitet. Bekräfta att din modellserver exponerar de mätvärden som din EPP-konfiguration förväntar sig.
• GPU-kapacitet och schemaläggning: Modellserverpoddar kräver ofta GPU-nodpooler, enhets plugin-program och autentiseringsuppgifter för modellnedladdning. Gatewayen och EPP:n kräver inga GPU:er.
• 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. LLM-D-routern exponerar också Prometheus-mätvärden för sina beslut om schemaläggning, flödeskontroll och modellomskrivning.

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.
• JWT-validering definierad av en AuthPolicy stöds för närvarande inte på rutter vars backend är en InferencePool.
• Gateway API Inference Extension och llm-d-routern utvecklas oberoende av Application Gateway for Containers och från varandra. Använd API-versioner och manifest som matchar de CRD:er som är installerade i ditt kluster: InferencePool CRD från Gateway API Inference Extension, och InferenceObjective samt InferenceModelRewrite CRD:erna från llm-d-routerns release som du distribuerar.

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
• llm-d router