Plugins

Libre WebUI utilise des plugins pour se connecter à des fournisseurs d’IA externes et à leurs capacités de modèles, aux côtés d’Ollama local.

Types de plugins

Type	Rôle
Discussion/complétion	Modèles de texte et de discussion provenant d’API de fournisseurs
Plongements	Plongements vectoriels pour la recherche documentaire et la mémoire
Génération d’images	Modèles d’images et serveurs dorsaux de type ComfyUI
Synthèse vocale	Fournisseurs de génération vocale
Reconnaissance vocale	Fournisseurs de transcription
Génération audio	Fournisseurs de sons et de génération audio
Génération vidéo	Fournisseurs de génération vidéo asynchrone

Les plugins peuvent exposer des correspondances statiques de modèles et, lorsque le fournisseur le permet, actualiser les modèles disponibles depuis ses API.

Familles de fournisseurs intégrées

Libre WebUI fournit des définitions pour des services courants :

• OpenAI et les API compatibles avec OpenAI
• Anthropic
• Google Gemini
• Groq
• Kimi Code de Moonshot AI
• Mistral
• OpenRouter
• Hugging Face
• GitHub Models
• MLX LM pour l’inférence locale sur Apple Silicon
• ComfyUI
• ElevenLabs

Les catalogues des fournisseurs changent fréquemment. Lorsqu’un plugin prend en charge la découverte en direct, l’interface doit être considérée comme la source de vérité.

Propriété et autorisation

Les définitions de plugins constituent une configuration partagée de l’instance. Toutes les routes /api/plugins exigent une authentification, et seuls les administrateurs peuvent importer, installer, mettre à jour ou supprimer une définition. L’activation est différente : chaque personne authentifiée peut activer ou désactiver un plugin partagé uniquement pour son propre compte. Cet état est stocké dans SQLite et subsiste après les redémarrages du serveur dorsal sans toucher les fournisseurs actifs d’une autre personne.

Lors d’une mise à niveau, l’ancienne liste globale d’activation .status.json est copiée une fois vers les comptes déjà existants, mais uniquement pour les définitions qui correspondent exactement aux ancres de confiance compilées de Libre WebUI. Les anciennes définitions personnalisées ou masquées restent en quarantaine et inactives. Les comptes créés après cette migration commencent sans plugin activé.

Une définition intégrée n’est fiable que si son contenu normalisé correspond à un hachage compilé dans le serveur dorsal. Les définitions accessibles en écriture sont approuvées dans SQLite d’après leur chemin source normalisé et le hachage complet de leur définition. L’installation, la mise à jour ou la réimportation par un administrateur enregistre cette approbation ; toute modification directe du fichier l’invalide. L’approbation et les mises à jour effacent l’activation de tous les comptes avant de remplacer le fichier, afin que chaque personne doive réactiver la définition vérifiée. Les définitions personnalisées antérieures à la mise à niveau doivent être réimportées par un administrateur avant de pouvoir apparaître dans les catalogues, découvrir des modèles, accepter des identifiants ou exécuter une capacité.

Les variables des plugins sont réparties selon leur finalité. Seuls les administrateurs peuvent stocker les variables reconnues de routage des connexions :

endpoint, base_url, api_path, models_endpoint, api_url, image_endpoint, embedding_endpoint, stt_endpoint, tts_endpoint, voice_clone_endpoint, api_mode, model et model_id. Une valeur config.endpoint_variable, config.models_endpoint_variable ou config.voice_clone_endpoint_variable déclarée par une capacité constitue également un routage de connexion, même si elle porte un autre nom.

Les personnes qui ne sont pas administratrices peuvent toujours enregistrer des réglages de génération tels que la température et les préférences de diffusion. Les anciennes lignes de routage qui leur appartiennent sont ignorées, ne sont pas renvoyées comme valeurs configurées et sont supprimées lors de la réinitialisation complète de leurs variables de plugin. Une promotion ultérieure ne peut ainsi pas réactiver silencieusement une route dormante.

