Contrat de service LLM

Statut documentaire : architecture — voir Maturité et preuves.

Le contrat de service LLM constitue la frontière stable côté application. Un provider peut l’implémenter avec llama.cpp, le Runtime natif logiCells, un endpoint distant ou un autre moteur d’inférence.

Cycle de vie principal

Un service expose les opérations sémantiques suivantes :

configurer le modèle
    -> démarrer le service
    -> soumettre une ou plusieurs requêtes
    -> streamer le texte généré
    -> terminer / annuler
    -> arrêter le service
    -> éventuellement décharger le modèle

Le contrat actuel comprend la configuration du modèle, Start, Stop, le déchargement explicite du modèle, l’annulation du travail courant, la soumission des requêtes et quelques états/diagnostics de base.

Contrat de requête

Une requête transporte au minimum :

• un identifiant fourni par l’appelant ou généré ;
• le prompt ;
• un budget maximal de tokens générés ;
• un callback de tokens pour le streaming ;
• un callback de fin ;
• une politique de dispatch des callbacks.

Un prompt vide et un budget de tokens non positif sont rejetés avant l’entrée de la requête dans la file du backend.

Indépendance du provider

Les objets propres au provider ne doivent pas franchir cette frontière. En particulier, les bindings publics ne doivent pas exposer les handles modèle/contexte/sampler de llama.cpp ni les objets internes d’ordonnancement.

Le registre de providers doit identifier l’implémentation llama.cpp par :

logicells.llm.llama.cpp

Le code de plus haut niveau peut ainsi sélectionner le backend sans coupler le modèle applicatif à son implémentation.

Évolution du contrat

Le contrat actuel est volontairement réduit. La proposition d’évolution du code fournie avec cette documentation recommande d’ajouter l’annulation et l’état par requête, des options de génération structurées et un résultat de fin structuré, tout en conservant cette frontière indépendante du provider.