AirLLM: un 70B su una GPU da 4 GB, davvero? Test e limites

#La promessa di AirLLM: un 70B su 4 GB di VRAM

Un modello 70B in quantizzazione Q4 richiede circa 40 GB di VRAM per essere caricato completamente in memoria — cioè una RTX 4090 (24 GB) più una seconda scheda, oppure un Mac Studio con un'ampia memoria unificata. AirLLM afferma di riuscire a far stare lo stesso modello su una scheda da 4 GB, anche su una modesta GTX 1650 o su una T4 gratuita di Google Colab. Non si tratta di un trucco di marketing sulla dimensione del modello: è proprio il modello 70B completo, in FP16 o in 4/8 bit, a generare le risposte.

Il segreto sta in tre parole: il modello non viene mai caricato interamente nella VRAM. AirLLM divide la rete in strati (layer), li memorizza sul disco e carica nella GPU un solo strato alla volta durante il calcolo. La VRAM contiene quindi soltanto i pesi di uno strato più le attivazioni correnti — da qui la necessità di pochi gigabyte.

#Come funziona lo streaming dei layer

Un LLM di tipo transformer è una pila di strati identici nella struttura (attenzione + feed-forward), attraversati uno dopo l'altro. Un Llama 70B ne conta 80. L'inferenza classica carica tutti gli 80 strati nella VRAM in una sola volta e li mantiene tutti in memoria durante l'intera generazione. AirLLM ribalta questo principio.

Suddivisione dei pesi in file su disco

Al primo caricamento, AirLLM spezza i pesi del modello in file separati, uno per livello, salvati sull'SSD. Questa fase di conversione avviene soltanto una volta per modello.

Caricamento on-demand

Per generare un token, il motore carica il layer 1 sulla GPU, esegue i calcoli, libera la VRAM, carica il layer 2, esegue i calcoli e così via fino al layer 80.

VRAM costante

In ogni momento, un solo layer risiede in VRAM. Il picco di memoria dipende dal layer più grande e dalla lunghezza del contesto, non dalla dimensione totale del modello.

Prefetch e quantizzazione su disco

AirLLM precarica il livello successivo durante il calcolo del livello corrente e può comprimere i pesi su disco (quantizzazione a blocchi) per ridurre il volume di dati da leggere.

Il collo di bottiglia è evidente: per ogni token generato, bisogna leggere tutti i pesi del modello dal disco. Per un modello da 70B, questo significa trasferire diverse decine di gigabyte dall'SSD alla GPU per un solo token. È qui che si determinano tutte le prestazioni — e tutti i limiti — di AirLLM.

#Prerequisiti e installazione

AirLLM è una libreria Python che si basa su PyTorch e sull'ecosistema Hugging Face. Non si usa come Ollama (nessun daemon, nessun comando run): si importa in uno script Python. Ecco cosa serve prima di iniziare.

GPU

Qualsiasi scheda NVIDIA con almeno 4 GB di VRAM (CUDA). È disponibile anche il supporto per Apple Silicon (MPS) e CPU, ma queste opzioni sono ancora più lente.

Disco

Un SSD NVMe veloce è indispensabile, così come lo spazio per archiviare il modello decompresso (≈40 GB per un 70B, di più in FP16).

RAM di sistema

16 GB sono sufficienti; AirLLM non carica il modello in RAM, a differenza di un offload CPU classico.

Python

Un ambiente Python 3.10+ con PyTorch e CUDA installati correttamente.

pip install airllm

#Avviare un 70B su 4 GB: il test

Il codice minimo per caricare e interrogare un Llama 70B sta in una quindicina di righe. AirLLM si occupa della suddivisione in livelli alla prima chiamata (metti in conto diversi minuti per la conversione e il download del modello da Hugging Face).

from airllm import AutoModel

# Le modèle est découpé en couches au premier chargement
model = AutoModel.from_pretrained("meta-llama/Meta-Llama-3.1-70B-Instruct")

input_text = ["Explique le layer streaming en une phrase."]
input_tokens = model.tokenizer(input_text,
                               return_tensors="pt",
                               truncation=True,
                               max_length=128,
                               padding=False)

generation_output = model.generate(
    input_tokens['input_ids'].cuda(),
    max_new_tokens=64,
    use_cache=True,
    return_dict_in_generate=True)

output = model.tokenizer.decode(generation_output.sequences[0])
print(output)

1. 01
   1. Primo caricamento

   AirLLM scarica il modello e poi lo converte in file separati per ciascuno strato sull'SSD. Questa fase richiede tempo, ma viene eseguita una sola volta: le esecuzioni successive riutilizzano la cache su disco.
2. 02
   2. Regolazione della compressione

   Il parametro compression='4bit' (o '8bit') riduce la quantità di dati letti dal disco e accelera quindi l'inferenza, a costo di una leggera perdita di qualità — lo stesso compromesso della quantizzazione classica.
3. 03
   3. Generazione

   Ogni token attiva una lettura completa degli 80 strati dall'SSD. La barra di avanzamento procede strato per strato: l'avanzamento appare lento, ed è normale.
4. 04
   4. Misura

   Misura il tempo totale e dividi per il numero di token generati per ottenere il tuo throughput reale in token/s. È l'unico dato che conta per decidere se l'utensile è utilizzabile nel tuo caso.

#Benchmark reale: quanti token al secondo?

È qui che la promessa incontra la realtà fisica. Su un 70B streamato da un SSD NVMe, non si parla di token al secondo ma spesso di secondi per token. L'ordine di grandezza da ricordare, secondo le configurazioni riportate e i nostri test:

