Application Gateway for Containers - inferencegateway

AI-inferentieworkloads gedragen zich niet als traditionele statusloze HTTP-applicaties. Aanvragen zijn vaak modelspecifiek, langlopend, duur om te dienen en gevoelig voor runtime-signalen, zoals beschikbaarheid van de accelerator, wachtrijdiepte, aanvraagprioriteit, tokenbudget en modelservercapaciteit.

Application Gateway for Containers inference gateway ondersteunt deze workloads door te integreren met de Kubernetes Gateway API Inference Extension, die inferencebewuste resources toevoegt aan het Gateway API-model. Met behulp van de inferentiegateway kunt u zelfgehoste modelservers ontsluiten via Application Gateway for Containers met modelbewust en belastingbewust routeringsgedrag.

De deductiegateway is speciaal ontworpen voor het leveren van grote taalmodellen (LLM's) en andere deductieworkloads. Hiermee worden aanvragen gerouteerd op basis van modelserversignalen in plaats van algemene taakverdeling, waardoor de tijd naar het eerste token (TTFT) wordt verlaagd, time-outs onder belasting worden verminderd en de GPU-efficiëntie wordt verbeterd. Dankzij de mogelijkheden voor inkomend verkeer van Application Gateway for Containers kunt u met de deductiegateway AI-workloads koppelen aan mogelijkheden zoals de Web Application Firewall (WAF) om verkeer te beveiligen voordat deze uw modelservers bereikt.

Veel zelfgehoste inferentie-runtimes, waaronder vLLM, bieden OpenAI-compatibele HTTP-API's aan, zoals /v1/chat/completions, /v1/completions en /v1/models. OpenAI-compatibel heeft betrekking op de API-indeling, niet dat het beperkt is tot door OpenAI gehoste modellen. Als een andere modelfamilie wordt geleverd via een runtime of proxy die deze indeling gebruikt, kan Application Gateway voor Containers het model veld in de hoofdtekst van de JSON-aanvraag gebruiken voor routering op basis van hoofdteksten.

Wat de Gateway API-inferentie-extensie biedt

Met de gateway-API-deductieextensie wordt een gateway-API-implementatie omgezet in een deductiegateway door deductiespecifieke back-end- en planningsconcepten toe te voegen.

De extensie introduceert deze primaire resources en onderdelen:

• InferencePool: een backendresource die een groep modelserverpods vertegenwoordigt en de endpointkiezer die wordt gebruikt om voor elke inferentieaanvraag een pod te selecteren.
• InferenceObjective: een resource die doelstellingen vertegenwoordigt voor het afhandelen van verzoeken, zoals prioriteit, voor verzoeken die dezelfde InferencePool gebruiken.
• Eindpuntkiezer (EPP): een door de klant geleverde extensie die wordt uitgevoerd in uw cluster en deductieplanning implementeert. De EPP ontvangt metagegevens van aanvragen, beoordeelt kandidaat-pods van modelservers met behulp van configureerbare plug-ins (bijvoorbeeld de lengte van de wachtrij, KV-cachegebruik en prefix-cache-affiniteit) en retourneert het geselecteerde eindpunt. Omdat eindpuntselectie in de EPP wordt uitgevoerd, hangt het beschikbare routeringsgedrag af van de scoreplug-ins die uw EPP heeft ingeschakeld.
• Body-based routing (BBR): een aanvraagprocessor die een openAI-compatibele aanvraagbody kan inspecteren, de modelnaam kan extraheren en deze beschikbaar kan maken voor de gateway als header X-Gateway-Model-Name voor modelbewuste routering.

Application Gateway for Containers voert de BBR-processor uit als beheerd onderdeel van de gateway, zodat er geen afzonderlijke routeringslaag op basis van de aanvraagbody hoeft te worden uitgerold, geschaald of gepatcht. Het integreert met een door de klant geleverde EPP ter ondersteuning van routeringsbeslissingen op het moment van de aanvraag. De inferencegateway ondersteunt de Gateway API Inference Extension API, zodat u deze mogelijkheden via standaard-Gateway API-resources configureert en platformteams een Kubernetes-native API-model voor inferentieverkeer kunnen gebruiken in plaats van een afzonderlijk ingress-configuratiemodel te introduceren.

Hoe Application Gateway for Containers inferencebronnen gebruikt

Application Gateway for Containers blijft standaard gateway-API-resources gebruiken voor de configuratie van inkomend verkeer. Inferentiegedrag wordt geactiveerd wanneer een HTTPRoute backendreferentie verwijst naar een InferencePool in plaats van een Kubernetes Service.

Voor niet-inferentieroutes behoudt Application Gateway for Containers het bestaande gedrag van de Gateway API. Routes die zijn gericht op Kubernetes-back-ends Service , roepen geen deductieprocessors aan en ontvangen geen deductiespecifiek routeringsgedrag.

Voor inferentieroutes stemt het besturingsvlak de Gateway API en inferentiebronnen op elkaar af en programmeert het het gegevensvlak, zodat:

• De HTTPRoute selecteert de InferencePool backend.
• De InferencePool selecteert de pods van de modelserver die bij de pool horen.
• De EPP die aan de pool is gekoppeld, wordt gebruikt om het eindpunt te selecteren.
• Het geselecteerde eindpunt van de modelserver ontvangt de aanvraag.
• Optionele modelbewuste routering maakt gebruik van de naam van het aanvraagmodel dat is geëxtraheerd door BBR.

Aanvraagstroom

Een typische deductieaanvraag volgt dit pad. De genummerde stappen komen overeen met de labels in het volgende diagram:

1. Clientaanvraag: een client verzendt een openAI-compatibele aanvraag naar de front-end van Application Gateway for Containers en de gatewaylistener accepteert deze.
2. Body-based routing (BBR): Voor modelbewuste routes inspecteert de beheerde BBR-processor de aanvraagbody, extraheert de modelnaam en injecteert de X-Gateway-Model-Name header. De HTTPRoute kan vervolgens op basis van die waarde de juiste InferencePool selecteren.
3. Eindpuntselectie: Wanneer de overeenkomende route is gericht op een InferencePool, roept Application Gateway for Containers de EPP aan, die de telemetrie van de aanvraag- en modelserver evalueert en het geselecteerde eindpunt retourneert.
4. Route naar de InferencePool: Application Gateway for Containers stuurt de aanvraag door naar de geselecteerde modelserverpod en het antwoord van de modelserver keert terug naar de client via de gateway.

Routeringsmogelijkheden

De inferentiegateway ondersteunt deze routeringspatronen voor zelfgehoste AI-workloads. Eindpuntselectie wordt uitgevoerd in de EPP, dus het laadbewuste en cachebewuste gedrag is afhankelijk van de scorer-invoegtoepassingen die uw EPP inschakelt.

• Modelbewuste routering: Routeaanvragen op basis van de modelnaam in met OpenAI compatibele aanvraagbody's, die door de beheerde BBR-processor worden geëxtraheerd.
• Verkeer splitsen en implementeren: gebruik standaardgewogen HTTPRoutebackendRefs om verkeer over InferencePool back-ends te splitsen voor kanarie- of blauwgroene model-implementaties.
• Taakbewuste en cachebewuste eindpuntselectie: de EPP-scores voor eindpunten met behulp van modelservertelemetrie, zoals wachtrijdiepte en KV-cachegebruik. Wanneer de EPP prefix-cachebewuste scoring inschakelt, gaan verzoeken die een promptprefix delen naar dezelfde replica om het aantal cachehits te verhogen en de TTFT te verlagen.
• Prioriteits- en overbelastingsbeveiliging aanvragen: gebruik InferenceObjective resources en de x-gateway-inference-objective aanvraagheader om de prioriteit van de dienst toe te wijzen. Wanneer modelservers verzadigd zijn, wijst de EPP eerst aanvragen met een lagere prioriteit af om latentie-kritisch verkeer te beschermen.
• Tolerante eindpuntselectie: Configureer het gedrag van EVP-fouten met FailOpen of FailClose, afhankelijk van of beschikbaarheid of strikte eindpuntselectie belangrijker is voor een pool.
• Gateway-API-compatibiliteit: Ga door met het gebruik van gateway, HTTPRoute, ReferenceGrant en standaardstatusvoorwaarden voor gateway-API's voor de configuratie van inkomend verkeer.

Beveiligde deductie

Houd modelservers privé achter de beheerde gateway en pas de beveiligingsmogelijkheden van het platform toe op deductieverkeer.

• Web application firewall (WAF): de inferentiegateway werkt naadloos samen met de bestaande WAF-functie in Application Gateway for Containers, waarbij op OWASP afgestemde beveiliging wordt toegepast op AI-verkeer voordat aanvragen uw modelservers bereiken.
• Bescherming voor kostbare back-ends: omdat het beleid aan de beheerde edge wordt gehandhaafd, kunnen onjuiste of kwaadaardige verzoeken worden geïnspecteerd en geblokkeerd voordat ze schaarse GPU-capaciteit verbruiken.

Voorbeeldscenario's

In de volgende scenario's ziet u veelvoorkomende manieren om de deductiegateway te gebruiken:

• Modelversies leveren en implementeren: OpenAI-compatibele aanvragen routeren naar een InferencePool modelnaam en vervolgens gewogen HTTPRoute backendRefs gebruiken om een percentage verkeer te verplaatsen naar een nieuwe modelversie voor canary-tests voordat u de implementatie voltooit.
• Prioriteit geven aan latentiekritisch verkeer: Resources definiëren InferenceObjective voor workloads met hoge prioriteit en lage prioriteit in een gedeelde pool. Interactieve chatverzoeken hebben de hoogste prioriteit, terwijl batchtaken een lagere prioriteit gebruiken die als eerste wegvalt wanneer de pool verzadigd raakt.

InferencePool vergeleken met Service

Een Kubernetes Service blijft de juiste back-endabstractie voor standaardtoepassingsverkeer. Gebruik een InferencePool wanneer de back-end een groep modelserverpods is die deductiespecifieke eindpuntselectie nodig hebben.

Een InferencePool bevat een podselector, doelpoortinformatie en een verwijzing naar een eindpuntkiezer. De EPP is verantwoordelijk voor het selecteren van het eindpunt voor een aanvraag. Eén EVP is gekoppeld aan één groep.

Foutgedrag

Inferentie-routering vindt plaats tijdens de aanvraag, dus de faalmodus van de endpointkiezer is belangrijk.

InferencePool Verwijzingen naar de eindpuntkiezer ondersteunen deze foutmodi:

• FailOpen: Als de EVP niet beschikbaar is of niet reageert, kan de gateway doorgaan met de standaardeindpuntselectie voor de pool. Deze keuze behoudt de beschikbaarheid, maar kan de routeringskwaliteit verminderen.
• FailClose: Als de EPP niet beschikbaar is of niet reageert, weigert de gateway het verzoek. Met deze keuze voorkomt u dat verkeer wordt verzonden zonder de vereiste beslissing voor eindpuntselectie.

Voor modelbewuste routering die afhankelijk is van het parseren van de aanvraaginhoud kiest Application Gateway voor Containers voor correctheid. Als de modelnaam niet kan worden geëxtraheerd voor een route waarvoor BBR is vereist, wordt het verzoek afgewezen in plaats van zonder waarschuwing naar de verkeerde modelbackend te worden doorgestuurd.

Operationele overwegingen

Houd rekening met de volgende overwegingen bij het uitvoeren van inferentieworkloads achter Application Gateway for Containers:

• EPP-capaciteit: De EPP bevindt zich op het verzoekpad voor InferencePool backends. Dimensioneer en monitor het als een bedrijfskritische applicatiecomponent.
• Modelservertelemetrie: De EPP heeft nieuwe metrische gegevens van modelservers nodig om beslissingen te nemen over routering van hoge kwaliteit. Controleer of uw modelserver de metrische gegevens ondersteunt die worden verwacht door uw EPP-configuratie.
• GPU-capaciteit en -planning: voor modelserverpods zijn vaak GPU-knooppuntgroepen, apparaatinvoegtoepassingen en modeldownloadreferenties vereist.
• Automatisch schalen: schaal modelserver-pods op basis van inferentiesignalen zoals wachtrijlengte en KV-cachegebruik met behulp van de Horizontal Pod Autoscaler of KEDA. Automatisch schalen voegt capaciteit toe naarmate de vraag toeneemt, terwijl de EPP het verkeer om replica's heen leidt die al verzadigd zijn.
• Streaming-reacties: Veel chatvoltooiingsworkloads maken gebruik van server-sent events. Valideer het streaminggedrag bij het testen van end-to-end latentie- en time-outinstellingen.
• Observeerbaarheid: Bewaak de status van Gateway en HTTPRoute, de status van InferencePool, de gezondheid van EPP, de gereedheid van de modelserver en modelservermetrics, zoals actieve verzoeken en wachtrijlengte.

Limitations

De inferentiegateway richt zich op zelfgehoste inferentieworkloads die op Kubernetes draaien. Routering rechtstreeks naar eindpunten van openbare of beheerde modelproviders valt buiten het bereik van deze integratie.

De gateway-API-deductieextensie ontwikkelt zich onafhankelijk van Application Gateway for Containers. Gebruik API-versies en -manifesten die overeenkomen met de deductieextensie CRD's die op uw cluster zijn geïnstalleerd.

Volgende stappen 

• Configureren van Application Gateway for Containers-inferentiegateway
• Application Gateway for Containers-onderdelen
• Documentatie van de Gateway API-inferentie-extensie