Pali v0.1 : Infrastructure de mémoire open source pour LLM avec des benchmarks reproductibles

Qu'est-ce que Pali
Pali est une infrastructure de mémoire open source pour les LLM qui est axée sur l'infrastructure. Il est construit en Go sous forme d'un binaire unique prêt à l'emploi avec des configurations pour des extensions plug-and-play comme qdrant, neo4j, ollama et openrouter. Le projet est sous licence MIT et entièrement auto-hébergeable.
Fonctionnalités principales
- API de mémoire multi-locataires avec isolation par locataire
- Récupération hybride à travers lexical, dense, fusion, reranking et expansion multi-sauts optionnelle
- Serveur MCP avec outils axés sur la mémoire et résolution tenant-aware
- API REST avec packages Python et JavaScript respectifs en direct
- Tableau de bord pour les opérateurs inspectant les locataires, les mémoires et l'état du système
- Points d'extension plug-and-play pour les magasins vectoriels, les embedders, les backends d'entités-faits et le scoring/routage
Approche de benchmark
Le créateur aborde les problèmes courants des benchmarks de piles de mémoire en mettant en œuvre une approche reproductible :
- Chaque exécution stocke les fichiers de configuration exacts utilisés (profil + rendu)
- Le matériel est entièrement divulgué (CPU, GPU, RAM, versions des modèles)
- Comparaisons appariées uniquement — même fixture/évaluation/top_k pour tous les profils
- Les voies de vitesse et les voies de qualité de récupération sont séparées
Chiffres de performance
Benchmarks des tests sur un Ryzen 9 7950X + RTX 5070 :
- sqlite + lexical : 208 opérations de stockage/s, Top1=0.32, Recall@5=0.54
- qdrant + ollama (all-minilm) : 98 opérations de stockage/s, Top1=0.34, Recall@5=0.52
- parser+graph (voie de stress mémoire structurée) : 2.4 opérations de stockage/s — lent en raison du coût d'extraction structurée, mais atteint ~30 en moyenne sur LoCoMo avec des pics temporels autour de ~40
Clarification importante
Pali n'est pas une mémoire LLM au sens SaaS. Il renvoie des résultats de récupération bruts que vous optimisez pour votre propre flux de travail — pas de scoring boîte noire, pas de décisions de fournisseur verrouillées. Vous pouvez échanger les backends vectoriels, les embedders et les scoreurs via la configuration sans changer le contrat de votre application.
État du projet
La version 0.1 a été récemment publiée avec une suite de benchmarks appropriée ajoutée. Le créateur recherche des contributeurs.
📖 Read the full source: r/LocalLLaMA
👀 See Also

Le plugin MCP de mise en cache des invites réduit automatiquement les coûts de l'API Claude en identifiant le contexte stable.
Le plugin MCP de mise en cache des prompts identifie automatiquement les parties stables du contexte comme les prompts système et les définitions d'outils, puis les marque pour la fonctionnalité de mise en cache d'Anthropic afin de réduire les coûts de l'API de 80 à 92 % lors des sessions de codage.

Évaluation de Nemotron 3 Super 120B avec un contexte de 1 million de tokens sur M1 Ultra
Un utilisateur a testé Nemotron 3 Super 120B avec un modèle quantifié Q4_K_M en utilisant llama.cpp sur un M1 Ultra, atteignant une fenêtre de contexte d'un million de tokens qui a consommé environ 90 Go de VRAM. Les benchmarks de performance montrent des vitesses de génération de tokens allant de 255 t/s pour un traitement de prompt de 512 tokens jusqu'à 22,37 t/s pour un contexte de 100 000 tokens.

Optio : Orchestration d'Agents d'IA de Codage dans Kubernetes du Ticket à la PR
Optio est un système d'orchestration open source qui transforme les tickets en demandes de fusion (pull requests) en utilisant des agents de codage IA comme Claude Code ou Codex. Il gère l'intégralité du cycle de vie dans des pods Kubernetes isolés avec une boucle de rétroaction qui redémarre automatiquement les agents en cas d'échec d'intégration continue ou de retours de revue.

CostHawk lance un classement public pour la consommation de tokens de Claude Code, Codex et Cursor
Le classement de CostHawk classe les utilisateurs publics de Claude Code, OpenAI Codex et Cursor par consommation totale de tokens, en suivant les compteurs, modèles et horodatages de synchronisation sans stocker les prompts ni le code.