Model Serving no Snowpark Container Services¶

Criação de um pool de computação¶

O Snowpark Container Services (SPCS) executa imagens de contêiner em pools de computação. Se você ainda não tiver um pool de computação adequado, crie um da seguinte forma:

CREATE COMPUTE POOL IF NOT EXISTS mypool
    MIN_NODES = 2
    MAX_NODES = 4
    INSTANCE_FAMILY = 'CPU_X64_M'
    AUTO_RESUME = TRUE;

Consulte a tabela de nomes de família para obter uma lista de famílias de instâncias válidas.

Certifique-se de que a função que executará o modelo seja a proprietário do pool de computação ou tenha o privilégio USAGE ou OPERATE no pool.

Criação de um repositório de imagens¶

O Snowflake Model Serving cria uma imagem de contêiner com o modelo e suas dependências. Para armazenar esta imagem, você precisa de um repositório de imagens. Se você ainda não tiver uma, crie uma da seguinte forma:

CREATE IMAGE REPOSITORY IF NOT EXISTS my_inference_images

Se você for usar um repositório de imagens que não seja seu, certifique-se de que a função que criará a imagem do contêiner tenha os privilégios SERVICE READ, SERVICE WRITE, READ e WRITE no repositório. Conceda esses privilégios da seguinte forma:

GRANT WRITE ON IMAGE REPOSITORY my_inference_images TO ROLE myrole;
GRANT READ ON IMAGE REPOSITORY my_inference_images TO ROLE myrole;
GRANT SERVICE WRITE ON IMAGE REPOSITORY my_inference_images TO ROLE myrole;
GRANT SERVICE READ ON IMAGE REPOSITORY my_inference_images TO ROLE myrole;

Criação de uma integração de acesso externo¶

O processo de construção do contêiner precisa de acesso a vários sites da Internet para baixar dependências do conda-forge, PyPI ou de outros repositórios ou sites. Elas devem ser definidas como integrações de acesso externo (EAIs) pela função ACCOUNTADMIN.

Primeiro, crie as regras de rede necessárias. O acesso ao conda-forge é sempre necessário; se você não precisar de acesso a nenhum outro repositório de pacote, crie esta regra.

CREATE OR REPLACE NETWORK RULE conda_forge_rule
    MODE = 'EGRESS'
    TYPE = 'HOST_PORT'
    VALUE_LIST = ('conda.anaconda.org:443')

Se você precisar instalar pacotes de PyPI, crie também a seguinte regra. Todos os quatro hosts listados são necessários para o pip funcionar.

CREATE OR REPLACE NETWORK RULE pypi_rule
    MODE = 'EGRESS'
    TYPE = 'HOST_PORT'
    VALUE_LIST = ('pypi.org:443', 'pypi.python.org:443', 'pythonhosted.org:443',
                  'files.pythonhosted.org:443');

Se precisar de acesso a muitos outros sites, você pode criar uma regra que permita amplo acesso à Internet. Há pouco risco de segurança envolvido, desde que essa regra se aplique apenas à função usada para criar imagens de contêiner.

CREATE OR REPLACE NETWORK RULE all_access_rule
    MODE = 'EGRESS'
    TYPE = 'HOST_PORT'
    VALUE_LIST = ('0.0.0.0:443', '0.0.0.0:80')

Crie a integração de acesso externo usando uma ou mais de suas regras. No exemplo abaixo, usamos conda_forge_rule e pypi_rule definidas anteriormente, permitindo acesso apenas ao conda-forge e PyPI.

CREATE OR REPLACE EXTERNAL ACCESS INTEGRATION model_service_build_access
    ALLOWED_NETWORK_RULES = (conda_forge_rule, pypi_rule)
    ENABLED = true;

Por fim, conceda USAGE na EAI para função que criará as imagens de contêiner.

GRANT USAGE ON INTEGRATION model_service_build_access TO ROLE model_users;

Dependências e elegibilidade do modelo¶

As dependências de um modelo determinam se ele pode ser executado em um warehouse, em um serviço SPCS ou em ambos. É possível, se necessário, especificar dependências intencionalmente para tornar um modelo inelegível para execução em um desses ambientes.

