Journaux d’inférence de capture automatique pour l’inférence en temps réel¶
Utiliser la capture automatique dans Snowflake ML pour enregistrer automatiquement chaque demande et réponse traitées par un service de modèle. La capture automatique offre une visibilité immédiate sur les demandes qui ont réussi, les demandes qui ont échoué et les entrées derrière des prédictions inattendues.
Au lieu de canaliser les données de demande ou de réponse dans une table ou une vue, vous pouvez automatiquement rendre persistants les données de demande et de réponse d’inférence. Au lieu de devoir créer correctement des pipelines pour l’ingestion et la surveillance des données, vous pouvez utiliser la capture automatique.
Avec la capture automatique, vous pouvez effectuer les opérations suivantes :
Débogage rapide : Analysez les données d’inférence historiques pour diagnostiquer les cas limites et comprendre le comportement des modèles.
Améliorez en continu vos modèles : Utilisez des données de production réelles pour créer des ensembles de données de haute qualité afin d’entraîner de nouveaux modèles.
Test : Utilisez les données collectées à partir des journaux pour les tests A/B et les tests en parallèle.
Pour chaque demande d’inférence, la capture automatique enregistre ce qui suit :
Charge utile de la demande
Charge utile de la réponse
Identificateur de la version du modèle
Identificateur du service
Métadonnées de routage de passerelle
Horodatages des demandes et des réponses
Code de réponse (tel que 200).
Note
Snowflake ne capture pas les données pour les entrées et les sorties à l’aide du moteur d’inférence vLLM.
Ces données sont en lecture seule et ne peuvent pas être modifiées par les utilisateurs.
Snowflake capture uniquement les données de réponse des demandes qui ont réussi. Si une demande échoue, Snowflake ne capture aucune donnée.
Conditions préalables et compatibilité des versions du modèle¶
Les sections suivantes décrivent les conditions préalables et la compatibilité des versions de modèles pour la capture automatique.
Exigences en matière de contrôle d’accès¶
Pour configurer les données d’inférence capturées et y accéder, votre rôle doit disposer des privilèges suivants :
Privilège |
Objet |
Remarques |
|---|---|---|
OWNERSHIP |
Modèle |
Nécessaire pour créer un service avec la capture automatique activée et pour lire les données de la table d’inférence à l’aide de la fonction INFERENCE_TABLE. OWNERSHIP est un privilège spécial sur un objet qui est automatiquement accordé au rôle qui a créé l’objet, mais qui peut aussi être transféré à l’aide de la commande GRANT OWNERSHIP vers un rôle différent par le rôle propriétaire (ou tout rôle avec le privilège MANAGE GRANTS). Seul le propriétaire d’un schéma d’accès géré (par exemple, le rôle doté du privilège OWNERSHIP sur le schéma) ou un rôle doté du privilège MANAGE GRANTS peut accorder ou révoquer des privilèges sur les objets du schéma, y compris des autorisations à venir. |
OWNERSHIP |
Service |
Requis pour indiquer si la capture automatique est activée pour un service dans la fonction list_service(). OWNERSHIP est un privilège spécial sur un objet qui est automatiquement accordé au rôle qui a créé l’objet, mais qui peut aussi être transféré à l’aide de la commande GRANT OWNERSHIP vers un rôle différent par le rôle propriétaire (ou tout rôle avec le privilège MANAGE GRANTS). Seul le propriétaire d’un schéma d’accès géré (par exemple, le rôle doté du privilège OWNERSHIP sur le schéma) ou un rôle doté du privilège MANAGE GRANTS peut accorder ou révoquer des privilèges sur les objets du schéma, y compris des autorisations à venir. |
USAGE |
Modèle, service, version, passerelle |
Nécessaire pour résoudre les entités dans la fonction INFERENCE_TABLE. |
Compatibilité de la version du modèle¶
Chaque modèle existe en tant qu’objet de modèle. L’objet modèle possède sa propre table d’inférence, qui contient les données et les métadonnées de chaque demande d’inférence. La capture automatique enregistre les données de la table d’inférence du modèle. Chaque service de modèle possède sa propre table d’inférence.
Si vous créez un nouveau modèle, la capture automatique est automatiquement activée.
Les modèles créés avant le 23 janvier 2026 ne prennent pas en charge la capture automatique. Vous devez cloner le modèle et activer la capture automatique pour son service.
Utilisez la commande suivante pour dupliquer un modèle existant :
CREATE [ OR REPLACE ] MODEL [ IF NOT EXISTS ] <name> [ WITH VERSION <version_name> ]
FROM MODEL <source_model_name> [ VERSION <source_version_or_alias_name> ]
Le modèle créé avec la commande précédente a une table d’inférence vide. Pour plus d’informations sur l’activation de la capture automatique, voir Activer la capture automatique.
Vous pouvez également créer une version de modèle à partir d’une version de modèle existante. Pour plus d’informations, voir Syntaxe des variantes.
Après avoir dupliqué le modèle, vous pouvez activer la capture automatique en suivant les instructions dans Activer la capture automatique.
Activer la capture automatique¶
Après avoir créé un nouveau modèle ou cloné un modèle existant, activez la capture automatique pour le service de modèle à l’aide du SDK Python. Pour plus d’informations sur le service de modèle, voir Déployer des modèles pour l’inférence en temps réel (REST API).
Utilisez le code Python suivant pour activer la capture automatique :
mv.create_service(
service_name="my_service",
service_compute_pool="my_compute_pool",
autocapture=True
)
La variable mv est l’objet de la version du modèle. Vous l’avez définie lorsque vous avez connecté le modèle au registre des modèles.
La valeur par défaut pour la capture automatique est False. Assurez-vous d’activer la capture automatique pour un modèle que vous avez créé après le 23 janvier 2026 et connecté au registre des modèles. Sinon, la création du service échoue, car le modèle ne dispose pas d’une table d’inférence.
Important
Le paramètre de capture automatique est immuable. Vous ne pouvez pas activer ou désactiver la capture automatique sur un service de modèle existant. Vous devez recréer le service pour modifier cette configuration. Si vous recréez le service, le point de terminaison change, sauf si vous utilisez un point de terminaison ou une passerelle stable.
Interroger les données d’inférence¶
Pour accéder à vos journaux, utilisez la fonction INFERENCE_TABLE. Cette fonction renvoie les journaux d’inférence pour un modèle et prend en charge le filtrage par version, service et passerelle. Seuls les propriétaires du modèle peuvent voir les données lorsqu’ils disposent de privilèges USAGE sur la passerelle et le service.
Exemple de base¶
L’exemple suivant montre comment récupérer tous les journaux d’inférence pour un modèle en utilisant la fonction INFERENCE_TABLE. Cette requête renvoie toutes les données de demande et de réponse capturées pour chaque demande d’inférence traitée par les services du modèle.
-- Fetch all inference logs for a specific model
SELECT * FROM TABLE(INFERENCE_TABLE('my_model'));
Exemple de filtrage avancé¶
Vous pouvez filtrer par versions, services ou passerelles spécifiques directement dans la fonction INFERENCE_TABLE() :
SELECT * FROM TABLE(
INFERENCE_TABLE(
'MY_MODEL',
VERSION => 'V1',
SERVICE => 'MY_PREDICTION_SERVICE',
GATEWAY => 'MY_GATEWAY'
)
);
Important
Les arguments de service, de version et de passerelle doivent exister au moment de la requête. Si un nouveau service, une nouvelle version ou une nouvelle passerelle est créé avec le même nom que celui qui existait précédemment, la requête ne produit que les données de la version actuelle.
Vous pouvez utiliser la clause de prédicat suivante pour filtrer par nom de fonction :
WHERE RECORD_ATTRIBUTES:"snow.model_serving.function.name" = 'predict'
Note
Pour une performance optimale, filtrez une plage horaire sur la colonne TIMESTAMP.
Interrogation des données historiques des entités supprimées¶
Les données d’inférence sont conservées après la suppression d’un service, d’une version ou d’une passerelle. Vous pouvez toujours interroger ces données historiques à condition que le modèle existe toujours.
L’exemple suivant renvoie tous les journaux d’inférence pour un modèle :
SELECT *
FROM TABLE(
INFERENCE_TABLE('my_model')
);
L’exemple suivant filtre les journaux d’inférence par version de modèle :
SELECT *
FROM TABLE(
INFERENCE_TABLE(
'my_model',
MODEL_VERSION => 'v1'
)
);
L’exemple suivant filtre les journaux d’inférence par version et par service :
SELECT *
FROM TABLE(
INFERENCE_TABLE(
'my_model',
MODEL_VERSION => 'v1',
SERVICE => 'my_service'
)
);
L’exemple suivant filtre les journaux d’inférence par version et par passerelle :
SELECT *
FROM TABLE(
INFERENCE_TABLE(
'my_model',
MODEL_VERSION => 'v1',
GATEWAY => 'my_gateway'
)
);
Schéma de données et métadonnées¶
Snowflake capture uniquement les données de réponse des demandes qui ont réussi. Si une demande échoue, Snowflake ne capture aucune donnée.
Les attributs d’enregistrement qui sont capturés sont les suivants :
Champ |
Description |
|---|---|
|
Les fonctionnalités d’entrée envoyées au modèle. |
|
La sortie d’inférence renvoyée par le modèle. |
|
Lorsque la demande a atteint le service d’inférence. |
|
Le statut HTTP (tel que 200 pour la réussite et 5xx pour les erreurs). |
|
Indique si les données ont dépassé les limites de taille (NONE ou TRUNCATED_DEFAULT). Pour plus d’informations, voir Logique de troncation des données. |
|
Reflète l’ID de la dernière passerelle à partir de laquelle la demande a abouti au service d’inférence. |
|
Reflète la liste des identifiants de passerelle, décrivant le chemin de parcours. Actuellement limité à une seule passerelle. |
Logique de troncation des données¶
Pour maintenir les performances du système, il existe un 1 limite de MB pour chaque événement d’inférence. Si la demande et la réponse atteignent la limite, Snowflake applique un processus de troncation en plusieurs zones de préparation pour préserver autant d’utilité que possible.
Le tableau suivant illustre le processus de troncation :
Étape |
Déclencheur |
Action entreprise |
|---|---|---|
1 : Réduction douce |
> 700 KB |
Octets bruts supprimés ; Chaînes > 2 KB tronqué ; JSON objets remplacés par un statut |
2 : Agressif |
> 900 KB |
Toutes les chaînes ont été tronquées à 256 octets. |
3 : Suppression |
> 900 KB* |
Si elle est toujours supérieure à la limite, la charge utile est détruite et remplacée par un squelette de métadonnées minimal. |
*La zone de préparation 3 se produit si les métadonnées seules dépassent le seuil après la réduction du contenu.
Limits¶
Gardez à l’esprit les limitations et considérations suivantes lorsque vous utilisez la capture automatique :
Prise en charge de LLM La capture automatique n’est pas prise en charge pour les grands modèles de langage (LLMs).
Débit : La capture automatique est conçue pour un débit système d’environ 300-400 demandes par seconde (ou 10MB/s) par service.
Réplication : Vous ne pouvez pas répliquer les tables d’inférence. Les modèles répliqués n’auront pas de tables d’inférence dans le compte cible.
Conservation : Les données d’inférence persistent même si le service ou la passerelle est supprimé.
Avertissement : La suppression de l’objet Modèle supprimera définitivement toutes les données d’inférence associées.
Réalité de terrain : Pour effectuer une analyse de migration, maintenez une table de réalité de terrain séparée et joignez-la à la sortie INFERENCE_TABLE en utilisant des IDs de demande communs.
Comptes des consommateurs : Les comptes des consommateurs ne peuvent pas créer un service lorsque la capture automatique est activée pour les modèles partagés avec des tables d’inférence.
Performance : La capture automatique est conçue pour ne pas ajouter de latence aux demandes d’inférence. Cependant, certaines captures peuvent être supprimées pendant les périodes de volume de demandes extrêmement élevé.
Schéma¶
Dans le cadre de cette fonction, les valeurs suivantes sont ajoutées aux colonnes respectives.
RESOURCE_ATTRIBUTES¶
Le tableau suivant décrit les champs du schéma d’attributs de ressources :
Champ |
Description |
|---|---|
|
Identificateur unique de la version de modèle. |
|
Nom de la version de modèle. |
RECORD_ATTRIBUTES¶
Le tableau suivant décrit les champs du schéma d’attributs d’enregistrement :
Champ |
Description |
|---|---|
|
Nom de la fonction de modèle qui a été appelée. |
|
L’ID de la dernière passerelle qui a traité la demande. |
|
Liste des IDs de passerelles qui ont traité la demande. |
|
Champs d’entrée où |
|
Horodatage du moment où la demande a été capturée par le service d’inférence. |
|
Données de réponse où |
|
Horodatage du moment où la réponse a été capturée par le service. |
|
Code de réponse du service d’inférence (par exemple, 200, 5xx). |
|
Indique si les données ont été tronquées. Les valeurs sont |