Il segnale oltre il dato grezzo: contesto, VRAM e stabilità operativa

Il test di LFM2.5-24-A2B su AMD W7900 restituisce un numero che da solo racconta poco: circa 95 token al secondo. La parte interessante è l'insieme delle condizioni in cui quel risultato emerge. Il modello, in versione Q8, occupa circa 30 GB di VRAM e gestisce una finestra di contesto di 128.000 token. Su una singola scheda professionale, questa combinazione sposta il confine di ciò che un team può eseguire localmente senza ricorrere a cluster o servizi cloud. Non è la velocità di picco a fare la differenza, ma il fatto che il dato arrivi insieme a una capacità di contesto estesa e a un profilo di stabilità descritto come adatto a compiti meccanici e ricorsivi.

Per chi progetta stack on-premise, il contesto da 128.000 token apre scenari concreti: analisi di codebase estese, revisione di documenti lunghi, elaborazione di log o trascrizioni senza dover spezzare il testo in blocchi che costringono a perdere riferimenti. Il costo di questa capacità si misura in VRAM, che cresce con l'estensione del contesto e con la precisione della quantization. La scelta di una versione Q8, piuttosto che una Q4 più leggera, indica una preferenza per la qualità della rappresentazione numerica pur accettando un ingombro maggiore. Su 30 GB, una singola W7900 basta; su altre schede con meno memoria video, lo stesso setup non sarebbe replicabile senza compromessi.

La stabilità descritta dall'utente è un elemento spesso trascurato nelle valutazioni preliminari. Molti modelli mostrano buoni numeri su prompt brevi, ma degradano quando vengono usati in sessioni lunghe, con chiamate ripetute o pipeline di agenti. LFM2.5-24-A2B viene definito un «cavallo da battaglia» per compiti meccanici e ricorsivi, e questo ha un valore operativo preciso: significa meno interruzioni, meno errori da gestire, meno necessità di supervisione umana su attività ripetitive. In un contesto aziendale, dove i carichi batch possono durare ore, la capacità di mantenere un comportamento prevedibile è un criterio di selezione tanto quanto i token al secondo.

Il terzo ordine di questa osservazione riguarda la classificazione dei carichi di lavoro. Quando un modello da 24 miliardi di parametri si dimostra affidabile per attività procedurali, una parte dei flussi che oggi girano su modelli più grandi o su API cloud può essere spostata su hardware locale. Questo non elimina i modelli di fascia alta, ma riduce il numero di chiamate che devono arrivare a loro, liberando risorse e abbassando i costi operativi. Il risultato è un'architettura in cui l'on-premise non sostituisce tutto, ma assorbe la quota ripetitiva e sensibile del lavoro.

AMD e ROCm: una seconda via per l'inference locale

Il test su W7900 con llama.cpp e accelerazione ROCm ha una portata che va oltre il singolo modello. Per anni l'inference locale di LLM è stata associata all'ecosistema CUDA e alle GPU NVIDIA. La presenza di una scheda AMD che esegue un modello da 24 miliardi di parametri con una finestra di contesto estesa e una velocità sostenuta dimostra che il panorama si sta allargando. Non si tratta di una compatibilità episodica: llama.cpp è un runtime open source con supporto attivo per diverse backend, e ROCm ha accumulato miglioramenti che rendono sempre più praticabile l'uso di hardware AMD in contesti di inference.

Questo allargamento ha implicazioni dirette sul Total Cost of Ownership. Le organizzazioni che valutano infrastrutture locali possono confrontare configurazioni con quantità di VRAM diverse senza essere vincolate a un unico fornitore di silicio. Una scheda professionale con 32 GB di VRAM può ospitare modelli con quantization a 8 bit o più leggeri che, fino a poco tempo fa, richiedevano soluzioni più costose o il cloud. Il TCO non si riduce però al prezzo di acquisto: vanno considerati consumi elettrici, raffreddamento, spazio nei rack e soprattutto il costo del personale che deve mantenere aggiornati driver, runtime e pipeline. La possibilità di scegliere tra più vendor introduce concorrenza, ma non elimina la complessità operativa.

Il trade-off principale resta la maturità relativa del software. ROCm ha fatto passi avanti, ma il supporto per alcune librerie, operatori e modelli può variare rispetto all'ecosistema CUDA. Non tutti i modelli girano con la stessa efficienza su tutte le schede AMD, e la validazione va fatta caso per caso. Per un team tecnico, questo significa pianificare test comparativi e mantenere una matrice di compatibilità tra versioni di runtime, modelli e schede. Chi cerca una soluzione plug-and-play troverà ancora differenze; chi ha competenze interne può sfruttare la flessibilità.

