Wie es funktioniert

Ein kurzer Rundgang
durch die Architektur.

Eldric besteht aus einer kleinen Gruppe zusammenarbeitender Prozesse. Jeder hat eine klar abgegrenzte Aufgabe. Alle können auf einem einzelnen Rechner laufen — für den Probelauf eines Entwicklers — oder über viele Maschinen verteilt sein, für einen mehrmandantenfähigen Produktiv-Cluster.


Die Prozesse, je ein Absatz.

Edge

Der einzige Prozess, der nach außen ins öffentliche Netz exponiert ist. Beendet TLS, prüft den API-Schlüssel, setzt Rate-Limits durch und leitet an einen Router weiter. Hat keinen eigenen Modellzustand. Liefert außerdem die eingebaute Chat-Oberfläche unter /chat.

Controller

Hält die Cluster-Topologie zentral. Worker melden sich hier an und schicken alle dreißig Sekunden einen Heartbeat. Beim Controller liegen die Lizenzdatei, das Audit-Protokoll, die Backup-Orchestrierung, der Koordinator für rollende Updates und die PKI für interne Zertifikate.

Router

Entscheidet, welcher Worker welche Anfrage bekommt. Wählt nach Absicht (Chat? RAG-Suche? Sprachanruf?), Last (welcher Worker ist am stärksten beschäftigt?) und Thema (eine medizinische Frage geht zu einem medizinisch trainierten Modell). Acht Lastverteilungs-Strategien und ein optionaler LLM-Entscheidungs-Modus.

Daten-Worker

Das System-Rückgrat für Daten. Speichert Benutzerkonten, Sitzungen, Audit-Spur, Dateien, Vektoren und das EMM-Assoziativspeicher. Spricht DB2, PostgreSQL, MySQL, ODBC und NFS — die Plattform setzt sich vor Datenbanken, die Sie bereits betreiben, ohne dass migriert werden muss. Mehrmandantenfähige Isolation, Quoten, Replikation zwischen Daten-Workern und ein optionaler NFS-Ganesha-Server für Dateisystem-Clients sind eingebaut. Alle anderen Worker stützen sich darauf.

Worker

Einer pro Aufgabe. Inferenz-Worker betreiben lokale Sprachmodelle (Ollama, vLLM, llama.cpp). Der Cloud-Worker steht vor externen Anbieter-APIs (OpenAI, Anthropic, xAI, Groq, Ollama Cloud), damit der Rest des Clusters nicht wissen muss, hinter welchem Anbieter ein Modell liegt. Agent-Worker führen die iterativen Reasoning-Schleifen aus. Medien-Worker machen Speech-to-Text, Text-to-Speech und Video. Comm-Worker tragen E-Mail, SMS, WhatsApp, Signal, Teams und VoIP. Trainings-Worker stimmen Modelle fein ab. Sie alle legen ihren Zustand im Daten-Worker ab.

Inferenced

Ein nativer Inferenz-Worker, der GGUF- und xLSTM-Modelle direkt über eingebettetes llama.cpp lädt. Keine Ollama-Abhängigkeit, und der einzige Pfad mit intelligenter Memory-Inferenz — das Modell nutzt Ihren Assoziativspeicher beim Eintreffen des Prompts. Für die kleinsten Installationen und für Air-Gap-Standorte.

xLSTM-Daemon

Strukturierte Machine-Learning-Workloads, die nicht zum klassischen Chat zählen: geschlossene Regelkreis-Policies für Steuerungen, Zeitreihen-Vorhersage auf Telemetriedaten, Vision-Language-Kodierung für Wahrnehmungsaufgaben und assoziative Abfrage mit Mikrosekunden-Latenz auf CPU. Ein Prozess, vier Workload-Klassen, Lizenz pro Klasse.

IoT-Worker

Spricht die Protokolle, die Smart Homes und Fabriken tatsächlich verwenden: OPC-UA für SPS und SCADA, Modbus TCP/RTU für Altanlagen und MQTT für alles dazwischen. Zeitreihen-Historian, Alarm-Management, OEE-Berechnung und ein Store-and-Forward-Puffer für Standorte mit instabiler Anbindung.

Wissenschafts-Worker

Bündelt wissenschaftliche Datenquellen aus sechzehn Kategorien — Teilchenphysik, Genomik, Neurowissenschaften, Klima, Archäologie und mehr — über eine zentrale Quellen-Registrierung. Admins schalten die Quellen frei, die ihre Mandanten brauchen; die LLM-aufrufbaren Werkzeuge bleiben gleich, egal welche Quellen verdrahtet sind. Eigene Plug-ins fügen sich unter custom ein, ohne dass am Worker-Code etwas geändert werden muss.

Drei Dinge, die wichtig sind.

Auf dem Pi läuft dieselbe Software.

Der 5.0-Kernel ist auf einem Raspberry Pi 4, auf einem Entwickler-Arbeitsplatz, auf einem Rack-Server und über einen Multi-Node-Cluster derselbe. Was sich ändert, sind die Module, die pro Knoten aktiv sind. Ein kleines Gerät bekommt kein abgespecktes Produkt — es bekommt dasselbe Produkt mit kleinerem aktiviertem Funktionsumfang.

Der Datenpfad ist kurz.

Edge → Router → Worker. Drei Stationen. Streaming-Antworten werden ohne Zwischenpufferung weitergereicht. Die Wissensbasis-Suche fragt zuerst das EMM ab (komprimierte, assoziative Erinnerung) und ergänzt nur dort den Vektor-Speicher, wo exakte Quellenangaben gebraucht werden — bei reinen Chat-Szenarien kann der Vektor-Speicher ganz weggelassen werden. Es gibt keine versteckte Zwischenschicht, die Ihre Daten verkauft.

Ehrlicher Stand: wo es schnell ist, wo nicht.

Auf unserem Referenz-Cluster hält Chat 793 Anfragen pro Sekunde bei 32 parallelen Verbindungen durch, mit einer Median-Latenz von 41 Millisekunden. Das ist gut. Wissensbasis-Suche bei vier parallelen Anfragen stößt heute noch auf eine Schwelle von rund 7 Sekunden im Median. Das ist nicht gut, und wir arbeiten daran. Die Zahlen kommen aus unserer 2026-05-Messung; wir veröffentlichen sie, damit Sie wissen, was Sie erwartet.


Hardware

Worauf es tatsächlich läuft.

Unser Referenz-Cluster ist bewusst bescheiden. Die obigen Zahlen kommen von dieser Hardware.

1
Inferenz-GPU (RTX 4070 Ti, 12 GB) für LLMs
1
Router-GPU (RTX 2080, 8 GB) für Routing + kleine Modelle
5
Knoten insgesamt — inklusive Controller, Edge, Daten
Pi 4
Das kleinste Ziel — 8 GB RAM reichen für Kernel + leichte Modelle