Gouverner les APIs de modèle (services de modèle)
Une API de modèle vous donne un accès gouverné à un grand modèle de langage. Envoyez une requête, obtenez une réponse, sans infrastructure à exécuter. default, chaque utilisateur du compte peut query les APIs de modèle fournies par le système dans le schéma system.ai sans aucune configuration. Il s’agit de modèles de fondation servis en mode natif par Databricks, facturés par jeton.
Sur Databricks, une API de modèle est un objet sécurisable Unity Catalog (un service de modèle) qui représente un endpoint LLM gouverné. Comme Unity Catalog le stocke, vous définissez, partagez et gouvernez son accès de manière centralisée, parallèlement à vos données et au-delà des limites des Workspace. Pour gouverner des modèles supplémentaires ou exposer un Endpoint, vous créez vos propres APIs.
Les APIs de modèle prennent en charge les éléments suivants :
- Modèles de fondation avec paiement par jeton hébergés par Databricks , en tant que services fournis par le système dans
system.aiet en tant que services que vous créez. - Création et gestion des APIs de modèle avec l’interface utilisateur Unity AI Gateway, l’Explorateur de catalogues et l’API REST Unity Catalog.
- Interrogation des APIs de modèle entre les Workspace, depuis l’intérieur et l’extérieur de Databricks.
Qu’est-ce qu’un service de modèle ?
Un service de modèle réside dans un schéma Unity Catalog et référence une ou plusieurs destinations, avec un routage et un fallback entre elles. Les appelants invoquent le service de modèle par son nom complet, et Unity AI Gateway achemine chaque requête vers une destination. Une destination peut être un modèle servi par Databricks ou un service de fournisseur de modèle qui achemine vers un fournisseur externe, et un seul service de modèle peut combiner les deux.
Étant donné qu'un service de modèle est un objet sécurisable Unity Catalog, il :
- **Vit dans un catalogue et un schéma**, où il hérite des paramètres du schéma tels que les liaisons de workspace.
- Contient les métadonnées standard de Unity Catalog , telles que le nom, le propriétaire, le commentaire et les tags.
- Est régi par les privilèges Unity Catalog , vous accordez donc l'accès en utilisant les mêmes déclarations
GRANTetREVOKEque vous utilisez pour les tables, les fonctions et les modèles. - **Est découvrable dans Catalog Explorer**, aux côtés du reste de vos assets Unity Catalog.
Le même service de modèle apparaît également comme un endpoint dans l'interface utilisateur de Unity AI Gateway, où les équipes d'IA peuvent configurer des fonctionnalités telles que les limites de débit, les tables d'inférence et les garde-fous. Pour en savoir plus sur ces fonctionnalités, consultez la gouvernance de l'IA avec Unity AI Gateway.
Pourquoi régir les LLM dans Unity Catalog ?
Les Endpoint de passerelle d’IA Unity créés dans un Workspace sont limités à ce Workspace. Pour partager un Endpoint entre les workspaces, vous devez le dupliquer dans chaque workspace et gérer chaque copie séparément.
Les services de modèle intègrent la gouvernance à Unity Catalog, afin que vous puissiez :
- Définissez un Endpoint LLM une seule fois et utilisez-le depuis n'importe quel Workspace rattaché au même métastore.
- Gouvernez l'accès de manière centralisée à l'aide des privilèges Unity Catalog, plutôt qu'avec des autorisations par Workspace.
- Découvrez les modèles qui vous sont disponibles sur tous les workspaces à partir d'un seul emplacement.
- Suivez l’utilisation et les coûts des services de modèle dans les tables système de Unity Catalog.
- Suivez la traçabilité pour voir les modèles qu’un service dessert et les assets en aval qui consomment ses charges utiles. Consultez Suivre la traçabilité des API de modèle et des fournisseurs.
Services de modèle fournis par le système
Databricks fournit un service de modèle prêt à l'emploi dans le schéma system.ai pour chaque modèle de fondation servi par Databricks, tel que system.ai.claude-opus-5. Databricks ajoute de nouveaux services de modèle système à mesure que de nouveaux modèles de fondation deviennent disponibles.
Les services de modèles fournis par le système présentent les caractéristiques suivantes :
- Par default, tous les utilisateurs du compte disposent du privilège
EXECUTE, afin que vous puissiez les interroger sans configuration supplémentaire. - Un utilisateur système les possède, et vous ne pouvez pas les supprimer.
- By default, seuls les administrateurs de metastore peuvent les modifier. Un administrateur de métastore peut déléguer la gestion en accordant le privilège
MANAGE.
Pour restreindre l'accès aux services de modèle fournis par le système, consultez gérer les services de modèle.
Privilèges
Les services de modèle utilisent le modèle de privilèges standard d'Unity Catalog. Les privilèges suivants s'appliquent :
Privilège | Description |
|---|---|
| Accéder au catalogue et au schéma qui contiennent le service de modèle. Requis pour toutes les Opérations. |
| Créez des services de modèle dans un schéma. Accordé sur le catalogue ou le schéma. |
| Interroger un service de modèle. |
| Modifier ou supprimer un service de modèle et gérer ses autorisations. Le propriétaire a un sur-ensemble de |
Les services de modèle utilisent les privilèges du définisseur. Databricks évalue une query en fonction des privilèges du propriétaire plutôt que de ceux de l'appelant. Lorsqu'un utilisateur effectue une query sur un service de modèle, Databricks vérifie que le propriétaire dispose de EXECUTE sur les destinations référencées, comme les modèles sous-jacents et tout service de fournisseur de modèle. L'appelant n'a pas besoin d'un accès direct à ces destinations.
Limitations
Les capacités suivantes ne sont pas prises en charge :
- Modèles de throughput provisionné en tant que destinations.
- Création et gestion de services de modèle avec SQL.
- Découverte des services de modèle avec seulement le privilège
BROWSE. - Recherche globale de services de modèle.