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à.
Pesi del modello, memorizzazione nella cache e memorizzazione nella cache delle immagini
Quando si espande una distribuzione di inferenza, ogni nuovo pod deve estrarre l'immagine del contenitore del server di inferenza da un registro. Deve inoltre scaricare i pesi dei modelli dallo storage remoto (Amazon S3 o Amazon FSx) prima di poter servire il traffico. Per i modelli linguistici di grandi dimensioni, il download dei pesi dei modelli e l'estrazione delle immagini dei contenitori contribuiscono maggiormente alla latenza di avvio a freddo.
Per eliminare questi ostacoli durante lo scale-out, configura uno o entrambi i seguenti meccanismi di caching locale dell'host in Amazon Inference: SageMaker HyperPod
- Memorizzazione
weightsCachenella cache dei pesi del modello () -
Pre-populates file di peso del modello su storage NVMe locale sull'host su ogni nodo idoneo. I pod di inferenza sullo stesso nodo caricano i pesi dallo storage locale invece di scaricarli dalla fonte remota del modello, eliminando i download ridondanti tra i pod.
- Memorizzazione nella cache delle immagini ()
imageCache -
Pre-pulls l'immagine del contenitore del server di inferenza sui nodi di destinazione in modo che i nuovi pod vengano avviati senza attendere l'estrazione a freddo dell'immagine.
È possibile configurare entrambi i meccanismi di memorizzazione nella cache tramite il modelCacheConfig campo della distribuzione. InferenceEndpointConfig JumpStartModel
È possibile abilitare il caching dei pesi e il caching delle immagini indipendentemente o insieme. Entrambe le funzionalità funzionano con tutte le sorgenti di modelli Amazon SageMaker HyperPod Inference, comprese le SageMaker JumpStart distribuzioni Amazon (sia modelli open-weights che gated) e i modelli personalizzati di Amazon S3 o Amazon FSx.
Prerequisiti
Prima di abilitare la memorizzazione nella cache, verifica quanto segue:
- Tipo di istanza con storage NVMe locale
-
La memorizzazione nella cache dei pesi del modello memorizza i pesi sullo storage NVMe locale dell'host (per impostazione predefinita).
/opt/dlami/nvmeIl tipo di istanza deve fornire lo storage NVMe locale nel formato configurato.hostPath - Capacità NVMe sufficiente
-
Assicurati che il nodo disponga di spazio di archiviazione locale sufficiente per il tuo modello. Ogni distribuzione utilizza una propria directory cache isolata, quindi più distribuzioni memorizzate nella cache sullo stesso nodo consumano ciascuna il proprio spazio di archiviazione.
- Operatore di inferenza
-
Il cluster deve avere una versione dell'operatore HyperPod Inference che supporti la memorizzazione nella cache dei modelli. Se il
modelCacheConfigcampo non viene riconosciuto, aggiorna il componente aggiuntivo dell'operatore di inferenza alla versione più recente.
Importante
Se il tipo di istanza non dispone di una memoria NVMe locale nella configurazionehostPath, la memorizzazione nella cache dei pesi del modello non riscalda la cache e i pod di inferenza si limitano a scaricare i pesi dalla fonte remota del modello. Verificate che il tipo di istanza fornisca uno storage NVMe locale prima di abilitare questa funzionalità.
Configura il caching dei pesi dei modelli e il caching delle immagini
Aggiungi un modelCacheConfig blocco alla tua spec InferenceEndpointConfig risorsa. JumpStartModel L'esempio seguente abilita sia la memorizzazione nella cache dei pesi del modello che la memorizzazione nella cache delle immagini.
spec: # ... model source, worker, and TLS configuration ... modelCacheConfig: weightsCache: enabled: true hostPath: /opt/dlami/nvme imageCache: enabled: true
Il modelCacheConfig campo supporta i seguenti sottocampi.
| Campo | Predefinita | Description |
|---|---|---|
weightsCache.enabled |
false |
Se il modello locale dell'host pesa la memorizzazione nella cache è abilitata. Quandotrue, l'operatore precompila i pesi del modello sullo storage locale dell'host e li monta in pod di inferenza. |
weightsCache.hostPath |
/opt/dlami/nvme |
Il percorso host in cui vengono memorizzati i pesi del modello memorizzati nella cache. Deve essere un percorso assoluto non vuoto di massimo 255 caratteri. |
imageCache.enabled |
false |
Se la memorizzazione nella cache delle immagini dei contenitori è abilitata. Quandotrue, l'operatore precarica l'immagine del contenitore del server di inferenza sui nodi di destinazione. |
Come funziona la memorizzazione nella cache dei pesi dei modelli
In tal caso weightsCache.enabledtrue, l'operatore scarica i pesi del modello dall'origine remota del modello (Amazon S3 o Amazon FSx) sullo storage NVMe locale dell'host su ciascun nodo idoneo prima che i pod di inferenza inizino a distribuire il traffico. I pod di inferenza montano i pesi memorizzati nella cache in sola lettura e caricano il modello dallo storage locale invece di scaricarlo ripetutamente dalla fonte remota.
L'operatore popola la cache sui nodi che corrispondono ai vincoli di pianificazione della distribuzione dell'inferenza ed etichetta ogni nodo quando la cache è calda. L'implementazione dell'inferenza utilizza l'affinità di nodo preferita su questa etichetta, quindi i pod vengono programmati su nodi caldi quando disponibili, ma possono comunque essere programmati altrove.
- Isolamento
-
Ogni distribuzione utilizza una directory cache isolata per distribuzione nella directory configurata, in modo che le distribuzioni di più modelli sullo
hostPathstesso nodo non interferiscano l'una con l'altra. - Errore di fallback nella cache
-
Se un pod è pianificato su un nodo in cui la cache non è ancora disponibile, la distribuzione ricorre al caricamento dei pesi del modello direttamente dall'origine remota del modello, in modo che le distribuzioni rimangano funzionali anche senza una cache calda.
- Sostituzione del nodo
-
Se un nodo viene sostituito (ad esempio, dopo un errore), l'operatore deve riscaldare nuovamente la cache sul nuovo nodo prima che i pod vengano programmati preferibilmente su di esso. I nodi caldi esistenti continuano a servire il traffico nel frattempo.
- Pulizia in caso di eliminazione
-
Quando si elimina la distribuzione, l'operatore rimuove i file di peso memorizzati nella cache dai nodi che ha popolato.
Come funziona la memorizzazione nella cache delle immagini
In tal casotrue, imageCache.enabled l'operatore preleva l'immagine del contenitore del server di inferenza sui nodi di destinazione. Poiché l'immagine è già presente sul nodo, i nuovi pod di inferenza evitano l'estrazione a freddo dell'immagine che altrimenti ritarderebbe l'avvio del pod. Ciò è particolarmente utile per le immagini di server di inferenza di grandi dimensioni e per le implementazioni con scalabilità orizzontale frequente.
La memorizzazione nella cache delle immagini è indipendente dalla memorizzazione nella cache dei pesi dei modelli. È possibile attivarla singolarmente o combinarla con la memorizzazione nella cache dei pesi per ridurre i tempi di estrazione delle immagini e di scaricamento del peso durante lo scale-out.
Verifica che la memorizzazione nella cache funzioni
Utilizza i seguenti controlli per confermare che la memorizzazione nella cache sia attiva per la tua distribuzione.
Controlla le etichette dei nodi per verificare la presenza di una cache calda
Quando la cache di un nodo è calda, l'operatore le applica un'etichetta pronta per la cache. La memorizzazione nella cache dei pesi dei modelli utilizza un'etichetta con il prefisso e la memorizzazione nella cache delle immagini utilizza il prefisso inference.sagemaker.aws.amazon.com/weights-cache-ready.inference.sagemaker.aws.amazon.com/image-cache-ready., ciascuno con il suffisso UID della configurazione della cache.
kubectl get nodes --show-labels | grep "cache-ready"
Nessun output significa che nessun nodo ha ancora riscaldato la cache.
Controlla gli eventi del pod per il montaggio della cache
Ispeziona un pod di inferenza e conferma che monti il percorso della cache locale dell'host in modalità di sola lettura. Se il volume HostPath è assente, il pod sta caricando i pesi dall'archiviazione remota.
kubectl describe podinference-pod-name-nnamespace
Controlla i log degli operatori
Esamina i log degli operatori di inferenza per individuare eventuali attività di riscaldamento della cache o eventuali errori.
kubectl logs -n hyperpod-inference-system deployment/hyperpod-inference-controller-manager | grep -i "cache"
Risoluzione dei problemi
| Caratteristiche | Possibile causa | Risoluzione |
|---|---|---|
| I pod si avviano lentamente anche se la memorizzazione nella cache è abilitata. | Il percorso NVMe non esiste nel tipo di istanza. | Verifica che il tipo di istanza disponga di una memoria NVMe locale e che hostPath corrisponda al punto di montaggio effettivo. |
| La cache non si riscalda mai. | Spazio su disco insufficiente nel percorso host. | Verifica la capacità disponibile inhostPath. I modelli di grandi dimensioni possono richiedere una notevole capacità di archiviazione locale. |
| Nessun nodo è etichettato come pronto per la cache. | Il download della cache non è riuscito o la fonte remota non è raggiungibile. | Controlla i log dell'operatore per individuare eventuali errori di download e verifica l'accesso alla rete ad Amazon S3 o Amazon FSx. |
| Le distribuzioni multiple causano una pressione del disco su un nodo. | Le distribuzioni memorizzate nella cache condividono lo stesso storage NVMe del nodo. | Utilizzate gruppi di istanze separati o riducete il numero di implementazioni simultanee memorizzate nella cache per nodo. |
Considerazioni
-
La memorizzazione nella cache dei pesi dei modelli richiede tipi di istanza con storage NVMe locale. EBS-only le istanze non sono supportate.
-
La dimensione massima del modello memorizzabile nella cache è limitata dalla capacità NVMe disponibile per il tipo di istanza.
-
Il tempo di riscaldamento della cache dipende dalle dimensioni del modello e dal throughput di rete verso l'origine remota del modello.
