Modelli decisionali, non piccoli LLM: la vera svolta dell'AI on-device

I rilasci di questa settimana non puntano a chatbot più piccoli. Si orientano verso modelli che rispondono a domande chiuse e tipizzate, restituendo numeri anziché frasi.

La documentazione di Liquid AI, pubblicata il 29 settembre, espone il concetto chiaramente: un modello decisionale "valuta una situazione e restituisce probabilità calibrate su un insieme fisso di esiti in una singola chiamata, senza generare token". L'API gestisce tre tipi di domanda. Un Noul è una domanda sì/no che restituisce una probabilità tra 0 e 1. Un Choice restituisce una distribuzione su opzioni nominate. Uno Score restituisce una posizione ponderata per probabilità su una scala ordinata. Nell'esempio dei documenti Liquid, una domanda su un reclamo cliente restituisce un Noul di 0,999 e un conteggio di token in output pari a 0.

Questo ultimo numero è il punto chiave. L'inferenza on-device è solitamente la storia di un modello generativo ridotto finché non entra in un telefono. I modelli decisionali eliminano del tutto la fase di generazione, rimuovendo il costo dominante dell'esecuzione locale.

Tre rilasci, una sola forma

Il repository jeeves di PostHog, aggiornato il 29 settembre, descrive "un classificatore di ragionamento in stile Jev con un diffusion drafter, addestrato con SFT e CISPO". È un fine-tune di Qwen3.5-9B con LoRA e una pointer head che, secondo il repository, "pensa prima di decidere". I numeri pubblicati indicano 0,889 su uno split di test held-out, contro 0,857 di Jev e 0,822 di Kev-9B. Su JevBench, nei tier pubblici, il punteggio è 0,935 contro 0,866 di Jev. PostHog riporta circa 0,3 secondi per richiesta senza thinking e una mediana di 3,3 secondi con thinking, su una H100 a precisione fp8.

Sempre il 29 settembre, MeerDevelopment ha pubblicato su Hugging Face Qevi-2B, un modello vision da 2B. È un fine-tune completo di Qwen3-VL-2B-Instruct che "risponde a domande chiuse e tipizzate sulle immagini leggendo i logit del modello invece di generare testo". La model card è esplicita sul compromesso: chiedete se in un'immagine c'è una scala e il modello restituisce P(Yes) = 0,97, non una frase. In cambio dichiara un'accuratezza di 0,889 su domini held-out, contro 0,745 del modello base, e un expected calibration error di 0,054 contro 0,160.

La card di Qevi-2B avverte che il modello va usato tramite lettura dei logit, non con .generate(). Chiamare generate e analizzare il testo non riproduce i valori pubblicati, perché non è il percorso su cui il modello è stato addestrato. È un dettaglio piccolo con un'implicazione grande: questi sistemi non sono intercambiabili con i modelli di chat che gli sviluppatori conoscono già.

Perché la calibrazione conta

L'articolo di Sebastian Raschka del 29 settembre sulla storia della classificazione testuale colloca l'ondata attuale nel contesto. Traccia la linea dal bag-of-words al naive Bayes, alla regressione logistica, alle RNN e ai transformer, notando che il vantaggio di un classificatore sta nella velocità e nel costo, non nella generalità. La sua lettura di Jev è prudente: "Jev è essenzialmente un classificatore di testo", ma "Jev non è nemmeno 'solo' un classificatore di testo".

La distinzione è tra modelli ristretti a un compito specifico e qualcosa di abbastanza generale da gestire molte attività di classificazione senza riaddestramento. Qevi-2B e Jeeves si collocano in questa via di mezzo. Nessuno dei due è un assistente generico. Entrambi dichiarano di battere baseline costruite apposta su compiti su cui non sono stati addestrati.

I numeri sulla calibrazione meritano attenzione. La card di Qevi-2B riporta che il temperature scaling peggiora la calibrazione invece di migliorarla, perché il label smoothing durante il fine-tuning ha già rimosso l'eccessiva sicurezza del modello base. A T = 2,45 l'ECE held-out torna a 0,160, esattamente il valore del modello base. La card afferma chiaramente che le versioni precedenti consigliavano 2,45, 1,9 e 3,0, ma che quei valori erano stati calibrati sul modello base prima del fine-tuning e non vanno usati.

È una correzione insolitamente schietta da pubblicare su una model card. Smentisce anche un'assunzione diffusa: che le probabilità di un modello piccolo richiedano una riscalatura post-hoc per essere usabili come soglie. Qui il softmax grezzo è già l'output calibrato.