O canal conda do Snowflake está disponível apenas em warehouses e é a única fonte de dependências de warehouse. Por padrão, as dependências do conda para modelos SPCS obtêm suas dependências do conda-forge.

Quando você registra em log uma versão do modelo, as dependências do conda do modelo são validadas em relação ao canal conda do Snowflake. Se todas as dependências do conda do modelo estiverem disponíveis, o modelo será considerado elegível para ser executado em um warehouse. Ele também pode ser elegível para executar em um serviço SPCS se todas as dependências estiverem disponíveis no conda-forge, embora isso não seja verificado até que você crie um serviço.

Modelos registrados em log com dependências PyPI devem ser executados no SPCS. Especificar pelo menos uma dependência PyPI é uma maneira de tornar um modelo inelegível para execução em um warehouse. Se seu modelo tiver apenas dependências conda, especifique pelo menos uma com um canal explícito (mesmo conda-forge), conforme mostrado no exemplo a seguir.

reg.log_model(
    model_name="my_model",
    version_name="v1",
    model=model,
    conda_dependencies=["conda-forge::scikit-learn"])

Para modelos implementados no SPCS, as dependências do conda, se houver, são instaladas primeiro e, em seguida, todas as dependências PyPI são instaladas no ambiente conda usando pip.

Criação de um serviço¶

Para criar um serviço SPCS e implementar o modelo nele, chame o método create_service da versão do modelo, conforme mostrado no exemplo a seguir.

mv.create_service(service_name="myservice",
              service_compute_pool="my_compute_pool",
              image_repo="mydb.myschema.my_image_repo",
              build_external_access_integration="my_external_access",
              ingress_enabled=True,
              gpu_requests=None)

A seguir estão os argumentos necessários para create_service:

• service_name: O nome do serviço a ser criado. Este nome deve ser único dentro da conta.

• service_compute_pool: O nome do pool de computação a ser usado para executar o modelo. O pool de computação já deve existir.

• image_repo: O nome do repositório de imagens a ser usado para armazenar a imagem do contêiner. O repositório já deve existir e o usuário deve ter privilégio SERVICE WRITE nele (ou OWNERSHIP).

• build_external_access_integration: O nome da integração de acesso externo a ser usado ao baixar dependências. Essa EA deve sempre permitir acesso ao conda-forge e também deve incluir hosts PyPI, se alguma dependência for instalada com pip.

• ingress_enabled: Se True, o serviço fica acessível por meio de um ponto de extremidade HTTP. Para criar o ponto de extremidade, o usuário deve ter o privilégio BIND SERVICE ENDPOINT.

• gpu_requests: Uma cadeia de caracteres especificando o número de GPUs. Para um modelo que pode ser executado em CPU ou GPU, este argumento determina se o modelo será executado em CPU ou em GPUs. Se o modelo for de um tipo conhecido que só pode ser executado em CPU (por exemplo, modelos scikit-learn), a criação da imagem falhará se GPUs forem solicitadas.

Este exemplo mostra apenas os argumentos necessários e mais comumente usados. Veja a referência da API ModelVersion para uma lista completa de argumentos.

Configuração de serviço padrão¶

Por padrão, um modelo alimentado por CPU usa o dobro do número de CPUs, mais um, de processos de trabalho. Modelos alimentados por GPU usam um processo de trabalho. É possível substituir isso usando o argumento num_workers.

Alguns modelos não são thread-safe. Portanto, o serviço carrega uma cópia separada do modelo para cada processo de trabalho. Isso pode resultar no esgotamento de recurso para modelos grandes.

Por padrão, o servidor de inferência é otimizado para executar uma única inferência por vez, visando fazer uso total de toda a CPU e memória de cada nó.

Comportamento de criação de imagem de contêiner¶

Por padrão, o Snowflake Model Serving cria a imagem do contêiner usando o mesmo pool de computação que será usado para executar o modelo. Este pool de computação de inferência provavelmente é muito poderoso para esta tarefa (por exemplo, GPUs não são usadas na criação de imagens de contêiner). Na maioria dos casos, isso não terá um impacto significativo nos custos de computação, mas se for uma preocupação, você pode escolher um pool de computação menos potente para criar imagens especificando o argumento image_build_compute_pool.

