Crea pacchetti e distribuisci facilmente ML e LLM classici con Amazon SageMaker, parte 1: Miglioramenti di PySDK | Servizi Web di Amazon

Amazon Sage Maker è un servizio completamente gestito che consente a sviluppatori e data scientist di creare, addestrare e distribuire in modo rapido e semplice modelli di machine learning (ML) su qualsiasi scala. SageMaker semplifica la distribuzione dei modelli in produzione direttamente tramite chiamate API al servizio. I modelli sono confezionati in contenitori per distribuzioni robuste e scalabili. Sebbene fornisca vari punti di ingresso come SageMaker Python SDK, AWS SDK, la console SageMaker e Amazon Sage Maker Studio notebook per semplificare il processo di formazione e distribuzione di modelli ML su larga scala, i clienti sono ancora alla ricerca di modi migliori per distribuire i propri modelli per i test sul campo da gioco e per ottimizzare le distribuzioni di produzione.

Stiamo lanciando due nuovi modi per semplificare il processo di confezionamento e distribuzione dei modelli utilizzando SageMaker.

In questo post presentiamo il nuovo SageMaker Python SDK ModelBuilder esperienza, che mira a ridurre al minimo la curva di apprendimento per i nuovi utenti SageMaker come i data scientist, aiutando allo stesso tempo gli ingegneri MLOps esperti a massimizzare l'utilizzo dei servizi di hosting SageMaker. Riduce la complessità della configurazione iniziale e della distribuzione e fornisce indicazioni sulle migliori pratiche per sfruttare tutte le funzionalità di SageMaker. Forniamo informazioni dettagliate ed esempi GitHub per questa nuova funzionalità SageMaker.

L'altro nuovo lancio consiste nell'utilizzare la nuova esperienza di distribuzione interattiva in SageMaker Studio. Ne discuteremo nella Parte 2.

La distribuzione di modelli su un endpoint SageMaker comporta una serie di passaggi per preparare il modello per essere ospitato su un endpoint SageMaker. Ciò implica ottenere gli artefatti del modello nel formato e nella struttura corretti, creare codice di inferenza e specificare dettagli essenziali come l'URL dell'immagine del modello, Servizio di archiviazione semplice Amazon (Amazon S3) posizione degli artefatti del modello, passaggi di serializzazione e deserializzazione e necessari Gestione dell'identità e dell'accesso di AWS (IAM) per facilitare le autorizzazioni di accesso appropriate. Successivamente, la configurazione di un endpoint richiede la determinazione del tipo di inferenza e la configurazione dei rispettivi parametri come tipi di istanze, conteggi e distribuzione del traffico tra le varianti del modello.

Per aiutare ulteriormente i nostri clienti quando utilizzano l'hosting SageMaker, abbiamo introdotto il nuovo ModelBuilder classe nell'SDK Python di SageMaker, che offre i seguenti vantaggi principali durante la distribuzione di modelli sugli endpoint SageMaker:

• Unifica l'esperienza di distribuzione tra framework – La nuova esperienza fornisce un flusso di lavoro coerente per la distribuzione di modelli creati utilizzando framework diversi come PyTorch, TensorFlow e XGBoost. Ciò semplifica il processo di distribuzione.
• Automatizza la distribuzione del modello – Attività come la selezione dei contenitori appropriati, l'acquisizione delle dipendenze e la gestione della serializzazione/deserializzazione sono automatizzate, riducendo lo sforzo manuale richiesto per la distribuzione.
• Fornisce una transizione graduale dall'endpoint locale all'endpoint ospitato da SageMaker – Con modifiche minime al codice, i modelli possono essere facilmente trasferiti dai test locali alla distribuzione su un endpoint SageMaker. I registri in tempo reale semplificano il debug.

Nel complesso, SageMaker ModelBuilder semplifica e ottimizza il processo di confezionamento del modello per l'inferenza di SageMaker gestendo i dettagli di basso livello e fornisce strumenti per test, convalida e ottimizzazione degli endpoint. Ciò migliora la produttività degli sviluppatori e riduce gli errori.

Nelle sezioni seguenti, approfondiamo i dettagli di questa nuova funzionalità. Discuteremo anche come distribuire modelli sull'hosting SageMaker utilizzando ModelBuilder, il che semplifica il processo. Quindi ti guideremo attraverso alcuni esempi di diversi framework per distribuire sia i modelli ML tradizionali che i modelli di base che alimentano i casi d'uso dell'intelligenza artificiale generativa.

