Presentazione del kit di strumenti di benchmarking per inferenza serverless di Amazon SageMaker

Inferenza serverless di Amazon SageMaker è un'opzione di inferenza appositamente creata che semplifica la distribuzione e la scalabilità dei modelli di machine learning (ML). Fornisce un modello pay-per-use, ideale per i servizi in cui le chiamate agli endpoint sono poco frequenti e imprevedibili. A differenza di un endpoint di hosting in tempo reale, che è supportato da un'istanza a lunga esecuzione, le risorse di calcolo per gli endpoint serverless vengono fornite su richiesta, eliminando così la necessità di scegliere tipi di istanze o gestire policy di dimensionamento.

La seguente architettura di alto livello illustra il funzionamento di un endpoint serverless. Un client richiama un endpoint, che è supportato dall'infrastruttura gestita da AWS.

Tuttavia, gli endpoint serverless sono soggetti ad avviamenti a freddo nell'ordine di secondi e sono quindi più adatti a carichi di lavoro intermittenti o imprevedibili.

Per aiutare a determinare se un endpoint serverless è l'opzione di distribuzione giusta dal punto di vista dei costi e delle prestazioni, abbiamo sviluppato il file Kit di strumenti di benchmarking per inferenza serverless SageMaker, che verifica diverse configurazioni di endpoint e confronta quella più ottimale con un'istanza di hosting in tempo reale comparabile.

In questo post presentiamo il toolkit e forniamo una panoramica della sua configurazione e dei suoi output.

Panoramica della soluzione

È possibile scaricare il toolkit e installarlo dal file Repository GitHub. Iniziare è semplice: basta installare la libreria, creare un file Modello SageMakere fornisci il nome del modello insieme a un file in formato JSON contenente un set di parametri di chiamata di esempio, inclusi il corpo del payload e il tipo di contenuto. Viene fornita una comoda funzione per convertire un elenco di argomenti di invocazione di esempio in un file di righe JSON o in un file pickle per payload binari come immagini, video o audio.

Installa il kit di strumenti

Per prima cosa installa la libreria di benchmarking nel tuo ambiente Python usando pip:

pip install sm-serverless-benchmarking

È possibile eseguire il codice seguente da un file Amazon Sage Maker Studio esempio, Istanza notebook SageMakero qualsiasi istanza con accesso programmatico ad AWS e l'appropriato Gestione dell'identità e dell'accesso di AWS (IAM) autorizzazioni. Le autorizzazioni IAM richieste sono documentate nel file Repository GitHub. Per ulteriori indicazioni e policy di esempio per IAM, fare riferimento a Come funziona Amazon SageMaker con IAM. Questo codice esegue un benchmark con un set di parametri predefinito su un modello che prevede un input CSV con due record di esempio. È buona norma fornire una serie rappresentativa di esempi per analizzare le prestazioni dell'endpoint con diversi payload di input.

from sm_serverless_benchmarking import benchmark
from sm_serverless_benchmarking.utils import convert_invoke_args_to_jsonl
model_name = ""
example_invoke_args = [
        {'Body': '1,2,3,4,5', "ContentType": "text/csv"},
        {'Body': '6,7,8,9,10', "ContentType": "text/csv"}
        ]
example_args_file = convert_invoke_args_to_jsonl(example_invoke_args,
output_path=".")
r = benchmark.run_serverless_benchmarks(model_name, example_args_file)

Inoltre, puoi eseguire il benchmark come processo di elaborazione SageMaker, che potrebbe essere un'opzione più affidabile per benchmark di lunga durata con un numero elevato di invocazioni. Vedere il seguente codice:

from sm_serverless_benchmarking.sagemaker_runner import run_as_sagemaker_job
run_as_sagemaker_job(
                    role="",
                    model_name="",
                    invoke_args_examples_file="",
                    )

Tieni presente che ciò comporterà costi aggiuntivi per l'esecuzione di un'istanza di elaborazione SageMaker ml.m5.large per la durata del benchmark.

Entrambi i metodi accettano una serie di parametri da configurare, come un elenco di configurazioni di memoria da confrontare e il numero di volte in cui verrà richiamata ciascuna configurazione. Nella maggior parte dei casi, le opzioni predefinite dovrebbero essere sufficienti come punto di partenza, ma fare riferimento a Repository GitHub per un elenco completo e le descrizioni di ciascun parametro.

Configurazione di benchmarking

Prima di approfondire cosa fa il benchmark e quali output produce, è importante comprendere alcuni concetti chiave quando si tratta di configurare endpoint serverless.

Ci sono due opzioni di configurazione chiave: MemorySizeInMB ed MaxConcurrency. MemorySizeInMB configura la quantità di memoria allocata all'istanza e può essere 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB o 6144 MB. Anche il numero di vCPU varia proporzionalmente alla quantità di memoria allocata. IL MaxConcurrency Il parametro regola il numero di richieste simultanee che un endpoint è in grado di soddisfare. Con un MaxConcurrency pari a 1, un endpoint serverless può elaborare solo una singola richiesta alla volta.

