Lokale KI mit vier NVIDIA-GPUs unter Hyper-V: Windows 11, DDA und Ollama Schritt für Schritt einrichten

Vier NVIDIA-GPUs im HP ML350 Gen9: Hardware und VRAM

Verbaut sind zwei NVIDIA Quadro M4000 mit jeweils 8 GB sowie zwei Quadro K2200 mit jeweils 4 GB. Das ergibt 24 GB physischen Grafikspeicher. Es handelt sich ausdrücklich nicht um vier M4000 mit 32 GB. Beide Kartentypen basieren auf der älteren Maxwell-Architektur und besitzen keine modernen Tensor Cores.

Die 24 GB bilden keinen zusammenhängenden Speicherblock. Die KI-Software verteilt Modellschichten auf die getrennten GPUs. Das ermöglicht grössere Modelle, garantiert aber keine vierfache Geschwindigkeit.

Voraussetzungen: Hyper-V, Stromversorgung und Treiber

Als Host dient in diesem Beispiel Windows Server 2025 Standard. Die virtuelle Maschine heisst Client-02, ist Generation 2 und verwendet Windows 11. Für die GPU-Durchreichung werden Administratorrechte auf dem Hyper-V-Host, unterstützte PCIe-Geräte, aktiviertes Intel VT-d beziehungsweise IOMMU und ausreichend reservierter PCIe-Adressraum benötigt. Wir gehen hier bewusst von einer DDA-fähigen, funktionierenden Hardwarekonfiguration aus und verzichten auf einen separaten Hardwaretest.

Vor dem Umbau sind Backup, korrekte Stromversorgung und Kühlung entscheidend. M4000 benötigen zusätzliche PCIe-Stromanschlüsse. Bei einem zweiten ATX-Netzteil muss die Einschaltung zuverlässig synchronisiert sein. Für Wartungsarbeiten sollte der Host über HPE iLO erreichbar bleiben.

Hyper-V-Hinweis: DDA übergibt eine ganze physische Karte exklusiv an die virtuelle Maschine. Die betreffende GPU steht dem Host danach nicht mehr zur Verfügung. Dynamischer VM-Arbeitsspeicher sowie bestimmte Migrations- und Speicherfunktionen sind mit dieser Konfiguration eingeschränkt. Die VM sollte deshalb vor dem Einrichten regulär heruntergefahren werden.

GPU-Passthrough mit Hyper-V DDA einfach einrichten

Für das Durchreichen ist kein zusätzlicher DDA-Installer nötig. Auf einem passenden Windows-Server-Host erledigt PowerShell die Zuweisung. Das folgende Beispiel übernimmt alle noch auf dem Host aktiven M4000- und K2200-Grafikkarten und hängt sie an Client-02. Bereits durchgereichte Karten sind in dieser Auswahl nicht mehr enthalten. Andere Hyper-V-VMs werden nicht verändert.

PowerShell-Befehl für die Zuweisung

Die Ziel-VM vorher sauber herunterfahren und den folgenden Block auf dem Hyper-V-Host als Administrator ausführen. Der Code setzt statischen RAM, konfiguriert die MMIO-Adressräume und übergibt die passenden PCIe-Geräte. -Force ist nur für eine vertrauenswürdige Konfiguration ohne Mitigation-Treiber vorgesehen, da damit die entsprechende DDA-Sicherheitswarnung umgangen wird.

# Auf dem Hyper-V-Host in PowerShell als Administrator ausführen.
$VM = 'Client-02'
$GPUNamen = @('NVIDIA Quadro M4000', 'NVIDIA Quadro K2200')
if ((Get-VM -Name $VM).State -ne 'Off') { throw 'VM zuerst herunterfahren.' }
Set-VMMemory -VMName $VM -DynamicMemoryEnabled $false
Set-VM -VMName $VM -AutomaticStopAction TurnOff `
    -GuestControlledCacheTypes $true -LowMemoryMappedIoSpace 3GB `
    -HighMemoryMappedIoSpace 64GB
