Robocikowo>ROBOCIKOWO
Infrastruktura

CUDA VMM

2019AktywnyOpublikowano: 23 września 2026Aktualizacja: 23 września 2026Opublikowany
Niskopoziomowe API sterownika CUDA (cuMemCreate, cuMemAddressReserve, cuMemMap, cuMemSetAccess) oddzielające rezerwację adresu wirtualnego od fizycznej alokacji pamięci GPU.
Kluczowa innowacja
Rozdzielenie rezerwacji wirtualnego zakresu adresów od fizycznej alokacji pamięci GPU, co pozwala mapować, przemapowywać i współdzielić pamięć bez kopiowania danych i bez globalnej synchronizacji.
Kategoria
Infrastruktura
Poziom abstrakcji
Primitive
Poziom operacji
TreningInferencjaUdostępnianie
Zastosowania
Rozszerzalne bufory i alokacje GPU bez kopiowania danychWłasne alokatory i pule pamięci GPUOgraniczanie fragmentacji pamięci (np. expandable_segments w PyTorch)Współdzielenie pamięci między procesami (IPC)Selektywny dostęp peer-to-peer między wieloma GPUInteroperacyjność z API graficznymi (Vulkan, OpenGL)Trening i inferencja dużych modeli ze zmiennym rozmiarem batcha

Jak działa

1) cuMemGetAllocationGranularity zwraca wymaganą granulację (wyrównanie) rozmiaru alokacji dla danego urządzenia. 2) cuMemAddressReserve rezerwuje ciągły zakres wirtualnych adresów (bez pamięci fizycznej). 3) cuMemCreate tworzy uchwyt do fizycznej pamięci (backing store) o rozmiarze wielokrotności granulacji. 4) cuMemMap mapuje uchwyt fizyczny w zarezerwowanym zakresie adresów. 5) cuMemSetAccess nadaje prawa dostępu (odczyt/zapis) dla wskazanych urządzeń, co steruje też dostępem peer-to-peer. Odwrotne operacje to cuMemUnmap, cuMemAddressFree i cuMemRelease. Aby rozszerzyć alokację, rezerwuje się większy zakres adresów i domapowuje kolejne uchwyty fizyczne bez przenoszenia dotychczasowych danych. Do współdzielenia między procesami służą cuMemExportToShareableHandle i cuMemImportFromShareableHandle, operujące na uchwytach OS: deskryptorach plików w Linuksie oraz HANDLE / D3DKMT_HANDLE w Windows. CUDA nie wspiera mapowania części pojedynczej alokacji fizycznej, więc rozmiary muszą się zgadzać.

Rozwiązany problem

Wysokopoziomowe cudaMalloc łączy rezerwację adresu z fizyczną alokacją, przez co nie da się rozszerzyć istniejącej alokacji bez realokacji i skopiowania danych, a zwalnianie pamięci wymaga synchronizacji całego urządzenia. Utrudnia to budowę rosnących buforów, pul pamięci i kontroli nad fragmentacją oraz współdzieleniem pamięci między urządzeniami i procesami.

Komponenty

cuMemAddressReserveRezerwacja przestrzeni adresowej

Rezerwuje ciągły zakres wirtualnych adresów GPU bez przypisywania pamięci fizycznej.

cuMemCreateAlokacja pamięci fizycznej

Tworzy uchwyt do fizycznej alokacji pamięci (backing store) o rozmiarze będącym wielokrotnością granulacji.

cuMemMapPowiązanie adresu wirtualnego z pamięcią fizyczną

Mapuje uchwyt pamięci fizycznej w zarezerwowanym zakresie adresów wirtualnych.

cuMemSetAccessKontrola dostępu urządzeń

Ustawia prawa dostępu (odczyt/zapis) do zmapowanej pamięci dla poszczególnych urządzeń, sterując też dostępem peer-to-peer.

cuMemGetAllocationGranularityWyznaczanie wyrównania rozmiaru

Zwraca wymagane wyrównanie (granulację) rozmiaru alokacji; rozmiary muszą być jego wielokrotnością.

cuMemExportToShareableHandle / cuMemImportFromShareableHandleWspółdzielenie pamięci między procesami

Eksportują i importują alokacje jako uchwyty systemu operacyjnego (deskryptor pliku w Linuksie, HANDLE/D3DKMT_HANDLE w Windows), umożliwiając współdzielenie między procesami oraz z API graficznymi.

Oficjalna

Implementacja

Implementacje referencyjne
NVIDIA CUDA Samples (memMapIPCDrv, vectorAddMMAP)
C++/CUDA · NVIDIA
Oficjalna
PyTorch CUDACachingAllocator (expandable_segments)
C++/CUDA · PyTorch
Oficjalna
Pułapki implementacyjne
Niewyrównanie do granulacji alokacjiŚrednia

Rozmiary muszą być wielokrotnością wartości z cuMemGetAllocationGranularity; CUDA nie mapuje części pojedynczej alokacji fizycznej.

Rozwiązanie:Zaokrąglaj rozmiary w górę do granulacji i dopasowuj rozmiary przy mapowaniu.
Ręczne zarządzanie cyklem życiaWysoka

Programista sam odpowiada za kolejność reserve → create → map → setAccess oraz zwolnienie unmap → release → addressFree; błędy prowadzą do wycieków lub błędów dostępu.

Rozwiązanie:Opakuj operacje we własny alokator/RAII i testuj ścieżki błędów.
Brak jawnego nadania dostępu peerŚrednia

Dostęp innego GPU do pamięci wymaga jawnego cuMemSetAccess; bez tego następuje błąd dostępu.

Rozwiązanie:Nadawaj prawa dostępu dla wszystkich urządzeń, które mają korzystać z alokacji.

Ewolucja

2019
Wprowadzenie Low-Level Virtual Memory Management API w CUDA 10.2
Punkt przełomowy

CUDA 10.2 dodaje cuMemCreate, cuMemAddressReserve, cuMemMap i cuMemSetAccess, rozdzielając rezerwację adresu od alokacji fizycznej.

2020
Publikacja przewodnika NVIDIA "Introducing Low-Level GPU Virtual Memory Management"

Oficjalny przewodnik opisuje wzorce użycia: rosnące alokacje, pule pamięci, IPC i selektywny dostęp peer.

2023
PyTorch wprowadza expandable_segments oparte na VMM

Caching allocator PyTorcha zyskuje tryb expandable_segments wykorzystujący VMM do ograniczania fragmentacji przy zmiennych rozmiarach alokacji.

Hiperparametry (konfigurowalne osie)

Granulacja alokacjiWysoka

Wyrównanie rozmiaru pamięci fizycznej wymagane przez urządzenie; rozmiary alokacji muszą być jego wielokrotnością.

Typ uchwytu współdzielonegoŚrednia

Rodzaj uchwytu OS używanego do współdzielenia: deskryptor pliku POSIX (Linux) albo HANDLE / D3DKMT_HANDLE (Windows).

Prawa dostępuWysoka

Prawa odczytu/zapisu ustawiane per urządzenie przez cuMemSetAccess, decydujące też o dostępie peer-to-peer.

Wymagania sprzętowe

Podstawowe

API sterownika CUDA działa wyłącznie na GPU NVIDIA wspierających zarządzanie pamięcią wirtualną (od CUDA 10.2).