Ninetails Memory Engine V4.5: Int8-Quantisierung + LRU-Cache reduziert lokalen MCP-Speicher auf 60 MB

Die Ninetails Memory Engine V4.5 adressiert den Speicherengpass in lokalen MCP-Tools (Model Context Protocol) durch die Implementierung von Int8-Skalarquantisierung in Kombination mit LRU-Cache-Auslagerung. Die Lösung hält den gesamten Engine-Prozess innerhalb einer Tauri-Desktop-App bei 40–60 MB RAM.

Das Speicherproblem

Ein Standard-Embedding mit 1536 Dimensionen im Float32-Format benötigt etwa 6144 Bytes (~6 KB). Die Speicherung von 10.000 Erinnerungen bedeutet ~60 MB nur für Vektoren, was sich auf ~600 MB für 100.000 Erinnerungen skaliert. Für ein lokales Tool, das auf SQLite läuft, ist dieser Ressourcenverbrauch inakzeptabel.

Technische Implementierung

Ebene 1: Int8-Skalarquantisierung

Durch die Komprimierung von Float32 (4 Bytes/Dim) auf Int8 (1 Byte/Dim) wird das Speichervolumen auf ein Viertel seiner ursprünglichen Größe reduziert. Die Implementierung berechnet den numerischen Bereich jeder Dimension, bildet Floats auf einen Integer-Bereich von -128 bis 127 ab und dequantisiert während des Abrufs zurück zu Float32 für die Kosinusähnlichkeit.

# Quantisieren: float32 → int8
def quantize_vector(vector_fp32, scale, zero_point):
    quantized = np.round(vector_fp32 / scale) + zero_point
    return np.clip(quantized, -128, 127).astype(np.int8)

# Dequantisieren: int8 → float32 (Approximation)
def dequantize_vector(vector_int8, scale, zero_point):
    return (vector_int8.astype(np.float32) - zero_point) * scale

Reales Ergebnis: Ein 1536-Dim-Vektor sinkt von 6144 Bytes auf 1536 Bytes. Unter Berücksichtigung des globalen Skalen- und Zero-Point-Overheads liegt das reale Kompressionsverhältnis bei etwa 3,8x - 4,0x.

Ebene 2: LRU-Cache-Auslagerung

Quantisierte Vektoren werden in einer SQLite-Datenbank (vector_cache.sqlite) unter Verwendung einer Least-Recently-Used-Strategie mit einer harten Obergrenze von 10.000 Einträgen gespeichert. Hochfrequente Vektoren bleiben im RAM, während veraltete ausgelagert werden.

Präzisionsüberlegungen

Int8-Quantisierung ist verlustbehaftet, aber für den Speicherabruf akzeptabel, weil:

• Die Engine eine Hybridsuche verwendet: 70 % Vektorähnlichkeit + 30 % BM25. Selbst wenn die Quantisierung die Vektorrangfolge leicht verzerrt, holt die genaue Schlüsselwortübereinstimmung via BM25 relevante Erinnerungen wieder nach oben.
• Der KI-Speicherabruf muss Kontext nur in den Top-5-Ergebnissen an die Oberfläche bringen, anders als Empfehlungsalgorithmen, die absolute Präzision für den ersten Platz benötigen.

Klärung zu "TurboQuant"

Die Engine verwendet Standard-Int8-Skalarquantisierung für die SQLite-Vektorspeicherung, nicht Googles TurboQuant (ICLR 2026), bei dem es sich um einen 3-Bit-Kompressionsalgorithmus (PolarQuant + QJL) handelt, der für den KV-Cache während der LLM-GPU-Inferenz entwickelt wurde. Die Bezeichnung "TurboQuant Compression" in der UI ist eine Anspielung auf die Philosophie der aggressiven Bitreduktion.

Vollständiger Tech-Stack

• Vektorkompression: Int8-Skalarquantisierung (~4x reale Kompression)
• Cache-Management: SQLite + LRU-Auslagerung (Obergrenze: 10.000 Einträge)
• Suchmaschine: Hybrid: 70 % Vektorähnlichkeit + 30 % BM25
• Profilmanager: Automatische STATIC/DYNAMIC-Faktenextraktion
• Faktenextraktion: asyncio.to_thread Hintergrund-Async-LLM-Aufrufe
• Datenspeicherung: 3x SQLite-Datenbanken (100 % lokal)
• Desktop-App: Tauri + Vue 3 + PyInstaller Sidecar

Die Engine ist unter der MIT-Lizenz quelloffen auf GitHub: sunhonghua1/ninetails-memory-engine.