Identifiants

Les identifiants peuvent provenir de variables d’environnement ou des paramètres de l’utilisateur.

Exemples d’environnement :

OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GROQ_API_KEY=gsk_...
GEMINI_API_KEY=...
MISTRAL_API_KEY=...
OPENROUTER_API_KEY=sk-or-...
KIMI_API_KEY=...
GITHUB_API_KEY=github_pat_...
ELEVENLABS_API_KEY=...

Dans un déploiement partagé, les identifiants propres à chaque utilisateur sont généralement préférables, car chacun contrôle sa facturation et ses limites auprès du fournisseur. Les clés d’environnement conviennent aux installations individuelles, aux démonstrations et aux déploiements gérés.

Une clé d’environnement ne sert de solution de repli que si la requête utilise la projection de routage et d’authentification d’une définition intégrée non masquée. Une définition importée, une définition accessible en écriture qui masque un identifiant intégré ou le remplacement de routage d’un administrateur exige un identifiant enregistré par le même compte. Avant d’autoriser la clé d’environnement, Libre WebUI compare le point de terminaison racine, les champs d’authentification, les points de terminaison et sélecteurs des capacités ainsi que les définitions et valeurs par défaut des variables de routage reconnues. Le hachage compilé du manifeste reste déterminant même si les anciens répertoires de plugins et les répertoires intégrés partagent un chemin, comme dans l’agencement standard d’un conteneur ; un manifeste de paquet remplacé ne peut pas établir sa propre confiance.

Cette règle s’applique à la découverte, à Chat, à Work, aux contrôles de disponibilité et aux catalogues de capacités. Elle empêche qu’un point de terminaison personnalisé ou un manifeste personnalisé antérieur à la mise à niveau reçoive un secret géré par l’opérateur.

Les identifiants stockés par l’utilisateur sont liés à la source de la définition effective, à son hachage complet, au contrat d’authentification, aux points de terminaison et sélecteurs des capacités ainsi qu’aux valeurs de routage effectives au moment de leur enregistrement. Après une modification de la route ou de la définition, l’ancien identifiant reste indisponible jusqu’à ce que l’utilisateur vérifie la nouvelle destination et le réenregistre. Les anciens identifiants sans liaison ne sont acceptés que sur une route intégrée ancrée exacte ; leur première utilisation réussie écrit la liaison avant de renvoyer la clé déchiffrée.

Fournisseurs compatibles avec OpenAI

De nombreux fournisseurs proposent une API compatible avec OpenAI. Un plugin peut définir :

• l’URL complète du point de terminaison de l’API ;
• la variable d’environnement de la clé d’API ;
• le comportement du point de terminaison de discussion ;
• la prise en charge des plongements ;
• le comportement de découverte des modèles ;
• une correspondance facultative de modèles comme solution de repli.

Si un fournisseur ne prend pas en charge la découverte en direct, Libre WebUI utilise la correspondance de modèles configurée. Un plugin JSON importé configure des fournisseurs qui parlent déjà l’un des formats filaires pris en charge par Libre WebUI : OpenAI Chat Completions, OpenAI Responses, Anthropic Messages ou Gemini. Le JSON seul ne traduit pas un protocole propriétaire arbitraire ; un fournisseur dont la forme des requêtes, de la diffusion, des appels d’outils ou des réponses est différente exige un petit adaptateur du serveur dorsal.

Génération d’images OpenAI

Le fournisseur OpenAI intégré expose l’API Image à l’adresse https://api.openai.com/v1/images/generations. Le modèle actuel est gpt-image-2. Le catalogue conserve également les identifiants obsolètes gpt-image-1.5, gpt-image-1 et gpt-image-1-mini pour les déploiements compatibles existants ; les nouvelles configurations doivent sélectionner gpt-image-2.

