Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Scalabilità e prestazioni delle applicazioni

Gestione degli artefatti ML, framework di servizio e ottimizzazione delle startup

La distribuzione di modelli di machine learning (ML) su Amazon EKS richiede un'attenta considerazione del modo in cui i modelli vengono integrati nelle immagini dei container e negli ambienti di runtime. Ciò garantisce scalabilità, riproducibilità e utilizzo efficiente delle risorse. Questo argomento descrive i diversi approcci alla gestione degli artefatti dei modelli ML, alla selezione dei framework di servizio e all'ottimizzazione dei tempi di avvio dei container attraverso tecniche come il pre-caching, tutte personalizzate per ridurre i tempi di avvio dei container.

Gestione degli artefatti del modello ML nelle distribuzioni

Una decisione chiave è come gestire autonomamente gli artefatti del modello ML (come pesi e configurazioni). La scelta influisce sulle dimensioni dell'immagine, sulla velocità di implementazione, sulla frequenza di aggiornamento del modello e sul sovraccarico operativo. Tieni presente che quando ci riferiamo alla memorizzazione del «modello», ci riferiamo agli artefatti del modello (come i parametri addestrati e i pesi del modello). Esistono diversi approcci alla gestione degli artefatti del modello ML su Amazon EKS. Ognuno ha i suoi compromessi e il migliore dipende dalle dimensioni del modello, dalla cadenza di aggiornamento e dalle esigenze di infrastruttura. Considerate i seguenti approcci, dal meno consigliato al più consigliato:

Per ulteriori informazioni, consulta Accelerare il processo di pull nel workshop AI on EKS.

Al servizio dei modelli ML

La distribuzione e l'utilizzo di modelli di machine learning (ML) su Amazon EKS richiede la selezione di un approccio di model serving appropriato per ottimizzare latenza, throughput, scalabilità e semplicità operativa. La scelta dipende dal tipo di modello (ad esempio, linguaggio, modello di visione), dalle richieste del carico di lavoro (ad esempio, inferenza in tempo reale) e dall'esperienza del team. Gli approcci comuni includono Python-based configurazioni per la prototipazione, server di modelli dedicati per funzionalità di livello di produzione e motori di inferenza specializzati per prestazioni ed efficienza elevate. Ogni metodo comporta compromessi in termini di complessità di configurazione, prestazioni e utilizzo delle risorse. Tieni presente che i framework di gestione possono aumentare le dimensioni delle immagini dei container (più GB) a causa delle dipendenze, con un potenziale impatto sui tempi di avvio: prendi in considerazione la possibilità di disaccoppiamento utilizzando tecniche di gestione degli artefatti per mitigare questo problema. Le opzioni sono elencate dalle meno consigliate a quelle più consigliate:

Utilizzo di framework Python (ad esempio, FastAPI, HuggingFace Transformers with) PyTorch Sviluppa un'applicazione personalizzata utilizzando framework Python, incorporando file modello (weights, config, tokenizer) all'interno di una configurazione di nodi containerizzata.

Utilizzo di framework di servizio di modelli dedicati (ad esempio TGI) Adotta server specializzati come TensorRT-LLM o TGI per l'inferenza ML, la gestione del caricamento, il routing e l'ottimizzazione dei modelli. TensorRT-LLM Questi supportano formati come safetensors, con compilazioni o plugin opzionali.

Utilizzo di motori di inferenza specializzati ad alto rendimento (ad esempio vLLM) Utilizza motori di inferenza avanzati come vLLM, ottimizzando il servizio LLM con batch in volo e quantizzazione (INT8, AWQ) PagedAttention, integrabili con l'autoscaling EKS. FP8-KV

Ottimizzazione dei tempi di recupero delle immagini dei contenitori

Le immagini di contenitori di grandi dimensioni possono causare ritardi di avvio a freddo che influiscono sulla latenza di avvio del pod. Per i carichi di lavoro sensibili alla latenza, come i carichi di lavoro di inferenza in tempo reale scalati orizzontalmente, l'avvio rapido dei pod è fondamentale. Considerate i seguenti approcci per ottimizzare i tempi di recupero delle immagini dei container:

Riduzione delle dimensioni delle immagini dei contenitori

