La nostra configurazione sperimentale: un modello da ~83,6 GB in locale su una RTX 3060 economica

È incredibile!

Qwen3.8-Flash-Next IQ3_S (~83,6 GB) gira in locale su una RTX 3060 12 GB economica con soli 48 GB di RAM di sistema!

Fino a 68 token/s in generazione, ~916 token/s nell'elaborazione del prompt e un prompt da 30K token elaborato in soli 34 secondi.

Basato su Strata di coldniko. Nessuna inferenza nel cloud. Solo hardware consumer accessibile!

Di seguito: misurazioni complete, specifiche hardware, ottimizzazioni e compromessi.

Le conclusioni principali sono riassunte nell'ultima sezione.

L'hardware dietro questi risultati

Nessuna GPU da data center, nessun costoso server multi-GPU, nessuna enorme quantità di RAM.

L'intero esperimento è stato eseguito su un PC consumer/workstation piuttosto ordinario.

CPU

• Intel Core Ultra 7 265 (Arrow Lake)
• 20 core / 20 thread
• Fino a 5,3 GHz
• 30 MB di cache L3
• Supporto AVX-VNNI / BF16; niente AVX-512

Scheda madre

• ASUS Pro Q870I-C
• Chipset Intel Q870, LGA1851
• Formato Mini-ITX

Memoria

• 48 GB DDR5-5600 (2 × 24 GB Micron)
• Circa 46 GiB utilizzabili

GPU

• NVIDIA GeForce RTX 3060 12 GB
• GA106, compute capability 8.6
• PCIe 4.0 ×16
• Limite di potenza configurato a 170 W

Archiviazione

• Lexar NM1090 PRO 2 TB
• PCIe 5.0 ×4 NVMe

OS

• Ubuntu 24.04.5 LTS
• Kernel Linux 7.0.0-38
• Driver NVIDIA 615.71.10

Rete

• Intel 1 GbE Ethernet

Il dettaglio cruciale: il modello è molto più grande della VRAM e della RAM disponibili messe insieme.

È proprio questo che rende interessante l'esperimento.

Modello, motore e architettura della memoria

Modello

Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S

Due shard GGUF:

• 54.82 GB
• 28.80 GB
• Totale: 83,62 GB (77,87 GiB)

Componenti aggiuntivi

• Pesi densi compattati: ~1,5 GiB
• Drafter MTP per la decodifica speculativa
• Adattatore visivo BF16: ~866 MB
• Encoder visivo su CPU (12 thread)

Motore di inferenza

• Strata engine 0.1.52
• Backend CUDA 13.0
• Architettura CUDA sm_86

Allocazione effettiva della memoria

• VRAM della GPU: 11,14 GiB occupati
• Esperti residenti nella RAM di sistema: 24 GiB
• I restanti dati degli esperti vengono letti in streaming dall'NVMe
• Nessuna attività di swap durante la normale inferenza

Impostazioni di configurazione importanti

--expert-cache auto
--prefill 4096
--spec 4
--spec-min-p 0.5
--mtp mtp/rt
--max-context 32768
--kv int8
--kv-grow
--kv-resident 32768
--vision
--vram-reserve-mib 960
--pool-workers 12
--conversation-cache-mib 1536
--prompt-cache-tail
--prompt-cache-spread
--resident-experts
--resident-budget-gib 24

Non è la classica impostazione «carica l'intero modello nella memoria della GPU».

Strata usa insieme la memoria della GPU, la RAM di sistema, la cache degli esperti e l'archiviazione NVMe.

L'ottimizzazione importante è ridurre al minimo i costosi trasferimenti di esperti mantenendo la GPU produttiva.

Risultati reali delle misurazioni

Stesso modello, stesso hardware, due configurazioni di routing.

Modalità A: routing veloce degli esperti, orientato a quelli già residenti (prior = 1.5)

Tempo al primo token a freddo:

• 1K: 3.7 s
• 4K: 4.9 s
• 8K: 9.7 s
• 16K: 17.3 s
• 30K: 33.9 s

Per confronto, la modalità B disattiva il routing orientato agli esperti residenti (prior = 0):

Generazione di 500 token:

• Veloce: 62 tok/s, 7,1 s in totale
• Precisa: 21 tok/s, 20,8 s in totale

Le misurazioni di velocità sono state verificate con i tempi di streaming lato client.

Osservazione principale:

Disattivare il routing orientato alla cache può ridurre la velocità di generazione di circa 2–2,4 volte.

