Fournisseurs de modèles : Vue d’ensemble

Les fournisseurs de modèles constituent l’abstraction de ZeroClaw pour tout point de terminaison LLM que l’agent peut appeler. Chaque requête de complétion de chat passe par une implémentation du trait ModelProvider (zeroclaw-api::ModelProvider), que la cible soit une API distante, un serveur d’inférence auto-hébergé ou un modèle Ollama local.

Un agent atteint un fournisseur en le référençant ; consultez Agents pour comprendre comment ce câblage s’articule.

Pourquoi fournisseur de « modèles » ? Nous utilisons l’expression « fournisseur de modèles » de manière cohérente, il existe également des fournisseurs de TTS et des fournisseurs de transcription, et conserver un qualificatif spécifique évite toute ambiguïté.

Forme de configuration

Les fournisseurs sont typés par famille, adressés sous la forme providers.models.<type>.<alias>. <type> est un emplacement de famille canonique (consultez le Catalogue pour la liste de tous les emplacements). Il existe un seul emplacement par éditeur, sans synonymes : azure_openai, azure-openai et claude (pour Anthropic) ne sont pas acceptés.

<alias> est le nom d’instance attribué par votre opérateur, et vous pouvez définir autant d’alias par type que vous le souhaitez. Exécutez plusieurs profils de la même famille de fournisseurs côte à côte : même type, des alias différents, chacun avec sa propre clé, son propre modèle et ses propres paramètres. Par exemple, deux comptes Anthropic en tant que anthropic.personal et anthropic.work (chacun avec son propre api_key et model), où un agent en choisit un avec model_provider = "anthropic.personal" (ou "anthropic.work"). Ajoutez et modifiez ces éléments via les interfaces ci-dessous, et non manuellement :

Voir Configuration pour le schéma complet et Catalog pour un exemple détaillé par famille.

Répartition par agent : il n’existe pas de valeurs par défaut globales

Une entrée de fournisseur ne fait rien à elle seule. Pour l’utiliser, un agent y fait référence via model_provider (avec un risk_profile et un runtime_profile optionnel). risk_profile et runtime_profile font référence à des tables d’alias indépendantes, donc leurs noms n’ont pas besoin de correspondre. Config::validate() échoue de manière explicite au démarrage si une référence ne peut pas être résolue. Chaque site d’appel choisit un alias configuré ou s’en passe ; il n’existe aucun réglage global de « fournisseur par défaut » ou de « modèle par défaut ».

Pour les déploiements multi-agents, attribuez à chaque agent son propre model_provider. Les canaux qui ingèrent des messages se lient à un seul agent à la fois via la liste channels de l’agent ; consultez Channels pour une vue d’ensemble complète.

Voix (TTS) et transcription par agent

La synthèse vocale et la reconnaissance vocale suivent le même schéma : une entrée de fournisseur à famille typée, puis une référence par agent. Il n’existe pas de champs de sélection globaux pour la TTS ou la transcription. Chaque agent qui souhaite utiliser la voix définit son propre routage.

Et maintenant ?

• Configuration : le schéma complet [providers.*], la configuration typée Azure, les variantes régionales et OAuth
• Streaming : comment circulent les jetons, les appels d’outils et les deltas de raisonnement
• Routage : répartition multi-agents et OpenRouter comme couche de routage
• Catalogue des fournisseurs : chaque famille prise en charge avec un exemple TOML détaillé
• Fournisseurs personnalisés : faire pointer l’emplacement custom vers un point de terminaison compatible OpenAI, ou implémenter le trait ModelProvider