Un utente su Reddit ha ospitato Kev 4B sullo stesso endpoint di Jev e li ha confrontati su un set di test costruito per non favorire nessuno: 362 elementi pubblicati dopo il rilascio di entrambi i modelli, tra nuovi paper arXiv, domande Stack Exchange e issue GitHub, con risposte estratte dalle fonti. Kev 4B è il fine-tuning Apache-2.0 di Qwen3.5-4B realizzato da Jared Palmer. Il risultato qualitativo è un pareggio: su ogni task l'accuratezza resta entro due punti, un margine che l'autore considera dentro il rumore statistico per questa dimensione campionaria. Jev risulta più calibrato e vince sulla paraphrase detection: PAWS 87,0% contro 74,5%.

Il costo nascosto nei token

Il punto che sposta il confronto dal piano qualitativo a quello economico è il conteggio dei token. I due modelli hanno lo stesso prezzo di listino, ma Jev conteggia circa 257 token di input extra per ogni richiesta. L'autore precisa che il conteggio resta identico chiamando TypeSafe direttamente: non è quindi un artefatto dell'endpoint. Per richieste brevi, questo overhead fisso porta il costo fino a 12 volte superiore. Non è una questione accademica: per applicazioni con milioni di richieste corte al giorno, 257 token moltiplicati per il volume diventano la voce principale della bolletta, anche se il listino suggerisce parità.

Chi gestisce uno stack self-hosted dovrebbe leggere questo dato con attenzione. In un ambiente locale, ogni token extra non è soltanto una voce di costo variabile: occupa cicli di calcolo e riduce la capacità utile di GPU e memoria. Se un modello o un wrapper aggiunge token fissi, l'impatto sul throughput e sulle risorse è simile a una tassa occulta, ma pagata in compute. Per chi considera un fine-tuning open-source come Kev, la convenienza non va misurata solo sulla qualità media: va misurata anche sulla trasparenza del conteggio e sulla prevedibilità del TCO.

La parità di listino, insomma, non equivale a parità di Total Cost of Ownership. La vicenda segnala un problema strutturale nei benchmark pubblici: tendono a premiare l'accuratezza, mentre le decisioni di deployment reali dipendono da variabili di contorno come token overhead, latenza e integrazione con i framework esistenti. Il fatto che Kev 4B sia open-source e pubblicato con licenza Apache-2.0 lo rende ispezionabile, ma il test mostra anche che un'alternativa aperta può perdere su calibrazione e paraphrase detection. Non emerge un vincitore unico: emerge una scelta tra trasparenza dei costi e precisione su task specifici. Chi valuta deployment on-premise può trovare su AI-RADAR framework analitici per confrontare questi trade-off, ma la lezione del test è di metodo prima che di scelta.

Il codice, i test e i risultati sono su GitHub, e l'autore si dice disponibile ad approfondire. Per chi vuole replicare, il messaggio è semplice: prima di confrontare due LLM sull'accuratezza, controllate quanti token passano davvero sotto il contatore.