Configurer AI Gateway sur les endpoints de service de modèle

info

Essayez la nouvelle version Bêta de la passerelle d'IA Unity

Une nouvelle expérience Unity AI Gateway est disponible en Bêta. La nouvelle Unity AI Gateway est le plan de contrôle d’entreprise pour la gouvernance des Endpoint LLM et des agents de codage avec des fonctionnalités améliorées. Voir Gouvernance de l’IA avec Unity AI Gateway.

Dans cet article, vous apprendrez à configurer AI Gateway sur un endpoint de service de modèle.

Exigences

• Un workspace Databricks dans une région où la diffusion de modèles est prise en charge. Voir la disponibilité des fonctionnalités de Model Serving.

• Un Endpoint de service de modèle. Vous pouvez utiliser l'un des Endpoint préconfigurés de paiement par jeton sur votre Workspace ou effectuer les opérations suivantes :

  • Pour créer un endpoint pour les modèles externes, suivez les étapes 1 et 2 de Créer un endpoint de déploiement de modèles externes.
  • Pour créer un endpoint pour un throughput provisionné, consultez APIs de modèles de fondation à throughput provisionné.
  • Pour créer un endpoint pour un modèle personnalisé, consultez Créer un endpoint.

• Les opérations d'administration d'Endpoint nécessitent CAN MANAGE sur cet Endpoint. Voir les listes de contrôle d'accès.

• Lors de la création, le créateur se voit accorder CAN MANAGE sur le nouvel Endpoint.

• Pour éviter de contourner les garde-fous ou les limites de throughput, limitez la création d’Endpoint et CAN MANAGE aux administrateurs, et accordez aux autres utilisateurs uniquement des autorisations de query sur les endpoints approuvés.

Configurer la passerelle d'IA Unity à l'aide de l'interface utilisateur

Dans la section AI Gateway de la page de création d'endpoint, vous pouvez configurer individuellement les fonctionnalités de Unity AI Gateway. Consultez Fonctionnalités prises en charge pour connaître les fonctionnalités disponibles sur les endpoints de service de modèles externes et les endpoints à throughput provisionné.

Le tableau suivant résume comment configurer Unity AI Gateway lors de la création d'Endpoint en utilisant l'interface utilisateur de Serving. Si vous préférez le faire par programmation, consultez l'exemple de Notebook.

