Fyra arbetslaster på samma GPU-server
Broadcom publicerade den 21 september den första delen i en serie om optimering av AI-miljöer på VMware Cloud Foundation. Den nya delen fokuserar på multi-tenancy och jämför två sätt att isolera flera lätta inferensarbetslaster: separata virtuella maskiner för varje tenant respektive flera containeriserade tenants i en gemensam virtuell maskin.
Testet använde en Dell PowerEdge XE7745 med två AMD EPYC 9555-processorer, 768 GB minne och fyra NVIDIA RTX Pro 6000-GPU:er med 96 GB minne vardera. Varje arbetslast körde Llama 3.1 8B genom MLPerf Inference med 35 inferensfrågor per sekund. Leverantörens syfte var att efterlikna lätta arbetslaster som lämnar mycket GPU-kapacitet oanvänd när de får en hel server själva.
När antalet samtidiga arbetslaster ökades från en till fyra steg den sammanlagda uppmätta genomströmningen från omkring 4 500 till omkring 18 000 token per sekund. GPU:ernas Streaming Multiprocessor-utnyttjande ökade samtidigt från cirka 36–38 procent till 71 procent. Detta är mätresultat från Broadcoms egen testmiljö och inte en garanti för andra modeller eller produktionslaster.
Separata VM:ar gav nästan samma prestanda
Den mest praktiskt intressanta jämförelsen gäller isoleringsgränsen. I den ena modellen låg alla tenant-arbetslaster som containers i samma virtuella maskin. I den andra fick varje tenant en separat VM. GPU:erna tilldelades genom antingen passthrough eller NVIDIA vGPU. Broadcom rapporterar nästan ingen skillnad i genomströmning mellan modellerna i den testade inferenslasten.
Resultatet talar för att starkare VM-baserad separation inte nödvändigtvis behöver innebära ett stort prestandastraff för just denna typ av lätt, parallell LLM-inferens. Det betyder däremot inte att modellerna är utbytbara. En gemensam VM delar operativsystem, kernel och större del av runtime-stacken. Separata VM:ar ger tydligare fel-, patch- och säkerhetsdomäner men kräver mer livscykelhantering.
VCF Automation stöder enligt Broadcom att varje tenant placeras i en separat VM. Om flera tenants ska dela samma VM måste tenancy i stället hanteras manuellt. Den begränsningen påverkar driftmodellen: hög densitet i en delad VM kan minska antalet objekt, men flyttar ansvar för isolering, kvoter och automatisering närmare containerplattformen.
Certifieringen täcker inte alla vGPU-scenarier
VMware vSphere 9.1 finns med i NVIDIA:s program för certifierade hypervisorer. NVIDIA beskriver programmet som validering av GPU-topologi, data-path locality, GPU-till-NIC-kommunikation, RDMA och representativa AI-arbetslaster. Certifieringen är ett relevant stöd för arkitekturbeslut, men dess exakta omfattning behöver läsas noggrant.
NVIDIA:s aktuella dokumentation anger att x86-spåret i certifieringen använder full GPU-passthrough med en 8-GPU-VM på en Hopper-baserad nod och två sådana VM:ar över två noder. Dokumentationen säger samtidigt att vGPU för compute, inklusive fraktionerad GPU, är möjlig framtida certifieringsomfattning och inte ingår i den nuvarande certifieringen.
Det är därför viktigt att inte tolka märkningen som att varje kombination av vSphere, GPU, server, vGPU-profil och gästkonfiguration är certifierad. Certifieringen gäller den specificerade partnerstacken och de validerade konfigurationerna. Broadcoms nya RTX Pro 6000-test ger separat prestandaevidens, men utökar inte automatiskt NVIDIA-certifieringens formella scope.
Vad resultatet betyder för kapacitetsplanering
Det tydligaste budskapet är att låg GPU-belastning bör mätas som ett konsolideringsproblem innan fler acceleratorer köps in. En ensam modellserver kan se snabb ut men ändå använda en dyr GPU dåligt när frågefrekvensen är låg. Genom att kombinera flera tenants eller tjänster kan samma hårdvara leverera högre total nytta.
Kapacitetsplaneringen bör börja med token per sekund, kötid, tid till första token, percentillatenser, GPU-minne och Streaming Multiprocessor-utnyttjande. Genomsnittlig GPU-belastning räcker inte: en arbetslast kan vara lätt större delen av tiden men skapa korta toppar som påverkar alla andra tenants på samma server.
Repetera därför testet med verkliga modellstorlekar, kvantisering, kontextlängder, batchning och samtidighetsnivåer. Lägg till störningstester där en tenant överbelastar inferensmotorn eller fyller GPU-minnet. Kontrollera att kvoter och schemaläggning begränsar påverkan på andra kunder och att övervakningen visar vilken tenant som orsakar trycket.
Säkerhet och drift väger tyngre än sista procenten
Valet mellan delad VM och separata VM:ar bör inte avgöras enbart av den uppmätta genomströmningen. Reglerade data, externa kunder och arbetslaster med olika administratörer talar för separata VM-gränser. Interna projekt med gemensamt förtroende och en mogen containerplattform kan ibland prioritera en gemensam VM för enklare konsolidering.
Oavsett modell behövs separata identiteter, nätverkspolicyer, loggning, hemlighetshantering och resurskvoter. GPU-fel och drivrutinsuppgraderingar måste dessutom ingå i fel- och underhållstester. En arkitektur som presterar bra under ett kort benchmark kan ändå ge dålig tillgänglighet om alla tenants påverkas av samma omstart eller drivrutinskrasch.
Planera även licenserna. NVIDIA anger att GPU-passthrough inte kräver NVIDIA AI Enterprise-licens inom certifieringsprogrammets modell, medan NVIDIA vGPU for Compute kräver den. VMware- och plattformslicenser hanteras separat. Den ekonomiska jämförelsen måste därför omfatta både hårdvara, mjukvarulicenser och den operativa kostnaden för vald isoleringsmodell.
Rekommenderad provordning
Börja med en ensam representativ arbetslast och mät prestanda, latenser och resursutnyttjande. Lägg sedan till tenants en i taget tills antingen GPU, minne, CPU, nätverk eller latenstak blir begränsande. Kör samma test i gemensam VM och separata VM:ar med identiska modell- och runtime-versioner.
Efter kapacitetstestet ska säkerhets- och feltålighetsproven genomföras. Testa resursmissbruk, drivrutinsfel, VM-omstart, hostunderhåll och återställning. Dokumentera vilken arkitektur som uppfyller verksamhetens isoleringskrav och jämför därefter kostnad per levererad token vid realistisk belastning.
LabOps IT:s bedömning
Vår bedömning är att testet ger användbar evidens för att VM-baserad tenantisolering kan kombineras med hög GPU-densitet utan tydligt genomströmningsstraff i en avgränsad LLM-last. Den största vinsten kommer dock inte från hypervisorn i sig, utan från att flera underutnyttjade tjänster kan dela samma dyra acceleratorer.
Siffrorna bör behandlas som en hypotes för lokal verifiering, inte som en dimensioneringsmall. Testet omfattar en server, en modell, en frågefrekvens och specifik hårdvara. Produktionsbeslut kräver mätning av toppar, latenser, minnestryck, felisolering och licenskostnad. Prioriteten är därför planerad: använd resultaten för att designa ett eget pilotprov innan inköp eller bred konsolidering.