La génération d’images utilise le même identifiant OpenAI effectif que Chat : la clé enregistrée de l’utilisateur actuel ou la clé d’environnement du fournisseur intégré fiable. Un remplacement facultatif image_endpoint distinct empêche qu’un point de terminaison Chat personnalisé reçoive accidentellement les requêtes d’images. Laissez image_endpoint vide pour hériter du point de terminaison de l’API Image intégrée.

Les sélections d’images sont qualifiées par fournisseur. Si deux plugins d’images exposent le même identifiant de modèle, Libre WebUI envoie la requête uniquement au fournisseur sélectionné dans le panneau d’images. Les réponses GPT Image utilisent des données d’image en base64 ; Libre WebUI les convertit en image dans l’application et les enregistre dans la galerie de l’utilisateur actuel. Les routes de l’API Image exigent une authentification, et les requêtes de génération directes doivent comporter pluginId et model. Elles peuvent définir n sur un entier JSON compris entre 1 et 10 ; les chaînes numériques et valeurs fractionnaires sont refusées avant d’atteindre le fournisseur.

Modes Chat Completions et API Responses

Les plugins de complétion compatibles avec OpenAI peuvent utiliser la sémantique de requête chat_completions ou responses. Le plugin OpenAI intégré propose ce choix dans Paramètres → Plugins.

Les paramètres de connexion sont résolus dans cet ordre :

1. Un remplacement complet endpoint, s’il est configuré.
2. base_url avec un api_path facultatif.
3. L’ancien endpoint du plugin.

Une valeur de point de terminaison exactement identique à celle du manifeste est considérée comme valeur par défaut, et non comme remplacement. Les anciennes valeurs par défaut stockées ne masquent ainsi pas une nouvelle URL de base après une mise à niveau. Un point de terminaison complet réellement personnalisé reste prioritaire.

Le chemin par défaut est /chat/completions en mode Chat Completions et /responses en mode Responses. base_url doit être la racine de l’API, par exemple https://api.example.com/v1 ; utilisez api_path lorsqu’un fournisseur compatible expose l’opération sous un autre chemin relatif. Un point de terminaison complet doit inclure le chemin entier de l’opération et l’emporte sur les deux champs. Un suffixe connu /chat/completions, /completions ou /responses détermine la sémantique des requêtes ; les chemins personnalisés conservent le mode api_mode sélectionné.

Le JSON d’un plugin importé peut fournir les mêmes valeurs par défaut :

{
  "endpoint": "https://api.example.com/v1/chat/completions",
  "api_mode": "responses",
  "base_url": "https://api.example.com/v1",
  "api_path": "/responses"
}

Les requêtes Responses utilisent input, max_output_tokens, des outils de fonctions aplatis, store: false et demandent le contenu de raisonnement chiffré afin de permettre une continuation sans état. Les sorties Responses terminées et diffusées sont normalisées vers les formats d’événements Chat et Work de Libre WebUI. L’état de relecture n’est conservé que si le tableau Item complet et ordonné contient au plus 64 Items et 90 KB ; les Items restent exacts et leurs champs ne sont jamais tronqués. Les Items rejouables doivent avoir des identifiants et types uniques et non vides, et les structures de messages, raisonnements et appels de fonctions sont validées avant l’émission de tout appel d’outil. Un état Chat trop volumineux revient à l’historique visible normalisé. Chat supprime aussi les Items d’appels de fonctions bruts, car il ne conserve pas les sorties d’outils correspondantes. Les réponses Work contenant des outils sans état de relecture borné et exact sont refusées avant tout effet d’outil.

Le stockage Chat fondé sur SQLite chiffre avec le message l’état du fournisseur conservé ; Work stocke l’état réservé aux outils dans des lignes de contexte masquées que les API de messages ne renvoient pas. Une portée hachée lie la relecture au même fournisseur, modèle, mode Responses, point de terminaison final configuré et empreinte opaque unidirectionnelle de l’identifiant sélectionné. Lorsque cette portée change, y compris après le renouvellement de la clé d’API, Libre WebUI revient à l’historique normalisé des messages au lieu d’envoyer des Items propres au fournisseur au-delà d’une frontière d’authentification. Une exécution Work active crée également une empreinte de son routage et de son identifiant, puis les valide de nouveau juste avant chaque étape du fournisseur ; modifier le mode, le point de terminaison ou la clé d’API arrête l’exécution avant qu’une autre requête ne reçoive l’ancien état d’outil.

