Quattro modelli decisionali open su una RTX 4090 in affitto: il test appena pubblicato da un utente su Reddit ha messo Laya, d1 di Liquid AI, Clef-Flash di Cloudflare e Lev di Interfaze a leggere nove voci di Wikipedia sui centopiedi, per un totale di 9.534 parole, e a segnalare ogni singola parola che identifica un centopiedi. Il client Python girava sulla stessa macchina, in localhost, per isolare la latenza end-to-end. Il protocollo era volutamente brutale: una chiamata all'endpoint /v1/systemone per ogni parola, con la richiesta successiva inviata appena arrivata la risposta. Non è un benchmark di generazione continua: è uno stress test sulla latenza per richiesta, sull'overhead del serving e sulla capacità del runtime di gestire migliaia di micro-inference senza collassare.

I numeri raccontano una classifica ma anche un equivoco. Laya-BF16 su llama.cpp b11495 ha chiuso con 3,9 ms per parola (p50) e 7.980 parole processate in 32 secondi. d1-3B in quantization AD-Q4_K_M, sempre su llama.cpp, ha registrato 6,0 ms e 5.306 parole. Clef-Flash-9B in Q8_0 è sceso a 1.292 parole con 24,4 ms. Lev-4B, che gira in BF16 sul server PyTorch lev serve, è arrivato a 626 parole con 51 ms. In termini di pura velocità, Laya e d1 staccano gli altri; ma il dato grezzo non dice tutto.

La trappola dell'accuratezza

Il primo problema è metrico: l'accuratezza riportata va dal 96,5% al 98,9%, ma in un compito sbilanciato come questo dire «no» sulla stragrande maggioranza delle parole produce automaticamente punteggi alti. La percentuale di nomi di centopiedi effettivamente catturati è molto più istruttiva: Lev ne prende l'83%, Laya il 70%, d1 il 51%, Clef-Flash il 36%. In altre parole, il modello più lento è anche quello che sbaglia meno sul bersaglio reale, mentre i modelli più veloci compensano la rapidità con più falsi negativi o falsi positivi. Chi valuta un decision model per un flusso operativo dovrebbe guardare precisione e richiamo sul caso d'uso, non l'accuratezza aggregata.

Il runtime come collo di bottiglia

Il secondo punto è strutturale e riguarda l'ecosistema dei runtime. Sulla stessa GPU, Laya e d1 sfruttano llama.cpp, un runtime C++/CUDA ottimizzato per inference locale, mentre Lev paga un costo evidente per il percorso PyTorch. Non è una differenza marginale: il divario arriva a circa 13x, e l'autore nota che su un'altra RTX 4090 Lev ha misurato 68 ms, quindi il risultato è anche sensibile alla CPU. A parità di hardware, la scelta del motore di serving diventa una leva di performance di primo livello, non un dettaglio implementativo. Per chi costruisce pipeline di decisione self-hosted, questo significa che il modello non è l'unico oggetto da valutare: va testato dentro il runtime con cui andrà in produzione.

C'è anche un segnale di terzo ordine. La disponibilità di modelli decisionali piccoli e aperti, unita a runtime leggeri come llama.cpp, sta spostando il punto di equilibrio dell'inference locale su GPU consumer. Non serve un datacenter per eseguire task di classificazione ad alta frequenza su un singolo documento: basta una scheda come la RTX 4090 e un server locale. Per chi ha vincoli di sovranità dei dati o preferisce non inviare testo a endpoint esterni, questo scenario rende più concreta l'ipotesi di tenere il decision model on-premise, anche se qui la GPU era in affitto e quindi non rappresenta un ambiente air-gapped. Il problema da risolvere, semmai, è la maturità dei server alternativi: il fatto che --compile non abbia completato il warm-up per Lev è un dettaglio che la dice lunga sulla variabilità degli stack emergenti.

Alla fine, il test restituisce un ritratto più interessante della classifica: Laya è il più veloce e, secondo l'autore, facile da sottoporre a fine-tuning per casi specifici; d1 offre un compromesso; Lev dimostra che l'accuratezza sul target può richiedere un costo di latenza non banale. Ma il vero messaggio per chi fa deployment locale è che i colli di bottiglia si spostano dal numero di parametri al runtime e alla metrica con cui si misura il successo. AI-RADAR segue questi trade-off anche nella sezione /llm-onpremise, dove l'analisi dei framework per deployment locale aiuta a separare i dati utili da quelli che sembrano solo buoni.