Les services IA de DnC

Politique LRU/MRU

Bertrand Degoy — 2026-06-29T09:04:20Z

Dans l'architecture Pyro5, les index ( et certains modèles ) sont chargés depuis le disque puis conservés en RAM pour être accessibles rapidement par les services distants. Le daemon joue le rôle de processus maître.

Pour les index par exemple, il les expose via IndexServer, et sert de point d'accès unique pour tous les RemoteIndexService.

Comme ces index peuvent être volumineux et que le daemon est conçu pour rester actif longtemps, il doit gérer sa mémoire de manière autonome et efficace. C'est précisément pour cela qu'une politique LRU/MRU est indispensable : elle permet de conserver en RAM les index les plus récemment utilisés (MRU), tout en évinçant automatiquement ceux qui ne sont plus sollicités (LRU).

Cette stratégie garantit que le flowchart Pyro5 fonctionne de manière fluide, sans surcharge mémoire, et que les services distants accèdent toujours aux index pertinents sans rechargement inutile depuis le disque.

Politique LRU/MRU

La politique LRU/MRU (Least Recently Used / Most Recently Used) est un mécanisme de gestion de la mémoire qui permet de décider quel objet doit être évincé lorsque la RAM atteint sa capacité maximale. Elle repose sur un principe simple :

MRU = objets récemment utilisés → à conserver
LRU = objets peu utilisés récemment → candidats à l'éviction

Dans notre système, cette politique est appliquée par le MemoryManager, qui maintient un ordre strict des objets en RAM grâce à un OrderedDict.

MRU — Most Recently Used

Un objet devient MRU lorsqu'il est :

chargé en RAM,
accédé via get(),
marqué via touch().

Le MemoryManager déplace alors la clé à la fin de l'OrderedDict :

[ LRU ... → ... MRU ]

Cela signifie :

cet index est actif,
il doit être conservé en priorité,
il ne doit pas être évincé tant que d'autres objets moins utilisés existent.

LRU — Least Recently Used

L'objet LRU est celui qui :

n'a pas été utilisé depuis le plus longtemps,
n'a pas été touché récemment,
se trouve au début de l'OrderedDict.

Lorsqu'une éviction est nécessaire (ex : len(store) > max_items), le MemoryManager fait :

key, _ = self._store.popitem(last=False)

Ce qui retire le premier élément, donc le LRU.

Pourquoi LRU/MRU est idéal dans ton architecture

1. Les index sont lourds

Ils peuvent peser plusieurs centaines de Mo.
Il est donc crucial d'éviter de recharger inutilement depuis le disque.

2. Les RemoteIndexService sont stateless

Ils ne conservent rien : tout repose sur la RAM du daemon.
LRU/MRU garantit que les index réellement utilisés restent disponibles.

3. Le daemon est long-lived

Il doit s'auto-réguler sans intervention humaine.
LRU/MRU fournit une politique simple, déterministe et efficace.

4. Les thèmes ont des patterns d'accès naturels

Certains thèmes sont consultés souvent (MRU), d'autres rarement (LRU).
La politique s'adapte automatiquement à ces usages.

Résultat : une mémoire auto-optimisée

Grâce à LRU/MRU :

Les index actifs restent en RAM → latence minimale
Les index inactifs sont évincés → RAM maîtrisée
Le daemon ne recharge que si nécessaire → I/O minimisées
Le système reste stable même sous forte charge → robustesse

Chargement des index

Bertrand Degoy — 2026-06-25T06:58:00Z

Le chargement des index repose sur une architecture modulaire où chaque composant joue un rôle précis, depuis le daemon initial jusqu'aux services distants qui exploitent les données en RAM.
L'objectif est de garantir un chargement efficace, unifié et non redondant des index, tout en permettant une mise en mémoire centralisée et partagée.
Grâce au ThemeIndexLoaderManager, les index sont reconstruits depuis le disque via des loaders spécialisés, normalisés en backends homogènes, puis mis à disposition des services Pyro5 pour répondre aux requêtes des clients. L'ensemble forme une chaîne cohérente, optimisée pour la performance et la réutilisation.

Chargement des index