Conoscere SageMaker ModelBuilder

Il nuovo ModelBuilder è una classe Python incentrata sull'acquisizione di modelli ML creati utilizzando framework, come XGBoost o PyTorch, e sulla loro conversione in modelli pronti per la distribuzione su SageMaker. ModelBuilder fornisce un build() funzione, che genera gli artefatti in base al server modello, e a deploy() funzione per la distribuzione locale o su un endpoint SageMaker. L'introduzione di questa funzionalità semplifica l'integrazione dei modelli con l'ambiente SageMaker, ottimizzandoli per prestazioni e scalabilità. Il diagramma seguente mostra come ModelBuilder funziona ad alto livello.

Classe ModelBuilder

I Costruttore di modelli class fornisce diverse opzioni per la personalizzazione. Tuttavia, per distribuire il modello framework, il costruttore del modello si aspetta solo il modello, l'input, l'output e il ruolo:

class ModelBuilder( model, # model id or model object role_arn, # IAM role schema_builder, # defines the input and output mode, # select between local deployment and depoy to SageMaker Endpoints ...
)

SchemaBuilder

I SchemaBuilder La classe ti consente di definire l'input e l'output per il tuo endpoint. Consente al costruttore dello schema di generare le funzioni di marshalling corrispondenti per serializzare e deserializzare l'input e l'output. Il seguente file di classe fornisce tutte le opzioni per la personalizzazione:

class SchemaBuilder( sample_input: Any, sample_output: Any, input_translator: CustomPayloadTranslator = None, output_translator: CustomPayloadTranslator = None
)

Tuttavia, nella maggior parte dei casi, funzionerebbero solo l'input e l'output di esempio. Per esempio:

input = "How is the demo going?"
output = "Comment la démo va-t-elle?"
schema = SchemaBuilder(input, output)

Fornendo input e output di esempio, SchemaBuilder può determinare automaticamente le trasformazioni necessarie, rendendo il processo di integrazione più semplice. Per i casi d'uso più avanzati, esiste la flessibilità di fornire funzioni di traduzione personalizzate sia per l'input che per l'output, garantendo che anche strutture di dati più complesse possano essere gestite in modo efficiente. Lo dimostreremo nelle sezioni seguenti distribuendo diversi modelli con vari framework utilizzando ModelBuilder.

Esperienza in modalità locale

In questo esempio, usiamo ModelBuilder per distribuire il modello XGBoost localmente. Puoi utilizzare la modalità per passare dal test locale alla distribuzione su un endpoint SageMaker. Per prima cosa addestriamo il modello XGBoost (localmente o in SageMaker) e memorizziamo gli artefatti del modello nella directory di lavoro:

# Train the model
model = XGBClassifier()
model.fit(X_train, y_train)
model.save_model(model_dir + "/my_model.xgb")

Quindi creiamo un oggetto ModelBuilder passando l'oggetto modello vero e proprio, the SchemaBuilder che utilizza gli oggetti di input e output di test di esempio (gli stessi input e output che abbiamo utilizzato durante il training e il test del modello) per dedurre la serializzazione necessaria. Nota che usiamo Mode.LOCAL_CONTAINER per specificare una distribuzione locale. Successivamente, chiamiamo il costruire funzione per identificare automaticamente l'immagine del contenitore del framework supportato e per eseguire la scansione delle dipendenze. Vedere il seguente codice:

model_builder_local = ModelBuilder( model=model, schema_builder=SchemaBuilder(X_test, y_pred), role_arn=execution_role, mode=Mode.LOCAL_CONTAINER
)
xgb_local_builder = model_builder_local.build()

Infine, possiamo chiamare il deploy funzione nell'oggetto del modello, che fornisce anche la registrazione in tempo reale per un debug più semplice. Non è necessario specificare il tipo o il numero di istanze perché il modello verrà distribuito localmente. Se hai fornito questi parametri, verranno ignorati. Questa funzione restituirà l'oggetto predittore che possiamo utilizzare per fare previsioni con i dati del test:

# note: all the serialization and deserialization is handled by the model builder.
predictor_local = xgb_local_builder.deploy(
# instance_type='ml.c5.xlarge',
# initial_instance_count=1
) # Make prediction for test data. predictor_local.predict(X_test)

