Aller au contenu

Modèles, clés et limites

Chaque bubble possède son propre modèle. Il démarre sur le modèle par défaut défini dans la page Modèles, et vous pouvez le modifier dans l’inspecteur du bubble : fournisseur, modèle, clé et format de réponse. Les modèles et les valeurs par défaut par rôle pour un projet se trouvent également sur la page Modèles.

OpenRouter et NVIDIA acceptent n’importe quel nom de modèle saisi, ce qui permet d’utiliser un modèle qui ne figure pas encore dans la liste.

Pour ajouter des clés et savoir où elles sont stockées, consultez Ajouter une clé de fournisseur.

Un pool est une liste ordonnée de huit modèles au maximum (et de huit clés au maximum) qu’un bubble utilise comme un seul. Lorsque le modèle utilisé subit une limite de taux, est hors service ou continue d’envoyer des réponses illisibles, le pool passe à l’entrée suivante.

  • Batch (par défaut), cycle et proportional déterminent la sélection des entrées.
  • Une entrée en échec patiente dix minutes avant une nouvelle tentative.
  • Une passe attend au total huit minutes au maximum qu’une entrée se libère, et vous prévient en cas d’attente prolongée.

Sur les forfaits gratuits des fournisseurs, les pools sont très utiles. Placez deux ou trois modèles gratuits dans un pool, et un bubble continue de fonctionner lorsqu’un d’entre eux n’a plus de requêtes. Démarrer gratuitement en crée un pour vous : consultez Première exécution sur des modèles gratuits.

Perfica suit les requêtes par minute et par jour pour chaque modèle et chaque clé, et espace les appels pour éviter qu’un bubble ne déclenche la limite du fournisseur.

Il calcule chaque limite dans cet ordre :

  1. ce que vous avez saisi sur la page Limites,
  2. ce que les refus de limites de taux du fournisseur lui ont appris,
  3. les limites publiées fournies par défaut (par exemple, les modèles gratuits d’OpenRouter à 20 par minute et 50 par jour, et le forfait gratuit de Google).

Les modèles locaux (Ollama, LM Studio) n’ont pas de limite.

  • Un pool ignore une entrée dont le quota est épuisé et passe à la suivante.
  • Lorsqu’il n’y a plus rien à interroger, le loop se met en pause sur le même bubble, avec une notification indiquant la prochaine tentative, puis reprend de lui-même : à l’heure indiquée par le fournisseur ou par la réinitialisation journalière, ou sinon après 5, 10, 20 et 40 minutes, puis toutes les heures, tant que le tableau est laissé sans surveillance. Pause, Stop ou Lecture met fin à l’attente ; la notification propose également Ajouter une clé payante.
  • Rien de tout cela ne consomme les plafonds d’erreur du loop, sauf si le loop a activé Continuer en cas d’erreur, et une nouvelle tentative refusée avant qu’aucun modèle n’ait répondu ne compte pas comme une passe du loop.

Les connexions interrompues et les erreurs de serveur font l’objet de trois nouvelles tentatives, sur environ sept secondes. Si le fournisseur est toujours hors service, le loop s’arrête sur le même bubble avec une notification, le fournisseur du modèle a cessé de répondre, et attend la lecture. Aucune erreur n’est comptabilisée.

L’onglet Utilisation affiche les jetons et le coût de ce tableau au fil du temps, Par modèle et Par rôle, à partir des comptages de jetons du fournisseur. Un modèle non couvert par le tableau des tarifs affiche n/a, jamais 0 $, et les totaux portent la mention +. Les modèles Ollama locaux sont comptés comme gratuits.

Un bubble peut afficher des images : collées dans un message Manager ou une carte de tâche, ou lues depuis le projet. Si son modèle ne peut pas voir, le modèle de vision du tableau décrit l’image à la place. Définissez-le sur la page Modèles sous Modèles auxiliaires. Sans cela, un modèle aveugle s’arrête avec une notification plutôt que de deviner le contenu de l’image.