Implementazione di modelli su Amazon SageMaker HyperPod - Amazon SageMaker AI

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

Implementazione di modelli su Amazon SageMaker HyperPod

Amazon SageMaker HyperPod ora va oltre la formazione per offrire una piattaforma di inferenza completa che combina la flessibilità di Kubernetes con l'eccellenza operativa dei servizi gestiti. AWS Implementa, ridimensiona e ottimizza i tuoi modelli di machine learning con affidabilità di livello aziendale utilizzando lo stesso calcolo per l'intero ciclo di vita del modello. HyperPod

Amazon SageMaker HyperPod offre interfacce di distribuzione flessibili che consentono di distribuire modelli tramite diversi metodi, tra cui kubectl, Python SDK, Amazon SageMaker Studio UI o CLI. HyperPod Il servizio offre funzionalità avanzate di dimensionamento automatico con allocazione dinamica delle risorse, regolata automaticamente in base alla domanda. Inoltre, include funzionalità complete di osservabilità e monitoraggio che tengono traccia di metriche critiche come la latenza e l'utilizzo della GPU per aiutarti a ottimizzare time-to-first-token le prestazioni.

Nota

Quando esegui la distribuzione su istanze abilitate per GPU, puoi utilizzare il partizionamento GPU con la tecnologia Multi-Instance GPU (MIG) per eseguire più carichi di lavoro di inferenza su una singola GPU. Ciò consente un migliore utilizzo della GPU e l'ottimizzazione dei costi. Per ulteriori informazioni sulla configurazione del partizionamento GPU, vedere. Utilizzo delle partizioni GPU in Amazon SageMaker HyperPod

Infrastruttura unificata per l’addestramento e l’inferenza

Massimizza l’utilizzo della GPU trasferendo senza problemi le risorse di calcolo tra i carichi di lavoro di addestramento e di inferenza. Questa funzionalità riduce il costo totale di proprietà garantendo al tempo stesso la continuità operativa.

Opzioni di implementazione pensate per le aziende

Implementa modelli da più fonti, tra cui modelli open weights e gated di Amazon e modelli personalizzati di Amazon S3 SageMaker JumpStart e Amazon FSx con supporto per architetture di inferenza a nodo singolo e multinodo.

Caching KV (Key-value) gestito su più livelli e routing intelligente

La memorizzazione nella cache KV salva i vettori chiave-valore precalcolati dopo l'elaborazione dei token precedenti. Quando viene elaborato il token successivo, non è necessario ricalcolare i vettori. Tramite un'architettura di caching a due livelli, è possibile configurare una cache L1 che utilizza la memoria della CPU per il riutilizzo locale a bassa latenza e una cache L2 che sfrutta Redis per consentire una condivisione scalabile della cache a livello di nodo.

Il routing intelligente analizza le richieste in entrata e le indirizza all'istanza di inferenza che ha più probabilità di avere coppie chiave-valore memorizzate nella cache. Il sistema esamina la richiesta e quindi la indirizza in base a una delle seguenti strategie di routing:

  1. prefixaware— Le richieste successive con lo stesso prefisso di prompt vengono indirizzate alla stessa istanza

  2. kvaware— Le richieste in entrata vengono indirizzate all'istanza con la più alta frequenza di accessi della cache KV.

  3. session— Le richieste provenienti dalla stessa sessione utente vengono indirizzate alla stessa istanza.

  4. roundrobin— Distribuzione uniforme delle richieste senza considerare lo stato della cache KV.

Per ulteriori informazioni su come abilitare questa funzionalità, vedereConfigura la memorizzazione nella cache KV e il routing intelligente per migliorare le prestazioni.

Supporto di storage su più livelli con cache L2 integrata per la memorizzazione nella cache KV

Basandosi sull'infrastruttura di cache KV esistente, HyperPod ora integra lo storage su più livelli come opzione di backend L2 aggiuntiva insieme a Redis. Grazie allo storage SageMaker gestito su più livelli integrato, ciò offre prestazioni migliorate. Questo miglioramento offre ai clienti un'opzione più scalabile ed efficiente per l'offload della cache, particolarmente vantaggiosa per i carichi di lavoro di inferenza LLM ad alto rendimento. L'integrazione mantiene la compatibilità con i server modello VLLm esistenti e le funzionalità di routing, offrendo al contempo prestazioni migliori.

Nota

Crittografia dei dati: i dati della cache KV (chiavi e valori di attenzione) vengono archiviati non crittografati quando sono inattivi per ottimizzare la latenza di inferenza e migliorare le prestazioni. Per carichi di lavoro con encryption-at-rest requisiti rigorosi, prendi in considerazione la crittografia a livello di applicazione di richieste e risposte o disabilita la memorizzazione nella cache.

Isolamento dei dati: quando si utilizza lo storage gestito su più livelli come backend della cache L2, più implementazioni di inferenza all'interno di un cluster condividono lo storage della cache senza isolamento. I dati della cache L2 KV (chiavi e valori di attenzione) provenienti da diverse implementazioni non sono separati. Per i carichi di lavoro che richiedono l'isolamento dei dati (scenari multi-tenant, diversi livelli di classificazione dei dati), esegui l'implementazione su cluster separati o utilizza istanze Redis dedicate.

Implementazione di tipo multiistanza con failover automatico

HyperPod Inference supporta l'implementazione di tipo multiistanza per migliorare l'affidabilità della distribuzione e l'utilizzo delle risorse. Specificate un elenco prioritario di tipi di istanze nella configurazione di distribuzione e il sistema selezionerà automaticamente tra le alternative disponibili quando il tipo di istanza preferito non ha capacità. Lo scheduler Kubernetes utilizza l'affinità dei preferredDuringSchedulingIgnoredDuringExecution nodi per valutare i tipi di istanza in ordine di priorità, posizionando i carichi di lavoro sul tipo di istanza con la priorità più alta disponibile e garantendo al contempo l'implementazione anche quando le risorse preferite non sono disponibili. Questa funzionalità previene gli errori di implementazione dovuti a vincoli di capacità, mantenendo al contempo le preferenze in termini di costi e prestazioni, garantendo la disponibilità continua del servizio anche durante le fluttuazioni della capacità del cluster.

Affinità dei nodi personalizzata per un controllo granulare della pianificazione

HyperPod Inference supporta l'affinità dei nodi personalizzata per controllare il posizionamento del carico di lavoro oltre la selezione del tipo di istanza. Specificate i criteri di selezione dei nodi, come la distribuzione delle zone di disponibilità, il filtraggio del tipo di capacità (su richiesta o spot) o le etichette personalizzate dei nodi tramite il campo. nodeAffinity Il sistema supporta vincoli di posizionamento obbligatori tramite l'utilizzo di preferenze requiredDuringSchedulingIgnoredDuringExecution opzionalipreferredDuringSchedulingIgnoredDuringExecution, garantendo il pieno controllo sulle decisioni di pianificazione dei pod pur mantenendo la flessibilità di implementazione.

Nota

Raccogliamo determinate metriche operative di routine per fornire la disponibilità essenziale del servizio. La creazione di queste metriche è completamente automatizzata e non prevede la revisione umana del carico di lavoro di inferenza del modello sottostante. Queste metriche riguardano le operazioni di distribuzione, la gestione delle risorse e la registrazione degli endpoint.

Argomenti