Der er stadig plads til en AI-tjeneste på den eksisterende Proxmox-vært. Er det nok at montere et grafikkort og oprette en virtuel maskine? Det kan være fornuftigt, når GPU-tildeling, værtsressourcer og vedligeholdelse planlægges sammen.
Ved passthrough tilhører den fysiske GPU én VM
PCIe-passthrough giver en virtuel maskine kontrol over en fysisk enhed. AI-VM’en bruger GPU’en gennem sin egen gæstedriver. Under denne tildeling kan værten og andre VM’er ikke samtidig bruge samme kort til egne beregninger.
En fælles modeltjeneste i AI-VM’en kan behandle flere forespørgsler. Det er noget andet end at dele kortet mellem flere VM’er. Om en separat vGPU-løsning er egnet, afhænger også af GPU, hypervisor, drivere, understøttede konfigurationer og licenser.
En VM giver et klart afgrænset systemmiljø: operativsystem, modelserver og nødvendige data kan administreres sammen. GPU’en er stadig en fysisk enhed med egne forudsætninger.
Kontrollér hele hardwarekæden før montering
Proxmox-dokumentationen kræver IOMMU-understøttelse inklusive interrupt-remapping. CPU, bundkort, firmware og Linux-understøttelse skal passe sammen. Betegnelsen VT-d eller AMD-Vi alene erstatter ikke denne kontrol.
IOMMU-gruppen for den valgte slot er også relevant. GPU’en og dens tilknyttede funktioner skal være passende adskilt fra andre nødvendige enheder. Linux-VFIO-dokumentationen forklarer, hvorfor en gruppe udgør grænsen for tildeling og isolation. En anden slot kan give en anden gruppering.
Kontrollér også plads, elektrisk PCIe-forbindelse, strømforsyning og køling. I gæsten kræves en passende GPU-driver og understøttelse i modeltjenesten. Til GPU-passthrough anbefaler Proxmox normalt q35 med OVMF/UEFI og PCIe; kortets firmware skal også passe til det. De konkrete indstillinger afhænger af den anvendte hardware.
Eksisterende kapacitet er et fælles budget
Planlægningseksemplet tager udgangspunkt i en eksisterende virtualiseringsvært med virksomhedsprogrammer og en ekstra AI-VM. CPU-tid, RAM, lager og netværk forbliver fælles ressourcer. En ubegrænset dokumentimport eller modelstart må ikke uventet bremse de øvrige programmer.
VM’en får derfor en gennemskuelig konfiguration og belastningsgrænser. Grafikhukommelse, kontekstlængde og samtidige modelkald testes sammen. Mere RAM tildelt VM’en øger ikke kortets fysiske VRAM. CPU-offloading kan ændre adfærden og kræver en særskilt måling.
For en fair sammenligning registreres modelversion, input, kontekst og samtidighed. Kvalitet, første svar, efterfølgende output, ventetid og påvirkning af andre VM’er vurderes. En generel procentsats for virtualiseringens overhead ville være til ringe nytte uden denne konkrete test.
VM eller dedikeret maskine: hvad ændrer sig i driften?
| Spørgsmål | AI-VM med GPU-passthrough | Dedikeret AI-server |
|---|---|---|
| Ressourcer | GPU fast tildelt; afstem øvrige værtsressourcer med eksisterende VM’er. | Beregning og hukommelse er til rådighed for det egne system. |
| Vedligeholdelse | Planlæg gæstedrivere, modeldrift og Proxmox-/værtsopdateringer sammen. | Operativsystem og modeldrift i et separat vedligeholdelsesområde. |
| Skift af vært | Direkte videregivne PCI-enheder forhindrer almindelig live-migrering. Ved flytning af en stoppet VM kontrolleres passende målhardware og tildeling. | Flytning eller erstatning gennem forberedt genetablering på anden hardware. |
| Backup | Se VM-diske, applikationskonsistens, konfiguration og enhedstildeling samlet. | Organisér system-/applikationsdata og gendannelse særskilt. |
| Indsats | Eksisterende infrastruktur kan bruges; medregn integration og ekstra værtsafhængigheder. | Planlæg egen hardware og faciliteter på stedet, med tydeligere adskilt vedligeholdelse. |
En eksisterende klynge gør ikke automatisk en hardwarebundet AI-VM flytbar uden afbrydelse. Genstart på en anden node kræver kompatible GPU-ressourcer, en gyldig tildeling og en faktisk afprøvet procedure. Servicekravene afgør, om denne forberedelse er nok, eller om en yderligere tjenestenode er relevant.
En restore skal vise mere end en VM, der starter
En kopieret virtuel disk indeholder ikke den fysiske GPUs kørende tilstand. Ved gendannelse kontrolleres derfor også modelversioner, konfiguration, datarettigheder og fornyet enhedstildeling. Et snapshot på samme vært erstatter ikke en separat backup.
Accepttesten omfatter en normal VM-genstart, en værtsgenstart, et driver-/kernelskift i det planlagte vedligeholdelsesvindue og en planlagt restore. Derefter testes en rigtig modelforespørgsel og de øvrige programmer. Det viser, om enheden bliver korrekt tilgængelig igen efter genstart.
En GPU, der kun bruges som beregningsaccelerator, behøver ingen tilsluttet skærm. Proxmox-konsollen viser ikke blot billedet fra en GPU i passthrough. AI-tjenesten bruges gennem sin tiltænkte grænseflade eller API.
Underbyg beslutningen med en begrænset pilot
DAXS afklarer først opgave, eksisterende vært, anvendelsesomfang og acceptabel afbrydelse. En begrænset pilot tester derefter enhedstildeling, faglig kvalitet og driftsvirkning. En VM, en egen maskine eller en ekstern tjeneste kan være egnet afhængigt af resultatet.
Vores Proxmox-overblik for virksomheder forklarer det generelle platformvalg. Vores fagside om lokal LLM-infrastruktur og pilot med belastningstest uddyber dimensioneringen. Til den fælles tjeneste supplerer artiklen om Ollama og Open WebUI arkitekturen.
Drøft AI-driftsmodel og eksisterende infrastruktur.
Kilder: Proxmox: PCIe-passthrough (eksternt link) · Proxmox: migrering af virtuelle maskiner (eksternt link) · Linux: VFIO og IOMMU-grupper (eksternt link) · NVIDIA: vGPU-understøttelsesmatrix (eksternt link) · Ollama: hardwareunderstøttelse (eksternt link).