Fonctionnalité	Comment activer	Détails
Suivi de l'utilisation	Sélectionnez Activer le suivi de l'utilisation pour activer le suivi et le monitoring des métriques d'utilisation des données.	Vous devez avoir Unity Catalog activé. Les tables système suivantes seront automatiquement partagées : system.serving.endpoint_usage, qui capture le nombre de jetons pour chaque requête vers l'Endpoint. system.serving.served_entities, qui stocke les métadonnées de chaque modèle de fondation. Consultez les schémas de table de suivi d'utilisation Seuls les administrateurs de compte ont l'autorisation d'afficher ou d'interroger la table served_entities ou la table endpoint_usage, même si l'utilisateur qui gère l'Endpoint doit activer le suivi d'utilisation. Voir Autoriser l'accès aux tables système. Le nombre de jetons d'entrée et de sortie est estimé à (text_length+1)/4 si le nombre de jetons n'est pas renvoyé par le modèle.
Journalisation de la charge utile	Sélectionnez Activer les tables d'inférence pour enregistrer automatiquement les requêtes et les réponses depuis votre Endpoint dans les tables Delta gérées par Unity Catalog.	Vous devez avoir Unity Catalog activé et un accès CREATE TABLE dans le schéma de catalogue spécifié. Consultez le schéma de la table d'inférence compatible avec Unity AI Gateway. Les données de journalisation de la charge utile remplissent ces tables moins d'une heure après l'interrogation de l'Endpoint. Consultez les Limitations pour connaître les attentes en matière de latence pour les Endpoint de déploiement de modèles personnalisés. Les charges utiles supérieures à 1 MiB ne sont pas journalisées. La charge utile de la réponse agrège la réponse de tous les segments renvoyés. Le streaming est pris en charge. Dans les scénarios de streaming, la charge utile de la réponse agrège la réponse des blocs renvoyés. Les tables d'inférence pour les endpoints de service de modèle optimisés par l'itinéraire sont en aperçu public.
Garde-fous pour l’IA	Consultez Configurer les garde-fous de l'IA dans l'interface utilisateur.	Les garde-fous empêchent le modèle d'interagir avec le contenu dangereux et nuisible détecté dans les entrées et les sorties du modèle. Les garde-fous de sortie ne sont pas pris en charge pour les modèles d'incorporation ou pour le streaming.
Limites de débit	Sélectionnez Limites de taux pour gérer et spécifier le nombre de query par minute (QPM) ou de jetons par minute (TPM) que votre Endpoint peut prendre en charge. Les limites de débit s’appliquent uniquement aux utilisateurs qui ont l’autorisation de query l’Endpoint. Vous pouvez définir des limites de débit basées sur une query et basées sur un jeton à différents niveaux : Utilisez le champ Endpoint pour spécifier le nombre maximal de QPM ou de TPM que l'ensemble de l'endpoint peut gérer. Cette limite s'applique à tout le trafic, quel que soit l'utilisateur. Utilisez le champ User (Default) pour définir une limite de débit par utilisateur par default qui s'applique à tous les utilisateurs de l'Endpoint, sauf si une limite de débit personnalisée plus spécifique est définie. Vous pouvez spécifier des limites de débit personnalisées pour : Utilisateurs individuels ou service principals . Ceux-ci priment sur les limites de débit personnalisées des groupes d'utilisateurs. Groupes d'utilisateurs . Cette limite est une limite de débit partagée pour tous les membres du groupe.	Les limites de débit TPM ne peuvent pas être appliquées aux endpoints de service qui servent des modèles personnalisés ou des agents. Par default, aucune limite de débit n'est configurée pour les utilisateurs ou l'Endpoint. Un maximum de 20 limites de débit et jusqu'à 5 limites de débit spécifiques à un groupe peuvent être spécifiées sur un Endpoint. La limite de débit de l'Endpoint est un maximum global. Si cette limite est dépassée, toutes les requêtes vers l'Endpoint sont bloquées, quelles que soient les limites de débit spécifiques à l'utilisateur ou au groupe. Si un Endpoint, un utilisateur ou un Service Principal possède à la fois une limite de débit basée sur les query et une limite de débit basée sur les jetons, la limite de débit la plus restrictive est appliquée. Les limites de débit personnalisées remplacent la limite de débit utilisateur (default). Si un utilisateur appartient à la fois à une limite spécifique à l'utilisateur et à une limite spécifique au groupe, la limite spécifique à l'utilisateur est appliquée. Si un utilisateur appartient à plusieurs groupes d’utilisateurs avec des limites de débit QPM ou TPM différentes, alors l’utilisateur est soumis à une limite de débit s’il dépasse toutes les limites de débit QPM ou toutes les limites de débit TPM de ses groupes d’utilisateurs.
Répartition du trafic	Dans la section **Entités servies**, spécifiez le **pourcentage de trafic** que vous souhaitez acheminer vers des modèles spécifiques. Pour configurer la répartition du trafic sur votre Endpoint par programmation, consultez Servir plusieurs modèles externes à un Endpoint.	Pour acheminer tout le trafic vers un modèle spécifique, définissez-le sur 100 %. Si vous souhaitez spécifier un modèle réservé au fallback, ajoutez ce modèle à l'Endpoint et définissez son pourcentage de trafic à 0 %. Pour équilibrer la charge du trafic entre les modèles et configurer les fallbacks, vous pouvez vous attendre au comportement suivant : Les requêtes sont réparties aléatoirement entre les entités en fonction des pourcentages de trafic attribués. Si la requête atteint la première entité et échoue, elle revient à l'entité suivante dans l'ordre où les entités servies ont été listées lors de la création de l'endpoint ou de la mise à jour la plus récente de l'endpoint. La répartition du trafic n'influence pas l'ordre des tentatives de fallback.
Fallbacks	Sélectionnez Activer les fallbacks dans la section Passerelle IA pour envoyer votre demande à d'autres modèles servis sur l'endpoint en tant que fallback.	Si la requête initiale acheminée vers une certaine entité renvoie une erreur 429 ou 5XX, la requête est redirigée vers l'entité suivante figurant sur l'endpoint. L’ordre dans lequel les requêtes sont redirigées vers les entités servies de fallback est basé sur l’ordre dans lequel les modèles sont répertoriés lors de la création de l’Endpoint ou de la mise à jour la plus récente de l’Endpoint. Le pourcentage de trafic n’influence pas l’ordre des tentatives de fallback envoyées aux entités servies. Les fallback ne sont pris en charge que pour les modèles externes. Vous devez affecter des pourcentages de trafic à d'autres modèles servis sur l'Endpoint avant de pouvoir activer les fallback vers des modèles externes. Tout modèle externe auquel 0 % de trafic est attribué fonctionne exclusivement comme un modèle de fallback. Vous pouvez avoir un maximum de deux fallbacks. Chaque entité est tentée une fois dans l’ordre séquentiel jusqu’à ce que la requête réussisse. Si toutes les entités listées ont été tentées sans succès, la requête échoue. La première tentative de requête réussie ou la dernière échouée et la réponse sont journalisées dans les tables de suivi d'utilisation et de journalisation de la charge utile.

