GPU Partitioning (GPU-P, GPU-PV) to nowa funkcja Hyper-V w Windows Server 2025, która pozwala podzielić jedną fizyczną kartę graficzną na wiele niezależnych partycji i przydzielić je różnym maszynom wirtualnym — zamiast przekazywać cały GPU do jednej VM (jak w DDA). Technologia wykorzystuje interfejs SR-IOV (Single Root I/O Virtualization), oferuje sprzętową izolację z przewidywalną wydajnością i — po raz pierwszy w historii Hyper-V — obsługuje Live Migration maszyn wirtualnych z przypisanym GPU.
W skrócie
- GPU Partitioning dzieli fizyczny GPU na partycje — każda VM dostaje własny, odizolowany ułamek mocy obliczeniowej
- Opiera się na SR-IOV — sprzętowej granicy bezpieczeństwa gwarantowanej przez producenta GPU
- Nowość w Windows Server 2025: Live Migration VM z GPU-P (wcześniej niemożliwe dla maszyn z przypisanym GPU)
- Obsługa klastrów failover — przy awarii węzła VM z GPU-P automatycznie startuje na innym hoście (wymagana edycja Datacenter)
- Obsługiwane karty: NVIDIA A2, A10, A16, A40, L2, L4, L40, L40S, RTX Pro 6000 Blackwell Server Edition; AMD Radeon PRO V710
- Znacznie wyższe zagęszczenie VM niż DDA — zamiast 1 VM na 1 GPU, jedna karta może obsłużyć kilka-kilkanaście maszyn jednocześnie
Pełna definicja
GPU Partitioning (GPU-P) to mechanizm wirtualizacji GPU wprowadzony natywnie w Hyper-V Windows Server 2025. Zamiast przypisywać całą kartę do pojedynczej maszyny wirtualnej (jak w Discrete Device Assignment — DDA), GPU-P dzieli zasoby fizycznego akceleratora na mniejsze, odseparowane fragmenty. Każda partycja otrzymuje własny wycinek pamięci VRAM, rdzeni CUDA/tensor i przepustowości magistrali PCIe — i tylko ten wycinek jest widoczny dla gościa VM.
Architektura GPU-P opiera się na Single Root I/O Virtualization (SR-IOV), czyli standardzie PCI-SIG, który od lat jest stosowany w kartach sieciowych (np. Mellanox), a teraz został rozszerzony o GPU. SR-IOV definiuje dwa typy funkcji PCIe: Physical Function (PF) — pełna funkcja fizycznego urządzenia dostępna dla hypervisora — oraz Virtual Functions (VF) — lekkie instancje udostępniane maszynom wirtualnym. Każda VF ma własną przestrzeń adresową DMA, co zapewnia sprzętową izolację: VM nie może odczytać danych z partycji należącej do innej VM.
Trzy przełomy, które przynosi GPU-P w Windows Server 2025
-
Live Migration z GPU — po raz pierwszy w ekosystemie Hyper-V można przenieść działającą VM z przypisanym GPU między hostami bez przerywania jej pracy. Wcześniej było to możliwe tylko dla VM bez akceleracji graficznej (lub z emulowanym GPU). Live Migration GPU-P automatycznie przełącza się na TCP/IP z kompresją, co może nieznacznie zwiększyć obciążenie CPU hosta, ale utrzymuje stan GPU podczas transferu.
-
Wysoka dostępność (HA) w klastrze — w przypadku nieplanowanej awarii węzła klastra, VM z partycją GPU zostaje automatycznie uruchomiona na innym hoście posiadającym kompatybilny GPU. Ta funkcja wymaga Windows Server 2025 Datacenter i jednorodnej konfiguracji GPU we wszystkich węzłach (ten sam model, ta sama liczba partycji).
-
Skalowalność gęstości VM — tam gdzie DDA pozwalało przypisać 1 GPU do 1 VM, GPU-P pozwala jedną kartą (np. NVIDIA A40 z 48 GB VRAM) obsłużyć kilka maszyn jednocześnie. To fundamentalnie zmienia ekonomikę VDI — zamiast kupować 10 kart do 10 VM, jedna karta może obsłużyć je wszystkie.
Jak działa GPU Partitioning — od sprzętu do VM
Proces konfiguracji i działania GPU-P składa się z kilku etapów:
| Etap | Co się dzieje |
|---|---|
| 1. Przygotowanie GPU | Administrator — przez Windows Admin Center lub PowerShell — ustawia fizyczny GPU jako partitionable (zamiast DDA). GPU przechodzi w tryb SR-IOV, odsłaniając Physical Function dla hypervisora |
| 2. Definiowanie partycji | Administrator określa liczbę partycji na danej karcie (np. 4, 8, 16). GPU dzieli VRAM i rdzenie proporcjonalnie. Każda partycja to osobna Virtual Function widoczna w Hyper-V |
| 3. Przypisywanie do VM | Partycje są auto-przypisywane — administrator nie wybiera konkretnej partycji dla konkretnej VM, Hyper-V robi to automatycznie. Do jednej VM można przypisać wiele partycji (każda będzie widoczna jako osobny GPU w gościu) |
| 4. Instalacja sterownika w gościu | Wewnątrz VM instaluje się pełny sterownik producenta GPU (NVIDIA vGPU Software v18.x+ lub sterownik AMD). VM widzi GPU tak, jakby był fizyczny — z tą różnicą, że ma dostęp tylko do swojego wycinka |
| 5. Izolacja sprzętowa | SR-IOV zapewnia, że DMA każdej VF trafia tylko do pamięci przypisanej do danej VM. Nawet jeśli jedna VM zostanie skompromitowana, nie może odczytać danych GPU innej VM |
Wymagania sprzętowe — co jest potrzebne
| Komponent | Wymaganie |
|---|---|
| CPU | Procesor z IOMMU i DMA bit tracking: Intel VT-D (4. gen Xeon SP Sapphire Rapids i nowsze) lub AMD-Vi (EPYC 7003 Milan i nowsze). EPYC 7002 Rome obsługuje GPU-P, ale bez Live Migration |
| GPU | Wyłącznie certyfikowane modele NVIDIA i AMD (lista poniżej). Karty konsumenckie (GeForce, Radeon RX) nie są wspierane |
| Sterownik GPU na hoście | NVIDIA vGPU Software v18.x lub nowszy (dla Live Migration); dla samego partycjonowania wystarczy standardowy sterownik GRID/vGPU |
| System gościa | Windows 10/11, Windows 10/11 Enterprise multi-session, Windows Server 2019/2022/2025, Ubuntu 18.04/20.04/22.04 LTS |
| Klastrowanie HA | Windows Server 2025 Datacenter + jednorodna konfiguracja GPU na wszystkich węzłach |
Obsługiwane GPU — pełna lista (stan na maj 2026)
| Producent | Model | Typowy VRAM | Przeznaczenie |
|---|---|---|---|
| NVIDIA | A2 | 16 GB | Wnioskowanie AI, małe VDI |
| NVIDIA | A10 | 24 GB | VDI średniej gęstości, rendering |
| NVIDIA | A16 | 64 GB (4×16 GB) | VDI wysokiej gęstości — do 16 użytkowników na kartę |
| NVIDIA | A40 | 48 GB | Wnioskowanie ML, rendering, stacje robocze |
| NVIDIA | L2 | 24 GB | Entry-level AI, małe VDI |
| NVIDIA | L4 | 24 GB | Wnioskowanie AI, transkrypcja, VDI |
| NVIDIA | L40 | 48 GB | Wnioskowanie, rendering, VDI |
| NVIDIA | L40S | 48 GB | Wnioskowanie ML, rendering |
| NVIDIA | RTX Pro 6000 Blackwell Server Edition | 96 GB | Najwyższa wydajność — AI, symulacje, zaawansowane VDI |
| AMD | Radeon PRO V710 | 32 GB | VDI, rendering, stacje robocze |
Ważne: GPU muszą być jednorodne w ramach klastra — nie wolno mieszać producentów ani różnych modeli tego samego producenta. Wszystkie karty muszą mieć identyczną liczbę partycji. Windows Admin Center automatycznie waliduje jednorodność i ostrzega przed błędami konfiguracji.
GPU Partitioning vs DDA — porównanie
| Cecha | GPU Partitioning (GPU-P) | Discrete Device Assignment (DDA) |
|---|---|---|
| Dostępność od | Windows Server 2025 | Windows Server 2016 |
| Model przypisania GPU | Jeden GPU → wiele VM (partycje) | Jeden GPU → jedna VM (dedykowany) |
| Wydajność | Przewidywalna, proporcjonalna do partycji | Pełna — VM widzi cały GPU |
| Live Migration | ✅ Tak (nowość w 2025) | ❌ Nie |
| HA / Failover klastra | ✅ Tak (Datacenter) | ❌ Nie |
| Obsługiwane GPU | Wybrane modele NVIDIA/AMD (lista certyfikowana) | Praktycznie każdy GPU z pełnym sterownikiem |
| Izolacja | Sprzętowa (SR-IOV) | Sprzętowa (cały GPU przekazany) |
| Gęstość VM | Wysoka — wiele VM na jednym GPU | Niska — maks. 1 VM na 1 GPU |
| CUDA / DirectX / OpenGL w gościu | ✅ Pełne wsparcie | ✅ Pełne wsparcie |
| Zastosowanie | VDI, AI inferencing, wielodostępne środowiska | Pojedyncze wymagające VM (CAD, symulacje) |
Kiedy wybrać GPU-P, a kiedy DDA
GPU Partitioning — optymalny wybór gdy:
- Budujesz farmę VDI (Windows 365, Azure Virtual Desktop on-prem, RDS) — potrzebujesz obsłużyć dziesiątki użytkowników na kilku kartach. GPU-P pozwala uruchomić 4–16 VM na jednej karcie.
- Uruchamiasz wiele lekkich modeli ML — np. inferencja w sklepach detalicznych, na liniach produkcyjnych — wiele równoległych instancji na jednym GPU.
- Potrzebujesz wysokiej dostępności — Live Migration i automatyczny failover są kluczowe, bo nie możesz sobie pozwolić na przestój VM.
- Optymalizujesz koszty infrastruktury — zamiast 10 kart dla 10 VM, kupujesz 1-2 karty i maksymalnie je wykorzystujesz.
DDA — lepszy wybór gdy:
- Jedna VM potrzebuje pełnej mocy GPU — renderowanie CAD, symulacje CFD, uczenie dużych modeli ML gdzie liczy się każdy teraflop.
- Używasz niestandardowego GPU spoza listy certyfikowanej dla GPU-P (np. starsze karty, karty konsumenckie w labie).
- Nie potrzebujesz Live Migration — serwer testowy, stacja robocza w laboratorium.
Częste pytania
Czym GPU Partitioning różni się od vGPU (NVIDIA GRID)?
GPU-P to natywna technologia Microsoft w Hyper-V, podczas gdy NVIDIA GRID vGPU to rozwiązanie własne NVIDII. Oba dzielą fizyczny GPU na wiele instancji, ale GPU-P używa otwartego standardu SR-IOV, nie wymaga licencji GRID i jest zarządzane bezpośrednio z Windows Admin Center. GRID vGPU oferuje natomiast bardziej zaawansowane profile wydajnościowe (np. profile Q-series z różnymi przydziałami VRAM) i działa też na VMware vSphere, czego GPU-P nie obsługuje.
Czy GPU Partitioning działa na Windows Server 2025 Standard?
Tak, ale z ograniczeniami. Na edycji Standard można używać GPU-P na pojedynczym serwerze (standalone), w tym Live Migration między dwoma niezależnymi hostami. Jednak klastrowanie z wysoką dostępnością (failover) wymaga już edycji Datacenter. Jeśli potrzebujesz automatycznego przełączania VM z GPU na inny węzeł przy awarii — Datacenter jest jedyną opcją.
Ile partycji mogę utworzyć na jednym GPU?
Liczba partycji zależy od modelu GPU i jego VRAM. NVIDIA A16 z 64 GB VRAM (4×16 GB fizycznie) może obsłużyć do 16 partycji. Karty z mniejszą pamięcią (np. A2 z 16 GB) zazwyczaj obsługują 4–8 partycji, aby każda miała sensowny przydział pamięci. Windows Admin Center automatycznie proponuje optymalną liczbę partycji dla danego modelu GPU. Pamiętaj: partycje dzielą VRAM proporcjonalnie — przy 4 partycjach na karcie 48 GB każda dostaje ~12 GB.
Czy mogę użyć GeForce RTX z GPU Partitioning?
Nie. GPU-P wymaga certyfikowanych kart serwerowych — NVIDIA A-series, L-series lub RTX Pro Blackwell Server Edition. Karty konsumenckie (GeForce, w tym RTX 4090/5090) nie obsługują SR-IOV w sterowniku, więc nie mogą być partycjonowane. Możesz je jednak przekazać przez DDA do pojedynczej VM.
Co się stanie z partycjami GPU podczas Live Migration?
Hyper-V automatycznie zapisuje stan partycji GPU (w tym VRAM i kontekst sterownika), przesyła go przez sieć do docelowego hosta i odtwarza. Transfer używa TCP/IP z kompresją, co może zwiększyć wykorzystanie CPU hosta i wydłużyć czas migracji — szczególnie przy dużych przydziałach VRAM. Kluczowe jest, aby docelowy host miał identyczny GPU z identyczną liczbą partycji — inaczej migracja zostanie odrzucona.
Czy GPU-P działa z maszynami linuksowymi?
Tak. Oficjalnie wspierane są Ubuntu 18.04, 20.04 i 22.04 LTS. Wymagane jest zainstalowanie odpowiedniego sterownika NVIDIA vGPU lub AMD ROCm wewnątrz VM. Funkcjonalność CUDA, OpenGL i Vulkan jest zachowana — gość linuksowy widzi przydzieloną partycję tak samo jak Windows.
Czy jedna VM może dostać kilka partycji GPU?
Tak. Jeśli przypiszesz VM dwie partycje z tego samego fizycznego GPU, w systemie gościa pojawią się one jako dwa osobne GPU. Pozwala to na ręczne rozdzielenie obciążeń (np. jedna partycja do CUDA, druga do grafiki) lub na użycie frameworków wspierających multi-GPU. Pamiętaj jednak, że obie partycje pochodzą z tego samego fizycznego GPU — dzielą więc wspólną przepustowość PCIe.
Windows Server 2025 w edycji Datacenter lub Standard znajdziesz w ofercie KluczeSoft.pl w kategorii Licencje Server — to w pełni legalne klucze resale w ramach swobodnego obrotu licencjami w UE, objęte fakturą VAT i polskojęzycznym wsparciem technicznym. W przeciwieństwie do subskrypcji Azure, licencja jest wieczysta i przypisana do twojego sprzętu — idealnie nada się pod środowisko Hyper-V z GPU Partitioning.