Eldric è un piccolo insieme di processi che cooperano. Ciascuno svolge un solo compito. Possono girare tutti su una sola macchina per una prova di sviluppo, o essere distribuiti su molte macchine per un cluster di produzione multi-tenant.
Una richiesta da un client arriva all'Edge (TLS + auth + rate-limit) — l'Edge verifica l'utente contro il Data Worker. L'Edge la passa a un Router, che chiede al Controller la topologia corrente, classifica la richiesta (chat? RAG? voce? lettura da sensore?) e sceglie il worker giusto. Il worker svolge il lavoro — persistendo lo stato nel Data Worker man mano — e fa streaming della risposta lungo lo stesso percorso. Il Data Worker è la spina dorsale di system-tier: ogni altro servizio lo consulta per utenti, sessioni, file, vettori e memoria EMM, e fa da ponte verso il tuo DB2, PostgreSQL, MySQL o storage NFS esistente, così la piattaforma può appoggiarsi ai dati che hai già.
L'unico processo esposto sulla rete pubblica. Termina TLS, valida la chiave API, applica i rate limit e inoltra a un Router. Non ha stato di modello proprio. Serve anche la chat shell integrata su /chat.
Tiene la topologia del cluster in un unico posto. I worker si registrano qui e inviano un heartbeat ogni trenta secondi. Il controller è proprietario del file di licenza, del registro di audit, dell'orchestrazione dei backup, del coordinatore degli aggiornamenti rolling e della PKI per i certificati interni.
Decide quale worker gestisce quale richiesta. Sceglie in base all'intento (una chat? una ricerca RAG? una chiamata vocale?), al carico (qual è il worker più occupato?) e al tema (una domanda medica va a un modello sintonizzato sulla medicina). Ha otto strategie di load balancing e una modalità decisionale opzionale basata su LLM.
La spina dorsale dati di system-tier. Memorizza account utente, sessioni, audit trail, file, vettori e memoria associativa EMM. Parla DB2, PostgreSQL, MySQL, ODBC e NFS, quindi può stare davanti a database che già gestisci — la piattaforma non ti chiede di migrare. Isolamento multi-tenant, quote, replica tra data worker e un server NFS-Ganesha opzionale per i client filesystem sono inclusi. Ogni altro worker si appoggia a questo.
Uno per funzione. I worker di inferenza eseguono modelli linguistici locali (Ollama, vLLM, llama.cpp). Il Cloud Worker fa da fronte alle API dei vendor esterni (OpenAI, Anthropic, xAI, Groq, Ollama Cloud) così al resto del cluster non importa dietro a quale vendor sta un modello. I worker Agent eseguono i loop di ragionamento iterativo. I worker Media fanno speech-to-text, text-to-speech e video. I worker Comm portano email, SMS, WhatsApp, Signal, Teams e VoIP. I worker Training fanno fine-tuning dei modelli. Tutti persistono il loro stato attraverso il Data Worker.
Un worker di inferenza nativo che carica modelli GGUF e xLSTM direttamente tramite llama.cpp embedded. Nessuna dipendenza da Ollama, e l'unico percorso che supporta l'inferenza con memoria intelligente — il modello consulta la tua memoria associativa al confine del prompt. Usalo per le installazioni più piccole e per i siti air-gapped.
Carichi di lavoro di structured machine learning che non sono chat generica: esecuzione di policy a ciclo chiuso per il controllo, previsioni su serie temporali sulla telemetria, encoding vision-language per la percezione, e retrieval associativo con latenza nell'ordine dei microsecondi su CPU. Un processo, quattro classi di carico, ciascuna con licenza separata.
Parla i protocolli che le case intelligenti e le fabbriche usano davvero: OPC-UA per PLC e SCADA, Modbus TCP/RTU per gli impianti legacy, e MQTT per tutto il resto. Historian per le serie temporali, gestione degli allarmi, calcolo OEE e un buffer store-and-forward per i siti con uplink instabili.
Federa i dati scientifici su sedici categorie — fisica delle particelle, genomica, neuroscienze, clima, archeologia e altre — attraverso un unico registro delle fonti. Gli admin abilitano le fonti di cui hanno bisogno i loro tenant; gli strumenti richiamabili dall'LLM restano gli stessi indipendentemente da quali fonti sono collegate. I plugin dei clienti finiscono sotto una categoria custom senza toccare il codice del worker.
Il kernel 5.0 è lo stesso su un Raspberry Pi 4, su una workstation di sviluppo, su un server rack-mounted e su un cluster multi-nodo. Quello che cambia è quali moduli attivi per ciascun nodo. Una scatoletta piccola non riceve un prodotto ridotto; riceve lo stesso prodotto con meno moduli accesi.
Edge → Router → Worker. Tre salti. Le risposte in streaming passano senza buffering. La ricerca su base di conoscenza colpisce prima la memoria EMM (compressa, associativa) e ricade sul vector store solo quando servono citazioni esatte delle fonti — per i casi d'uso di sola chat il vector store si può togliere del tutto. Non c'è middleware nascosto che rivende i tuoi dati.
Sul nostro cluster di riferimento, la chat sostiene 793 richieste al secondo con 32 connessioni in concorrenza, con latenza mediana di 41 millisecondi. Quello è un buon risultato. La ricerca su base di conoscenza a quattro connessioni in concorrenza tocca ancora una soglia di latenza p50 di circa 7 secondi. Quello non è un buon risultato, e ci stiamo lavorando. I numeri vengono dal nostro baseline 2026-05; li pubblichiamo perché tu sappia cosa aspettarti.
Il nostro cluster di riferimento è volutamente modesto. I numeri qui sopra vengono da questo hardware.