Una nuova categoria di runtime per inference sta emergendo ai margini dell'ecosistema LLM: motori deliberatamente overfit, costruiti non per funzionare con qualsiasi modello su qualsiasi hardware, ma per spremere ogni ciclo di calcolo da una configurazione molto stretta. Nomi come Strata, ninfer, DwarfStar, Splash, llamAmpere e gufo compaiono nei repository e nelle discussioni tecniche con un tratto comune: rinunciano alla generalità che ha reso llama.cpp e vLLM punti di riferimento.

La tesi è netta. La generalità serve alla compatibilità; l'overfit serve alla prestazione. I runtime generali devono gestire numerosi modelli, tecniche di quantization, pipeline di token e target hardware differenti. I runtime monoscopo, al contrario, possono assumere un unico modello, un livello di precisione e una famiglia di chip — per esempio Strix Halo — e da lì riscrivere i kernel, riorganizzare la memoria e tagliare tutti i rami inutili. Il codice non deve essere elegante né manutenibile: deve esaurire la sua funzione su una configurazione specifica. È un approccio quasi usa e getta.

Questa separazione dei compiti non è solo una moda. Segnala una biforcazione strutturale nel modo in cui il software di serving viene concepito. Da una parte restano i framework generali, indispensabili per chi deve spostare un LLM tra ambienti diversi o mantenere compatibilità a lungo termine. Dall'altra crescono oggetti monouso che competono su throughput, latenza e occupazione di VRAM in contesti self-hosted. Chi gestisce un parco macchine locale, o un singolo nodo con un modello congelato, può accettare volentieri la fragilità del runtime in cambio di un recupero di prestazioni senza cambiare hardware.

Il dato di secondo ordine è che l'intelligenza non si democratizza soltanto distribuendo i modelli, ma anche distribuendo la capacità di eseguirli. Un runtime specializzato può abbassare la barriera per chi vuole mantenere i dati in casa: se un motore su misura estrae più valore da una configurazione esistente, il costo marginale del deployment locale scende senza richiedere un salto di generazione hardware. Per la sovranità dei dati, questo è rilevante: più alternative di esecuzione locale significano meno dipendenza da stack cloud unici.

Non è tutto positivo. La frammentazione ha un costo reale. Ogni runtime monoscopo vive e muore con la configurazione per cui è stato scritto; un aggiornamento del modello o un cambio hardware lo rende inutile. Anche la manutenzione, la sicurezza e la verificabilità diventano più complicate: un codice molto specializzato è più difficile da sottoporre a audit rispetto a un framework con una comunità ampia. La sicurezza e la compliance, in contesti regolati, non vivono solo di prestazioni.

Per chi valuta deployment on-premise, esistono trade-off tra ottimizzazione estrema e sostenibilità operativa. AI-RADAR offre framework analitici su /llm-onpremise per valutare questi aspetti, ma la scelta resta legata al contesto specifico. La domanda posta da chi ha sollevato il tema resta aperta: questi runtime diventeranno la norma? Difficile dirlo. Ma se la risposta è sì, il panorama dell'inference locale cambierà: meno motori universali, più pezzi specializzati, più output da hardware che altrimenti resterebbe fermo.