Prestazioni - Amazon EKS
Scalabilità e prestazioni delle applicazioni

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à.

Prestazioni

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ù comandi RUN o COPY per creare un numero inferiore di livelli più grandi. La creazione di immagini più piccole presenta i seguenti vantaggi e svantaggi:

  • Vantaggi:

    • Il recupero delle immagini è più veloce e nel complesso è necessario meno spazio di archiviazione.

    • Le immagini più piccole hanno un vettore di attacco inferiore.

  • Contro:

    • Poiché le immagini dei container sono più snelle, sarà necessario creare più immagini per soddisfare le esigenze di esecuzione in ambienti diversi.

    • Il risparmio di dimensioni ottenuto combinando i comandi a volte può essere trascurabile, quindi è consigliabile testare diversi approcci di costruzione per vedere cosa offre i risultati migliori. Per quanto riguarda i AI/ML framework, selezionate varianti come immagini solo in fase di esecuzione (ad esempio, da 3,03 GB rispetto pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime a devel da 6,66 GB), ma il benchmark dei carichi di lavoro come immagini più piccole può saltare la compilazione JIT, con conseguenti percorsi di codice più lenti. Usa build in più fasi per separare build e runtime, copiando solo gli artefatti necessari (ad esempio, tramite COPY —from= per registri o contesti locali). Utilizzate l'ottimizzazione dei livelli combinando COPY in una fase di assemblaggio per un minor numero di livelli, ma ponete l'accento sulla riduzione dell'efficienza della cache e sui tempi di costruzione più lunghi.

Gestione degli artefatti del modello ML nelle distribuzioni

Una decisione chiave è come gestire autonomamente gli artefatti del modello ML (ad esempio pesi, configurazioni). La scelta influisce sulle dimensioni dell'immagine, sulla velocità di implementazione, sulla frequenza di aggiornamento del modello e sul sovraccarico operativo. Non che quando ci riferiamo alla memorizzazione del «modello», ci riferiamo agli artefatti del modello (ad esempio, parametri addestrati, pesi del modello). Esistono tre 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, elencate dal meno consigliato al più consigliato:

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.

  • Vantaggi: garantisce coerenza e riproducibilità, nessun ritardo di caricamento, semplifica la gestione delle dipendenze.

  • Svantaggi: consente di ottenere immagini di dimensioni maggiori, rallenta le compilazioni e i push, richiede la ricostruzione e la ridistribuzione per gli aggiornamenti dei modelli. Non è la soluzione ideale per i modelli di grandi dimensioni a causa della velocità effettiva di recupero del registro. Inoltre, ciò può portare a cicli di feedback più lunghi per la sperimentazione, il debug e i test a causa della configurazione più complessa e può aumentare i costi di archiviazione in caso di co-localizzazione su immagini diverse.

Download 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 Mountpoint per il driver CSI S3, AWS S3 CLI o s5cmd OSS CLI) tramite script in un contenitore init o entrypoint. Consigliamo di iniziare con questo approccio per modelli di grandi dimensioni con aggiornamenti frequenti.

  • Vantaggi: consente di concentrare le immagini dei container su code/runtime, enables easy model updates without rebuilds, supports versioning via storage metadata. It also allows for A/B test, hot-swap o rollback dei modelli senza aumentare le dimensioni dell'immagine del contenitore e offre la possibilità di condividere i modelli tra diverse applicazioni senza inserirli in tutte le immagini dei container. Inoltre, introduce modifiche minime ai flussi di lavoro dei team di apprendimento automatico o delle applicazioni e consente una creazione di container più rapida per facilitare la sperimentazione e i test. L'utilizzo di strumenti supportati da S3 CRT come AWS CLI, s5cmd o il driver CSI Mountpoint S3 può ridurre significativamente la latenza di download e migliorare le prestazioni per i file di grandi dimensioni, spesso con tempi di avvio complessivi dei pod più rapidi rispetto all'estrazione di immagini di contenitori di grandi dimensioni da registri come ECR, a seconda delle prestazioni della rete e del registro.

  • Svantaggi: introduce potenziali errori di rete (richiede una logica di ripetizione), richiede l'autenticazione e la memorizzazione nella cache. Un'ulteriore complessità operativa deriva dalla gestione del processo di download, compresi i nuovi tentativi, la gestione degli errori e il backoff, oltre alla gestione aggiuntiva dello storage e della pulizia che replica la funzionalità ECR.