Facoltativamente, è anche possibile controllare il caricamento del modello e la pre-elaborazione e post-elaborazione utilizzando InferenceSpec. Forniamo maggiori dettagli più avanti in questo post. Utilizzando LOCAL_CONTAINER è un ottimo modo per testare il tuo script localmente prima della distribuzione su un endpoint SageMaker.

Fare riferimento a costruttore-di-modelli-xgboost.ipynb esempio per testare la distribuzione sia localmente che su un endpoint SageMaker utilizzando ModelBuilder.

Distribuisci modelli tradizionali agli endpoint SageMaker

Negli esempi seguenti, mostriamo come utilizzare ModelBuilder per implementare modelli ML tradizionali.

Modelli XGBoost

Analogamente alla sezione precedente, puoi distribuire un modello XGBoost su un endpoint SageMaker modificando il file mode parametro durante la creazione del file ModelBuilder oggetto:

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(sample_input=sample_input, sample_output=sample_output), role_arn=execution_role, mode=Mode.SAGEMAKER_ENDPOINT
)
xgb_builder = model_builder.build()
predictor = xgb_builder.deploy( instance_type='ml.c5.xlarge', initial_instance_count=1
)

Tieni presente che durante la distribuzione sugli endpoint SageMaker, devi specificare il tipo di istanza e il numero di istanze quando chiami il file deploy funzione.

Fare riferimento a costruttore-di-modelli-xgboost.ipynb esempio per distribuire un modello XGBoost.

Modelli Tritone

Puoi usare ModelBuilder per servire i modelli PyTorch Server di inferenza Triton. Per questo è necessario specificare il file model_server parametro come ModelServer.TRITON, passa un modello e ottieni un SchemaBuilder oggetto, che richiede input e output campione dal modello. ModelBuilder si prenderà cura di tutto il resto per te.

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(sample_input=sample_input, sample_output=sample_output), role_arn=execution_role, model_server=ModelServer.TRITON, mode=Mode.SAGEMAKER_ENDPOINT
) triton_builder = model_builder.build() predictor = triton_builder.deploy( instance_type='ml.g4dn.xlarge', initial_instance_count=1
)

Fare riferimento a costruttore-di-modelli-triton.ipynb per schierare un modello con Triton.

Modelli di volti abbracciati

In questo esempio, ti mostriamo come distribuire un modello di trasformatore pre-addestrato fornito da Hugging Face a SageMaker. Vogliamo usare la faccia che abbraccia pipeline per caricare il modello, quindi creiamo una specifica di inferenza personalizzata per ModelBuilder:

# custom inference spec with hugging face pipeline
class MyInferenceSpec(InferenceSpec): def load(self, model_dir: str): return pipeline("translation_en_to_fr", model="t5-small") def invoke(self, input, model): return model(input) inf_spec = MyInferenceSpec()

Definiamo anche l'input e l'output del carico di lavoro di inferenza definendo il SchemaBuilder oggetto basato sull'input e sull'output del modello:

schema = SchemaBuilder(value,output)

Quindi creiamo il ModelBuilder oggetto e distribuisci il modello su un endpoint SageMaker seguendo la stessa logica mostrata nell'altro esempio:

builder = ModelBuilder( inference_spec=inf_spec, mode=Mode.SAGEMAKER_ENDPOINT, # you can change it to Mode.LOCAL_CONTAINER for local testing schema_builder=schema, image_uri=image,
)
model = builder.build( role_arn=execution_role, sagemaker_session=sagemaker_session,
)
predictor = model.deploy( initial_instance_count=1, instance_type='ml.g5.2xlarge'
)

Fare riferimento a model-builder-huggingface.ipynb per distribuire un modello di pipeline Hugging Face.

Distribuisci modelli di base agli endpoint SageMaker

Negli esempi seguenti, mostriamo come utilizzare ModelBuilder per implementare modelli di base. Proprio come per i modelli menzionati in precedenza, tutto ciò che serve è l'ID del modello.

Hub per il viso che abbraccia

Se desideri distribuire un modello di base da Hub per il viso che abbraccia, tutto ciò che devi fare è trasmettere l'ID del modello pre-addestrato. Ad esempio, il seguente frammento di codice distribuisce il file metallo-llama/Llama-2-7b-hf modellare localmente. È possibile modificare la modalità in Mode.SAGEMAKER_ENDPOINT per eseguire la distribuzione sugli endpoint SageMaker.