Per riassumere, il MemorySizeInMB Il parametro fornisce un meccanismo per la scalabilità verticale, consentendo di regolare la memoria e le risorse di calcolo per servire modelli più grandi, mentre MaxConcurrency fornisce un meccanismo per la scalabilità orizzontale, consentendo all'endpoint di elaborare più richieste simultanee.

Il costo di gestione di un endpoint è in gran parte determinato dalle dimensioni della memoria e non sono previsti costi associati all'aumento della concorrenza massima. Tuttavia, esiste un limite di account per regione per la massima concorrenza su tutti gli endpoint. Fare riferimento a Endpoint e quote SageMaker per gli ultimi limiti.

Risultati dell'analisi comparativa

Detto questo, l'obiettivo del benchmarking di un endpoint serverless è determinare l'impostazione delle dimensioni della memoria più conveniente e affidabile e la concorrenza massima minima in grado di gestire i modelli di traffico previsti.

Per impostazione predefinita, lo strumento esegue due benchmark. Il primo è un benchmark di stabilità, che distribuisce un endpoint per ciascuna delle configurazioni di memoria specificate e richiama ciascun endpoint con i payload di esempio forniti. L'obiettivo di questo benchmark è determinare l'impostazione MemorySizeInMB più efficace e stabile. Il benchmark acquisisce le latenze di chiamata e calcola il costo previsto per chiamata per ciascun endpoint. Quindi confronta il costo con un'istanza di hosting in tempo reale simile.

Una volta completato il benchmarking, lo strumento genera diversi output nell'ordine specificato result_save_path directory con la seguente struttura di directory:

├── benchmarking_report
├── concurrency_benchmark_raw_results
├── concurrency_benchmark_summary_results
├── cost_analysis_summary_results
├── stability_benchmark_raw_results
├── stability_benchmark_summary_results

I benchmarking_report directory contiene un rapporto consolidato con tutti i risultati di riepilogo che descriviamo in questo post. Directory aggiuntive contengono output grezzi e intermedi che è possibile utilizzare per analisi aggiuntive. Fare riferimento al Repository GitHub per una descrizione più dettagliata di ciascun artefatto di output.

Esaminiamo alcuni risultati effettivi del benchmarking per un endpoint che serve un modello TensorFlow MobileNetV2 di visione artificiale. Se desideri riprodurre questo esempio, fai riferimento a quaderni di esempio directory nel repository GitHub.

Il primo output all'interno del report consolidato è una tabella di riepilogo che fornisce i parametri di latenza minima, media, media e massima per ciascuno MemorySizeInMB configurazione corretta della dimensione della memoria. Come mostrato nella tabella seguente, la latenza media delle chiamate (invocation_latency_mean) ha continuato a migliorare man mano che la configurazione della memoria è stata aumentata a 3072 MB, ma da allora in poi ha smesso di migliorare.

Oltre alle statistiche descrittive di alto livello, viene fornito un grafico che mostra la distribuzione della latenza osservata dal client per ciascuna configurazione di memoria. Ancora una volta, possiamo osservare che la configurazione da 1024 MB non è performante come le altre opzioni, ma non c'è una differenza sostanziale nelle prestazioni nelle configurazioni da 2048 e superiori.

Amazon Cloud Watch Vengono inoltre fornite le metriche associate a ciascuna configurazione dell'endpoint. Una metrica chiave qui è ModelSetupTime, che misura il tempo impiegato per caricare il modello quando l'endpoint è stato richiamato in uno stato freddo. La metrica potrebbe non essere sempre visualizzata nel report poiché un endpoint viene avviato in uno stato caldo. UN cold_start_delay Il parametro è disponibile per specificare il numero di secondi di sospensione prima di avviare il benchmark su un endpoint distribuito. L'impostazione di questo parametro su un numero più alto, ad esempio 600 secondi, dovrebbe aumentare la probabilità di un'invocazione dello stato a freddo e migliorare le possibilità di acquisire questa metrica. Inoltre, è molto più probabile che questa metrica venga acquisita con il benchmark dell'invocazione simultanea, di cui parleremo più avanti in questa sezione.

La tabella seguente mostra i parametri acquisiti da CloudWatch per ciascuna configurazione di memoria.

Il grafico successivo mostra i compromessi in termini di prestazioni e costi delle diverse configurazioni di memoria. Una riga mostra il costo stimato per richiamare l'endpoint 1 milione di volte e l'altra mostra la latenza media della risposta. Questi parametri possono aiutarti a decidere quale configurazione dell'endpoint è più conveniente. In questo esempio, vediamo che la latenza media si appiattisce dopo 2048 MB, mentre il costo continua ad aumentare, indicando che per questo modello una configurazione della dimensione della memoria di 2048 sarebbe la più ottimale.

