Il token non è più l'unità di misura universale

Con la famiglia LFM3, Liquid AI ha introdotto una distinzione che la maggior parte dei benchmark non cattura: un modello può essere progettato per produrre testo token per token, oppure per restituire una decisione già calibrata. I due decision model, d1-Omni-2B e d1-2B, non generano token: eseguono un singolo forward pass e restituiscono risposte strutturate con latenze dichiarate di 5,8 ms su NVIDIA H100 e 3,7 ms su AMD MI325X per il primo, e 5,7 ms e 3,8 ms per il secondo.

Questa scelta architetturale ha una conseguenza profonda. Il costo computazionale non scala con la lunghezza di una sequenza generata, perché non esiste una pipeline di generazione autoregressiva. Per attività di estrazione di testo, numeri, date o stima di quantità con intervallo, il collo di bottiglia non è più il throughput di token, ma il tempo di attivazione del modello e la gestione della memoria. Chi progetta sistemi on-premise può dimensionare l'hardware su latenza e footprint, non su volumi di token fatturabili.

Il modello testuale LFM3-1.7B condivide la stessa impostazione generale ma genera token. La sua architettura tri-hybrid da 24 layer combina 13 convoluzioni brevi gated, 5 layer di attenzione a finestra scorrevole e 6 layer di attenzione globale. Non è un transformer classico, e questo spiega almeno in parte il contesto da 256K token e l'ingombro ridotto in quantization a 4 bit. Per AI-Radar il punto non è il dettaglio architetturale fine a se stesso, ma il fatto che il vincolo di progetto sia stato spostato: prima le risorse disponibili sul dispositivo, poi le metriche di modello.

Un gigabyte di VRAM cambia la geografia del deployment

Il modello a 4 bit occupa circa 1 GB di VRAM. È un dato che, da solo, riapre scenari di deployment che i modelli cloud generalisti avevano reso marginali. Un LLM da 1,7 miliardi di parametri in quantization a 4 bit può girare su telefoni e laptop comuni, ma anche su microservizi self-hosted senza GPU dedicate. Per le aziende con vincoli di sovranità dei dati, questo significa poter mantenere l'inference dentro i confini dell'organizzazione senza dover sostenere i costi di infrastrutture accelerate di fascia alta.

Il supporto a llama.cpp è già stato integrato. Non è un dettaglio tecnico secondario. Chi oggi pianifica deployment locali su hardware consumer o edge può usare runtime consolidati, senza dipendere da stack proprietari o da servizi cloud. Questo riduce gli attriti di integrazione e rende più semplice distribuire modelli su flotte eterogenee, con cicli di aggiornamento gestiti internamente.

Liquid AI precisa che il fine-tuning del modello testuale richiede una singola GPU. Questa indicazione sposta il baricentro dal training centralizzato alla personalizzazione distribuita. Un team che opera in un contesto regolato può addestrare varianti locali su dati proprietari, mantenendo il controllo del flusso di dati e riducendo la superficie di esposizione. Il TCO di un simile approccio non si limita al costo di hardware: include la possibilità di evitare contratti API, limiti di trasmissione e dipendenze operative.

Decision model e TCO: il costo marginale che scompare

I decision model colpiscono un nervo scoperto del business dei fornitori API cloud. Se un servizio di fatturazione si basa sul volume di token generati, un modello che risponde in millisecondi senza generare token riduce drasticamente l'unità di ricavo. Non si tratta solo di efficienza: si tratta di una categoria di workload che può uscire dal perimetro del cloud e spostarsi su edge o on-premise senza perdere velocità.

Per i decision model dichiarati, le latenze su hardware server sono nell'ordine di pochi millisecondi. Su dispositivi edge il framework cambia, ma il principio resta: quando la risposta è un valore calibrato e non una sequenza testuale, il costo marginale non cresce con la complessità sintattica della richiesta. Questo rende possibile automatizzare decisioni ripetitive su immagini, audio o dati strutturati con un budget computazionale prevedibile.

Va però osservato un trade-off. I modelli d1 non sono pensati per coding agentico o ragionamento multi-step, e Liquid AI stessa ne sconsiglia l'uso in quei contesti. Sono strumenti specializzati per estrarre informazioni e produrre decisioni immediate. Chi li adotta deve accettare una riduzione dell'ampiezza funzionale in cambio di latenza e footprint. In ottica AI-Radar, è una scelta di deployment, non una classifica di qualità assoluta.

Chi paga il conto della specializzazione

La famiglia LFM3 non è un singolo modello, ma una matrice di specializzazioni: visione, audio, input omni-modali e decisione. LFM3-VL-2B accetta testo, immagini e video; LFM3-Audio-2B gestisce l'elaborazione audio con sintesi vocale multilingue in 18 lingue; LFM3-Omni-2B sostituisce ASR, VLM, LLM e TTS in un unico checkpoint. Questa modularità ha un costo gestionale: ogni variante va valutata, integrata e manutenuta separatamente.

Chi guadagna? Gli sviluppatori di agenti locali, le PMI che vogliono automazione senza mandare dati sensibili a terze parti, e i team di robotica che hanno bisogno di ragionamento spaziale e temporale a bassa latenza. Per loro, la disponibilità di modelli compatti self-hosted riduce la dipendenza da API e consente un controllo più diretto su dati e prestazioni.

Chi perde? I fornitori di API cloud che monetizzano il consumo di token su modelli generalisti. Se il decision model risponde senza generare testo, il volume di token fatturabili si riduce drasticamente. Anche i team che hanno costruito pipeline attorno a LLM generalisti potrebbero dover rivedere i propri assunti: non tutti i carichi di lavoro richiedono un modello grande, e non tutti i problemi si risolvono con più parametri.

Cosa guardare nei prossimi mesi

La mossa di Liquid AI rientra in una tendenza più ampia verso l'efficienza architetturale e la specializzazione spinta. I segnali da monitorare sono concreti: benchmark indipendenti su compiti di estrazione e decisione, integrazioni con framework self-hosted, supporto hardware per quantization a 4 bit e modalità di distribuzione su dispositivi edge. Servirà capire se le prestazioni dichiarate reggono al di fuori dei laboratori.

Un secondo fronte riguarda l'aggiornamento e la manutenzione dei modelli locali. La possibilità di fine-tuning con una singola GPU apre scenari interessanti, ma impone anche processi chiari di versione, validazione e rollback. Chi opera in produzione deve considerare il costo di gestione del ciclo di vita, non solo quello di servizio. La sovranità dei dati non si ottiene con un singolo deployment, ma con procedure ripetibili.

Infine, il vero test sarà l'adozione da parte di chi costruisce applicazioni edge e on-premise. Se i decision model dimostreranno di essere sufficientemente robusti per compiti reali, potranno ridisegnare l'economia dell'inference locale: meno token, più decisioni, hardware più modesto. Se invece la qualità resterà limitata a casi d'uso molto stretti, resteranno una nicchia interessante ma non strutturale.