View a markdown version of this page

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

Distribuzione di modelli su Amazon SageMaker HyperPod

Amazon SageMaker HyperPod ora va oltre la formazione per fornire una piattaforma di inferenza completa che combina la flessibilità di Kubernetes con l'eccellenza operativa dei servizi gestiti. AWS Implementa, scala e ottimizza i tuoi modelli di machine learning con un'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 Studio UI o CLI. SageMaker 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 il tempo al primo token (Time To First Token), la latenza e l’utilizzo della GPU per aiutarti a ottimizzare le prestazioni.

Nota

Quando si esegue la distribuzione su GPU-enabled istanze, è possibile utilizzare il partizionamento GPU con tecnologia GPU (MIG) per eseguire più carichi di lavoro di inferenza su una singola Multi-Instance GPU. Ciò consente un migliore utilizzo della GPU e l'ottimizzazione dei costi. Per ulteriori informazioni sulla configurazione del partizionamento della GPU, vedere. Utilizzo di 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.

Enterprise-ready opzioni di distribuzione

Implementa modelli da più fonti, inclusi 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.

Key-value Cache gestita su più livelli (KV) e routing intelligente

La 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, puoi 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 la condivisione della cache scalabile a livello di nodo.

Il routing intelligente analizza le richieste in arrivo e le indirizza all'istanza di inferenza che molto probabilmente contiene coppie chiave-valore pertinenti 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 arrivo vengono indirizzate all'istanza con la più alta percentuale di hit 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 il caching KV e il routing intelligente.

Cache L2 integrata, supporto di storage su più livelli per il caching KV

Basato 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 su più livelli SageMaker gestito integrato, questo offre prestazioni migliorate. Questo miglioramento offre ai clienti un'opzione più scalabile ed efficiente per l'offload della cache, particolarmente utile 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 a riposo per ottimizzare la latenza di inferenza e migliorare le prestazioni. Per carichi di lavoro con severi requisiti di crittografia a riposo, prendi in considerazione la crittografia a livello di applicazione di prompt 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 di attenzione e valori) 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.

È possibile ridurre la latenza di avvio a freddo durante la scalabilità delle distribuzioni memorizzando nella cache i pesi del modello sullo storage NVMe locale dell'host e preinserendo l'immagine del contenitore del server di inferenza sui nodi di destinazione. Puoi abilitare queste funzionalità indipendentemente o insieme modelCacheConfig sul campo e funzionano con i modelli di Amazon, Amazon S3 e Amazon FSx. SageMaker JumpStart Per ulteriori informazioni, consulta Pesi del modello, memorizzazione nella cache e memorizzazione nella cache delle immagini.

Multi-instance distribuzione di tipo con failover automatico

HyperPod Inference supporta l'implementazione di tipo multiistanza per migliorare l'affidabilità dell'implementazione e l'utilizzo delle risorse. Specificate un elenco prioritario di tipi di istanza nella configurazione di distribuzione e il sistema seleziona automaticamente tra le alternative disponibili quando il tipo di istanza preferito non dispone di 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 disponibile con la massima priorità e garantendo la distribuzione anche quando le risorse preferite non sono disponibili. Questa funzionalità previene gli errori di distribuzione 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 L'inferenza supporta l'affinità personalizzata dei nodi per controllare il posizionamento del carico di lavoro oltre alla selezione del tipo di istanza. Specifica i criteri di selezione dei nodi come la distribuzione delle zone di disponibilità, il filtro del tipo di capacità (on-demand o spot) o le etichette personalizzate dei nodi tramite il campo. nodeAffinity Il sistema supporta l'utilizzo di vincoli di posizionamento obbligatori requiredDuringSchedulingIgnoredDuringExecution e preferenze opzionalipreferredDuringSchedulingIgnoredDuringExecution, fornendo il pieno controllo sulle decisioni di pianificazione dei pod pur mantenendo la flessibilità di implementazione.

Nota

Raccogliamo alcune metriche operative di routine per fornire la disponibilità essenziale dei servizi. La creazione di queste metriche è completamente automatizzata e non comporta la revisione umana del carico di lavoro di inferenza del modello sottostante. Queste metriche si riferiscono alle operazioni di distribuzione, alla gestione delle risorse e alla registrazione degli endpoint.

Argomenti