Un état comportant des outils doit respecter à la fois la limite de relecture et celle de l’enveloppe complète de métadonnées persistantes de 100 KB avant qu’un outil Work produise un effet. Si un lot Work persistant a été interrompu, chaque résultat d’outil manquant est restauré avec son identifiant d’appel exact et un avertissement indiquant que le résultat est inconnu, afin que le fournisseur inspecte l’espace de travail au lieu de répéter aveuglément un effet éventuel. Un résultat Responses incomplet n’est pas considéré comme un tour Chat ou Work réussi ; son incomplete_details.reason est conservé et présenté à l’appelant.

La découverte des modèles dérive /models du chemin de l’opération. Par exemple, https://api.example.com/v1/responses utilise https://api.example.com/v1/models. Les fournisseurs dépourvus de point de terminaison compatible peuvent toujours utiliser un model_map manuel. La découverte est limitée aux variables et identifiants de l’utilisateur actuel. Les résultats persistent par utilisateur et ne sont pas écrits dans le manifeste partagé. La découverte s’exécute après l’activation, une actualisation explicite, un changement de clé d’API, une modification des variables de connexion ou leur réinitialisation ; l’enregistrement de variables de génération sans rapport n’entraîne aucune requête réseau.

La découverte s’exécute aussi automatiquement. La lecture de la liste des plugins redécouvre tout fournisseur actif de complétion dont le catalogue manque ou date de plus de PLUGIN_MODEL_DISCOVERY_TTL_MS. Recharger l’application reflète donc les modèles actuels du fournisseur plutôt que ceux capturés à l’activation. Un délai propre au fournisseur évite d’interroger un fournisseur inaccessible à chaque requête, et une échéance empêche un fournisseur lent de retarder la réponse ; une actualisation qui la dépasse est servie à la requête suivante. L’URL finale dérivée est contrôlée avant la lecture des identifiants ou la création d’un en-tête d’autorisation, y compris si elle provient d’un manifeste importé. La découverte et les requêtes de capacités ne suivent pas les redirections HTTP. Configurez directement le point de terminaison final de Chat, Work, la liste des modèles, les images, plongements, transcriptions, paroles, clonages de voix, sons ou vidéos ; les identifiants ne peuvent ainsi pas être transférés d’une URL validée vers une destination de redirection non validée.

Les points de terminaison des fournisseurs peuvent utiliser HTTP ou HTTPS. HTTP envoie sans chiffrement de transport les clés d’API, prompts, résultats d’outils et contenus générés ; ne l’utilisez que pour une passerelle auto-hébergée sur un réseau fiable et préférez HTTPS dès que TLS est disponible. Les requêtes proviennent du serveur dorsal. Dans un conteneur, utilisez donc une URL de service comme http://ai-gateway:8080/v1, tandis que localhost désigne le conteneur Libre WebUI lui-même. Les routes des capacités de plugins, y compris la génération d’images, résolvent les variables de point de terminaison et les identifiants pour le compte authentifié qui effectue la requête. Libre WebUI ne possède aucun mode mono-utilisateur non authentifié.

Points de terminaison propres aux capacités

Les remplacements du point de terminaison Chat sont isolés des capacités d’images, de plongements, de transcription, de synthèse vocale, d’audio et de vidéo. Les plugins à capacités multiples peuvent exposer image_endpoint, embedding_endpoint, stt_endpoint, tts_endpoint ou une autre variable nommée dans config.endpoint_variable. Les routes de clonage vocal peuvent de même nommer config.voice_clone_endpoint_variable. Laisser ces champs vides utilise le point de terminaison déclaré par le plugin ; un endpoint Chat générique ne sert jamais de remplacement pour une capacité.

