Inférence par lots native de Snowflake (SQL)¶

Sélectionner un environnement d’exécution¶

Vous pouvez héberger un modèle sur un entrepôt virtuel ou sur un pool de calcul SPCS. Utilisez les informations suivantes pour déterminer où héberger votre modèle.

Exécuter un modèle sur un entrepôt¶

Pour héberger votre modèle sur un entrepôt, spécifiez WAREHOUSE dans l’argument target_plateforms pour enregistrer votre modèle. Pour plus d’informations, consultez la section Utilisation des dépendances et des plateformes cibles.

Pour savoir si un modèle existant est exécutable dans un entrepôt, exécutez SHOW VERSIONS IN MODEL. Si la colonne runnable_in indique WAREHOUSE comme valeur, vous pouvez l’exécuter.

Exécuter un modèle sur SPCS¶

Pour utiliser votre modèle dans SPCS, vous devez déployer le modèle en tant que service. Pour plus d’informations sur le déploiement d’un modèle dans SPCS, consultez la section Déploiement du modèle pour l’inférence en ligne. Assurez-vous que la suspension automatique est active.

Utilisez un entrepôt XSMALL ou SMALL pour acheminer vos demandes d’inférence vers le pool de calcul SPCS. Un entrepôt peut exécuter plusieurs threads par nœud et envoyer un grand nombre de demandes d’inférence avec chaque requête. Par conséquent, le service fonctionnant au sein de SPCS peut être facilement surchargé. Par conséquent, il est recommandé d’utiliser un entrepôt XSMALL ou SMALL lorsque le modèle est déployé dans SPCS.

Se connecter au registre des modèles¶

Récupérez le modèle que vous utilisez pour les demandes d’inférence à partir du registre des modèles. Utilisez le code suivant pour récupérer le modèle :

from snowflake.ml.registry import Registry

registry = Registry(session=session, database_name=DATABASE, schema_name=REGISTRY_SCHEMA)
mv = registry.get_model('my_model').version('my_version')  # returns ModelVersion

Exécuter une tâche d’inférence par lots¶

Utilisez la méthode d’exécution de votre objet de version de modèle pour exécuter une tâche d’inférence par lots. En utilisant la méthode d’exécution, vous pouvez :

• Exécuter une tâche d’inférence sur un entrepôt ou un pool de calcul SPCS.

• Fournir un dataframe Snowpark ou pandas avec les données d’inférence.

La méthode d’exécution renvoie un dataframe qui correspond au type de dataframe que vous avez spécifié. Par exemple, si vous spécifiez un dataframe pandas comme entrée, vous obtenez un dataframe pandas comme sortie.

L’exemple suivant exécute une tâche d’inférence par lots sur un entrepôt :

# Run inference on a warehouse
# mv: snowflake.ml.model.ModelVersion
remote_prediction = mv.run(input_features, function_name="predict")
remote_prediction.show()

Pour exécuter l’inférence sur SPCS au lieu d’un entrepôt, ajoutez l’argument service_name à l’appel run :

# Run inference on SPCS
# mv: snowflake.ml.model.ModelVersion
remote_prediction = mv.run(input_features, function_name="predict", service_name="example_spcs_service")
remote_prediction.show()

Pour voir les méthodes que vous pouvez appeler à partir d’un modèle, exécutez mv.show_functions. La valeur de retour de cette méthode est une liste d’objets ModelFunctionInfo. Chacun de ces objets comprend les attributs suivants :

• name : Nom de la fonction qui peut être appelée depuis Python ou SQL.

• target_method : Nom de la méthode Python dans le modèle original enregistré.

# Get signature of the inference function in Python
# mv: snowflake.ml.model.ModelVersion
mv.show_functions()

Transmission de paramètres pendant l’inférence¶

Si la signature du modèle comprend des paramètres définis dans l’objet ParamSpec, vous pouvez transmettre les valeurs des paramètres au moment de l’inférence en utilisant l’argument params. Tout paramètre non inclus dans le dictionnaire utilise sa valeur par défaut à partir de la signature. L’argument params fonctionne de la même manière que vous exécutiez l’inférence sur un entrepôt ou sur SPCS.

# Pass parameters to override default values
# mv: snowflake.ml.model.ModelVersion
remote_prediction = mv.run(
    input_features,
    function_name="predict",
    params={"temperature": 0.9, "max_tokens": 512}
)

Exécuter un modèle sur un entrepôt¶

Utilisez la syntaxe MODEL(model_name)!method_name(...) pour appeler ou invoquer les méthodes d’un modèle. Les méthodes disponibles sur un modèle sont déterminées par la classe de modèle Python sous-jacente. Par exemple, de nombreux types de modèles utilisent une méthode appelée « prédire » pour l’inférence.

Pour appeler une méthode du modèle par défaut, utilisez la syntaxe suivante. Incluez les arguments de la méthode entre parenthèses et spécifiez la table contenant les données d’inférence dans la clause FROM.

SELECT MODEL(<model_name>)!<method_name>(...) FROM <table_name>;