Architecture générale

daemon.py ↓
MemoryManager ↓
IndexServer ↓
RemoteIndexService (créés à la demande) ↓
ThemeIndexLoaderManager (loader) ↓
Index en RAM

Description des composants

daemon.py

Point d'entrée du système. Initialise :

MemoryManager (gestion centralisée de la RAM)
IndexServer (service maître des index)
ThemeIndexLoaderManager (factory de loaders)

Il enregistre les services Pyro5 et expose IndexServer.

MemoryManager

Gestionnaire RAM partagé.

Stocke les backends d'index en mémoire
Applique les politiques LRU/MRU
Fournit get(), set(), touch() pour la gestion des index

IndexServer

Service maître Pyro5.

Centralise le chargement des index
Un seul backend par thème
Crée les RemoteIndexService à la demande
Réutilise les services déjà créés

IndexServer ne charge jamais directement depuis le disque : il délègue au ThemeIndexLoaderManager.

RemoteIndexService

Service Pyro5 par thème.

Reçoit les requêtes du client
Exécute les opérations sur l'index en RAM
Ne charge jamais lui-même un index : il dépend d'IndexServer

ThemeIndexLoaderManager (IndexLoaderFactory)

Factory de loaders.
Responsable de toute la chaîne de chargement depuis le disque :

Lire la configuration du thème
Déterminer le type d'index à charger
Instancier le loader concret
Charger les données persistées depuis le disque
Construire un backend unifié
Retourner le backend à IndexServer

Chaîne de chargement des index depuis le disque

(détaillée depuis IndexLoaderFactory / ThemeIndexLoaderManager)

1. Vue d'ensemble du pipeline

IndexLoaderFactory (ThemeIndexLoaderManager) ↓
Sélection du loader (selon thème + config) ↓
Loader concret (LlamaIndexLoader, FAISSLoader, etc.) ↓
Chargement depuis le disque ↓
Construction du backend unifié ↓
Retour à IndexServer ↓
Stockage dans MemoryManager (RAM) ↓
RemoteIndexService utilise l'index

2. IndexLoaderFactory / ThemeIndexLoaderManager

Ce composant est la factory centrale.
Il est responsable de :

Lire la configuration du thème (ex : theme_config.json)
Déterminer le type d'index à charger :
- llama_index
- faiss
- dummy
- custom
Instancier le loader concret correspondant
Appeler loader.load()
Retourner un backend unifié, prêt à être mis en RAM

Rôle clé

Il garantit que IndexServer ne connaît jamais les loaders concrets.
IndexServer ne manipule que des backends unifiés.

3. Sélection du loader

La factory applique une logique typique :

index_type = theme_config.get("index_type", "llama_index") if index_type == "llama_index": loader = LlamaIndexLoader(theme_name, theme_config)
elif index_type == "faiss": loader = FAISSLoader(theme_name, theme_config)
else: loader = DummyLoader(theme_name)

Chaque loader :

connaît son répertoire de stockage
connaît son format de données
sait reconstruire un backend utilisable

4. Loader concret : chargement depuis le disque

Exemple : LlamaIndexLoader

Responsable de :

Construire un StorageContext
Charger les fichiers persistés :
- docstore.json
- vector_store.json
- index_store.json
Recréer l'index LlamaIndex complet
Appliquer le modèle d'embedding (si nécessaire)
Retourner un objet Python opaque (backend)

Pseudo-code :

def load(self): storage = StorageContext.from_defaults(persist_dir=self.storage_dir) index = load_index_from_storage(storage) return index

Exemple : FAISSLoader

Responsable de :

Charger le fichier .faiss
Charger les métadonnées associées
Recréer l'index FAISS en RAM
Retourner un backend unifié

Pseudo-code :

def load(self): faiss_index = faiss.read_index(self.index_path) metadata = json.load(open(self.meta_path)) return FAISSBackend(faiss_index, metadata)

DummyLoader

Toujours utile pour les tests :

def load(self): return {"theme": self.theme_name, "data": "fake_index"}

5. Construction du backend unifié

Chaque loader retourne un objet différent :

