Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Risoluzione dei problemi
Le domande frequenti seguenti possono essere utili per risolvere i problemi con gli endpoint di inferenza asincrona di Amazon SageMaker.
Puoi utilizzare i metodi seguenti per trovare il conteggio istanze del tuo endpoint:
Puoi utilizzare l’API DescribeEndpoint di SageMaker AI per descrivere il numero di istanze alla base dell’endpoint in un determinato momento.
Puoi ottenere il numero di istanze visualizzando i parametri di Amazon CloudWatch. Visualizza i parametri per le tue istanze di endpoint, ad esempio
CPUUtilizationoMemoryUtilizatione controlla la statistica del conteggio di esempio per un periodo di 1 minuto. Il conteggio deve essere uguale al numero di istanze attive. Lo screenshot seguente mostra il grafico dei parametriCPUUtilizationnella console CloudWatch, dove la Statistica è impostata suSample count, il Periodo è impostato su1 minutee il conteggio risultante è 5.
Le tabelle seguenti descrivono le variabili di ambiente ottimizzabili comuni per i container SageMaker AI in base al tipo di framework.
TensorFlow
| Variabile di ambiente | Descrizione |
|---|---|
|
|
Per i modelli basati su TensorFlow, il binario |
|
|
Questo parametro regola la frazione della memoria GPU disponibile per inizializzare CUDA/cuDNN e altre librerie GPU. |
|
Ciò si ricollega alla variabile |
|
Ciò si ricollega alla variabile |
|
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, |
|
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, |
|
Python utilizza internamente OpenMP per implementare il multithreading all'interno dei processi. In genere, vengono generati thread equivalenti al numero di core CPU. Tuttavia, se implementato in aggiunta al Simultaneous Multi Threading (SMT), come HypeThreading di Intel, un determinato processo potrebbe superare la sottoscrizione di un determinato core generando un numero di thread doppio rispetto al numero di core CPU effettivi. 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 hai registrato un numero eccessivo di core disponibili utilizzando i thread del worker, è |
|
|
In alcuni casi, la disattivazione di MKL può velocizzare l'inferenza se |
PyTorch
| Variabile di ambiente | Descrizione |
|---|---|
|
|
Questo è il tempo di ritardo massimo che TorchServe attende per ricevere il batch. |
|
|
Se TorchServe non riceve il numero di richieste specificato in |
|
|
Il numero minimo di worker che TorchServe può ridurre. |
|
|
Il numero massimo di worker che TorchServe può aumentare. |
|
|
Il ritardo temporale, dopo il quale scade l'inferenza in assenza di una risposta. |
|
|
La dimensione massima del payload per TorchServe. |
|
|
La dimensione della risposta del payload per TorchServe. |
Server multimodello (MMS)
| Variabile di ambiente | Descrizione |
|---|---|
|
|
Questo parametro è utile per effettuare il tuning 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 heap della JVM in cui viene gestita questa coda. Idealmente, potresti voler mantenere bassi i requisiti di memoria heap di JVM e consentire ai worker Python di allocare più memoria per l'effettivo servizio del modello. JVM serve solo a ricevere le richieste HTTP, metterle in coda e inviarle ai worker basati su Python per l'inferenza. Se aumenti il |
|
|
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 Amazon SQS: illimitato. Tuttavia, esiste una quota di 120.000 per il numero di messaggi al 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 questo parametro o il parametro InvocationsPerInstance per capire a quale TPS potresti essere limitato. A livello di istanza, controlla il tipo di istanza e l'utilizzo della CPU/GPU per stabilire quando aumentare. 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 container è in grado di gestire le richieste di ping e invocazione contemporaneamente. Le richieste di invocazione di SageMaker AI impiegano circa 3 minuti e, in questo periodo, in genere più richieste di ping finiscono per avere esito negativo a causa del timeout che causa il rilevamento del container come Unhealthy da parte di SageMaker AI.
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 container del cliente ha restituito un errore. SageMaker AI non controlla il comportamento dei container dei clienti. SageMaker AI restituisce semplicemente la risposta da ModelContainer e non effettua altri tentativi. 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 S3FailurePath per la risposta del modello in Amazon SNS come parte delle notifiche di errore asincrone per esaminare gli 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 è di abilitare Amazon SNS, un servizio di notifica per applicazioni orientate alla messaggistica, con più abbonati che richiedono e ricevono notifiche «push» di messaggi urgenti tramite una scelta di protocolli di trasporto, tra cui HTTP, Amazon SQS ed e-mail. L’inferenza asincrona pubblica notifiche quando crei un endpoint con CreateEndpointConfig e 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 il tuo abbonamento all'argomento e annotare il nome della risorsa Amazon (ARN) di quell'argomento. Per informazioni dettagliate su come creare, abbonarsi e trovare l'ARN Amazon di un argomento su Amazon SNS, consulta Configurazione di Amazon SNS nella Guida per lo sviluppatore di Amazon SNS. Per ulteriori informazioni su come utilizzare Amazon SNS con inferenza asincrona, consulta Verifica dei risultati di previsione.
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 dall’inferenza asincrona per Regione, consulta i Prezzi di SageMaker