Ridurre le dimensioni delle immagini dei contenitori durante l'avvio è un altro modo per rimpicciolire le immagini. È possibile effettuare riduzioni in ogni fase del processo di creazione dell'immagine del contenitore. Per iniziare, scegliete immagini di base che contengano il minor numero di dipendenze richieste. Durante la creazione delle immagini, includi solo le librerie e gli artefatti essenziali richiesti. Durante la creazione di immagini, provate a combinare più COPY comandi RUN per creare un numero inferiore di livelli più grandi. Per quanto riguarda i AI/ML framework, utilizzate build in più fasi per separare build e runtime, copiando solo gli elementi necessari (ad esempio, tramite i registri COPY —from= for o i contesti locali) e selezionate varianti come immagini solo in fase di esecuzione (ad esempio, da 3,03 GB rispetto a devel a 6,66 GB). pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime Per ulteriori informazioni, consulta Riduzione delle dimensioni dell'immagine del contenitore nel workshop AI on EKS.

Ridurre la latenza di estrazione delle immagini

Per i cluster EKS in esecuzione in sottoreti private, configura gli endpoint dell'interfaccia VPC per Amazon ECR per mantenere il traffico di acquisizione delle immagini sulla rete privata AWS, riducendo la latenza ed eliminando i costi di elaborazione dei dati del gateway NAT. Per istruzioni di configurazione, consulta Creare gli endpoint VPC per Amazon ECR.

Inoltre, se i tuoi carichi di lavoro si basano su immagini di container upstream provenienti da registri esterni, prendi in considerazione l'utilizzo di ECR pull through cache per eseguire il proxy e memorizzare tali immagini nel tuo registro ECR privato.

Ottimizza la larghezza di banda di rete per Image Pulls

Quando si estraggono immagini di container di grandi dimensioni, la larghezza di banda di rete disponibile per i nodi di lavoro EKS influisce direttamente sui tempi di avvio dei carichi di lavoro di formazione e inferenza. Tutte le Nitro-based istanze di generazione attuale utilizzano l'Elastic Network Adapter (ENA), ma la larghezza di banda disponibile varia in modo significativo in base alla dimensione dell'istanza ed è fondamentale comprendere la differenza tra larghezza di banda di base e larghezza di banda burst (vedi Larghezza di banda di rete delle istanze Amazon EC2). Per ridurre al minimo i tempi di preparazione dei carichi di lavoro, seleziona le dimensioni delle istanze con una larghezza di banda di rete di base sufficiente rispetto alle dimensioni dell'immagine e richiedi la concorrenza.

Utilizzo dello snapshotter SOCI per le immagini Pre-pull

Per immagini molto grandi che non è possibile minimizzare facilmente, è possibile utilizzare lo snapshotter open source Seekable OCI (SOCI) configurato in modalità pull and unpack parallela. Questa soluzione consente di utilizzare le immagini esistenti senza ricostruire o modificare le pipeline di compilazione. Questa opzione è particolarmente efficace quando si distribuiscono carichi di lavoro con immagini molto grandi su istanze di calcolo EC2 ad alte prestazioni. Funziona bene con configurazioni di rete ad alto throughput e storage ad alte prestazioni, come è tipico dei carichi di lavoro scalabili. AI/ML

pull/unpack La modalità parallela SOCI migliora le prestazioni di acquisizione delle immagini end-to-end attraverso strategie di parallelizzazione configurabili. L'estrazione e la preparazione delle immagini più rapide influiscono direttamente sulla velocità con cui è possibile implementare nuovi carichi di lavoro e scalare il cluster in modo efficiente. Le acquisizioni di immagini hanno due fasi principali:

La modalità pull parallela SOCI utilizza un sistema di controllo a doppia soglia con parametri configurabili sia per la concomitanza dei download che per il parallelismo di decompressione. Questo controllo granulare consente di ottimizzare il comportamento di SOCI per soddisfare i requisiti prestazionali e le condizioni ambientali specifici. La comprensione di questi parametri consente di ottimizzare il tempo di esecuzione per ottenere le migliori prestazioni di pull.

Riferimenti

Pre-pull Usare le istantanee EBS sulle immagini

Puoi creare uno snapshot di Amazon Elastic Block Store (EBS) delle immagini dei container memorizzate nella cache e riutilizzarlo per i nodi di lavoro EKS. Ciò garantisce che le immagini vengano precaricate localmente all'avvio del nodo, riducendo i tempi di inizializzazione dei pod. Per ulteriori informazioni, consulta Ridurre i tempi di avvio dei container su Amazon EKS con il volume di dati Bottlerocket per ulteriori informazioni utilizzando Karpenter ed EKS Terraform Blueprints per gruppi di nodi gestiti.

