Risoluzione dei problemi

Quanto segue FAQs può aiutarti a risolvere i problemi con gli endpoint Amazon Asynchronous SageMaker Inference.

Puoi utilizzare i metodi seguenti per trovare il conteggio istanze del tuo endpoint:

Puoi usare l' SageMaker intelligenza artificiale DescribeEndpointAPIper descrivere il numero di istanze alla base dell'endpoint in un dato momento.
Puoi ottenere il numero di istanze visualizzando i CloudWatch parametri di Amazon. Visualizza i parametri per le tue istanze di endpoint, ad esempio CPUUtilization o MemoryUtilization e controlla la statistica del conteggio di esempio per un periodo di 1 minuto. Il conteggio deve essere uguale al numero di istanze attive. La schermata seguente mostra la CPUUtilization metrica rappresentata graficamente nella CloudWatch console, dove la Statistica è impostata suSample count, il Periodo è impostato su e il conteggio 1 minute risultante è 5.

CloudWatch console che mostra il grafico del conteggio delle istanze attive per un endpoint.

Le tabelle seguenti descrivono le variabili di ambiente regolabili comuni per i contenitori SageMaker AI per tipo di framework.

TensorFlow

Variabile di ambiente	Descrizione
`SAGEMAKER_TFS_INSTANCE_COUNT`	Per i modelli TensorFlow basati, il `tensorflow_model_server` binario è la parte operativa responsabile del caricamento di un modello in memoria, dell'esecuzione degli input su un grafico del modello e della derivazione degli output. In genere, viene lanciata un’istanza singola di questo file binario per servire i modelli in un endpoint. Questo binario è internamente multithread e genera più thread per rispondere a una richiesta di inferenza. In alcuni casi, se si osserva che CPU viene utilizzato in modo rispettabile (oltre il 30%) ma la memoria è sottoutilizzata (utilizzo inferiore al 10%), potrebbe essere utile aumentare questo parametro. L'aumento del numero di risorse `tensorflow_model_servers` disponibili da servire in genere aumenta il throughput di un endpoint.
`SAGEMAKER_TFS_FRACTIONAL_GPU_MEM_MARGIN`	Questo parametro regola la frazione di memoria disponibile GPU per inizializzare /cu e altre librerie. CUDA DNN GPU `0.2`significa che il 20% della GPU memoria disponibile è riservata all'inizializzazione di CUDA /cu DNN e di altre GPU librerie e l'80% della GPU memoria disponibile viene allocata equamente tra i processi TF. GPUla memoria è preallocata a meno che l'opzione non sia abilitata. `allow_growth`
`SAGEMAKER_TFS_INTER_OP_PARALLELISM`	Ciò si ricollega alla variabile `inter_op_parallelism_threads` Questa variabile determina il numero di thread utilizzati da operazioni indipendenti non bloccanti. `0` significa che il sistema sceglie un numero appropriato.
`SAGEMAKER_TFS_INTRA_OP_PARALLELISM`	Ciò si ricollega alla variabile `intra_op_parallelism_threads` Ciò determina il numero di thread che possono essere utilizzati per determinate operazioni come la moltiplicazione delle matrici e le riduzioni per gli acceleratori. Un valore di `0` indica che il sistema seleziona un numero appropriato.
`SAGEMAKER_GUNICORN_WORKERS`	Questo regola il numero di processi di lavoro che Gunicorn deve generare per la gestione delle richieste. Questo valore viene utilizzato in combinazione con altri parametri per ricavare un set che massimizzi la velocità di inferenza. Inoltre, `SAGEMAKER_GUNICORN_WORKER_CLASS` regola il tipo di worker generati, in genere `async` o `gevent`.
`SAGEMAKER_GUNICORN_WORKER_CLASS`	Questo regola il numero di processi di lavoro che Gunicorn deve generare per la gestione delle richieste. Questo valore viene utilizzato in combinazione con altri parametri per ricavare un set che massimizzi la velocità di inferenza. Inoltre, `SAGEMAKER_GUNICORN_WORKER_CLASS` regola il tipo di worker generati, in genere `async` o `gevent`.
`OMP_NUM_THREADS`	Python utilizza internamente OpenMP per implementare il multithreading all'interno dei processi. In genere, vengono generati thread equivalenti al numero di CPU core. Tuttavia, se implementato su Simultaneous Multi Threading (SMT), come quello di Intel HypeThreading, un determinato processo potrebbe superare la sottoscrizione di un particolare core generando il doppio dei thread rispetto al numero di core effettivi. CPU In alcuni casi, un binario Python potrebbe finire per generare fino a quattro volte più thread dei core del processore disponibili. Pertanto, l'impostazione ideale per questo parametro, se avete registrato un numero eccessivo di core disponibili utilizzando i thread di lavoro`1`, è la metà del numero di core su un dispositivo attivato. CPU CPU SMT
`TF_DISABLE_MKL` `TF_DISABLE_POOL_ALLOCATOR`	In alcuni casi, la disattivazione MKL può velocizzare l'inferenza se e sono impostate su. `TF_DISABLE_MKL` `TF_DISABLE_POOL_ALLOCATOR` `1`