Il risultato finale del benchmark di costi e stabilità è una configurazione di memoria consigliata, insieme a una tabella che confronta il costo di gestione di un endpoint serverless rispetto a un'istanza di hosting SageMaker comparabile. Sulla base dei dati raccolti, lo strumento ha determinato che la configurazione da 2048 MB è quella ottimale per questo modello. Sebbene la configurazione 3072 fornisca una latenza migliore di circa 10 millisecondi, ciò comporta un aumento dei costi del 30%, da $ 4.55 a $ 5.95 per 1 milione di richieste. Inoltre, l'output mostra che un endpoint serverless fornirebbe un risparmio fino all'88.72% rispetto a un'istanza di hosting in tempo reale comparabile quando ci sono meno di 1 milione di richieste di invocazione mensili e raggiungerebbe il pareggio con un endpoint in tempo reale dopo 8.5 milioni di richieste.

Il secondo tipo di benchmark è facoltativo e testa vari test MaxConcurency impostazioni in base a diversi modelli di traffico. Questo benchmark viene solitamente eseguito utilizzando l'ottimale MemorySizeInMB configurazione dal benchmark di stabilità. I due parametri chiave per questo benchmark sono un elenco di MaxConcurency impostazioni da testare insieme a un elenco di moltiplicatori client, che determinano il numero di client simultanei simulati con cui viene testato l'endpoint.

Ad esempio, impostando il file concurrency_benchmark_max_conc parameter a [4, 8] e concurrency_num_clients_multiplier a [1, 1.5, 2], vengono lanciati due endpoint: uno con MaxConcurency di 4 e gli altri 8. Ciascun endpoint viene quindi confrontato con un (MaxConcurency x moltiplicatore) numero di client simultanei simulati, che per l'endpoint con una concorrenza di 4 si traduce in benchmark del test di carico con 4, 6 e 8 client simultanei.

Il primo risultato di questo benchmark è una tabella che mostra i parametri di latenza, le eccezioni di limitazione e i parametri di transazioni al secondo (TPS) associati a ciascuno MaxConcurrency configurazione con diversi numeri di client simultanei. Questi parametri aiutano a determinare l'appropriato MaxConcurrency impostazione per gestire il carico di traffico previsto. Nella tabella seguente, possiamo vedere che un endpoint configurato con una concorrenza massima di 8 è stato in grado di gestire fino a 16 client simultanei con solo due eccezioni di limitazione su 2,500 chiamate effettuate a una media di 24 transazioni al secondo.

La successiva serie di output fornisce un grafico per ciascuno MaxConcurrency impostazione che mostra la distribuzione della latenza sotto carichi diversi. In questo esempio, possiamo vedere che un endpoint con a MaxConcurrency l'impostazione 4 è stata in grado di elaborare con successo tutte le richieste con un massimo di 8 client simultanei con un aumento minimo della latenza di chiamata.

L'output finale fornisce una tabella con i parametri CloudWatch per ciascuno MaxConcurrency configurazione. A differenza della tabella precedente che mostra la distribuzione della latenza per ciascuna configurazione di memoria, che potrebbe non sempre visualizzare l'avvio a freddo ModelSetupTime metrica, è molto più probabile che questa metrica venga visualizzata in questa tabella a causa del numero maggiore di richieste di chiamata e di un numero maggiore MaxConcurrency.

Conclusione

In questo post abbiamo introdotto il kit di strumenti di benchmarking per inferenza serverless SageMaker e abbiamo fornito una panoramica della sua configurazione e dei suoi risultati. Lo strumento può aiutarti a prendere una decisione più informata per quanto riguarda l'inferenza serverless testando diverse configurazioni con modelli di traffico realistici. Prova il toolkit di benchmarking con i tuoi modelli per verificare di persona le prestazioni e il risparmio sui costi che puoi aspettarti distribuendo un endpoint serverless. Si prega di fare riferimento al Repository GitHub per documentazione aggiuntiva e quaderni di esempio.

Risorse addizionali

Circa gli autori

Simone Zamarin è un architetto di soluzioni AI / ML il cui obiettivo principale è aiutare i clienti a estrarre valore dalle loro risorse di dati. Nel tempo libero, Simon ama passare il tempo con la famiglia, leggere fantascienza e lavorare a vari progetti di case fai da te.

Dhawal Patel è un Principal Machine Learning Architect presso AWS. Ha lavorato con organizzazioni che vanno dalle grandi imprese alle startup di medie dimensioni su problemi legati all'informatica distribuita e all'intelligenza artificiale. Si concentra sull'apprendimento profondo, inclusi i domini della PNL e della visione artificiale. Aiuta i clienti a ottenere un'inferenza del modello ad alte prestazioni su SageMaker.

Rishabh Ray Chaudhury è un Senior Product Manager presso Amazon SageMaker, specializzato nell'inferenza del machine learning. La sua passione è l'innovazione e la creazione di nuove esperienze per i clienti del machine learning su AWS per aiutarli a scalare i loro carichi di lavoro. Nel tempo libero gli piace viaggiare e cucinare. Lo puoi trovare su LinkedIn.