GPU-virtualisering för Delad Lokal AI-infrastruktur

GPU-användningsproblemet i företags-AI

De flesta lokala GPU-kluster i företag opererar med förvånansvärt låg genomsnittlig användning. Enskilda team begär dedikerade GPU:er för sina arbetsbelastningar, dessa GPU:er står inaktiva mellan inferenstoppar eller träningskörningar, och organisationen betalar för dyr hårdvara som tillbringar det mesta av sin tid med att göra ingenting. Användningsgrader på 15-30% är vanliga i miljöer utan virtualisering.

GPU-virtualisering löser detta genom att tillåta flera arbetsbelastningar att dela en enda fysisk GPU säkert, med isoleringsgarantier som förhindrar att ett teams arbetsbelastning påverkar ett annats prestanda eller kommer åt deras minnesområde. Teknologin har mognat avsevärt och moderna NVIDIA GPU:er erbjuder flera tillvägagångssätt beroende på dina isoleringskrav, arbetsbelastningsegenskaper och hårdvarugeneration.

Att välja rätt virtualiseringsstrategi kräver förståelse för avvägningarna mellan isoleringsstyrka, schemaläggningsflexibilitet och prestandaoverhead. Det finns inget enskilt bästa tillvägagångssätt; de flesta produktionsmiljöer använder en kombination av tekniker matchade mot olika arbetsbelastningstyper.

Multi-Instance GPU (MIG): Partitionering på hårdvarunivå

Multi-Instance GPU, tillgänglig på NVIDIA A100, A30, H100 och nyare arkitekturer, partitionerar en enda fysisk GPU i upp till sju oberoende instanser på hårdvarunivå. Varje instans får dedikerade beräkningsenheter, minnesbandbredd och L2-cache. Ett fel i en instans kan inte påverka en annan eftersom isoleringen upprätthålls av GPU-hårdvaran själv.

MIG är idealt för inferensarbetsbelastningar som behöver garanterad prestanda men inte kräver en hel GPU. En enda H100 kan partitioneras för att betjäna sju olika modeller samtidigt, var och en med förutsägbara latensegenskaper som inte påverkas av vad de andra partitionerna gör. Detta gör MIG väl lämpat för SLA-bunden produktionsinferens där latenskonsistens är viktigare än rå genomströmning.

Avvägningen är rigiditet. MIG-partitioner måste konfigureras statiskt och kan inte storleksändras utan att stoppa alla arbetsbelastningar på GPU:n. Partitionsstorlekarna följer fasta profiler (1g, 2g, 3g, 4g, 7g på H100), så du kan inte skapa godtyckliga uppdelningar. Att planera MIG-allokeringar kräver att du förstår dina arbetsbelastningars minnes- och beräkningskrav i förväg.

I praktiken, konfigurera MIG-profiler under underhållsfönster baserat på arbetsbelastningsefterfrågmönster från föregående period. Reservera större profiler (3g eller 4g) för latenskänsliga produktionsmodeller och använd mindre profiler (1g eller 2g) för utveckling, testning eller lågtrafikinterna tjänster.

vGPU: Hypervisorförmedlad delning

NVIDIA vGPU (Virtual GPU) använder ett hypervisorlager för att presentera virtuella GPU-enheter för virtuella maskiner. Varje VM ser vad som verkar vara en dedikerad GPU, men den fysiska GPU:n delas över flera VM:ar genom tidsmultiplexing som hanteras av NVIDIA vGPU-mjukvaran.

vGPU:s primära fördel är integration med befintlig virtualiseringsinfrastruktur. Om din organisation redan kör VMware vSphere, KVM eller Citrix Hypervisor utökar vGPU samma hanteringsparadigm till GPU-resurser. IT-team kan allokera GPU-kapacitet genom välbekanta verktyg, tillämpa samma säkerhetspolicyer och hantera GPU-resurser tillsammans med CPU och minne i enhetlig orkestrering.

Overheaden är mätbar: förvänta dig 5-15% prestandaminskning jämfört med bare-metal-åtkomst, beroende på arbetsbelastningsegenskaper och konkurrensnivåer. För inferensarbetsbelastningar är denna overhead vanligtvis acceptabel. För storskaliga träningskörningar som behöver varje tillgänglig FLOP tillför vGPU kostnad utan proportionell nytta.

vGPU-licensiering tillför driftskostnad utöver hårdvaran. Inkludera detta i dina beräkningar av total ägandekostnad. För rena AI-inferenskluster kan MIG eller tidsdelning vara mer kostnadseffektivt. vGPU är mest meningsfullt när GPU-arbetsbelastningar samexisterar med traditionell virtualiserad infrastruktur och enhetlig hantering är en prioritet.

Tidsdelning: Kubernetes-nativ GPU-delning

