C’è un messaggio che circola nella community degli sviluppatori AI, breve e apparentemente naïf: «Con tutto il polverone su Kimi, mi è venuta voglia di scaricarmi tutti i modelli migliori, nel caso partisse qualche mossa politica assurda». Niente di nuovo sotto il sole, se non fosse che la frase cattura un’inquietudine che sta diventando sistemica.

Chi scrive non segue la scena da febbraio e chiede consigli senza badare alla dimensione: dalle minuscole varianti esperte fino ai monster model generalisti. «La cosa che conta è la performance – dice – poi a farli girare ci penso dopo». Una sorta di accaparramento preventivo, una scorta digitale che rivela molto più di quel che sembra.

Il riflesso condizionato della dipendenza API

La reazione dell’utente non è isolata. Dopo ogni scossa geopolitica o annuncio di restrizione all’export vediamo picchi di download di modelli aperti. È il riflesso di chi ha già sperimentato la fragilità delle API esclusive: dal ban improvviso di determinate regioni all’oscuramento di endpoint critici. La “paura Kimi” – indipendentemente dai dettagli della vicenda cinese – ricorda a tutti che delegare l’inference al cloud significa consegnare la continuità operativa a un fornitore terzo, esposto a pressioni politiche e cambi di policy.

Scaricare è facile, inferire è un altro mestiere

Il vero nodo, però, è l’ultima frase: «poi a farli girare ci penso dopo». Perché non basta avere il file .safetensors bello fermo sull’hard disk. Servono GPU con VRAM adeguata, framework di serving, pipeline di pre-processing e una gestione oculata dei parametri. Un LLM da 70 miliardi di parametri in FP16 vuole almeno 140GB di memoria video; anche ricorrendo a quantization aggressiva (INT4) si resta su numeri che richiedono hardware enterprise o configurazioni multi-GPU raffazzonate. E poi c’è la latenza, il throughput, la scalabilità.

Il gesto dell’utente è quindi simbolico: rappresenta la volontà di riprendere il controllo, di non farsi trovare impreparati. Ma mette anche in luce il gap tra la “proprietà del modello” e la capacità di metterlo realmente in produzione. Gap che spiega perché sempre più aziende guardino con attenzione alle architetture on-premise e ai nodi bare-metal, dove il costo di capitale (CapEx) si sostituisce a bollette mensili imprevedibili e il TCO può essere calcolato su un orizzonte pluriennale.

Chi vince e chi perde in questo scenario

A guadagnarci sono i produttori di modelli aperti: ogni episodio di instabilità rafforza la percezione che Llama, Mistral, Falcon e compagnia non siano solo alternative tecniche, ma vere polizze assicurative. Ne beneficiano anche gli ecosistemi di tooling (Ollama, vLLM, llama.cpp) che semplificano il self-hosting, trasformandolo da impresa per pochi a pratica diffusa. Ci rimettono, invece, i fornitori di API proprietarie che fondano il loro business sull’adesione a un ecosistema chiuso: ogni download locale è un cliente potenziale che si allontana.

Sul fronte hardware, la tensione è doppia: da un lato la domanda di schede consumer con tanta VRAM (si veda la RTX 3090/4090) continua a salire tra i practitioner; dall’altro, le aziende che pianificano deployment seri guardano a soluzioni server con NVLink o a macchine con centinaia di GB di memoria unificata. L’industria dei datacenter sta riconsiderando i carichi di lavoro AI come sempre meno “bursty” e sempre più residenti.

L’episodio “Kimi”, insomma, non è che un catalizzatore. Ma il messaggio di quell’utente anonimo ci dice che il pendolo si sta spostando: dalla comodità del SaaS alla resilienza del locale, dall’abbonamento alla proprietà. Per chi valuta deployment on-premise, non è più solo un tema di privacy o compliance GDPR: è una scelta strategica che incide sulla stessa sopravvivenza del servizio. Archiviare modelli oggi significa prepararsi a scenari in cui la domanda non è “posso usare questa API?”, ma “posso far funzionare il mio stack anche se il resto del mondo sparisce?”.