Intégration LLM du Runtime

Statut documentaire : architecture — voir Maturité et preuves.

logiCells sépare le contrat de service LLM du backend d’inférence. Les applications doivent dépendre de la capacité LLM générique ; le provider prend en charge le chargement du modèle, l’ordonnancement, la génération des tokens et les ressources propres au backend.

L’architecture actuelle comporte deux chemins locaux distincts qu’il ne faut pas confondre :

• le Runtime GGUF/Transformer natif de logiCells, utilisé par la pile tenseur/Transformer ;
• un provider llama.cpp, qui charge un modèle local compatible via llama.cpp derrière la frontière de service LLM générique.

Le nom canonique du provider llama.cpp est logicells.llm.llama.cpp. llama.cpp est le nom lisible du backend. L’ancienne terminologie MiniOllama est retirée car ce provider n’implémente ni le serveur ni l’API Ollama.

Frontière publique

application / agent / processus
        |
        v
   contrat de service LLM
        |
        +-- Runtime LLM natif logiCells
        |
        +-- provider llama.cpp
        |
        +-- providers distants ou futurs

Le code applicatif ne doit pas dépendre des handles natifs llama.cpp, des files de requêtes, des workers ou des sessions internes. Ces éléments restent des détails d’implémentation du backend.

Pour continuer

• Contrat de service LLM
• Exécuter un modèle local avec le provider llama.cpp
• Cycle de vie du provider llama.cpp
• Patterns d’usage LLM

Le nommage décrit ici est le nommage canonique cible du renommage en cours. Tant que la modification correspondante n’est pas intégrée au source, d’anciens identifiants internes peuvent encore apparaître dans l’arbre d’implémentation.