Il segnale per il mercato è comunque chiaro: l'inference on-premise non è più sinonimo di NVIDIA. La combinazione tra modelli efficienti come LFM2.5-24-A2B e runtime open source come llama.cpp riduce la dipendenza da un singolo stack. Questo sposta il potere negoziale verso chi acquista hardware e rende più credibili le strategie di diversificazione del parco GPU. Per i fornitori storici, la pressione non arriva solo dai concorrenti diretti, ma dalla crescente disponibilità di alternative che possono essere integrate senza riscrivere l'intera architettura.

La divisione del lavoro: un «cavallo da battaglia» accanto ai modelli da insight

La fonte accenna a un confronto con il precedente Ornith 1.5-35B e riporta che il nuovo modello si comporta bene nei compiti meccanici e ricorsivi, mentre l'analisi per compiti che richiedono insight più profondi è ancora in corso. Questa distinzione è più importante di quanto sembri. Nel deployment di LLM, il parametro di riferimento non è solo la qualità assoluta, ma l'idoneità a classi specifiche di attività. Un modello da 24 miliardi di parametri può essere inefficiente per ragionamenti complessi, ma eccellente per estrarre dati, generare riassunti strutturati, trasformare formati o eseguire routine ripetitive.

Questa specializzazione suggerisce un'architettura a più livelli, dove modelli di dimensioni diverse condividono lo stesso stack locale. I modelli compatti ed efficienti gestiscono il volume: chiamate frequenti, pipeline batch, attività con bassa latenza richiesta. I modelli più grandi o più costosi vengono riservati ai casi che richiedono pianificazione, ragionamento astratto o decisioni con elevato impatto. In questo schema, un modello come LFM2.5-24-A2B non compete con i modelli di fascia alta, ma li alleggerisce, riducendo il numero di chiamate di inference che devono assorbire.

Il vantaggio operativo è duplice. Da un lato si abbassa il costo marginale dell'inference, perché un modello più piccolo consuma meno risorse per token generato. Dall'altro si riduce la latenza percepita nelle attività di routine, che non devono attendere la disponibilità di una GPU più potente o di un endpoint remoto. Per team che eseguono elaborazioni notturne o flussi continui, questa separazione consente di pianificare le risorse in modo più granulare e di evitare colli di bottiglia.

Il trade-off è la complessità di orchestrazione. Gestire più modelli nello stesso ambiente richiede una logica di routing che assegni ogni richiesta al modello appropriato, oltre a procedure di aggiornamento, versioning e monitoraggio separate. Non tutti i team hanno le competenze per mantenere un parco modelli eterogeneo. Tuttavia, la direzione è chiara: la maturità dell'on-premise passa anche dalla capacità di combinare modelli con profili diversi, non dalla ricerca di un unico modello che faccia tutto.

Sovranità, air-gapping e controllo della pipeline

Il riferimento agli ambienti air-gapped e ai requisiti di compliance contenuto nella fonte non è un dettaglio. Per molte organizzazioni, la possibilità di eseguire un LLM con contesto esteso interamente su hardware locale è la condizione necessaria per poter usare l'AI generativa su dati sensibili. In settori come sanità, finanza, pubblica amministrazione e difesa, i dati non possono lasciare il perimetro aziendale per vincoli normativi o contrattuali. Un modello self-hosted su una scheda locale elimina la necessità di inviare prompt a servizi cloud e riduce la superficie di esposizione.

Il controllo della pipeline di inference è un aspetto altrettanto rilevante. Con llama.cpp e un modello open, il team può decidere quale versione eseguire, con quale quantization, su quale hardware, con quali log e con quali policy di retention. Non ci sono endpoint esterni da interrogare, né dipendenze da API che possono cambiare prezzo o condizioni di servizio. Questo livello di controllo si traduce in prevedibilità: i costi sono legati all'infrastruttura interna, non a un listino cloud, e i tempi di risposta dipendono dal carico locale, non dalla congestione di un provider.

Il rovescio della medaglia è l'onere operativo. Un'infrastruttura on-premise richiede competenze per la gestione di driver, sicurezza, backup e aggiornamenti. Se qualcosa si rompe, il team interno è responsabile del ripristino. Per organizzazioni con risorse limitate, questo può essere un costo nascosto che supera i benefici. La sovranità dei dati non è gratuita: va acquistata con investimenti in competenze e processi.