Fonctionnalité	Comment activer	Détails
Suivi de l'utilisation	Sélectionnez Activer le suivi de l'utilisation pour activer le suivi et le monitoring des métriques d'utilisation des données.	Vous devez avoir Unity Catalog activé. Les tables système suivantes seront automatiquement partagées : system.serving.endpoint_usage, qui capture le nombre de jetons pour chaque requête vers l'Endpoint. system.serving.served_entities, qui stocke les métadonnées de chaque modèle de fondation. Consultez les schémas de table de suivi d'utilisation Seuls les administrateurs de compte ont l'autorisation d'afficher ou d'interroger la table served_entities ou la table endpoint_usage, même si l'utilisateur qui gère l'Endpoint doit activer le suivi d'utilisation. Voir Autoriser l'accès aux tables système. Le nombre de jetons d'entrée et de sortie est estimé à (text_length+1)/4 si le nombre de jetons n'est pas renvoyé par le modèle.
Journalisation de la charge utile	Sélectionnez Activer les tables d'inférence pour enregistrer automatiquement les requêtes et les réponses depuis votre Endpoint dans les tables Delta gérées par Unity Catalog.	Vous devez avoir Unity Catalog activé et un accès CREATE TABLE dans le schéma de catalogue spécifié. Consultez le schéma de la table d'inférence compatible avec Unity AI Gateway. Les données de journalisation de la charge utile remplissent ces tables moins d'une heure après l'interrogation de l'Endpoint. Consultez les Limitations pour connaître les attentes en matière de latence pour les Endpoint de déploiement de modèles personnalisés. Les charges utiles supérieures à 1 MiB ne sont pas journalisées. La charge utile de la réponse agrège la réponse de tous les segments renvoyés. Le streaming est pris en charge. Dans les scénarios de streaming, la charge utile de la réponse agrège la réponse des blocs renvoyés. Les tables d'inférence pour les endpoints de service de modèle optimisés par l'itinéraire sont en aperçu public.
Garde-fous pour l’IA	Consultez Configurer les garde-fous de l'IA dans l'interface utilisateur.	Les garde-fous empêchent le modèle d'interagir avec le contenu dangereux et nuisible détecté dans les entrées et les sorties du modèle. Les garde-fous de sortie ne sont pas pris en charge pour les modèles d'incorporation ou pour le streaming.
Limites de débit	Sélectionnez Limites de taux pour gérer et spécifier le nombre de query par minute (QPM) ou de jetons par minute (TPM) que votre Endpoint peut prendre en charge. Les limites de débit s’appliquent uniquement aux utilisateurs qui ont l’autorisation de query l’Endpoint. Vous pouvez définir des limites de débit basées sur une query et basées sur un jeton à différents niveaux : Utilisez le champ Endpoint pour spécifier le nombre maximal de QPM ou de TPM que l'ensemble de l'endpoint peut gérer. Cette limite s'applique à tout le trafic, quel que soit l'utilisateur. Utilisez le champ User (Default) pour définir une limite de débit par utilisateur par default qui s'applique à tous les utilisateurs de l'Endpoint, sauf si une limite de débit personnalisée plus spécifique est définie. Vous pouvez spécifier des limites de débit personnalisées pour : Utilisateurs individuels ou service principals . Ceux-ci priment sur les limites de débit personnalisées des groupes d'utilisateurs. Groupes d'utilisateurs . Cette limite est une limite de débit partagée pour tous les membres du groupe.	Les limites de débit TPM ne peuvent pas être appliquées aux endpoints de service qui servent des modèles personnalisés ou des agents. Par default, aucune limite de débit n'est configurée pour les utilisateurs ou l'Endpoint. Un maximum de 20 limites de débit et jusqu'à 5 limites de débit spécifiques à un groupe peuvent être spécifiées sur un Endpoint. La limite de débit de l'Endpoint est un maximum global. Si cette limite est dépassée, toutes les requêtes vers l'Endpoint sont bloquées, quelles que soient les limites de débit spécifiques à l'utilisateur ou au groupe. Si un Endpoint, un utilisateur ou un Service Principal possède à la fois une limite de débit basée sur les query et une limite de débit basée sur les jetons, la limite de débit la plus restrictive est appliquée. Les limites de débit personnalisées remplacent la limite de débit utilisateur (default). Si un utilisateur appartient à la fois à une limite spécifique à l'utilisateur et à une limite spécifique au groupe, la limite spécifique à l'utilisateur est appliquée. Si un utilisateur appartient à plusieurs groupes d’utilisateurs avec des limites de débit QPM ou TPM différentes, alors l’utilisateur est soumis à une limite de débit s’il dépasse toutes les limites de débit QPM ou toutes les limites de débit TPM de ses groupes d’utilisateurs.
Répartition du trafic	Dans la section **Entités servies**, spécifiez le **pourcentage de trafic** que vous souhaitez acheminer vers des modèles spécifiques. Pour configurer la répartition du trafic sur votre Endpoint par programmation, consultez Servir plusieurs modèles externes à un Endpoint.	Pour acheminer tout le trafic vers un modèle spécifique, définissez-le sur 100 %. Si vous souhaitez spécifier un modèle réservé au fallback, ajoutez ce modèle à l'Endpoint et définissez son pourcentage de trafic à 0 %. Pour équilibrer la charge du trafic entre les modèles et configurer les fallbacks, vous pouvez vous attendre au comportement suivant : Les requêtes sont réparties aléatoirement entre les entités en fonction des pourcentages de trafic attribués. Si la requête atteint la première entité et échoue, elle revient à l'entité suivante dans l'ordre où les entités servies ont été listées lors de la création de l'endpoint ou de la mise à jour la plus récente de l'endpoint. La répartition du trafic n'influence pas l'ordre des tentatives de fallback.
Fallbacks	Sélectionnez Activer les fallbacks dans la section Passerelle IA pour envoyer votre demande à d'autres modèles servis sur l'endpoint en tant que fallback.	Si la requête initiale acheminée vers une certaine entité renvoie une erreur 429 ou 5XX, la requête est redirigée vers l'entité suivante figurant sur l'endpoint. L’ordre dans lequel les requêtes sont redirigées vers les entités servies de fallback est basé sur l’ordre dans lequel les modèles sont répertoriés lors de la création de l’Endpoint ou de la mise à jour la plus récente de l’Endpoint. Le pourcentage de trafic n’influence pas l’ordre des tentatives de fallback envoyées aux entités servies. Les fallback ne sont pris en charge que pour les modèles externes. Vous devez affecter des pourcentages de trafic à d'autres modèles servis sur l'Endpoint avant de pouvoir activer les fallback vers des modèles externes. Tout modèle externe auquel 0 % de trafic est attribué fonctionne exclusivement comme un modèle de fallback. Vous pouvez avoir un maximum de deux fallbacks. Chaque entité est tentée une fois dans l’ordre séquentiel jusqu’à ce que la requête réussisse. Si toutes les entités listées ont été tentées sans succès, la requête échoue. La première tentative de requête réussie ou la dernière échouée et la réponse sont journalisées dans les tables de suivi d'utilisation et de journalisation de la charge utile.

