GPU-chargeback och kvoter for delade on-prem AI-plattformar

Delade GPU-plattformar far problem nar kapaciteten ser gratis ut

On-prem AI startar ofta med en rimlig teknisk ambition: samla GPU-resurser pa en gemensam plattform sa att flera team kan dela samma infrastruktur. Sedan blir plattformen popular, koerna vaxer och varje grupp haller sina jobb for affarskritiska. Utan ett tydligt system for kvoter och chargeback vinner ofta de team som hors mest, medan viktiga arbetslaster far vanta. Det har ar inte bara ett schemalaggningsproblem. Det ar ett ekonomiproblem. Nar en knapp resurs uppfattas som gratis vaxer efterfragan snabbare an styrningen.

Molnleverantorer skapar delvis disciplin genom synlig fakturering. Interna AI-miljoer behover en motsvarande mekanism. Det betyder inte att man maste införa full internfakturering direkt. I manga organisationer ar showback ett battre forsta steg: visa vem som anvande vilka GPU-klasser, hur lange, med vilken prioritet och med vilket lagringsavtryck. Nar konsumtionen blir synlig uppfattas inte kvotbeslut som godtyckliga, och diskussionen om plattformen blir betydligt mer konkret.

Definiera tjansteklasser innan du satter priser

Manga kvotmodeller misslyckas eftersom de borjar i kostnadsformeln i stallet for i tjanstedesignen. Borja med att definiera tjansteklasser som speglar hur plattformen faktiskt anvands. Ett praktiskt upplagg ar tre nivaer. En interaktiv klass stoder notebooks, korta experiment och utvecklingsjobb. En batchklass stoder finjustering, embeddinggenerering, offline-utvardering och nattkorningar. En kritisk klass reserveras for produktionsinferens eller andra overenskomna affarsfonster med tydliga servicenivaer. Varje klass bor ha egna regler for maxkortid, ko-prioritet, preemption och tillatna GPU-typer.

Nar tjansteklasserna finns pa plats blir kvoter begripliga. Ett team kan tilldelas en manadsram for interaktiva A10- eller L40-noder, en separat batchkvot for delade H100-fonster och en liten reserverad kapacitet for produktion om de driver en verkligt kritisk tjanst. Det ar betydligt sundare an att ge alla tillgang till alla acceleratorer och hoppas att schemalaggaren ska skapa ordning. Plattformens policy bor uttryckas medvetet via namespaces, queue classes och admission controls.

Det maste ocksa vara tydligt vad som ar reserverad kapacitet och vad som ar burstkapacitet. Reserverad kapacitet ar det teamet faktiskt kan planera efter. Burstkapacitet ar opportunistisk och kan tas tillbaka. Om de blandas ihop uppstar snabbt konflikter eftersom anvandarna planerar mot resurser som aldrig varit garanterade.

Bygg chargeback runt forbrukningsenheter som teamen forstar

De mest anvandbara chargebackmodellerna ar inte de matematiskt perfekta, utan de som teknikledare kan resonera kring i vardagen. En stark grund ar en enkel modell baserad pa GPU-timmar per hardvaruklass, lagringskostnad for artefakter som sparas over tid och tillagg for reserverad kapacitet eller sarskilda driftfonster. Vissa verksamheter vill ocksa ta med kostnad for vektordatabaser, snabb lagring eller dedikerade inferensendpointar, men bara om dessa poster ar materiella och pa riktigt kan paverkas av det konsumerande teamet.

Det brukar fungera bra att publicera ett internt rate card med fa rader: pris per GPU-timme och klass, pris for reserverade slices per manad, kostnad for hogpresterande lagring och pris for garanterad produktionssupport. Aven om ekonomiavdelningen inte anvander talen for faktisk internfakturering direkt skapar de ett gemensamt sprak for arkitekturbeslut. Da blir det tydligt att en stor modell som star pa dygnet runt inte bara ar ett tekniskt val. Det ar ett budgetval som maste vagnas mot alternativ som mindre modeller, batchkorningar eller smart modellrouting.

Incitamenten bor ocksa styra mot god plattformshygien. Straffa inte korta experiment som avslutas korrekt. Straffa i stallet overdimensionerade reservationer, overgivna langkorningar och endpointar som star tomma men aldrig skalar ned. En bra chargebackmodell handlar mindre om att fordele skuld i efterhand och mer om att uppmuntra rationellt beteende i forvag.

Genomfor kvoter i schemalaggaren, inte i kalkylblad

Styrning blir verklig forst nar den kodas in i kontrollplanet. Pa Kubernetes-baserade plattformar betyder det ofta en kombination av resource quotas, priority classes och ko-utokningar som Kueue eller Volcano. I mer HPC-praglade miljoer ar Slurm fortfarande mycket starkt for att partitionera acceleratorkapacitet och tillampa fair-share-politik. Team som bygger distribuerad traning med Ray eller Kubeflow behover fortfarande ett underliggande schema som respekterar samma kvotregler, annars kommer undantagen snart att sprida sig genom hogre abstraheringslager.

Hardvarupartitionering gor ocksa skillnad. NVIDIA MIG ar anvandbart nar interaktiva jobb eller inferens inte behover hela GPU:n, medan hela enheter bor reserveras for arbetslaster som verkligen drar nytta av dem. Policyverktyg som OPA Gatekeeper eller Kyverno kan blockera otillatna GPU-klasser, for stora lagringsbegaran och obegransade kortider. Regler for att ta tillbaka tom kapacitet ar lika viktiga. Om en notebook eller endpoint ar inaktiv under en definierad tid bor plattformen kunna skala ned den automatiskt eller flytta den till en lagre prioriterad pool.

Det operativa malet ar enkelt: anvandarna ska kanna av plattformens regler redan nar jobbet skickas in, inte i efterhand pa ett manadsmote nar all kapacitet redan ar forbrukad.

Folj upp kvoter kvartalsvis och ha en tydlig vag for undantag

Ingen kvotmodell forblir korrekt for alltid. Nya anvandningsfall tillkommer, produktlanseringar skapar toppar och vissa team behover tillfallig extra kapacitet for migrering eller validering. Darfor bor kvotstyrning vara en lattviktig kvartalsprocess, inte ett beslut som spikas en gang om aret och sedan gloms bort. Granska faktisk nyttjandegrad, ko-tryck per tjansteklass, tomma reservationer och vilka arbetslaster som upprepade ganger overstiger sin grundtilldelning. De signalerna visar om problemet ligger i policy, prognos eller ren kapacitetsbrist.

Undantagshanteringen ska vara formell men snabb. En produktionsincident, en tillsynsgranskning eller en planerad fabriksutrullning kan motivera tillfallig prioritet, men kriterierna maste vara skrivna och tidsbegransade. Annars blir varje begaran bradskande per definition. Ofta racker ett enkelt undantagsunderlag: affarsorsak, onskad tidsperiod, berord GPU-klass, planerat slutdatum och ansvarig godkannare. Da bevaras flexibiliteten utan att rattvisan urholkas.

I on-prem AI ar chargeback och kvotdesign inte byrakrati ovanpa tekniken. Det ar en del av sjalva plattformsarkitekturen. Nar GPU-ekonomin ar synlig och genomforbar gor teamen battre modellval, routar arbetslaster smartare och sparar premiumhardvara till de jobb som faktiskt kraver den.

Featured image by Elimende Inagella on Unsplash.