Ninetails Memory Engine V4.5：Int8量子化+LRUキャッシュにより、ローカルMCPメモリを60MBに削減

Ninetails Memory Engine V4.5は、Int8スカラー量子化とLRUキャッシュ削除を組み合わせることで、ローカルMCP（Model Context Protocol）ツールにおけるメモリのボトルネックに対処します。このソリューションにより、Tauriデスクトップアプリ内で動作するエンジンプロセス全体を40-60MBのRAMで維持します。

メモリの問題

標準的な1536次元のfloat32埋め込みは、約6144バイト（〜6KB）を消費します。10,000個のメモリを保存すると、ベクトルだけで約60MB、100,000個では約600MBに達します。SQLite上で動作するローカルツールにとって、このリソース消費は許容できません。

技術的実装

第1層：Int8スカラー量子化

float32（1次元あたり4バイト）をint8（1次元あたり1バイト）に圧縮することで、ストレージ容量を元のサイズの4分の1に削減します。実装では、各次元の数値範囲を計算し、浮動小数点数を-128から127の整数範囲にマッピングし、コサイン類似度の検索時にはfloat32に逆量子化します。

# 量子化: 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)

# 逆量子化: int8 → float32 (近似)
def dequantize_vector(vector_int8, scale, zero_point):
    return (vector_int8.astype(np.float32) - zero_point) * scale

実際の結果：1536次元のベクトルは、6144バイトから1536バイトに削減されます。グローバルなスケールとzero_pointのオーバーヘッドを考慮すると、実際の圧縮率は約3.8倍から4.0倍です。

第2層：LRUキャッシュ削除

量子化されたベクトルは、Least Recently Used戦略を用いてSQLiteデータベース（vector_cache.sqlite）に保存され、10,000エントリのハードキャップが設けられます。高頻度のベクトルはRAMに保持され、古いベクトルは削除されます。

精度に関する考慮事項

Int8量子化は損失を伴いますが、メモリ検索では許容されます。理由は以下の通りです：

• エンジンはハイブリッド検索を使用：70%のベクトル類似度 + 30%のBM25。量子化によってベクトルのランキングがわずかに歪んでも、BM25による正確なキーワードマッチングが関連するメモリを上位に引き上げます。
• AIメモリ検索では、コンテキストを上位5件の結果に表示できれば十分であり、1位の精度を絶対的に必要とする推薦アルゴリズムとは異なります。

「TurboQuant」についての説明

このエンジンは、SQLiteベクトルストレージに標準のInt8スカラー量子化を使用しており、GoogleのTurboQuant（ICLR 2026）は使用していません。TurboQuantは、LLM GPU推論中のKVキャッシュ向けに設計された3ビット圧縮アルゴリズム（PolarQuant + QJL）です。UIでの「TurboQuant Compression」という表記は、積極的なビット削減の哲学へのオマージュです。

完全な技術スタック

• ベクトル圧縮： Int8スカラー量子化（約4倍の実圧縮）
• キャッシュ管理： SQLite + LRU削除（上限：10,000エントリ）
• 検索エンジン： ハイブリッド：70%ベクトル類似度 + 30% BM25
• プロファイルマネージャー： 自動STATIC/DYNAMIC事実抽出
• 事実抽出： asyncio.to_thread バックグラウンド非同期LLM呼び出し
• データストレージ： 3つのSQLiteデータベース（100%ローカル）
• デスクトップアプリ： Tauri + Vue 3 + PyInstallerサイドカー

このエンジンは、GitHub: sunhonghua1/ninetails-memory-engine でMITライセンスの下オープンソースとして公開されています。