EULLM: Perché Abbiamo Costruito una Piattaforma LLM Europea
Il 95% dell'infrastruttura AI usata in Europa dipende da aziende americane o cinesi. Ogni chiamata API trasmette dati fuori dai confini UE. Con l'EU AI Act in vigore da agosto 2026, abbiamo costruito EULLM: inferenza locale in Rust, specializzazione modelli e registry su infrastruttura europea.
Il Problema: Sovranità Digitale e AI in Europa
Lavoriamo con aziende europee dal 2015. Quando un cliente ci chiede un sistema RAG o un assistente AI, la prima domanda è sempre la stessa: "dove finiscono i miei dati?" La risposta onesta, fino a ieri, era complicata. Anche le soluzioni "on-premise" più diffuse dipendono da componenti americani: i modelli Llama di Meta richiedono branding obbligatorio, Ollama trasmette telemetria, e la maggior parte dei registry di modelli gira su AWS us-east. Il vero punto è un altro: l'EU AI Act entra in vigore il 2 agosto 2026. Gli articoli 53-55 impongono obblighi specifici per i modelli AI general-purpose: documentazione tecnica, trasparenza sull'addestramento, valutazione dei rischi. Chi usa modelli via API non ha il controllo necessario per rispettare questi requisiti. Chi li esegue in locale con strumenti che non producono audit trail, nemmeno. Abbiamo iniziato a costruire EULLM partendo da un'esigenza concreta: RAG Enterprise PRO, il nostro sistema di retrieval documentale, aveva bisogno di un runtime di inferenza che fosse veloce, controllabile e compliance-ready. Ollama funzionava bene per lo sviluppo, ma in produzione avevamo tre problemi: nessun audit log nativo, processamento sequenziale delle richieste (un utente alla volta), e dipendenza da infrastruttura non-UE per i modelli. EULLM è nato per risolvere questi tre problemi.
Engine: Inferenza in Rust con Continuous Batching
Il cuore di EULLM è l'Engine: un singolo binario Rust che wrappa llama.cpp e aggiunge quello che manca per un uso enterprise. Niente Python, niente Docker obbligatorio, niente dipendenze runtime. Scarichi il binario, lo lanci, funziona. La differenza più importante rispetto a Ollama è il continuous batching. Ollama processa le richieste in coda FIFO: se 16 utenti chiedono una risposta contemporaneamente, il secondo aspetta che il primo finisca, il terzo aspetta il secondo, e così via. L'Engine di EULLM decodifica tutte le richieste in parallelo all'interno di un singolo pass GPU. Il risultato: con 16 richieste concorrenti su una RTX 5070 Ti, EULLM raggiunge 259 token/secondo contro i 102 di Ollama. Il throughput totale è 2.5 volte superiore, e soprattutto tutti gli utenti ricevono i token in streaming dall'inizio, senza coda. L'Engine espone due famiglie di API: compatibile Ollama (stessa porta 11434, stessi endpoint) e compatibile OpenAI (/v1/chat/completions). Questo significa che qualsiasi applicazione che usa LangChain, LlamaIndex o Open WebUI funziona senza modifiche — basta cambiare l'URL del server. Per RAG Enterprise, la migrazione da Ollama a EULLM Engine è stata letteralmente un cambio di variabile d'ambiente. Ogni richiesta di inferenza viene loggata automaticamente in ~/.eullm/audit/audit.jsonl con timestamp, ID richiesta, modello utilizzato, conteggio token input/output e ID utente. Questo audit trail è esattamente quello che serve per dimostrare compliance con l'EU AI Act: tracciabilità completa di ogni interazione con il modello, senza dover aggiungere middleware custom.
Forge: Da Modello Generico a Esperto di Dominio
Un modello generico da 14 miliardi di parametri pesa circa 28 GB e richiede una GPU da datacenter per girare. Per un'azienda che vuole un assistente legale o medico, è sovradimensionato: contiene conoscenza su cucina, astronomia, poesia — tutto inutile per analizzare contratti. Forge è la pipeline di "verticalizzazione" di EULLM: prende un modello generico e lo trasforma in un esperto di dominio che gira su hardware consumer. Il processo ha cinque fasi. Prima il pruning strutturale: identifica neuroni e attention head meno importanti per il dominio target e li rimuove, riducendo un modello 14B a 7B parametri. Poi la knowledge distillation: il modello originale (teacher) insegna a quello compresso (student) a replicare i suoi output sullo specifico dominio, recuperando la qualità persa nel pruning. Terza fase, la quantizzazione: comprime i pesi da float16 a int4 (formato Q4_K_M), portando il file da ~14 GB a ~4.5 GB. Quarta fase, l'identity fine-tuning con LoRA: incorpora nel modello l'identità desiderata (nome, tono, limiti di conoscenza) senza il costo di un fine-tuning completo. Infine l'export in formato GGUF, pronto per l'Engine. Abbiamo già definito tre profili di verticalizzazione: legal-it (diritto italiano), medical-de (medicina tedesca), finance-fr (finanza francese). Ogni profilo è un file YAML che specifica il dataset di dominio, gli iperparametri di pruning e distillation, e le soglie di qualità minima. Un'azienda può creare il proprio profilo per qualsiasi dominio: basta un dataset di testi specifici e una GPU A100 per 2-3 giorni. Perché non usare semplicemente un modello generico quantizzato? Perché un modello specializzato da 7B parametri batte un generico da 14B sulle task del suo dominio. Il pruning rimuove il rumore, la distillation concentra la conoscenza, e il fine-tuning di identità assicura risposte coerenti e brandizzabili. Il risultato è un modello che un'azienda può chiamare "il proprio AI", non "un wrapper su Llama".
Hub e Compliance: Modelli su Infrastruttura Europea
L'ultimo componente è l'Hub: un registry REST per pubblicare, scoprire e scaricare modelli verticalizzati. La differenza rispetto a Hugging Face? L'Hub di EULLM gira esclusivamente su server europei (Hetzner in Germania, OVH in Francia), con zero telemetria verso endpoint non-UE. Ogni modello nel registry ha due documenti: una model card tecnica (architettura, dataset di training, benchmark, licenza) e una compliance card allineata al Regolamento UE 2024/1689 (l'EU AI Act). La compliance card specifica: classificazione di rischio, misure di trasparenza, allineamento GDPR, specifiche tecniche, meccanismi di supervisione umana e dettagli infrastrutturali che confermano la residenza UE dei dati. Perché questo è importante? Perché l'EU AI Act non chiede solo di "usare l'AI in modo responsabile" — chiede documentazione specifica e verificabile. Un'azienda che usa GPT-4 via API non può produrre questa documentazione: non sa come il modello è stato addestrato, non controlla dove girano i dati, non ha audit trail. Con EULLM, ogni pezzo della catena è documentato, locale e verificabile. Una scelta deliberata: EULLM esclude i modelli Llama di Meta. La licenza Llama richiede la dicitura "Built with Llama" in ogni prodotto derivato, il che è incompatibile con deployment white-label dove un'azienda vuole brandizzare il modello come proprio. Usiamo esclusivamente modelli con licenza Apache 2.0 o MIT: Qwen 3, Mistral, DeepSeek, Falcon 3. Nessun vincolo di branding, nessuna restrizione d'uso commerciale. EULLM è open-source con licenza Apache 2.0. Il codice è su GitHub e il sito ufficiale è eullm.eu. I contributi sono benvenuti. Per noi di i3k, EULLM è il tassello che mancava: un'infrastruttura di inferenza che possiamo offrire ai clienti sapendo che i dati restano in Europa, il modello è specializzato per il loro dominio, e la compliance è built-in, non un'aggiunta tardiva.
Servizi Correlati
Scopri come applichiamo queste tecnologie nei nostri progetti enterprise.
Interessato?
Contattaci per ricevere un preventivo personalizzato.
Securvita S.r.l. — i3k.eu