LLM on-premise: risparmio per token, ma nuovi rischi nella supply chain e nell'operatività

Arvind Krishna ha messo i numeri sul tavolo: i modelli a pesi aperti costano tra il 10 e il 25 per cento per token rispetto ai frontier e rendono “al 90 per cento” del migliore su benchmark ampi¹. Se li porti in azienda, in locale, “hanno perfettamente senso”¹. La tesi di questo pezzo è semplice: quell’economia spinge on-premise, ma sposta il rischio dal cloud alla supply chain software e all’operatività.

Perché le aziende guardano ai modelli open-weight on-premise

Krishna lega prezzo ed efficacia in un’unica domanda pratica: paghi dieci volte di più o scegli qualcosa che costa il 10 per cento ed è buono al 90 per cento del migliore¹. Il suo racconto insiste sull’evoluzione. Nel 2024 il top “poteva prendere 70” e l’aperto “20 o 30”. Più avanti, “70 contro 50”¹. Con il costo che scende e la resa che sale, l’equilibrio cambia.

Il metro resta il compito concreto. Per attività diffuse, la differenza residua non giustifica il sovrapprezzo: riassumere un’email, esaminare un contratto, rispondere a una chiamata clienti, comporre un’email¹. In questi casi la valutazione tiene conto di resa e prezzo per token, non solo del massimo assoluto su benchmark di frontiera¹.

Casi d’uso locali che mostrano il vantaggio operativo

SlothSort mette in pratica l’argomento della prossimità. Analizza i primi 2.048 byte di ogni file, decide tra 18 domini e propone un nuovo nome con data. Tutto in locale². Non legge il file intero. Si ferma a 2 KB netti. Annusa intestazioni, script, metadati multimediali. Quel campione diventa il contesto per l’inferenza².

Non si fida di estensioni e nomi originali. Deduce l’intento dal contenuto del campione. Classifica in uno dei 18 “vault domains”. Poi genera un titolo normalizzato. Esempio: download (1).txt diventa 2026-10-22_Cloud_Compute_Invoice.txt². L’obiettivo è ridurre il carico cognitivo del riordino. La decisione nasce dai primi 2 KB, non da etichette deboli come “final_v2”².

Questo schema mostra due elementi utili all’on-premise. Il modello lavora in locale. E usa pesi aperti quantizzati per restare leggero². È un promemoria: molti guadagni arrivano da scelte di contesto e campionamento, non solo dalla taglia del modello.

La localizzazione sposta il rischio: la supply chain software

Portare tutto in casa non elimina il rischio. Cambia dove nasce. Una versione di LiteLLM su PyPI ha incluso codice malevolo che, in fase di installazione, può rubare credenziali e aprire una backdoor. Basta un pip install per innescarlo³.

Il meccanismo non aspetta l’import. Può scattare durante la build della source distribution, perché l’esecuzione di setup.py avviene prima di qualsiasi utilizzo. Può scattare all’avvio dell’interprete: un file .pth in site-packages con una riga di import viene caricato a ogni esecuzione di Python, anche con un semplice python -c "print(1)". Può scattare per via indiretta: una dipendenza aggiornata trascina dentro il pacchetto compromesso senza installazione esplicita³.

Questi canali colpiscono le abitudini di delivery. Esempi citati: pip install -U litellm dentro un Dockerfile, o requirements.txt senza versioni bloccate³. Se qualcuno prende il controllo dell’account che pubblica su PyPI, ottiene esecuzione di codice sui laptop degli sviluppatori, nei runner CI, nei container di produzione. Una sola build può attivare lo script inserito nel pacchetto³.

Per l’on-premise il messaggio è netto: la superficie d’attacco si sposta sugli anelli deboli delle dipendenze e dei processi di build. Il controllo dei pesi non basta se la pipeline che li porta in produzione può eseguire codice terzo al di fuori del perimetro atteso³.

Costi nascosti: consumo di token, infrastruttura e ottimizzazione

Il costo per token può scendere, ma il consumo può esplodere. Peter Steinberger, membro dello staff tecnico di OpenAI e creatore di OpenClaw, ha detto sul palco di Cloudflare Connect 2026 a San Francisco di aver speso circa 10 milioni di dollari in token nell’ultimo mese per far girare carichi AI. Denaro di investitori, non suo⁴. Dopo un’osservazione su un “budget di token virtualmente illimitato”, ha risposto: “Quello che le persone non capiscono sempre è che non tutto questo è utile”⁴. Più avanti ha indicato un limite di base: “la nostra infrastruttura non ha ancora davvero tenuto il passo”⁴.

Il resoconto collega la scena al momento dell’azienda: OpenAI starebbe cercando di “accelerare il finanziamento”. Anthropic è attesa alla quotazione in Borsa⁴. Qui la lezione operativa è sul lato opposto della convenienza: senza una disciplina su carichi e flussi, la spesa in token può superare in fretta i risparmi unitari.

Nel frattempo NVIDIA ha presentato Kumo Relational, un modello foundation relazionale pre-addestrato. Esegue previsioni direttamente sui database aziendali, senza training specifico. Seleziona fino a 10.000 esempi storici pertinenti come contesto, poi produce la previsione in un’unica forward pass⁵. Sugli esperimenti dichiarati, supera sistemi supervisati su 41 task in 15 database. Nel benchmark enterprise SAP SALT, ottiene un vantaggio dell’8 per cento in mean reciprocal rank rispetto a un ensemble AutoGluon⁵.

La promessa è ridurre feature engineering e appiattimenti forzati di schema, con una pipeline più corta⁵. Ma c’è un corollario operativo: servire fino a 10.000 esempi come contesto impone attenzione a storage, accesso ai dati e capacità di calcolo. L’efficienza del modello non cancella il costo di orchestrare dati e query predittive su base regolare⁵.

Implicazioni pratiche per chi implementa LLM on-premise

I fatti puntano a un bilancio. Da un lato, i modelli a pesi aperti offrono un rapporto prezzo-prestazioni favorevole su compiti aziendali comuni. Krishna parla di costi tra il 10 e il 25 per cento per token e di resa “al 90 per cento” del migliore¹. Dall’altro, l’on-premise richiede maturità sulla supply chain: versioni bloccate, verifica dei pacchetti, attenzione ai trigger di esecuzione come setup.py e i file .pth, e disciplina nelle pipeline CI e nei container³.

Allo stesso tempo serve governo dei consumi. L’esperienza di Steinberger mostra come una spesa in token può crescere rapidamente in assenza di selezione dei carichi “utili” e di infrastrutture adeguate⁴. Modelli come Kumo Relational possono tagliare lavoro manuale e superare baseline supervisionate, ma spostano lo sforzo sull’integrazione con i database e sulla gestione del contesto a scala⁵. Strumenti locali come SlothSort ricordano il valore di scelte mirate: campionare poco, decidere bene, restare in locale quando possibile².

La decisione, quindi, non è solo quale modello scegliere. È come costruire la catena che lo alimenta. Il risparmio per token che oggi fa “perfettamente senso” in azienda, per usare le parole di Krishna, regge se la stessa cura va a pacchetti, build e misurazione dei consumi^1,3,4. Chi sposta i LLM in casa dovrà dimostrare la stessa perizia nel tenere fuori il codice indesiderato e nel tenere a bada il contatore dei token, mentre nuovi modelli bussano ai database con 10.000 esempi alla volta⁵.