Vlákno názorů k článku
Greenboost přidává paměť pro GPU Nvidia z RAM a NVMe
od fanoush - hmm, to je divne, myslel jsem ze CUDA...
-
FíkZlatý podporovatelAutor 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. -
Tak jsem GreenBoost otestoval. Podle toho, jak se chová je to zatím fakt jen hack do ollama.
Dost věcí je tam zadrátovaných (autorovo 12GB VRAM, nebo 64GB (ten se to snaží spočítat) swap natvrdo v rootu (a instalační script počítá natvrdo s systémovou instalací v Ubuntu, ale nezhroutil se a potřebnou práci (librarku, kernel modul) na Slackwaru udělal na první dobrou). Fajn, je to opensource, s tím se dá žít a upravit si to, beru to jako první zveřejnění ~ alfa.
Hooknutí funguje hezky, testovací prográmek v pythonu to opravdu naalokuje jak má. Test s ollama dopadl trochu hůř - sice nefailne alokace, ale ollama si vyčetla skutečnou alokaci a co se nevešlo do VRAM, tak sama nacpala offloadnuté do CPU ;-) - ale musím zaklepat, na OOM to nenarazilo, takže asi vše funguje jak má.
Na pokusy přimět ollamu alokovat co to dá jsem se už nedostal, taky musím spát.S druhou grafikou (M40) se to, přesně podle očekávání (sm5_2) nebaví, ale nijak to nic neblokuje, takže spokojenost.
Ještě rant, /sys/class/greenboost/greenboost/pool_info ukazuje v T2 (RAM) 0 allocated, 0 available, i když tam nějaká data jsou.
-
No zajimave by bylo jaky to ma vykon, treba llama.cpp automaticky nacte nejake vrstvy velkeho modelu do GPU RAM co se vejde a zbytek asi zustane na procesoru - tedy nactu jakykoliv model ktery se vejde do RAM jenom to pak jede treba 2t/s na procesoru. tak jestli tohle by jelo rychleji. Mozna ani i ne. Treba na laptopu s RTX A2000 8GB jsem zkousel model Qwen3.5 27B Q4 (cca 15GB model) a neco jelo pres CUDA z GPU (VRAM byla obsazena na 7GB, nvidia-smi psalo ze to bezi na 15W z 35) a delalo to 2t/s. pak jsem zakazal CUDA pro llama.cpp pres nejakou promennou a jelo to cele na procesoru a jelo to cca stejne rychle. podobne na gpt-oss 20b modelu (ten je rychlejsi). takze bud je to hack specialne pro ollama ktera tohle vubec neumi nebo to ma opravdu nejaky vykonovy prinos kdyz to jede cele z gpu ale pro neco/vetsinu si to jde pres pcie.
17. 3. 2026, 17:06 editováno autorem komentáře
-
Tak to je divný. U mě to prvně defaultní qwen3.5 (tuším 9B) nacpalo celý na CPU, rychlost byla kolem 2t/s, ale na prastaré M40 to jede řádově nízké desítky/s, na RTX 4060Ti pokud je vše v VRAM ještě líp pro stejný prompt.
Ale souhlasí, jakmile z toho ollama udělala ~50% CPU 50% GPU, tak to šlo na stejně pomalé jako na samotném CPU (to ještě bez Greenboostu). Až/jestli se mi podaří to přesvědčit, aby offloading dělal greenboost, tak to zkusím změřit taky.
-
Hmm, tak jsem jeste vygoglil ze existuje promenna GGML_CUDA_ENABLE_UNIFIED_MEMORY=1 a muzu potvrdit ze s tim to nahraje cely gpt-oss-20b model pres CUDA
llama_params_fit_impl: projected to use 15756 MiB of device memory vs. 28502 MiB of free device memory
llama_params_fit_impl: will leave 12745 >= 1024 MiB of free device memory, no changes needed
llama_params_fit: successfully fit params to free device memory
llama_params_fit: fitting params to free memory took 0.41 seconds
llama_model_load_from_file_impl: using device CUDA0 (NVIDIA RTX A2000 8GB Laptop GPU) (0000:01:00.0) - 28502 MiB free
....
....
load_tensors: offloaded 25/25 layers to GPU
load_tensors: CPU_Mapped model buffer size = 586.82 MiB
load_tensors: CUDA0 model buffer size = 10949.38 MiB
narozdil od
llama_params_fit_impl: projected to use 15756 MiB of device memory vs. 7739 MiB of free device memory
llama_params_fit_impl: cannot meet free memory target of 1024 MiB, need to reduce device memory by 9040 MiB
llama_params_fit_impl: user has requested full context size of 131072 -> no change
llama_params_fit_impl: with only dense weights in device memory there is a total surplus of 383 MiB
llama_params_fit_impl: filling dense-only layers back-to-front:
llama_params_fit_impl: - CUDA0 (NVIDIA RTX A2000 8GB Laptop GPU): 25 layers, 6453 MiB used, 1285 MiB free
llama_params_fit_impl: converting dense-only layers to full layers and filling them front-to-back with overflow to next device/system memory:
llama_params_fit_impl: - CUDA0 (NVIDIA RTX A2000 8GB Laptop GPU): 25 layers (24 overflowing), 6588 MiB used, 1151 MiB free
...
load_tensors: offloaded 25/25 layers to GPU
load_tensors: CPU_Mapped model buffer size = 10949.33 MiB
load_tensors: CUDA0 model buffer size = 1780.97 MiBale na vykon to ma zajimavy vliv. Pro ggml-org/gpt-oss-20b-GGUF model dela oboji cca 20t/s ale s timhle GPU jede naplno (34W z 35W) a procesor se flaka. Ale treba pro model unsloth/Qwen3.5-27B-GGUF:UD-Q4_K_XL to pise
llama_params_fit_impl: projected to use 19714 MiB of device memory vs. 28845 MiB of free device memory
llama_params_fit_impl: will leave 9130 >= 1024 MiB of free device memory, no changes needed
llama_params_fit: successfully fit params to free device memory
llama_params_fit: fitting params to free memory took 0.79 seconds
llama_model_load_from_file_impl: using device CUDA0 (NVIDIA RTX A2000 8GB Laptop GPU) (0000:01:00.0) - 28845 MiB free
...
load_tensors: loading model tensors, this can take a while... (mmap = true, direct_io = false)
load_tensors: offloading output layer to GPU
load_tensors: offloading 63 repeating layers to GPU
load_tensors: offloaded 65/65 layers to GPU
load_tensors: CPU_Mapped model buffer size = 682.03 MiB
load_tensors: CUDA0 model buffer size = 16112.30 MiB
ale vykon je skoro nulovy - 0.3t/s - naprosto nepouzitelne. Bez te promenne to dela s pomoci procesoru ty cca 2 t/s a s promennou CUDA_VISIBLE_DEVICES= kdy to pak bezi cele jenom na procesoru priblizne to same (i9-12900H)takze mozna kdyz model je jen o malicko vetsi tak to k necemu byt muze ale pro neco vetsiho asi ne.
-
@fanoush – presne toto som mal na mysli v mojom komentári "Unified Memory Dome"!
Je jasné, že natívne CUDA Unified Memory, ako lepšiu alternatívu k Greenboostu, treba natrénovať užívateľsky v aplikácii... O čo ide? Tá premenná (cez GGML_CUDA_ENABLE_UNIFIED_MEMORY=1) zapne CUDA Unified Memory (cudaMallocManaged + automatickú migráciu stránok driverom). Model sa načíta "ako keby celý do GPU", ale všetko, čo sa nezmestí do VRAM, driver sám presunie do systémovej RAM bez kernelu (a neskôr aj späť). Žiadny kernel modul, žiadny LD_PRELOAD – čistý oficiálny CUDA 12+ mechanizmus (presne to, čo som vám písal v "Unified Memory Dome"). Všetko čo ste ukázal v logoch (rýchlosť v tokenoch podľa situácie) je presne ten "druhý koniec mince", o ktorom som písal v komentári…
(...Na gpt-oss-20b (cca 20 GB model na 8 GB VRAM RTX A2000): s premennou potom plný offload do GPU (10949 MiB CUDA buffer), GPU ide na 34 W, 20 t/s... Bez premennej potom klasický -ngl offload + CPU mapped buffer, celé je pomalšie... Na väčšom Qwen3.5-27B: s premennou potom "všetko do GPU", ale výkon 0,3 t/s (totálne nepoužiteľné, lebo PCIe sa zadusí masívnym swapovaním)... Bez premennej potom hybrid CPU+GPU pre asi 2 t/s (ešte použiteľné)...)
Ak sa bavíme o Ollame (a starších llama.cpp setupoch), ktorá ignoruje Unified Memory a robí primitívny offload (polovica na CPU = pomalé) – tak je to problém. Zdalo by sa, že bude "env var" ako "riešenie" – lenže treba spomenúť aj nasledovné... Na RTX 40xx (Ada) je Unified Memory oveľa efektívnejší (lepší MMU + page migration engine). Stále však potrebujete tuning (-ngl 99 alebo auto + prefetch hints...cudaMemPrefetchAsync), inak sa to zadusí ako u vás na Qwen3.5. Greenboost je super hack pre appky, ktoré Unified Memory nepodporujú (staršie Ollama, ExLlama atď.), ale na moderné llama.cpp + RTX 40xx už stačí natívny CUDA stack. No a vLLM / TensorRT-LLM + PagedAttention + GDS je ešte vyššia liga (to ste si zatiaľ vôbec nespomenuli).
Zdalo by sa, že sú tu "dopletené uvažovacie vlákna"... avšak, ono sa vlastne len ukazuje že čiastočné riešenie (len "env var") je neefektívne, bez videnia celej hierarchie, ktorú som opísal (Unified Memory + PagedAttention + GDS). Je to ako keby niekto ukázal, že "máme kľúč od dverí"(env var), ale v záznamoch budovy je ešte napísané "a ešte máme výťah a eskalátor" (PagedAttention + GDS). Takže vám dávam úplne za pravdu, že env var už existuje a je lepší ako Greenboost. Ja len pridávam pravdu, že na RTX 40xx to ide ešte ďalej a bez kompromisov.
GGML_CUDA_ENABLE_UNIFIED_MEMORY=1 je natívny spôsob (cudaMallocManaged), o ktorom som písal – žiadny kernel, žiadny Greenboost hack. Na gpt-oss-20b vám to pekne funguje (plný GPU load), ale na väčšom modeli (Qwen 27B) vás to zadusí, lebo driver swapuje všetko cez PCIe bez inteligencie. Na RTX 40xx (4080/4090) to ide ešte lepšie, keď pridáte ("vyššia liga"): (A) vLLM s PagedAttention (KV cache ako virtuálna pamäť OS, swapuje stránky bez fragmentácie) / alebo (B) GPU Direct Storage (GDS) pre NVMe vrstvu (GPU priamo do NVMe s priechodom mimo CPU/RAM je potom ako takmer nekonečná pamäť pre KV cache pri long-context modeloch). Výsledok: 14–24× rýchlejšie ako čistý unified memory offload a žiadny pokles na "0,3 t/s" (hlavne varianta A).
Greenboost je super pre staré appky, ale na moderné llama.cpp/Ollama + RTX 40xx už stačí natívny CUDA stack. Skúšali ste vLLM (alebo GDS) na svojom A2000 alebo 40xx? @Wasper – vy ste spomínal testy s Greenboostom, ako to dopadlo?
ČLÁNKY DO MAILU