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.