Pour invoquer une méthode à partir d’une version spécifique d’un modèle, créez un alias vers la version spécifique du modèle et appelez la méthode par l’intermédiaire de l’alias.

Utilisez la syntaxe suivante pour appeler une méthode à partir d’une version spécifique d’un modèle.

SELECT MODEL(<model_name>,<version_or_alias_name>)!<method_name>(...) FROM <table_name>;

L’exemple suivant utilise l’alias LAST pour appeler la dernière version d’un modèle.

SELECT MODEL(my_model,LAST)!predict(...) FROM my_table;

Transmission de paramètres en SQL¶

Si la signature du modèle comprend des paramètres définis avec ParamSpec, vous pouvez transmettre les valeurs des paramètres en tant qu’arguments supplémentaires après les colonnes d’entrée. Les paramètres peuvent être spécifiés par la position ou par le nom.

Lorsque vous utilisez des arguments positionnels, les paramètres peuvent être omis du côté droit, et les valeurs par défaut de la signature sont utilisées :

-- Pass all parameters positionally (temperature, then max_tokens)
SELECT MODEL(my_model, v1)!predict(input_text, 0.9, 512) FROM my_table;

-- Omit max_tokens from the right; its default value from the signature is used
SELECT MODEL(my_model, v1)!predict(input_text, 0.9) FROM my_table;

En cas d’utilisation d’arguments nommés, tous les arguments (y compris les colonnes d’entrée) doivent être spécifiés par leur nom. Cela vous permet de ne transmettre que des paramètres spécifiques, quelle que soit leur position :

SELECT MODEL(my_model, v1)!predict(
    input_text => input_text,
    max_tokens => 512
) FROM my_table;

Exécuter un modèle sur SPCS¶

Contrairement à l’exécution dans un entrepôt, les fonctions peuvent être appelées à partir d’un service en appelant service_name!method_name(...).

SELECT <mservice_name>!<method_name>(...) FROM <table_name>;

Les paramètres sont transmis de la même manière que pour les fonctions d’entrepôt, soit tous par leur position, soit tous par leur nom :

-- Positional
SELECT my_service!predict(input_text, 0.9, 512) FROM my_table;

-- Named arguments (all arguments must be named)
SELECT my_service!predict(input_text => input_text, max_tokens => 512) FROM my_table;

SQL¶

Les tables dynamiques offrent aux utilisateurs de Snowflake une capacité robuste leur permettant d’effectuer une inférence incrémentielle sur les données entrantes. Utilisez SQL pour définir une table dynamique qui fait référence au modèle et l’applique aux nouvelles lignes entrantes dans LOGINS_RAW :

CREATE OR REPLACE DYNAMIC TABLE logins_with_predictions
    WAREHOUSE = my_wh
    TARGET_LAG = '20 minutes'
    REFRESH_MODE = INCREMENTAL
    INITIALIZE = on_create
    COMMENT = 'Dynamic table with continuously updated model predictions'
AS
SELECT
    login_id,
    user_id,
    location,
    event_time,
    MODEL(ml.registry.mymodel)!predict(l.user_id, l.location) AS prediction_result
FROM logins_raw;

Snowpark Python¶

L’API de Snowpark Python vous permet d’accéder au registre des modèles par programmation et d’exécuter l’inférence directement sur le site DataFrames. Cette approche peut être plus souple et plus facile à maintenir, en particulier dans les environnements axés sur le code.

from snowflake.snowpark import Session
from snowflake.snowpark.functions import col
from snowflake.ml.registry import Registry

# Initialize the registry
reg = Registry(session=sp_session, database_name="ML", schema_name="REGISTRY")

# Retrieve the default model version from the registry
model = reg.get_model("MYMODEL")

# Load the source data
df_raw = sp_session.table("LOGINS_RAW")

# Run inference on the necessary features
predictions_df = model.run(df_raw.select("USER_ID", "LOCATION"))

# Join predictions back to the source data
joined_df = df_raw.join(predictions_df, on=["USER_ID", "LOCATION"])

# Create or replace a dynamic table from the joined DataFrame
joined_df.create_or_replace_dynamic_table(
    name="LOGINS_WITH_PREDICTIONS",
    warehouse="MY_WH",
    lag='20 minutes',
    refresh_mode='INCREMENTAL',
    initialize="ON_CREATE",
    comment="Dynamic table continuously updated with model predictions"
)

L’échantillon de code ci-dessus exécutera automatiquement l’inférence à l’aide de MYMODEL sur les nouvelles données contenues dans LOGINS_RAW toutes les 20 minutes.

Immuable vs volatile¶

Cette valeur incrémentielle est essentielle et nécessite que toutes les fonctions invoquées dans la définition de table dynamique soient désignées comme IMMUTABLE. Alors que les fonctions au sein d’un modèle standard sont généralement IMMUTABLE, les modèles personnalisés ont pour valeur par défaut VOLATILE. Si le modèle sous-jacent est connu comme étant immuable, il est essentiel de s’assurer que la fonction de modèle correspondante est explicitement marquée comme immuable lorsque le modèle est enregistré.