Le diagramme suivant montre un exemple de fallbacks, où

• Trois entités servies sont déployées sur un endpoint de service de modèle.
• La requête est initialement acheminée vers l'entité desservie 3 .
• Si la requête renvoie une réponse 200, la requête a abouti sur l'entité Served entity 3 et la requête ainsi que sa réponse sont journalisées dans les tables de suivi de l'utilisation et de journalisation des charges utiles de l'Endpoint.
• Si la requête renvoie une erreur 429 ou 5xx sur l' entité servie 3 , la requête bascule vers l'entité servie suivante sur l'Endpoint, l' entité servie 1 .
  • Si la requête renvoie une erreur 429 ou 5xx sur l' entité servie 1 , la requête bascule vers l'entité servie suivante sur l'Endpoint, l' entité servie 2 .
  • Si la requête renvoie une erreur 429 ou 5xx sur *Served entity 2*, la requête échoue car il s’agit du nombre maximal d’entités de secours. La requête ayant échoué et l'erreur de réponse sont enregistrées dans les tables de suivi d'utilisation et de Logs de charge utile.

Configurez les Garde-fous IA dans l'interface utilisateur.

info

Aperçu

Cette fonctionnalité est en aperçu public.

Le tableau suivant montre comment configurer les garde-fous pris en charge.

