GreenBoost: il driver open source che estende la VRAM delle GPU NVIDIA con RAM di sistema e NVMe

Un nuovo modulo kernel Linux open source permette di eseguire LLM di grandi dimensioni su GPU consumer sfruttando DDR4 e storage NVMe come memoria estesa.

Contenuto

GreenBoost: il driver open source che estende la VRAM delle GPU NVIDIA con RAM di sistema e NVMe

Scopri anche

GreenBoost: il driver open source che estende la VRAM delle GPU NVIDIA con RAM di sistema e NVMe

GreenBoost: il driver open source che estende la VRAM delle GPU NVIDIA con RAM di sistema e NVMe

In questo articolo:

Un sviluppatore indipendente ha rilasciato GreenBoost, un modulo kernel Linux open source licenziato sotto GPLv2 che estende in modo trasparente la memoria VRAM delle GPU NVIDIA utilizzando la RAM di sistema DDR4 e lo storage NVMe. La soluzione consente di eseguire modelli linguistici di grandi dimensioni su hardware consumer con VRAM limitata, aggirando le tradizionali limitazioni hardware senza modificare i driver ufficiali NVIDIA.

Architettura tecnica e funzionamento

⬆ Torna su

GreenBoost si compone di due elementi principali: un modulo kernel che alloca pagine DDR4 pinned esportandole come descrittori DMA-BUF, e una libreria CUDA shim iniettata tramite LD_PRELOAD che intercetta le chiamate di allocazione memoria. Il modulo kernel utilizza il buddy allocator per allocare pagine compound da 2 MB per efficienza, esportandole come file descriptor DMA-BUF che la GPU può importare come memoria esterna CUDA tramite cudaImportExternalMemory.

Il collegamento PCIe 4.0, con larghezza di banda circa 32 GB/s, permette alla GPU di accedere direttamente alla RAM di sistema senza coinvolgimento della CPU nel percorso dati. L'architettura prevede tre livelli di memoria: T1 per i layer caldi nella VRAM nativa, T2 per il resto del modello nella DDR4, e T3 come livello di sicurezza su NVMe per overflow aggiuntivi.

La shim library intercetta cudaMalloc, cudaMallocAsync, cuMemAllocAsync, cudaFree e cuMemFree. Le allocazioni inferiori a 256 MB passano direttamente al runtime CUDA originale, mentre quelle maggiori - tipicamente KV cache e pesi del modello che overflowano la VRAM - vengono reindirizzate al modulo kernel e importate come memoria esterna.

Gestione delle limitazioni software

⬆ Torna su

Uno dei punti critici affrontati riguarda Ollama, che risolve i simboli GPU tramite dlopen e dlsym internamente, bypassando LD_PRELOAD su quei simboli. Per gestire questo caso, la shim intercetta anch'essa dlsym utilizzando dlvsym con il tag di versione GLIBC per ottenere un puntatore reale senza ricorsione, restituendo versioni hookate di cuDeviceTotalMem_v2 e nvmlDeviceGetMemoryInfo.

Senza questo accorgimento, Ollama vedrebbe solo i 12 GB nativi della GPU e piazzerebbe i layer sulla CPU, con decadimento prestazionale di 5-10 volte inferiore. Un'interfaccia sysfs situata in /sys/class/greenboost/greenboost/pool_info permette di monitorare l'utilizzo in tempo reale, mentre un thread watchdog kernel controlla la pressione su RAM e NVMe segnalando allo userspace prima che si verifichino condizioni critiche.

Configurazione hardware di riferimento

⬆ Torna su

Il sistema di sviluppo utilizza un processore i9-14900KF, una GPU RTX 5070 da 12 GB con architettura Blackwell e compute capability 12.0, 64 GB di RAM DDR4-3600, un'unità Samsung 990 EVO Plus da 4 TB NVMe, sistema Ubuntu 26.04 con kernel 6.19 e driver NVIDIA 580.x. Con questa configurazione, GreenBoost riesce a caricare il modello glm-4.7-flash:q8_0 da 31,8 GB mantenendo un buon rate di inferenza AI.

Il sviluppatore ha studiato il codice dei moduli kernel open-source NVIDIA per comprendere il funzionamento della gestione dei page fault UVM e il comportamento atteso delle importazioni di memoria esterna CUDA. Ha inoltre analizzato come llama.cpp gestisce l'offload CPU, come ExLlamaV2/V3 struttura la propria KV cache, e come la paged attention di vLLM alloca la memoria.

Strumenti integrati per l'ottimizzazione

⬆ Torna su

Per massimizzare le prestazioni della memoria estesa, GreenBoost include diversi strumenti open-source. ExLlamaV3 fornisce un motore di inferenza ad alte prestazioni con KV cache nativa per GreenBoost. Lo strumento kvpress offre compressione runtime della KV cache tramite algoritmi come ExpAttn, SnapKV e KnormPress, applicabili in tempo di inferenza senza riaddestramento, riducendo significativamente la pressione sulla DDR4 per contesti lunghi.

NVIDIA ModelOpt fornisce quantizzazione post-training in FP8, INT4-AWQ e NVFP4, richiedendo solo un passaggio di calibrazione con circa 512 campioni e nessun riaddestramento. Questa tecnica riduce un modello da 32 GB a circa 16 GB in FP8 o 8 GB con quantizzazioni più aggressive. Unsloth con LoRA permette fine-tuning efficiente di parametri che riesce a far stare un modello da 30B in 12 GB di VRAM tramite quantizzazione base a 4 bit e adapter rank-16.

Porting su Windows e bug individuato

⬆ Torna su

