Uno dei modelli più popolari disponibili oggi è XGBoost. Con la capacità di risolvere vari problemi come la classificazione e la regressione, XGBoost è diventata un'opzione popolare che rientra anche nella categoria dei modelli basati su albero. In questo post, ci immergiamo in profondità per vedere come Amazon Sage Maker può servire questi modelli utilizzando Server di inferenza NVIDIA Triton. I carichi di lavoro di inferenza in tempo reale possono avere diversi livelli di requisiti e accordi sul livello di servizio (SLA) in termini di latenza e throughput e possono essere soddisfatti utilizzando gli endpoint in tempo reale di SageMaker.
SageMaker fornisce endpoint di un singolo modello, che consentono di distribuire un singolo modello di machine learning (ML) su un endpoint logico. Per altri casi d'uso, puoi scegliere di gestire i costi e le prestazioni utilizzando endpoint multi-modello, che consentono di specificare più modelli da ospitare dietro un endpoint logico. Indipendentemente dall'opzione scelta, gli endpoint SageMaker consentono un meccanismo scalabile anche per i clienti aziendali più esigenti, fornendo valore in una pletora di funzionalità, tra cui varianti d'ombra, ridimensionamento automaticoe integrazione nativa con Amazon Cloud Watch (per maggiori informazioni, vd Metriche di CloudWatch per distribuzioni di endpoint multimodello).
Triton supporta vari backend come motori per supportare l'esecuzione e la pubblicazione di vari modelli ML per l'inferenza. Per qualsiasi implementazione di Triton, è fondamentale sapere in che modo il comportamento del back-end influisce sui carichi di lavoro e cosa aspettarsi per avere successo. In questo post, ti aiutiamo a capire il Back-end FIL (Forest Inference Library)., che è supportato da Triton su SageMaker, in modo che tu possa prendere una decisione informata per i tuoi carichi di lavoro e ottenere le migliori prestazioni e l'ottimizzazione dei costi possibili.
Immergiti nel backend di FIL
Triton supporta il back-end FIL per servire modelli di albero, come ad esempio XGBoost, GBM chiaro, scikit-impara Foresta casuale, RAPIDS cuML Foresta casualee qualsiasi altro modello supportato da Treelite. Questi modelli sono stati a lungo utilizzati per risolvere problemi come la classificazione o la regressione. Sebbene questi tipi di modelli siano tradizionalmente eseguiti su CPU, la popolarità di questi modelli e le richieste di inferenza hanno portato a varie tecniche per aumentare le prestazioni di inferenza. Il backend FIL utilizza molte di queste tecniche utilizzando i costrutti cuML ed è basato su C++ e sulla libreria principale CUDA per ottimizzare le prestazioni di inferenza sugli acceleratori GPU.
Il backend FIL utilizza le librerie di cuML per utilizzare i core della CPU o della GPU per accelerare l'apprendimento. Per utilizzare questi processori, i dati vengono referenziati dalla memoria host (ad esempio, array NumPy) o dagli array GPU (uDF, Numba, cuPY o qualsiasi libreria che supporti il __cuda_array_interface__
) API. Dopo che i dati sono stati messi in scena in memoria, il back-end FIL può eseguire l'elaborazione su tutti i core CPU o GPU disponibili.
I thread back-end FIL possono comunicare tra loro senza utilizzare la memoria condivisa dell'host, ma nei carichi di lavoro dell'insieme è necessario considerare la memoria dell'host. Il diagramma seguente mostra un'architettura di runtime dell'utilità di pianificazione dell'insieme in cui è possibile ottimizzare le aree di memoria, inclusa la memoria condivisa indirizzabile dalla CPU utilizzata per la comunicazione tra processi tra Triton (C++) e il processo Python (backend Python) per lo scambio tensori (input/output) con il backend FIL.
Triton Inference Server offre agli sviluppatori opzioni configurabili per ottimizzare i propri carichi di lavoro e ottimizzare le prestazioni del modello. La configurazione dynamic_batching
consente a Triton di conservare le richieste lato client e raggrupparle sul lato server al fine di utilizzare in modo efficiente il calcolo parallelo di FIL per dedurre l'intero batch insieme. L'opzione max_queue_delay_microseconds
offre un controllo fail-safe di quanto tempo Triton attende per formare un batch.
Ci sono un certo numero di altri FIL specifici opzioni disponibili che influenzano le prestazioni e il comportamento. Suggeriamo di iniziare con storage_type
. Quando si esegue il back-end su GPU, FIL crea una nuova struttura di memoria/dati che è una rappresentazione dell'albero per cui FIL può influire sulle prestazioni e sul footprint. Questo è configurabile tramite il parametro dell'ambiente storage_type
, che ha le opzioni dense, sparse e auto. La scelta dell'opzione densa consumerà più memoria della GPU e non sempre si tradurrà in prestazioni migliori, quindi è meglio controllare. Al contrario, l'opzione sparse consumerà meno memoria della GPU e potrebbe funzionare altrettanto bene o meglio di dense. La scelta di auto farà sì che il modello diventi denso per impostazione predefinita, a meno che ciò non consumi molta più memoria GPU rispetto a sparse.
Quando si tratta di prestazioni del modello, potresti considerare di enfatizzare il threads_per_tree
opzione. Una cosa che potresti esagerare negli scenari del mondo reale è quella threads_per_tree
può avere un impatto maggiore sulla velocità effettiva rispetto a qualsiasi altro parametro. Impostarlo su qualsiasi potenza di 2 da 1 a 32 è legittimo. È difficile prevedere il valore ottimale per questo parametro, ma quando si prevede che il server gestisca un carico maggiore o elabori batch di dimensioni maggiori, tende a trarre vantaggio da un valore maggiore rispetto a quando elabora poche righe alla volta.
Un altro parametro da tenere presente è algo
, che è disponibile anche se si esegue su GPU. Questo parametro determina l'algoritmo utilizzato per elaborare le richieste di inferenza. Le opzioni supportate per questo sono ALGO_AUTO
, NAIVE
, TREE_REORG
e BATCH_TREE_REORG
. Queste opzioni determinano come sono organizzati i nodi all'interno di un albero e possono anche portare a miglioramenti delle prestazioni. IL ALGO_AUTO
l'opzione predefinita è NAIVE
per l'archiviazione scarsa e BATCH_TREE_REORG
per lo stoccaggio denso.
Infine, FIL viene fornito con la spiegazione di Shapley, che può essere attivata utilizzando il treeshap_output
parametro. Tuttavia, dovresti tenere presente che gli output di Shapley danneggiano le prestazioni a causa delle dimensioni dell'output.
Formato del modello
Attualmente non esiste un formato di file standard per archiviare i modelli basati su foresta; ogni framework tende a definire il proprio formato. Per supportare più formati di file di input, FIL importa i dati utilizzando l'open-source Treelite biblioteca. Ciò consente a FIL di supportare modelli addestrati in framework popolari, come ad esempio XGBoost ed LuceGBM. Tieni presente che il formato del modello che stai fornendo deve essere impostato nel file model_type
valore di configurazione specificato in config.pbtxt
file.
Configurazione.pbtxt
Ogni modello in a deposito di modelli deve includere una configurazione del modello che fornisca le informazioni obbligatorie e facoltative sul modello. In genere, questa configurazione è fornita in a config.pbtxt
file specificato come Protocollo ModelConfig. Per ulteriori informazioni sulle impostazioni di configurazione, fare riferimento a Configurazione del modello. Di seguito sono riportati alcuni dei parametri di configurazione del modello:
- dimensione_batch_massima – Questo determina la dimensione massima del batch che può essere passato a questo modello. In generale, l'unico limite alla dimensione dei batch passati a un backend FIL è la memoria disponibile con cui elaborarli. Per le esecuzioni GPU, la memoria disponibile è determinata dalla dimensione del pool di memoria CUDA di Triton, che può essere impostato tramite un argomento della riga di comando all'avvio del server.
- ingresso – Le opzioni in questa sezione indicano a Triton il numero di funzioni da aspettarsi per ciascun campione di input.
- produzione – Le opzioni in questa sezione indicano a Triton quanti valori di output ci saranno per ogni campione. Se la
predict_proba
option è impostata su true, verrà restituito un valore di probabilità per ciascuna classe. In caso contrario, verrà restituito un singolo valore, che indica la classe prevista per il dato campione. - gruppo_istanza – Determina quante istanze di questo modello verranno create e se utilizzeranno GPU o CPU.
- modello_tipo – Questa stringa indica in che formato è il modello (
xgboost_json
in questo esempio, maxgboost
,lightgbm
etl_checkpoint
sono formati validi pure). - predizione_proba – Se impostato su true, i valori di probabilità verranno restituiti per ogni classe anziché solo una previsione di classe.
- classe_output – Questo è impostato su true per i modelli di classificazione e false per i modelli di regressione.
- soglia – Questa è una soglia di punteggio per determinare la classificazione. Quando
output_class
è impostato su true, deve essere fornito, anche se non verrà utilizzato sepredict_proba
è anche impostato su true. - tipo_archiviazione – In generale, l'utilizzo di AUTO per questa impostazione dovrebbe soddisfare la maggior parte dei casi d'uso. Se è selezionata l'archiviazione AUTO, FIL caricherà il modello utilizzando una rappresentazione sparsa o densa basata sulla dimensione approssimativa del modello. In alcuni casi, potresti voler impostare esplicitamente questo parametro su SPARSE per ridurre il footprint di memoria di modelli di grandi dimensioni.
Server di inferenza Triton su SageMaker
SageMaker consente di implementare endpoint a modello singolo e multi-modello con NVIDIA Triton Inference Server. La figura seguente mostra l'architettura di alto livello di Triton Inference Server. IL deposito di modelli è un repository basato su file system dei modelli che Triton renderà disponibili per l'inferenza. Le richieste di inferenza arrivano al server e vengono instradate allo scheduler per modello appropriato. Strumenti Triton più algoritmi di pianificazione e batching che possono essere configurati modello per modello. Lo scheduler di ogni modello esegue facoltativamente il batch delle richieste di inferenza e quindi passa le richieste al backend corrispondente al tipo di modello. Il back-end esegue l'inferenza utilizzando gli input forniti nelle richieste in batch per produrre gli output richiesti. Gli output vengono quindi restituiti.
Quando configuri i tuoi gruppi di ridimensionamento automatico per gli endpoint SageMaker, potresti prendere in considerazione SageMakerVariantInvocationsPerInstance
come criterio principale per determinare le caratteristiche di ridimensionamento del gruppo di ridimensionamento automatico. Inoltre, a seconda che i tuoi modelli siano in esecuzione su GPU o CPU, puoi anche prendere in considerazione l'utilizzo di CPUUtilization o GPUUtilization come criteri aggiuntivi. Si noti che per gli endpoint a modello singolo, poiché i modelli distribuiti sono tutti uguali, è abbastanza semplice impostare criteri adeguati per soddisfare i contratti di servizio. Per gli endpoint multi-modello, consigliamo di distribuire modelli simili dietro un determinato endpoint per avere prestazioni prevedibili più costanti. Nei casi d'uso in cui vengono utilizzati modelli di dimensioni e requisiti diversi, potresti voler separare tali carichi di lavoro su più endpoint multi-modello o dedicare un po' di tempo alla messa a punto della policy di gruppo di ridimensionamento automatico per ottenere il miglior equilibrio tra costi e prestazioni.
Per un elenco di NVIDIA Triton Deep Learning Container (DLC) supportati dall'inferenza di SageMaker, fare riferimento a Immagini disponibili dei contenitori di apprendimento profondo.
Procedura dettagliata del notebook SageMaker
Le applicazioni ML sono complesse e spesso possono richiedere la pre-elaborazione dei dati. In questo notebook, esaminiamo come distribuire un modello ML basato su albero come XGBoost utilizzando il back-end FIL in Triton su un endpoint multi-modello SageMaker. Vedremo anche come implementare una pipeline di inferenza per la pre-elaborazione dei dati basata su Python per il tuo modello utilizzando la funzionalità di ensemble in Triton. Ciò ci consentirà di inviare i dati grezzi dal lato client e di eseguire sia la pre-elaborazione dei dati che l'inferenza del modello in un endpoint Triton SageMaker per prestazioni di inferenza ottimali.
Caratteristica dell'ensemble del modello Triton
Triton Inference Server semplifica enormemente l'implementazione di modelli AI su larga scala nella produzione. Triton Inference Server viene fornito con una comoda soluzione che semplifica la creazione di pipeline di pre-elaborazione e post-elaborazione. La piattaforma Triton Inference Server fornisce lo scheduler dell'ensemble, che è responsabile del pipelining dei modelli che partecipano al processo di inferenza, garantendo al tempo stesso efficienza e ottimizzazione del throughput. L'utilizzo di modelli di ensemble può evitare il sovraccarico del trasferimento di tensori intermedi e ridurre al minimo il numero di richieste che devono essere inviate a Triton.
In questo notebook, mostriamo come utilizzare la funzionalità di ensemble per creare una pipeline di pre-elaborazione dei dati con l'inferenza del modello XGBoost e puoi estrapolare da essa per aggiungere post-elaborazione personalizzata alla pipeline.
Crea l'ambiente
Iniziamo impostando l'ambiente richiesto. Installiamo le dipendenze necessarie per impacchettare la nostra pipeline di modelli ed eseguire inferenze utilizzando Triton Inference Server. Definiamo anche il Gestione dell'identità e dell'accesso di AWS (IAM) che consentirà a SageMaker di accedere agli artefatti del modello e a NVIDIA Triton Registro dei contenitori Amazon Elastic (Amazon ECR) immagine. Vedere il seguente codice:
Crea un ambiente Conda per la pre-elaborazione delle dipendenze
Il backend Python in Triton richiede l'utilizzo di un file Conda ambiente per eventuali dipendenze aggiuntive. In questo caso, utilizziamo il backend Python per preelaborare i dati grezzi prima di inserirli nel modello XGBoost in esecuzione nel backend FIL. Anche se originariamente utilizzavamo RAPIDS cuDF e cuML per eseguire la preelaborazione dei dati, qui utilizziamo Pandas e scikit-learn come dipendenze di preelaborazione durante l'inferenza. Lo facciamo per tre motivi:
- Mostriamo come creare un ambiente Conda per le tue dipendenze e come impacchettarlo nel file formato previsto dal backend Python di Triton.
- Mostrando il modello di pre-elaborazione in esecuzione nel back-end Python sulla CPU mentre XGBoost viene eseguito sulla GPU nel back-end FIL, illustriamo come ogni modello nella pipeline dell'ensemble di Triton può essere eseguito su un diverso back-end del framework e su diverse configurazioni hardware.
- Evidenzia come le librerie RAPIDS (cuDF, cuML) siano compatibili con le loro controparti CPU (Pandas, scikit-learn). Ad esempio, possiamo mostrare come
LabelEncoders
creato in cuML può essere utilizzato in scikit-learn e viceversa.
Seguiamo le istruzioni del Documentazione di Tritone per impacchettare le dipendenze di preelaborazione (scikit-learn e Pandas) da utilizzare nel backend Python come file TAR dell'ambiente Conda. Lo script bash create_prep_env.sh crea il file TAR dell'ambiente Conda, quindi lo spostiamo nella directory del modello di pre-elaborazione. Vedere il seguente codice:
Dopo aver eseguito lo script precedente, viene generato preprocessing_env.tar.gz
, che copiamo nella directory di preelaborazione:
Configura la pre-elaborazione con il backend Triton Python
Per la preelaborazione, usiamo Triton's Backend Python per eseguire la preelaborazione dei dati tabulari (codifica categoriale) durante l'inferenza per le richieste di dati grezzi che arrivano al server. Per ulteriori informazioni sulla pre-elaborazione eseguita durante l'addestramento, fare riferimento a quaderno di formazione.
Il backend Python consente di implementare pre-elaborazione, post-elaborazione e qualsiasi altra logica personalizzata in Python e servita con Triton. L'utilizzo di Triton su SageMaker richiede innanzitutto di configurare una cartella di repository di modelli contenente i modelli che vogliamo servire. Abbiamo già impostato un modello per la preelaborazione dei dati Python chiamato preelaborazione in cpu_model_repository
ed gpu_model_repository
.
Triton ha requisiti specifici per il layout del repository di modelli. All'interno della directory del repository del modello di livello superiore, ogni modello ha la propria sottodirectory contenente le informazioni per il modello corrispondente. Ogni directory del modello in Triton deve avere almeno una sottodirectory numerica che rappresenta una versione del modello. Il valore 1 rappresenta la versione 1 del nostro modello di preelaborazione Python. Ogni modello è eseguito da un back-end specifico, quindi all'interno di ogni sottodirectory della versione deve essere presente l'artefatto del modello richiesto da quel back-end. Per questo esempio, utilizziamo il backend Python, che richiede che il file Python che stai servendo sia chiamato model.py e il file deve implementare determinate funzioni. Se stessimo utilizzando un backend PyTorch, sarebbe richiesto un file model.pt e così via. Per ulteriori dettagli sulle convenzioni di denominazione per i file modello, fare riferimento a File modello.
Il modello.py Il file Python che utilizziamo qui implementa tutta la logica di preelaborazione dei dati tabulari per convertire i dati grezzi in funzionalità che possono essere inserite nel nostro modello XGBoost.
Ogni modello Triton deve inoltre fornire a config.pbtxt
file che descrive la configurazione del modello. Per ulteriori informazioni sulle impostazioni di configurazione, fare riferimento a Configurazione del modello. Il nostro config.pbtxt file specifica il back-end come python e tutte le colonne di input per i dati grezzi insieme all'output preelaborato, che consiste in 15 funzionalità. Specifichiamo anche che vogliamo eseguire questo modello di preelaborazione Python sulla CPU. Vedere il seguente codice:
Imposta un modello ML basato su albero per il back-end FIL
Successivamente, impostiamo la directory del modello per un modello ML basato su albero come XGBoost, che utilizzerà il backend FIL.
Il layout previsto per cpu_memory_repository
ed gpu_memory_repository
sono simili a quello che abbiamo mostrato in precedenza.
Qui, FIL
è il nome del modello. Possiamo dargli un nome diverso come xgboost
se vogliamo. 1
è la sottodirectory della versione, che contiene l'artefatto del modello. In questo caso, è il xgboost.json
modello che abbiamo salvato. Creiamo questo layout previsto:
Dobbiamo avere il file di configurazione config.pbtxt
descrivendo la configurazione del modello per il modello ML basato su albero, in modo che il backend FIL in Triton possa capire come servirlo. Per ulteriori informazioni, fare riferimento all'ultimo generico Opzioni di configurazione di Triton e le opzioni di configurazione specifiche per il back-end FIL. In questo esempio ci concentriamo solo su alcune delle opzioni più comuni e pertinenti.
Creare config.pbtxt
per model_cpu_repository
:
Allo stesso modo, imposta config.pbtxt
per model_gpu_repository
(notare la differenza è USE_GPU = True
):
Imposta una pipeline di inferenza del back-end Python di pre-elaborazione dei dati e del back-end FIL utilizzando ensemble
Ora siamo pronti per impostare la pipeline di inferenza per la pre-elaborazione dei dati e l'inferenza del modello basata su albero utilizzando un modello d'insieme. Un modello di ensemble rappresenta una pipeline di uno o più modelli e la connessione di tensori di input e output tra tali modelli. Qui usiamo il modello ensemble per costruire una pipeline di pre-elaborazione dei dati nel backend Python seguita da XGBoost nel backend FIL.
Il layout previsto per il ensemble
la directory del modello è simile a quelle che abbiamo mostrato in precedenza:
Abbiamo creato il modello dell'ensemble config.pbtxt seguendo la guida in Modelli d'insieme. È importante sottolineare che dobbiamo impostare lo scheduler dell'ensemble in config.pbtxt
, che specifica il flusso di dati tra i modelli all'interno dell'ensemble. Lo scheduler dell'insieme raccoglie i tensori di output in ogni passaggio e li fornisce come tensori di input per altri passaggi in base alle specifiche.
Crea un pacchetto del repository del modello e caricalo su Amazon S3
Infine, ci ritroveremo con la seguente struttura di directory del repository di modelli, contenente un modello di pre-elaborazione Python e le sue dipendenze insieme al modello XGBoost FIL e all'insieme del modello.
Impacchettamo la directory e il suo contenuto come model.tar.gz
per il caricamento in Servizio di archiviazione semplice Amazon (Amazon S3). Abbiamo due opzioni in questo esempio: utilizzare un'istanza basata su CPU o un'istanza basata su GPU. Un'istanza basata su GPU è più adatta quando hai bisogno di una maggiore potenza di elaborazione e desideri utilizzare CUDA core.
Crea e carica il pacchetto modello per un'istanza basata su CPU (ottimizzata per CPU) con il seguente codice:
Crea e carica il pacchetto modello per un'istanza basata su GPU (ottimizzata per GPU) con il seguente codice:
Crea un endpoint SageMaker
Ora abbiamo gli artefatti del modello archiviati in un bucket S3. In questo passaggio, possiamo anche fornire la variabile di ambiente aggiuntiva SAGEMAKER_TRITON_DEFAULT_MODEL_NAME
, che specifica il nome del modello che deve essere caricato da Triton. Il valore di questa chiave deve corrispondere al nome della cartella nel pacchetto del modello caricato su Amazon S3. Questa variabile è facoltativa nel caso di un singolo modello. Nel caso di modelli ensemble, questa chiave deve essere specificata per l'avvio di Triton in SageMaker.
Inoltre, puoi impostare SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT
ed SAGEMAKER_TRITON_THREAD_COUNT
per ottimizzare il conteggio dei thread.
Usiamo il modello precedente per creare una configurazione dell'endpoint in cui possiamo specificare il tipo e il numero di istanze che vogliamo nell'endpoint
Utilizziamo questa configurazione dell'endpoint per creare un endpoint SageMaker e attendere il completamento della distribuzione. Con SageMaker MME, abbiamo la possibilità di ospitare più modelli di ensemble ripetendo questo processo, ma per questo esempio ci atteniamo a una distribuzione:
Lo stato cambierà in InService
quando la distribuzione ha esito positivo.
Richiama il tuo modello ospitato sull'endpoint SageMaker
Dopo che l'endpoint è in esecuzione, possiamo utilizzare alcuni dati non elaborati di esempio per eseguire l'inferenza utilizzando JSON come formato del payload. Per il formato della richiesta di inferenza, Triton utilizza il formato KFServing
standard comunitario protocolli di inferenza. Vedi il seguente codice:
Il quaderno a cui si fa riferimento nel blog si trova in Repository GitHub.
Buone pratiche
Oltre alle opzioni per ottimizzare le impostazioni del back-end FIL menzionate in precedenza, i data scientist possono anche garantire che i dati di input per il back-end siano ottimizzati per l'elaborazione da parte del motore. Quando possibile, inserisci i dati nel formato riga principale nell'array GPU. Altri formati richiedono una conversione interna e cicli di acquisizione, riducendo le prestazioni.
A causa del modo in cui le strutture dati FIL vengono mantenute nella memoria della GPU, prestare attenzione alla profondità dell'albero. Maggiore è la profondità dell'albero, maggiore sarà il footprint di memoria della GPU.
Usa il instance_group_count
parametro per aggiungere processi di lavoro e aumentare la velocità effettiva del back-end FIL, che si tradurrà in un maggiore consumo di memoria di CPU e GPU. Inoltre, considera le variabili specifiche di SageMaker che sono disponibili per aumentare il throughput, come i thread HTTP, la dimensione del buffer HTTP, la dimensione del batch e il ritardo massimo.
Conclusione
In questo post, abbiamo approfondito il backend FIL supportato da Triton Inference Server su SageMaker. Questo backend fornisce sia l'accelerazione CPU che GPU dei tuoi modelli basati su albero come il popolare algoritmo XGBoost. Ci sono molte opzioni da considerare per ottenere le migliori prestazioni per l'inferenza, come le dimensioni dei batch, i formati di input dei dati e altri fattori che possono essere ottimizzati per soddisfare le tue esigenze. SageMaker ti consente di utilizzare questa funzionalità con endpoint singoli e multi-modello per bilanciare prestazioni e risparmi sui costi.
Ti invitiamo a prendere le informazioni in questo post e vedere se SageMaker è in grado di soddisfare le tue esigenze di hosting per servire modelli basati su albero, soddisfacendo i tuoi requisiti di riduzione dei costi e prestazioni del carico di lavoro.
Il notebook a cui si fa riferimento in questo post può essere trovato negli esempi di SageMaker Repository GitHub. Inoltre, puoi trovare la documentazione più recente sul backend FIL su GitHub.
Informazioni sugli autori
Raghu Ramesha è un Senior ML Solutions Architect del team di assistenza di Amazon SageMaker. Si concentra sull'aiutare i clienti a creare, distribuire e migrare i carichi di lavoro di produzione ML su SageMaker su larga scala. È specializzato in machine learning, intelligenza artificiale e domini di visione artificiale e ha conseguito un master in Informatica presso l'UT Dallas. Nel tempo libero ama viaggiare e fotografare.
James Park è un Solutions Architect presso Amazon Web Services. Collabora con Amazon.com per progettare, creare e distribuire soluzioni tecnologiche su AWS e ha un interesse particolare per l'intelligenza artificiale e l'apprendimento automatico. Nel tempo libero gli piace cercare nuove culture, nuove esperienze e tenersi aggiornato sulle ultime tendenze tecnologiche.
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 un'inferenza del modello ad alte prestazioni su Amazon SageMaker.
Jiahong Liu è un Solution Architect nel team di Cloud Service Provider di NVIDIA. Assiste i clienti nell'adozione di soluzioni di apprendimento automatico e intelligenza artificiale che sfruttano l'informatica accelerata NVIDIA per affrontare le loro sfide di formazione e inferenza. Nel tempo libero ama gli origami, i progetti fai-da-te e gioca a basket.
Kshitiz Gupta è un architetto di soluzioni presso NVIDIA. Gli piace educare i clienti del cloud sulle tecnologie di intelligenza artificiale GPU che NVIDIA ha da offrire e assisterli nell'accelerazione delle loro applicazioni di machine learning e deep learning. Al di fuori del lavoro, gli piace correre, fare escursioni e osservare la fauna selvatica.
- Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
- PlatoAiStream. Intelligenza dei dati Web3. Conoscenza amplificata. Accedi qui.
- Coniare il futuro con Adryenn Ashley. Accedi qui.
- Fonte: https://aws.amazon.com/blogs/machine-learning/hosting-ml-models-on-amazon-sagemaker-using-triton-xgboost-lightgbm-and-treelite-models/
- :ha
- :È
- :non
- :Dove
- $ SU
- 1
- 100
- 11
- 13
- 200
- 23
- 24
- 7
- 8
- 9
- a
- capacità
- WRI
- accelerare
- accelerata
- accelerando
- acceleratori
- accesso
- Secondo
- di conseguenza
- Il mio account
- Raggiungere
- operanti in
- aggiungere
- aggiunta
- aggiuntivo
- indirizzo
- indirizzabile
- Adottando
- Dopo shavasana, sedersi in silenzio; saluti;
- contro
- accordi
- AI
- algoritmo
- Tutti
- allocazioni
- consentire
- consente
- lungo
- già
- anche
- Sebbene il
- sempre
- Amazon
- Amazon Sage Maker
- Amazon Web Services
- Amazon.com
- quantità
- an
- ed
- in qualsiasi
- api
- applicazioni
- opportuno
- architettura
- SONO
- aree
- argomento
- Italia
- artificiale
- intelligenza artificiale
- AS
- assist
- At
- auto
- disponibile
- evitare
- AWS
- BACKEND
- Equilibrio
- basato
- bash
- base
- Pallacanestro
- BE
- perché
- diventare
- stato
- prima
- iniziare
- dietro
- sotto
- beneficio
- MIGLIORE
- Meglio
- fra
- maggiore
- Blog
- stile di vita
- entrambi
- bufferizzare
- costruire
- Costruzione
- costruito
- ma
- by
- C++
- detto
- Materiale
- carta
- Custodie
- casi
- Categoria
- Causare
- sfide
- il cambiamento
- caratteristiche
- dai un'occhiata
- patata fritta
- Scegli
- la scelta
- Città
- classe
- classificazione
- cliente
- clienti
- Cloud
- codice
- colonne
- COM
- viene
- arrivo
- Uncommon
- comunicare
- Comunicazione
- comunità
- compatibile
- complesso
- calcolo
- computer
- Informatica
- Visione computerizzata
- informatica
- Configurazione
- veloce
- Prendere in considerazione
- considerato
- consumare
- consumo
- Contenitore
- Tecnologie Container
- contiene
- testuali
- contrasto
- di controllo
- Comodo
- Conversione
- convertire
- Nucleo
- Corrispondente
- Costo
- riduzione dei costi
- risparmi
- coprire
- creare
- creato
- crea
- criteri
- cruciale
- Attualmente
- costume
- Clienti
- cicli
- Dallas
- dati
- Data
- giorno
- affare
- decisione
- deep
- apprendimento profondo
- più profondo
- Predefinito
- defaults
- Laurea
- ritardo
- esigente
- richieste
- Dipendente
- schierare
- schierato
- distribuzione
- deployment
- profondità
- Design
- dettagli
- Determinare
- determinato
- determina
- determinazione
- sviluppatori
- differenza
- diverso
- distribuito
- calcolo distribuito
- fai da te
- do
- documentazione
- non
- fare
- domini
- fatto
- colomba
- dovuto
- durante
- ogni
- In precedenza
- educare
- efficienza
- in modo efficiente
- o
- enfatizzando
- Abilita
- incoraggiare
- fine
- endpoint
- motore
- Motori
- garantire
- assicurando
- Impresa
- aziende
- Intero
- Ambiente
- errori
- Anche
- Ogni
- esempio
- Esempi
- scambio
- attenderti
- previsto
- Esperienze
- export
- Fattori
- abbastanza
- cadute
- falso
- caratteristica
- Caratteristiche
- Federale
- alimentazione
- pochi
- figura
- Compila il
- File
- Trovate
- finire
- Nome
- flusso
- Focus
- si concentra
- seguire
- seguito
- i seguenti
- Orma
- Nel
- modulo
- formato
- essere trovato
- Contesto
- quadri
- frode
- Gratis
- da
- Inoltre
- Guadagni
- Generale
- genera
- ottenere
- Dare
- dato
- GPU
- molto
- Gruppo
- Gruppo
- guida
- accadere
- Hard
- Hardware
- Avere
- he
- Aiuto
- aiutare
- aiuta
- qui
- alto livello
- Alte prestazioni
- superiore
- evidenzia
- il suo
- tenere
- detiene
- host
- ospitato
- di hosting
- Come
- Tutorial
- Tuttavia
- HTML
- http
- HTTPS
- Male
- Identità
- ids
- IDX
- if
- Immagine
- Impact
- impatti
- realizzare
- implementato
- attrezzi
- importazioni
- in
- includere
- Compreso
- Aumento
- indica
- informazioni
- informati
- ingresso
- install
- esempio
- istruzioni
- integrazione
- Intelligence
- interesse
- interno
- ai miglioramenti
- IT
- SUO
- jpg
- json
- ad appena
- mantenere
- Le
- Genere
- Sapere
- grandi
- Grandi imprese
- superiore, se assunto singolarmente.
- Latenza
- con i più recenti
- disposizione
- IMPARARE
- apprendimento
- meno
- Guidato
- legittimo
- meno
- Livello
- livelli
- Leva
- biblioteche
- Biblioteca
- piace
- LIMITE
- linea
- Lista
- caricare
- logica
- logico
- Lunghi
- macchina
- machine learning
- make
- gestire
- molti
- master
- partita
- max
- massimo
- Maggio..
- meccanismo
- Soddisfare
- incontro
- Memorie
- menzionato
- Mercante
- Metrica
- forza
- migrare
- mente
- ML
- Moda
- modello
- modelli
- Mese
- Scopri di più
- maggior parte
- Più popolare
- cambiano
- Endpoint multimodello
- multiplo
- devono obbligatoriamente:
- Nome
- di denominazione
- nativo
- Bisogno
- esigenze
- New
- nlp
- no
- nodi
- taccuino
- adesso
- numero
- numpy
- Nvidia
- ottenere
- of
- offrire
- Offerte
- di frequente
- on
- ONE
- quelli
- esclusivamente
- open source
- ottimale
- ottimizzazione
- OTTIMIZZA
- ottimizzati
- ottimizzazione
- Opzione
- Opzioni
- or
- minimo
- organizzazioni
- Organizzato
- originariamente
- OS
- Altro
- altrimenti
- nostro
- su
- produzione
- al di fuori
- proprio
- pacchetto
- imballaggio
- panda
- Parallel
- parametro
- parametri
- partecipante
- particolare
- Passato
- Passi
- sentiero
- Eseguire
- performance
- esegue
- autorizzazione
- fotografia
- conduttura
- piattaforma
- Platone
- Platone Data Intelligence
- PlatoneDati
- gioco
- per favore
- pletora
- Termini e Condizioni
- politica
- pool
- Popolare
- popolarità
- possibile
- forse
- Post
- energia
- predire
- Prevedibile
- previsto
- predizione
- Previsioni
- in precedenza
- primario
- Direttore
- problemi
- processi
- i processi
- lavorazione
- Potenza di calcolo
- processori
- produrre
- Produzione
- progetti
- corretto
- Proto
- fornire
- purché
- fornitore
- fornisce
- fornitura
- Python
- pytorch
- casuale
- che vanno
- piuttosto
- Crudo
- pronto
- mondo reale
- tempo reale
- motivi
- raccomandare
- ridurre
- di cui
- Indipendentemente
- regione
- relazionato
- pertinente
- sostituire
- deposito
- rappresentazione
- che rappresenta
- rappresenta
- richiesta
- richieste
- richiedere
- necessario
- Requisiti
- richiede
- risposta
- responsabile
- colpevole
- Risultati
- Ruolo
- Correre
- running
- s
- sagemaker
- Inferenza di SageMaker
- stesso
- Risparmio
- scalabile
- Scala
- scala
- Scenari
- programmazione
- Scienze
- scienziati
- scikit-impara
- Punto
- Sezione
- vedere
- cerca
- selezionato
- inviare
- anziano
- separato
- servire
- servizio
- Provider di servizi
- Servizi
- servizio
- set
- regolazione
- impostazioni
- Forma
- condiviso
- dovrebbero
- mostrare attraverso le sue creazioni
- Spettacoli
- lato
- significativamente
- simile
- Un'espansione
- singolo
- Taglia
- Dimensioni
- So
- soluzione
- Soluzioni
- RISOLVERE
- Soluzione
- alcuni
- Fonte
- specializzata
- specifico
- specificazione
- specificato
- spendere
- Standard
- inizia a
- Di partenza
- Startup
- Regione / Stato
- Stato dei servizi
- costante
- step
- Passi
- conservazione
- Tornare al suo account
- memorizzati
- lineare
- Corda
- La struttura
- di successo
- tale
- suggerire
- adatto
- supporto
- supportato
- supporti
- Fai
- team
- tecniche
- Tecnologie
- Tecnologia
- dire
- condizioni
- di
- che
- Il
- le informazioni
- loro
- Li
- poi
- Là.
- Strumenti Bowman per analizzare le seguenti finiture:
- di
- cosa
- questo
- quelli
- anche se?
- tre
- soglia
- portata
- tempo
- a
- oggi
- insieme
- di livello superiore
- tradizionalmente
- allenato
- Training
- Trasferimento
- Di viaggio
- albero
- tendenze
- tritone
- vero
- seconda
- Digitare
- Tipi di
- tipicamente
- capire
- caricato
- Caricamento
- us
- uso
- utilizzato
- Utente
- utilizzando
- utilizza
- Utilizzando
- APPREZZIAMO
- Valori
- vario
- versione
- via
- visione
- W
- aspettare
- volere
- Prima
- guardare
- Modo..
- we
- sito web
- servizi web
- WELL
- sono stati
- Che
- quando
- ogni volta che
- se
- quale
- while
- volere
- con
- entro
- senza
- Lavora
- lavorato
- lavoratore
- lavori
- sarebbe
- XGBoost
- anno
- Tu
- Trasferimento da aeroporto a Sharm
- zefiro
- Codice postale