

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
<a name="async-inference-troubleshooting"></a>

Le domande frequenti seguenti possono essere utili per risolvere i problemi con gli endpoint di inferenza asincrona di Amazon SageMaker.

## D: Ho abilitato il dimensionamento automatico. Come posso trovare il conteggio istanze dietro l'endpoint in un dato momento?
<a name="async-troubleshooting-q1"></a>

Puoi utilizzare i metodi seguenti per trovare il conteggio istanze del tuo endpoint:
+ Puoi utilizzare l’API [DescribeEndpoint](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeEndpoint.html) 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](https://docs.aws.amazon.com/sagemaker/latest/dg/monitoring-cloudwatch.html#cloudwatch-metrics-jobs), 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. Lo screenshot seguente mostra il grafico dei parametri `CPUUtilization` nella console CloudWatch, dove la **Statistica** è impostata su `Sample count`, il **Periodo** è impostato su `1 minute` e il conteggio risultante è 5.

![Console CloudWatch che mostra il grafico del conteggio di istanze attive per un endpoint.](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/cloudwatch-sample-count.png)


## D: Quali sono le variabili di ambiente ottimizzabili più comuni per i container SageMaker AI?
<a name="async-troubleshooting-q2"></a>

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 | 
| --- | --- | 
| `SAGEMAKER_TFS_INSTANCE_COUNT` | Per i modelli basati su TensorFlow, il binario `tensorflow_model_server` è 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 alcune istanze, se si osserva che la CPU è utilizzata 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 della memoria GPU disponibile per inizializzare CUDA/cuDNN e altre librerie GPU. `0.2` significa che il 20% della memoria GPU disponibile è riservata all'inizializzazione di CUDA/cuDNN e altre librerie GPU e l'80% della memoria GPU disponibile è allocata equamente tra i processi TF. La memoria della GPU `allow_growth` è preallocata a meno che l'opzione non sia abilitata. | 
| `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 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, è `1`, o la metà del numero di core CPU su una CPU con SMT attivato. | 
| `TF_DISABLE_MKL`<br />`TF_DISABLE_POOL_ALLOCATOR` | In alcuni casi, la disattivazione di MKL può velocizzare l'inferenza se `TF_DISABLE_MKL` e `TF_DISABLE_POOL_ALLOCATOR` sono impostati su `1`. | 

**PyTorch**


| Variabile di ambiente | Descrizione | 
| --- | --- | 
| `SAGEMAKER_TS_MAX_BATCH_DELAY` | Questo è il tempo di ritardo massimo che TorchServe attende per ricevere il batch. | 
| `SAGEMAKER_TS_BATCH_SIZE` | Se TorchServe non riceve il numero di richieste specificato in `batch_size` prima dello scadere del timer, invia le richieste ricevute al gestore del modello. | 
| `SAGEMAKER_TS_MIN_WORKERS` | Il numero minimo di worker che TorchServe può ridurre. | 
| `SAGEMAKER_TS_MAX_WORKERS` | Il numero massimo di worker che TorchServe può 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 payload per TorchServe. | 
| `SAGEMAKER_TS_MAX_RESPONSE_SIZE` | La dimensione della risposta del payload per TorchServe. | 

**Server multimodello (MMS)**


| Variabile di ambiente | Descrizione | 
| --- | --- | 
| `job_queue_size` | 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 `job_queue_size`, potresti finire per aumentare il consumo di memoria heap della JVM e, infine, sottrarre memoria dall'host che avrebbe potuto essere utilizzata dai worker 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. | 

## D: Come posso assicurarmi che il mio container supporti l'inferenza asincrona?
<a name="async-troubleshooting-q3"></a>

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.

## D: Quali sono i limiti specifici dell'inferenza asincrona e possono essere modificati?
<a name="async-troubleshooting-q4"></a>

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.

## D: Quali parametri è meglio definire per il dimensionamento automatico nell'inferenza asincrona? Posso avere più policy di dimensionamento?
<a name="async-troubleshooting-q5"></a>

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.

## D: Perché il mio endpoint asincrono chiude un'istanza come `Unhealthy` e le richieste di aggiornamento tramite il dimensionamento automatico non riescono?
<a name="async-troubleshooting-q6"></a>

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.

## D: `MaxConcurrentInvocationsPerInstance` può funzionare con il mio container modello BYOC con le impostazioni ningx/gunicorn/flask?
<a name="async-troubleshooting-q7"></a>

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.

## D: Come posso eseguire il debug degli errori del server del modello (500) sul mio endpoint asincrono?
<a name="async-troubleshooting-q8"></a>

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](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AsyncInferenceOutputConfig.html#sagemaker-Type-AsyncInferenceOutputConfig-S3FailurePath) per la risposta del modello in Amazon SNS come parte delle notifiche di errore asincrone per esaminare gli errori.

## D: Come posso sapere se `MaxConcurrentInvocationsPerInstance=1` ha effetto? Ci sono parametri che posso controllare?
<a name="async-troubleshooting-q9"></a>

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.

## D: Come posso tenere traccia del successo e degli errori delle mie richieste di invocazione? Quali sono le best practice?
<a name="async-troubleshooting-q10"></a>

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](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html) 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](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference-check-predictions.html).

## D: Posso definire una policy di dimensionamento che parta da zero istanze dopo aver ricevuto una nuova richiesta?
<a name="async-troubleshooting-q11"></a>

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](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference-autoscale.html#async-inference-autoscale-scale-up).

## D: Ricevo un errore che indica che il tipo di istanza non è supportato per l'inferenza asincrona. Quali sono i tipi di istanza supportati dall’inferenza asincrona?
<a name="async-troubleshooting-q12"></a>

Per un elenco completo delle istanze supportate dall’inferenza asincrona per Regione, consulta i [Prezzi di SageMaker](https://aws.amazon.com/sagemaker/pricing/). Verifica se l'istanza richiesta è disponibile nella tua Regione prima di procedere.