70B / NVMe PCIe 4.0 veloce

nell'ordine di 0,1–0,5 token/s, cioè da 2 a 10 secondi per produrre una sola parola. Una risposta di 200 token richiede diversi minuti.

70B / SSD SATA

Ancora da 2 a 5 volte più lento: la banda passante del disco è limitata a circa 500 MB/s e si scende sotto 0,1 token/s.

Confronto 70B caricato in VRAM (2x RTX 4090)

Da 15 a 30 token/s. La differenza rispetto ad AirLLM è di un fattore da 30 a 300, a seconda del disco.

Modello 8B in Q4 su una sola RTX 3060 12 GB

Da 40 a 80 token/s, senza alcuno streaming — per ricordare quanto comfort si perde.

La formula è semplice: per ogni token, bisogna rileggere tutto il modello dal disco. Un 70B a 4 bit pesa circa 40 GB; con una velocità di lettura NVMe di 5 GB/s, servono già 8 secondi di sole operazioni di input/output per token, prima ancora del calcolo. Nessuna ottimizzazione software può aggirare questa barriera finché i pesi risiedono sul disco. Si tratta di un rallentamento da 5 a 30 volte nel migliore dei casi (modelli piccoli, disco molto veloce, compressione aggressiva) e molto maggiore sui modelli grandi.

#Casi d'uso realistici

A 0,2 token/s, AirLLM è inutilizzabile per conversare. Ma esistono scenari concreti in cui la lentezza non è un problema, perché nessuno aspetta davanti allo schermo.

Elaborazione a batch offline

A uno script che deve elaborare 500 documenti con un 70B durante la notte non importa che un documento richieda 3 minuti: il risultato è pronto al mattino. È il caso d'uso più legittimo.

Sperimentazione occasionale

Verificare come risponde uno specifico modello 70B ad alcuni prompt, senza noleggiare una GPU cloud né acquistare hardware, per decidere se vale l'investimento.

Estrazione strutturata non urgente

Generare un insieme di dati, annotare un corpus, produrre embedding o sintesi in background, dove la velocità non è fondamentale.

Accesso a un modello enorme senza budget

Studente, ricercatore o curioso con una sola piccola scheda, che vuole provare un modello che non potrebbe eseguire in altro modo.

#Quando è marketing

La formula «un 70B su 4 GB» è tecnicamente vera, ma è fuorviante sul piano editoriale quando lascia intendere un uso normale. Ecco le situazioni in cui AirLLM non mantiene le sue promesse implicite.

Chat interattiva

Attendere diversi minuti per una risposta uccide qualsiasi conversazione. Per conversare, un modello locale da 8B o 14B che risponde istantaneamente è infinitamente più utile di un 70B che risponde alla velocità di un fax.

Assistente alla programmazione in tempo reale

L'autocompletazione e il pair-programming richiedono risposte in pochi secondi. AirLLM ne è lontano anni luce.

Server multiutente

Impossibile servire più persone: ogni token monopolizza già tutta la banda passante del disco per una sola richiesta.

Produzione

Nessun servizio online può basarsi su AirLLM. La latenza e l'usura dell'SSD (letture massive e continue) lo escludono fin da subito.

#Alternative: prima di tutto la quantizzazione classica

Prima di ricorrere al layer streaming, sfrutta tutte le soluzioni che mantengono il modello in memoria — sono quasi sempre preferibili. La domanda non è «come far stare un 70B in 4 GB», ma «quale modello soddisfa davvero le mie esigenze».

Passare a una quantizzazione con meno bit

Un 70B in Q4_K_M entra in circa 40 GB di memoria, mentre in Q2/Q3 ne richiede molta meno. Ma un 70B quantizzato in modo troppo aggressivo perde qualità: spesso è meglio un 32B in Q4 caricato correttamente.

Scegliere un modello più piccolo e recente

Un 32B (≈19 GB di VRAM) o un 14B (≈9 GB) del 2026 rivaleggia con un 70B del 2024 nella maggior parte delle attività, pur girando istantaneamente su una sola scheda.

Offload CPU/GPU di Ollama o llama.cpp

Questi motori trasferiscono parte dei layer nella RAM di sistema quando la VRAM non basta. È più lento rispetto a caricare tutto sulla GPU, ma molto più veloce di AirLLM, perché la RAM è cento volte più veloce di un SSD.

Noleggiare una GPU cloud per un'esigenza occasionale

Per testare un vero 70B rapidamente una sola volta, un'ora di GPU noleggiata costa poco e fornisce un throughput normale — spesso più conveniente di ore di attesa locale.

#Per approfondire

AirLLM è uno strumento per aggirare i limiti: prima di usarlo, è meglio padroneggiare le tecniche classiche di gestione della VRAM e di scelta del modello. Tre guide del sito completano il quadro.

Scegliere la quantizzazione (Q4, Q5, Q8, FP16)

Capire quanta qualità perde un modello in Q4 o Q3 e come far rientrare un modello grande in una VRAM limitata senza ricorrere allo streaming da disco.

Scegliere la GPU per l'IA locale

I compromessi tra VRAM, budget e prestazioni, dalla RTX 3060 12 GB al Mac Studio Ultra, per capire quali dimensioni di modello il tuo hardware può davvero gestire.

llama.cpp vs vLLM vs Exllama

I motori di inferenza e la loro gestione dell'offload CPU/GPU, un'alternativa valida ad AirLLM quando manca un po' di VRAM.