Tidsdelning är den enklaste formen av GPU-delning och kräver inga speciella hårdvarufunktioner. NVIDIA device plugin för Kubernetes kan exponera en enda GPU som flera virtuella enheter, och GPU-schemaläggaren roterar mellan arbetsbelastningar med tidsmultiplexing. Varje arbetsbelastning får periodisk exklusiv åtkomst till hela GPU:n.

Tidsdelningens attraktionskraft är enkelhet och flexibilitet. Det fungerar på vilken NVIDIA GPU som helst, kräver bara en konfigurationsändring i device plugin och integreras nativt med Kubernetes-resursförfrågningar. Du kan överabonnera en GPU med vilken faktor som helst och låta tio eller tjugo poddar dela en enda enhet.

Den betydande nackdelen är frånvaron av minnesisolering. Alla arbetsbelastningar som delar en tidsdelad GPU delar samma minnesområde. En arbetsbelastning som allokerar överdrivet GPU-minne orsakar out-of-memory-fel för andra hyresgäster. Det finns heller ingen prestandaisolering: en beräkningsintensiv arbetsbelastning svälter andra arbetsbelastningar på tidsdelningar.

Tidsdelning fungerar bra för utvecklings- och testmiljöer där team behöver tillfällig GPU-åtkomst för experiment och konsekvenserna av interferens är låga. Det är inte lämpligt för produktionsinferens med SLA-krav. Kombinera tidsdelning med resurskvoter och övervakning för att upptäcka och avhysa arbetsbelastningar som konsumerar oproportionella resurser.

Att designa en flernivå-virtualiseringsstrategi

Produktionsmiljöer gynnas av att kombinera dessa tillvägagångssätt i en skiktad arkitektur. Nivå 1 använder MIG för produktionsinferensarbetsbelastningar med strikta latens-SLA:er. Nivå 2 använder vGPU eller MIG för staging och förproduktionsvalidering. Nivå 3 använder tidsdelning för utveckling, experiment och batchbearbetning.

Implementera detta genom Kubernetes-nodpooler eller etiketter. Tagga GPU-noder med deras virtualiseringsnivå och använd nodaffinitetsregler för att schemalägga arbetsbelastningar lämpligt. En produktionsinferensdriftsättning riktar sig mot MIG-partitionerade noder, medan en utvecklares notebook-server schemaläggs på tidsdelade noder.

Kapacitetsplanering förändras avsevärt med virtualisering. Istället för att räkna fysiska GPU:er, planera i termer av effektiva GPU-fraktioner tillgängliga per nivå. Ett kluster med åtta H100 GPU:er med MIG vid 4g-profiler ger 16 effektiva inferensplatser i Nivå 1. Samma åtta GPU:er tidsdelade med 4x överabonnemang ger 32 utvecklingsplatser i Nivå 3. Denna aritmetik driver hårdvaruupphandlingsbeslut.

Övervaka användning på partitionsnivå, inte fysisk GPU-nivå. En GPU som visar 60% total användning kan ha en MIG-partition på 95% och en annan på 25%. Partitionsnivåmätvärden driver ombalanseringsbeslut och avslöjar huruvida dina profiler matchar faktiska arbetsbelastningskrav.

Operativa överväganden och styrning

GPU-virtualisering introducerar styrningsutmaningar som måste hanteras genom policy och verktyg. Definiera en tydlig allokeringsmodell: vilka team som får garanterade MIG-partitioner, hur tidsdelningsprioriteter hanteras och vad som händer när efterfrågan överstiger kapaciteten.

Implementera ett begäranarbetsflöde där team deklarerar sina GPU-krav (minne, beräkning, isoleringsnivå, varaktighet) och ett plattformsteam eller automatiserat system matchar begäran till lämpliga virtualiseringsnivåer. Detta förhindrar det vanliga felfallet där varje team begär dedikerade GPU:er "för säkerhets skull" och användningen kollapsar.

Ställ in kostnadsåterföring eller kostnadsvisning baserad på faktisk förbrukning på partitionsnivå. När team ser kostnaden för sina reserverade MIG-partitioner jämfört med sin faktiska användning förändras beteendet. Inaktiva reservationer frigörs, batchjobb schemaläggs under lågtrafiktimmar och organisationen får mer värde från samma hårdvara.

Planera GPU-drivrutins- och firmwareuppdateringar noggrant. MIG-omkonfiguration kräver att alla partitioner på en GPU dräneras, och vGPU-uppdateringar kan kräva VM-migrering eller driftstopp. Bygg in dessa underhållsoperationer i din ändringshanteringsprocess och bibehåll tillräcklig reservkapacitet så att enskilda GPU:er kan tas offline utan tjänstepåverkan.

Featured image by Andrey Matveev on Unsplash.