Ma c'è un motivo importante per non lasciare attivo un routing aggressivo per ogni carico di lavoro. Ne parliamo nella prossima sezione.

Velocità contro qualità del modello: il compromesso nascosto

In questa versione del motore Strata, le GPU con ≤13 GB di VRAM usano automaticamente il routing orientato agli esperti residenti:

STRATA_ROUTE_PRIOR=1.5

Così vengono favoriti gli esperti già disponibili nella memoria veloce, invece di scegliere sempre quelli che il router originale preferirebbe.

Il vantaggio è enorme:

• Tasso di hit della cache degli esperti: 97,2% in modalità veloce
• Senza la preferenza: 65,3%
• Letture dall'archiviazione nel carico confrontato: 5,5 GiB contro 46 GiB
• Velocità di generazione: circa 2 volte più alta

Ma questa NON è un'ottimizzazione gratuita.

Cambiare la selezione degli esperti può modificare il comportamento del modello, aumentare la divergenza dal modello originale e influire su ragionamenti lunghi o flussi di lavoro con agenti.

Secondo la valutazione dello sviluppatore su 10 compiti per agenti:

• Routing prior 1.5: 4,5/10
• Routing prior 0: 5,6/10

Gli stessi risultati di riferimento sono variati tra un'esecuzione e l'altra, quindi è un'indicazione di tendenza, non una misura definitiva della qualità.

Le mie sei brevi prove con agenti sono state superate in entrambe le modalità.

Tuttavia, una prova di stress separata sull'unicità ha evidenziato ripetizioni:

• Modalità veloce: 205 righe, 96 duplicati
• Modalità precisa: 209 righe, 79 duplicati

La conclusione è semplice:

• Routing veloce per chat, uso interattivo e compiti brevi.
• Routing originale per flussi di lavoro con agenti più lunghi e sensibili alla qualità.

E la sola velocità di un benchmark non va mai confusa con la qualità del modello.

La cache dei prompt cambia tutto

Uno dei risultati più impressionanti non è stata la velocità di generazione, ma il tempo di risposta alle richieste ripetute con lo stesso prompt.

Con un prompt interamente in cache:

In queste esecuzioni il tempo al primo token è circa 45–90 volte inferiore.

La cache dei prompt fa un'enorme differenza quando si interroga più volte lo stesso documento lungo o si porta avanti una conversazione con un contesto stabile.

Il motore è configurato anche per la cache delle conversazioni:

• Budget di cache di 1536 MiB
• Minimo 4096 token per il parcheggio
• Soglia minima di memoria libera: 1536 MiB

C'è un limite: questi risultati valgono per prompt identici con una cache interamente riutilizzabile.

Non significano che un nuovo prompt qualsiasi da 30K token venga elaborato in mezzo secondo.

Ma per l'IA locale interattiva una cache calda cambia le regole del gioco.

Il mistero dell'SSD: il collo di bottiglia non è il PCIe 5.0

All'inizio l'unità NVMe sembrava sospettosamente lenta. Abbiamo analizzato il collegamento PCIe, la topologia dell'archiviazione e il comportamento reale dell'I/O.

L'unità: Lexar NM1090 PRO 2 TB, PCIe 5.0 ×4.

Collegamento PCIe verificato:

• Collegamento attuale: 32.0 GT/s ×4
• Collegamento massimo: 32.0 GT/s ×4
• Root port della CPU: 32.0 GT/s ×4

Quindi l'unità funziona alla piena velocità del collegamento PCIe 5.0.

Misurazioni di lettura diretta senza cache:

• Flusso singolo, blocchi da 1–4 MiB: 2,9–3,4 GB/s
• Quattro flussi paralleli: 10,94 GB/s
• Quattro flussi, blocchi da 64 KiB: 2,25 GB/s
• Quattro flussi, blocchi da 4 KiB: 0,26 GB/s (~63K IOPS)

Il risultato parallelo di 10,94 GB/s è particolarmente importante: supera la larghezza di banda pratica del PCIe 4.0 ×4.

Perché il throughput a flusso singolo è molto più basso?

Perché la larghezza di banda PCIe non coincide con il throughput a livello di applicazione.

Contano la profondità della coda, la dimensione dell'I/O, il parallelismo delle richieste e la latenza.

Lo schema di caricamento degli esperti di Strata è molto più vicino al caso a bassa concorrenza che a un benchmark sintetico di throughput massimo.