Garde-fou	Comment activer
Sécurité	Sélectionnez Sécurité pour activer les garde-fous afin d'empêcher votre modèle d'interagir avec du contenu dangereux et nuisible.
Détection des informations personnellement identifiables (PII)	Sélectionnez pour **Bloquer** ou **Masquer** les données DCP telles que les noms, les adresses, les numéros de carte de crédit si de telles informations sont détectées dans les requêtes et les réponses des Endpoint. Sinon, sélectionnez **None** pour qu'aucune détection des PII ne soit effectuée.

Garde-fou	Comment activer
Sécurité	Sélectionnez Sécurité pour activer les garde-fous afin d'empêcher votre modèle d'interagir avec du contenu dangereux et nuisible.
Détection des informations personnellement identifiables (PII)	Sélectionnez pour **Bloquer** ou **Masquer** les données DCP telles que les noms, les adresses, les numéros de carte de crédit si de telles informations sont détectées dans les requêtes et les réponses des Endpoint. Sinon, sélectionnez **None** pour qu'aucune détection des PII ne soit effectuée.

Schémas de table de suivi d'utilisation

Les sections suivantes résument les schémas de table de suivi d'utilisation pour les tables système system.serving.served_entities et system.serving.endpoint_usage.

Schéma de la table de suivi d'utilisationsystem.serving.served_entities

La table système de suivi d’utilisation system.serving.served_entities a le schéma suivant :