$GPUs = @(Get-PnpDevice -PresentOnly -Class Display | Where-Object {
    $_.Status -eq 'OK' -and $_.FriendlyName -in $GPUNamen
})
foreach ($GPU in $GPUs) {
    $Pfad = (Get-PnpDeviceProperty -InstanceId $GPU.InstanceId `
        -KeyName 'DEVPKEY_Device_LocationPaths').Data[0]
    if (-not $Pfad) { throw "PCIe-Pfad fehlt: $($GPU.FriendlyName)" }
    Disable-PnpDevice -InstanceId $GPU.InstanceId -Confirm:$false
    Dismount-VMHostAssignableDevice -LocationPath $Pfad -Force
    Add-VMAssignableDevice -LocationPath $Pfad -VMName $VM
    Write-Host "Zugewiesen: $($GPU.FriendlyName)"
}
Get-VMAssignableDevice -VMName $VM

Der Wert 64GB ist hier eine grosszügige Beispielreservierung für den High-MMIO-Adressraum, keine zusätzliche RAM-Zuteilung. Je nach GPU-Modell und PCIe-Konfiguration kann ein anderer Wert nötig sein. Tritt während der Zuweisung ein Fehler auf, müssen die bereits übertragenen Geräte gegebenenfalls einzeln zurückgegeben werden.

Grafikkarten im Windows-11-Gast erkennen

Anschliessend Client-02 starten und in Windows 11 den passenden professionellen NVIDIA-Treiber installieren. Im Praxisbeispiel funktionierte Treiberversion 582.99. Danach zeigt der folgende Befehl alle an die VM übergebenen NVIDIA-Karten:

nvidia-smi -L

In der fertigen Umgebung erscheinen zweimal M4000 und zweimal K2200. Der erste Screenshot entstand noch nach der erfolgreichen Zuweisung einer einzelnen M4000; die späteren Messungen dokumentieren dann den Betrieb mit allen vier GPUs.

Ollama unter Windows 11 installieren und KI-Modell starten

Für die lokale Sprachverarbeitung eignet sich Ollama für Windows. Die Software übernimmt Modell-Downloads, den lokalen Inferenzserver und die automatische GPU-Verteilung. Mit den hier verwendeten älteren Maxwell-Karten ist der unterstützte NVIDIA-Treiber besonders wichtig. Nach der Ollama-Installation wird eine neue PowerShell geöffnet; ein zusätzliches CUDA Toolkit oder Visual Studio ist für die normale Nutzung von Ollama nicht erforderlich.

Qwen3 14B als Hauptmodell laden

Im gezeigten Aufbau wurde Qwen3 14B verwendet. Es bietet einen guten Kompromiss zwischen Sprachqualität, technischem Verständnis, Mehrsprachigkeit und Modellgrösse. Beim ersten Aufruf lädt Ollama die Modellgewichte automatisch herunter; spätere Starts verwenden die lokale Kopie.

ollama run qwen3:14b

Das Modell eignet sich für IT-Support, Zusammenfassungen, PowerShell und Softwarekonzepte. Auf den älteren K2200 ist es jedoch deutlich langsamer als auf modernen KI-GPUs.

Welche lokalen KI-Modelle passen zu 24 GB GPU-VRAM?

Die folgenden Grössen beschreiben die ungefähren Downloadgrössen quantisierter Ollama-Modelle, nicht ihren vollständigen Speicherverbrauch zur Laufzeit. Je nach Kontextlänge, parallelen Anfragen und GPU-Treiber kann deutlich mehr VRAM nötig sein. Für einen schnellen Alltagsassistenten kann ein kleineres Modell sinnvoller sein als ein langsameres 30B-Modell.

Weitere Modelle lassen sich direkt mit folgenden Befehlen herunterladen und starten:

ollama run qwen3:8b
ollama run qwen2.5-coder:7b
ollama run qwen3:30b

Kleinere Modelle passen unter Umständen vollständig auf eine einzelne 8-GB-Karte. Ollama nutzt dann nicht zwangsläufig alle vier GPUs, weil die Übertragung zwischen mehreren PCIe-Karten zusätzliche Zeit kostet. Erst wenn ein Modell nicht vollständig auf eine einzelne GPU passt, verteilt Ollama es normalerweise auf mehrere verfügbare Karten.

Ollama-Modelle wechseln, anzeigen und entladen

Im laufenden Ollama-Chat beendet /bye die interaktive Sitzung. Danach kann direkt ein anderes Modell mit ollama run gestartet werden. Der Download bleibt gespeichert. Für die Verwaltung sind besonders diese Befehle nützlich:

/bye

ollama list
ollama ps
ollama stop qwen3:14b

ollama list zeigt installierte Modelle; ollama ps nennt aktuell geladene Modelle und ihre CPU-/GPU-Verteilung; ollama stop qwen3:14b entlädt dieses Modell aus dem Speicher, ohne es zu löschen. Jeder Befehl gehört in eine eigene Eingabezeile. Die Ausgabe zweier Befehle sollte nicht versehentlich zu einem einzigen Aufruf zusammengezogen werden.

Praxiswerte: Nutzt Ollama wirklich alle vier Grafikkarten?

Ja. Die tatsächliche Messung vom 30. Oktober 2026 zeigte auf jeder Karte den Prozess llama-server.exe. Bei laufendem qwen3:14b waren rund 18,03 GiB von 24 GiB VRAM belegt. Die Verteilung sah so aus:

Die Messwerte können mit nvidia-smi überwacht werden; der Schalter -l 1 aktualisiert die Anzeige einmal pro Sekunde:

nvidia-smi -l 1

Ollama zeigte zusätzlich 87 % GPU / 13 % CPU bei einem Kontext von 32'768 Tokens. Das ist keine Anzeige der momentanen Auslastung in Prozent, sondern die Aufteilung der Modellverarbeitung beziehungsweise Modellschichten. Ein Teil wird im System-RAM von der CPU bearbeitet. Gleichzeitig müssen die Grafikkarten nicht alle dauerhaft mit 100 % rechnen: Beim sogenannten Layer-Splitting laufen viele Berechnungsschritte nacheinander ab.

Kontext reduzieren, um GPU-Speicher freizugeben

In diesem Fall lohnt es sich, innerhalb eines laufenden Ollama-Chats den Kontext zunächst auf 4'096 Tokens zu begrenzen:

/set parameter num_ctx 4096

Danach das Modell bei Bedarf entladen und neu aufrufen und mit ollama ps vergleichen. Ein kleinerer Kontext senkt den Speicherbedarf; ob damit 100% GPU erreicht wird, hängt auch von den einzelnen GPU-Kapazitäten und der Modellaufteilung ab. Als nächster Kompromiss bieten sich 8'192 oder 16'384 Tokens an. Weniger Kontext bedeutet jedoch, dass längere Dokumente beziehungsweise Gesprächsverläufe früher abgeschnitten werden.

Auf andere GPUs, Hyper-V-Hosts und KI-Modelle anpassen

Der PowerShell-Block ist bewusst einfach gehalten. Für andere Umgebungen sind vor allem vier Stellen anzupassen: In $VM steht der exakte Name der Ziel-VM, beispielsweise KI-Win11. Im Array $GPUNamen stehen die gewünschten Gerätenamen gemäss Geräte-Manager. -HighMemoryMappedIoSpace muss zum MMIO-Bedarf der eingesetzten PCIe-Geräte passen. Und innerhalb der VM ist ein Treiber für genau diese GPU-Generation und das Gastbetriebssystem zu installieren.

Neuere NVIDIA-Karten rechnen schneller; andere Hersteller benötigen passende Treiber und KI-Backends. Eine an DDA übertragene GPU darf nicht mehr für die Host-Anzeige gebraucht werden. Bei Linux-Gästen unterscheiden sich die Treiber. PCIe-Slots, CPUs, Kühlung und Stromversorgung begrenzen die Kartenanzahl.

Wichtig bei der Modellwahl: Die Namen qwen3:14b und qwen3:8b sind lediglich Ollama-Tags. Sie lassen sich durch andere Modellnamen aus der offiziellen Ollama-Bibliothek ersetzen. Ein grösserer Download benötigt nicht nur mehr SSD-Platz, sondern häufig auch mehr Arbeitsspeicher und VRAM.

Ollama, llama.cpp, LM Studio und GPU-P: Was ist sinnvoll?

Ollama ist für eine schnelle, reproduzierbare Installation besonders praktisch. Alternativen bieten mehr Kontrolle, erfordern aber teils zusätzliche Einrichtung. Bei mehreren älteren GPUs ist ausserdem zwischen dem vollständigen PCIe-Passthrough per DDA und der Teilung einer GPU per GPU-Partitionierung (GPU-P) zu unterscheiden: Für den beschriebenen Server wurde DDA erfolgreich eingesetzt.

Häufige Probleme bei lokaler KI mit mehreren GPUs

Eine GPU erscheint nicht in Windows 11

Kontrollieren, ob sie bereits einer anderen VM zugewiesen ist, ob der NVIDIA-Gasttreiber installiert wurde und ob ausreichend MMIO-Adressraum vorhanden ist. Auch fehlerhafte GPU-Stromversorgung kann die Erkennung verhindern. Der Hyper-V-Manager bietet für einen einzelnen Host keinen gleichwertigen Standarddialog für die vollständige DDA-Zuweisung wie die PowerShell-Befehle.

Ollama verwendet nicht alle vier Karten

Das kann vollkommen korrekt sein: Ein kleines Modell passt auf eine einzige M4000. Bei grösseren Modellen können mehrere GPUs Speicher belegen, ohne permanent gleich hohe Auslastung anzuzeigen. Erst die Kombination aus ollama ps, GPU-Prozessliste und Speichernutzung ergibt ein verlässliches Bild.

Bei nvidia-smi steht CUDA 13.0

Die dort angezeigte CUDA-Version beschreibt die vom Treiber unterstützte CUDA-Treiberschnittstelle, nicht automatisch ein installiertes CUDA Toolkit. Für die normale Ollama-Installation ist kein separat installiertes Toolkit notwendig. Wer eigene CUDA-Programme für Maxwell kompiliert, benötigt dagegen eine ältere kompatible Toolchain; CUDA 13 kann für diese Architektur nicht mehr neu kompilieren.

Fazit: Vorhandene Server-GPUs als lokalen KI-Server weiterverwenden

Der HP ML350 Gen9 zeigt, dass auch ältere Workstation-Grafikkarten noch für lokale KI-Aufgaben eingesetzt werden können. Im beschriebenen Aufbau wurden zwei M4000 und zwei K2200 erfolgreich an eine Windows-11-VM durchgereicht. Ollama verteilte Qwen3 14B auf alle vier Karten; die gemessene Belegung lag bei rund 18 GiB VRAM. Die Einschränkungen bleiben sichtbar: getrennte Speicherbereiche, CPU-Auslagerung bei grossem Kontext und begrenzte Rechenleistung älterer GPUs.

Für lokale Sprachmodelle bleibt Hyper-V DDA mit Ollama eine praktikable Wiederverwendung vorhandener Hardware. Zuerst Modell und Kontext optimieren, dann erst über neue GPUs nachdenken.