Le plugin GitHub Models intégré hérite de son point de terminaison actuel models.github.ai/inference/chat/completions lorsque son remplacement facultatif est vide. Le plugin Hugging Face utilise des routes et charges utiles hf-inference/models/{model} propres aux tâches pour les plongements, les images et la synthèse vocale, au lieu d’envoyer ces requêtes à son point de terminaison Chat.

Remplacements des points de terminaison

La variable endpoint est l’URL complète de la requête, chemin de l’opération compris. Par exemple, un plugin de discussion compatible avec OpenAI utilise normalement une URL comme https://provider.example/v1/chat/completions, et non seulement https://provider.example. Les anciennes configurations importées peuvent appeler cette variable api_url ; Libre WebUI accepte cet alias, mais une valeur endpoint non vide reste prioritaire si les deux sont présentes.

Les URL absolues HTTP et HTTPS sont acceptées ; les autres protocoles sont refusés. HTTP est réservé aux passerelles auto-hébergées sur des réseaux fiables, car il envoie les identifiants et le contenu des requêtes sans chiffrement de transport. Préférez HTTPS pour toute route quittant la frontière d’un déploiement privé. Un remplacement vide utilise le point de terminaison complet de la définition ; un remplacement explicite invalide est refusé au lieu d’être silencieusement acheminé vers cette valeur par défaut.

Les requêtes aux fournisseurs ne suivent aucune redirection. Configurez directement l’URL finale validée de l’opération ; une redirection est signalée comme erreur du fournisseur au lieu de transférer les identifiants ou le contenu de la requête à un autre saut.

Rappelez-vous que les requêtes proviennent du serveur dorsal de Libre WebUI. Dans un conteneur, localhost désigne le conteneur lui-même, et non l’hôte ou un autre service. Utilisez le nom de service de la passerelle ou un nom accessible depuis l’hôte comme host.docker.internal si l’environnement d’exécution de conteneurs le fournit.

Découverte des modèles

Paramètres → Plugins comporte un espace Connexions aux fournisseurs consacré à ce parcours. Recherchez un fournisseur dans le panneau gauche, sélectionnez-le, puis utilisez le panneau droit pour vérifier son état actif et son catalogue effectif. La configuration reste réduite tant que Configurer n’est pas sélectionné, ce qui masque par défaut les points de terminaison, identifiants et réglages avancés de génération.

Pour les fournisseurs de discussion et de complétion, Actualiser les modèles lance la découverte du fournisseur sélectionné, puis recharge le catalogue des plugins et la liste des modèles de Chat. Le catalogue est en lecture seule : ses lignes proviennent des identifiants découverts de l’utilisateur actuel et des correspondances de modèles des capacités de la définition. Les libellés des capacités indiquent quelle route du plugin répertorie un modèle ; ce ne sont pas des contrôles d’intégrité. Ajoutez les identifiants de repli ou gérés manuellement au model_map JSON du plugin, et non en modifiant une ligne découverte.

Lorsqu’un plugin est activé, Libre WebUI tente la découverte avec le point de terminaison et l’identifiant effectifs du compte. Une route personnalisée par un administrateur exige un identifiant stocké par ce même compte ; la valeur d’environnement ne sert de repli qu’avec la route du manifeste fiable. Pour les API compatibles, Libre WebUI dérive l’URL de la liste des modèles du point de terminaison complet :

• une URL se terminant par /models est utilisée telle quelle ;
• les suffixes d’opérations connus, comme /chat/completions, /completions, /responses, /embeddings ou /messages, sont remplacés par /models ;
• sinon, /models est ajouté au chemin.

Les plugins incompatibles avec l’URL dérivée peuvent exposer models_endpoint comme URL complète explicite de la liste. Cette valeur est prioritaire, suit la même politique de sortie et est demandée sans suivre les redirections. Enregistrer ou réinitialiser endpoint, api_url, models_endpoint, base_url, api_path ou api_mode efface puis actualise le catalogue découvert de l’utilisateur avant le rechargement de l’interface.