LlamaIndex → VectorStoreIndex
FAISS → FAISSBackend
Dummy → dict

La factory applique ensuite une normalisation :

backend = IndexBackend(index_object, index_type)

Ce backend :

expose une API homogène (query(), search(), metadata())
masque les différences entre loaders
permet à RemoteIndexService d'être totalement générique

6. Retour à IndexServer

IndexServer reçoit le backend :

backend = loader_manager.load(theme_name)

Puis :

stocke le backend dans MemoryManager
crée un RemoteIndexService si nécessaire
retourne le backend ou le service au daemon

IndexServer ne recharge jamais un index déjà en RAM.

7. Stockage dans MemoryManager (RAM)

MemoryManager :

stocke le backend sous la clé theme_name
applique une politique LRU/MRU
garantit qu'un index n'est chargé qu'une seule fois

La politique LRU/MRU (Least Recently Used / Most Recently Used) est un mécanisme de gestion de la mémoire qui permet de décider quel objet doit être évincé lorsque la RAM atteint sa capacité maximale. Elle repose sur un principe simple : MRU = objets récemment utilisés → à conserver LRU = objets peu utilisés récemment → candidats à l'éviction

Cette politique est appliquée par le MemoryManager, qui maintient un ordre strict des objets en RAM grâce à un OrderedDict.

memory.set(theme_name, backend)

8. Utilisation par RemoteIndexService

RemoteIndexService :

récupère l'index en RAM via MemoryManager
exécute les requêtes :
- search()
- query()
- similarity()
ne charge jamais lui-même un index

Résumé du chargement depuis le disque

Étape	Composant	Rôle
1	IndexLoaderFactory	Choix du loader + orchestration
2	Loader concret	Lecture disque + reconstruction
3	Factory	Normalisation backend
4	IndexServer	Stockage + exposition Pyro
5	MemoryManager	Mise en RAM + LRU
6	RemoteIndexService	Utilisation de l'index

Trois modes de chargement des modèles

Bertrand Degoy — 2026-06-24T09:23:00Z

Dans l'architecture v200, les modèles peuvent être chargés de trois manières : via une API distante (comme Mistral), en local sans persistance (chargement HuggingFace classique dans le process), ou en mémoire persistante grâce à un service Pyro5.

Les deux premiers modes sont simples mais limités : l'API impose une latence réseau et des coûts, tandis que le chargement local disparaît dès que le process se termine.

Pyro5 apporte une troisième voie : un daemon Python indépendant, capable de conserver des objets lourds (embedding, index, SLM) en RAM de manière durable, et de les exposer via RPC à tous les composants du runtime.

Dans ce modèle, models.json décrit les modèles à charger, ModelsConfigurator les instancie une seule fois au démarrage, puis AppSettings les expose à l'ensemble du système.

Les services Pyro5, déclarés dans services.json, ne chargent jamais de modèles eux‑mêmes : ils se contentent d'exposer des capacités (embedding, SLM, indexation, mémoire) en s'appuyant sur les objets déjà initialisés, garantissant ainsi cohérence, performance et séparation stricte des responsabilités.

Introduction

Dans l'architecture v200, la gestion des modèles repose sur une séparation stricte entre trois modes de chargement :

API distante (ex. Mistral) — aucun coût mémoire local, mais latence réseau et dépendance externe.
Chargement local non persistant — les modèles HF sont chargés dans le process courant, mais disparaissent dès que le process se termine.
Chargement persistant via Pyro5 — un daemon Python indépendant conserve les modèles lourds en RAM et expose leurs capacités via RPC, permettant une mutualisation entre plusieurs composants du runtime.

Cette architecture permet d'adapter le chargement des modèles aux contraintes matérielles (CPU, GPU, RAM), tout en garantissant une cohérence stricte :

models.json décrit les modèles à charger.
ModelsConfigurator les instancie une seule fois.
AppSettings les stocke en mémoire.
Les services Pyro5 les consomment via RPC sans jamais les recharger.

Vue d'ensemble du pipeline v200

1. Les trois modes de chargement des modèles

1.1 Modèles API (ex. Mistral)

Caractéristiques :

