Le applicazioni di machine learning (ML) sono complesse da implementare e spesso richiedono la capacità di iperscalabilità, oltre a requisiti di latenza estremamente bassi e budget di costo rigorosi. Casi d'uso come il rilevamento delle frodi, i consigli sui prodotti e la previsione del traffico sono esempi in cui i millisecondi contano e sono fondamentali per il successo aziendale. È necessario soddisfare rigorosi accordi sul livello di servizio (SLA) e una richiesta tipica può richiedere più passaggi come la pre-elaborazione, la trasformazione dei dati, la progettazione delle funzionalità, la logica di selezione del modello, l'aggregazione del modello e la post-elaborazione.
L'implementazione di modelli ML su larga scala con costi ottimizzati ed efficienze di calcolo può essere un'attività scoraggiante e ingombrante. Ogni modello ha i suoi meriti e le sue dipendenze in base alle origini dati esterne e all'ambiente di runtime come la potenza della CPU/GPU delle risorse di calcolo sottostanti. Un'applicazione può richiedere più modelli ML per servire una singola richiesta di inferenza. In alcuni scenari, una richiesta può passare attraverso più modelli. Non esiste un approccio valido per tutti ed è importante che i professionisti del machine learning cerchino metodi collaudati per affrontare le sfide ricorrenti dell'hosting di machine learning. Ciò ha portato all'evoluzione dei modelli di progettazione per l'hosting di modelli ML.
In questo post, esploriamo modelli di progettazione comuni per la creazione di applicazioni ML Amazon Sage Maker.
Modelli di progettazione per la creazione di applicazioni ML
Diamo un'occhiata ai seguenti modelli di progettazione da usare per l'hosting di applicazioni ML.
Applicazioni ML basate su un singolo modello
Questa è un'ottima opzione quando il tuo caso d'uso ML richiede un singolo modello per servire una richiesta. Il modello viene distribuito su un'infrastruttura di calcolo dedicata con la possibilità di scalare in base al traffico di input. Questa opzione è ideale anche quando l'applicazione client ha un requisito di inferenza a bassa latenza (nell'ordine di millisecondi o secondi).
Applicazioni ML basate su più modelli
Per rendere l'hosting più conveniente, questo modello di progettazione consente di ospitare più modelli sulla stessa infrastruttura tenant. Più modelli ML possono condividere le risorse dell'host o del contenitore, incluso il caching dei modelli ML più utilizzati nella memoria, con conseguente migliore utilizzo della memoria e delle risorse di calcolo. A seconda dei tipi di modelli che hai scelto di distribuire, il co-hosting dei modelli può utilizzare i seguenti metodi:
- Hosting multi-modello – Questa opzione consente di ospitare più modelli utilizzando un contenitore di servizio condiviso su un singolo endpoint. Questa funzione è ideale quando si dispone di un numero elevato di modelli simili che è possibile servire tramite un contenitore di pubblicazione condiviso e non è necessario accedere a tutti i modelli contemporaneamente.
- Hosting multi-container – Questa opzione è ideale quando si hanno più modelli in esecuzione su diversi stack di servizio con esigenze di risorse simili e quando i singoli modelli non dispongono di traffico sufficiente per utilizzare la piena capacità delle istanze dell'endpoint. L'hosting multi-container consente di distribuire più container che utilizzano modelli o framework diversi su un singolo endpoint. I modelli possono essere completamente eterogenei, con il proprio stack di servizio indipendente.
- Insiemi di modelli – In molti casi d'uso di produzione, spesso possono esserci molti modelli a monte che forniscono input a un determinato modello a valle. È qui che gli ensemble sono utili. I modelli di ensemble implicano la miscelazione dell'output da uno o più modelli di base per ridurre il errore di generalizzazione della previsione. I modelli di base possono essere diversi e addestrati da diversi algoritmi. Gli insiemi di modelli possono superare i singoli modelli perché l'errore di previsione del modello diminuisce quando viene utilizzato l'approccio dell'insieme.
I seguenti sono casi d'uso comuni di modelli di insieme e dei relativi diagrammi di modello di progettazione:
- Scatter-raccogli – In un modello scatter-gather, una richiesta di inferenza viene indirizzata a un numero di modelli. Viene quindi utilizzato un aggregatore per raccogliere le risposte e distillarle in un'unica risposta di inferenza. Ad esempio, un caso d'uso di classificazione delle immagini può utilizzare tre diversi modelli per eseguire l'attività. Il modello scatter-gather consente di combinare i risultati delle inferenze eseguite su tre diversi modelli e scegliere il modello di classificazione più probabile.
- Aggregato del modello – In un modello di aggregazione, viene calcolata la media degli output di più modelli. Per i modelli di classificazione, le previsioni di più modelli vengono valutate per determinare la classe che ha ricevuto il maggior numero di voti e viene trattata come l'output finale dell'insieme. Ad esempio, in un problema di classificazione a due classi per classificare un insieme di frutti come arance o mele, se due modelli votano per un'arancia e un modello vota per una mela, l'output aggregato sarà un'arancia. L'aggregazione aiuta a combattere l'imprecisione nei singoli modelli e rende l'output più accurato.
- Selezione dinamica – Un altro modello per i modelli di ensemble consiste nell'eseguire dinamicamente la selezione del modello per i dati attributi di input. Ad esempio, in un dato input di immagini di frutti, se l'input contiene un'arancia, verrà utilizzato il modello A perché è specializzato per le arance. Se l'input contiene una mela, verrà utilizzato il modello B perché è specializzato per le mele.
- Applicazioni ML di inferenza seriale – Con un modello di inferenza seriale, noto anche come pipeline di inferenza, i casi d'uso hanno requisiti per pre-elaborare i dati in entrata prima di richiamare un modello ML pre-addestrato per la generazione di inferenze. Inoltre, in alcuni casi, potrebbe essere necessario elaborare ulteriormente le inferenze generate, in modo che possano essere facilmente utilizzate dalle applicazioni a valle. Una pipeline di inferenza consente di riutilizzare lo stesso codice di pre-elaborazione utilizzato durante l'addestramento del modello per elaborare i dati della richiesta di inferenza utilizzati per le previsioni.
- Logica di business – La produzione di ML implica sempre una logica di business. I modelli di logica aziendale coinvolgono tutto ciò che è necessario per eseguire un'attività ML che non è l'inferenza del modello ML. Ciò include il caricamento del modello da Servizio di archiviazione semplice Amazon (Amazon S3), ad esempio, ricerche nel database per convalidare l'input, ottenere funzionalità precalcolate dal feature store e così via. Dopo aver completato questi passaggi della logica aziendale, gli input vengono passati ai modelli ML.
Opzioni di inferenza ML
Per la distribuzione del modello, è importante lavorare a ritroso rispetto al caso d'uso. Qual è la frequenza della previsione? Ti aspetti traffico in tempo reale verso la tua applicazione e una risposta in tempo reale ai tuoi clienti? Hai molti modelli addestrati per diversi sottoinsiemi di dati per lo stesso caso d'uso? Il traffico di previsione fluttua? La latenza dell'inferenza è un problema? Sulla base di questi dettagli, tutti i modelli di progettazione precedenti possono essere implementati utilizzando le seguenti opzioni di distribuzione:
- Inferenza in tempo reale – L'inferenza in tempo reale è ideale per i carichi di lavoro di inferenza in cui si hanno requisiti in tempo reale, interattivi e a bassa latenza. I carichi di lavoro di inferenza ML in tempo reale possono includere un'applicazione ML basata su un singolo modello, in cui un'applicazione richiede un solo modello ML per servire una singola richiesta, o un'applicazione ML basata su più modelli, in cui un'applicazione richiede più modelli ML per servire un singolo richiesta.
- Inferenza quasi in tempo reale (asincrona). – Con l'inferenza quasi in tempo reale, puoi mettere in coda le richieste in arrivo. Questo può essere utilizzato per eseguire l'inferenza su input che sono centinaia di MB. Funziona quasi in tempo reale e consente agli utenti di utilizzare l'input per l'inferenza e di leggere l'output dall'endpoint da un bucket S3. Può essere particolarmente utile nei casi con PNL e visione artificiale, dove sono presenti grandi carichi utili che richiedono tempi di preelaborazione più lunghi.
- Inferenza batch – L'inferenza batch può essere utilizzata per eseguire l'inferenza offline su un set di dati di grandi dimensioni. Poiché viene eseguito offline, l'inferenza batch non offre la latenza più bassa. In questo caso, la richiesta di inferenza viene elaborata con un trigger pianificato o basato su eventi di un processo di inferenza batch.
- Inferenza senza server – L'inferenza serverless è ideale per i carichi di lavoro con periodi di inattività tra gli scatti di traffico e può tollerare alcuni secondi extra di latenza (avvio a freddo) per la prima chiamata dopo un periodo di inattività. Ad esempio, un servizio di chatbot o un'applicazione per elaborare moduli o analizzare dati da documenti. In questo caso, potresti volere un'opzione di inferenza online in grado di eseguire automaticamente il provisioning e la scalabilità della capacità di calcolo in base al volume delle richieste di inferenza. E durante il periodo di inattività, dovrebbe essere in grado di disattivare completamente la capacità di calcolo in modo da non essere addebitato. L'inferenza serverless elimina il lavoro pesante indifferenziato di selezionare e gestire i server avviando automaticamente le risorse di elaborazione e ridimensionandole in base al traffico.
Usa le funzioni di fitness per selezionare l'opzione di inferenza ML corretta
Decidere la giusta opzione di hosting è importante perché ha un impatto sugli utenti finali resi dalle tue applicazioni. A questo scopo, prendiamo in prestito il concetto di funzioni di fitness, che è stato coniato da Neal Ford e dai suoi colleghi di AWS Partner ThoughtWorks nel loro lavoro Costruire architetture evolutive. Le funzioni di fitness forniscono una valutazione prescrittiva di varie opzioni di hosting in base agli obiettivi del cliente. Le funzioni di fitness ti aiutano a ottenere i dati necessari per consentire l'evoluzione pianificata della tua architettura. Stabiliscono valori misurabili per valutare quanto la tua soluzione è vicina al raggiungimento degli obiettivi prefissati. Le funzioni di fitness possono e devono essere adattate man mano che l'architettura si evolve per guidare un processo di cambiamento desiderato. Ciò fornisce agli architetti uno strumento per guidare i loro team mantenendo l'autonomia del team.
Ci sono cinque principali funzioni di fitness che interessano ai clienti quando si tratta di selezionare l'opzione di inferenza ML giusta per ospitare i loro modelli e applicazioni ML.
Funzione fitness | Descrizione |
Costo |
Distribuire e mantenere un modello ML e un'applicazione ML su un framework scalabile è un processo aziendale critico e i costi possono variare notevolmente a seconda delle scelte effettuate sull'infrastruttura di hosting del modello, sull'opzione di hosting, sui framework ML, sulle caratteristiche del modello ML, sulle ottimizzazioni, sulla politica di ridimensionamento, e altro ancora. I carichi di lavoro devono utilizzare l'infrastruttura hardware in modo ottimale per garantire che i costi rimangano sotto controllo. Questa funzione di fitness si riferisce specificamente al costo dell'infrastruttura, che fa parte del costo totale di proprietà (TCO) complessivo. I costi dell'infrastruttura sono i costi combinati per l'archiviazione, la rete e l'elaborazione. È inoltre fondamentale comprendere altri componenti del TCO, inclusi i costi operativi e i costi di sicurezza e conformità. I costi operativi sono i costi combinati di funzionamento, monitoraggio e manutenzione dell'infrastruttura ML. I costi operativi sono calcolati come il numero di ingegneri richiesti in base a ogni scenario e lo stipendio annuo degli ingegneri, aggregato per un periodo specifico. I clienti che utilizzano soluzioni ML autogestite su Cloud di calcolo elastico di Amazon (Amazon EC2), Servizio di container elastici Amazon (Amazon ECS) e Servizio Amazon Elastic Kubernetes (Amazon EKS) devono creare da soli gli strumenti operativi. I clienti che utilizzano SageMaker incorrono in un TCO significativamente inferiore. L'inferenza di SageMaker è un servizio completamente gestito e fornisce funzionalità pronte all'uso per la distribuzione di modelli ML per l'inferenza. Non è necessario eseguire il provisioning delle istanze, monitorare l'integrità delle istanze, gestire gli aggiornamenti o le patch di sicurezza, emettere metriche operative o creare il monitoraggio per i carichi di lavoro di inferenza ML. Dispone di funzionalità integrate per garantire disponibilità e resilienza elevate. SageMaker supporta la sicurezza con crittografia end-to-end a riposo e in transito, inclusa la crittografia del volume root e Negozio di blocchi elastici di Amazon (Amazon EBS) volume, Cloud privato virtuale di Amazon (Amazon VPC) supporto, Collegamento privato AWS, chiavi gestite dal cliente, Gestione dell'identità e dell'accesso di AWS (IAM) controllo degli accessi a grana fine, AWS CloudTrail audit, crittografia internodo per l'addestramento, controllo degli accessi basato su tag, isolamento della rete e proxy di applicazione interattivo. Tutte queste funzionalità di sicurezza sono fornite immediatamente in SageMaker e possono far risparmiare alle aziende decine di mesi di sviluppo di sforzi ingegneristici in un periodo di 3 anni. SageMaker è un servizio idoneo HIPAA ed è certificato PCI, SOC, GDPR e ISO. SageMaker supporta anche gli endpoint FIPS. Per ulteriori informazioni sul TCO, fare riferimento a Il costo totale di proprietà di Amazon SageMaker. |
Latenza di inferenza | Molti modelli e applicazioni ML sono critici per la latenza, in cui la latenza di inferenza deve rientrare nei limiti specificati da un obiettivo del livello di servizio. La latenza dell'inferenza dipende da una moltitudine di fattori, tra cui le dimensioni e la complessità del modello, la piattaforma hardware, l'ambiente software e l'architettura di rete. Ad esempio, i modelli più grandi e più complessi possono richiedere più tempo per eseguire l'inferenza. |
Throughput (transazioni al secondo) | Per l'inferenza del modello, l'ottimizzazione del throughput è fondamentale per l'ottimizzazione delle prestazioni e il raggiungimento dell'obiettivo aziendale dell'applicazione ML. Mentre continuiamo a progredire rapidamente in tutti gli aspetti del machine learning, comprese le implementazioni di basso livello delle operazioni matematiche nella progettazione dei chip, le librerie specifiche dell'hardware svolgono un ruolo maggiore nell'ottimizzazione delle prestazioni. Vari fattori come la dimensione del payload, gli hop di rete, la natura degli hop, le caratteristiche del grafico del modello, gli operatori nel modello e la CPU, la GPU e il profilo di memoria delle istanze di hosting del modello influiscono sulla velocità effettiva del modello ML. |
Scalare la complessità della configurazione | È fondamentale che i modelli o le applicazioni ML vengano eseguiti su un framework scalabile in grado di gestire la domanda di traffico variabile. Consente inoltre il massimo utilizzo delle risorse di CPU e GPU e impedisce l'overprovisioning delle risorse di calcolo. |
Modello di traffico previsto | I modelli o le applicazioni ML possono avere modelli di traffico diversi, che vanno dal traffico live continuo in tempo reale a picchi periodici di migliaia di richieste al secondo e da modelli di richiesta poco frequenti e imprevedibili a richieste batch offline su set di dati più grandi. Si consiglia di lavorare a ritroso rispetto al modello di traffico previsto per selezionare l'opzione di hosting corretta per il proprio modello ML. |
Distribuzione di modelli con SageMaker
SageMaker è un servizio AWS completamente gestito che offre a ogni sviluppatore e data scientist la possibilità di creare, addestrare e distribuire rapidamente modelli ML su larga scala. Con l'inferenza di SageMaker, puoi distribuire i tuoi modelli ML su endpoint ospitati e ottenere risultati di inferenza. SageMaker offre un'ampia selezione di hardware e funzionalità per soddisfare i requisiti del tuo carico di lavoro, consentendoti di selezionare oltre 70 tipi di istanza con accelerazione hardware. SageMaker può anche fornire consigli sul tipo di istanza di inferenza utilizzando una nuova funzionalità chiamata SageMaker Inference Recommender, nel caso in cui non si sia sicuri di quale sia la più ottimale per il proprio carico di lavoro.
Puoi scegliere le opzioni di distribuzione per soddisfare al meglio i tuoi casi d'uso, come l'inferenza in tempo reale, gli endpoint asincroni, batch e persino senza server. Inoltre, SageMaker offre varie strategie di implementazione come canary, blu verde, ombrae test A/B per la distribuzione del modello, insieme a una distribuzione conveniente con endpoint multi-modello, multi-container e scalabilità elastica. Con l'inferenza di SageMaker, puoi visualizzare le metriche delle prestazioni per i tuoi endpoint in Amazon Cloud Watch, scala automaticamente gli endpoint in base al traffico e aggiorna i tuoi modelli in produzione senza perdere alcuna disponibilità.
SageMaker offre quattro opzioni per distribuire il tuo modello in modo da poter iniziare a fare previsioni:
- Inferenza in tempo reale – Questo è adatto per carichi di lavoro con requisiti di latenza di millisecondi, dimensioni di payload fino a 6 MB e tempi di elaborazione fino a 60 secondi.
- Trasformazione batch – Questo è l'ideale per le previsioni offline su grandi lotti di dati che sono disponibili in anticipo.
- Inferenza asincrona – Questo è progettato per carichi di lavoro che non hanno requisiti di latenza inferiori al secondo, dimensioni di payload fino a 1 GB e tempi di elaborazione fino a 15 minuti.
- Inferenza senza server – Con l'inferenza serverless, puoi distribuire rapidamente modelli ML per l'inferenza senza dover configurare o gestire l'infrastruttura sottostante. Inoltre, paghi solo per la capacità di calcolo utilizzata per elaborare le richieste di inferenza, ideale per carichi di lavoro intermittenti.
Il diagramma seguente può aiutarti a comprendere le opzioni di implementazione del modello di hosting SageMaker insieme alle valutazioni della funzione di fitness associate.
Esploriamo ciascuna delle opzioni di distribuzione in modo più dettagliato.
Inferenza in tempo reale in SageMaker
L'inferenza in tempo reale di SageMaker è consigliata se hai un traffico sostenuto e hai bisogno di una latenza inferiore e coerente per le tue richieste con dimensioni di payload fino a 6 MB e tempi di elaborazione fino a 60 secondi. Distribuisci il tuo modello ai servizi di hosting SageMaker e ottieni un endpoint che può essere utilizzato per l'inferenza. Questi endpoint sono completamente gestiti e supportano il ridimensionamento automatico. L'inferenza in tempo reale è popolare per i casi d'uso in cui ti aspetti una risposta sincrona a bassa latenza con modelli di traffico prevedibili, come consigli personalizzati per prodotti e servizi o casi d'uso per il rilevamento di frodi transazionali.
In genere, un'applicazione client invia richieste all'endpoint HTTPS di SageMaker per ottenere inferenze da un modello distribuito. Puoi distribuire più varianti di un modello allo stesso endpoint HTTPS SageMaker. Questo è utile per testare le variazioni di un modello in produzione. Il ridimensionamento automatico consente di regolare dinamicamente il numero di istanze di cui è stato eseguito il provisioning per un modello in risposta alle modifiche del carico di lavoro.
La tabella seguente fornisce indicazioni sulla valutazione dell'inferenza in tempo reale di SageMaker in base alle funzioni di fitness.
Funzione fitness | Descrizione |
Costo |
Gli endpoint in tempo reale offrono una risposta sincrona alle richieste di inferenza. Poiché l'endpoint è sempre in esecuzione e disponibile per fornire una risposta di inferenza sincrona in tempo reale, si paga per l'utilizzo dell'istanza. I costi possono aumentare rapidamente quando si distribuiscono più endpoint, soprattutto se gli endpoint non utilizzano completamente le istanze sottostanti. La scelta dell'istanza giusta per il tuo modello ti assicura di avere l'istanza più performante al minor costo per i tuoi modelli. Si consiglia il ridimensionamento automatico per regolare dinamicamente la capacità in base al traffico per mantenere prestazioni costanti e prevedibili al costo più basso possibile. SageMaker estende l'accesso alle famiglie di istanze ML basate su Graviton2 e Graviton3. Gravitone AWS i processori sono creati su misura da Amazon Web Services utilizzando i core Arm Neoverse a 64 bit per offrire il miglior rapporto qualità-prezzo per i tuoi carichi di lavoro cloud in esecuzione su Amazon EC2. Con le istanze basate su Graviton, hai più opzioni per ottimizzare i costi e le prestazioni quando distribuisci i tuoi modelli ML su SageMaker. SageMaker supporta anche Istanze di Inf1, fornendo prestazioni elevate e inferenza ML conveniente. Con 1–16 Chip AWS Inferentia per istanza, le istanze Inf1 possono scalare in termini di prestazioni e offrire un throughput fino a tre volte superiore e un costo per inferenza inferiore fino al 50% rispetto alle istanze basate su GPU AWS. Per utilizzare le istanze Inf1 in SageMaker, puoi compilare i tuoi modelli addestrati utilizzando Amazon Sage Maker Neo e seleziona le istanze Inf1 per distribuire il modello compilato su SageMaker. Puoi anche esplorare Piani di risparmio per SageMaker di beneficiare di risparmi sui costi fino al 64% rispetto al prezzo on demand. Quando crei un endpoint, SageMaker collega un volume di storage EBS a ogni istanza di calcolo ML che ospita l'endpoint. La dimensione del volume di archiviazione dipende dal tipo di istanza. Il costo aggiuntivo per gli endpoint in tempo reale include il costo di GB al mese di storage con provisioning, oltre a GB di dati elaborati all'interno e GB di dati elaborati dall'istanza dell'endpoint. |
Latenza di inferenza | L'inferenza in tempo reale è l'ideale quando hai bisogno di un endpoint persistente con requisiti di latenza di millisecondi. Supporta dimensioni di payload fino a 6 MB e tempi di elaborazione fino a 60 secondi. |
Throughput |
Un valore ideale del throughput di inferenza è soggettivo a fattori quali modello, dimensione dell'input del modello, dimensione del batch e tipo di istanza dell'endpoint. Come best practice, esamina i parametri di CloudWatch per le richieste di input e l'utilizzo delle risorse e seleziona il tipo di istanza appropriato per ottenere un throughput ottimale. Un'applicazione aziendale può essere ottimizzata per il throughput o per la latenza. Ad esempio, il batch dinamico può aiutare ad aumentare la velocità effettiva per le app sensibili alla latenza utilizzando l'inferenza in tempo reale. Tuttavia, esistono limiti alla dimensione del batch, senza i quali la latenza dell'inferenza potrebbe risentirne. La latenza dell'inferenza aumenterà man mano che aumenti la dimensione del batch per migliorare la velocità effettiva. Pertanto, l'inferenza in tempo reale è un'opzione ideale per le applicazioni sensibili alla latenza. SageMaker offre opzioni di inferenza asincrona e trasformazione batch, che sono ottimizzate per fornire un throughput più elevato rispetto all'inferenza in tempo reale se le applicazioni aziendali possono tollerare una latenza leggermente superiore. |
Scalare la complessità della configurazione |
Supporto degli endpoint in tempo reale di SageMaker ridimensionamento automatico fuori dalla scatola. Quando il carico di lavoro aumenta, il ridimensionamento automatico porta più istanze online. Quando il carico di lavoro diminuisce, il ridimensionamento automatico rimuove le istanze non necessarie, aiutandoti a ridurre i costi di calcolo. Senza ridimensionamento automatico, è necessario eseguire il provisioning per il traffico di picco o l'indisponibilità del modello di rischio. A meno che il traffico verso il tuo modello non sia costante per tutto il giorno, ci sarà un eccesso di capacità inutilizzata. Ciò porta a un basso utilizzo e allo spreco di risorse. Con SageMaker, puoi configurare diverse opzioni di ridimensionamento in base al modello di traffico previsto. Il ridimensionamento semplice o il ridimensionamento del monitoraggio della destinazione è l'ideale quando si desidera eseguire il ridimensionamento in base a un parametro CloudWatch specifico. Puoi farlo scegliendo una metrica specifica e impostando i valori di soglia. Le metriche consigliate per questa opzione sono nella media Se hai bisogno di una configurazione avanzata, puoi impostare un criterio di ridimensionamento graduale per regolare dinamicamente il numero di istanze da ridimensionare in base alle dimensioni della violazione dell'allarme. Questo ti aiuta a configurare una risposta più aggressiva quando la domanda raggiunge un certo livello. Puoi utilizzare un'opzione di scalabilità pianificata quando sai che la domanda segue una pianificazione specifica nel giorno, nella settimana, nel mese o nell'anno. Questo ti aiuta a specificare una pianificazione una tantum o una pianificazione ricorrente o espressioni cron insieme alle ore di inizio e di fine, che costituiscono i limiti di quando l'azione di ridimensionamento automatico inizia e si interrompe. Per maggiori dettagli, consultare Configurazione degli endpoint di inferenza con scalabilità automatica in Amazon SageMaker ed Carica test e ottimizza un endpoint Amazon SageMaker utilizzando il dimensionamento automatico. |
Schema del traffico | L'inferenza in tempo reale è ideale per i carichi di lavoro con uno schema di traffico continuo o regolare. |
Inferenza asincrona in SageMaker
L'inferenza asincrona di SageMaker è una nuova funzionalità di SageMaker che accoda le richieste in arrivo e le elabora in modo asincrono. Questa opzione è ideale per le richieste con payload di grandi dimensioni (fino a 1 GB), lunghi tempi di elaborazione (fino a 15 minuti) e requisiti di latenza quasi in tempo reale. Esempi di carichi di lavoro per l'inferenza asincrona includono aziende sanitarie che elaborano immagini o video biomedici ad alta risoluzione come ecocardiogrammi per rilevare anomalie. Queste applicazioni ricevono picchi di traffico in entrata in momenti diversi della giornata e richiedono un'elaborazione quasi in tempo reale a basso costo. I tempi di elaborazione per queste richieste possono variare nell'ordine dei minuti, eliminando la necessità di eseguire l'inferenza in tempo reale. Invece, i payload di input possono essere elaborati in modo asincrono da un archivio di oggetti come Amazon S3 con accodamento automatico e una soglia di concorrenza predefinita. Al momento dell'elaborazione, SageMaker posiziona la risposta di inferenza nella posizione Amazon S3 precedentemente restituita. Puoi facoltativamente scegliere di ricevere notifiche di successo o di errore tramite Servizio di notifica semplice Amazon (SNS Amazon).
La tabella seguente fornisce indicazioni sulla valutazione dell'inferenza asincrona di SageMaker in base alle funzioni di fitness.
Funzione fitness | Descrizione |
Costo | L'inferenza asincrona è un'ottima scelta per carichi di lavoro sensibili ai costi con payload di grandi dimensioni e traffico burst. L'inferenza asincrona ti consente di risparmiare sui costi ridimensionando automaticamente il conteggio delle istanze a zero quando non ci sono richieste da elaborare, quindi paghi solo quando l'endpoint sta elaborando le richieste. Le richieste ricevute quando sono presenti zero istanze vengono messe in coda per l'elaborazione dopo che l'endpoint si è ridimensionato. |
Latenza di inferenza | L'inferenza asincrona è ideale per i requisiti di latenza quasi in tempo reale. Le richieste vengono messe in coda ed elaborate non appena il calcolo è disponibile. Ciò si traduce in genere in decine di millisecondi di latenza. |
Throughput | L'inferenza asincrona è ideale per i casi d'uso non sensibili alla latenza, perché le applicazioni non devono scendere a compromessi sulla velocità effettiva. Le richieste non vengono eliminate durante i picchi di traffico perché l'endpoint di inferenza asincrona accoda le richieste invece di eliminarle. |
Scalare la complessità della configurazione |
SageMaker supporta ridimensionamento automatico per l'endpoint asincrono. A differenza degli endpoint ospitati in tempo reale, gli endpoint di inferenza asincrona supportano il ridimensionamento delle istanze a zero impostando la capacità minima su zero. Per gli endpoint asincroni, SageMaker consiglia vivamente di creare una configurazione della policy per il ridimensionamento del monitoraggio della destinazione per un modello distribuito (variante). Per i casi d'uso che possono tollerare una penalità di avvio a freddo di pochi minuti, puoi facoltativamente ridurre a zero il conteggio delle istanze dell'endpoint quando non ci sono richieste in sospeso e aumentare il backup all'arrivo di nuove richieste in modo da pagare solo per la durata del gli endpoint stanno elaborando attivamente le richieste. |
Schema del traffico | Gli endpoint asincroni accodano le richieste in arrivo e le elaborano in modo asincrono. Sono una buona opzione per schemi di traffico intermittenti o poco frequenti. |
Inferenza batch in SageMaker
La trasformazione in batch di SageMaker è ideale per le previsioni offline su grandi batch di dati disponibili in anticipo. La funzionalità di trasformazione batch è un metodo ad alte prestazioni e ad alto rendimento per la trasformazione dei dati e la generazione di inferenze. È ideale per gli scenari in cui si gestiscono grandi batch di dati, non è necessaria una latenza inferiore al secondo o è necessario preelaborare e trasformare i dati di training. I clienti in determinati domini come la pubblicità e il marketing o l'assistenza sanitaria spesso hanno bisogno di fare previsioni offline su set di dati iperscalabili in cui il throughput elevato è spesso l'obiettivo del caso d'uso e la latenza non è un problema.
Quando viene avviato un processo di trasformazione in batch, SageMaker inizializza le istanze di calcolo e distribuisce il carico di lavoro di inferenza tra di esse. Rilascia le risorse quando i lavori sono completati, quindi paghi solo per ciò che è stato utilizzato durante l'esecuzione del tuo lavoro. Quando il lavoro è completo, SageMaker salva i risultati della previsione in un bucket S3 da te specificato. Le attività di inferenza batch sono in genere buone candidate per il ridimensionamento orizzontale. Ogni lavoratore all'interno di un cluster può operare su un diverso sottoinsieme di dati senza la necessità di scambiare informazioni con altri lavoratori. AWS offre più opzioni di archiviazione e calcolo che consentono il ridimensionamento orizzontale. I carichi di lavoro di esempio per la trasformazione batch di SageMaker includono applicazioni offline come le applicazioni bancarie per prevedere l'abbandono dei clienti in cui è possibile pianificare l'esecuzione periodica di un lavoro offline.
La tabella seguente fornisce indicazioni sulla valutazione della trasformazione batch di SageMaker in base alle funzioni di fitness.
Funzione fitness | Descrizione |
Costo | La trasformazione batch di SageMaker consente di eseguire previsioni su set di dati batch grandi o piccoli. Ti viene addebitato il tipo di istanza che scegli, in base alla durata di utilizzo. SageMaker gestisce il provisioning delle risorse all'inizio del lavoro e le rilascia al termine del lavoro. Non ci sono costi aggiuntivi per l'elaborazione dei dati. |
Latenza di inferenza | È possibile utilizzare l'invocazione basata su eventi o pianificata. La latenza può variare a seconda delle dimensioni dei dati di inferenza, della concorrenza dei processi, della complessità del modello e della capacità dell'istanza di calcolo. |
Throughput |
I processi di trasformazione in batch possono essere eseguiti su una vasta gamma di set di dati, da petabyte di dati a set di dati molto piccoli. Non è necessario ridimensionare set di dati più grandi in piccoli blocchi di dati. È possibile velocizzare i processi di trasformazione batch utilizzando valori ottimali per parametri quali Carico utile massimo in MB, MaxConcurrentTransforms, o BatchStrategia. Il valore ideale per L'elaborazione in batch può aumentare la velocità effettiva e ottimizzare le risorse perché aiuta a completare un numero maggiore di inferenze in un determinato periodo di tempo a scapito della latenza. Per ottimizzare la distribuzione del modello per una maggiore velocità effettiva, la linea guida generale consiste nell'aumentare le dimensioni del batch finché la velocità effettiva non diminuisce. |
Scalare la complessità della configurazione | La trasformazione batch di SageMaker viene utilizzata per l'inferenza offline che non è sensibile alla latenza. |
Schema del traffico | Per l'inferenza offline, un processo di trasformazione batch viene pianificato o avviato utilizzando un trigger basato su eventi. |
Inferenza serverless in SageMaker
L'inferenza serverless di SageMaker consente di distribuire modelli ML per l'inferenza senza dover configurare o gestire l'infrastruttura sottostante. In base al volume di richieste di inferenza ricevute dal tuo modello, l'inferenza serverless di SageMaker esegue automaticamente il provisioning, la scalabilità e la disattivazione della capacità di calcolo. Di conseguenza, paghi solo per il tempo di elaborazione per eseguire il codice di inferenza e la quantità di dati elaborati, non per il tempo di inattività. Puoi utilizzare gli algoritmi integrati di SageMaker e i contenitori di servizio del framework ML per distribuire il tuo modello a un endpoint di inferenza serverless o scegliere di portare il tuo contenitore. Se il traffico diventa prevedibile e stabile, puoi eseguire facilmente l'aggiornamento da un endpoint di inferenza serverless a un endpoint SageMaker in tempo reale senza la necessità di apportare modifiche all'immagine del tuo container. Con l'inferenza serverless, puoi beneficiare anche di altre funzionalità di SageMaker, inclusi parametri integrati come numero di chiamate, errori, latenza, parametri dell'host ed errori in CloudWatch.
La tabella seguente fornisce indicazioni sulla valutazione dell'inferenza serverless di SageMaker in base alle funzioni di fitness.
Funzione fitness | Descrizione |
Costo | Con un modello pay-as-you-run, l'inferenza serverless è un'opzione conveniente se si dispone di modelli di traffico poco frequenti o intermittenti. Paghi solo per la durata per la quale l'endpoint elabora la richiesta e quindi puoi risparmiare sui costi se il modello di traffico è intermittente. |
Latenza di inferenza |
Gli endpoint serverless offrono una bassa latenza di inferenza (nell'ordine da millisecondi a secondi), con la possibilità di scalare istantaneamente da decine a migliaia di inferenze in pochi secondi in base ai modelli di utilizzo, rendendolo ideale per le applicazioni ML con traffico intermittente o imprevedibile. Poiché gli endpoint serverless eseguono il provisioning delle risorse di calcolo su richiesta, l'endpoint potrebbe subire alcuni secondi in più di latenza (avvio a freddo) per la prima chiamata dopo un periodo di inattività. L'ora di avvio a freddo dipende dalle dimensioni del modello, dal tempo necessario per scaricare il modello e dall'ora di avvio del contenitore. |
Throughput | Durante la configurazione dell'endpoint serverless, puoi specificare la dimensione della memoria e il numero massimo di chiamate simultanee. L'inferenza serverless di SageMaker assegna automaticamente risorse di calcolo proporzionali alla memoria selezionata. Se scegli una dimensione di memoria maggiore, il tuo container ha accesso a più vCPU. Come regola generale, la dimensione della memoria dovrebbe essere grande almeno quanto la dimensione del modello. Le dimensioni della memoria che puoi scegliere sono 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB e 6144 MB. Indipendentemente dalla dimensione della memoria scelta, gli endpoint serverless hanno a disposizione 5 GB di storage su disco temporaneo. |
Scalare la complessità della configurazione | Gli endpoint serverless avviano automaticamente le risorse di calcolo e le ridimensionano in base al traffico, eliminando la necessità di scegliere i tipi di istanza o gestire le policy di dimensionamento. Questo toglie il lavoro pesante indifferenziato di selezionare e gestire i server. |
Schema del traffico | L'inferenza serverless è ideale per i carichi di lavoro con schemi di traffico poco frequenti o intermittenti. |
Modello di hosting dei modelli di progettazione in SageMaker
Gli endpoint di inferenza SageMaker utilizzano i container Docker per l'hosting dei modelli ML. I contenitori consentono di impacchettare il software in unità standardizzate che vengono eseguite in modo coerente su qualsiasi piattaforma che supporti Docker. Ciò garantisce la portabilità tra piattaforme, distribuzioni immutabili dell'infrastruttura e una più semplice gestione delle modifiche e implementazioni CI/CD. SageMaker fornisce container gestiti predefiniti per framework popolari come Apache MXNet, TensorFlow, PyTorch, Sklearn e Hugging Face. Per un elenco completo delle immagini dei contenitori SageMaker disponibili, fare riferimento a Immagini disponibili dei contenitori di apprendimento profondo. Nel caso in cui SageMaker non disponga di un contenitore supportato, puoi anche creare il tuo contenitore (BYOC) e inviare la tua immagine personalizzata, installando le dipendenze necessarie per il tuo modello.
Per distribuire un modello su SageMaker, è necessario un contenitore (contenitori del framework gestito SageMaker o BYOC) e un'istanza di calcolo per ospitare il contenitore. SageMaker supporta più opzioni avanzate per modelli di progettazione di hosting di modelli ML comuni in cui i modelli possono essere ospitati su un singolo contenitore o co-ospitati su un contenitore condiviso.
Un'applicazione ML in tempo reale può utilizzare un singolo modello o più modelli per soddisfare una singola richiesta di previsione. Il diagramma seguente mostra vari scenari di inferenza per un'applicazione ML.
Esploriamo un'opzione di hosting SageMaker adatta per ciascuno dei precedenti scenari di inferenza. Puoi fare riferimento alle funzioni di fitness per valutare se è l'opzione giusta per il caso d'uso specificato.
Hosting di un'applicazione ML basata su un singolo modello
Esistono diverse opzioni per ospitare applicazioni ML basate su un singolo modello utilizzando i servizi di hosting SageMaker a seconda dello scenario di distribuzione.
Endpoint a modello singolo
Gli endpoint SageMaker a modello singolo ti consentono di ospitare un modello su un container ospitato su istanze dedicate per una bassa latenza e un throughput elevato. Questi endpoint sono completamente gestiti e supportano il ridimensionamento automatico. Puoi configurare l'endpoint a modello singolo come endpoint con provisioning in cui passi la configurazione dell'infrastruttura dell'endpoint come il tipo e il numero di istanze o un endpoint serverless in cui SageMaker avvia automaticamente le risorse di calcolo e le ridimensiona in base al traffico, eliminando la necessità per scegliere i tipi di istanza o gestire le policy di dimensionamento. Gli endpoint serverless sono per le applicazioni con traffico intermittente o imprevedibile.
Il diagramma seguente mostra gli scenari di inferenza dell'endpoint a modello singolo.
La tabella seguente fornisce indicazioni sulla valutazione delle funzioni di idoneità per un endpoint a modello singolo di cui è stato eseguito il provisioning. Per le valutazioni della funzione di fitness dell'endpoint serverless, fare riferimento alla sezione dell'endpoint serverless in questo post.
Funzione fitness | Descrizione |
Costo | Ti viene addebitato l'utilizzo del tipo di istanza che scegli. Poiché l'endpoint è sempre in esecuzione e disponibile, i costi possono aumentare rapidamente. La scelta dell'istanza giusta per il tuo modello ti assicura di avere l'istanza più performante al minor costo per i tuoi modelli. Si consiglia il ridimensionamento automatico per regolare dinamicamente la capacità in base al traffico per mantenere prestazioni costanti e prevedibili al costo più basso possibile. |
Latenza di inferenza | Un endpoint a modello singolo fornisce inferenza sincrona, interattiva e in tempo reale con requisiti di latenza di millisecondi. |
Throughput | La velocità effettiva può essere influenzata da vari fattori, come la dimensione dell'input del modello, la dimensione del batch, il tipo di istanza dell'endpoint e così via. Si consiglia di esaminare i parametri CloudWatch per le richieste di input e l'utilizzo delle risorse e selezionare il tipo di istanza appropriato per ottenere un throughput ottimale. SageMaker fornisce funzionalità per gestire le risorse e ottimizzare le prestazioni di inferenza durante la distribuzione di modelli ML. Puoi ottimizzare le prestazioni del modello utilizzando Neooppure utilizza le istanze Inf1 per una migliore velocità effettiva dei tuoi modelli ospitati da SageMaker utilizzando un'istanza GPU per il tuo endpoint. |
Scalare la complessità della configurazione | Il ridimensionamento automatico è supportato per impostazione predefinita. SageMaker consiglia di scegliere un file appropriato configurazione in scala eseguendo prove di carico. |
Schema del traffico | Un endpoint a modello singolo è ideale per i carichi di lavoro con modelli di traffico prevedibili. |
Co-hosting di più modelli
Quando hai a che fare con un numero elevato di modelli, la distribuzione di ognuno su un singolo endpoint con un contenitore e un'istanza dedicati può comportare un aumento significativo dei costi. Inoltre, diventa anche difficile gestire così tanti modelli in produzione, in particolare quando non è necessario richiamare tutti i modelli contemporaneamente ma è comunque necessario che siano sempre disponibili. Il co-hosting di più modelli sulle stesse risorse di elaborazione sottostanti semplifica la gestione delle distribuzioni ML su larga scala e riduce i costi di hosting grazie a un maggiore utilizzo dell'endpoint e delle relative risorse di elaborazione sottostanti. SageMaker supporta opzioni avanzate di co-hosting di modelli come endpoint multi-modello (MME) per modelli omogenei e endpoint multi-container (MCE) per modelli eterogenei. I modelli omogenei utilizzano lo stesso framework ML su un contenitore di servizi condiviso, mentre i modelli eterogenei consentono di distribuire più contenitori di servizio che utilizzano modelli o framework diversi su un singolo endpoint.
Il diagramma seguente mostra le opzioni di co-hosting del modello utilizzando SageMaker.
Endpoint multimodello SageMaker
SageMaker MME consentono di ospitare più modelli utilizzando un contenitore di servizio condiviso su un singolo endpoint. Si tratta di una soluzione scalabile ed economica per distribuire un numero elevato di modelli che soddisfano lo stesso caso d'uso, framework o logica di inferenza. Gli MME possono servire dinamicamente le richieste in base al modello invocato dal chiamante. Riduce anche il sovraccarico di distribuzione perché SageMaker gestisce il caricamento dei modelli in memoria e il loro ridimensionamento in base ai modelli di traffico verso di essi. Questa funzione è ideale quando si dispone di un numero elevato di modelli simili che è possibile servire tramite un contenitore di pubblicazione condiviso e non è necessario accedere a tutti i modelli contemporaneamente. Gli endpoint multi-modello consentono inoltre la condivisione del tempo delle risorse di memoria tra i tuoi modelli. Funziona meglio quando i modelli sono abbastanza simili per dimensioni e latenza di chiamata, consentendo alle MME di utilizzare efficacemente le istanze in tutti i modelli. Gli MME SageMaker supportano l'hosting di modelli supportati da CPU e GPU. Utilizzando modelli supportati da GPU, puoi ridurre i costi di distribuzione del modello attraverso un maggiore utilizzo dell'endpoint e delle relative istanze di calcolo accelerato sottostanti. Per un caso d'uso reale di MME, fare riferimento a Come ridimensionare l'inferenza di machine learning per casi d'uso SaaS multi-tenant.
La tabella seguente fornisce indicazioni sulla valutazione delle funzioni di fitness per le MME.
Funzione fitness | Descrizione |
Costo |
Gli MME consentono di utilizzare un contenitore di servizio condiviso per ospitare migliaia di modelli su un singolo endpoint. Ciò riduce significativamente i costi di hosting migliorando l'utilizzo degli endpoint rispetto all'utilizzo di endpoint a modello singolo. Ad esempio, se hai 10 modelli da distribuire utilizzando un'istanza ml.c5.large, basata su Prezzi di SageMaker, il costo per avere 10 endpoint persistenti a modello singolo è: 10 * $ 0.102 = $ 1.02 all'ora. Considerando che con un MME che ospita i 10 modelli, otteniamo risparmi sui costi 10 volte: 1 * $ 0.102 = $ 0.102 all'ora. |
Latenza di inferenza |
Per impostazione predefinita, gli MME memorizzano nella cache i modelli utilizzati di frequente in memoria e su disco per fornire inferenza a bassa latenza. I modelli memorizzati nella cache vengono scaricati o eliminati dal disco solo quando un contenitore esaurisce la memoria o lo spazio su disco per accogliere un nuovo modello di destinazione. Gli MME consentono il caricamento lento dei modelli, il che significa che i modelli vengono caricati in memoria quando vengono richiamati per la prima volta. Questo ottimizza l'utilizzo della memoria; tuttavia, provoca picchi di tempo di risposta al primo caricamento, con conseguenti problemi di avvio a freddo. Pertanto, gli MME sono adatti anche a scenari che possono tollerare occasionali penalizzazioni di latenza legate all'avvio a freddo che si verificano quando si richiamano modelli usati di rado. Per soddisfare gli obiettivi di latenza e throughput delle applicazioni ML, le istanze GPU sono preferite rispetto alle istanze CPU (data la potenza computazionale offerta dalle GPU). Con il supporto MME per GPU, puoi implementare migliaia di modelli di deep learning dietro un endpoint SageMaker. Gli MME possono eseguire più modelli su un core GPU, condividere istanze GPU dietro un endpoint su più modelli e caricare e scaricare dinamicamente i modelli in base al traffico in entrata. Con questo, puoi risparmiare in modo significativo sui costi e ottenere il miglior rapporto qualità-prezzo. Se il tuo caso d'uso richiede transazioni al secondo (TPS) o requisiti di latenza significativamente più elevati, ti consigliamo di ospitare i modelli su endpoint dedicati. |
Throughput |
Un valore ideale del throughput di inferenza MME dipende da fattori quali modello, dimensioni del payload e tipo di istanza dell'endpoint. Una maggiore quantità di memoria dell'istanza consente di avere più modelli caricati e pronti a servire le richieste di inferenza. Non è necessario perdere tempo a caricare il modello. Una quantità maggiore di vCPU consente di richiamare più modelli univoci contemporaneamente. Gli MME caricano e scaricano dinamicamente il modello da e verso la memoria dell'istanza, il che può influire sulle prestazioni di I/O. Gli MME SageMaker con GPU funzionano utilizzando Server di inferenza NVIDIA Triton, che è un software di servizio di inferenza open source che semplifica il processo di servizio di inferenza e fornisce prestazioni di inferenza elevate. SageMaker carica il modello nella memoria del container NVIDIA Triton su un'istanza con accelerazione GPU e serve la richiesta di inferenza. Il core della GPU è condiviso da tutti i modelli in un'istanza. Se il modello è già caricato nella memoria del contenitore, le richieste successive vengono servite più velocemente perché SageMaker non ha bisogno di scaricarlo e caricarlo di nuovo. Un test e un'analisi delle prestazioni adeguati sono consigliati nelle distribuzioni di produzione di successo. SageMaker fornisce parametri CloudWatch per endpoint multi-modello in modo da poter determinare l'utilizzo dell'endpoint e la percentuale di riscontri nella cache per ottimizzare l'endpoint. |
Scalare la complessità della configurazione | Gli endpoint multi-modello SageMaker supportano completamente il ridimensionamento automatico, che gestisce le repliche dei modelli per garantire la scalabilità dei modelli in base ai modelli di traffico. Tuttavia, si consiglia un test di carico adeguato per determinare la dimensione ottimale delle istanze per il ridimensionamento automatico dell'endpoint. Il giusto dimensionamento della flotta MME è importante per evitare lo scarico di troppi modelli. Il caricamento di centinaia di modelli su poche istanze più grandi può portare a limitazioni in alcuni casi e potrebbe essere preferibile l'utilizzo di più istanze più piccole. Per sfruttare il ridimensionamento automatico dei modelli in SageMaker, assicurati di averlo impostazione del ridimensionamento automatico dell'istanza per eseguire il provisioning di ulteriore capacità di istanza. Configura la policy di dimensionamento a livello di endpoint con parametri personalizzati o chiamate al minuto (consigliate) per aggiungere più istanze al parco di endpoint. I tassi di chiamata usati per attivare un evento di scalabilità automatica si basano sul set aggregato di previsioni nell'intero set di modelli serviti dall'endpoint. |
Schema del traffico | Gli MME sono ideali quando si dispone di un numero elevato di modelli di dimensioni simili che è possibile servire tramite un contenitore di servizio condiviso e non è necessario accedere a tutti i modelli contemporaneamente. |
Endpoint multi-contenitore SageMaker
SageMaker MCE supporta la distribuzione di un massimo di 15 container che utilizzano modelli o framework diversi su un singolo endpoint e il loro richiamo in modo indipendente o in sequenza per l'inferenza a bassa latenza e il risparmio sui costi. I modelli possono essere completamente eterogenei, con il proprio stack di servizio indipendente. L'hosting sicuro di più modelli da diversi framework su una singola istanza potrebbe farti risparmiare fino al 90% sui costi.
I modelli di chiamata MCE sono i seguenti:
- Condutture di inferenza – I contenitori in un MME possono essere richiamati in una sequenza lineare, nota anche come a pipeline di inferenza seriale. In genere vengono utilizzati per separare la pre-elaborazione, l'inferenza del modello e la post-elaborazione in contenitori indipendenti. L'output del contenitore corrente viene passato come input al contenitore successivo. Sono rappresentati come un singolo modello di pipeline in SageMaker. Una pipeline di inferenza può essere distribuita come MME, in cui uno dei contenitori nella pipeline può servire dinamicamente le richieste in base al modello richiamato.
- Invocazione diretta - Con invocazione diretta, è possibile inviare una richiesta a un contenitore di inferenza specifico ospitato su un MCE.
La tabella seguente fornisce indicazioni sulla valutazione delle funzioni di fitness per MCE.
Funzione fitness | Descrizione |
Costo | Gli MCE consentono di eseguire fino a 15 contenitori ML diversi su un singolo endpoint e di richiamarli in modo indipendente, risparmiando così sui costi. Questa opzione è ideale quando disponi di più modelli in esecuzione su diversi stack di servizio con esigenze di risorse simili e quando i singoli modelli non dispongono di traffico sufficiente per utilizzare la piena capacità delle istanze dell'endpoint. Gli MCE sono quindi più convenienti rispetto a un endpoint a modello singolo. Gli MCE offrono una risposta di inferenza sincrona, il che significa che l'endpoint è sempre disponibile e paghi per il tempo di attività dell'istanza. Il costo può aumentare a seconda del numero e del tipo di istanze. |
Latenza di inferenza | Gli MCE sono ideali per l'esecuzione di app ML con diversi framework e algoritmi ML per ogni modello a cui si accede raramente ma che richiedono comunque un'inferenza a bassa latenza. I modelli sono sempre disponibili per l'inferenza a bassa latenza e non ci sono problemi di avvio a freddo. |
Throughput | Gli MCE sono limitati a un massimo di 15 container su un endpoint multi-container e l'inferenza GPU non è supportata a causa di conflitti di risorse. Per gli endpoint multi-container che utilizzano la modalità di chiamata diretta, SageMaker non solo fornisce parametri a livello di istanza come fa con altri endpoint comuni, ma supporta anche parametri per contenitore. Come best practice, esamina i parametri di CloudWatch per le richieste di input e l'utilizzo delle risorse e seleziona il tipo di istanza appropriato per ottenere un throughput ottimale. |
Scalare la complessità della configurazione | Gli MCE supportano il ridimensionamento automatico. Tuttavia, per configurare il ridimensionamento automatico, è consigliabile che il modello in ogni contenitore mostri un utilizzo della CPU e una latenza simili per ogni richiesta di inferenza. Questa operazione è consigliata perché se il traffico verso l'endpoint multi-container passa da un modello a basso utilizzo della CPU a un modello a elevato utilizzo della CPU, ma il volume complessivo delle chiamate rimane lo stesso, l'endpoint non si ridimensiona e potrebbero non esserci abbastanza istanze per gestire tutte le richieste al modello ad alto utilizzo della CPU. |
Schema del traffico | Gli MCE sono ideali per carichi di lavoro con schemi di traffico continui o regolari, per l'hosting di modelli su diversi framework (come TensorFlow, PyTorch o Sklearn) che potrebbero non avere traffico sufficiente per saturare la piena capacità di un'istanza di endpoint. |
Hosting di un'applicazione ML basata su più modelli
Molte applicazioni aziendali devono utilizzare più modelli ML per servire una singola richiesta di previsione ai propri consumatori. Ad esempio, una società di vendita al dettaglio che desidera fornire consigli ai propri utenti. L'applicazione ML in questo caso d'uso potrebbe voler utilizzare diversi modelli personalizzati per consigliare diverse categorie di prodotti. Se l'azienda desidera aggiungere la personalizzazione ai suggerimenti utilizzando le informazioni sui singoli utenti, il numero di modelli personalizzati aumenta ulteriormente. L'hosting di ogni modello personalizzato su un'istanza di calcolo distinta non è solo proibitivo in termini di costi, ma porta anche a un sottoutilizzo delle risorse di hosting se non tutti i modelli vengono utilizzati di frequente. SageMaker offre opzioni di hosting efficienti per applicazioni ML basate su più modelli.
Il diagramma seguente mostra le opzioni di hosting multi-modello per un singolo endpoint che utilizza SageMaker.
Pipeline di inferenza seriale
Una pipeline di inferenza è un modello SageMaker composto da una sequenza lineare di 2-15 contenitori che elaborano le richieste di inferenze sui dati. Utilizzi una pipeline di inferenza per definire e distribuire qualsiasi combinazione di algoritmi integrati SageMaker preaddestrati e i tuoi algoritmi personalizzati impacchettati nei container Docker. È possibile utilizzare una pipeline di inferenza per combinare attività di data science di pre-elaborazione, previsioni e post-elaborazione. L'output di un contenitore viene passato come input al successivo. Quando si definiscono i contenitori per un modello di pipeline, si specifica anche l'ordine in cui vengono eseguiti i contenitori. Sono rappresentati come un singolo modello di pipeline in SageMaker. La pipeline di inferenza può essere distribuita come MME, in cui uno dei contenitori nella pipeline può servire dinamicamente le richieste in base al modello richiamato. Puoi anche eseguire un file trasformazione batch lavoro con una pipeline di inferenza. Le pipeline di inferenza sono completamente gestite.
La tabella seguente fornisce indicazioni sulla valutazione delle funzioni di fitness per l'hosting di modelli ML usando una pipeline di inferenza seriale.
Funzione fitness | Descrizione |
Costo | La pipeline di inferenza seriale consente di eseguire fino a 15 contenitori ML diversi su un singolo endpoint, con conseguente convenienza economica dell'hosting dei contenitori di inferenza. Non ci sono costi aggiuntivi per l'utilizzo di questa funzione. Paghi solo per le istanze in esecuzione su un endpoint. Il costo può aumentare a seconda del numero e del tipo di istanze. |
Latenza di inferenza | Quando un'applicazione ML viene distribuita come pipeline di inferenza, i dati tra diversi modelli non lasciano lo spazio del contenitore. L'elaborazione delle funzionalità e le inferenze vengono eseguite con bassa latenza perché i container si trovano nelle stesse istanze EC2. |
Throughput | All'interno di un modello di pipeline di inferenza, SageMaker gestisce le chiamate come una sequenza di richieste HTTP. Il primo contenitore nella pipeline gestisce la richiesta iniziale, quindi la risposta intermedia viene inviata come richiesta al secondo contenitore e così via per ogni contenitore nella pipeline. SageMaker restituisce la risposta finale al client. La velocità effettiva è soggettiva a fattori quali il modello, la dimensione dell'input del modello, la dimensione del batch e il tipo di istanza dell'endpoint. Come best practice, esamina i parametri di CloudWatch per le richieste di input e l'utilizzo delle risorse e seleziona il tipo di istanza appropriato per ottenere un throughput ottimale. |
Scalare la complessità della configurazione | Le pipeline di inferenza seriale supportano il ridimensionamento automatico. Tuttavia, per configurare il ridimensionamento automatico, è consigliabile che il modello in ogni contenitore mostri un utilizzo della CPU e una latenza simili per ogni richiesta di inferenza. Questa operazione è consigliata perché se il traffico verso l'endpoint multi-container passa da un modello a basso utilizzo della CPU a un modello a elevato utilizzo della CPU, ma il volume complessivo delle chiamate rimane lo stesso, l'endpoint non si ridimensiona e potrebbero non esserci abbastanza istanze per gestire tutte le richieste al modello ad alto utilizzo della CPU. |
Schema del traffico |
Le pipeline di inferenza seriale sono ideali per modelli di traffico prevedibili con modelli che vengono eseguiti in sequenza sullo stesso endpoint. |
Distribuzione di insiemi di modelli (Triton DAG):
SageMaker offre l'integrazione con Server di inferenza NVIDIA Triton attraverso Contenitori del server di inferenza Triton. Questi container includono NVIDIA Triton Inference Server, supporto per framework ML comuni e utili variabili di ambiente che consentono di ottimizzare le prestazioni su SageMaker. Con le immagini dei container NVIDIA Triton, puoi servire facilmente i modelli ML e beneficiare delle ottimizzazioni delle prestazioni, del batch dinamico e del supporto multi-framework fornito da NVIDIA Triton. Triton aiuta a massimizzare l'utilizzo di GPU e CPU, riducendo ulteriormente il costo dell'inferenza.
Nei casi d'uso aziendali in cui le applicazioni ML utilizzano diversi modelli per soddisfare una richiesta di previsione, se ogni modello utilizza un framework diverso o è ospitato su un'istanza separata, può comportare un aumento del carico di lavoro e dei costi, nonché un aumento della latenza complessiva. SageMaker NVIDIA Triton Inference Server supporta la distribuzione di modelli da tutti i principali framework, come TensorFlow GraphDef, TensorFlow SavedModel, ONNX, PyTorch TorchScript, TensorRT e formati di modelli Python/C++ e altro ancora. L'ensemble di modelli Triton rappresenta una pipeline di uno o più modelli o logica di pre-elaborazione e post-elaborazione e la connessione di tensori di input e output tra di essi. Una singola richiesta di inferenza a un ensemble attiva l'esecuzione dell'intera pipeline. Triton ha anche più algoritmi di pianificazione e batch incorporati che combinano le singole richieste di inferenza per migliorare il throughput dell'inferenza. Queste decisioni di pianificazione e batch sono trasparenti per il client che richiede l'inferenza. I modelli possono essere eseguiti su CPU o GPU per la massima flessibilità e per supportare requisiti di elaborazione eterogenei.
L'hosting di più modelli supportati da GPU su endpoint multi-modello è supportato tramite il Server di inferenza SageMaker Triton. Il server di inferenza NVIDIA Triton è stato esteso per implementare un Contratto API MME, da integrare con MME. Puoi utilizzare NVIDIA Triton Inference Server, che crea una configurazione di repository di modelli per diversi backend del framework, per distribuire un MME con ridimensionamento automatico. Questa funzionalità consente di ridimensionare centinaia di modelli iper-personalizzati che sono ottimizzati per soddisfare esperienze uniche dell'utente finale nelle applicazioni AI. Puoi anche utilizzare questa funzione per ottenere le prestazioni di prezzo necessarie per la tua applicazione di inferenza utilizzando GPU frazionarie. Per saperne di più, fare riferimento a Esegui più modelli di deep learning su GPU con gli endpoint multimodello Amazon SageMaker.
La tabella seguente fornisce indicazioni sulla valutazione delle funzioni di fitness per l'hosting di modelli ML usando MME con supporto GPU su contenitori di inferenza Triton. Per gli endpoint a modello singolo e le valutazioni della funzione di idoneità dell'endpoint serverless, fare riferimento alle sezioni precedenti di questo post.
Funzione fitness | Descrizione |
Costo | Gli MME SageMaker con supporto GPU che utilizzano Triton Inference Server forniscono un modo scalabile ed economico per implementare un gran numero di modelli di deep learning dietro un endpoint SageMaker. Con MME, più modelli condividono l'istanza GPU dietro un endpoint. Ciò consente di abbattere il costo in aumento lineare dell'hosting di più modelli e di riutilizzare l'infrastruttura in tutti i modelli. Paghi per il tempo di attività dell'istanza. |
Latenza di inferenza |
SageMaker con Triton Inference Server è progettato appositamente per massimizzare il throughput e l'utilizzo dell'hardware con una latenza di inferenza estremamente bassa (una cifra in millisecondi). Dispone di un'ampia gamma di framework ML supportati (tra cui TensorFlow, PyTorch, ONNX, XGBoost e NVIDIA TensorRT) e back-end dell'infrastruttura, tra cui GPU NVIDIA, CPU e AWS Inferenza. Con il supporto MME per GPU che utilizza SageMaker Triton Inference Server, puoi implementare migliaia di modelli di deep learning dietro un endpoint SageMaker. SageMaker carica il modello nella memoria del container NVIDIA Triton su un'istanza con accelerazione GPU e serve la richiesta di inferenza. Il core della GPU è condiviso da tutti i modelli in un'istanza. Se il modello è già caricato nella memoria del contenitore, le richieste successive vengono servite più velocemente perché SageMaker non ha bisogno di scaricarlo e caricarlo di nuovo. |
Throughput |
Gli MME offrono funzionalità per l'esecuzione simultanea di più modelli di deep learning o ML sulla GPU con Triton Inference Server. Ciò consente di utilizzare facilmente il servizio di inferenza ad alte prestazioni multi-framework di NVIDIA Triton con la distribuzione del modello completamente gestita di SageMaker. Triton supporta tutte le inferenze basate su GPU NVIDIA, x86, Arm® CPU e AWS Inferentia. Offre batch dinamico, esecuzioni simultanee, configurazione ottimale del modello, insieme di modelli e input audio e video in streaming per massimizzare la produttività e l'utilizzo. Altri fattori come la rete e le dimensioni del payload possono svolgere un ruolo minimo nell'overhead associato all'inferenza. |
Scalare la complessità della configurazione |
Gli MME possono scalare orizzontalmente utilizzando una policy di ridimensionamento automatico e fornire istanze di calcolo GPU aggiuntive in base a metriche come Con il server di inferenza Triton, puoi facilmente creare un contenitore personalizzato che includa il tuo modello con Triton e portarlo a SageMaker. SageMaker Inference gestirà le richieste e ridimensionerà automaticamente il container all'aumentare dell'utilizzo, semplificando la distribuzione del modello con Triton su AWS. |
Schema del traffico |
Gli MME sono ideali per modelli di traffico prevedibili con modelli eseguiti come DAG sullo stesso endpoint. SageMaker si occupa della modellatura del traffico verso l'endpoint MME e mantiene copie del modello ottimali sulle istanze GPU per il miglior rapporto prezzo/prestazioni. Continua a instradare il traffico all'istanza in cui viene caricato il modello. Se le risorse dell'istanza raggiungono la capacità a causa dell'utilizzo elevato, SageMaker scarica i modelli meno utilizzati dal container per liberare risorse per caricare i modelli utilizzati più frequentemente. |
Buone pratiche
Considera le seguenti best practice:
- Elevata coesione e basso accoppiamento tra i modelli – Ospita i modelli nello stesso contenitore che ha un'elevata coesione (favorisce la funzionalità di un'unica azienda) e li incapsula insieme per facilitare l'aggiornamento e la gestibilità. Allo stesso tempo, separa questi modelli l'uno dall'altro (ospitali in contenitori diversi) in modo da poter aggiornare facilmente un modello senza influire sugli altri modelli. Ospita più modelli che utilizzano contenitori diversi dietro un endpoint e li richiama in modo indipendente oppure aggiungi la logica di pre-elaborazione e post-elaborazione del modello come pipeline di inferenza seriale.
- Latenza di inferenza – Raggruppare i modelli basati su funzionalità aziendali singole e ospitarli in un unico contenitore per ridurre al minimo il numero di salti e quindi ridurre al minimo la latenza complessiva. Ci sono altri avvertimenti, come se i modelli raggruppati utilizzassero più framework; potresti anche scegliere di ospitare in più container ma eseguirli sullo stesso host per ridurre la latenza e minimizzare i costi.
- Raggruppa logicamente i modelli ML con elevata coesione – Il gruppo logico può essere costituito da modelli omogenei (ad esempio, tutti i modelli XGBoost) o eterogenei (ad esempio, alcuni XGBoost e alcuni BERT). Può consistere in modelli condivisi tra più funzionalità aziendali o può essere specifico per soddisfare solo una funzionalità aziendale.
- Modelli condivisi – Se il gruppo logico è costituito da modelli condivisi, la facilità di aggiornamento dei modelli e la latenza giocheranno un ruolo importante nell'architettura degli endpoint SageMaker. Ad esempio, se la latenza è una priorità, è meglio posizionare tutti i modelli in un singolo contenitore dietro un singolo endpoint SageMaker per evitare più hop. Lo svantaggio è che se uno qualsiasi dei modelli deve essere aggiornato, ciò comporterà l'aggiornamento di tutti gli endpoint SageMaker pertinenti che ospitano questo modello.
- Modelli non condivisi – Se il gruppo logico è costituito solo da modelli specifici di funzionalità aziendali e non è condiviso con altri gruppi, la complessità del packaging e le dimensioni della latenza diventeranno fondamentali per il raggiungimento. È consigliabile ospitare questi modelli in un singolo contenitore dietro un singolo endpoint SageMaker.
- Uso efficiente dell'hardware (CPU, GPU) – Raggruppa i modelli basati su CPU e ospitali sullo stesso host in modo da poter utilizzare la CPU in modo efficiente. Allo stesso modo, raggruppa i modelli basati su GPU in modo da poterli utilizzare e scalare in modo efficiente. Esistono carichi di lavoro ibridi che richiedono CPU e GPU sullo stesso host. L'hosting dei modelli solo CPU e solo GPU sullo stesso host deve essere guidato da elevati requisiti di coesione e latenza delle applicazioni. Inoltre, il costo, la capacità di ridimensionamento e il raggio dell'esplosione all'impatto in caso di guasto sono le dimensioni chiave da esaminare.
- Funzioni fitness – Utilizzare le funzioni di fitness come linea guida per la selezione di un'opzione di hosting ML.
Conclusione
Quando si tratta di hosting ML, non esiste un approccio unico per tutti. I professionisti del machine learning devono scegliere il modello di progettazione giusto per affrontare le sfide dell'hosting di machine learning. La valutazione delle funzioni di fitness fornisce indicazioni prescrittive sulla selezione dell'opzione di hosting ML corretta.
Per maggiori dettagli su ciascuna delle opzioni di hosting, fare riferimento ai seguenti post di questa serie:
Circa gli autori
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 l'inferenza del modello ad alte prestazioni su SageMaker.
Deepali Rajale è Technical Account Manager specializzato in AI/ML presso Amazon Web Services. Lavora con i clienti aziendali fornendo indicazioni tecniche sull'implementazione di soluzioni di machine learning con le best practice. Nel tempo libero le piace fare escursioni, film e uscire con la famiglia e gli amici.
Saurabh Trikande è un Senior Product Manager per Amazon SageMaker Inference. È appassionato di lavorare con i clienti ed è motivato dall'obiettivo di democratizzare l'apprendimento automatico. Si concentra sulle sfide principali relative all'implementazione di applicazioni ML complesse, modelli ML multi-tenant, ottimizzazioni dei costi e rendere più accessibile l'implementazione di modelli di deep learning. Nel tempo libero, Saurabh ama fare escursioni, conoscere tecnologie innovative, seguire TechCrunch e trascorrere del tempo con la sua famiglia.
- Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
- Platoblockchain. Web3 Metaverse Intelligence. Conoscenza amplificata. Accedi qui.
- Fonte: https://aws.amazon.com/blogs/machine-learning/model-hosting-patterns-in-amazon-sagemaker-part-1-common-design-patterns-for-building-ml-applications-on-amazon-sagemaker/
- 1
- 10
- 100
- 11
- 39
- 7
- 70
- a
- capacità
- capace
- Chi siamo
- accelerata
- accesso
- accessibile
- accessibile
- ospitare
- Il mio account
- preciso
- Raggiungere
- il raggiungimento
- operanti in
- Action
- attivamente
- aggiunta
- aggiuntivo
- Inoltre
- indirizzo
- avanzare
- Avanzate
- Vantaggio
- Pubblicità
- influenzare
- Dopo shavasana, sedersi in silenzio; saluti;
- aggregazione
- Aggregator
- aggressivo
- accordi
- AI
- AI / ML
- allarme
- Algoritmi
- Tutti
- Consentire
- consente
- già
- sempre
- Amazon
- Amazon EC2
- Amazon Sage Maker
- Amazon Web Services
- quantità
- .
- analizzare
- ed
- e infrastruttura
- annuale
- Un altro
- Apache
- api
- Apple
- Applicazioni
- applicazioni
- approccio
- opportuno
- applicazioni
- architettura
- ARM
- artificiale
- intelligenza artificiale
- aspetti
- valutazione
- associato
- gli attributi
- Audio
- audit
- auto
- Automatizzata
- Automatico
- automaticamente
- disponibilità
- disponibile
- media
- AWS
- precedente
- Backed
- Settore bancario
- base
- basato
- perché
- diventare
- diventa
- prima
- dietro
- essendo
- beneficio
- MIGLIORE
- best practice
- Meglio
- fra
- biomedico
- Bloccare
- Prestiti
- confini
- Scatola
- violazione
- Rompere
- portare
- Porta
- Per i bilanci
- costruire
- Costruzione
- costruito
- incassato
- affari
- Applicazioni aziendali
- Processo Di Business
- aziende
- Cache
- calcolato
- chiamata
- detto
- visitatore
- i candidati
- funzionalità
- Ultra-Grande
- che
- Custodie
- casi
- categoria
- cause
- certo
- Certificato
- sfide
- il cambiamento
- Modifiche
- caratteristiche
- carico
- chatbot
- dai un'occhiata
- patata fritta
- scegliere
- scelte
- Scegli
- la scelta
- classe
- classificazione
- classificare
- cliente
- clienti
- Chiudi
- Cloud
- Cluster
- codice
- coniato
- colleghi
- raccogliere
- combattere
- combinazione
- combinare
- combinato
- Uncommon
- Aziende
- azienda
- rispetto
- completamento di una
- completamente
- complesso
- complessità
- conformità
- componenti
- composto
- compromesso
- potenza computazionale
- Calcolare
- computer
- Visione computerizzata
- informatica
- concetto
- Problemi della Pelle
- concorrente
- Configurazione
- veloce
- coerente
- consumato
- Consumatori
- Contenitore
- Tecnologie Container
- contiene
- continua
- continua
- continuo
- di controllo
- Nucleo
- Corrispondente
- Costo
- risparmi
- costo effettivo
- Costi
- potuto
- creare
- crea
- critico
- cruciale
- Corrente
- costume
- cliente
- Clienti
- GIORNO
- dati
- elaborazione dati
- scienza dei dati
- scienziato di dati
- Banca Dati
- dataset
- giorno
- trattare
- decisioni
- dedicato
- deep
- apprendimento profondo
- Predefinito
- definizione
- consegnare
- Richiesta
- richieste
- democratizzare
- Dipendente
- dipende
- schierare
- schierato
- distribuzione
- deployment
- implementazioni
- Design
- modelli di progettazione
- progettato
- dettaglio
- dettagli
- rivelazione
- Determinare
- Costruttori
- Mercato
- diagrammi
- diverso
- difficile
- dimensioni
- dirette
- distinto
- distribuito
- calcolo distribuito
- paesaggio differenziato
- docker
- documenti
- non
- domini
- Dont
- giù
- scaricare
- svantaggio
- spinto
- caduto
- lancio
- durante
- dinamico
- ogni
- In precedenza
- più facile
- facilmente
- Efficace
- in maniera efficace
- efficacia
- efficienze
- efficiente
- in modo efficiente
- sforzo
- o
- eliminando
- enable
- Abilita
- crittografia
- da un capo all'altro
- endpoint
- Ingegneria
- Ingegneri
- abbastanza
- garantire
- assicura
- Impresa
- aziende
- Intero
- Ambiente
- errore
- errori
- particolarmente
- valutato
- valutazioni
- Anche
- Evento
- qualunque cosa
- evoluzione
- esempio
- Esempi
- exchange
- mostre
- attenderti
- previsto
- esperienza
- Esperienze
- esplora
- espressioni
- esterno
- extra
- Faccia
- Fattori
- Fallimento
- abbastanza
- famiglie
- famiglia
- più veloce
- caratteristica
- Caratteristiche
- alimentazione
- pochi
- finale
- Nome
- prima volta
- fitness
- FLOTTA
- Flessibilità
- flusso
- fluttuare
- si concentra
- i seguenti
- segue
- guado
- modulo
- forme
- frazionario
- Contesto
- quadri
- frode
- rilevazione di frodi
- Gratis
- Frequenza
- frequentemente
- amici
- da
- Frutta
- pieno
- completamente
- function
- funzionalità
- funzionalità
- funzioni
- ulteriormente
- GDPR
- Generale
- generato
- la generazione di
- ottenere
- Dare
- dato
- scopo
- Obiettivi
- buono
- GPU
- GPU
- grafico
- grande
- maggiore
- molto
- Gruppo
- Gruppo
- Crescere
- guida
- maniglia
- Maniglie
- a portata di mano
- Hardware
- avendo
- Salute e benessere
- assistenza sanitaria
- Aiuto
- aiutare
- aiuta
- qui
- Alta
- Alte prestazioni
- ad alta risoluzione
- superiore
- Colpire
- Orizzontale
- host
- ospitato
- di hosting
- costi di hosting
- servizi di hosting
- Come
- Tuttavia
- HTML
- HTTPS
- centinaia
- IBRIDO
- ideale
- Identità
- Idle
- Immagine
- Classificazione delle immagini
- immagini
- immutabile
- Impact
- impattato
- impatti
- realizzare
- implementato
- Implementazione
- importante
- competenze
- miglioramento
- in
- includere
- inclusi
- Compreso
- In arrivo
- Aumento
- è aumentato
- Aumenta
- crescente
- studente indipendente
- indipendentemente
- individuale
- informazioni
- Infrastruttura
- inizialmente
- creativi e originali
- tecnologie innovative
- ingresso
- installazione
- esempio
- invece
- integrare
- integrazione
- Intelligence
- interattivo
- coinvolgere
- ISO
- da solo
- IT
- Lavoro
- Offerte di lavoro
- Le
- Tasti
- Sapere
- conosciuto
- grandi
- superiore, se assunto singolarmente.
- Latenza
- lanciare
- lancia
- lancio
- portare
- principale
- Leads
- IMPARARE
- apprendimento
- Lasciare
- Guidato
- Livello
- biblioteche
- di sollevamento
- Limitato
- limiti
- Lista
- vivere
- caricare
- Caricamento in corso
- carichi
- località
- Lunghi
- più a lungo
- Guarda
- a
- lotto
- Basso
- macchina
- machine learning
- fatto
- Principale
- mantenere
- mantiene
- maggiore
- make
- FA
- Fare
- gestire
- gestito
- gestione
- direttore
- gestisce
- gestione
- molti
- Marketing
- matematico
- Importanza
- Massimizzare
- massimo
- si intende
- Soddisfare
- Memorie
- metodo
- metodi
- metrico
- Metrica
- forza
- minimo
- ordine
- Minuti
- Miscelazione
- ML
- Moda
- modello
- modelli
- Monitorare
- monitoraggio
- Mese
- mese
- Scopri di più
- maggior parte
- motivato
- Film
- Endpoint multimodello
- multiplo
- moltitudine
- Natura
- necessaria
- Bisogno
- esigenze
- Rete
- New
- GENERAZIONE
- nlp
- notifica
- notifiche
- numero
- Nvidia
- oggetto
- obiettivo
- Obiettivi d'Esame
- ottenendo
- occasionale
- offrire
- Offerte
- offline
- ONE
- online
- open source
- operare
- opera
- operativo
- operativa
- Operazioni
- Operatori
- ottimale
- ottimizzazione
- OTTIMIZZA
- ottimizzati
- Ottimizza
- ottimizzazione
- Opzione
- Opzioni
- Arancio
- minimo
- organizzazioni
- Altro
- eccezionale
- complessivo
- proprio
- proprietà
- pacchetto
- imballaggio
- parametri
- parte
- particolare
- partner
- Passato
- appassionato
- Patch
- Cartamodello
- modelli
- Paga le
- Corrente di
- Eseguire
- performance
- esecuzione
- periodo
- periodico
- periodi
- personalizzazione
- Personalizzata
- scegliere
- conduttura
- posto
- Partner
- previsto
- piani
- piattaforma
- Piattaforme
- Platone
- Platone Data Intelligence
- PlatoneDati
- Giocare
- più
- Termini e Condizioni
- politica
- Popolare
- possibile
- Post
- Post
- energia
- pratica
- pratiche
- Prevedibile
- previsione
- predizione
- Previsioni
- preferito
- in precedenza
- prezzo
- Direttore
- priorità
- un bagno
- Problema
- problemi
- processi
- Elaborato
- i processi
- lavorazione
- processori
- Prodotto
- product manager
- Produzione
- Prodotti
- Profilo
- corretto
- fornire
- purché
- fornisce
- fornitura
- fornitura
- delega
- scopo
- Spingi
- pytorch
- rapidamente
- gamma
- che vanno
- rapidamente
- tasso
- raggiungere
- raggiunge
- Leggi
- pronto
- di rose
- mondo reale
- tempo reale
- ricevere
- ricevuto
- riceve
- raccomandare
- Consigli
- raccomandazioni
- raccomandato
- raccomandando
- raccomanda
- ricorrenti
- ridurre
- riduce
- si riferisce
- Indipendentemente
- Basic
- relazionato
- Uscite
- pertinente
- resti
- deposito
- rappresentato
- rappresenta
- richiesta
- richieste
- richiedere
- necessario
- requisito
- Requisiti
- richiede
- risorsa
- Risorse
- risposta
- REST
- colpevole
- risultante
- Risultati
- nello specifico retail
- problemi
- recensioni
- Rischio
- Ruolo
- radice
- strada
- Regola
- Correre
- running
- SaaS
- sagemaker
- Inferenza di SageMaker
- stipendio
- stesso
- Risparmi
- risparmio
- Risparmio
- scalabile
- Scala
- bilancia
- scala
- Scenari
- programma
- in programma
- Scienze
- Scienziato
- Secondo
- secondo
- Sezione
- sezioni
- in modo sicuro
- problemi di
- Selezione
- prodotti
- anziano
- delicata
- Sequenza
- serial
- Serie
- servire
- serverless
- Server
- serve
- servizio
- Servizi
- servizio
- set
- regolazione
- alcuni
- sagomatura
- Condividi
- condiviso
- Turni
- dovrebbero
- Spettacoli
- significativa
- significativamente
- simile
- Allo stesso modo
- Un'espansione
- singolo
- Taglia
- Dimensioni
- piccole
- inferiore
- So
- Software
- soluzione
- Soluzioni
- alcuni
- fonti
- lo spazio
- specialista
- specializzata
- specifico
- in particolare
- specificato
- velocità
- Spendere
- picchi
- stabile
- pila
- Stacks
- inizia a
- iniziato
- inizio
- startup
- Startup
- costante
- step
- Passi
- Ancora
- Interrompe
- conservazione
- Tornare al suo account
- strategie
- Streaming
- Strict
- fortemente
- successivo
- il successo
- di successo
- tale
- sufficiente
- adatto
- supporto
- supportato
- supporti
- ondata
- tavolo
- Fai
- prende
- Target
- mirata
- Task
- task
- team
- le squadre
- TechCrunch
- Consulenza
- Tecnologie
- inquilino
- tensorflow
- test
- Testing
- I
- loro
- si
- in tal modo
- perciò
- migliaia
- tre
- soglia
- Attraverso
- per tutto
- portata
- tempo
- volte
- a
- insieme
- pure
- Totale
- tps
- Tracking
- traffico
- Treni
- allenato
- Training
- transazionale
- Le transazioni
- Trasformare
- Trasformazione
- trasformazione
- transito
- trasparente
- innescare
- tritone
- TURNO
- Tipi di
- tipico
- tipicamente
- per
- sottostante
- capire
- unico
- unità
- imprevedibile
- non usato
- Aggiornanento
- Aggiornamenti
- upgrade
- aggiornato
- uptime
- Impiego
- uso
- caso d'uso
- Utente
- utenti
- generalmente
- utilizzare
- utilizzati
- CONVALIDARE
- APPREZZIAMO
- Valori
- Variante
- vario
- via
- Video
- Video
- Visualizza
- virtuale
- visione
- volume
- Votazione
- voti
- Rifiuto
- sito web
- servizi web
- settimana
- Che
- Che cosa è l'
- quale
- while
- largo
- Vasta gamma
- volere
- entro
- senza
- Lavora
- lavorato
- lavoratore
- lavoratori
- lavoro
- lavori
- mondo
- sarebbe
- XGBoost
- anno
- Tu
- Trasferimento da aeroporto a Sharm
- zefiro
- zero