é uma função idempotente create_service. Chamá-la várias vezes não aciona a criação da imagem a cada vez. No entanto, as imagens de contêiner podem ser reconstruídas com base em atualizações no serviço de inferência, incluindo correções de vulnerabilidades em pacotes dependentes. Quando isso acontece, create_service aciona automaticamente a reconstrução da imagem Portanto, você não deve desabilitar a integração de acesso externo após a primeira chamada para create_service.

SQL¶

O Snowflake Model Serving cria funções de serviço ao implementar um modelo no SPCS. Essas funções servem como uma ponte de SQL para o modelo em execução no pool de computação do SPCS. Uma função de serviço é criada para cada método do modelo, e elas são nomeadas como model_name_method_name. Por exemplo, se o modelo tiver dois métodos nomeados PREDICT e EXPLAIN e estiver sendo implementado em um serviço nomeado MY_SERVICE, as funções de serviço resultantes serão MY_SERVICE_PREDICT e MY_SERVICE_EXPLAIN.

A chamada das funções de serviço de modelo em SQL é feita usando um código como o seguinte:

SELECT MY_SERVICE_PREDICT(...) FROM ...;

Python¶

Chame os métodos de um serviço usando o método run de um objeto de versão do modelo, incluindo o argumento service_name para especificar o serviço onde o método será executado. Por exemplo:

service_prediction = mv.run(
    test_df,
    function_name="predict",
    service_name="my_service")

Se você não incluir o argumento service_name, o modelo será executado em um warehouse.

Ponto de extremidade HTTP¶

Após implantar um serviço com entrada habilitada, um novo ponto de extremidade HTTP fica disponível para o serviço. É possível encontrar o ponto de extremidade usando o comando ShOW ENDPOINTS IN SERVICE.

SHOW ENDPOINTS IN SERVICE my_service;

Observe que a coluna ingress_url deve se parecer com random_str-account-id.snowflakecomputing.app.

Para saber mais sobre como usar esse ponto de extremidade, consulte o tutorial do SPCS Criação de um serviço Snowpark Container Services e o tópico Como usar um serviço de fora do Snowflake no Guia do desenvolvedor. Para obter mais informações sobre o formato de dados necessário, consulte Formatos de dados de entrada e saída de serviços remotos.

Consulte Implementação de um transformador de frase Hugging Face para inferência com alimentada por GPU para um exemplo de uso de um ponto de extremidade HTTP do servidor modelo.

Suspensão de serviços¶

Quando terminar de usar um modelo, ou se não houver uso, é uma boa prática suspender o serviço para economizar custos. É possível fazer isso usando o comando ALTER SERVICE.

ALTER SERVICE my_service SUSPEND;

O serviço é reiniciado automaticamente quando recebe uma solicitação, sujeito a agendamento e atrasos na inicialização. O atraso no agendamento depende da disponibilidade do pool de computação, e o atraso na inicialização depende do tamanho do modelo.

Exclusão de modelos¶

É possível gerenciar modelos e versões de modelo normalmente com a interface SQL ou a API Python, com a restrição de que um modelo ou versão de modelo que esteja sendo usado por um serviço (esteja em execução ou suspenso) não pode ser descartado (excluído). Para descartar um modelo ou versão de modelo, descarte o serviço primeiro.

Implementando um modelo XGBoost para inferência alimentada por CPU¶

THe código a seguir ilustra as principais chaves na implementação de um modelo XGBoost para inferência no SPCS, e depois usa o modelo implementado para inferência. Um notebook para este exemplo está disponível.

from snowflake.ml.registry import registry
from snowflake.ml.utils.connection_params import SnowflakeLoginOptions
from snowflake.snowpark import Session
from snowflake.ml.modeling.xgboost import XGBRegressor

# your model training code here output of which is a trained xgb_model

# Open model registry
reg = registry.Registry(session=session, database_name='my_registry_db', schema_name='my_registry_schema')

