Changer de modèle

Cette page couvre deux besoins : remplacer le modèle en place, ou faire servir un modèle différent à l’autocomplétion et au chat.

Dans un déploiement Lemniscate, le modèle se choisit sur la passerelle, pas sur le poste : un endpoint de la passerelle désigne le moteur d’inférence et le modèle à poids ouverts qu’il sert. Le workstation.yaml du poste porte des pointeurs vers ces endpoints, et le choix des rôles (chat, autocomplétion). Le poste ne connaît que l’adresse de la passerelle : seul l’hôte de la passerelle joint le moteur d’inférence (livre blanc sécurité V3, sections 3.3 et 8.2).

Changer le modèle servi : côté passerelle

Deux cas, selon ce que vous voulez obtenir.

Le même endpoint doit servir un autre modèle, par exemple code-principal doit passer sur un modèle à poids ouverts plus récent : c’est un geste d’administration de la passerelle, décrit dans Déclarer un modèle servi par la passerelle. Le poste n’a rien à changer ; les appels suivants partent vers le nouveau modèle.

Vous voulez basculer sur un autre endpoint, par exemple de code-principal vers code-candidat : le poste change le segment d’endpoint de son apiBase :

models:
  - name: Code candidat (passerelle)
    provider: openai
    model: any
    apiBase: https://passerelle.interne:6001/code-candidat/v1
    apiKey: sk-lemniscate-<la-clé-du-développeur>

Trois champs n’ont pas le sens qu’ils paraissent avoir : provider est le dialecte parlé par l’IDE, ici celui de l’API compatible OpenAI ; model est ignoré (la passerelle le réécrit) ; apiKey est la clé du compte sur la passerelle. Le détail champ par champ, et les codes de refus à reconnaître, sont dans Router l’IDE vers la passerelle. Un endpoint mal orthographié répond 404 en listant les endpoints existants.

Affecter un modèle à un rôle

Le champ roles décide de ce à quoi sert chaque entrée de models, y compris quand l’entrée pointe la passerelle. Un modèle peut porter plusieurs rôles, et plusieurs modèles le même rôle ; le premier déclaré est alors retenu par défaut.

Rôle	Ce qu’il alimente
chat	la conversation
edit	les modifications demandées sur une sélection
apply	l’application d’un bloc de code proposé dans le chat
autocomplete	les suggestions en cours de frappe

models:
  - name: Chat (passerelle)
    provider: openai
    model: any
    apiBase: https://passerelle.interne:6001/code-principal/v1
    apiKey: sk-lemniscate-<clé>
    roles:
      - chat
      - edit
      - apply
  - name: Complétion (passerelle)
    provider: openai
    model: any
    apiBase: https://passerelle.interne:6001/completion-rapide/v1
    apiKey: sk-lemniscate-<clé>
    roles:
      - autocomplete

Le champ omis a un effet à connaître. Un modèle déclaré sans roles reçoit les rôles conversationnels (chat, edit, apply et summarize) et ceux-là seulement. Un roles explicite est la seule façon d’obtenir autocomplete ; voir régler l’autocomplétion.

Aucun rôle ne sert à indexer le code : Lemniscate ne construit aucun index, et l’agent explore le dépôt à la demande ; voir Ce qui n’existe pas.

Basculer d’un modèle à l’autre en cours de session

Les entrées de workstation.yaml sont toutes chargées en même temps : passer de l’une à l’autre ne demande pas de rééditer le fichier. Dans lemni, la commande /model ouvre la liste des modèles portant le rôle chat et bascule sur celui que vous choisissez. Dans l’extension, le sélecteur au-dessus de la zone de saisie du chat fait la même chose.

Quand le changement prend effet

Dans l’IDE, l’enregistrement du fichier déclenche un rechargement de la configuration : la nouvelle entrée apparaît sans redémarrer l’éditeur. lemni lit sa configuration au démarrage ; une modification faite pendant une session est prise à la session suivante. Un changement fait côté passerelle (le modèle derrière un endpoint) est immédiat pour tout le monde : le poste ne recharge rien.

Une entrée dont le chargement lève une erreur n’interrompt pas les autres : elle est écartée, et l’erreur est signalée avec son nom. Un provider inconnu produit une erreur de cette famille : le message nomme le modèle, cite le provider reçu et liste les identifiants acceptés. Un modèle qui n’apparaît nulle part est d’abord une faute de frappe dans provider.

Un modèle peut aussi manquer parce que la politique de votre organisation interdit son provider : une entrée dont le provider figure dans la liste interdite est écartée au chargement, et la page de configuration l’annonce (Model provider '…' is forbidden by your organization's policy). L’écran d’ajout de modèle ne propose pas ces valeurs et indique combien il en cache. La règle vient de l’administrateur, pas du poste ; le chemin attendu est un endpoint de la passerelle.

Où la configuration est cherchée

La configuration est cherchée dans ~/.lemniscate/workstation.yaml ; la variable LEMNISCATE_GLOBAL_DIR déplace le dossier entier. lemni accepte aussi un fichier explicite : lemni --config ./config-experimental.yaml "…". L’écriture ${{ secrets.NOM }} évite d’inscrire la clé du compte dans un fichier suivi par git : la valeur est cherchée dans l’environnement de la fenêtre qui a lancé le produit, puis dans ~/.lemniscate/.env, puis <projet>/.lemniscate/.env, puis <projet>/.env. Cet ordre est le même sur toutes les surfaces.

Pour la liste complète des clés acceptées par le fichier, voir Fichier de configuration.