12 novembre 2026 · Team VRAMfarm

Llama 70B su una sola GPU: 4 bit o FP8, 48 GB o 80 GB, e le velocità reali

Il primo tentativo di solito va così: una scheda da 24 GB, ollama run llama3.3:70b, e una risposta che esce a fatica, a due o tre token al secondo. Non c’è niente di rotto. Il modello a 4 bit pesa 43 GB, quindi Ollama ne ha messo in silenzio quasi metà nella RAM di sistema. Una sola scheda fa girare un modello da 70B a velocità di lettura solo se il modello ci sta tutto: una scheda da 48 GB per una persona con un contesto normale (circa 12–18 token al secondo), oppure una da 80 GB per documenti lunghi, più utenti o la qualità dell’FP8 (25–50 token al secondo).

Tutto quello che segue usa Llama 3.3 70B, e i numeri valgono anche per gli altri modelli densi da 70B costruiti su di esso, come DeepSeek R1 Distill Llama 70B. Un modello da 72B come Qwen2.5 72B è qualche gigabyte più grande (circa 47 GB in Q4_K_M), e su una scheda da 48 GB non lascia quasi spazio alla cache.

Prima scegli il formato

Ogni runtime ha il suo formato di file, e il formato decide la dimensione, e con essa la scheda.

GGUF è il formato di llama.cpp, e lo usa anche Ollama. Un solo file contiene i pesi, e il runtime può tenere alcuni layer sulla CPU se la GPU non basta: è il suo punto di forza e anche la trappola del primo paragrafo. Q4_K_M è la scelta abituale per un 70B.

AWQ e GPTQ sono formati a 4 bit pensati per i server GPU. vLLM li fa girare entrambi con kernel veloci su tutte le schede dalla generazione Ampere in poi, cioè su tutto il nostro catalogo. La qualità è simile; scegli una build da una fonte mantenuta e con molti download.

L’FP8 dimezza l’originale quasi senza perdite. Le schede lo calcolano in modo nativo dalla generazione Ada in poi (serie RTX 40, L40S), e su Hopper (H100, H200) e Blackwell (serie RTX 50, RTX PRO 6000, B200). Un modello da 70B in FP8 chiede circa 71 GB, quindi in pratica FP8 significa una H100 da 80 GB, una RTX PRO 6000 da 96 GB o una H200. La A100 può caricare pesi FP8 in vLLM ma calcola a 16 bit, quindi risparmia memoria senza guadagnare velocità. Le schede Blackwell calcolano anche NVFP4, un formato a 4 bit da circa 40 GB che nei confronti pubblicati spesso resta più vicino alla qualità dell’FP8 rispetto ai metodi a 4 bit più vecchi; il supporto nei runtime è più recente, quindi verifica che la tua versione di vLLM lo indichi.

48 GB o 80 GB: decide il contesto

I pesi sono solo una parte del conto. Llama 3.3 70B tiene circa 0,33 MB di KV cache per token a 16 bit, quindi 8.000 token di conversazione occupano 2,7 GB e il contesto completo di 128k ne occupa 43, quanto i pesi a 4 bit. La guida alla VRAM spiega la formula; ecco cosa significa scheda per scheda.

Sono intervalli, perché le schede differiscono di un gigabyte o due nella memoria utilizzabile, ogni runtime tiene i suoi buffer e vLLM usa solo la quota di scheda impostata con --gpu-memory-utilization. “In totale” conta quando servi un’API: la cache è condivisa tra tutti quelli che parlano con il modello nello stesso momento, quindi 100k token su una scheda da 80 GB sono un documento lungo oppure una dozzina di conversazioni da 8k.

La regola pratica: una scheda da 48 GB come la L40S o la RTX A6000 basta per una persona che chatta o riassume qualche pagina. Prendi una scheda da 80 GB quando incolli documenti lunghi, servi un team o vuoi l’FP8. Anche due schede da 24 GB nella stessa macchina contengono un 70B a 4 bit. Confronta due RTX 3090 a 0,60 € all’ora con una RTX A6000 a 0,72 €; le macchine con più schede sono elencate a parte nel catalogo.

Ollama o llama.cpp: un utente, meno passaggi

Ollama è la strada più breve. Su un server vuoto PyTorch, apri il terminale di Jupyter o collegati via SSH:

curl -fsSL https://ollama.com/install.sh | sh
OLLAMA_CONTEXT_LENGTH=8192 OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve > /workspace/ollama.log 2>&1 &
ollama run llama3.3:70b

Il tag predefinito llama3.3:70b è il Q4_K_M da 43 GB. Impostare di proposito la lunghezza del contesto è importante: se il contesto che chiedi non ci sta, Ollama non dà errore, sposta dei layer sulla CPU. Controlla con ollama ps in un secondo terminale. La colonna PROCESSOR deve dire 100% GPU; qualcosa come 20%/80% CPU/GPU significa che la velocità è appena scesa di cinque-dieci volte, e la soluzione è un contesto più corto o una scheda più grande. Con la cache a 8 bit qui sopra, su una scheda da 48 GB ci stanno anche 16k di contesto.

llama.cpp ti dà più controllo: file di quantizzazione precisi, tipi di cache, come dividere i layer tra due schede. Va prima compilato con CUDA; il confronto tra runtime riporta i passaggi della build. Poi:

pip install -U huggingface_hub
hf download bartowski/Llama-3.3-70B-Instruct-GGUF Llama-3.3-70B-Instruct-Q4_K_M.gguf --local-dir /workspace/models