Toutes les routes personnalisées sont résolues et validées avant la sélection des identifiants. La politique ne doit pas revenir à une clé d’environnement du serveur pour une route personnalisée stockée ; configurez plutôt une clé propre à l’utilisateur. La clé d’environnement est réservée au point de terminaison fourni par la définition fiable.

La découverte attend une réponse compatible avec OpenAI comportant les identifiants dans un tableau data. L’activation attend cette tentative avant de répondre afin que la première actualisation puisse inclure le catalogue découvert. Les résultats réussis sont stockés par utilisateur et superposés à sa vue ; Libre WebUI ne réécrit pas le JSON partagé et n’expose pas les identifiants découverts d’une personne à une autre. Si le fournisseur n’a aucun point de terminaison compatible, est inaccessible ou renvoie une autre forme, une activation ordinaire conserve le précédent résultat de découverte. Une modification volontaire d’un champ de connexion efface d’abord le catalogue obsolète et utilise donc le model_map de repli si la nouvelle route ne peut pas être découverte.

Enregistrer ou réinitialiser le routage de connexion efface le précédent catalogue de ce compte avant la prochaine découverte ; les modèles appris depuis une destination ne restent donc pas sélectionnables après un changement de route.

L’état des plugins, la disponibilité de Work, les catalogues de modèles et les routes des capacités utilisent le même contexte utilisateur et la même frontière d’identifiants. Par exemple, la disponibilité des modèles d’images, les variables de point de terminaison et les identifiants sont résolus pour la personne qui effectue la requête.

Sélection exacte du fournisseur dans Chat

Les identifiants de modèles ne sont pas uniques globalement. Un modèle Ollama et plusieurs plugins actifs peuvent tous exposer example-model. Chat stocke donc l’identifiant brut avec l’identité facultative du fournisseur :

• providerType: "ollama" désigne la route Ollama locale ou configurée ;
• providerType: "plugin" avec providerId désigne un plugin précis.

Les valeurs qualifiées par fournisseur et encodées dans l’URL servent uniquement de clés sans collision dans les sélecteurs. Les requêtes continuent d’envoyer l’identifiant brut. Les noms Ollama/plugin ou plugin/plugin en double restent des choix distincts, et rouvrir une discussion restaure exactement le choix enregistré.

Une identité explicite échoue de manière sécurisée. Si le plugin sélectionné est désactivé, supprimé ou n’annonce plus le modèle, Libre WebUI conserve la sélection enregistrée comme indisponible et ne passe pas silencieusement à un autre fournisseur portant le même nom. Réactivez le fournisseur ou choisissez explicitement un autre modèle avant de relancer une génération.

Les sessions et préférences créées avant le stockage de l’identité peuvent avoir providerType et providerId non définis ou null. Par compatibilité, ces enregistrements conservent leur ancien routage d’après le nom seul, car il est impossible de reconstruire le fournisseur d’origine de façon fiable. Le sélecteur les indique comme « fournisseur non enregistré » plutôt que de deviner Ollama ou un plugin. Choisir une entrée précise enregistre le fournisseur exact pour les requêtes suivantes. Les nouvelles sélections de personas conservent leur identité d’interface persona:<id> et sont enregistrées comme reposant sur Ollama.

Paramètres des fournisseurs et héritage

Ouvrez Paramètres → Plugins et choisissez Configurer pour un fournisseur. Les panneaux sont fermés par défaut. Les administrateurs gèrent les définitions partagées et les valeurs de routage. Les autres personnes authentifiées peuvent activer les fournisseurs, enregistrer leurs propres clés d’API et modifier leurs réglages de génération, mais l’interface ne leur propose ni importation, installation, exportation, suppression ni réglage du routage.

