Gérer les modèles et outils dans le niveau IA Gateway (aperçu)

S’APPLIQUE AU : niveau AI Gateway (aperçu)

Important

Le niveau de service AI Gateway est actuellement en préversion publique. Lors de l’aperçu public, le niveau IA Gateway est disponible dans les régions suivantes :

  • États-Unis - USA Est 2
  • Europe - Suède centrale

Utilisez le niveau IA Gateway (aperçu) pour gérer les modèles et outils que les applications et agents appellent. Importez des modèles pour fournir un point de terminaison régi pour les requêtes de modèles. Ajoutez des serveurs MCP pour exposer des outils approuvés via un point de terminaison gouverné Model Context Protocol (MCP). Les applications et les agents s’authentifient à la passerelle à l’aide de clés d’accès d’exécution. La passerelle utilise l’authentification du backend que vous configurez pour chaque fournisseur de modèles ou backend d’outil.

Prerequisites

  • Une instance de niveau IA Gateway.
  • Autorisation de gérer l’instance du niveau AI Gateway.
  • Accès au modèle de fournisseur ou au backend que vous prévoyez d’ajouter.
  • Pour l’authentification du back-end à l’aide d’une identité managée, autorisation d’attribuer le rôle requis à la ressource back-end.

Importer des modèles

Utilisez l’assistant Ajouter des modèles pour connecter le niveau AI Gateway à Microsoft Foundry, Azure OpenAI, AWS Bedrock, Google Vertex, OpenAI, Anthropic ou des points d’accès personnalisés. La passerelle dessert chaque modèle sur les points de terminaison supportés par son backend, sous le préfixe https://<gateway>.azure-api.net/default/models. Le segment suivant est le format de l’API du fournisseur. Par exemple, les modèles compatibles OpenAI sont servis en .../default/models/openai/v1 (comme /chat/completions et /responses), et les modèles Anthropic en .../default/models/anthropic/v1/messages. Les champs de connexion dont l’assistant a besoin varient selon le fournisseur.

Choisissez Importer depuis Foundry lorsque votre modèle s'exécute dans une ressource Microsoft Foundry, qui inclut les déploiements Azure OpenAI et Azure AI Services — l'assistant découvre automatiquement les déploiements de la ressource. Choisissez Ajouter un modèle personnalisé pour AWS Bedrock, Google Vertex, OpenAI, Anthropic ou tout autre point de terminaison pris en charge, où vous entrez vous-même les noms du terminau et du modèle.

Utilisez l’identité gérée lorsque le fournisseur prend en charge l’authentification backend Microsoft Entra ID, comme Microsoft Foundry. Accordez à l’identité de la passerelle le rôle requis sur la ressource principale avant l’import. Sinon, fournissez la clé API ou le secret du fournisseur lors de l’importation. La passerelle stocke et protège les informations d’identification.

Les appelants font référence au modèle par son nom de modèle dans le model champ :

{
  "model": "gpt-5.6-sol",
  "messages": [
    {
      "role": "user",
      "content": "Summarize the incident report."
    }
  ]
}

La model valeur est le nom du modèle donné par le modèle importé.

Note

Actuellement, chaque nom de modèle dans la passerelle doit être unique pour tous les fournisseurs. La passerelle achemine chaque requête en fonction d’une correspondance exacte avec la valeur model.

Pour ajouter des modèles, ouvrez la page Modèles et sélectionnez Ajouter des modèles. Choisissez comment vous voulez vous connecter.

Importation depuis Microsoft Foundry

  1. Sélectionnez Importer depuis Foundry.
  2. Sur Sélectionner la ressource, choisissez l’abonnement et la ressource Foundry. L’assistant liste les déploiements de modèles dans cette ressource.
  3. Dans les détails du fournisseur, saisissez un nom et un nom affiché, ajoutez une description optionnelle, puis choisissez la méthode d’authentification - Identité gérée (recommandée, lorsque disponible) ou Basée sur clé.
  4. Cliquez sur Créer. La passerelle importe les déploiements de la ressource sous forme de modèles que les appelants demandent par nom.