Un altro sviluppatore ha realizzato un porting completo su Windows, consistente in un driver kernel KMDF di circa 1.400 righe che sostituisce greenboost.ko, una DLL shim CUDA di 1.030 righe che utilizza Microsoft Detours invece di LD_PRELOAD, script PowerShell per installazione e diagnostica, e test IOCTL. Il totale comprende circa 4.500 righe distribuite su 17 file. L'architettura si traduce pulitamente una volta mappati i sottosistemi Linux agli equivalenti Windows.

Durante la revisione del codice è stato individuato un bug nella shim CUDA: l'uso di memset per azzerare le entry nella hash table dopo una rimozione crea un problema con open-addressing. Quando una slot viene azzerata, le lookup successive per chiavi con lo stesso prefisso di hash smettono di probeare troppo presto, causando una perdita silenziosa del buffer che resta non registrato in CUDA con il file descriptor DMA-BUF mai chiuso e le pagine pinned fino alla terminazione del processo.

La soluzione proposta prevede l'uso di un marker HT_TOMBSTONE per le slot eliminate invece di azzerarle, preservando le catene di probe mentre permette il riutilizzo delle slot eliminate all'inserimento successivo. La probabilità di occorrenza è bassa poiché richiede collisioni di hash e un ordine specifico di free, ma quando si manifesta causa una memory leak silenziosa senza messaggi di errore.

Limitazioni e requisiti

⬆ Torna su

GreenBoost non sostituisce il driver NVIDIA ma si carica accanto ad esso. Non è una GPU virtuale e non espone un nuovo dispositivo GPU né modifica come le applicazioni vedono il compute device. L'approccio DMA-BUF con importazione memoria esterna è supportato ufficialmente da CUDA e funziona attraverso i driver esistenti. I test sono stati condotti su kernel 6.19 con Ubuntu 26.04, mentre kernel precedenti potrebbero mancare di alcuni simboli esportati necessari.

L'hook dlsym è specifico per come Ollama risolve i simboli CUDA, quindi altri motori di inferenza potrebbero richiedere adattamenti. Il livello T3 su NVMe è lento per accessi casuali: se un workload thrasha pesantemente su T3, le prestazioni degradano significativamente per i vincoli fondamentali di latenza NVMe. L'architettura Blackwell con compute capability 12.0 è la GPU testata primaria, mentre Ada Lovelace e Ampere dovrebbero funzionare ma necessitano di test aggiuntivi.

Requisiti hardware per LLM secondo i vendor

⬆ Torna su

Secondo la documentazione consultata, per i server di modelli linguistici di grandi dimensioni la CPU non è generalmente importante quanto la piattaforma su cui è installata. Le piattaforme consigliate sono Intel Xeon W e AMD Threadripper PRO, entrambe con elevato numero di core, eccellenti prestazioni e capacità di memoria e gran numero di corsie PCIe. Le versioni a 32 core di entrambe sono indicate per utilizzo e prestazioni bilanciate della memoria.

Per le applicazioni server LLM si consigliano GPU di livello Professional o Compute perché offrono quantità maggiori di VRAM e sono più adatte all'ambiente di raffreddamento di chassis server. Esempi includono le RTX 6000 Ada e Blackwell, L40S e H100 di NVIDIA, o le GPU AMD MI Instinct. NVIDIA raccomanda una quantità di memoria di sistema della CPU almeno doppia rispetto alla quantità totale di VRAM della GPU per permettere il pinning completo della memoria.

Considerazioni sulla quantizzazione

⬆ Torna su

Per modelli con 7-13 miliardi di parametri in inferenza quantizzata, sono generalmente necessari 12-24 GB di VRAM. Un metodo per ridurre i requisiti hardware di un LLM è ridurre la quantizzazione, ovvero il numero di bit di precisione dei valori numerici. Questo riduce le dimensioni in memoria del modello permettendo esecuzione più veloce con meno VRAM, ma a discapito della precisione dei risultati.

Di molti modelli sono disponibili versioni preaddestrate con quantizzazioni differenti, e un'analisi del livello qualitativo dei risultati può aiutare a selezionere il compromesso adeguato tra prestazioni e precisione. Per Llama-2 con 7 miliardi di parametri può bastare una GPU con 6 GB di VRAM, mentre per la versione da 70 miliardi è raccomandato avere due GPU per un totale di 48 GB.

Questo articolo è una sintesi basata esclusivamente sulle fonti elencate.

Implicazioni e scenari

⬆ Torna su

L'approccio software-based di GreenBoost potrebbe ridurre la dipendenza da GPU professionali per carichi di inferenza su modelli linguistici, rendendo accessibili configurazioni da 12-16 GB di VRAM a workload pensati per hardware ben più costoso.

  • Scenario 1: gli sviluppatori con GPU consumer come RTX 5070 potrebbero eseguire modelli da 30+ GB senza upgrade hardware, usando DDR4 e NVMe come estensione trasparente.
  • Scenario 2: la disponibilità di un porting Windows amplierebbe l'adozione oltre l'ecosistema Linux, pur con possibili differenze prestazionali dovute all'architettura KMDF.
  • Scenario 3: l'integrazione con strumenti di quantizzazione e compressione KV cache potrebbe rendere sostenibile anche l'uso del livello T3 su NVMe per contesti molto lunghi.

Cosa monitorare

⬆ Torna su
  • Stabilità del modulo kernel su distribuzioni diverse da Ubuntu 26.04 e kernel precedenti al 6.19.
  • Adozione da parte di motori di inferenza alternativi a Ollama e llama.cpp.
  • Eventuali reazioni o integrazioni da parte di NVIDIA nei driver ufficiali.

Nota editoriale: questa sezione propone una lettura analitica dei temi trattati, senza introdurre dati fattuali non presenti nelle fonti.

Fonti

⬆ Torna su

In breve

  • nvidia
  • cuda
  • llm
  • opensource

Link utili

Apri l'articolo su DeafNews