PyTorch

Variabile di ambiente	Descrizione
`SAGEMAKER_TS_MAX_BATCH_DELAY`	Si tratta del tempo massimo di TorchServe attesa per la ricezione del batch.
`SAGEMAKER_TS_BATCH_SIZE`	Se TorchServe non riceve il numero di richieste specificato in `batch_size` prima che scada il timer, invia le richieste ricevute al gestore del modello.
`SAGEMAKER_TS_MIN_WORKERS`	Il numero minimo di lavoratori a cui TorchServe è consentito ridurre.
`SAGEMAKER_TS_MAX_WORKERS`	Il numero massimo di lavoratori a cui TorchServe è consentito aumentare.
`SAGEMAKER_TS_RESPONSE_TIMEOUT`	Il ritardo temporale, dopo il quale scade l'inferenza in assenza di una risposta.
`SAGEMAKER_TS_MAX_REQUEST_SIZE`	La dimensione massima del carico utile per TorchServe.
`SAGEMAKER_TS_MAX_RESPONSE_SIZE`	La dimensione massima di risposta per TorchServe.

Server multimodello () MMS

Variabile di ambiente Descrizione

Variabile di ambiente	Descrizione
`job_queue_size`	Questo parametro è utile per effettuare la regolazione in uno scenario in cui il tipo di payload della richiesta di inferenza è elevato e, a causa della maggiore dimensione del payload, è possibile che si verifichi un maggiore consumo di memoria nell'heap di quella JVM in cui viene mantenuta questa coda. Idealmente, potresti voler mantenere i requisiti di memoria heap JVM inferiori e consentire ai lavoratori Python di allocare più memoria per l'effettivo servizio del modello. JVMserve solo per ricevere le HTTP richieste, metterle in coda e inviarle ai worker basati su Python per l'inferenza. Se si aumenta il`job_queue_size`, si potrebbe finire per aumentare il consumo di memoria heap JVM e, infine, sottrarre all'host la memoria che avrebbe potuto essere utilizzata dai worker di Python. Pertanto, fai attenzione anche quando regoli questo parametro.
`default_workers_per_model`	Questo parametro è destinato al servizio del modello di back-end e potrebbe essere utile da ottimizzare poiché questo è il componente fondamentale del servizio complessivo del modello, in base al quale i processi Python generano i thread per ciascun modello. Se questo componente è più lento (o non ottimizzato correttamente), l'ottimizzazione del front-end potrebbe non essere efficace.

job_queue_size

Questo parametro è utile per effettuare la regolazione in uno scenario in cui il tipo di payload della richiesta di inferenza è elevato e, a causa della maggiore dimensione del payload, è possibile che si verifichi un maggiore consumo di memoria nell'heap di quella JVM in cui viene mantenuta questa coda. Idealmente, potresti voler mantenere i requisiti di memoria heap JVM inferiori e consentire ai lavoratori Python di allocare più memoria per l'effettivo servizio del modello. JVMserve solo per ricevere le HTTP richieste, metterle in coda e inviarle ai worker basati su Python per l'inferenza. Se si aumenta iljob_queue_size, si potrebbe finire per aumentare il consumo di memoria heap JVM e, infine, sottrarre all'host la memoria che avrebbe potuto essere utilizzata dai worker di Python. Pertanto, fai attenzione anche quando regoli questo parametro.

default_workers_per_model

Questo parametro è destinato al servizio del modello di back-end e potrebbe essere utile da ottimizzare poiché questo è il componente fondamentale del servizio complessivo del modello, in base al quale i processi Python generano i thread per ciascun modello. Se questo componente è più lento (o non ottimizzato correttamente), l'ottimizzazione del front-end potrebbe non essere efficace.

Puoi utilizzare lo stesso container per l'inferenza asincrona utilizzato per l'inferenza in tempo reale o la trasformazione in batch. Devi confermare che i timeout e i limiti di dimensione del payload sul container siano impostati per gestire payload più grandi e timeout più lunghi.

Fai riferimento ai seguenti limiti per l'inferenza asincrona:

Limite di dimensione del payload: 1 GB
Limite di timeout: una richiesta può richiedere fino a 60 minuti.
Messaggio in coda TimeToLive (TTL): 6 ore
Numero di messaggi che possono essere inseriti in AmazonSQS: illimitato. Tuttavia, esiste una quota di 120.000 per il numero di messaggi in volo per una coda standard e di 20.000 per una coda. FIFO

