Quando un Modello "Piccolo" Batte i Giganti sul TCO per le PMI: Il Caso On-Premise
La narrativa dominante vuole che per far girare LLM seri in azienda servano cluster GPU da decine di migliaia di euro. La realtà dell'AI on-premise per le PMI europee sta cambiando per aritmetica pura, non per marketing.
Il Cambio di Paradigma: Modelli Compatti che Competono con Quelli Medi
L'evoluzione architetturale recente — modelli encoder-free multimodali con context window estesi (256K+) e footprint memoria ridotto — permette a modelli da 12B parametri quantizzati a 4-bit (8-10 GB VRAM) di eguagliare o superare le prestazioni di modelli da 27B della generazione precedente su benchmark di ragionamento (GPQA, MMLU Pro) e comprensione documentale (DocVQA). Non è magia: è distillation fatta bene, training su dati curati, e la decisione di non inseguire il parametro-count come vanity metric.
Per una PMI che deve processare fatture, contratti, ticket assistenza e documentazione tecnica senza far uscire un byte dal perimetro aziendale (GDPR Art. 25, privacy by design), questo cambia l'economia del progetto.
Il Confronto di Principio: TCO On-Prem vs API Cloud
| Componente | Modello 12B On-Prem (Es. Gemma/Qwen classe 12B) | API Cloud (Es. GPT-4o / Claude Sonnet) |
|------------|--------------------------------------------------|----------------------------------------|
| Hardware | 1× GPU 48GB (es. RTX 6000 Ada) o 2× 24GB consumer | — |
| Licenza Modello | €0 (licenze aperte tipo Apache 2.0 / Qwen) | — |
| Costo Inferenza (stima 2M token/giorno) | Energia + ammortamento HW | Costo per token × volume |
| Manutenzione/Anno | Sysadmin part-time | €0 (gestito dal vendor) |
| Governance Dati | Completa (dati mai escono) | Richiede DPA, valutazione subprocessori, Schrems II |
L'equazione economica si ribalta al crescere del volume: oltre una certa soglia di token/giorno, l'on-premise diventa più conveniente del pay-per-token — e i dati non lasciano mai l'ufficio. Nessun DPA da negoziare, nessuna sorpresa sul pricing che lievita quando il business scala, nessun vendor lock-in su roadmap e deprecazioni altrui (es. modelli deprecati a 12-18 mesi dal lancio).
L'Insight Pratico che Puoi Applicare Oggi
Non serve un cluster. Serve una workstation ben configurata e un inference server leggero.
Il pattern che funziona nelle PMI che adottano questo approccio:
1. Hardware: Una workstation con GPU 48GB VRAM totale (es. RTX 6000 Ada o 2× RTX 4090/3090) — budget €8-12k chiavi in mano.
2. Software: `llama.cpp` / `vLLM` / `Ollama` con quantizzazione Q4_K_M / Q5_K_M. Latenza <100ms/token, throughput 30-50 tok/s per utente concorrente.
3. Integrazione: Un'API gateway interno (FastAPI + Pydantic) che espone `/v1/chat/completions` compatibile OpenAI. Lo stack a valle (RAG, agenti, UI) non cambia.
4. Osservabilità: Log strutturati, metriche Prometheus/Grafana, alert su VRAM >90% e latenza p95 >2s.
Il trucco non tecnico: inizia con un solo caso d'uso ad alto volume e bassa criticità (es. classificazione ticket, estrazione campi fatture, riassunto verbali). Misura. Poi espandi. Le PMI che provano a "fare tutto insieme" si bloccano su governance e change management, non su GPU.
Perché Non È Solo Questione di Euro
La disponibilità di modelli weight-open con licenze permissive (Apache 2.0, MIT, Qwen License) elimina l'ambiguità legale che circonda ancora molti modelli "open weight" con clausole di uso commerciale restrittive. Per una PMI che deve rispondere a revisori, DPO, o clienti enterprise che chiedono model cards e data processing agreements, la licenza è un asset strategico, non un dettaglio legale.
Inoltre: nessun vendor lock-in. Se domani esce un modello migliore (e uscirà), swappi i pesi, ricompili il container, e riparti. Con API cloud, sei legato a roadmap altrui, deprecazioni unilaterali, e aumenti di prezzo improvvisi.
La tecnologia è la parte facile. La parte difficile è decidere che i tuoi dati valgono abbastanza da tenerli in casa.