La scommessa silenziosa dell'hardware "superato"

Due RTX 3090, PCIe 3.0 saturo, DDR4-2133 e una coppia di Xeon E5-2696 v4: sulla carta, una workstation che molti team metterebbero in dismissione. Invece, i numeri raccolti da un post tecnico recente raccontano un'altra storia. Con llama.cpp e la quantization UD-Q6_K_XL di Qwen3.8-Flash-Next, il decode passa da circa 17 token/s a 25-29 token/s su contesti brevi e medi. A 131.000 token di profondità, il miglioramento è altrettanto visibile: da 12 a circa 17 token/s. Il contesto pieno resta 261.888 token, con KV in f16.

Il dato non sta solo nell'accelerazione. Sta nel fatto che il salto arriva senza sostituire le GPU, senza passare a PCIe 4.0 e senza aggiornare la RAM. Arriva da una modifica software: la PR #27861 di llama.cpp introduce una cache LRU degli esperti residente in GPU. È un cambio di prospettiva che tocca direttamente il cuore delle strategie on-premise.

Per AI-RADAR questo è un segnale da isolare. Non perché due 3090 diventino improvvisamente una piattaforma da training, ma perché la fattibilità dell'inference MoE si sposta dal puro inventario di VRAM alla gestione intelligente della gerarchia di memoria. E in quella partita, l'hardware datato ha margini più ampi di quanto i benchmark su singola GPU lascino intendere.

Il punto di partenza è un'architettura con 48 layer di esperti pinnati nella RAM di sistema. La GPU non contiene l'intero modello: contiene una cache veloce. Quando il runtime indovina quali esperti servono, l'inference accelera. Quando sbaglia, paga il costo di rileggerli dalla RAM host. La differenza tra questi due stati è un nuovo fattore di progettazione.

Perché la cache degli esperti cambia le regole

La PR #27861 non carica interi layer di esperti in VRAM. Tiene in cache gli esperti usati più di recente per ogni layer. La scommessa è semplice: un modello MoE tende a scegliere per un token gli stessi esperti dei token precedenti. I dati riportati parlano di un tasso di successo dell'80-85% sul codice e più alto sulla prosa. Quando il runtime indovina, evita di rileggere dalla RAM di sistema. Quando fallisce, paga un costo in latenza.

Questo meccanismo ha una conseguenza immediata: il ruolo della VRAM cambia. Non è più un archivio completo, ma una cache. La distinzione è sottile e fondamentale. Un archivio cresce con la dimensione del modello. Una cache cresce con la località degli accessi. Se gli accessi sono prevedibili, una cache piccola può produrre un guadagno sproporzionato. Se sono casuali, serve capacità. Il caso Qwen3.8-Flash-Next mostra che, almeno su codice e prosa, la località c'è.

Un secondo passaggio decisivo è l'abbassamento dell'ubatch da 2048 a 512. I buffer di calcolo scalano con l'ubatch. Riducendolo, si liberano circa 5 GB per GPU. La cache passa da 80 a 135 slot per layer a contesto pieno. Il prezzo è un prefill più lento sui prompt lunghi. I prompt brevi restano sostanzialmente invariati. È un trade-off esplicito: privilegiare il decode continuativo rispetto all'elaborazione iniziale di contesti ampi.

Non tutti i parametri rispondono allo stesso modo. L'autore segnala che thread count, poll, CPU masks, KV q8, lazy PLE e i draft n-gram sulla prosa non hanno prodotto benefici o hanno peggiorato le prestazioni. Il multi-token prediction a temperatura 0,7 è controproducente perché i batch di verifica rileggono gli esperti dalla RAM host. Funziona solo in greedy o a contesto profondo. Più di due upload di cache per passo saturano il PCIe 3.0 e fanno crollare il tasso di successo.

Il baricentro si sposta: non più solo capacità, ma scheduling

Il risultato sposta il baricentro del problema. Nei modelli MoE, la VRAM non è più l'unico indicatore di fattibilità. Contano la gerarchia di memoria e la politica di cache. Un sistema con PCIe 3.0 saturo e DDR4 lente può comunque migliorare in modo misurabile, se il software evita di rileggere da RAM gli esperti già presenti in GPU. È una lezione che vale per molti deployment on-premise.

Le implicazioni di secondo ordine sono concrete per chi gestisce cluster con hardware non recente. Il costo marginale di tenere in vita due 3090 scende. Il TCO di macchine più nuove va giustificato con carichi in cui il prefill o il training continuo dominano. Se il caso d'uso è principalmente decode su contesti lunghi e prevedibili, l'investimento in GPU moderne non è automaticamente il più razionale.

C'è anche un'ulteriore sfumatura: la cache degli esperti premia i carichi con località temporale alta. Codice e prosa sono due esempi. Altri carichi potrebbero comportarsi diversamente. Un sistema di serving generalista, con prompt molto vari per dominio e stile, potrebbe avere tassi di successo inferiori. La scelta di adottare questa tecnica non è neutra: va calibrata sulla natura reale del traffico.

Il confine tra caching e scheduling si fa poroso. La cache LRU decide implicitamente quali esperti restano in GPU e quali vengono riletti. Ma non pianifica nulla in anticipo. Un passo successivo potrebbe essere una politica predittiva, che usi la storia recente per precaricare gli esperti probabili prima del passo successivo. Non è ancora quello che fa la PR #27861, ma è una direzione che il caso rende naturale.