Aucun coût mémoire local
Latence réseau
Dépendance à un fournisseur
Coût financier potentiel
Pas de GPU requis

Exemple dans models.json :

"llm": { "model_name": "mistral-medium-latest", "backend": "mistral_api", "api_key": "env:MISTRAL_API_KEY"
}

Quand utiliser ?

Pas de GPU disponible
RAM limitée
Besoin d'un modèle puissant (Mixtral, Mistral Large)
Déploiement cloud ou edge léger

1.2 Modèles locaux non persistants (HF dans le process)

Caractéristiques :

Chargés par HuggingFace dans le process courant
Disparaissent à la fin du process
Temps de chargement non négligeable
Nécessitent RAM + CPU/GPU
Idéal pour tests, scripts, outils CLI

Exemple :

"slm": { "model_name": "TinyLlama/TinyLlama-1.1B-Chat-v1.0", "model_path": "/home/user/.models/TinyLlama", "backend": "hf", "device": "cpu"
}

Quand utiliser ?

Développement local
Tests unitaires
Modèles légers (<2 GB)
Pas besoin de persistance

Sur ce dernier point, notons qu'un service HTTP Rest ne chargera les modèles qu'une fois à son lancement ; dans cette configuration, on pourra s'accommoder de la non-persistance, au prix d'un délai au re-lancement du service.

1.3 Modèles persistants via Pyro5 (daemon)

Caractéristiques :

Modèles chargés une seule fois dans un daemon
Persistants en RAM
Accessibles via RPC
Mutualisés entre plusieurs composants
Idéal pour embeddings, index, SLM

Exemple dans services.json :

{ "name": "embedding.server", "class": "runtime_v2.services.embedding.embedding_server.EmbeddingServer", "params": {}
}

Quand utiliser ?

Modèles lourds (embedding, SLM)
Besoin de persistance
Plusieurs clients doivent accéder au même modèle
RAM suffisante (8–32 GB selon modèles)

2. Quelle solution pour quel modèle ? (selon contraintes matérielles)

2.1 Embedding (BGE-small, BGE-large, E5, etc.)

Contrainte	Recommandation
< 4 GB RAM	API ou modèle très léger (BGE-small)
4–8 GB RAM	HF local non persistant
> 8 GB RAM	Pyro5 persistant (recommandé)

Pourquoi Pyro5 ?
Les embeddings sont appelés très souvent → éviter les rechargements → gain x10 en latence.

2.2 SLM (TinyLlama, Phi-2, Gemma 2B)

Contrainte	Recommandation
CPU only	TinyLlama / Phi-2 via Pyro5
GPU 4–8 GB	Gemma 2B local
GPU 16 GB	Mixtral 8x7B local (rare)

Pourquoi Pyro5 ?
Les SLM sont lourds à charger → persistance indispensable.

2.3 Tokenizer

Contrainte	Recommandation
Toujours	HF local non persistant

Pourquoi ?
Le tokenizer est léger (<200 MB) → inutile de le mettre dans Pyro5.

2.4 LLM principal (Mistral, Mixtral, Claude, GPT)

Contrainte	Recommandation
Pas de GPU	API obligatoire
GPU 24–48 GB	Mixtral local possible
GPU > 80 GB	Modèles 70B locaux

Conclusion :
Dans 99 % des cas → API.

3. Exemples complets

3.1 Exemple `models.json` optimisé pour machine CPU 16 GB

Embedding en Pyro5
SLM en Pyro5
Tokenizer local
LLM via API

{ "embedding": { "model_name": "BAAI/bge-small-en-v1.5", "model_path": "/models/bge-small", "backend": "hf", "device": "cpu" }, "slm": { "model_name": "TinyLlama/TinyLlama-1.1B-Chat-v1.0", "model_path": "/models/tinyllama", "backend": "hf", "device": "cpu" }, "tokenizer": { "model_name": "mistralai/Mixtral-8x7B-Instruct-v0.1", "backend": "hf" }, "llm": { "model_name": "mistral-medium-latest", "backend": "mistral_api", "api_key": "env:MISTRAL_API_KEY" }
}