model_builder = ModelBuilder( model="meta-llama/Llama-2-7b-hf", schema_builder=SchemaBuilder(sample_input, sample_output), model_path="/home/ec2-user/SageMaker/LoadTestResources/meta-llama2-7b", #local path where artifacts will be saved mode=Mode.LOCAL_CONTAINER, env_vars={ # Llama 2 is a gated model and requires a Hugging Face Hub token. "HUGGING_FACE_HUB_TOKEN": "<YourHuggingFaceToken>" }
)
model = model_builder.build()
local_predictor = model.deploy()

Per i modelli con gate su Hugging Face Hub, è necessario richiedere l'accesso tramite Hugging Face Hub e utilizzare la chiave associata passandola come variabile di ambiente HUGGING_FACE_HUB_TOKEN. Alcuni modelli Hugging Face potrebbero richiedere l'attendibilità del codice remoto. Può essere impostato anche come variabile di ambiente utilizzando HF_TRUST_REMOTE_CODE. Di default, ModelBuilder utilizzerà un'inferenza per la generazione del testo del volto abbracciato (TGI) contenitore come contenitore sottostante per i modelli Hugging Face. Se desideri utilizzare AWS Large Model Inference (contenitori LMI)., puoi impostare il file model_server parametro come ModelServer.DJL_SERVING quando configuri il ModelBuilder oggetto.

Una caratteristica ordinata di ModelBuilder è la possibilità di eseguire l'ottimizzazione locale dei parametri del contenitore quando si utilizza LOCAL_CONTAINER modalità. Questa funzionalità può essere utilizzata semplicemente eseguendo tuned_model = model.tune().

Fare riferimento a demo-model-builder-huggingface-llama2.ipynb per implementare un modello Hugging Face Hub.

SageMaker JumpStart

JumpStart di Amazon SageMaker offre anche una serie di modelli di fondazione pre-addestrati. Proprio come il processo di distribuzione di un modello da Hugging Face Hub, è richiesto l'ID del modello. La distribuzione di un modello JumpStart SageMaker su un endpoint SageMaker è semplice come eseguire il codice seguente:

model_builder = ModelBuilder( model="huggingface-llm-falcon-7b-bf16", schema_builder=SchemaBuilder(sample_input, sample_output), role_arn=execution_role
) sm_ep_model = model_builder.build() predictor = sm_ep_model.deploy()

Per tutti gli ID modello SageMaker JumpStart disponibili, fare riferimento a Algoritmi incorporati con tabella modello pre-addestrata. Fare riferimento a costruttore-di-modelli-jumpstart-falcon.ipynb per distribuire un modello SageMaker JumpStart.

Componente di inferenza

ModelBulder consente di utilizzare la nuova funzionalità del componente di inferenza in SageMaker per distribuire modelli. Per ulteriori informazioni sui componenti di inferenza, vedere Riduci i costi di implementazione del modello in media del 50% utilizzando le funzionalità più recenti di SageMaker. È possibile utilizzare i componenti di inferenza per la distribuzione con ModelBuilder specificando endpoint_type=EndpointType.INFERENCE_COMPONENT_BASED nel deploy() metodo. Puoi anche usare il tune() metodo, che recupera il numero ottimale di acceleratori e lo modifica se necessario.

resource_requirements = ResourceRequirements( requests={ "num_accelerators": 4, "memory": 1024, "copies": 1, }, limits={},
) goldfinch_predictor_2 = model_2.deploy( mode=Mode.SAGEMAKER_ENDPOINT, endpoint_type=EndpointType.INFERENCE_COMPONENT_BASED, ... )

Fare riferimento a componente-inferenza-costruttore-modello.ipynb per distribuire un modello come componente di inferenza.

Personalizza la classe ModelBuilder

I ModelBuilder class consente di personalizzare il caricamento del modello utilizzando InferenceSpec.

Inoltre, è possibile controllare la serializzazione e la deserializzazione del payload e delle risposte e personalizzare la preelaborazione e la postelaborazione utilizzando CustomPayloadTranslator. Inoltre, quando hai bisogno di estendere i nostri contenitori predefiniti per la distribuzione del modello su SageMaker, puoi utilizzare ModelBuilder per gestire il processo di confezionamento del modello. Nella sezione seguente forniamo maggiori dettagli su queste funzionalità.

