Für Skalierung gebaut
EDDI läuft auf Java 25 mit Quarkus und nutzt Virtual Threads (Project Loom) für massive I/O-gebundene Nebenläufigkeit. Anders als Node.js Event-Loops bieten Virtual Threads echte Multi-Thread-Parallelität mit minimalem Overhead.
Warum virtuelle Threads für KI-Agenten wichtig sind
Moderne KI-Agenten sind grundlegend I/O-gebunden.
Java Virtual Threads lösen dies elegant.
Performance-Highlights
- Virtual Threads: Millionen leichtgewichtiger Threads für gleichzeitige LLM-Aufrufe
- Quarkus-Runtime: Cloud-natives Java mit Dev-Mode-Hot-Reload, optimiert für Container. Quarkus liefert deutlich höheren Durchsatz und schnelleren Start als klassische JVM-Stacks, bei geringerem Speicherbedarf
- Loom-freundliche Verbindungspools: Agroal Connection Pooling vermeidet ThreadLocal-Engpässe, die traditionelle Pools unter Virtual-Thread-Lasten beeinträchtigen können
- NATS JetStream: Horizontale Skalierung mit eventgesteuerter Architektur
- Dual Database: MongoDB oder PostgreSQL, Umschaltung mit einer Umgebungsvariable. Ein Docker-Image für beide
- SSE-Streaming: Echtzeit-Chat-Antworten, Gruppendiskussions-Feeds und Live-Log-Streaming über Server-Sent Events
- Ein-Befehl-Installation: Interaktiver Assistent stellt EDDI + Datenbank + Starter-Agent über Docker Compose bereit
- Red Hat Zertifiziert: Container-Zertifizierung mit automatisierten Preflight-Checks in CI/CD
Leistung im Kontext
Keine Laufzeitumgebung gewinnt in jedem Szenario. Node.js kann Java in hochspezifischen, reinen I/O-Routing-Szenarien übertreffen, während Java bei Workloads mit CPU-intensiven Aufgaben konsistent vorne liegt, und genau das benötigen KI-Agenten. Moderne Agenten kombinieren massives I/O (LLM-API-Aufrufe, Vektorabfragen) mit intensiver Berechnung (Datentransformation, Routing-Logik, Embedding-Verarbeitung, Konfidenzbewertung). Genau bei diesem gemischten Workload-Profil spielen virtuelle Threads auf Quarkus ihre größte Stärke aus.
EDDIs Architektur ist bewusst für diese Realität optimiert: Quarkus mit virtuellen Threads für die I/O-lastige Agent-Orchestrierungsschicht, kombiniert mit Loom-freundlichen Verbindungspools (Agroal), die die ThreadLocal-Konfliktprobleme vermeiden, die bei traditionellen Pooling-Bibliotheken unter hoher Virtual-Thread-Nebenläufigkeit auftreten.