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

Implementa modelli dallo storage NVMe locale usando kubectl

Questo argomento mostra come distribuire endpoint di inferenza su Amazon SageMaker HyperPod che caricano i pesi dei modelli dallo storage NVMe locale di un nodo invece di trasferirli sulla rete da Amazon S3 o Amazon FSx. La lettura dei pesi localmente elimina il salto di rete durante l'avvio del pod, il che riduce il tempo di avvio a freddo del pod di inferenza ed è utile per la scalabilità automatica degli eventi, i carichi di lavoro con scalabilità da zero e i failover sensibili alla latenza. Per i carichi di lavoro in cui la latenza di avvio a freddo non è un problema, utilizza o e salta questo argomento. modelSourceType: s3 fsx

L'NVMe locale è locale al nodo ed è temporaneo: i dati su NVMe vengono persi quando un nodo viene sostituito, ad esempio durante un'interruzione occasionale, un guasto hardware o un aggiornamento dell'AMI. Gli approcci descritti in questo argomento gestiscono la situazione in modo diverso: alcuni richiedono la precompilazione di ogni nodo, altri ricorrono automaticamente ad Amazon S3 quando il modello non viene memorizzato nella cache locale. Lo storage di istanze NVMe locale si trova in genere nelle famiglie di istanze P, G e Trn. Consulta le specifiche dello store di istanze Amazon EC2 per convalidare la disponibilità per il tuo tipo di istanza.

Puoi scegliere tra i seguenti approcci in base ai tuoi requisiti di storage:

Prerequisiti

Prima di iniziare, verifica di aver:

Scegliete il vostro approccio di distribuzione

Utilizza il seguente flusso decisionale per determinare quale approccio è giusto per il tuo caso d'uso.

                  ┌────────────────────────────┐
                  │ Want to use a volume of    │
                  │ your choice, e.g. NVMe?    │
                  └─────┬──────────────┬───────┘
                   YES  │              │ NO
                        ▼              ▼
        ┌──────────────────────┐   Use S3/FSx/HF
        │ Are you sure EVERY   │   as-is (no volume
        │ node has the model   │   override needed)
        │ on NVMe?             │
        └─────┬──────────┬─────┘
         YES  │          │ NO
              ▼          ▼
  ┌─────────────────┐  ┌───────────────────────────────┐
  │ Approach 1      │  │ Do you need the operator to   │
  │                 │  │ create S3/FSx PVCs as a       │
  │ Use k8sVolume   │  │ fallback when the model is    │
  │ field in CRD to │  │ missing on a node?            │
  │ read from NVMe  │  └──────┬────────────────┬───────┘
  │ directly.       │    YES  │                │ NO
  └─────────────────┘         ▼                ▼
                  ┌──────────────────┐  ┌──────────────────────┐
                  │ Approach 3       │  │ Approach 2           │
                  │                  │  │                      │
                  │ Use S3 with      │  │ Use k8sVolume with a │
                  │ prefetch enabled.│  │ custom initContainer │
                  │ Custom           │  │ you create that      │
                  │ initContainer    │  │ checks NVMe first    │
                  │ checks NVMe      │  │ and downloads from   │
                  │ first, falls     │  │ S3 via IRSA if the   │
                  │ back to S3, and  │  │ model is missing.    │
                  │ copies to RAM.   │  └──────────────────────┘
                  └──────────────────┘

Esegui l'implementazione utilizzando un volume Kubernetes (senza fallback)

Usa questo approccio quando hai i pesi dei modelli su NVMe su ogni nodo e desideri la configurazione più semplice: nessuna configurazione di Amazon S3 o Amazon FSx, no e senza InitContainers. PV/PVC

Una volta impostata, l'operatore salta completamente modelSourceType: kubernetesVolume la creazione. PV/PVC Non viene utilizzato alcun driver CSI, supporto con fusibile Amazon S3 o supporto Amazon FSx. Il model-weights volume fornito dal cliente viene utilizzato direttamente nelle specifiche del pod e il lavoratore legge i dati del modello da NVMe all'indirizzo. /opt/ml/model

Esegui l'implementazione utilizzando un volume Kubernetes con fallback

Usa questo approccio quando il modello potrebbe essere o meno su NVMe su un determinato nodo. Un hostPath volume funziona solo sui nodi in cui sono presenti i dati: i pod pianificati su altri nodi monterebbero un percorso vuoto o inesistente, causando il fallimento del server del modello.

In questo approccio, imposti modelSourceType: kubernetesVolume e fornisci una configurazione personalizzata initContainer che controlla prima NVMe e scarica da Amazon S3 utilizzando le credenziali IRSA se il modello è mancante.

