Cycle de vie du provider llama.cpp

Statut documentaire : architecture — voir Maturité et preuves.

Le provider llama.cpp sépare la résidence du modèle/de la session de la durée de vie de l’ordonnanceur de requêtes.

Modèle d’état

configuré, arrêté, modèle non chargé
          |
        Start
          v
démarré, modèle chargé, ordonnanceur actif
          |
        Stop
          v
arrêté, modèle toujours résident
          |
   +------+------+
   |             |
 Start       UnloadModel
   |             |
   v             v
réutilise    arrêté, modèle déchargé

Au premier Start, le provider charge le modèle configuré lorsqu’aucune session résidente n’existe. Les cycles Stop/Start suivants réutilisent cette session et évitent ainsi un rechargement inutile du modèle lors d’un arrêt temporaire du service.

Une modification de configuration du modèle pendant l’arrêt invalide la session résidente et la décharge avant d’accepter la nouvelle configuration.

File et annulation

Les requêtes soumises entrent dans une file synchronisée. L’arrêt du service :

1. demande l’annulation de la requête en cours ;
2. ferme la file ;
3. termine les requêtes en attente comme annulées au lieu de les perdre silencieusement ;
4. attend la fin du worker d’ordonnancement ;
5. conserve le modèle/la session en mémoire.

L’opération d’annulation publique actuelle cible la requête courante. Une annulation par identifiant de requête est une évolution recommandée du contrat.

Affinité de thread du backend

L’implémentation macOS/FPC + Metal actuelle exécute volontairement la génération llama.cpp sur le même thread de contrôle que celui qui possède/a chargé la session, tandis qu’un worker gère l’ordonnancement de la file. Il s’agit d’une contrainte d’implémentation, pas d’une sémantique LLM destinée aux applications.

Les bindings publics ne doivent donc pas promettre un thread particulier pour les callbacks ou l’exécution native. Une évolution devrait encapsuler l’affinité derrière un dispatcher d’exécution du backend et vérifier si un thread propriétaire dédié peut remplacer la synchronisation sur le thread principal pour chaque accélérateur supporté.

Diagnostics

L’implémentation expose actuellement l’état démarré, l’état de chargement du modèle, le nombre de requêtes en attente et les compteurs de chargement/déchargement. Ces compteurs sont utiles pour les tests de cycle de vie mais ont, à terme, davantage leur place dans une surface de diagnostic que dans le contrat minimal multi-provider.