3.2 Exemple `services.json` correspondant

Voir Construction des modèles : models.json et services.json

{ "daemon": { "host": "127.0.0.1", "port": 50050 }, "services": [ { "name": "embedding.server", "class": "runtime_v2.services.embedding.embedding_server.EmbeddingServer", "params": {} }, { "name": "slm.server", "class": "runtime_v2.services.llm.slm_server.SLMServer", "params": {} }, { "name": "index.server", "class": "runtime_v2.services.index.index_server.IndexServer", "params": { "embedding_service": "embedding.server" } }, { "name": "memory.server", "class": "runtime_v2.services.memory_manager.MemoryManager", "params": { "embedding_service": "embedding.server", "index_service": "index.server" } } ]
}

Construction des modèles : models.json et services.json

Bertrand Degoy — 2026-06-23T08:51:00Z

L'architecture v200 repose sur une séparation stricte entre la définition des modèles, leur construction centralisée, et la déclaration des services qui les consomment.
Les modèles sont décrits dans un fichier unique (`models.json`), puis construits une seule fois au démarrage par le `ModelsConfigurator`, avant d'être stockés dans `AppSettings` pour être partagés par l'ensemble du runtime.
Les services Pyro5, déclarés dans `services.json`, ne chargent jamais de modèles eux‑mêmes : ils se contentent d'exposer des capacités en s'appuyant sur les objets déjà initialisés, garantissant ainsi cohérence, performance et isolation des responsabilités.

Construction des modèles : `models.json` et `services.json`

1. Présentation générale : comment les modèles sont construits dans v200

L'architecture v200 repose sur une séparation stricte des responsabilités :

1. `models.json` décrit les modèles

Ce fichier déclare uniquement les modèles utilisés par le runtime :

embedding
slm
tokenizer
llm

Chaque entrée décrit :

model_name
model_path (optionnel)
backend
device
api_key (si backend = API)

2. ModelsConfigurator construit les modèles

Le composant ModelsConfigurator :

lit models.json
instancie les modèles (HF, API, local, etc.)
crée les objets Python correspondants

Il ne connaît pas les services Pyro5.

3. AppSettingsManager stocke les modèles

Une fois construits, les modèles sont transmis à :

AppSettingsManager.load_models(...)

Ce composant :

crée un objet AppSettings
stocke les modèles dans des attributs statiques
verrouille la configuration

4. Les services Pyro5 consomment les modèles

Les services (EmbeddingServer, SLMServer, IndexServer, MemoryManager) :

ne chargent pas de modèles
ne reçoivent pas de paramètres de modèle
récupèrent les modèles via :

from runtime_v2.settings.app_settings import AppSettings self.embedding = AppSettings.embedding
self.slm = AppSettings.slm
self.tokenizer = AppSettings.tokenizer
self.llm = AppSettings.llm

5. `services.json` décrit uniquement les services

Ce fichier :