Tuttavia, il segnale di test come quello sulla W7900 è che la soglia tecnica si sta abbassando. Non serve più un data center dedicato per sperimentare con un modello da 24 miliardi di parametri e contesto esteso. Una singola workstation con una scheda professionale può diventare un ambiente di sviluppo o un nodo di inference per casi d'uso circoscritti. Questo favorisce l'adozione incrementale: si parte con un progetto pilota, si valuta il comportamento su dati reali e si scala solo quando i processi interni sono maturi.

TCO e provisioning hardware: il costo vero dell'on-premise

Il Total Cost of Ownership di un deployment locale non si misura solo in token al secondo. La prova di LFM2.5-24-A2B su W7900 fornisce un punto di riferimento utile, ma va inserita in un calcolo più ampio. Una scheda con 32 GB di VRAM ha un costo di acquisto, un consumo elettrico sotto carico e una dissipazione termica che influenzano la bolletta e il raffreddamento del locale. In più, va considerata la vita utile dell'hardware: i modelli evolvono, le tecniche di quantization cambiano e le finestre di contesto crescono, rendendo necessario pianificare aggiornamenti ciclici.

Per un'azienda che confronta on-premise e cloud, la variabile decisiva è spesso il volume di inference e la prevedibilità del carico. Se l'uso è continuo e i dati sono sensibili, l'hardware locale ammortizza il costo iniziale e riduce i costi variabili. Se l'uso è sporadico, il cloud può essere più flessibile. Il test non risolve questo dilemma, ma aggiunge un elemento: una singola scheda professionale può gestire un modello con contesto da 128.000 token, il che riduce il numero di nodi necessari per molti scenari. Non serve sempre un cluster.

Il TCO include anche il software. llama.cpp è open source, ma richiede integrazione con i sistemi aziendali, monitoraggio, sicurezza e governance. ROCm introduce un ulteriore livello di gestione rispetto agli stack più consolidati. I team devono valutare se hanno le competenze per mantenere questi componenti o se devono investire in formazione o supporto esterno. La riduzione del costo hardware può essere compensata da un aumento dei costi di gestione, soprattutto nelle prime fasi.

Il terzo ordine di questa riflessione riguarda la pianificazione finanziaria. Quando l'inference locale diventa una scelta praticabile con hardware diversificato, i budget IT possono spostarsi da una logica di canoni mensili a una logica di investimenti in conto capitale. Questo cambia il modo in cui le aziende valutano i progetti AI: non più solo una spesa operativa legata al consumo di API, ma un asset che si deprezza e che va rinnovato. Per i CFO, il messaggio è che l'AI generativa on-premise sta diventando una voce di investimento infrastrutturale, con i relativi criteri di valutazione.

Cosa guardare nei prossimi mesi

Il test su LFM2.5-24-A2B e AMD W7900 è un segnale, non una conclusione. Per capire se la tendenza si consolida, vanno monitorati alcuni indicatori. Il primo è la maturità di ROCm su schede professionali AMD: driver, supporto per operatori, stabilità nelle sessioni lunghe e compatibilità con le versioni più recenti di llama.cpp. La velocità di generazione è importante, ma lo è altrettanto la costanza nel tempo e la gestione degli errori.

Il secondo indicatore riguarda le tecniche di quantization e compressione del contesto. La versione Q8 da 30 GB mostra che un contesto esteso ha un costo in VRAM significativo. Nei prossimi mesi sarà interessante osservare se emergono metodi che riducono questo ingombro senza sacrificare la qualità, o se i produttori di hardware rispondono con schede che offrono più memoria video a prezzi accessibili. L'evoluzione dei formati di quantization e delle cache KV può spostare rapidamente l'equazione.

Il terzo indicatore è l'ecosistema di supporto. Non basta che un modello giri su una scheda: servono documentazione, casi d'uso validati, strumenti di orchestrazione e, per le aziende, canali di supporto commerciale. La presenza di vendor di hardware che investono in compatibilità con runtime open source è un segnale da seguire, così come la disponibilità di riferimenti indipendenti su prestazioni e affidabilità.

Infine, vanno osservati i modelli stessi. LFM2.5-24-A2B appartiene a una classe di modelli efficienti progettati per l'inference locale. Se questa categoria continua a crescere, con rilasci frequenti e licenze permissive, l'on-premise diventerà una scelta sempre più naturale per un numero maggiore di organizzazioni. Non si tratta di prevedere vincitori, ma di riconoscere che il baricentro dell'AI generativa si sta spostando verso infrastrutture più distribuite e controllabili.