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.

Worker

Einer pro Aufgabe. Inferenz-Worker betreiben Modelle (Ollama, vLLM, llama.cpp oder eine Cloud-API). Daten-Worker speichern Dateien, Vektoren und Matrix-Memory. 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. Wissenschafts-Worker leiten an die 140 externen wissenschaftlichen APIs weiter. Trainings-Worker stimmen Modelle fein ab.

Inferenced

Ein nativer Inferenz-Worker, der GGUF- und xLSTM-Modelle direkt über eingebettetes llama.cpp lädt. Keine Ollama-Abhängigkeit. Für die kleinsten Installationen und für Air-Gap-Standorte.

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