Dreischichtige Cache-Architektur senkt LLM-Suchlatenz auf CPU-Hardware

Dreischichtige Cache-Architektur senkt LLM-Suchlatenz auf CPU-Hardware

OreoLook (ehemals lixSearch) ist eine Open-Source-Answer-Engine, die automatisierte Browser-Agenten und provider-geroutete LLM-Inferenz nutzt. Die lokale Suche, das Caching, Session-Management und der Embedding-Stack laufen auf Standard-CPU-Hardware; die Antwort-Synthese erfolgt durch einen entfernten Inferenz-Provider. Um die Latenz zu senken und redundante LLM-Aufrufe zu vermeiden, haben die Entwickler eine dreischichtige Cache-Architektur implementiert. Die erste Schicht, das Session Context Window, hält ein rollierendes Fenster aktueller Nachrichten in Redis. Bei Überlauf weicht es automatisch auf Huffman-komprimierte Disk-Archive aus. Die zweite Schicht, der Semantic Query Cache, erkennt Umformulierungen über Kosinus-Ähnlichkeit auf Embedding-Vektoren und eliminiert dadurch redundante LLM-Aufrufe. Die dritte Schicht, der URL Embedding Cache, dedupliziert Embedding-Berechnungen über Sessions hinweg. Nach Angaben der Entwickler erreichte das System auf einem einzelnen 8-vCPU Intel Cascade Lake Server (2 GHz, 32 GB RAM) eine aggregierte Redis-Keyspace-Hit-Rate von 89,3 Prozent bei einer Leselatenz von 0,1 Millisekunden. Der Memory-Overhead lag bei 1,38 Megabyte. Diese Werte zeigen, dass die Cache-Schichten einen Großteil der Anfragen abfangen, bevor überhaupt ein LLM-Aufruf nötig wird. Die Architektur adressiert drei Probleme, die bei wachsender Nutzung auftraten: Sessions verloren Kontext, äquivalente Anfragen lösten redundante Arbeit aus, und URLs wurden wiederholt über Sessions hinweg eingebettet.

Technische Umsetzung: Redis, Huffman-Kompression und LRU-Eviction

Das System wurde auf einem einzelnen 8-vCPU Intel Cascade Lake Server mit 2 GHz Takt und 32 GB RAM deployed. Darauf laufen 30 Hypercorn-Worker-Prozesse, verteilt über drei containerisierte Replicas. Diese Konfiguration erlaubt eine parallele Verarbeitung von Anfragen, ohne dass eine GPU benötigt wird. Das Session Context Window hält die jüngsten Nachrichten einer Sitzung im Redis-Speicher. Überschreitet die Sitzung die Kapazität des Fensters, weicht das System automatisch auf Huffman-komprimierte Disk-Archive aus. Dadurch bleibt der Speicherverbrauch begrenzt, während ältere Konversationsteile weiterhin verfügbar sind. Ein Hintergrund-LRU-Eviction-Daemon (Least Recently Used) migriert inaktive Sessions von Redis auf die Festplatte und rehydriert sie bei Bedarf wieder in den Speicher. So wird der Arbeitsspeicher effizient genutzt, ohne dass Sitzungsdaten verloren gehen. Die Kombination aus Redis für schnelle Zugriffe, Huffman-Kompression für platzsparende Archivierung und LRU-Eviction für das Auslagern seltener genutzter Daten ermöglicht den Betrieb auf Standard-CPU-Hardware, wie die gemessenen Latenzwerte belegen.