MPS e Triton riducono del 75% i costi di inference ASR su EC2

AWS, NVIDIA e Heidi mostrano come tagliare fino al 75% i costi di inference per l’ASR su Amazon EC2 usando NVIDIA CUDA MPS con NVIDIA Triton Inference Server¹.

Una singola richiesta occupa in media solo il 15–20% della GPU. Il time-slicing predefinito di CUDA fa avanzare le richieste in sequenza. L’80% della scheda resta ferma. Con vincoli stretti di latenza, questa gestione obbliga a sovra-provisionare GPU per reggere i picchi¹.

Heidi Health offre il caso reale. Processa oltre 2,4 milioni di consulti clinici a settimana in 190 paesi. Per tenere la latenza di trascrizione sotto il secondo nei picchi, la configurazione di default richiede 16 istanze GPU. Il carico c’è, ma la GPU lavora a frazioni di utilizzo a causa dell’accesso sequenziale¹.

Il post parte da qui: non dal training, ma dal serving. In un articolo precedente, gli autori hanno descritto la messa a punto di un modello di parlato della famiglia Nemotron, NVIDIA Parakeet TDT 0.6B V2, per il dominio clinico. Ora spiegano come erogare quel modello in modo più efficiente su GPU in EC2¹.

La proposta tecnica è diretta: combinare NVIDIA CUDA Multi-Process Service con NVIDIA Triton Inference Server su istanze GPU Amazon EC2. Questa configurazione consente di far convivere più richieste sulla stessa scheda, riducendo la porzione di hardware inattiva. Il risultato, misurato nel post, è un taglio dei requisiti di infrastruttura GPU e, di conseguenza, dei costi di inference fino al 75% rispetto al comportamento di default¹.

L’approccio non tocca il modello né cambia l’ambiente EC2. Interviene solo sul livello di serving. Quando ogni richiesta usa solo una frazione della GPU, MPS rimuove il collo di bottiglia dell’accesso sequenziale. Triton orchestra le richieste in parallelo. Così si sfrutta la stessa scheda rispettando la latenza di trascrizione, anche nei picchi¹.

Nel caso di Heidi, le metriche sono chiare: latenze sub-secondo al picco e 16 GPU nella configurazione iniziale. Gli autori spiegano come ridurre il numero di istanze necessarie a sostenere quel traffico. La leva è la riallocazione del lavoro sulla GPU per limitare i tempi morti imposti dal time-slicing, restando sulle stesse istanze EC2¹.

Il quadro economico segue dal dato tecnico. Se una richiesta impiega il 15–20% della GPU e l’accesso resta sequenziale, si paga per capacità inutilizzata. Con MPS e Triton, le stesse schede servono più richieste in parallelo. Servono meno GPU per lo stesso carico. I costi calano in proporzione, fino alla soglia indicata dagli autori¹.

Il post nasce dalla collaborazione tra AWS, NVIDIA e Heidi e fornisce numeri, strumenti e un caso reale. La novità sta nella messa a fuoco del serving: ottimizzare l’uso della GPU senza toccare il modello né l’infrastruttura di base, per contenere i costi mantenendo la latenza richiesta¹.