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 ](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html#ac_instance-store) per convalidare la disponibilità per il tuo tipo di istanza. Puoi scegliere tra i seguenti approcci in base ai tuoi requisiti di storage: **Approcci di implementazione NVMe** | \# | Approccio | Description | | --- | --- | --- | | 1 | Volume Kubernetes (nessun fallback) | Da utilizzare quando i pesi del modello sono presenti su NVMe su ogni nodo. La configurazione più semplice che non richiede Amazon S3, Amazon FSx o InitContainers. PV/PVC | | 2 | Volume Kubernetes con fallback | Da utilizzare quando il modello potrebbe non esistere su NVMe su tutti i nodi. Fornisci una configurazione personalizzata initContainer che controlla prima NVMe e scarica da Amazon S3 utilizzando le credenziali IRSA se il modello è mancante. | | 3 | Amazon S3 con prefetch e fallback | Da utilizzare quando si desidera trasferire i pesi dei modelli nella RAM per l'avvio del pod. Se il modello non è memorizzato nella cache locale, fornisci una configurazione personalizzata initContainer che controlla innanzitutto NVMe e ritorna alla copia dal mount Amazon S3 fornito dall'operatore. | ## Prerequisiti Prima di iniziare, verifica di aver: + Configura le funzionalità di inferenza sui tuoi cluster Amazon. SageMaker HyperPod Per ulteriori informazioni, consulta [Configurazione dei HyperPod cluster per la distribuzione dei modelli](sagemaker-hyperpod-model-deployment-setup.md). + Installato l’utilità [kubectl](https://kubernetes.io/docs/reference/kubectl/) e configurato [jq](https://jqlang.org/) nel terminale. + Pre-populated pesi del modello sullo storage NVMe locale dei nodi di destinazione (consulta le istruzioni). [Precarica i pesi dei modelli su NVMe](#sagemaker-hyperpod-model-deployment-deploy-nvme-preload) ## 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` **Importante** Durante l'utilizzo`modelSourceType: kubernetesVolume`, l'operatore ricava il nome del volume previsto dalla configurazione del lavoratore. `modelVolumeMount.name` `kubernetes.volumes`deve contenere un volume con lo stesso nome. L'operatore lo convalida e rifiuta la distribuzione con una `KubernetesVolumeValidationFailed` condizione se non viene trovato alcun volume corrispondente. Negli esempi seguenti, entrambi utilizzano. `model-weights` 1. Crea il file `InferenceEndpointConfig` YAML. Sostituisci i valori segnaposto con i tuoi identificatori di risorsa effettivi. ``` cat < deploy_nvme_k8s_volume.yaml apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: nvme-k8s-volume namespace: default spec: endpointName: nvme-k8s-volume modelName: Qwen2.5-VL-7B-Instruct invocationEndpoint: v1/chat/completions replicas: 1 modelSourceConfig: modelSourceType: kubernetesVolume kubernetes: volumes: - name: model-weights hostPath: path: /opt/dlami/nvme/ type: Directory loadBalancer: healthCheckPath: /health worker: image: lmcache/vllm-openai:latest args: - /opt/ml/model - --max-model-len - "15000" - --tensor-parallel-size - "1" modelInvocationPort: containerPort: 8000 name: http modelVolumeMount: name: model-weights mountPath: /opt/ml/model resources: limits: nvidia.com/gpu: "1" requests: cpu: "6" memory: 30Gi nvidia.com/gpu: "1" environmentVariables: - name: PYTHONHASHSEED value: "123" - name: VLLM_REQUEST_TIMEOUT value: "600" EOF ``` **Nota** Per configurare il caching KV e il routing intelligente per migliorare le prestazioni, vedi. [Configura il caching KV e il routing intelligente](sagemaker-hyperpod-model-deployment-caching-routing.md#sagemaker-hyperpod-model-deployment-deploy-ftm-cache-route) 1. Distribuisci il. `InferenceEndpointConfig` ``` kubectl apply -f deploy_nvme_k8s_volume.yaml ``` 1. Verifica lo stato della distribuzione. ``` kubectl describe InferenceEndpointConfig nvme-k8s-volume -n default ``` ## 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. 1. Ottieni l'ID del provider OIDC per il tuo cluster. ``` aws eks describe-cluster --name --region \ --query "cluster.identity.oidc.issuer" --output text ``` 1. Crea una policy di fiducia IAM. Salva quanto segue con nome`trust-policy.json`, sostituendo i valori segnaposto. ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam:::oidc-provider/oidc.eks..amazonaws.com/id/" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.eks..amazonaws.com/id/:sub": "system:serviceaccount::", "oidc.eks..amazonaws.com/id/:aud": "sts.amazonaws.com" } } }] } ``` **avvertimento** Limita sempre la politica di fiducia a un namespace e a un nome specifici. ServiceAccount Non utilizzare mai caratteri jolly nella condizione dell'oggetto (ad esempio`system:serviceaccount:*:*`), poiché ciò consentirebbe a chiunque ServiceAccount in qualsiasi spazio dei nomi di assumere il ruolo. 1. Crea il ruolo IAM e allega una policy di lettura Amazon S3 con ambito per il bucket del tuo modello. ``` aws iam create-role --role-name \ --assume-role-policy-document file://trust-policy.json aws iam put-role-policy --role-name \ --policy-name S3ModelReadAccess \ --policy-document '{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::", "arn:aws:s3::://*" ] }] }' ``` 1. Crea l'account del servizio Kubernetes con l'annotazione IRSA. ``` kubectl create sa -n kubectl annotate sa -n \ eks.amazonaws.com/role-arn=arn:aws:iam:::role/ ``` ### Implementazione del modello 1. Crea il file `InferenceEndpointConfig` YAML. Sostituisci i valori segnaposto con i tuoi identificatori di risorsa effettivi. ``` cat < deploy_nvme_k8s_volume_fallback.yaml apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: nvme-k8s-volume-fallback namespace: default spec: endpointName: nvme-k8s-volume-fallback modelName: Qwen2.5-VL-7B-Instruct invocationEndpoint: v1/chat/completions replicas: 1 modelSourceConfig: modelSourceType: kubernetesVolume kubernetes: serviceAccountName: initContainers: - name: smart-loader image: public.ecr.aws/aws-cli/aws-cli:latest command: ["/bin/bash", "-c"] args: - | if [ "$(ls -A /model)" ]; then echo "NVMe hit — model already present ($(du -sh /model | cut -f1))" else echo "NVMe miss — downloading from S3" aws s3 sync s3://// /model/ fi volumeMounts: - name: model-weights mountPath: /model volumes: - name: model-weights hostPath: path: /opt/dlami/nvme/ type: DirectoryOrCreate loadBalancer: healthCheckPath: /health worker: image: lmcache/vllm-openai:latest args: - /opt/ml/model - --max-model-len - "15000" - --tensor-parallel-size - "1" modelInvocationPort: containerPort: 8000 name: http modelVolumeMount: name: model-weights mountPath: /opt/ml/model resources: limits: nvidia.com/gpu: "1" requests: cpu: "6" memory: 30Gi nvidia.com/gpu: "1" environmentVariables: - name: PYTHONHASHSEED value: "123" EOF ``` **Nota** Per configurare il caching KV e il routing intelligente per migliorare le prestazioni, vedi. [Configura il caching KV e il routing intelligente](sagemaker-hyperpod-model-deployment-caching-routing.md#sagemaker-hyperpod-model-deployment-deploy-ftm-cache-route) 1. Distribuisci il. `InferenceEndpointConfig` ``` kubectl apply -f deploy_nvme_k8s_volume_fallback.yaml ``` 1. Verifica lo stato della distribuzione. ``` kubectl describe InferenceEndpointConfig nvme-k8s-volume-fallback -n default ``` ## 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` volumi`prefetchEnabled: true`: + Un volume che prende il nome dal tuo `modelVolumeMount.name` (in genere`model-weights`): un fusibile CSI di Amazon S3 contenente il tuo modello + `model-weights-copy`— a da RAM-backed `emptyDir` dove il lavoratore legge Si aggiunge un `nvme-cache` volume personalizzato che punta allo storage NVMe locale del nodo e uno personalizzato che: `initContainer` + Se il modello esiste su NVMe, copia da NVMe a RAM ()`model-weights-copy`, ignorando completamente la rete. + Se il modello è mancante, ricorre alla copia da Amazon S3 mount () a RAM (). `model-weights` `model-weights-copy` Facoltativamente, esegue la copia su NVMe in modo che i successivi avvii del pod sullo stesso nodo utilizzino il percorso locale veloce. **Importante** Non eseguire l'override quando si utilizza `model-weights` questo approccio`kubernetes.volumes`. L'operatore crea un `model-weights` riferimento al volume CSI di Amazon S3. L'override rimuove il volume fornito dall'operatore di cui InitContainer ha bisogno per il fallback. Utilizzate un nome di volume separato (ad esempio,) per il vostro NVMe HostPath. `nvme-cache` **Importante** Non includere in. `model-weights-copy` `kubernetes.volumes` È un nome riservato creato automaticamente dall'operatore. Il tuo InitContainer può farvi riferimento `volumeMounts` ma non deve dichiararlo come volume. 1. Create il file `InferenceEndpointConfig` YAML. Sostituisci i valori segnaposto con i tuoi identificatori di risorsa effettivi. ``` cat < deploy_nvme_s3_prefetch_fallback.yaml apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: nvme-s3-prefetch-fallback namespace: default spec: endpointName: nvme-s3-prefetch-fallback modelName: Qwen2.5-VL-7B-Instruct invocationEndpoint: v1/chat/completions replicas: 1 modelSourceConfig: modelSourceType: s3 s3Storage: bucketName: region: prefetchEnabled: true kubernetes: serviceAccountName: initContainers: - name: smart-loader image: public.ecr.aws/aws-cli/aws-cli:latest command: ["/bin/bash", "-c"] args: - | # Check NVMe first, fall back to S3 mount, then copy to RAM if [ "$(ls -A /nvme)" ]; then echo "NVMe hit ($(du -sh /nvme | cut -f1))" echo "Copying model from NVMe to RAM..." cp -r /nvme/* /model/ else echo "NVMe miss — copying from S3 mount to NVMe, then NVMe to RAM" cp -r /s3-model/* /nvme/ cp -r /nvme/* /model/ fi echo "Done. $(du -sh /model | cut -f1) in RAM." volumeMounts: - name: model-weights mountPath: /s3-model - name: nvme-cache mountPath: /nvme - name: model-weights-copy mountPath: /model volumes: - name: nvme-cache hostPath: path: /opt/dlami/nvme/ type: DirectoryOrCreate loadBalancer: healthCheckPath: /health worker: image: lmcache/vllm-openai:latest args: - /opt/ml/model - --max-model-len - "15000" - --tensor-parallel-size - "1" modelInvocationPort: containerPort: 8000 name: http modelVolumeMount: name: model-weights mountPath: /opt/ml/model resources: limits: nvidia.com/gpu: "1" requests: cpu: "6" memory: 30Gi nvidia.com/gpu: "1" environmentVariables: - name: PYTHONHASHSEED value: "123" - name: VLLM_REQUEST_TIMEOUT value: "600" EOF ``` **Nota** Per configurare il caching KV e il routing intelligente per migliorare le prestazioni, vedi. [Configura il caching KV e il routing intelligente](sagemaker-hyperpod-model-deployment-caching-routing.md#sagemaker-hyperpod-model-deployment-deploy-ftm-cache-route) 1. Distribuisci il. `InferenceEndpointConfig` ``` kubectl apply -f deploy_nvme_s3_prefetch_fallback.yaml ``` 1. Verifica lo stato della distribuzione. ``` kubectl describe InferenceEndpointConfig nvme-s3-prefetch-fallback -n default ``` ## Informazioni su model-weights e model-weights-copy con prefetch Quando si utilizza prefetch, l'operatore crea due volumi relativi al modello: + Un volume che prende il nome dal tuo `modelVolumeMount.name` (in genere`model-weights`): un fusibile CSI di Amazon S3 contenente il tuo modello + `model-weights-copy`— un RAM-backed EmptyDir da cui il lavoratore legge effettivamente Nel tuo`InferenceEndpointConfig`, definisci: ``` modelVolumeMount: name: model-weights mountPath: /opt/ml/model ``` Mentre si fa riferimento a quando `model-weights``prefetchEnabled: 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 chiamato`model-weights-copy`, dove il lavoratore si aspetta di trovarli. Quando`prefetchEnabled: false`, c'è solo un volume (che prende il nome dal tuo`modelVolumeMount.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. **Importante** Il supporto per gli account di servizio personalizzati è disabilitato per impostazione predefinita e deve essere abilitato esplicitamente da un amministratore del cluster prima dell'uso. Per istruzioni, consulta [Abilita gli account di servizio personalizzati](#sagemaker-hyperpod-model-deployment-deploy-nvme-sa-enable). 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 propria`InferenceEndpointConfig`. + Aggiorna i valori Helm dell'operatore per abilitare la funzionalità. Se hai schierato l'operatore tramite Helm, esegui l'upgrade con il flag: ``` helm upgrade hyperpod-inference-operator \ --set enableCustomServiceAccounts=true \ --reuse-values ``` + Se hai implementato l'operatore come componente aggiuntivo di Amazon EKS, aggiorna la configurazione del componente aggiuntivo per includerla `enableCustomServiceAccounts: true` nelle impostazioni di configurazione avanzate. + Verifica che il pod operatore abbia la variabile di ambiente impostata: ``` kubectl get deployment hyperpod-inference-controller-manager \ -n hyperpod-inference-system \ -o jsonpath='{.spec.template.spec.containers[0].env}' | jq '.[] | select(.name=="ENABLE_CUSTOM_SERVICE_ACCOUNTS")' ``` Dovresti vedere: ``` { "name": "ENABLE_CUSTOM_SERVICE_ACCOUNTS", "value": "true" } ``` **Importante** Se questa funzione non è abilitata, tutto `InferenceEndpointConfig` ciò che specifica `kubernetes.serviceAccountName` viene rifiutato con uno `DeploymentFailed` stato e il messaggio:`kubernetes.serviceAccountName is not enabled. Requires addon configuration (enableCustomServiceAccounts: true)`. ### 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 \ sagemaker.amazonaws.com/user-assignable=true \ -n ``` 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 tuo`InferenceEndpointConfig`: ``` 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: + Non ServiceAccount esiste nel namespace — `serviceAccountName "X" not found in namespace "Y"` + Manca ServiceAccount l'etichetta richiesta — `serviceAccountName "X" is not labeled as user-assignable (requires label sagemaker.amazonaws.com/user-assignable=true)` + ServiceAccount È il sistema dell'operatore ServiceAccount — `serviceAccountName must not reference the operator's service account` **Nota** Tutti i contenitori nel contenitore di inferenza (worker, init container e sidecar) ereditano le autorizzazioni di quelli specificati. ServiceAccount Se ServiceAccount è annotato con`eks.amazonaws.com/role-arn`, il pod riceve le credenziali temporanee AWS per quel ruolo IAM. Gli amministratori del cluster devono etichettare ServiceAccounts come assegnabile dall'utente solo dopo aver esaminato i ruoli RBAC e le autorizzazioni IAM associati. **Nota** Se a ServiceAccount viene eliminato mentre an `InferenceEndpointConfig` è già in esecuzione, i pod esistenti continuano a funzionare con le credenziali correnti fino al riavvio. Tuttavia, la creazione di nuovi pod (ad esempio, durante il ridimensionamento o la riprogrammazione) fallirà perché non esiste più. ServiceAccount L'operatore convalida ServiceAccount quando la distribuzione viene creata per la prima volta e quando le specifiche IEC vengono aggiornate: non monitora continuamente il. ServiceAccount L'aggiornamento delle specifiche IEC dopo l'eliminazione della SA comporterà uno stato. `DeploymentFailed` ### 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 ** + Crea un carico di lavoro dedicato ServiceAccount per ogni carico di lavoro di inferenza. Non riutilizzarlo ServiceAccounts tra carichi di lavoro non correlati. + Associa solo le autorizzazioni RBAC minime richieste. Ad esempio, se il tuo contenitore init deve solo leggere da Amazon S3, non ServiceAccount dovrebbe avere le autorizzazioni per elencare o modificare le risorse Kubernetes. ``` # Example: minimal Role for an inference workload that only needs S3 access via IRSA # No Kubernetes API permissions needed — IRSA provides AWS credentials directly apiVersion: v1 kind: ServiceAccount metadata: name: my-inference-sa namespace: my-namespace labels: sagemaker.amazonaws.com/user-assignable: "true" annotations: eks.amazonaws.com/role-arn: arn:aws:iam:::role/ ``` + Evita di concedere autorizzazioni () a livello di cluster per l'utilizzo da parte dei pod di inferenza. ClusterRoleBindings ServiceAccounts **Ambito dei ruoli IRSA IAM ** + Quando annoti un ServiceAccount with`eks.amazonaws.com/role-arn`, assicurati che il ruolo IAM segua i principi del privilegio minimo. + Assegna le autorizzazioni di Amazon S3 al bucket e al prefisso specifici contenenti i pesi del modello. ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::", "arn:aws:s3::://*" ] }] } ``` + Non utilizzare politiche gestite generiche, ad esempio in fase di produzione. `AmazonS3FullAccess` Usa `AmazonS3ReadOnlyAccess` o una policy personalizzata limitata al bucket del tuo modello. **Proteggi l'etichetta assegnabile dall'utente ** + Solo gli amministratori del cluster devono aggiungere o rimuovere l'etichetta. `sagemaker.amazonaws.com/user-assignable=true` Usa Kubernetes RBAC per limitare chi può modificare le etichette nel tuo namespace. ServiceAccount + Esamina i ruoli RBAC e le autorizzazioni IAM associati a a prima di etichettarlo come assegnabile dall'utente. ServiceAccount + Verifica periodicamente quali sono i portatori dell'etichetta. ServiceAccounts `user-assignable` ``` kubectl get serviceaccounts -n -l sagemaker.amazonaws.com/user-assignable=true ``` + Assicurati che i ruoli non amministrativi non `patch` includano `update` né `create` verbi sulle ServiceAccount risorse. L'operatore convalida l'`user-assignable`etichetta al momento della distribuzione, ma non impedisce agli utenti non autorizzati di aggiungere l'etichetta a un. ServiceAccount Limitare chi può modificare ServiceAccounts tramite RBAC è il controllo principale per proteggere questa etichetta. Non-admin gli utenti devono avere e accedere solo a: `get` `list` ``` # Example: RBAC Role for non-admin users — read-only access to ServiceAccounts apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: sa-read-only namespace: rules: - apiGroups: [""] resources: ["serviceaccounts"] verbs: ["get", "list"] ``` **Importante** L'operatore di HyperPod inferenza funge da intermediario che crea le distribuzioni per conto degli utenti. A differenza dei carichi di lavoro Kubernetes standard in cui il chiamante crea direttamente i pod, l'operatore assegna i pod specificati ai pod che crea. ServiceAccount Ciò significa che tutte le autorizzazioni concesse a un utente assegnabile ServiceAccount sono effettivamente disponibili per chiunque possa creare un nome in quel namespace. `InferenceEndpointConfig` Assicurati che l'RBAC a livello di namespace controlli chi può creare e aggiornare le risorse. `InferenceEndpointConfig` ## 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. **Nota** Questo approccio si rivolge a un nodo specifico tramite `nodeName` scalabilità automatica e non funziona. Per gli scenari di scalabilità automatica, utilizza il volume Kubernetes con fallback o Amazon S3 con approcci di prefetch, che gestiscono automaticamente i modelli mancanti tramite la logica di fallback InitContainer. 1. Crea il file YAML del pod di precaricamento. Sostituisci i valori segnaposto con gli identificatori effettivi delle risorse. ``` cat < nvme-s3-copy.yaml apiVersion: v1 kind: Pod metadata: name: nvme-s3-copy namespace: default spec: nodeName: restartPolicy: Never containers: - name: s3-copy image: public.ecr.aws/aws-cli/aws-cli:latest command: ["/bin/bash", "-c"] args: - | echo "=== Starting S3 sync to NVMe ===" aws s3 sync s3://// /nvme// --region echo "=== Sync complete ===" ls -la /nvme// du -sh /nvme// echo "=== Done ===" volumeMounts: - name: nvme-storage mountPath: /nvme serviceAccountName: default volumes: - name: nvme-storage hostPath: path: /opt/dlami/nvme type: Directory EOF ``` 1. Applica il pod e monitora l'avanzamento della sincronizzazione. ``` kubectl apply -f nvme-s3-copy.yaml kubectl get pod nvme-s3-copy -w kubectl logs nvme-s3-copy -f ``` 1. Pulisci il pod al termine della sincronizzazione. ``` kubectl delete pod nvme-s3-copy ``` ## 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. **Nomi di volumi riservati** | \# | Nome | Scopo | | --- | --- | --- | | 1 | shm | Memoria condivisa (/dev/shm) per la comunicazione tra processi | | 2 | model-weights-copy | RAM-backed EmptyDir utilizzato quando prefetchEnabled: true | | 3 | parallel-copy-configmap | ConfigMap per script di copia parallela (prefetch) | | 4 | lmcache-config | volume di configurazione LMCache | | 5 | gated-model-downloader-configmap | ConfigMap per lo script di download del modello gated | ## Cose da ricordare + **Non utilizzare nomi di volume riservati. ** L'operatore gestisce diversi volumi interni (vedi[Nomi dei volumi riservati](#sagemaker-hyperpod-model-deployment-deploy-nvme-reserved-volumes)). L'utilizzo di uno di questi nomi `kubernetes.volumes` determina una `KubernetesVolumeValidationFailed` condizione. + **I nomi dei volumi devono corrispondere. ** L'operatore ricava il nome del volume da`modelVolumeMount.name`. Quando si utilizza`modelSourceType: kubernetesVolume`, `kubernetes.volumes` deve contenere un volume con lo stesso nome. + **Monta i volumi nella posizione corretta nel tuo InitContainer. ** Assicurati che qualsiasi volume creato sia montato nel percorso corretto nel tuo InitContainer. + **Non è necessario un account di servizio personalizzato per S3/FSx. ** Se non riesci a creare account di servizio personalizzati o preferisci non farlo, puoi utilizzare `modelSourceType: s3` o`fsx`. L'operatore effettua il S3/FSx provisioning dei volumi automaticamente. È comunque possibile aggiungere volumi personalizzati `initContainers` e sovrascrivere allo storage gestito dall'operatore. + **Le credenziali IRSA vengono inserite in tutti i contenitori. ** Quando imposti un account `kubernetes.serviceAccountName` di servizio con un'annotazione IRSA, Amazon EKS inserisce AWS le credenziali (`aws-iam-token`volume,,`AWS_WEB_IDENTITY_TOKEN_FILE`) in tutti i contenitori`AWS_ROLE_ARN`, inclusi i tuoi InitContainers personalizzati. + **Non impostarlo durante l'uso. `modelLocation` `kubernetesVolume` ** Il percorso del volume è controllato da`kubernetes.volumes`. L'impostazione di `modelLocation` quando `modelSourceType` è `kubernetesVolume` genera un errore di convalida. + **Scopri come `model-weights-copy` funziona `model-weights` vs con prefetch. ** Quando`prefetchEnabled: true`, l'operatore crea due volumi relativi al modello: + `model-weights`— il volume di origine (da Amazon S3/Amazon FSx PVC o dal tuo override) + `model-weights-copy`— un RAM-backed EmptyDir da cui il lavoratore legge effettivamente + Mentre si fa riferimento `model-weights` nella configurazione, quando`prefetchEnabled: 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 chiamato`model-weights-copy`, dove il lavoratore si aspetta di trovarli. Quando`prefetchEnabled: false`, c'è solo un volume (che prende il nome dal tuo`modelVolumeMount.name`) e viene montato direttamente su. `/opt/ml/model` ## Risoluzione dei problemi Utilizza questi comandi di debug se l’implementazione non funziona come previsto. + Controlla lo `InferenceEndpointConfig` stato per vedere lo stato di distribuzione di alto livello e gli eventuali problemi di configurazione. ``` kubectl describe InferenceEndpointConfig -n ``` + Controlla lo stato dell’implementazione di Kubernetes. ``` kubectl describe deployment -n ``` + Controlla lo stato di tutti gli oggetti Kubernetes nel tuo namespace. ``` kubectl get pods,svc,deployment,InferenceEndpointConfig,sagemakerendpointregistration -n ``` + Controlla i log di InitContainer se la fase di caricamento del modello non riesce. ``` kubectl logs -c smart-loader -n ``` + Se la distribuzione non riesce con «not found in namespace», verifica che esista: ServiceAccount ``` kubectl get serviceaccount -n ``` + Se la distribuzione non riesce con «non etichettato come assegnabile dall'utente», chiedi all'amministratore del cluster di aggiungere l'etichetta richiesta: ``` kubectl label serviceaccount sagemaker.amazonaws.com/user-assignable=true -n ``` + Se la distribuzione non riesce con la dicitura «deve non fare riferimento all'account di servizio dell'operatore», creane uno separato per il carico di lavoro. ServiceAccount Non è possibile utilizzare quello dell'operatore di HyperPod inferenza. ServiceAccount