Nom de colonne	Description	Type
served_entity_id	L’ID unique de l’entité servie.	CHAÎNE
account_id	L'ID de compte client pour OpenSharing.	CHAÎNE
workspace_id	L'ID de workspace client de l'endpoint de service.	CHAÎNE
created_by	Le nom de l'auteur. Peut être un nom d'utilisateur, de Service Principal ou de groupe. Pour les endpoints à paiement par jeton, il s'agit de System-User	CHAÎNE
endpoint_name	Le nom de l'endpoint de service.	CHAÎNE
endpoint_id	L'ID unique de l'endpoint de service.	CHAÎNE
served_entity_name	Le nom de l'entité servie.	CHAÎNE
entity_type	Type d'entité servie. Peut être FEATURE_SPEC, EXTERNAL_MODEL, FOUNDATION_MODEL, ou CUSTOM_MODEL	CHAÎNE
entity_name	Le nom sous-jacent de l'entité. Différent de served_entity_name qui est un nom fourni par l'utilisateur. Par exemple, entity_name est le nom du modèle Unity Catalog.	CHAÎNE
entity_version	La version de l'entité servie.	CHAÎNE
endpoint_config_version	La version de la configuration du Endpoint.	INT
task	Le type de tâche. Peut être llm/v1/chat, llm/v1/completions ou llm/v1/embeddings.	CHAÎNE
external_model_config	Configurations pour les modèles externes. Par exemple, {Provider: OpenAI}	Structure
foundation_model_config	Configurations des modèles de fondation. Par exemple,{min_provisioned_throughput: 2200, max_provisioned_throughput: 4400}	Structure
custom_model_config	Configurations pour les modèles personnalisés. Par exemple,{ min_concurrency: 0, max_concurrency: 4, compute_type: CPU }	Structure
feature_spec_config	Configurations pour les spécifications de fonctionnalités. Par exemple, { min_concurrency: 0, max_concurrency: 4, compute_type: CPU }	Structure
change_time	Timestamp de modification pour l'entité servie.	Horodatage
endpoint_delete_time	Timestamp de la suppression de l'entité. L'endpoint est le conteneur de l'entité servie. Une fois l'endpoint supprimé, l'entité servie est également supprimée.	Horodatage

Nom de colonne	Description	Type
served_entity_id	L’ID unique de l’entité servie.	CHAÎNE
account_id	L'ID de compte client pour OpenSharing.	CHAÎNE
workspace_id	L'ID de workspace client de l'endpoint de service.	CHAÎNE
created_by	Le nom de l'auteur. Peut être un nom d'utilisateur, de Service Principal ou de groupe. Pour les endpoints à paiement par jeton, il s'agit de System-User	CHAÎNE
endpoint_name	Le nom de l'endpoint de service.	CHAÎNE
endpoint_id	L'ID unique de l'endpoint de service.	CHAÎNE
served_entity_name	Le nom de l'entité servie.	CHAÎNE
entity_type	Type d'entité servie. Peut être FEATURE_SPEC, EXTERNAL_MODEL, FOUNDATION_MODEL, ou CUSTOM_MODEL	CHAÎNE
entity_name	Le nom sous-jacent de l'entité. Différent de served_entity_name qui est un nom fourni par l'utilisateur. Par exemple, entity_name est le nom du modèle Unity Catalog.	CHAÎNE
entity_version	La version de l'entité servie.	CHAÎNE
endpoint_config_version	La version de la configuration du Endpoint.	INT
task	Le type de tâche. Peut être llm/v1/chat, llm/v1/completions ou llm/v1/embeddings.	CHAÎNE
external_model_config	Configurations pour les modèles externes. Par exemple, {Provider: OpenAI}	Structure
foundation_model_config	Configurations des modèles de fondation. Par exemple,{min_provisioned_throughput: 2200, max_provisioned_throughput: 4400}	Structure
custom_model_config	Configurations pour les modèles personnalisés. Par exemple,{ min_concurrency: 0, max_concurrency: 4, compute_type: CPU }	Structure
feature_spec_config	Configurations pour les spécifications de fonctionnalités. Par exemple, { min_concurrency: 0, max_concurrency: 4, compute_type: CPU }	Structure
change_time	Timestamp de modification pour l'entité servie.	Horodatage
endpoint_delete_time	Timestamp de la suppression de l'entité. L'endpoint est le conteneur de l'entité servie. Une fois l'endpoint supprimé, l'entité servie est également supprimée.	Horodatage

Schéma de la table de suivi d'utilisationsystem.serving.endpoint_usage

La table système de suivi d’utilisation system.serving.endpoint_usage a le schéma suivant :