Specifica di inferenza

Specifica di inferenza offre un ulteriore livello di personalizzazione. Ti consente di definire come viene caricato il modello e come gestirà le richieste di inferenza in entrata. Attraverso InferenceSpec, puoi definire procedure di caricamento personalizzate per i tuoi modelli, ignorando i meccanismi di caricamento predefiniti. Questa flessibilità è particolarmente vantaggiosa quando si lavora con modelli non standard o pipeline di inferenza personalizzate. Il metodo di chiamata può essere personalizzato, offrendoti la possibilità di personalizzare il modo in cui il modello elabora le richieste in entrata (preelaborazione e postelaborazione). Questa personalizzazione può essere essenziale per garantire che il processo di inferenza sia in linea con le esigenze specifiche del modello. Vedere il seguente codice:

class InferenceSpec(abc.ABC): @abc.abstractmethod def load(self, model_dir: str): pass @abc.abstractmethod def invoke(self, input_object: object, model: object): pass

Il codice seguente mostra un esempio di utilizzo di questa classe:

class MyInferenceSpec(InferenceSpec): def load(self, model_dir: str): return // model object def invoke(self, input, model): return model(input)

CustomPayloadTranslator

Quando si richiamano gli endpoint SageMaker, i dati vengono inviati tramite payload HTTP con diversi tipi MIME. Ad esempio, un'immagine inviata all'endpoint per l'inferenza deve essere convertita in byte sul lato client e inviata tramite il payload HTTP all'endpoint. Quando l'endpoint riceve il carico utile, deve deserializzare la stringa di byte riportandola al tipo di dati previsto dal modello (noto anche come deserializzazione lato server). Una volta che il modello ha completato la previsione, i risultati devono essere serializzati in byte che possono essere rinviati tramite il payload HTTP all'utente o al client. Quando il client riceve i dati in byte di risposta, deve eseguire la deserializzazione lato client per riconvertire i dati in byte nel formato dati previsto, ad esempio JSON. Al minimo, è necessario convertire i dati per quanto segue (come numerato nel diagramma seguente):

1. Serializzazione della richiesta di inferenza (gestita dal client)
2. Deserializzazione della richiesta di inferenza (gestita dal server o dall'algoritmo)
3. Invocare il modello contro il carico utile
4. Invio del payload della risposta
5. Serializzazione della risposta all'inferenza (gestita dal server o dall'algoritmo)
6. Deserializzazione della risposta di inferenza (gestita dal client)

Il diagramma seguente mostra il processo di serializzazione e deserializzazione durante il processo di chiamata.

Nel seguente frammento di codice, mostriamo un esempio di CustomPayloadTranslator quando è necessaria un'ulteriore personalizzazione per gestire sia la serializzazione che la deserializzazione rispettivamente sul lato client e server:

from sagemaker.serve import CustomPayloadTranslator # request translator
class MyRequestTranslator(CustomPayloadTranslator): # This function converts the payload to bytes - happens on client side def serialize_payload_to_bytes(self, payload: object) -> bytes: # converts the input payload to bytes ... ... return //return object as bytes # This function converts the bytes to payload - happens on server side def deserialize_payload_from_stream(self, stream) -> object: # convert bytes to in-memory object ... ... return //return in-memory object # response translator class MyResponseTranslator(CustomPayloadTranslator): # This function converts the payload to bytes - happens on server side def serialize_payload_to_bytes(self, payload: object) -> bytes: # converts the response payload to bytes ... ... return //return object as bytes # This function converts the bytes to payload - happens on client side def deserialize_payload_from_stream(self, stream) -> object: # convert bytes to in-memory object ... ... return //return in-memory object

Nel demo-model-builder-pytorch.ipynb notebook, dimostriamo come distribuire facilmente un modello PyTorch su un endpoint SageMaker utilizzando ModelBuilder con la CustomPayloadTranslator e la InferenceSpec classe.

Modello di fase per la distribuzione

Se si desidera organizzare il modello per l'inferenza o nel registro del modello, è possibile utilizzare model.create() or model.register(). Il modello abilitato viene creato nel servizio ed è quindi possibile distribuirlo in un secondo momento. Vedere il seguente codice:

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(X_test, y_pred), role_arn=execution_role, )
deployable_model = model_builder.build() deployable_model.create() # deployable_model.register() for model registry

