Hastighetsbegränsning och mottryck för lokala AI-API:er

Varför AI-API:er behöver annorlunda skyddsstrategier

Traditionell API-hastighetsbegränsning är välförstått för webbtjänster: sätt ett tak för förfrågningar per sekund, returnera HTTP 429 när det överskrids och låt klienter försöka igen. Men lokala AI-inferens-API:er har egenskaper som gör standardhastighetsbegränsning otillräcklig och ibland kontraproduktiv.

AI-inferensförfrågningar är inte enhetliga i kostnad. En förfrågan som genererar 50 tokens förbrukar en bråkdel av den GPU-tid och det minne som en generering av 4 000 tokens kräver. Hastighetsbegränsning baserad enbart på antal förfrågningar tillåter ett litet antal dyra förfrågningar att svälta din GPU medan hastighetsbegränsaren rapporterar utrymme. Omvänt kan en burst av billiga klassificeringsförfrågningar utlösa hastighetsgränser trots att GPU:n är underutnyttjad.

GPU-resurser misslyckas också annorlunda än CPU-bundna tjänster. När en webbserver är överbelastad ökar svarstiderna gradvis. När en GPU får slut på minne under inferens kraschar processen eller förfrågan misslyckas helt med ett minnesfel. Det finns ingen gradvis degraderingskurva; istället finns det en klippa. Detta gör proaktivt skydd genom mottryck och lastavlastning nödvändigt snarare än valfritt.

Tokenmedveten hastighetsbegränsning

Den mest effektiva hastighetsbegränsningsstrategin för AI-API:er använder tokenbudgetar istället för antal förfrågningar. Varje konsument (team, applikation eller API-nyckel) får en tilldelning definierad i tokens per minut eller tokens per timme, som täcker både in- och ut-tokens.

Att implementera tokenmedveten hastighetsbegränsning kräver att man uppskattar kostnaden för en förfrågan innan den körs. För in-tokens är detta enkelt: tokenisera inmatningsprompten och räkna. För ut-tokens behöver du använda parametern max_tokens från förfrågan som reservation. När svaret är klart, stäm av reservationen mot faktisk användning och returnera oanvända tokens till budgeten.

En praktisk implementation använder en glidande fönster-tokenräknare per konsument. När en förfrågan anländer, kontrollera om konsumentens återstående tokenbudget kan rymma den uppskattade kostnaden. Om ja, dra av de uppskattade tokens och bearbeta förfrågan. Om nej, returnera ett hastighetsbegränsningsfel som inkluderar återställningstid och återstående budget.

Sätt tokenbudgetar baserade på din GPU-kapacitet. Om ditt inferenskluster kan upprätthålla 50 000 tokens per minut över alla konsumenter, allokera budgetar som summerar till 70-80% av den kapaciteten för att lämna marginal.

Implementera mottrycksmekanismer

Mottryck är praxis att signalera uppströms anropare att sakta ner när systemet närmar sig kapacitet. Till skillnad från hastighetsbegränsning, som tillämpar hårda gränser, ger mottryck graderade signaler som låter anropare justera sitt beteende innan de når gränser.

Den enklaste mottrycksmekanismen är ködjupövervakning. De flesta inferensservrar (vLLM, TGI, Triton) upprätthåller en intern förfrågningskö. Exponera aktuellt ködjup som ett mätvärde och inkludera det i API-svarsrubriker. Klienter som observerar ökande ködjup kan proaktivt minska sin förfrågningsfrekvens utan att vänta på hastighetsbegränsningsfel.

En mer sofistikerad ansats använder adaptiva samtidighetsgränser. Istället för en fast hastighetsgräns, justera dynamiskt antalet tillåtna samtidiga förfrågningar baserat på observerad latens. TCP Vegas-algoritmen erbjuder en bra modell: när latensen ökar, minska samtidighetsgränsen; när latensen är stabil, öka den gradvis.

För multimodell-distributioner, implementera mottryck per modell. En enda överbelastad modell ska inte orsaka mottryck på orelaterade modeller som delar samma API-gateway. Spåra ködjup och latens per modellendpoint och tillämpa mottryckssignaler oberoende.