Configura IRSA

Prima della distribuzione, configura IAM Roles for Service Accounts (IRSA) per fornire ai tuoi pod le credenziali per il download da Amazon S3.

Implementazione del modello

Esegui la distribuzione utilizzando Amazon S3 con prefetch e fallback NVMe

Usa questo approccio quando desideri prestazioni di inferenza assegnando i pesi dei modelli alla RAM, con riserva automatica ad Amazon S3 se il modello non è memorizzato nella cache locale su NVMe.

Quando imposti con, l'operatore crea automaticamente due modelSourceType: s3 volumiprefetchEnabled: true:

Si aggiunge un nvme-cache volume personalizzato che punta allo storage NVMe locale del nodo e uno personalizzato che: initContainer

Informazioni su model-weights e model-weights-copy con prefetch

Quando si utilizza prefetch, l'operatore crea due volumi relativi al modello:

Nel tuoInferenceEndpointConfig, definisci:

modelVolumeMount:
    name: model-weights
    mountPath: /opt/ml/model

Mentre si fa riferimento a quando model-weightsprefetchEnabled: true, in realtà è model-weights-copy quello che viene montato /opt/ml/model nel container di lavoro. Quando utilizzate un InitContainer personalizzato, assicuratevi di copiare i dati nel volume chiamatomodel-weights-copy, dove il lavoratore si aspetta di trovarli.

QuandoprefetchEnabled: false, c'è solo un volume (che prende il nome dal tuomodelVolumeMount.name) e viene montato direttamente su. /opt/ml/model

Configura un account di servizio personalizzato

Puoi assegnare un Kubernetes personalizzato ServiceAccount ai tuoi pod endpoint di inferenza utilizzando il campo in. spec.kubernetes.serviceAccountName InferenceEndpointConfig Ciò è utile per fornire AWS credenziali tramite IRSA (IAM Roles for Service Accounts) ai container worker o init container, ad esempio per scaricare i pesi dei modelli da Amazon S3 in uno scenario alternativo.

Se non si specifica un ServiceAccount, viene utilizzato il namespace predefinito ServiceAccount.

Abilita gli account di servizio personalizzati

Il supporto per gli account di servizio personalizzati è disabilitato per impostazione predefinita. Un amministratore del cluster deve abilitarlo nella configurazione Helm dell'operatore prima che gli utenti possano fare riferimento ServiceAccounts a custom nella propriaInferenceEndpointConfig.

Etichetta l'account del servizio

Prima di poter fare riferimento a una personalizzazione ServiceAccount, un amministratore del cluster deve etichettarla come assegnabile dall'utente:

kubectl label serviceaccount <your-service-account> \
  sagemaker.amazonaws.com/user-assignable=true \
  -n <namespace>

Solo ServiceAccounts con questa etichetta è possibile fare riferimento agli endpoint di inferenza. Si tratta di un controllo di sicurezza per prevenire l'escalation non autorizzata dei privilegi.

Specifica l'account di servizio nella tua configurazione

Aggiungi il serviceAccountName campo sottostante spec.kubernetes nel tuoInferenceEndpointConfig:

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: my-inference-endpoint
  namespace: my-namespace
spec:
  kubernetes:
    serviceAccountName: my-inference-sa
  # ... rest of your config

Regole di convalida

L'operatore convalida il serviceAccountName campo nelle operazioni di creazione e aggiornamento. La distribuzione verrà rifiutata con uno DeploymentFailed stato se viene soddisfatta una delle seguenti condizioni:

Procedure consigliate di sicurezza per gli account di servizio personalizzati

Quando utilizzi un endpoint personalizzato ServiceAccount con inferenza, l'operatore di HyperPod inferenza crea Deployments per tuo conto. Tutti i contenitori nel contenitore di inferenza, inclusi worker, init container e sidecar, ereditano le autorizzazioni di quelli specificati. ServiceAccount Segui queste best practice per proteggere il tuo cluster.

Blocca le autorizzazioni RBAC

Ambito dei ruoli IRSA IAM

Proteggi l'etichetta assegnabile dall'utente

Precarica i pesi dei modelli su NVMe

Se devi precompilare NVMe su nodi specifici prima della distribuzione, puoi utilizzare un pod una tantum per la sincronizzazione da Amazon S3.

Nomi dei volumi riservati

L'operatore gestisce diversi volumi interni che non possono essere sovrascritti tramite. kubernetes.volumes L'utilizzo di uno di questi nomi comporta una KubernetesVolumeValidationFailed condizione.

Cose da ricordare

Risoluzione dei problemi

Utilizza questi comandi di debug se l’implementazione non funziona come previsto.