Utilizza contenitori personalizzati

SageMaker fornisce immagini Docker precostruite per i suoi algoritmi integrati e i framework di deep learning supportati utilizzati per l'addestramento e l'inferenza. Se un contenitore SageMaker predefinito non soddisfa tutti i tuoi requisiti, puoi estendere l'immagine esistente per soddisfare le tue esigenze. Estendendo un'immagine predefinita, puoi utilizzare le librerie e le impostazioni di deep learning incluse senza dover creare un'immagine da zero. Per ulteriori dettagli su come estendere i contenitori predefiniti, fare riferimento al documento SageMaker. ModelBuilder supporta i casi d'uso in cui si portano i propri contenitori estesi dai nostri contenitori Docker predefiniti.

Per utilizzare la tua immagine del contenitore in questo caso, devi impostare i campi image_uri ed model_server quando si definisce ModelBuilder:

model_builder = ModelBuilder( model=model, # Pass in the actual model object. its "predict" method will be invoked in the endpoint. schema_builder=SchemaBuilder(X_test, y_pred), # Pass in a "SchemaBuilder" which will use the sample test input and output objects to infer the serialization needed. role_arn=execution_role, image_uri=image_uri, # REQUIRED FOR BYOC: Passing in image hosted in personal ECR Repo model_server=ModelServer.TORCHSERVE, # REQUIRED FOR BYOC: Passing in model server of choice mode=Mode.SAGEMAKER_ENDPOINT, dependencies={"auto": True, "custom": ["protobuf==3.20.2"]}
)

Qui, il image_uri sarà l'ARN dell'immagine del contenitore archiviato nel tuo account Registro dei contenitori Amazon Elastic (Amazon ECR). Un esempio è mostrato come segue:

# Pulled the xgboost:1.7-1 DLC and pushed to personal ECR repo
image_uri = "<your_account_id>.dkr.ecr.us-west-2.amazonaws.com/my-byoc:xgb"

Quando il image_uri è impostato, durante il ModelBuilder processo di compilazione, salterà il rilevamento automatico dell'immagine poiché viene fornito l'URI dell'immagine. Se model_server non è impostato in ModelBuilder, riceverai un messaggio di errore di convalida, ad esempio:

ValueError: Model_server must be set when image_uri is set. Supported model servers: {<ModelServer.TRITON: 5>, <ModelServer.DJL_SERVING: 4>, <ModelServer.TORCHSERVE: 1>}

A partire dalla pubblicazione di questo post, ModelBuilder supporta il trasporto dei propri contenitori estesi dal ns immagini di contenitori DLC precostruiti o contenitori costruiti con server modello simili Libreria Deep Java (DJL), Inferenza sulla generazione di testo (TGI), Torcia Serviree Server di inferenza Triton.

Dipendenze personalizzate

Durante la corsa ModelBuilder.build(), per impostazione predefinita cattura automaticamente il tuo ambiente Python in un file requirements.txt file e installa la stessa dipendenza nel contenitore. Tuttavia, a volte il tuo ambiente Python locale entrerà in conflitto con l'ambiente nel contenitore. ModelBuilder fornisce un modo semplice per modificare le dipendenze acquisite per risolvere tali conflitti di dipendenza consentendoti di fornire le tue configurazioni personalizzate in ModelBuilder. Tieni presente che questo è solo per TorchServe e Triton InferenceSpec. Ad esempio, puoi specificare le dipendenze dei parametri di input, che è un dizionario Python, in ModelBuilder come segue:

dependency_config = { "auto" = True, "requirements" = "/path/to/your/requirements.txt" "custom" = ["module>=1.2.3,<1.5", "boto3==1.16.*", "some_module@http://some/url"]
} ModelBuilder( # Other params dependencies=dependency_config,
).build()

Definiamo i seguenti campi:

• auto – Se provare ad acquisire automaticamente le dipendenze nel tuo ambiente.
• requisiti – Una stringa del percorso personale requirements.txt file. (Questo è facoltativo.)
• costume – Un elenco di eventuali altre dipendenze personalizzate che desideri aggiungere o modificare. (Questo è facoltativo.)