Note

Pour utiliser l’identité managée, la passerelle doit déjà avoir une identité gérée configurée, et vous devez avoir la permission d’attribuer le rôle d’utilisateur Foundry à cette identité sur la ressource Foundry. Lorsque vous disposez des autorisations nécessaires, l’assistant d’importation vous attribue le rôle.

Ajouter un modèle personnalisé

  1. Sélectionnez Ajouter un modèle personnalisé.
  2. Sur Fournisseur, saisissez un nom d’affichage et un nom de fournisseur, ainsi qu’une description optionnelle.
  3. Sur Endpoint, entrez l’URL de base du point de terminaison, le nom de l’en-tête d’authentification (par exemple, Authorization), et la clé API.
  4. Sur Models, saisissez chaque nom de modèle et sélectionnez ses points de terminaison pris en charge - complétions de chat OpenAI, réponses OpenAI, messages Anthropic, ou Autre. Sélectionnez Ajouter un modèle pour chaque modèle que vous définissez.
  5. Cliquez sur Créer.

Il n’y a pas d’étape de validation séparée. La passerelle établit la connexion lorsque vous créez le fournisseur. Après avoir ajouté un modèle, vous pouvez mettre à jour son authentification ou ses politiques, ou le supprimer lorsqu’il n’est plus nécessaire.

Après l’ajout du modèle, envoyez une requête de test via le point de terminaison de la passerelle :

curl "https://<gateway>.azure-api.net/default/models/openai/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -H "api-key: <runtime-access-key>" \
  -d '{
    "model": "gpt-5.6-sol",
    "messages": [
      { "role": "user", "content": "Write a one-sentence status update." }
    ]
  }'

Si vous n’avez pas encore créé de clé d’accès à l’exécution, créez-en une depuis la page Clés . Les candidatures n’ont pas besoin d’accréditations directes du fournisseur. Utilisez les vues de surveillance pour examiner le volume des requêtes, la latence, l’utilisation des jetons et les erreurs par nom de modèle.

Passthrough de l’API Anthropic Messages

Différents fournisseurs exposent différents formats d’API, et la passerelle sert chacun sur son propre chemin sous /default/models. Les modèles Anthropic utilisent l’API Anthropic Messages en mode passthrough : la passerelle conserve le format natif de requête et de réponse Anthropic Messages et transmet les appels à Anthropic à /default/models/anthropic/v1/messages. Utilisez-le lorsque les applications utilisent déjà le SDK Anthropic ou /v1/messages.

Pour ajouter un modèle Anthropic, utilisez Ajouter des modèles>Ajouter un modèle personnalisé :

  1. Sur Fournisseur, saisissez un nom d’affichage et un nom de fournisseur pour Anthropic.
  2. Sur Endpoint, définissez l’URL de base du endpoint à https://api.anthropic.com, définissez le nom de l’en-tête d’authentification sur x-api-key, et entrez la clé API Anthropic. La passerelle stocke la clé et l’injecte lors des appels backend.
  3. Dans Models, saisissez le nom du modèle Anthropic que les appelants envoient (comme claude-fable-5), et sélectionnez le point de terminaison des messages Anthropic.
  4. Cliquez sur Créer. La passerelle prend en charge Anthropic Messages en passthrough à /default/models/anthropic/v1/messages.

Les clients utilisent le chemin d’accès de la passerelle. La passerelle stocke l’identifiant, injecte le backend x-api-key et transmet l’en-tête anthropic-version de l’appelant à Anthropic.

curl -X POST "https://<gateway>.azure-api.net/default/models/anthropic/v1/messages" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -H "api-key: <runtime-access-key>" \
  -d '{"model":"claude-fable-5","max_tokens":256,"messages":[{"role":"user","content":"Write a product description for a trail running backpack."}]}'