Montaggio del modello tramite volumi persistenti Archivia il modello in uno storage esterno (ad esempio, Amazon EFS, EBS, FSx per NetApp ONTAP, per Lustre, FSx FSx per OpenZFS o S3 tramite il driver CSI Mountpoint S3) e montalo come Kubernetes (PV). PersistentVolume Questi sono i file e i dati generati durante il processo di addestramento del modello che consentono di effettuare previsioni o inferenze. Consigliamo di utilizzare questo approccio per modelli condivisi tra pod o cluster.

  • Vantaggi: separa il modello dall'immagine per l'accesso condiviso, facilita gli aggiornamenti senza riavvii (se supportato dal framework), gestisce in modo efficiente set di dati di grandi dimensioni. Consente inoltre il provisioning e il controllo degli accessi basati su Kubernetes tramite funzionalità come clonazione, condivisione e istantanee, riducendo la necessità di copiare modelli e creare nuove operazioni. È possibile il controllo degli accessi ai modelli basato su POSIX, oltre alla possibilità di aggiornare le versioni del modello separatamente dall'applicazione senza ricostruire l'immagine del contenitore e creare build di container più veloci per sperimentazioni e test. Per le applicazioni di AI/ML inferenza che leggono gli artefatti in memoria, ciò consente di caricare i dati direttamente dal file system esterno senza doverli archiviare intermediamente sul disco locale del nodo, migliorando le prestazioni di caricamento. Inoltre, per l'archiviazione di modelli di grandi dimensioni su larga scala, FSx servizi come FSx NetApp ONTAP e Lustre forniscono tecniche di ottimizzazione dello storage (ad esempio, deduplicazione, compressione, thin provisioning), controllo delle versioni tramite istantanee e supporto per il riutilizzo dello stesso file senza sprecare spazio di archiviazione. Altri servizi, come S3, offrono il controllo delle versioni native. Questo approccio può estendersi anche su cluster e potenzialmente regioni, a seconda della configurazione di replica (ad esempio, replica asincrona o replica FSx interregionale in S3 ed EFS).

  • Svantaggi: può aumentare I/O la latenza se collegato alla rete, richiede il provisioning dello storage e il controllo degli accessi, può essere meno portabile (ad esempio, EBS) se lo storage è specifico del cluster. I compromessi includono una maggiore complessità operativa per le CI/CD modifiche e la manutenzione dei processi di caricamento, la necessità di meccanismi personalizzati per ridurre i costi di storage e una replica interregionale più complessa. TTL/retention Le prestazioni di lettura degli artefatti del modello devono essere misurate in base al tempo di download dell'immagine del contenitore.

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 (ad esempio 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 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] (https://containerd.io/)) 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 è utile quando le istantanee EBS non sono preconfigurate o quando si preferisce la preestrazione delle immagini. Consulta il [AWS Samples GitHub repository] (https://github.com/aws-samples/aws-do-eks/tree/main/Container-Root/eks/deployment/prepull) per esempi di preestrazione delle immagini. Nota che alternative come il lazy loading con [SOCI Snapshotter] (https://github.com/awslabs/soci-snapshotter) (un plug-in containerd per il recupero parziale delle immagini) possono integrare questi metodi, anche se richiedono una configurazione personalizzata e potrebbero non adattarsi a tutti gli scenari. L'utilizzo della cache di runtime del contenitore presenta i seguenti vantaggi e svantaggi:

  • Vantaggi:

    • Non è necessario gestire le istantanee EBS.

    • Con DaemonSets te avrai sempre l'ultima versione dell'immagine del contenitore.

    • Più flessibile, in quanto le immagini possono essere aggiornate senza ricreare istantanee.

    • Riduce comunque i tempi di avvio del pod assicurando che le immagini siano già presenti sul nodo.

  • Svantaggi:

    • L'estrazione iniziale di immagini di grandi dimensioni può comunque richiedere del tempo, anche se viene eseguita in anticipo.

    • Potrebbe non essere efficiente quanto le istantanee EBS per immagini molto grandi (oltre 10 GB), poiché l'estrazione è comunque necessaria, anche se non all'avvio del pod.

    • Con DaemonSets, un'immagine viene precaricata su tutti i nodi in cui potrebbe funzionare il pod. Ad esempio, se 1000 nodi eseguivano solo un'istanza di un pod, lo spazio viene consumato su tutti i 1000 nodi solo per eseguire un'istanza su un nodo.

    • Per i carichi di lavoro di inferenza in tempo reale in cui i nodi si espandono o diminuiscono, i nuovi nodi aggiunti da strumenti come Cluster Autoscaler possono pianificare i pod dei carichi di lavoro prima che il prepull completi l'estrazione delle immagini. DaemonSet 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.

    • 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. Nei modelli di scale-in/out, 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.

Utilizzo delle istantanee EBS

  • 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. Consulta questo Riduzione dei tempi di avvio dei container su Amazon EKS con volume di dati Bottlerocket per ulteriori informazioni sull'utilizzo di Karpenter e questo EKS Terraform Blueprints per gruppi di nodi gestiti. Ti consigliamo di automatizzare la creazione di istantanee EBS come parte della tua CI/CD pipeline per mantenerle con le versioni più recenti delle immagini dei container. up-to-date L'utilizzo delle istantanee EBS presenta i seguenti vantaggi e svantaggi:

  • Vantaggi:

    • Elimina la necessità di estrarre immagini di contenitori di grandi dimensioni all'avvio del pod, riducendo significativamente i tempi di avvio (ad esempio, da 10-15 minuti a secondi per immagini di dimensioni superiori a 10 GB).

    • Assicura che le immagini siano disponibili localmente all'avvio del nodo.

    • Particolarmente utile per carichi di lavoro di inferenza con immagini di contenitori di grandi dimensioni.

  • Svantaggi:

    • Richiede la manutenzione e l'aggiornamento delle istantanee EBS con ogni aggiornamento di immagine o versione.

    • Richiede passaggi aggiuntivi per assicurarsi che tutti i carichi di lavoro utilizzino l'ultima versione dell'immagine del contenitore.

    • Implica attività operative aggiuntive per creare e gestire istantanee.

    • Può includere immagini non necessarie se non viene gestita correttamente, sebbene ciò possa essere mitigato con una corretta configurazione del pool di nodi.

Ottimizza le prestazioni di Image Pull

Consigliamo vivamente di ottimizzare le prestazioni del container image pull per i cluster Amazon EKS che eseguono AI/ML carichi di lavoro. L'uso di immagini di base di grandi dimensioni e non ottimizzate o un ordinamento inefficiente dei livelli può comportare tempi di avvio dei pod lenti, un maggiore consumo di risorse e una riduzione della latenza di inferenza. Per risolvere questo problema, adotta immagini di base piccole e leggere con dipendenze minime, personalizzate in base ai tuoi carichi di lavoro. Puoi anche prendere in considerazione gli AWS Deep Learning Containers (DLCs), immagini di container predefinite che semplificano l'esecuzione dei framework di deep learning più diffusi (ad esempio e). PyTorchTensorFlow Per ulteriori informazioni sulla creazione di un'immagine personalizzata, consulta Personalizzare i Deep Learning Containers. Quando crei immagini personalizzate, prendi in considerazione immagini di base leggere e aggiungi solo le librerie necessarie per mantenere le immagini snelle. Utilizza build in più fasi per ridurre le dimensioni dei livelli e ottimizzare l'ordinamento dei livelli per una memorizzazione efficiente nella cache. Per maggiori dettagli, consulta le best practice di Docker per la creazione di immagini.

Riduci i tempi di avvio dei container precaricando le immagini dei container nei volumi di dati

Per i carichi di lavoro di machine learning che richiedono una bassa latenza di avvio dei pod, come l'inferenza in tempo reale, consigliamo di precaricare le immagini dei container per ridurre al minimo i ritardi di inizializzazione. Le immagini di contenitori di grandi dimensioni possono rallentare l'avvio dei pod, specialmente su nodi con larghezza di banda limitata. Oltre a utilizzare immagini di base minime, build in più fasi e tecniche di caricamento lento, prendi in considerazione i seguenti approcci per precaricare le immagini in Amazon EKS. Oltre a utilizzare immagini di base minime, build in più fasi e tecniche di caricamento lento, considera le seguenti opzioni:

  • Precarica le immagini utilizzando le istantanee EBS: scatta uno snapshot Amazon Elastic Block Store (EBS) delle immagini dei container memorizzate nella cache e riutilizza questa istantanea per i nodi di lavoro EKS. Sebbene ciò aggiunga attività operative aggiuntive, garantisce che le immagini vengano precaricate localmente all'avvio del nodo, riducendo i tempi di inizializzazione dei pod. Consulta questo Riduzione dei tempi di avvio dei container su Amazon EKS con volume di dati Bottlerocket per ulteriori informazioni sull'utilizzo di Karpenter e questo EKS Terraform Blueprints per gruppi di nodi gestiti.

  • Pre-inserisci le immagini nella cache di runtime del contenitore: precarica le immagini del contenitore 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 è utile quando le istantanee EBS non sono preconfigurate o quando si preferisce la preestrazione delle immagini. Prova questo approccio in un ambiente di staging per convalidare i miglioramenti della latenza. Consulta il GitHub repository AWS Samples per esempi di preestrazione di immagini.