In generale, con l’inferenza asincrona, puoi aumentare orizzontalmente in base a invocazioni o istanze. Per quanto riguarda i parametri di invocazione, è una buona idea consultare ApproximateBacklogSize, che è un parametro che definisce il numero di elementi nella coda che devono ancora essere elaborati. Puoi utilizzare questa metrica o la tua InvocationsPerInstance metrica per capire a cosa potresti essere limitato. TPS A livello di istanza, controlla il tipo di istanza e il relativo GPU utilizzo diCPU/per definire quando effettuare la scalabilità orizzontale. Se un’istanza singola ha una capacità superiore al 60-70%, questo è spesso un buon segno che si sta saturando l'hardware.

Non è consigliabile adottare più policy di dimensionamento, in quanto possono entrare in conflitto e creare confusione a livello hardware, causando ritardi nell’aumento.

Verifica se il tuo contenitore è in grado di gestire le richieste di ping e invocazione contemporaneamente. SageMaker Le richieste di richiamo AI richiedono circa 3 minuti e, in questo periodo, di solito più richieste di ping finiscono per fallire a causa del timeout che causa il rilevamento del container da parte dell' SageMaker IA. Unhealthy

Sì MaxConcurrentInvocationsPerInstance è una funzionalità degli endpoint asincroni. Ciò non dipende dall'implementazione del container personalizzato. MaxConcurrentInvocationsPerInstance controlla la frequenza con cui le richieste di invoca vengono inviate al container del cliente. Se questo valore è impostato su 1, viene inviata solo 1 richiesta alla volta al container, indipendentemente dal numero di worker presenti nel container del cliente.

L'errore indica che il contenitore del cliente ha restituito un errore. SageMaker L'intelligenza artificiale non controlla il comportamento dei container dei clienti. SageMaker L'intelligenza artificiale restituisce semplicemente la risposta da ModelContainer e non riprova. Se lo desideri, puoi configurare l’invocazione per riprovare in caso di errore. Ti consigliamo di attivare la registrazione dei container e di controllarli per trovare la causa principale dell'errore 500 relativo al tuo modello. Controlla anche i parametri CPUUtilization e MemoryUtilization corrispondenti nel punto in cui si è verificato l'errore. Puoi anche configurare S3 in base FailurePath al modello di risposta in Amazon SNS come parte delle notifiche di errore asincrone per indagare sugli errori.

Puoi controllare il parametro InvocationsProcesssed, che dovrebbe essere in linea con il numero di invocazioni che prevedi vengano elaborate in un minuto in base a una singola concorrenza.

La best practice consiste nell'abilitare AmazonSNS, un servizio di notifica per applicazioni orientate alla messaggistica, con più abbonati che richiedono e ricevono notifiche «push» di messaggi urgenti da una scelta di protocolli di trasporto, HTTP tra cui Amazon ed e-mail. SQS Asynchronous Inference pubblica notifiche quando crei un endpoint con e CreateEndpointConfig specifichi un argomento Amazon. SNS

Per utilizzare Amazon SNS per controllare i risultati delle previsioni dal tuo endpoint asincrono, devi prima creare un argomento, iscriverti all'argomento, confermare la tua iscrizione all'argomento e annotare il nome della risorsa Amazon () ARN di quell'argomento. Per informazioni dettagliate su come creare, abbonarsi e trovare l'SNSargomento Amazon ARN di un Amazon, consulta Configuring Amazon SNS nell'Amazon SNS Developer Guide. Per ulteriori informazioni su come usare Amazon SNS con Asynchronous Inference, consulta Verifica i risultati delle previsioni.

Sì. L'inferenza asincrona fornisce un meccanismo per ridurre a zero istanze quando non ci sono richieste. Se l'endpoint è stato ridimensionato a zero istanze durante questi periodi, l'endpoint non aumenterà nuovamente fino a quando il numero di richieste in coda non supererà l'obiettivo specificato nella policy di dimensionamento. Ciò può comportare lunghi tempi di attesa per le richieste in coda. In questi casi, se desideri passare da zero istanze per nuove richieste inferiori all'obiettivo di coda specificato, puoi utilizzare una policy di dimensionamento aggiuntiva denominata HasBacklogWithoutCapacity. Per ulteriori informazioni su come definire questa policy di dimensionamento, consulta Scalabilità automatica di un endpoint asincrono.

Per un elenco completo delle istanze supportate da Asynchronous Inference per regione, consulta i prezzi di AI. SageMaker Verifica se l'istanza richiesta è disponibile nella tua Regione prima di procedere.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Scalabilità automatica di un endpoint asincrono

Trasformazione in batch