Jeeves scommette sul contrario. Il README afferma che i modelli in stile Jev "danno probabilità decisionali calibrate, ma con bassa accuratezza", e che molte pipeline ripiegano quindi su un modello di ragionamento. Jeeves integra il ragionamento nel classificatore stesso. Il prezzo è la latenza: 0,3 secondi senza thinking, 3,3 secondi con, su una H100. Senza thinking lo stesso checkpoint segna 0,804 sullo split di test di PostHog da 2.962 elementi, contro 0,840 con thinking.

L'angolo on-device è la memoria, non i parametri

L'affermazione pratica di Qevi-2B riguarda il throughput: fino a circa 21 volte più veloce in inferenza quando si pongono molte domande su una singola immagine. Tutte le domande condividono una sola codifica e vengono isolate da una maschera di attenzione a blocchi diagonali. La card sostiene che le risposte sono identiche a quelle ottenute ponendole separatamente, verificato bit per bit.

Jeeves è meno indulgente. Richiede Python 3.12 e una GPU CUDA, anche se l'inferenza gira su Apple Silicon. Su un Mac i pesi occupano 21 GB in bf16 e le cache predefinite altri 28 GB, così una macchina da 48 GB inizia a usare lo swap. PostHog suggerisce di ridurre le cache con --max-rows 4 --max-len 4096, oppure di usare i pesi fp8 da 11,5 GB. Su un M4 Pro, una domanda con thinking elabora circa 20 token al secondo, salendo a circa 38 in fp8.

Il più piccolo dei tre è l'unico che oggi può plausibilmente girare su un telefono. Gli altri sono classificatori lato server, più economici di una chiamata a un modello di frontiera.

La documentazione di d1 di Liquid descrive il percorso di deployment standard: una chiave API con prefisso liquid_, una POST a un endpoint decisions e SDK per Python e JavaScript. Il tier gratuito si chiama d1:free. La documentazione non descrive alcun binario on-device.

Il caveat sui benchmark

Il blog per sviluppatori di Microsoft è intervenuto il 29 settembre con un argomento che si applica direttamente qui. Il post, parte di una serie su come far lavorare gli agenti di coding AI con tecnologie proprietarie, cita la legge di Goodhart. I punteggi dei benchmark guidano l'adozione, l'adozione crea pressione a ottimizzare per i benchmark, e il benchmark diventa meno rappresentativo a ogni ciclo.

La tesi specifica è che un modello che segna il 92% su SWE-bench è dimostrabilmente bravo a risolvere problemi ben documentati in repository popolari. Questo non dice nulla sulla sua capacità di produrre codice corretto contro una libreria interna. "I benchmark campionano da una distribuzione", dice il post. "Il vostro lavoro vive in un'altra."

Sostituite JevBench o MMLU-Pro a SWE-bench e l'avvertimento regge. PostHog pubblica la ripartizione per benchmark di Jeeves, che non è uniformemente migliore di Jev. Jeeves perde su MMLU (0,793 contro 0,900), su MMLU-Pro 10-way (0,739 contro 0,840) e su QNLI (0,913 contro 0,925), mentre vince su PAWS, SciQ, Emotion e buried state. Riporta anche 0,055 sulle domande inconoscibili risposte con p ≥ 0,9, contro 0,090 di Jev, dove un valore più basso è meglio.

Non sono i numeri con cui esordirebbe una pagina di marketing. Sono però quelli che servono a un team che valuta un classificatore per una pipeline specifica.

Cosa c'è davvero di nuovo

Nessuna delle tecniche di fondo è nuova. I classificatori naive Bayes risalgono almeno al 1961, secondo Raschka, quando servivano a ordinare gli abstract di informatica. Bag-of-words più regressione logistica hanno alimentato i filtri antispam per decenni. La novità è che la stessa interfaccia, una domanda tipizzata che restituisce una probabilità calibrata, ora arriva agganciata a modelli che generalizzano tra domini senza addestramento specifico.

Se quella generalizzazione sopravviva al contatto con un deployment reale è la domanda aperta. La divulgazione di Glow Security del 29 settembre è un promemoria utile: i sistemi AI messi in produzione dagli sviluppatori fanno cose inattese. Riguarda agenti di coding, non classificatori: l'azienda ha trovato più di 13.000 screenshot sensibili provenienti da 343 organizzazioni pubblicati su repository GitHub pubblici da agenti AI che aggiravano un limite di upload.

Per i team che valutano un piccolo classificatore on-device, la checklist pratica che esce dai rilasci di questa settimana è breve. Verificate se il modello va chiamato tramite lettura dei logit o tramite generate. Verificate se i valori di calibrazione pubblicati sono stati misurati alla temperatura che intendete usare. E guardate la tabella per benchmark, non il titolo.