Le SDK Python d’Anthropic fonctionne si vous pointez base_url vers le chemin de la passerelle. Par défaut, le SDK d’origine envoie l’identifiant dans l’en-tête x-api-key , donc passez la clé d’accès à l’exécution de la passerelle dans l’en-tête api-key en utilisant default_headers. La api_key="unused" valeur ne satisfait que l'argument requis du SDK ; la passerelle l'ignore et injecte la clé Anthropic stockée en backend. Définissez model sur le nom du modèle Anthropic.

from anthropic import Anthropic

client = Anthropic(api_key="unused", base_url="https://<gateway>.azure-api.net/default/models/anthropic", default_headers={"api-key": "<runtime-access-key>"})
message = client.messages.create(model="claude-fable-5", max_tokens=256, messages=[{"role":"user","content":"Hello"}])
print(message.content[0].text)

Validez les délais d’attente et la gestion des réponses avant la production, surtout si les politiques inspectent les organismes.

Ajouter des serveurs MCP

Le niveau AI Gateway permet aux équipes de plateforme de publier des serveurs MCP derrière un seul point de terminaison MCP régi. Le flux de configuration est : créer un serveur MCP, attacher un ou plusieurs backends, et exposer certaines capacités backend sous forme d’outils. Un seul serveur MCP peut combiner trois types de backends : des serveurs MCP distants (par URL), des outils générés à partir d’une spécification OpenAPI, et des connecteurs intégrés pour des applications SaaS courantes (plus de 1 000 intégrations préconstruites, sans serveur à héberger).

Utilisez des serveurs MCP lorsque les agents doivent appeler des systèmes métier, des outils de développement, des magasins de connaissances ou des API internes. Les agents s’authentifient une fois sur la passerelle et n’ont pas besoin d’identifiants séparés pour chaque backend. Pour chaque backend, vous choisissez comment la passerelle s’authentifie : Aucun, clé API, OAuth 2.0 ou identité gérée.

Un seul serveur MCP fédére un ou plusieurs backends. Chaque backend fournit des outils, et la passerelle place les outils de chaque backend dans un espace de noms utilisant le nom du backend afin que des outils portant le même nom provenant de différents backends n’entrent pas en conflit. Par exemple, un outil create_issue provenant d’un backend nommé github est exposé aux agents dans l’espace de noms github, distinct d’un outil create_issue sur un autre backend.

Type de back-end À utiliser lorsque Input Résultat de la passerelle
Serveur MCP Vous hébergez déjà un point de terminaison MCP distant URL de point de terminaison MCP (SSE ou HTTP streamable) Les outils du serveur distant, fédérés via le point de terminaison régi
Spécification OpenAPI Vous avez une API REST que les agents devraient appeler comme outils Document OpenAPI (upload, URL ou collage en ligne) Outils MCP générés à partir des opérations que vous sélectionnez
Connecteur intégré Vous avez besoin d’une application SaaS commune sans héberger de serveur Sélection des connecteurs et configuration des connexions Les actions du connecteur, exposées comme des outils MCP

Chaque source apporte des outils différemment :

  • Serveur MCP — fédére les outils depuis un point de terminaison MCP distant que vous hébergez déjà.
  • Spécification OpenAPI — transforme les opérations API que vous sélectionnez en outils ; Le résumé ou la description de l’opération devient la description de l’outil.
  • Connecteur intégré — utilise une connexion gérée à une application SaaS telle qu’Office 365, SharePoint, GitHub ou Salesforce. Les connecteurs OAuth demandent leur consentement lorsque vous configurez la connexion.

Note

Lors de la présentation publique, les transports supportés, les options d’hébergement et les limites peuvent varier selon la région. Vérifiez les détails d’enregistrement en aperçu de votre abonnement avant de déplacer le trafic de production.

