Endpoints compatibles OpenAI

Ajoutez Paramètres → Plateforme → Extensions → Ajouter une extension → Fournisseurs d'IA → OpenAI-compatible server pour connecter tout serveur qui implémente l'API OpenAI /v1 — vLLM, Ollama, LM Studio, LocalAI, Groq, Together AI, et bien d'autres.

C'est la voie recommandée pour :

• Les serveurs d'inférence auto-hébergés (Ollama, vLLM, LM Studio) dans des déploiements entièrement locaux ou isolés (air-gapped).
• Les services hébergés tiers compatibles OpenAI (Groq, Together AI, Perplexity, etc.) qui ne figurent pas parmi les extensions nommées.
• Les endpoints personnalisés ou internes qui implémentent le contrat OpenAI /v1.

Configurer

Accédez à Paramètres → Plateforme → Extensions → Ajouter une extension, trouvez OpenAI-compatible server sous Fournisseurs d'IA (ou recherchez-le), puis cliquez sur Connecter. L'étape de connexion demande :

1. Capacités — cochez les capacités que fournit cet endpoint (LLM, Embeddings, STT, TTS, Image, Moderation). Une sonde GET /v1/models, au mieux, pré-remplit les modèles disponibles ; si votre serveur n'implémente pas /models, vous pouvez saisir les identifiants de modèles manuellement.
2. Configurer — définissez l'URL de base et l'authentification facultative.
3. Vérifier — l'assistant teste la joignabilité avant l'enregistrement.

Champs de configuration

Couverture des capacités

Endpoints multiples

Si vous avez besoin de serveurs distincts pour différentes capacités (par exemple un service dédié de transcription audio aux côtés d'un serveur de chat), ajoutez une deuxième connexion OpenAI Compatible. La plateforme prend en charge plusieurs connexions nommées par fournisseur et vous permet de choisir la connexion qui sert chaque capacité.

Configurations auto-hébergées courantes

Ollama (entièrement local / air-gapped)

Ollama expose GET /v1/models, si bien que l'assistant peut découvrir automatiquement les modèles disponibles.

vLLM (inférence GPU auto-hébergée)

Groq / Together AI / fournisseurs hébergés

Dépannage

409 CAPABILITY_NOT_CONFIGURED, ou 412 depuis une fonctionnalité Scrydon

L'endpoint n'est pas défini comme valeur par défaut de l'organisation pour cette capacité, ou aucune connexion n'est activée pour elle. Accédez à Paramètres → Plateforme → Extensions, ouvrez la connexion OpenAI Compatible et assurez-vous que le produit de capacité concerné est activé et défini par défaut.

L'API Platform répond 409 CAPABILITY_NOT_CONFIGURED. Les fonctionnalités Scrydon qui l'appellent pour vous répondent 412 à la place : la création d'une base de connaissances ou le téléversement vers celle-ci renvoie code: "EMBEDDING_NOT_CONFIGURED", et la génération d'images renvoie un message qui nomme le fournisseur.

Modèle absent de la liste après l'ajout de la connexion

Si votre serveur n'implémente pas GET /v1/models, la sonde de découverte automatique ne renvoie rien. Vous pouvez saisir les identifiants de modèles manuellement dans les paramètres de capacité une fois la connexion enregistrée.

Un motif s'affiche à côté de la connexion au lieu d'une liste de modèles

Le serveur n'a jamais répondu à la sonde : l'URL de base ne se résout pas, le port refuse les connexions, ou l'endpoint présente un certificat TLS que la plateforme ne peut pas vérifier (un certificat auto-signé ou émis par une AC interne en est la cause habituelle). Chaque appel de modèle sur cette connexion échoue de la même manière : la plateforme indique donc la cause plutôt qu'une liste vide. Le message nomme l'endpoint et le texte propre à la couche de transport. Corrigez l'adresse, ou placez un certificat émis par une autorité de confiance devant le serveur, puis sélectionnez Refresh models. Un problème de certificat n'est pas réessayé de lui-même ; un appel de modèle sur la connexion renvoie CAPABILITY_NOT_CONFIGURED tant que l'endpoint n'est pas corrigé.

Function tools with reasoning_effort are not supported … use /v1/responses

Le champ OpenAI API de la connexion est fixé sur chat-completions. Videz-le (auto), ou définissez responses pour cet endpoint.

La vérification de la connexion échoue

Vérifiez que :

• L'URL de base est joignable depuis le réseau de la plateforme (pas localhost, sauf si le serveur et la plateforme s'exécutent sur le même hôte).
• La clé d'API est correcte (si l'authentification est activée).
• Les certificats TLS auto-signés sont approuvés par le magasin de confiance de la plateforme (configuration au niveau de l'opérateur).

API OpenAI

Les serveurs compatibles OpenAI implémentent Chat Completions (/chat/completions), la Responses API (/responses), ou les deux, et certains modèles ne fonctionnent pleinement qu'avec l'une d'elles. Par exemple, gpt-6.1-sol refuse les outils de fonction avec raisonnement sur Chat Completions, et certaines passerelles ne servent un déploiement Claude que via Responses. Laissez OpenAI API vide et Scrydon détermine le bon choix pour chaque modèle :

1. Chat Completions est essayé en premier.
2. Si l'endpoint répond que la route n'existe pas (404 ou 405), ou rejette la requête en désignant la Responses API comme solution, la même requête est envoyée une fois à /responses. L'inverse s'applique également.
3. L'API qui a répondu est mémorisée pour cet endpoint et ce modèle, de sorte que la requête supplémentaire n'a lieu qu'une fois, et non à chaque appel.

Ne définissez chat-completions ou responses que pour fixer un serveur qui ne prend en charge que l'une d'elles. Une valeur fixée n'est jamais modifiée : un refus de l'API fixée vous est donc présenté tel quel. Les requêtes qui comportent une entrée audio utilisent toujours Chat Completions, car la Responses API ne l'accepte pas. Les requêtes envoyées à /responses définissent store: false, afin que le fournisseur ne conserve pas la conversation.

Profils de compatibilité de chat

Définissez Chat compatibility profile sur la connexion. Il ne s'applique qu'au chat ; la découverte des modèles et les autres capacités continuent d'utiliser leurs endpoints existants. La valeur par défaut est openai. Les identifiants de modèles sont découverts ou configurés par le client, et non déduits d'un catalogue fournisseur.

Choisissez en fonction du comportement d'API du serveur, et pas seulement de sa famille de modèles. Par exemple, un modèle Qwen auto-hébergé peut utiliser le profil standard ou reasoning-content plutôt que le profil de l'API Qwen hébergée par Alibaba. Les valeurs de profil inconnues sont rejetées.

Les racines de version explicites telles que /api/paas/v4 sont conservées pour la découverte et le chat ; une racine sans version reçoit /v1. Les endpoints avec clé d'API comme sans clé sont pris en charge. Des connexions différentes peuvent sélectionner des profils différents.

Exposez le modèle activé via l'AI Gateway. Les clients peuvent utiliser Chat Completions, Responses ou Anthropic Messages, tandis que l'amont reçoit Chat Completions. La conversion de protocole n'émule pas les outils hébergés non pris en charge, le stockage distant des conversations ni les capacités des modèles.

Pour les endpoints sur site, déployez l'exécuteur à un endroit d'où il peut joindre le serveur et configurez l'egress de l'organisation en conséquence. Définir une URL privée ne crée pas de connectivité réseau. Testez le texte, les suites d'appels d'outils et le streaming sur votre serveur réel avant de vous appuyer sur une capacité ; la découverte seule ne vaut pas qualification.