déclare les services Pyro5
indique leur classe Python
fournit uniquement les paramètres nécessaires aux RPC (ex : nom d'un autre service)

Il ne doit jamais contenir de paramètres de modèle.

2. Comment écrire `models.json`

Voici la structure officielle :

{ "embedding": { "model_name": "BAAI/bge-small-en-v1.5", "model_path": "/home/iadnc/.models/bge-small", "backend": "hf", "device": "cpu" }, "slm": { "model_name": "TinyLlama/TinyLlama-1.1B-Chat-v1.0", "model_path": "/home/iadnc/.models/TinyLlama-1.1B-Chat-v1.0", "backend": "hf", "device": "cpu" }, "tokenizer": { "model_name": "mistralai/Mixtral-8x7B-Instruct-v0.1", "model_path": null, "backend": "hf", "device": null }, "llm": { "model_name": "mistral-medium-latest", "backend": "mistral_api", "api_key": "env:MISTRAL_API_KEY", "model_path": null, "device": null }
}

Règles :

Chaque modèle doit avoir un model_name
model_path peut être null si HF doit télécharger automatiquement
backend détermine le loader (hf, hf_local, mistral_api, etc.)
device peut être cpu, cuda, ou null
api_key est utilisé uniquement pour les backends API

3. Comment écrire `services.json`

Voici la version correcte, conforme à v200 :

{ "daemon": { "host": "127.0.0.1", "port": 50050 }, "services": [ { "name": "embedding.server", "class": "runtime_v2.services.embedding.embedding_server.EmbeddingServer", "params": {} }, { "name": "slm.server", "class": "runtime_v2.services.llm.slm_server.SLMServer", "params": {} }, { "name": "index.server", "class": "runtime_v2.services.index.index_server.IndexServer", "params": { "embedding_service": "embedding.server" } }, { "name": "memory.server", "class": "runtime_v2.services.memory_manager.MemoryManager", "params": { "embedding_service": "embedding.server", "index_service": "index.server" } } ]
}

Règles :

Aucun service ne doit recevoir de modèle
→ pas de model, model_name, backend, device, etc.
Les services doivent recevoir uniquement :
- des noms de services Pyro5 (pour RPC)
- des paramètres métier (rare)
Les services doivent récupérer les modèles via AppSettings.

4. Résumé

Élément	Rôle	Contenu
`models.json`	Décrit les modèles	model_name, backend, device, path
`ModelsConfigurator`	Construit les modèles	HF, API, local
`AppSettingsManager`	Stocke les modèles	AppSettings.embedding, etc.
`services.json`	Décrit les services	classes, RPC, dépendances
Services Pyro5	Consomment les modèles	via AppSettings

Les services IA de DnC

Politique LRU/MRU

Politique LRU/MRU

MRU — Most Recently Used

LRU — Least Recently Used

Pourquoi LRU/MRU est idéal dans ton architecture

1. Les index sont lourds

2. Les RemoteIndexService sont stateless

3. Le daemon est long-lived

4. Les thèmes ont des patterns d'accès naturels

Résultat : une mémoire auto-optimisée

Chargement des index

Chargement des index

Architecture générale

Description des composants

daemon.py

MemoryManager

IndexServer

RemoteIndexService

ThemeIndexLoaderManager (IndexLoaderFactory)

Chaîne de chargement des index depuis le disque

1. Vue d'ensemble du pipeline

2. IndexLoaderFactory / ThemeIndexLoaderManager

Rôle clé

3. Sélection du loader

4. Loader concret : chargement depuis le disque

Exemple : LlamaIndexLoader

Exemple : FAISSLoader

DummyLoader

5. Construction du backend unifié

6. Retour à IndexServer

7. Stockage dans MemoryManager (RAM)

8. Utilisation par RemoteIndexService

Résumé du chargement depuis le disque

Trois modes de chargement des modèles

Introduction

Vue d'ensemble du pipeline v200

1. Les trois modes de chargement des modèles

1.1 Modèles API (ex. Mistral)

1.2 Modèles locaux non persistants (HF dans le process)

1.3 Modèles persistants via Pyro5 (daemon)

2. Quelle solution pour quel modèle ? (selon contraintes matérielles)

2.1 Embedding (BGE-small, BGE-large, E5, etc.)

2.2 SLM (TinyLlama, Phi-2, Gemma 2B)

2.3 Tokenizer

2.4 LLM principal (Mistral, Mixtral, Claude, GPT)

3. Exemples complets

3.1 Exemple models.json optimisé pour machine CPU 16 GB

3.2 Exemple services.json correspondant

Construction des modèles : models.json et services.json

Construction des modèles : models.json et services.json

1. Présentation générale : comment les modèles sont construits dans v200

1. models.json décrit les modèles

2. ModelsConfigurator construit les modèles

3. AppSettingsManager stocke les modèles

4. Les services Pyro5 consomment les modèles

5. services.json décrit uniquement les services

2. Comment écrire models.json

Règles :

3. Comment écrire services.json

Règles :

4. Résumé

3.1 Exemple `models.json` optimisé pour machine CPU 16 GB

3.2 Exemple `services.json` correspondant

Construction des modèles : `models.json` et `services.json`

1. `models.json` décrit les modèles

5. `services.json` décrit uniquement les services

2. Comment écrire `models.json`

3. Comment écrire `services.json`