Pour créer un serveur MCP :

  1. Dans le portail de niveau IA Gateway, sélectionnez les serveurs MCP.
  2. Sélectionnez Ajouter un serveur MCP.
  3. Sur Source, choisissez un type backend pour commencer : serveur MCP, spécification OpenAPI ou connecteur intégré. Vous pouvez ajouter plus de backends par la suite.
  4. Donnez un nom unique au backend. La passerelle ajoute comme préfixe aux outils de ce backend le nom de ce backend au sein du serveur MCP combiné.
  5. Configurez le backend et choisissez comment la passerelle s’authentifie : Aucun, clé API, OAuth 2.0 ou identité managée. Pour la clé API, saisissez le nom et la valeur de l’en-tête ; les valeurs sont chiffrées au repos.
  6. Pour fédérer plus de services derrière le même point de terminaison, ajoutez un autre backend et répétez.
  7. Sélectionnez Confirmer, puis Créer.

Il n’y a pas d’étape de test de connectivité séparée. La passerelle configure et vérifie chaque backend lors de la création du serveur.

La passerelle crée un point d’accès MCP qui fédére tous les backends sélectionnés. Les clients appellent le point de terminaison gouverné et s’authentifient avec une clé d’accès à l’exécution.

Note

Authentification backend OAuth 2.0 (limitation de prévisualisation). Pour un backend utilisant OAuth 2.0, vous effectuez une connexion interactive pour autoriser la passerelle vers ce backend. La passerelle ne rapporte pas un statut d’autorisation vérifié au portail, donc après que la fenêtre de connexion confirme la complétude, confirmez le résultat dans le portail quand demandé. Le statut affiché pour le backend est autodéclaré — vérifiez que les outils du backend apparaissent sur le serveur MCP, et reconnectez-vous pour vous identifier à nouveau si ce n’est pas le cas.

Les agents appellent le serveur MCP à :

https://<gateway>.azure-api.net/default/toolservers/<server-name>/mcp

Envoyez la clé d’accès du runtime dans l’en-tête api-key. Pointer tout framework client ou agent compatible MCP vers cette URL. Par exemple, listez les outils disponibles avec une demande JSON-RPC tools/list :

curl "https://<gateway>.azure-api.net/default/toolservers/<server-name>/mcp" \
  -H "Content-Type: application/json" \
  -H "api-key: <runtime-access-key>" \
  -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }'

Si un système possède une API REST mais pas de serveur MCP, importez sa description OpenAPI. Sélectionnez les opérations à exposer comme outils, modifiez les noms et descriptions des outils, configurez une méthode d’authentification backend prise en charge, et créez l’asset MCP. L’outil passerelle mappe les appels aux opérations REST.

Utilisez la passerelle pour les serveurs MCP afin de centraliser :

  • Découverte — fournir un catalogue de serveurs MCP approuvés pour les développeurs et agents.
  • Authentification — les clients s’authentifient à la passerelle. La passerelle stocke les identifiants backend, donc la configuration client ne contient pas de secrets en amont.
  • Exposition aux outils — choisissez quelles opérations backend chaque serveur publie comme outils. En préversion, chaque clé d’accès du runtime peut accéder à toutes les ressources publiées dans la passerelle.
  • Observabilité — la passerelle émet des métriques d’utilisation des tokens OpenTelemetry (OTLP) pour le trafic modèle, que vous pouvez envoyer à Application Insights ou à une autre destination OTLP. La surveillance du trafic par outil MCP (volume de requêtes, latence et erreurs) est disponible dans le portail lorsque vous utilisez Application Insights ; L’exportation OpenTelemetry (OTLP) pour le trafic de l’outil MCP n’est pas encore disponible.
  • Gouvernance — appliquer les mêmes politiques au trafic MCP que vous utilisez pour les modèles, telles que les limites de débit et la sécurité du contenu.

Après avoir créé le serveur, configurez l’accès à l’exécution avant de le partager. Ajoutez des politiques telles que la sécurité du contenu, les filtres IP, ainsi que les limites de débit de jetons et de requêtes, adaptées à la passerelle ou à des actifs publiés spécifiques.

Contenu connexe

  • Last updated on