Nom de colonne	Description	Type
account_id	L'ID de compte du client.	CHAÎNE
workspace_id	L'ID de workspace client de l'endpoint de mise en service.	CHAÎNE
client_request_id	L'identifiant de requête fourni par l'utilisateur peut être spécifié dans le corps de la requête du service de modèle. Pour les Endpoint de modèle personnalisés, cela n'est pas pris en charge pour les requêtes supérieures à 4 MiB.	CHAÎNE
databricks_request_id	Un identifiant de requête généré par Databricks attaché à toutes les requêtes de diffusion de modèle.	CHAÎNE
requester	L'ID de l'utilisateur ou du service principal dont les autorisations sont utilisées pour la requête d'invocation de l'endpoint de service.	CHAÎNE
status_code	Le code de statut HTTP qui a été renvoyé par le modèle.	INTEGER
request_time	Timestamp auquel la requête est reçue.	Horodatage
input_token_count	Le nombre de jetons de l'entrée. Ce sera 0 pour les requêtes de modèle personnalisé.	LONG
output_token_count	Le nombre de jetons de la sortie. Ce sera 0 pour les requêtes de modèle personnalisé.	LONG
input_character_count	Le nombre de caractères de la chaîne d'entrée ou de l'invite. Ce sera 0 pour les requêtes de modèle personnalisé.	LONG
output_character_count	Le nombre de caractères de la chaîne de sortie de la réponse. Ce sera 0 pour les requêtes de modèle personnalisé.	LONG
usage_context	La carte fournie par l'utilisateur contenant les identifiants de l'utilisateur final ou de l'application cliente qui effectue l'appel à l'Endpoint. Consultez Définir plus précisément l'utilisation avec usage_context. Pour les endpoints de modèle personnalisés, cela n’est pas pris en charge pour les requêtes supérieures à 4 MiB.	Carte
request_streaming	Si la requête est en mode stream.	Booléen
served_entity_id	L'ID unique utilisé pour joindre la table de dimensions system.serving.served_entities afin de rechercher des informations sur l'Endpoint et l'entité servie.	CHAÎNE

Nom de colonne	Description	Type
account_id	L'ID de compte du client.	CHAÎNE
workspace_id	L'ID de workspace client de l'endpoint de mise en service.	CHAÎNE
client_request_id	L'identifiant de requête fourni par l'utilisateur peut être spécifié dans le corps de la requête du service de modèle. Pour les Endpoint de modèle personnalisés, cela n'est pas pris en charge pour les requêtes supérieures à 4 MiB.	CHAÎNE
databricks_request_id	Un identifiant de requête généré par Databricks attaché à toutes les requêtes de diffusion de modèle.	CHAÎNE
requester	L'ID de l'utilisateur ou du service principal dont les autorisations sont utilisées pour la requête d'invocation de l'endpoint de service.	CHAÎNE
status_code	Le code de statut HTTP qui a été renvoyé par le modèle.	INTEGER
request_time	Timestamp auquel la requête est reçue.	Horodatage
input_token_count	Le nombre de jetons de l'entrée. Ce sera 0 pour les requêtes de modèle personnalisé.	LONG
output_token_count	Le nombre de jetons de la sortie. Ce sera 0 pour les requêtes de modèle personnalisé.	LONG
input_character_count	Le nombre de caractères de la chaîne d'entrée ou de l'invite. Ce sera 0 pour les requêtes de modèle personnalisé.	LONG
output_character_count	Le nombre de caractères de la chaîne de sortie de la réponse. Ce sera 0 pour les requêtes de modèle personnalisé.	LONG
usage_context	La carte fournie par l'utilisateur contenant les identifiants de l'utilisateur final ou de l'application cliente qui effectue l'appel à l'Endpoint. Consultez Définir plus précisément l'utilisation avec usage_context. Pour les endpoints de modèle personnalisés, cela n’est pas pris en charge pour les requêtes supérieures à 4 MiB.	Carte
request_streaming	Si la requête est en mode stream.	Booléen
served_entity_id	L'ID unique utilisé pour joindre la table de dimensions system.serving.served_entities afin de rechercher des informations sur l'Endpoint et l'entité servie.	CHAÎNE

