Scalabilità e prestazioni delle applicazioni

Gestione degli artefatti ML, framework di servizio e ottimizzazione dell'avvio

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.

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.

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, da quelli meno consigliati a quelli più consigliati:

• Inserimento del modello nell'immagine del contenitore: copia i file del modello (ad es. .safetensors, .pth, .h5) nell'immagine del contenitore (ad esempio, Dockerfile) durante la creazione dell'immagine. Il modello fa parte dell'immagine immutabile. Si consiglia di utilizzare questo approccio per i modelli più piccoli con aggiornamenti poco frequenti. Ciò garantisce coerenza e riproducibilità, non prevede ritardi di caricamento e semplifica la gestione delle dipendenze, ma comporta immagini di dimensioni maggiori, rallenta le build e le push, richiede la ricostruzione e la ridistribuzione per gli aggiornamenti dei modelli e non è ideale per i modelli di grandi dimensioni a causa del throughput di pull del registro.

• Scaricamento del modello in fase di esecuzione: all'avvio del contenitore, l'applicazione scarica il modello da uno storage esterno (ad esempio, Amazon S3, supportato da S3 CRT per trasferimenti ottimizzati ad alto rendimento utilizzando metodi come il driver CSI Mountpoint per S3, AWS S3 CLI o l'OSS CLI s5cmd) tramite script in un contenitore init o entrypoint. Consigliamo di iniziare con questo approccio per modelli di grandi dimensioni con aggiornamenti frequenti. In questo modo le immagini dei container si concentrano sul codice/runtime, facilita gli aggiornamenti dei modelli senza ricostruzioni, supporta il controllo delle versioni tramite metadati di archiviazione, ma introduce potenziali errori di rete (richiede una logica di ripetizione) e richiede l'autenticazione e la memorizzazione nella cache.

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 configurazioni basate su Python per la prototipazione, server modello dedicati per funzionalità di livello di produzione e motori di inferenza specializzati per alte prestazioni ed efficienza. 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 (multiple GBs) delle immagini dei container a causa delle dipendenze, con un potenziale impatto sui tempi di avvio: prendi in considerazione la possibilità di disaccoppiare i container utilizzando tecniche di gestione degli artefatti per mitigare questo problema. Le opzioni sono elencate da quelle 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.

• Vantaggi: prototipazione semplice, solo Python senza infrastruttura aggiuntiva, compatibile con tutti i HuggingFace modelli, implementazione semplice di Kubernetes.

• Svantaggi: si limita al singolo request/simple batch, la generazione lenta di token (nessun kernel ottimizzato), la memoria è inefficiente, manca di scalabilità e monitoraggio e comporta lunghi tempi di avvio.

• Raccomandazione: utilizzalo per la prototipazione iniziale o per attività a nodo singolo che richiedono un'integrazione logica personalizzata.

Utilizzo di framework di model serving dedicati (ad es. Tensorrt-LLM, TGI) Adotta server specializzati come Tensorrt-LLM o TGI per l'inferenza ML, gestendo il caricamento, il routing e l'ottimizzazione del modello. Questi supportano formati come safetensors, con compilazioni o plugin opzionali.

• Vantaggi: offre il raggruppamento in batch (parallelismo). static/in-flight or continuous), quantization (INT8, FP8, GPTQ), hardware optimizations (NVIDIA, AMD, Intel, Inferentia), and multi-GPU support (Tensor/Pipeline TensorRT-LLM supporta diversi modelli (Encoder-Decoder)LLMs, mentre TGI sfrutta l'integrazione. HuggingFace

• Contro: Tensorrt-LLM necessita di compilazione ed è solo per NVIDIA; TGI potrebbe essere meno efficiente nel batching; entrambi aggiungono un sovraccarico di configurazione e potrebbero non adattarsi a tutti i tipi di modello (ad esempio, non trasformatori).

• PyTorch/TensorFlow Raccomandazione: adatto per modelli che richiedono funzionalità di produzione come test o produttività elevata con hardware compatibile. A/B

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 (, -KV, AWQ) PagedAttention, integrabili con l'autoscaling EKS. INT8 FP8

• Vantaggi: elevata produttività ed efficienza della memoria (risparmio del 40-60% di VRAM), gestione dinamica delle richieste, streaming di token, supporto multi-GPU Tensor Parallel a nodo singolo e ampia compatibilità hardware.

• Svantaggi: ottimizzato per i trasformatori che utilizzano solo decoder (ad esempio, LLa MA), meno efficace per i modelli senza trasformatore, richiede hardware compatibile (ad esempio, NVIDIA) e sforzi di configurazione. GPUs

• Raccomandazione: la scelta migliore per l'inferenza LLM ad alto volume e bassa latenza su EKS, che massimizza la scalabilità e le prestazioni.

Pre-memorizzazione nella cache delle immagini dei container

Le immagini di contenitori di grandi dimensioni (come quelle contenenti modelli simili PyTorch) possono causare ritardi di avvio a freddo che influiscono sulla latenza. Per i carichi di lavoro sensibili alla latenza, come i carichi di lavoro di inferenza in tempo reale scalati orizzontalmente e l'avvio rapido dei pod è fondamentale, consigliamo di precaricare le immagini dei container per ridurre al minimo i ritardi di inizializzazione. Considera i seguenti approcci, da quelli meno consigliati a quelli più consigliati:

Utilizzo dello snapshotter SOCI per preestrarre le immagini

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 ad alte prestazioni. EC2 Funziona bene con configurazioni di rete ad alto throughput e storage ad alte prestazioni, come è tipico dei carichi di lavoro scalabili. AI/ML

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

1. Recupero dei livelli dal registro al nodo

Per l'ottimizzazione del recupero dei livelli, SOCI crea più connessioni HTTP simultanee per livello, moltiplicando la velocità di download oltre la limitazione della singola connessione. Divide i livelli di grandi dimensioni in blocchi e li scarica contemporaneamente su più connessioni. Questo approccio aiuta a saturare la larghezza di banda di rete disponibile e a ridurre significativamente i tempi di download. Ciò è particolarmente utile per i AI/ML carichi di lavoro in cui un singolo livello può pesare diversi gigabyte.

2. Disimballare e preparare quegli strati per creare contenitori

Per l'ottimizzazione del disimballaggio dei livelli, SOCI elabora più livelli contemporaneamente. Invece di aspettare che ogni livello venga decompresso completamente prima di iniziare il successivo, utilizza i core della CPU disponibili per decomprimere ed estrarre più livelli contemporaneamente. Questa elaborazione parallela trasforma la tradizionale fase di decompressione legata all'I/O in un'operazione ottimizzata per la CPU che si adatta ai core disponibili. Il sistema orchestra attentamente questa parallelizzazione per mantenere la coerenza del file system massimizzando al contempo la velocità di trasmissione.

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

• Per ulteriori informazioni sulla soluzione e sui compromessi di ottimizzazione, consulta la documentazione sulle funzionalità nell'archivio del progetto SOCI su. GitHub

• Per un esempio pratico con Karpenter su Amazon EKS, consulta Karpenter Blueprint che utilizza la modalità parallela dello snapshotter SOCI. pull/unpack

• Per informazioni sulla configurazione di Bottlerocket per il pull parallelo, vedere soci-snapshotter Parallel Pull Unpack Mode nella documentazione di Bottlerocket.

Utilizzo delle istantanee EBS per preestrarre le 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 Container Runtime Cache per preestrarre le immagini

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. La preestrazione 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à nel cluster e devono far girare i pod su richiesta utilizzando una delle diverse immagini possibili.

La preselezione di tutte le varianti garantisce 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 garantisce di avere sempre a disposizione la versione più recente dell'immagine del contenitore DaemonSets, ma per i carichi di lavoro di inferenza in tempo reale in cui i nodi scalano i in/out, new nodes added by tools like Cluster Autoscaler may schedule workload pods before the pre-pull DaemonSet completes image pulling. This can cause the initial pod on the new node to trigger the pull anyway, potentially delaying startup and impacting low-latency requirements. Additionally, kubelet image garbage collection can affect pre-pulled images by removing unused ones when disk usage exceeds certain thresholds or if they exceed a configured maximum unused age. In scale-in/out modelli, ciò può comportare l'eliminazione delle immagini sui nodi inattivi, con la conseguente necessità di richiamare nuovamente le immagini durante i successivi scale-up e ridurre l'affidabilità della cache per carichi di lavoro a picco.

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

Utilizzo NVMe per lo storage in kubelet e containerd

Valuta la possibilità di configurare kubelet e utilizzare dischi containerd di storage a istanze temporanee per prestazioni del disco più elevate NVMe . 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: NVMe istanze con backup con archiviazione locale rispetto a IBS Volume IOPS/throughput. Per EC2 le istanze con archiviazione NVMe locale, prendi in considerazione la configurazione del filesystem sottostante del nodo per kubelet (/var/lib/kubelet), containerd () e Pod logs /var/log/pods () per utilizzare NVMe dischi /var/lib/containerd di archiviazione di istanze temporanee 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 AL2 023 EKS Optimized, AMIs questo può essere configurato impostando su RAID0 o, se si utilizzano Managed Node instanceStorePolicy Groups, EC2NodeClassimpostando l'ingresso come parte dei dati utente. localStoragePolicy NodeConfig