Pour les administrateurs, les remplacements de connexion apparaissent en premier. L’échantillonnage et les autres commandes spécialisées restent sous Paramètres avancés, également fermé par défaut. Les valeurs de connexion et de génération héritées s’affichent comme des champs vides avec une indication de la valeur par défaut. Libre WebUI ne copie pas les valeurs du manifeste dans les paramètres d’un compte simplement parce que le panneau a été ouvert.

L’enregistrement n’envoie que les champs modifiés pendant la session d’édition actuelle. Effacer une valeur non sensible enregistrée retire le remplacement du compte et restaure la valeur par défaut ; un champ sensible masqué vide reste inchangé. Rétablir les valeurs par défaut supprime tous les remplacements que le compte est autorisé à gérer. Si l’enregistrement ou la réinitialisation échoue, l’éditeur conserve les valeurs non enregistrées afin que l’utilisateur puisse réessayer.

Cette distinction est importante pour les points de terminaison personnalisés : un administrateur laisse le champ vide pour hériter de l’URL intégrée ou saisit une URL compatible complète afin de la remplacer pour sa connexion.

Plugins dans Work

Work peut utiliser les plugins completion et chat actifs, en plus d’Ollama et d’Ollama Cloud. Une exécution Work reposant sur un plugin n’est acceptée que si :

• le plugin est actif ;
• son modèle figure dans le catalogue découvert de l’utilisateur actuel ou dans la correspondance configurée du plugin ;
• des identifiants sont disponibles pour l’administrateur actuel.

Work conserve le type de fournisseur et l’identifiant du plugin avec la tâche et chaque exécution. Le routage repose donc sur le fournisseur exact enregistré, pas seulement sur le nom du modèle. Activer un plugin dont le modèle porte le même nom qu’un modèle Ollama ne peut pas rediriger silencieusement une tâche existante.

Work adapte les appels d’outils aux formats natifs de requêtes/réponses compatibles avec OpenAI, Anthropic et Gemini. Le modèle sélectionné doit prendre en charge les appels d’outils, même si le fournisseur propose des complétions de discussion ordinaires. Si le fournisseur refuse les outils ou renvoie une réponse incompatible, l’exécution échoue sans revenir à un autre fournisseur.

Une exécution Work distante peut effectuer plusieurs requêtes au fournisseur. Celui-ci reçoit le prompt système Work, le contexte de la conversation, les définitions des outils et les résultats demandés. Ces résultats peuvent contenir des fichiers sources, des listes de répertoires ou des sorties de commandes. Libre WebUI affiche dans Work une information sur le fournisseur distant, propre à chaque utilisateur et révocable ; les opérateurs doivent néanmoins vérifier ses tarifs et politiques de conservation et d’entraînement avant d’activer le service pour des projets sensibles.

Plongements

Les plugins prenant en charge les plongements peuvent apparaître dans les paramètres de plongement des documents. Libre WebUI détecte aussi les modèles Ollama probablement adaptés, comme nomic-embed-text, bge, e5, gte et les noms similaires.

Si aucun modèle de plongement n’est découvert, l’interface utilise nomic-embed-text comme candidat local par défaut.

Notes sur le développement des plugins

Une définition doit décrire clairement sa capacité sans prétendre que le fournisseur prend en charge des fonctionnalités inexistantes. Conservez des correspondances de modèles assez petites pour rester utiles en repli et préférez la découverte lorsque l’API de liste du fournisseur est rapide et fiable.

Lors de l’ajout d’un fournisseur :

1. Ajoutez la définition du plugin.
2. Définissez la clé d’identification ou les champs d’identifiants utilisateur.
3. Implémentez la découverte si le fournisseur propose une liste de modèles.
4. Ajoutez la transformation des requêtes pour la discussion, les plongements, les images, TTS ou STT.
5. Testez les états sans clé, avec une mauvaise clé et avec une erreur du fournisseur.

Documentation connexe

• Variables d’environnement
• Utiliser les modèles
• Work : espaces de travail isolés
• Kimi Code
• MLX LM sur Apple Silicon