./build/bin/llama-server -m /workspace/models/Llama-3.3-70B-Instruct-Q4_K_M.gguf \
  -ngl 99 -c 16384 --flash-attn on -ctk q8_0 -ctv q8_0 \
  --host 127.0.0.1 --port 8081

-ngl 99 mette tutti i layer sulla GPU. Sui nostri server la porta 8080 è occupata da Jupyter, quindi usane un’altra e aprila con un tunnel SSH: ssh -p <port> -L 8081:localhost:8081 root@<address>, con porta e indirizzo presi dalla scheda del server, poi vai su http://localhost:8081 per la pagina di chat integrata di llama.cpp. La guida alla chiave SSH spiega come creare la chiave. Su due schede, llama.cpp divide i layer tra le due da solo.

vLLM: un’API per più utenti

vLLM è la scelta giusta quando le richieste arrivano da altri programmi o da altre persone, perché le raggruppa in batch e il suo throughput totale cresce con il numero di richieste in parallelo. Il nostro server vLLM ha già vLLM installato e la porta 8000 pubblicata. Avvia da solo un piccolo modello Qwen 7B, quindi prima fermalo, poi avvia il 70B:

pkill -f "vllm serve"

# scheda da 48 GB: AWQ a 4 bit, contesto breve
vllm serve casperhansen/llama-3.3-70b-instruct-awq \
  --max-model-len 8192 --gpu-memory-utilization 0.95 --max-num-seqs 8 \
  --host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &

# H100 da 80 GB: FP8, qualità quasi originale
vllm serve RedHatAI/Llama-3.3-70B-Instruct-FP8-dynamic \
  --max-model-len 16384 --gpu-memory-utilization 0.95 \
  --host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &

# due schede da 24 GB nella stessa macchina: ogni layer diviso su entrambe
vllm serve casperhansen/llama-3.3-70b-instruct-awq \
  --tensor-parallel-size 2 --max-model-len 8192 --gpu-memory-utilization 0.95 \
  --host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &

Il caricamento richiede diversi minuti dopo il download; tail -f /workspace/vllm.log mostra l’avanzamento. All’avvio vLLM verifica che ci stia almeno una richiesta lunga --max-model-len e, se non ci sta, si rifiuta di partire, con un messaggio che indica il contesto più grande possibile. Abbassa il numero o aggiungi --kv-cache-dtype fp8, che raddoppia lo spazio sulle schede Ada, Hopper e Blackwell. La build FP8 su una H100 è il caso al limite: i pesi occupano circa 72 GB, quindi i 16k qui sopra richiedono l’impostazione 0.95, e contesti più lunghi richiedono la cache fp8 o una scheda più grande. Tieni --api-key: l’indirizzo dell’API funziona da ovunque, e senza chiave chiunque lo trovi può usare la tua GPU. Il nostro server vLLM blocca una versione di vLLM compatibile con il driver CUDA delle macchine; se ne installi una più recente su un server vuoto, controlla prima la versione CUDA mostrata prima dell’avvio.

Quanto va veloce: token al secondo per scheda

Per un solo utente, ogni nuovo token richiede di leggere l’intero modello dalla memoria una volta, quindi la velocità è più o meno la banda di memoria divisa per la dimensione del modello, meno l’overhead. Questi sono token di output per una singola conversazione, ricavati dal calcolo sulla banda e da report pubblici della community, non da benchmark nostri:

Le persone leggono a circa 5–8 token al secondo, quindi in una chat anche la riga più lenta sembra fluida. In pratica contano altri due numeri. La lettura del prompt è molto più veloce della scrittura della risposta, da centinaia a qualche migliaio di token al secondo a seconda della scheda, quindi un documento di 10 pagine richiede da pochi secondi a mezzo minuto prima della prima parola. E con molte richieste in parallelo l’output totale di vLLM su una H100 sale a diverse centinaia o a più di mille token al secondo. L’articolo sul costo per milione di token trasforma queste velocità in batch in euro.

Quanto costa una prima serata, e quando basta un modello più piccolo

Prima viene il download: circa 40–43 GB per una build a 4 bit e circa 72 GB per l’FP8. È traffico fatturato alla tariffa per GB della macchina, indicata prima dell’avvio, più i minuti necessari, da meno di dieci su una linea veloce a mezz’ora su una più lenta. Due ore con Ollama su una L40S costano 2,12 € di tempo GPU, due ore di FP8 su una H100 7,80 €. I prezzi sono in tempo reale, e il prezzo al minuto si blocca quando avvii.

Se torni spesso, puoi tenere il modello nella cartella salvata: 43 GB costano 43 × 0,03 € al mese. Anche il ripristino sul server successivo è traffico, quindi confrontalo con il semplice riscaricamento; l’articolo sui file dopo lo stop fa i conti per entrambe le opzioni.

Prima di fermarti sul 70B, prova un modello da 32B su una scheda da 24 GB. Qwen3 32B a 4 bit sta su una RTX 4090 a 0,59 € all’ora, risponde circa due volte più in fretta, e per molta chat e scrittura di tutti i giorni la differenza da un 70B è piccola. Fai passare gli stessi cinque prompt reali da entrambi nella stessa sessione; il 70B si merita la scheda più grande quando il 32B sbaglia i tuoi fatti o le tue istruzioni. La pagina del modello Llama indica la memoria per ogni dimensione.