QoS och rättvisa för delade on-premises GPU-inferenskluster

Varför delade GPU:er kräver uttrycklig kvalitetstjänstdesign

När en organisation centraliserar on-premises inferens är den enkla delen att installera servrar. Den svåra delen är att upprätthålla förtroende mellan team när latenstoppar i en arbetslast svälter en annan, eller när ett batchanalysjobb konsumerar så mycket minne att interaktiva chattsessioner faller. Till skillnad från generisk Kubernetes-CPU-trottling exponerar GPU-delning skarpa felmoder: out-of-memory-avslut, head-of-line-blocking i inferensservrar och otydliga ködjup som ser bra ut tills demodagen.

Kvalitetstjänst för GPU-inferens är därför en produkt av schemaläggningspolicy, serverkonfiguration och organisatoriska avtal uttryckta som kod. Utan den trion blir ”delat kluster” snabbt ”delad skuld”.

Partitionsstrategier: från hård isolering till viktad delning

Den starkaste isoleringen är dedikerad hårdvara per kritisk tjänsteklass. Det krockar med kostnadsmål, så plattformar kombinerar ofta fysiska pooler med logisk separation. NVIDIA Multi-Instance GPU (MIG), när det finns på understödda acceleratorer, delar ett kort i mindre profiler med begränsat minne och beräkning. Där MIG inte är ett alternativ minskar separata inferensserverinstanser per nivå på samma värd fortfarande korsverkan jämfört med en enda monolitisk process med en kö.

Svagare men vanliga mönster inkluderar flera distributioner bakom en lastbalanserare med separata Kubernetes-prioritetsklasser och resurskvoter. De hjälper Kubernetes-placering men översätts inte automatiskt till rättvis GPU-tid i en långlivad inferensarbetare. Ni behöver fortfarande begäranden på applikationsnivå—interaktiv, standardbatch och opportunistisk—med uttryckliga gränser för hur många samtidiga batchströmmar varje klass får uppta.

Köer, backtryck och användar synligt beteende

Rättvisa handlar inte bara om genomströmning utan om vad som händer när efterfrågan överstiger kapacitet. Definiera beteenden i förväg: avbryter interaktiv trafik pågående batcharbete? Får klienter strukturerade 429-svar med exponentiell backoff, eller sitter de i en begränsad kö med deadlines? Strukturerade HTTP-fel slår tysta flersekundersstopp.

Inferensservrar som stödjer kontinuerlig batchning behöver trimparametrar för maximal batchstorlek, väntetid för att bilda en batch och evictionsregler när sekvenser oväntat växer. De knopparna bör skilja sig per tjänsteklass. En intern playbook som listar standardvärden per nivå—och vem som får ändra dem—förhindrar midnattändringar som hjälper ett team och överraskar ett annat.

Observabilitet som teknik och ekonomi kan dela

GPU-utnyttjandeprocent ensamt vilseleder: en upptagen GPU kan fortfarande ge usel svanslatens om batchar domineras av en tenant. Spåra signaler per tenant eller applikation som kötid före första token, batchformningstid, antal förhandsändringar och out-of-memory-händelser attribuerade till namnrymd eller API-nyckel. Exportera dessa till er befintliga Prometheus-liknande stack och koppla dem till chargeback- eller showback-paneler där organisationen redan kör GPU-kvoter.

Para tekniska mätvärden med periodiska kapacitetsgranskningar som jämför tillväxtkurvor med anskaffningsledtider. QoS-policyer köper tid genom att jämna ut konkurrens men skapar inte kisel. Vid ihållande konkurrens är rätt utfall ofta budgetdialog, inte oändlig trimning.

När rättvisa brister: incidenthantering

När svanslatens toppar eller out-of-memory-händelser klumpar sig kring ett enda namnrymd eller API-nyckel, behandla situationen som en kapacitets- och tenantincident, inte bara ett applikationsfel. Runbooks bör dokumentera vem som tillfälligt får gasa ned vilken tenantklass, hur en nod töms utan att släppa långlivade sessioner i möjligaste mån, och hur interna konsumenter informeras om försämrad tjänsteklass. Efter händelser: fråga om felmoder redan syntes i befintliga mätvärden; om inte, lägg till en signal i stället för ytterligare informell regel.

Korrelera inferensmätvärden med uppströmsberoenden—hämtningslatens, autentisering och feature stores—så GPU-köer inte får skulden för problem med rötterna någon annanstans. Målet är återhämtning som går att upprepa: samma jourtekniker klockan tre på natten använder samma dokumenterade spakar som under kontorstid.

Styrning: SLO:er, avtal och eskalering

Dokumentera servicenivåmål per nivå: till exempel interaktiva arbetslaster med bundna latenspercentiler under kontorstid medan batchjobb accepterar nattfönster. Gör dessa SLO:er synliga för produktägare som registrerar konsumenter. När konflikter uppstår—två ”interaktiva” team under samma lansering—ska eskalationsvägar leda till en plattformsstyrningsforum med mandat att omprioritera eller tillfälligt avdela hårdvara.

Automatisering hjälper. Git-hanterade policyer för hastighetsgränser, namnrymdskvoter och ingressprioriteringar låter ändringar granskas. Undvik ad hoc kubectl-justeringar som fixar en demo men lämnar inget revisionsspår.

Sammanfattning

Delade on-premises GPU-kluster misslyckas socialt innan de misslyckas tekniskt. Investera tidigt i isoleringsmekanismer som matchar er risk, köpolicyer som misslyckas synligt, mätvärden som exponerar tenant-upplevelse och styrning som kopplar SLO:er till finansieringsbeslut. Resultatet är en plattform där team argumenterar i data i stället för anekdoter—och där inferenskapacitet känns förutsägbar även när den är fullt prenumererad.

Utvald bild av Avi Waxman på Unsplash.