Définir davantage l'utilisation avec usage_context

Lorsque vous interrogez un modèle externe avec le suivi d’utilisation activé, vous pouvez fournir le paramètre usage_context de type Map[String, String]. Le mappage du contexte d'utilisation apparaît dans la table de suivi de l'utilisation dans la colonne usage_context. La taille de la carte usage_context ne peut pas dépasser 10 KiB.

Bash

{
  "messages": [
    {
      "role": "user",
      "content": "What is Databricks?"
    }
  ],
  "max_tokens": 128,
  "usage_context":
    {
      "use_case": "external",
      "project": "project1",
      "priority": "high",
      "end_user_to_charge": "abcde12345",
      "a_b_test_group": "group_a"
    }
}

Si vous utilisez le client Python OpenAI, vous pouvez spécifier le usage_context en l'incluant dans le parameter extra_body.

Python

from openai import OpenAI

client = OpenAI(
    api_key="dapi-your-databricks-token",
    base_url="https://example.staging.cloud.databricks.com/serving-endpoints"
)

response = client.chat.completions.create(
    model="databricks-claude-sonnet-4-5",
    messages=[{"role": "user", "content": "What is Databricks?"}],
    temperature=0,
    extra_body={"usage_context": {"project": "project1"}},
)
answer = response.choices[0].message.content
print("Answer:", answer)

Les administrateurs de compte peuvent agréger différentes lignes en fonction du contexte d'utilisation pour obtenir des insights et peuvent joindre ces informations avec les informations de la table de journalisation des charges utiles. Par exemple, vous pouvez ajouter end_user_to_charge au usage_context pour le suivi de l'attribution des coûts aux utilisateurs finaux.

Surveiller l'utilisation des Endpoint.

Pour surveiller l'utilisation de l'Endpoint, vous pouvez joindre les tables système et les tables d'inférence pour votre Endpoint.

Joindre des tables système

Cet exemple s'applique aux endpoints de modèle externes, de throughput provisionné, de paiement au jeton et personnalisés.

Pour joindre les tables système endpoint_usage et served_entities, utilisez le SQL suivant :

SQL

SELECT * FROM system.serving.endpoint_usage as eu
JOIN system.serving.served_entities as se
ON eu.served_entity_id = se.served_entity_id
WHERE created_by = "\<user_email\>";

Mettre à jour les fonctionnalités de Unity AI Gateway sur les endpoints

Vous pouvez mettre à jour les fonctionnalités de Unity AI Gateway sur les endpoints de service de modèle qui les avaient déjà activées et sur les endpoints qui ne les avaient pas. Les mises à jour des configurations de Unity AI Gateway prennent environ 20 à 40 secondes pour être appliquées, toutefois les mises à jour de la limitation de débit peuvent prendre jusqu'à 60 secondes.

Ce qui suit montre comment mettre à jour les fonctionnalités d'Unity AI Gateway sur un Endpoint de service de modèle à l'aide de l'interface utilisateur de service.

Dans la section Gateway de la page d'endpoint, vous pouvez voir les fonctionnalités activées. Pour mettre à jour ces fonctionnalités, cliquez sur Modifier la passerelle d'IA Unity .

Exemple de Notebook

Le notebook suivant montre comment activer et utiliser par programme les fonctionnalités de la passerelle Databricks Unity AI pour gérer et gouverner les modèles des fournisseurs. Consultez le PUT /api/2.0/serving-endpoints/{name}/ai-gateway pour les détails de l'API REST.

Activez les fonctionnalités du Notebook Databricks Unity AI Gateway

Ouvrir le notebook dans un nouvel ongletOuvrir dans Databricks

Ressources supplémentaires

• AI Gateway pour les endpoints de service.
• Surveiller les modèles déployés à l'aide de tables d'inférence activées par AI Gateway.