Chi ne beneficia e chi perde

I beneficiari immediati sono i team con workstation o piccoli server dotati di GPU consumer di generazione passata. Due RTX 3090 in PCIe 3.0 non servono solo per esperimenti: possono sostenere un decode fluido su un modello MoE con contesto ampio. Il costo di ingresso per l'inference self-hosted scende. La sovranità dei dati diventa più accessibile, perché non serve noleggiare GPU cloud di ultima generazione.

Ne beneficia anche chi deve estendere la vita utile dell'hardware esistente. In molti contesti enterprise, il rinnovo delle macchine passa da processi lenti. Poter migliorare l'inference con una modifica software riduce la pressione sul budget. Non è una bacchetta magica: il prefill su prompt lunghi peggiora e alcune tecniche avanzate smettono di funzionare. Ma per una classe di workload, il guadagno è reale.

Perde chi ha costruito il proprio dimensionamento solo sulla VRAM totale. Se la cache degli esperti diventa una pratica comune, i modelli MoE potrebbero essere valutati in modo diverso. Una GPU con meno VRAM ma un'interconnessione solida e una cache ben gestita può battere una GPU con più memoria ma software meno maturo. Il parametro "GB di VRAM" non scompare, ma smette di essere il solo metro di giudizio.

Perdono anche i vendor che spingono hardware nuovo come unica soluzione per l'inference MoE. La narrativa del "serve l'ultima GPU" si indebolisce. Resta vera per il training continuo, per il prefill massiccio o per modelli densi molto grandi. Ma per il decode MoE su hardware condiviso, la software-defined inference cambia l'equazione. Il TCO si sposta: meno hardware, più ingegneria software.

Il framework più ampio: l'inference diventa un problema di caching

Il caso Qwen3.8-Flash-Next segnala una direzione. L'inference MoE sta diventando un problema di caching e scheduling, non solo di capacità. È un tema che attraversa tutta l'AI infrastructure: dalle cache KV ai prefix caching, dalle code di scheduling alle politiche di preemption. La PR #27861 aggiunge un tassello specifico: la cache degli esperti.

Il concetto non è nuovo nella storia dei sistemi. La gerarchia di memoria è da decenni il cuore delle architetture di calcolo: registri, cache L1, L2, L3, RAM, storage. Portare questo schema nell'inference MoE significa applicare ai pesi del modello la stessa logica che si applica ai dati. Gli esperti usati di frequente stanno vicini alla GPU. Gli altri aspettano in RAM. L'efficienza dipende dalla qualità della previsione di accesso.

Questo apre interrogativi di secondo e terzo ordine. Perché non usare cache più grandi, magari su più GPU? Perché non condividere la cache tra più richieste concorrenti, così da aumentare il tasso di successo? Perché non esporre la politica di cache come API, così che l'applicazione possa suggerire gli esperti da tenere in GPU? Non sono ipotesi presenti nella fonte, ma sono conseguenze logiche di un campo in movimento.

C'è anche una lettura per il mondo open source. llama.cpp master e la PR #27861 sono sufficienti per replicare il risultato. Non serve un fork. Questo abbassa la barriera di sperimentazione. Chi vuole testare la tecnica sulla propria workstation può farlo rapidamente. La velocità di iterazione diventa essa stessa un vantaggio competitivo per i team on-premise.

Cosa guardare adesso

Il prossimo test dichiarato è la quantization UD-Q4_K_XL, seguita da un possibile ritorno sul multi-token prediction. La Q4 riduce l'ingombro in VRAM e potrebbe aumentare ulteriormente il numero di slot di cache per layer. Ma introduce un rischio: una perdita di qualità del modello. Il bilanciamento tra cache più ampia e precisione dei pesi è una delle variabili da monitorare.

Un secondo segnale da osservare è la dimensione della cache. L'autore stima circa 100 MB per slot per GPU su Q6. La calibrazione dipende dalla VRAM residua dopo i buffer KV e di calcolo. Su configurazioni diverse, la dimensione ottimale cambia. Non esiste un valore universale. Questo rende la tecnica più simile a un'arte di tuning che a un'opzione standard.

Un terzo segnale è l'evoluzione delle interconnessioni. Su PCIe 3.0 saturo, più di due upload di cache per passo fanno crollare il tasso di successo. Su PCIe 4.0 o 5.0, quel limite potrebbe spostarsi. Ma anche con interconnessioni più veloci, la rilettura dalla RAM resta un costo. La gerarchia di memoria non sparirà: aumenterà solo la sua tolleranza agli errori di cache.

Infine, vale la pena osservare se altri framework adotteranno tecniche simili. Se la cache LRU degli esperti diventasse un'opzione standard in più runtime, l'inference MoE su hardware datato si normalizzerebbe. In quel caso, il vantaggio competitivo si sposterebbe dalla semplice adozione alla messa a punto fine delle politiche di cache per workload specifici. Per chi valuta deployment on-premise, AI-RADAR continuerà a raccogliere su /llm-onpremise strumenti analitici per soppesare questi trade-off.