# Log the model in Snowflake Model Registry
model_ref = reg.log_model(
    model_name="my_xgb_forecasting_model",
    version_name="v1",
    model=xgb_model,
    conda_dependencies=["scikit-learn","xgboost"],
    sample_input_data=train,
    comment="XGBoost model for forecasting customer demand"
)

# Deploy the model to SPCS
reg_model.create_service(
    service_name="ForecastModelServicev1",
    service_compute_pool="my_cpu_pool",
    image_repo="my_db.data.my_images",
    build_external_access_integration="my_egress_access_integration_for_conda_pip",
    ingress_enabled=True)

# See all services running a model
reg_model.list_services()

# Run on SPCS
reg_model.run(input_data, function_name="predict", service_name="ForecastModelServicev1")

# Delete the service
reg_model.delete_service("ForecastModelServicev1")

Implementação de um transformador de frase Hugging Face para inferência com alimentada por GPU¶

Este código treina e implementa um transformador de frase Hugging Face, incluindo um ponto de extremidade HTTP.

from snowflake.ml.registry import registry
from snowflake.ml.utils.connection_params import SnowflakeLoginOptions
from snowflake.snowpark import Session
from sentence_transformers import SentenceTransformer

session = Session.builder.configs(SnowflakeLoginOptions("connection_name")).create()
reg = registry.Registry(session=session, database_name='my_registry_db', schema_name='my_registry_schema')

# Take an example sentence transformer from HF
embed_model = SentenceTransformer('sentence-transformers/all-MiniLM-L6-v2')

# Have some sample input data
input_data = [
    "This is the first sentence.",
    "Here's another sentence for testing.",
    "The quick brown fox jumps over the lazy dog.",
    "I love coding and programming.",
    "Machine learning is an exciting field.",
    "Python is a popular programming language.",
    "I enjoy working with data.",
    "Deep learning models are powerful.",
    "Natural language processing is fascinating.",
    "I want to improve my NLP skills.",
]

# Log the model with pip dependencies
pip_model = reg.log_model(
    embed_model,
    model_name="sentence_transformer_minilm",
    version_name='pip',
    sample_input_data=input_data,  # Needed for determining signature of the model
pip_requirements=["sentence-transformers", "torch", "transformers"], # If you want to run this model in the Warehouse, you can use conda_dependencies instead
)

# Force Snowflake to not try to check warehouse
conda_forge_model = reg.log_model(
    embed_model,
    model_name="sentence_transformer_minilm",
    version_name='conda_forge_force',
    sample_input_data=input_data,
    # setting any package from conda-forge is sufficient to know that it can't be run in warehouse
    conda_dependencies=["sentence-transformers", "conda-forge::pytorch", "transformers"]
)

# Deploy the model to SPCS
pip_model.create_service(
    service_name="my_minilm_service",
    service_compute_pool="my_gpu_pool",  # Using GPU_NV_S - smallest GPU node that can run the model
    image_repo="my_db.data.my_images",
    ingress_enabled=True,
    build_external_access_integration="my_egress_access_integration_for_conda_pip",
    gpu_requests="1", # Model fits in GPU memory; only needed for GPU pool
    max_instances=4, # 4 instances were able to run 10M inferences from an XS warehouse
)

# See all services running a model
pip_model.list_services()

# Run on SPCS
pip_model.run(input_data, function_name="encode", service_name="my_minilm_service")

# Delete the service
pip_model.delete_service("my_minilm_service")

Como esse modelo tem a entrada habilitada, é possível chamar seu ponto de extremidade HTTP da seguinte forma.

import json
from pprint import pprint
import requests
import snowflake.connector

# Generate right header
# Note that, ideally user should use key-pair authentication for API access (see this).
def initiate_snowflake_connection():
    connection_parameters = SnowflakeLoginOptions("connection_name")
    connection_parameters["session_parameters"] = {"PYTHON_CONNECTOR_QUERY_RESULT_FORMAT": "json"}
    snowflake_conn = snowflake.connector.connect(**connection_parameters)
    return snowflake_conn

def get_headers(snowflake_conn):
    token = snowflake_conn._rest._token_request('ISSUE')
    headers = {'Authorization': f'Snowflake Token=\"{token["data"]["sessionToken"]}\"'}
    return headers