Throughput di archiviazione osservato del motore:

• Routing veloce: ~0,3 GB/s
• Routing originale: ~2,4 GB/s

La differenza dipende da quanti esperti devono essere caricati, non da un declassamento del PCIe.

Un altro dettaglio utile: la RTX 3060 stessa è un dispositivo PCIe 4.0. Vedere il suo collegamento scendere a Gen1 a riposo è un normale comportamento di risparmio energetico.

Prima di diagnosticare un problema PCIe, verificate sempre quale dispositivo state misurando.

Una lezione importante: non lasciate che Linux metta in cache un modello da 83,6 GB su una macchina da 48 GB

Durante il primo avvio abbiamo incontrato un problema serio.

La prima configurazione consentiva il caricamento bufferizzato dei file del modello.

Il modello pesa ~83,6 GB, mentre il sistema ha solo 48 GB di RAM fisica.

Con quel carico Linux è entrato in una forte pressione di recupero della memoria. La macchina è diventata quasi irraggiungibile, anche via SSH, ed è servito un riavvio forzato.

La soluzione è stata cambiare la strategia di caricamento e introdurre protezioni per la memoria.

Impostazioni attuali:

• STRATA_UNBUFFERED_LOAD=1
• STRATA_RESIDENT_HEADROOM_GIB=10
• Budget di 24 GiB per gli esperti residenti
• Verifica della memoria disponibile prima dell'avvio
• Margine di sicurezza aggiuntivo di 12 GiB nella politica di avvio

Dopo queste modifiche:

• Nessuna attività di swap durante la normale inferenza
• Circa 34,6 GiB di RAM in uso nel momento osservato
• Circa 12,7 GiB disponibili
• Generazione stabile sotto carico

La lezione:

Eseguire un modello più grande della memoria fisica è possibile, ma il conteggio della memoria è assolutamente critico.

Pressione sulla page cache, dati del modello bloccati in memoria, esperti residenti e cache KV vanno considerati insieme.

Non copiate alla cieca i flag di massime prestazioni da macchine con molta più RAM.

Consumo energetico, temperature e costo dell'inferenza

Un'altra piacevole sorpresa.

Potenza misurata dei componenti:

A riposo con il modello caricato:

• CPU: ~5.8 W
• GPU: 15–18 W

Durante la generazione:

• CPU: ~62.8 W
• GPU: 152–167 W
• Brevi picchi della GPU intorno a 174 W

Potenza totale stimata del sistema alla presa (non misurata con un wattmetro):

• A riposo: ~54 W
• In generazione: ~280 W

Temperature osservate:

• GPU sotto carico: 62–68 °C
• GPU a riposo: ~40 °C
• NVMe: 38–47°C

Nessun thermal throttling osservato.

Con un prezzo dell'elettricità ipotizzato di 0,25 €/kWh:

• 24 ore a riposo: ~0,32 €
• 30 giorni continuativi a riposo: ~9,72 €
• Un'ora di generazione attiva: ~0,07 €

Questo rende del tutto realistico gestire a casa un servizio di IA locale capace e rispettoso della privacy.

Naturalmente si tratta di costi elettrici stimati, non del costo totale di possesso. Ammortamento dell'hardware, raffreddamento e manutenzione sono esclusi.

Dove la configurazione con RTX 3060 smette di avere senso

Questa configurazione è eccellente per brevi richieste interattive, ma ha dei limiti.

I più importanti:

• Contesto massimo: 32.768 token
• Un prompt vicino a 32K lascia spazio insufficiente per la generazione
• Il tetto pratico nelle misurazioni è stato di ~30.165 token in ingresso
• Il ragionamento (thinking/reasoning) può consumare centinaia di token generati in più
• Le sessioni lunghe con agenti incontrano presto dei vincoli

Per confronto, ho eseguito lo stesso modello su un sistema locale più potente con una GPU da 24 GB.

Prestazioni misurate su quel sistema:

• Prefill di un prompt 4K: 1.339 tok/s
• Generazione a 4K: 94 tok/s
• Prefill di un prompt 16K: 2.956 tok/s
• Generazione a 16K: 125 tok/s
• Contesto massimo: 262.144 token
• 15 thread di lavoro

Il sistema con RTX 3060 offre un throughput di prefill molto più basso e circa la metà del throughput di generazione in casi comparabili, con un ottavo del contesto disponibile.

Tuttavia la scheda da 12 GB è molto più accessibile e resta sorprendentemente utile.