Lastavlastning för GPU-skydd

Lastavlastning är medveten avvisning av förfrågningar för att skydda systemstabiliteten när mottryck ensamt inte räcker. För GPU-bundna AI-arbetsbelastningar är lastavlastning din sista försvarslinje mot minnesfel och kaskadande haverier.

Designa ett prioritetssystem i nivåer för dina AI-förfrågningar. Inte alla förfrågningar bär samma affärsvärde. En kundriktad chatbotförfrågan har typiskt högre prioritet än ett internt batchanalysjobb. Tilldela prioritetsnivåer på API-nyckel- eller konsumentnivå, och när GPU-minne eller beräkningsutnyttjande överskrider en tröskel (typiskt 85-90%), börja avlasta lägre prioriterade förfrågningar först.

Implementera GPU-minnesmedveten antagningskontroll. Innan du accepterar en ny inferensförfrågan, kontrollera aktuell GPU-minnesanvändning. Om det uppskattade minnesbehovet för den nya förfrågan skulle trycka utnyttjandet över din säkerhetströskel, avvisa förfrågan omedelbart istället för att riskera ett minnesfel som kan påverka alla pågående förfrågningar.

Vid lastavlastning, tillhandahåll handlingsbara felsvar. Inkludera orsaken (minnestryck, beräkningsmättnad eller kööverskridning), uppskattad tid tills kapacitet finns tillgänglig och huruvida förfrågan bör göras om eller omdirigeras.

Kostnadsberäkning och rättvis schemaläggning

Rättvis schemaläggning säkerställer att ingen enskild konsument kan monopolisera GPU-resurser på andras bekostnad. Detta är särskilt viktigt i multitenanta lokala distributioner där flera team delar samma inferensinfrastruktur.

Implementera en viktad rättvis kö vid inferensgateway:n. Varje konsuments förfrågningar går in i en separat kö, och schemaläggaren väljer nästa förfrågan att bearbeta baserat på varje konsuments vikt och senaste användning. Konsumenter som har använt mindre än sin rättvisa andel får prioritet; konsumenter som har överskridit sin andel nedprioriteras men blockeras inte.

Ta hänsyn till den faktiska kostnaden för förfrågningar i rättviseberäkningen. En konsument som skickar en förfrågan som kräver 10 000 ut-tokens bör inte behandlas likadant som en konsument som skickade 100 förfrågningar med 100 tokens vardera. Långvariga förfrågningar binder GPU-minne under hela genereringstiden.

Publicera en kostnadsmodell till dina API-konsumenter så att de kan förutsäga och optimera sin användning. Kostnadsmodellen bör uttrycka de GPU-sekunder som förbrukas per förfrågan som en funktion av inmatningslängd, utmatningslängd och modellstorlek.

Övervakning och optimering av ditt skyddslager

Hastighetsbegränsning och mottryckskonfigurationer är inte ställ-och-glöm. De kräver löpande övervakning och justering allteftersom dina arbetsbelastningsmönster utvecklas. Bygg instrumentpaneler som spårar viktiga skyddsmätvärden: hastighetsbegränsningsträffar per konsument, ködjupstrender, lastavlastningsfrekvens och gapet mellan allokerad och faktisk tokenanvändning.

En hög hastighetsbegränsningsträfffrekvens för en specifik konsument kan indikera att deras tilldelning är för låg för legitimt bruk, eller det kan indikera en okontrollerad process som genererar överdrivet antal förfrågningar. Undersök innan du justerar gränser.

Övervaka lastavlastningshändelser som kapacitetsplaneringssignaler. Om ditt system avlastar under förutsägbara rusningstimmar kan du behöva ytterligare GPU-kapacitet eller bättre trafikstyrning.

Testa dina skyddsmekanismer under kontrollerade förhållanden. Kör belastningstester som medvetet överskrider dina hastighetsgränser och utlöser mottryck för att verifiera att systemet beter sig som designat. Bekräfta att lastavlastning aktiveras vid rätt tröskelvärden och att högprioriterade förfrågningar fortsätter att servas när lägre prioriterad trafik avlastas.

Utvald bild av Daniel Julio på Unsplash.