Se lo stesso modulo è specificato in più posti, custom avrà la massima priorità, quindi requirementse auto avrà la priorità più bassa. Ad esempio, supponiamo che durante il rilevamento automatico, ModelBuilder rileva numpy==1.25, e un requirements.txt viene fornito il file che specifica numpy>=1.24,<1.26. Inoltre, esiste una dipendenza personalizzata: custom = ["numpy==1.26.1"]. In questo caso, numpy==1.26.1 verrà selezionato quando installeremo le dipendenze nel contenitore.

ripulire

Una volta terminato il test dei modelli, come best practice, eliminare l'endpoint per risparmiare sui costi se l'endpoint non è più necessario. Puoi seguire il ripulire sezione in ciascuno dei notebook demo o utilizzare il codice seguente per eliminare il modello e l'endpoint creati dalla demo:

predictor.delete_model()
predictor.delete_endpoint()

Conclusione

La nuova funzionalità SageMaker ModelBuilder semplifica il processo di distribuzione dei modelli ML in produzione su SageMaker. Gestendo molti dei dettagli complessi dietro le quinte, ModelBuilder riduce la curva di apprendimento per i nuovi utenti e massimizza l'utilizzo per gli utenti esperti. Con solo poche righe di codice, puoi distribuire modelli con framework integrati come XGBoost, PyTorch, Triton e Hugging Face, nonché modelli forniti da SageMaker JumpStart in endpoint robusti e scalabili su SageMaker.

Incoraggiamo tutti gli utenti di SageMaker a provare questa nuova funzionalità facendo riferimento al Costruttore di modelli pagina della documentazione. ModelBuilder è ora disponibile per tutti gli utenti SageMaker senza costi aggiuntivi. Sfrutta questo flusso di lavoro semplificato per distribuire i tuoi modelli più rapidamente. Non vediamo l'ora di sapere come ModelBuilder accelera il ciclo di vita dello sviluppo del modello!

Un ringraziamento speciale a Sirisha Upadhyayala, Raymond Liu, Gary Wang, Dhawal Patel, Deepak Garg e Ram Vegiraju.

Circa gli autori

Melania Li, PhD, è Senior AI/ML Specialist TAM presso AWS con sede a Sydney, in Australia. Aiuta i clienti aziendali a creare soluzioni utilizzando strumenti AI/ML all'avanguardia su AWS e fornisce indicazioni sull'architettura e l'implementazione di soluzioni ML con le best practice. Nel tempo libero ama esplorare la natura e trascorrere del tempo con la famiglia e gli amici.

Marc Karp è un ML Architect del team Amazon SageMaker Service. Si concentra sull'aiutare i clienti a progettare, distribuire e gestire i carichi di lavoro ML su larga scala. Nel tempo libero ama viaggiare ed esplorare posti nuovi.

Sam Edwards, è un Cloud Engineer (AI/ML) presso AWS Sydney specializzato in machine learning e Amazon SageMaker. La sua passione è aiutare i clienti a risolvere i problemi relativi ai flussi di lavoro di machine learning e creare nuove soluzioni per loro. Al di fuori del lavoro gli piace praticare sport con la racchetta e viaggiare.

Raghu Ramesha è un Senior ML Solutions Architect presso il team di assistenza Amazon SageMaker. Il suo obiettivo è aiutare i clienti a creare, distribuire e migrare carichi di lavoro di produzione ML su SageMaker su larga scala. È specializzato in ambiti di machine learning, intelligenza artificiale e visione artificiale e ha conseguito un master in informatica presso l'UT di Dallas. Nel tempo libero gli piace viaggiare e fotografare.

Shiva Raaj Kotini lavora come Principal Product Manager nel portafoglio di prodotti di inferenza di Amazon SageMaker. Si concentra sulla distribuzione dei modelli, sulla regolazione delle prestazioni e sull'ottimizzazione in SageMaker per l'inferenza.

Mohan Gandhi è Senior Software Engineer presso AWS. È stato con AWS negli ultimi 10 anni e ha lavorato su vari servizi AWS come EMR, EFA e RDS. Attualmente, è concentrato sul miglioramento dell'esperienza di inferenza di SageMaker. Nel tempo libero ama fare escursioni e maratone.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
• PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
• PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
• Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
• Fonte: https://aws.amazon.com/blogs/machine-learning/package-and-deploy-classical-ml-and-llms-easily-with-amazon-sagemaker-part-1-pysdk-improvements/