Il mio approccio attuale:

• Hardware più potente per agenti complessi e di lunga durata
• GPU accessibili da 12 GB per chat, flussi brevi, esperimenti e inferenza di riserva

Il punto non è fingere che una GPU economica sostituisca una macchina di fascia alta.

Il punto è quanta IA locale utile si possa già eseguire su hardware poco costoso.

Cosa si potrebbe ancora ottimizzare?

Il sistema funziona già bene, ma ci sono alcune direzioni interessanti per ulteriori esperimenti.

Inferenza concorrente

L'opzione --slots 2 potrebbe migliorare il throughput totale con due conversazioni simultanee.

Per questo carico è possibile un throughput aggregato stimato di +10–12%, ma va verificato.

Questo non significa che una singola conversazione diventi più veloce del 12%.

Batch di prefill più grandi

Attuale: --prefill 4096

Candidato: --prefill auto:16384

Finestre di prefill più ampie potrebbero migliorare l'elaborazione dei prompt lunghi, ma la VRAM disponibile è già al limite.

Con circa 11,14 GiB occupati sui 12 GiB della GPU, il comportamento della memoria va misurato con attenzione.

Più RAM di sistema

L'uso di --ple-io ram potrebbe portare più dati del modello nella memoria di sistema e ridurre le letture dall'archiviazione.

La documentazione dello sviluppatore indica:

• +16–31% di prestazioni in prefill
• +3–11% di prestazioni in generazione

Ma questa configurazione richiederebbe molta più RAM, circa 72+ GiB per la disposizione misurata.

Non è praticabile sull'attuale configurazione da 48 GB.

Decodifica speculativa

La decodifica speculativa MTP è già attiva.

Accettazione osservata: ~33–41 token accettati su 50–60 proposti, cioè circa il 65–70%.

Contesto più lungo

L'attuale limite di 32K è un limite operativo della configurazione, non la prova che il modello stesso supporti solo 32K.

Aumentarlo richiede di verificare di nuovo capacità di memoria, comportamento della cache KV, latenza e stabilità.

Per questo carico, ridurre le costose letture degli esperti e migliorare gli schemi di accesso può contare più che aumentare la larghezza di banda sequenziale massima dell'unità.

Come sempre: misurate il carico reale, non solo i numeri di marketing dell'hardware.

Conclusioni

Ecco cosa dimostra questo esperimento.

Un modello MoE quantizzato da ~83,6 GB può girare in locale su:

• RTX 3060 12 GB
• 48 GB DDR5 RAM
• CPU Intel consumer
• PCIe 5.0 NVMe SSD
• Ubuntu + Strata

Con risultati misurati fino a:

• 68 tok/s di generazione a caldo
• 916 tok/s di elaborazione del prompt
• Prompt da 30K token a freddo in ~34 secondi
• Prompt da 30K interamente in cache: ~0,44 s al primo token
• Nessuno swap in condizioni operative normali

Ma ci sono avvertenze importanti.

• Il contesto massimo configurato è 32K
• Il routing veloce degli esperti cambia il comportamento del modello
• La massima velocità non coincide necessariamente con la massima qualità
• Le prestazioni dell'archiviazione dipendono dagli schemi di accesso
• La gestione della memoria richiede una messa a punto accurata
• Gli agenti di lunga durata traggono vantaggio da hardware più potente

Mi interessa in particolare l'economia pratica dell'IA locale.

Non solo il benchmark massimo su un sistema da 10.000 €, ma le prestazioni utili ottenibili su macchine consumer e configurazioni accessibili a partire da circa 1.000 €.

Privacy, indipendenza, costi operativi sotto controllo e utilità reale contano più della sola rincorsa a numeri di benchmark impressionanti.

È ancora un esperimento in evoluzione e continuerò a condividere misurazioni, fallimenti, modifiche di configurazione e miglioramenti.

Il futuro dell'IA locale sta già diventando sorprendentemente accessibile.

Aggiunte successive

Ah, dimenticavo di dire che la GPU funziona con NVIDIA Unlock, uscito solo pochi giorni fa, la settimana scorsa.

Ho appena chiesto al mio agente IA di ripetere gli stessi benchmark senza l'unlock, così tra circa 15–20 minuti potremo confrontare i risultati.

Nei prossimi giorni, ma non oggi, installerò questa GPU in un sistema che costa meno di 1.000 dollari e vedrò come si comporta lì.

Thread originale su X · Tutte le notizie