headers = get_headers(initiate_snowflake_connection())

# Put the endpoint url with method name
URL='https://<random_str>-<account>.snowflakecomputing.app/encode'

# Prepare data to be sent
data = {
    'data': []
}
for idx, x in enumerate(input_data):
    data['data'].append([idx, x])

# Send over HTTP
def send_request(data: dict):
    output = requests.post(URL, json=data, headers=headers)
    assert (output.status_code == 200), f"Failed to get response from the service. Status code: {output.status_code}"
    return output.content

# Test
results = send_request(data=data)
pprint(json.loads(results))

Implementação de um modelo PyTorch para inferência alimentada por GPU¶

Consulte este guia de início rápido para um exemplo de treinamento e implementação de um modelo de recomendação de aprendizado profundo PyTorch (DLRM) no SPCS para inferência com GPU.

Monitoramento de implementações SPCS¶

É possível monitorar a implementação inspecionando os serviços que estão sendo iniciados usando a seguinte consulta SQL.

SHOW SERVICES IN COMPUTE POOL my_compute_pool;

Dois trabalhos são lançados:

• MODEL_BUILD_xxxxx: Os caracteres finais do nome são randomizados para evitar conflitos de nomes. Este trabalho cria a imagem e termina depois que ela é criada. Se uma imagem já existir, o trabalho será ignorado.

  Os logs são úteis para depurar conflitos em dependências de pacote ou problemas de integração de acesso externo que estão impedindo o acesso a repositórios de pacote, entre outros problemas potenciais. Para ver os logs deste trabalho, execute o SQL abaixo, certificando-se de usar os mesmos caracteres finais:

  CALL SYSTEM$GET_SERVICE_LOGS('MODEL_BUILD_xxxxx', 0, 'model-build');
  

  Copy

• MYSERVICE: O nome do serviço conforme especificado na chamada para create_service. Este trabalho é iniciado se o trabalho de MODEL_BUILD for bem-sucedido ou ignorado. Para ver os logs deste trabalho, execute o SQL abaixo:

  CALL SYSTEM$GET_SERVICE_LOGS('MYSERVICE', 0, 'model-inference');
  

  Copy

Conflitos de pacotes¶

Dois sistemas determinam os pacotes instalados no contêiner de serviço: o próprio modelo e o servidor de inferência. Para minimizar conflitos com as dependências de seu modelo, o servidor de inferência requer apenas os seguintes pacotes:

• gunicorn<24.0.0

• starlette<1.0.0

• uvicorn-standard<1.0.0

Certifique-se de que as dependências do modelo, juntamente com as dependências acima, possam ser resolvidas por pip ou conda, independentemente da que você escolher.

Se um modelo tiver conda_dependencies e pip_requirements definidos, eles serão instalados da seguinte forma via conda:

Canais:

• conda-forge

• nodefaults

Dependências:

• all_conda_packages

• pip:

  • all_pip_packages

Por padrão, o Snowflake usa o conda-forge para pacotes Anaconda, já que o canal conda do Snowflake está disponível em warehouses, e o canal defaults exige que os usuários aceitem os termos de uso do Anaconda. Para especificar pacotes do canal padrão, inclua o nome do pacote: defaults::pkg_name.

Serviço sem memória¶

Alguns modelos não são seguros para threads, então o Snowflake carrega uma cópia do modelo na memória para cada processo de trabalho. Isso pode causar condições de falta de memória para modelos grandes com um número maior de trabalhadores. Tente reduzir num_workers.

Desempenho de consulta insatisfatório¶

Normalmente, a inferência é limitada pelo número de instâncias no serviço de inferência. Tente passar um valor mais alto para max_instances ao implementar o modelo.

Não é possível alterar a especificação do serviço¶

As especificações da compilação de modelo e serviços de inferência não podem ser alteradas usando ALTER SERVICE. Somente é possível alterar atributos como TAG, MIN_INSTANCES e assim por diante.

No entanto, como a imagem é publicada no repositório de imagens, você pode copiar a especificação, modificá-la e criar um novo serviço a partir dela, que pode ser iniciado manualmente.