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

Distribuisci 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 anziché trasferirli sulla rete da Amazon S3 o Amazon FSx. La lettura locale dei pesi elimina l'hop di rete durante l'avvio del pod, il che riduce il tempo di avvio a freddo del pod di inferenza ed è utile per eventi di scalabilità automatica, carichi di lavoro con scalabilità da zero e failover sensibili alla latenza. Per i carichi di lavoro in cui la latenza con avvio a freddo non è un problema, usa o salta questo argomento. modelSourceType: s3 fsx

L'NVMe locale è locale del nodo ed è effimero: i dati su NVMe vengono persi quando un nodo viene sostituito, ad esempio durante un'interruzione puntuale, un guasto hardware o un aggiornamento dell'AMI. Gli approcci illustrati 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 è 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 dell'instance store di 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:

Scegli il tuo approccio di implementazione

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 la distribuzione utilizzando un volume Kubernetes (senza fallback)

Utilizza questo approccio quando disponi di pesi dei modelli su NVMe su ogni nodo e desideri la configurazione più semplice: nessuna configurazione Amazon S3 o Amazon FSx, niente e niente InitContainers. PV/PVC

Quando imposti, l'operatore salta completamente la modelSourceType: kubernetesVolume creazione. PV/PVC Non viene utilizzato alcun driver CSI, montaggio su fusibili Amazon S3 o montaggio Amazon FSx. Il model-weights volume fornito dal cliente viene utilizzato direttamente nelle specifiche del pod e l'operatore legge i dati del modello da NVMe all'indirizzo. /opt/ml/model

Esegui la distribuzione utilizzando un volume Kubernetes con fallback

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

In questo approccio, imposti modelSourceType: kubernetesVolume e fornisci una soluzione personalizzata initContainer che controlla innanzitutto 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 le credenziali dei tuoi pod per il download da Amazon S3.

Implementazione del modello

Esegui la distribuzione utilizzando Amazon S3 con prefetch e fallback NVMe

Utilizza questo approccio quando desideri prestazioni di inferenza organizzando i pesi del modello sulla RAM, con fallback automatico su 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 un volume personalizzato che: initContainer

Comprensione dei pesi dei modelli e dei pesi dei modelli con prefetch

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

Nel tuo, definisciInferenceEndpointConfig:

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

Mentre fate riferimentomodel-weights, quandoprefetchEnabled: true, in realtà model-weights-copy viene montato /opt/ml/model nel container del lavoratore. Quando utilizzi un InitContainer personalizzato, assicurati di copiare i dati nel volume chiamatomodel-weights-copy, che è dove l'operatore si aspetta di trovarli.

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

Configura un account di servizio personalizzato

Puoi assegnare un Kubernetes personalizzato ServiceAccount ai tuoi pod degli 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 di lavoro o ai contenitori init, ad esempio per scaricare i pesi dei modelli da Amazon S3 in uno scenario di fallback.

Se non si specifica a ServiceAccount, viene utilizzata l'impostazione predefinita ServiceAccount dello spazio dei nomi.

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 nel proprioInferenceEndpointConfig.

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 possono essere referenziati dagli endpoint di inferenza. Si tratta di un controllo di sicurezza per prevenire l'escalation non autorizzata dei privilegi.

Specificare l'account di servizio nella 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 sia nelle operazioni di creazione che di aggiornamento. La distribuzione verrà rifiutata con uno DeploymentFailed status se viene soddisfatta una delle seguenti condizioni:

Le migliori pratiche di sicurezza per gli account di servizio personalizzati

Quando utilizzi un endpoint personalizzato ServiceAccount con inferenza, l'operatore di HyperPod inferenza crea distribuzioni per tuo conto. Tutti i contenitori nel contenitore di inferenza, inclusi worker, init container e sidecar, ereditano le autorizzazioni specificate. 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 prepopolare NVMe su nodi specifici prima della distribuzione, puoi utilizzare un pod unico per la sincronizzazione da Amazon S3.

Nomi dei volumi riservati

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

Cose da ricordare

Risoluzione dei problemi

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