hmm, to je divne, myslel jsem ze CUDA shared RAM davno umoznuje (ve widows i v linuxu), jen je to proste pomale kvuli pcie rychlosti. to NVME samozrejme ne ale to uz je dost zoufalost
to by me taky zajimalo detailneji.
jestlize uz cuda ma funkci cudaImportExternalMemory, tak jsem predpokladal, ze tam pujde hodit pointer na nejakou alokovanou pamet z RAm a je to.
Autor píše toto:
Greenboost is not a hack around driver restrictions. The DMA-BUF + external memory import path it uses is a documented CUDA feature.
Počkat, to je něco jiného, shared RAM je o tom, že to dynamicky přesouvá mezi RAM a GPU při přístupu z CPU a/nebo kernelu (prostě že se o to člověk nemusí starat, kde ty data jsou), ale ne samotný RAM offloading.
Ten dělají nějaké další funkce (PyTorch má nějakou, accelerate taky), ale co jsem si (před rokem) hrál, mají pořád své limity, něco jako "transparentní pagging" to má daleko a na OOM to naráží také. (Už si nepamatuju proč, ale tuším to bylo protože to pracovalo s bloky, a ne zcela správně to unloadovalo když to bylo na hraně)
to nevypada ze by se neco dynamicky presouvalo
https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/understanding-memory.html#page-locked-host-memory
Page-locked memory can be mapped to the GPU for direct access from GPU kernels.
....
2.4.3.1. Mapped Memory
On systems with HMM or ATS, all host memory is directly accessible from the GPU using the host pointers.
....
While mapped memory may be useful in some cases where certain data which is not copied to the GPU needs to be accessed from a kernel, accessing mapped memory in a kernel requires transactions across the CPU-GPU interconnect, PCIe, or NVLink C2C. These operations have higher latency and lower bandwidth compared to accessing device memory. Mapped memory should not be considered a performant alternative to unified memory or explicit memory management for the majority of a kernel’s memory needs.
Máte naprostou pravdu, popletl jsem to s Unified memory. Mea culpa
Nicméně mi to moc nepomůže, jestli koukám dobře, tak ani jedna moje grafika to nepodporuje :( Škoda, i tak díky za nasměrování.
16. 3. 2026, 12:44 editováno autorem komentáře
Neni pri inferenci nejvetsi realny bottleneck prave hruba propusnost pameti?
Pak mi prijde, ze to asi velka vyhra nebude, v principu se stale bude cekat na presun dat...
Nebo je uvaha chybna?
16. 3. 2026, 15:31 editováno autorem komentáře
Autor píše, že ty nejvíce hot data drží v té rychlé paměti na GPU, cold data v RAM a NVMe je jen rezerva, když něco na chvíli přeteče.
Večer vyzkouším. Jinak máte pravdu s tou pomalostí, ale to autor víceméně neřeší (resp. řeší to, že se snaží dávat hot alokace do VRAM ...) - ten řeší mnohem větší bottleneck, když se mu to prostě do VRAM nevešlo vůbec (a koukám, že zatím jen pro Ollama, což ale nevadí, pořád dobrý začátek).
"The dlsym hook is specific to how Ollama resolves CUDA symbols. Other inference engines
(llama.cpp, vllm) may need different handling — contributions welcome."