Per saperne di più, consulta Using containerd snapshotter e Preload delle immagini dei container nei volumi di dati Bottlerocket con EBS Snapshots nell'AI on EKS Workshop.

Utilizzo della Pre-pull Container Runtime Cache to Images

Puoi precaricare le immagini dei container sui nodi utilizzando le risorse Kubernetes (ad esempio, DaemonSet o Deployment) per popolare la cache di runtime del contenitore del nodo. La cache di runtime del contenitore è l'archiviazione locale gestita dal runtime del contenitore (ad esempio, containerd), in cui le immagini vengono archiviate dopo essere state estratte da un registro. Pre-pulling assicura che le immagini siano disponibili localmente, evitando ritardi nel download durante l'avvio del pod. Questo approccio è particolarmente utile quando le immagini cambiano spesso (ad esempio, aggiornamenti frequenti), quando le istantanee EBS non sono preconfigurate, quando la creazione di un volume EBS richiederebbe più tempo rispetto all'estrazione diretta da un registro di contenitori o quando i nodi sono già presenti nel cluster e necessita di avviare i pod su richiesta utilizzando una delle diverse immagini possibili.

Pre-pulling tutte le varianti garantiscono tempi di avvio rapidi indipendentemente dall'immagine necessaria. Ad esempio, in un carico di lavoro ML estremamente parallelo che richiede 100.000 piccoli modelli creati utilizzando 10 tecniche diverse, il preupload di 10 immagini tramite un DaemonSet cluster di grandi dimensioni (ad esempio migliaia di nodi) riduce al minimo il tempo di avvio del pod, consentendone il completamento in meno di 10 secondi evitando richiami su richiesta. L'utilizzo dell'approccio Container Runtime Cache elimina la necessità di gestire le istantanee EBS e assicura di avere sempre la versione più recente dell'immagine del contenitore DaemonSets, ma per i carichi di lavoro di inferenza in tempo reale in cui i nodi sono scalabili in/out, i nuovi nodi aggiunti da strumenti come Cluster Autoscaler possono pianificare i pod dei carichi di lavoro prima che il pre-pull DaemonSet completi l'estrazione delle immagini. Ciò può far sì che il pod iniziale sul nuovo nodo attivi comunque il pull, ritardando potenzialmente l'avvio e influendo sui requisiti di bassa latenza. Inoltre, kubelet image garbage collection può influire sulle immagini preestratte rimuovendo quelle inutilizzate quando l'utilizzo del disco supera determinate soglie o se superano l'età massima di inutilizzo configurata. Negli in/out schemi di scalabilità, ciò può eliminare le immagini sui nodi inattivi, il che richiede la necessità di richiamare nuovamente le immagini durante i successivi scale-up e ridurre l'affidabilità della cache per carichi di lavoro a raffica.

Consulta il GitHub repository AWS per esempi di preinserimento delle immagini nella cache di runtime del contenitore.

Prendi in considerazione NVMe per lo storage su kubelet e containerd

Prendi in considerazione la configurazione kubelet e l'utilizzo di dischi di storage containerd a istanze NVMe temporanei per prestazioni del disco più elevate. Il processo di estrazione del contenitore prevede lo scaricamento di un'immagine del contenitore da un registro e la decompressione dei relativi livelli in un formato utilizzabile. Per ottimizzare I/O le operazioni durante la decompressione, è necessario valutare cosa offre livelli più elevati di I/O prestazioni e velocità effettiva per il tipo di istanza dell'host del contenitore: istanze con backup NVMe con storage locale anziché EBS Volume. IOPS/throughput Per le istanze EC2 con storage locale NVMe, prendi in considerazione la configurazione del filesystem sottostante del nodo per kubelet (/var/lib/kubelet), containerd () e Pod logs /var/log/pods () per utilizzare dischi di storage di istanze NVMe /var/lib/containerd temporanei per livelli di prestazioni e throughput più elevati. I/O

Lo storage temporaneo del nodo può essere condiviso tra i Pod che richiedono lo storage temporaneo e le immagini dei contenitori che vengono scaricate sul nodo. Se si utilizza Karpenter con Bottlerocket o AMI ottimizzate EKS AL2023, questo può essere configurato impostando EC2NodeClassl'StorePolicy istanza su RAID0 o, se si utilizzano i gruppi di nodi gestiti, impostando il local in come parte dei dati utente. StoragePolicy NodeConfig