Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Implemente modelos desde el almacenamiento NVMe local mediante kubectl En este tema, se muestra cómo implementar puntos de enlace de inferencia en Amazon SageMaker HyperPod que carguen los pesos de los modelos desde el almacenamiento NVMe local de un nodo en lugar de transferirlos a la red desde Amazon S3 o Amazon FSx. La lectura local de las ponderaciones elimina los saltos de red durante el arranque del pod, lo que reduce el tiempo de arranque en frío del pod de inferencia y resulta útil para escalar automáticamente eventos, cargas de trabajo que escalan desde cero y conmutaciones por error sensibles a la latencia. Para las cargas de trabajo en las que la latencia de arranque en frío no sea un problema, utilice u omita este tema. `modelSourceType: s3` `fsx` El NVMe local es un nodo local y efímero: los datos del NVMe se pierden cuando se reemplaza un nodo, por ejemplo, durante una interrupción puntual, un fallo de hardware o una actualización de la AMI. Los enfoques de este tema abordan este tema de forma diferente: algunos requieren que rellene previamente todos los nodos, otros recurren a Amazon S3 automáticamente cuando el modelo no está almacenado en caché local. El almacenamiento de instancias NVMe local suele encontrarse en las familias de instancias P, G y Trn. Consulte las [especificaciones del almacén de instancias de Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html#ac_instance-store) para validar la disponibilidad de su tipo de instancia. Puede elegir entre los siguientes enfoques en función de sus requisitos de almacenamiento: **Enfoques de implementación de NVMe** | \# | Método | Description (Descripción) | | --- | --- | --- | | 1 | Volumen de Kubernetes (sin respaldo) | Úselo cuando existan pesos de modelo en NVMe en todos los nodos. La configuración más sencilla sin necesidad de Amazon S3, Amazon FSx ni PV/PVC InitContainers. | | 2 | Volumen de Kubernetes con respaldo | Úselo cuando es posible que el modelo no exista en NVMe en todos los nodos. Usted proporciona una personalización initContainer que comprueba primero NVMe y descarga desde Amazon S3 con credenciales IRSA si falta el modelo. | | 3 | Amazon S3 con captura previa y recuperación | Úselo cuando desee transferir los pesos del modelo a la RAM para el inicio del pod. Usted proporciona una personalización initContainer que comprueba primero NVMe y vuelve a copiar desde el soporte Amazon S3 aprovisionado por el operador si el modelo no está almacenado en caché local. | ## Requisitos previos Antes de comenzar, compruebe que: + Configure capacidades de inferencia en sus SageMaker HyperPod clústeres de Amazon. Para obtener más información, consulte [Configuración de los HyperPod clústeres para la implementación de modelos](sagemaker-hyperpod-model-deployment-setup.md). + Ha instalado la utilidad [kubectl](https://kubernetes.io/docs/reference/kubectl/) y configurado [jq](https://jqlang.org/) en su terminal. + Pre-populated modele las ponderaciones en el almacenamiento NVMe local de sus nodos de destino (consulte las [Precarga los pesos de los modelos en NVMe](#sagemaker-hyperpod-model-deployment-deploy-nvme-preload) instrucciones). ## Elija su enfoque de implementación Utilice el siguiente flujo de decisiones para determinar qué enfoque es el adecuado para su caso de 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. │ └──────────────────────┘ └──────────────────┘ ``` ## Implemente mediante un volumen de Kubernetes (sin respaldo) Utilice este enfoque cuando tenga pesos de modelo en NVMe en cada nodo y desee la configuración más sencilla: sin configuración de Amazon S3 o Amazon FSx, PV/PVC ni InitContainers. Cuando se configura`modelSourceType: kubernetesVolume`, el operador omite la creación por completo. PV/PVC No se utiliza ningún controlador CSI, montura de fusible Amazon S3 ni montura Amazon FSx. El `model-weights` volumen proporcionado por el cliente se utiliza directamente en las especificaciones del módulo y el trabajador lee los datos del modelo desde NVMe en. `/opt/ml/model` **importante** Al usarlo`modelSourceType: kubernetesVolume`, el operador obtiene el nombre del volumen esperado de la configuración de `modelVolumeMount.name` trabajo. `kubernetes.volumes`debe contener un volumen con el mismo nombre. El operador lo valida y rechaza el despliegue con una `KubernetesVolumeValidationFailed` condición si no encuentra ningún volumen coincidente. En los ejemplos siguientes, ambos utilizan`model-weights`. 1. Crea el archivo `InferenceEndpointConfig` YAML. Sustituya los valores de los marcadores de posición por sus identificadores de recursos reales. ``` 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 ``` 1. Implemente el. `InferenceEndpointConfig` ``` kubectl apply -f deploy_nvme_k8s_volume.yaml ``` 1. Compruebe el estado del despliegue. ``` kubectl describe InferenceEndpointConfig nvme-k8s-volume -n default ``` ## Implemente mediante un volumen de Kubernetes con respaldo Utilice este enfoque cuando el modelo esté o no en NVMe en un nodo determinado. Un `hostPath` volumen solo funciona en los nodos en los que existen los datos: los pods programados en otros nodos montarían una ruta vacía o inexistente, lo que provocaría un error en el servidor modelo. En este enfoque, se establece `modelSourceType: kubernetesVolume` y se proporciona una personalización `initContainer` que comprueba primero NVMe y descarga desde Amazon S3 con credenciales IRSA si falta el modelo. ### Configure IRSA Antes de la implementación, configure las funciones de IAM para las cuentas de servicio (IRSA) a fin de proporcionar a sus pods las credenciales para descargarlos desde Amazon S3. 1. Obtenga el ID de proveedor de OIDC para su clúster. ``` aws eks describe-cluster --name --region \ --query "cluster.identity.oidc.issuer" --output text ``` 1. Cree una política de confianza de IAM. Guarde lo siguiente como`trust-policy.json`, sustituyendo los valores de los marcadores de posición. ``` { "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" } } }] } ``` **aviso** Limite siempre la política de confianza a un espacio de nombres y un nombre específicos. ServiceAccount Nunca utilices caracteres comodín en la condición de asunto (por ejemplo,`system:serviceaccount:*:*`), ya que esto permitiría que cualquier persona de cualquier espacio ServiceAccount de nombres asumiera esa función. 1. Cree el rol de IAM y adjunte una política de lectura de Amazon S3 específica para su segmento de modelos. ``` 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. Cree la cuenta de servicio de Kubernetes con la anotación IRSA. ``` kubectl create sa -n kubectl annotate sa -n \ eks.amazonaws.com/role-arn=arn:aws:iam:::role/ ``` ### Implementación del modelo 1. Cree el archivo YAML. `InferenceEndpointConfig` Sustituya los valores de los marcadores de posición por sus identificadores de recursos reales. ``` 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 ``` 1. Implemente el. `InferenceEndpointConfig` ``` kubectl apply -f deploy_nvme_k8s_volume_fallback.yaml ``` 1. Compruebe el estado del despliegue. ``` kubectl describe InferenceEndpointConfig nvme-k8s-volume-fallback -n default ``` ## Implemente con Amazon S3 con prefetch y NVMe fallback Utilice este enfoque cuando desee obtener un rendimiento de inferencia organizando los pesos de los modelos en la RAM y recurriendo automáticamente a Amazon S3 si el modelo no está almacenado en caché local en NVMe. Cuando se configura `modelSourceType: s3` con`prefetchEnabled: true`, el operador crea dos volúmenes automáticamente: + Un volumen que lleve el nombre de su `modelVolumeMount.name` (normalmente`model-weights`), un soporte de fusible CSI de Amazon S3 que contenga su modelo + `model-weights-copy`— un RAM-backed `emptyDir` lugar desde el que el trabajador lee Añades un `nvme-cache` volumen personalizado que apunta al almacenamiento NVMe local del nodo y un volumen personalizado `initContainer` que: + Si el modelo existe en NVMe, copia de NVMe a la RAM (`model-weights-copy`), omitiendo por completo la red. + Si falta el modelo, vuelve a copiar del soporte de Amazon S3 (`model-weights`) a la RAM (`model-weights-copy`). Opcionalmente, se copia a NVMe para que los subsiguientes inicios del pod en el mismo nodo utilicen la ruta local rápida. **importante** No lo anule `model-weights` `kubernetes.volumes` cuando utilice este enfoque. El operador crea un `model-weights` apuntamiento al volumen CSI de Amazon S3. Al anularlo, se elimina el volumen aprovisionado por el operador que su InitContainer necesita como alternativa. Use un nombre de volumen diferente (por ejemplo,) para su HostPath de NVMe. `nvme-cache` **importante** No lo incluya `model-weights-copy` en. `kubernetes.volumes` Es un nombre reservado creado automáticamente por el operador. Su InitContainer puede hacer referencia a él`volumeMounts`, pero no debe declararlo como un volumen. 1. Crea el archivo `InferenceEndpointConfig` YAML. Sustituya los valores de los marcadores de posición por sus identificadores de recursos reales. ``` 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 ``` 1. Implemente el. `InferenceEndpointConfig` ``` kubectl apply -f deploy_nvme_s3_prefetch_fallback.yaml ``` 1. Compruebe el estado del despliegue. ``` kubectl describe InferenceEndpointConfig nvme-s3-prefetch-fallback -n default ``` ## Cómo entender los pesos de los modelos y los pesos de los modelos copiados con prefetch Al utilizar la captura previa, el operador crea dos volúmenes relacionados con el modelo: + Un volumen que lleve el nombre de su `modelVolumeMount.name` (normalmente`model-weights`), un soporte de fusible CSI de Amazon S3 que contenga su modelo + `model-weights-copy`— un RAM-backed EmptyDir desde donde el trabajador lee realmente En tu`InferenceEndpointConfig`, defines: ``` modelVolumeMount: name: model-weights mountPath: /opt/ml/model ``` Al hacer referencia a cuándo `model-weights``prefetchEnabled: true`, en realidad es lo `model-weights-copy` que se monta `/opt/ml/model` en el contenedor de trabajo. Cuando utilice un InitContainer personalizado, asegúrese de copiar los datos en el volumen denominado`model-weights-copy`, que es donde el trabajador espera encontrarlos. Cuando `prefetchEnabled: false` solo hay un volumen (que lleva el nombre del suyo`modelVolumeMount.name`) y está montado directamente en él. `/opt/ml/model` ## Configure una cuenta de servicio personalizada Puede asignar un Kubernetes personalizado ServiceAccount a sus pods de puntos finales de inferencia mediante el campo del`spec.kubernetes.serviceAccountName`. `InferenceEndpointConfig` Esto resulta útil para proporcionar AWS credenciales mediante IRSA (funciones de IAM para cuentas de servicio) a sus contenedores de trabajo o contenedores de inicio, por ejemplo, para descargar pesos de modelos de Amazon S3 en un escenario alternativo. **importante** La compatibilidad con cuentas de servicio personalizadas está deshabilitada de forma predeterminada y un administrador de clústeres debe habilitarla de forma explícita antes de utilizarla. Para obtener instrucciones, consulte [Habilite las cuentas de servicio personalizadas](#sagemaker-hyperpod-model-deployment-deploy-nvme-sa-enable). Si no especificas una ServiceAccount, se utilizará el espacio de nombres ServiceAccount predeterminado. ### Habilite las cuentas de servicio personalizadas La compatibilidad con cuentas de servicio personalizadas está deshabilitada de forma predeterminada. Un administrador de clústeres debe habilitarlo en la configuración de Helm del operador para que los usuarios puedan hacer referencia a la personalización ServiceAccounts en su configuración`InferenceEndpointConfig`. + Actualice los valores de Helm del operador para activar la función. Si desplegaste al operador mediante Helm, actualízalo con la siguiente bandera: ``` helm upgrade hyperpod-inference-operator \ --set enableCustomServiceAccounts=true \ --reuse-values ``` + Si implementó el operador como un complemento de Amazon EKS, actualice la configuración del complemento para incluirlo `enableCustomServiceAccounts: true` en los ajustes de configuración avanzada. + Compruebe que el módulo del operador tenga configurada la variable de entorno: ``` kubectl get deployment hyperpod-inference-operator-controller-manager \ -n hyperpod-inference-system \ -o jsonpath='{.spec.template.spec.containers[0].env}' | jq '.[] | select(.name=="ENABLE_CUSTOM_SERVICE_ACCOUNTS")' ``` Deberías ver lo siguiente: ``` { "name": "ENABLE_CUSTOM_SERVICE_ACCOUNTS", "value": "true" } ``` **importante** Si esta función no está habilitada, `kubernetes.serviceAccountName` se rechazará cualquiera `InferenceEndpointConfig` que lo especifique con un `DeploymentFailed` estado y el mensaje:`kubernetes.serviceAccountName is not enabled. Requires addon configuration (enableCustomServiceAccounts: true)`. ### Etiquete la cuenta de servicio Para poder hacer referencia a una personalización ServiceAccount, el administrador del clúster debe etiquetarla como asignable por el usuario: ``` kubectl label serviceaccount \ sagemaker.amazonaws.com/user-assignable=true \ -n ``` Los puntos finales de inferencia solo pueden hacer referencia a ellos ServiceAccounts con esta etiqueta. Se trata de un control de seguridad para evitar la escalada de privilegios no autorizada. ### Especifique la cuenta de servicio en su configuración Añada el `serviceAccountName` campo siguiente `spec.kubernetes` en su`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 ``` ### Reglas de validación El operador valida el `serviceAccountName` campo tanto en las operaciones de creación como en las de actualización. El despliegue se rechazará con un `DeploymentFailed` estado si se cumple alguna de las siguientes condiciones: + No ServiceAccount existe en el espacio de nombres: `serviceAccountName "X" not found in namespace "Y"` + Falta ServiceAccount la etiqueta requerida: `serviceAccountName "X" is not labeled as user-assignable (requires label sagemaker.amazonaws.com/user-assignable=true)` + Este ServiceAccount es el sistema del operador ServiceAccount : `serviceAccountName must not reference the operator's service account` **nota** Todos los contenedores del módulo de inferencia (worker, init containers y sidecars) heredan los permisos de los especificados. ServiceAccount Si ServiceAccount está anotado con`eks.amazonaws.com/role-arn`, el pod recibe AWS credenciales temporales para esa función de IAM. Los administradores de clústeres solo deben etiquetarlo ServiceAccounts como asignable por el usuario después de revisar los roles RBAC y los permisos de IAM asociados. **nota** Si ServiceAccount se elimina a mientras an ya `InferenceEndpointConfig` está en ejecución, los pods existentes seguirán ejecutándose con sus credenciales actuales hasta que se reinicien. Sin embargo, la creación de nuevos pods (por ejemplo, durante el escalado o la reprogramación) fallará porque ya no existe. ServiceAccount El operador lo valida ServiceAccount cuando se crea el despliegue por primera vez y cuando se actualiza la especificación IEC; no la supervisa continuamente. ServiceAccount Si se actualiza la especificación IEC después de eliminar la SA, se generará un estado. `DeploymentFailed` ### Prácticas recomendadas de seguridad para cuentas de servicio personalizadas Cuando utilizas un dispositivo personalizado ServiceAccount con puntos finales de inferencia, el operador de HyperPod inferencia crea despliegues en tu nombre. Todos los contenedores del módulo de inferencia, incluidos el contenedor de trabajo, los contenedores de inicio y los sidecars, heredan los permisos de los especificados. ServiceAccount Siga estas prácticas recomendadas para proteger su clúster. **Bloquee los permisos RBAC** + Cree una carga de trabajo dedicada ServiceAccount a cada inferencia. No la reutilices ServiceAccounts en cargas de trabajo no relacionadas. + Vincula solo los permisos RBAC mínimos necesarios. Por ejemplo, si tu contenedor de inicio solo necesita leer datos de Amazon S3, no ServiceAccount debería tener permisos para enumerar o modificar los recursos de 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/ ``` + Evite conceder permisos para todo el clúster () ClusterRoleBindings para que los utilicen los pods de inferencia. ServiceAccounts **Ámbito: funciones de IRSA (IAM)** + Al anotar un ServiceAccount signo`eks.amazonaws.com/role-arn`, asegúrese de que la función de IAM siga los principios de privilegios mínimos. + Limite los permisos de Amazon S3 al bucket y prefijo específicos que contengan los pesos de su modelo. ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::", "arn:aws:s3::://*" ] }] } ``` + No utilice políticas gestionadas de forma amplia, como `AmazonS3FullAccess` en el caso de la producción. Utilice `AmazonS3ReadOnlyAccess` una política personalizada adaptada a su segmento de modelos. **Proteja la etiqueta asignable por el usuario** + Solo los administradores del clúster deben añadir o quitar la `sagemaker.amazonaws.com/user-assignable=true` etiqueta. Usa el RBAC de Kubernetes para restringir quién puede modificar ServiceAccount las etiquetas en tu espacio de nombres. + Revisa las funciones del RBAC y los permisos de IAM asociados a un antes de etiquetarlo como asignable por el usuario. ServiceAccount + Audite periódicamente los que llevan la etiqueta. ServiceAccounts `user-assignable` ``` kubectl get serviceaccounts -n -l sagemaker.amazonaws.com/user-assignable=true ``` + Asegúrese de que las funciones que no son de administrador no incluyan `patch` ni `create` verbos en ServiceAccount los recursos. `update` El operador valida la `user-assignable` etiqueta en el momento de la implementación, pero no impide que usuarios no autorizados añadan la etiqueta a un. ServiceAccount Restringir quién puede modificarla ServiceAccounts mediante el RBAC es el principal control para proteger esta etiqueta. Non-admin los usuarios solo deberían tener acceso `get` a: `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** El operador de HyperPod inferencia actúa como un intermediario que crea las implementaciones en nombre de los usuarios. A diferencia de las cargas de trabajo estándar de Kubernetes, en las que la persona que llama crea directamente los pods, el operador asigna los módulos especificados a los que crea. ServiceAccount Esto significa que cualquier permiso otorgado a un usuario asignable está disponible de forma efectiva para cualquier persona ServiceAccount que pueda crear uno en ese espacio de nombres. `InferenceEndpointConfig` Asegúrese de que el RBAC a nivel de espacio de nombres controle quién puede crear y actualizar los recursos. `InferenceEndpointConfig` ## Precarga los pesos de los modelos en NVMe Si necesita rellenar previamente NVMe en nodos específicos antes de la implementación, puede usar un pod único para sincronizar desde Amazon S3. **nota** Este enfoque se dirige a un nodo específico mediante el escalado automático `nodeName` y no funciona con él. Para los escenarios de escalado automático, utilice el volumen de Kubernetes con respaldo o Amazon S3 con enfoques de captura previa, que gestionan los modelos faltantes automáticamente mediante la lógica de respaldo de InitContainer. 1. Cree el archivo YAML del pod de precarga. Sustituya los valores de los marcadores de posición por sus identificadores de recursos reales. ``` 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. Aplica el módulo y supervisa el progreso de la sincronización. ``` kubectl apply -f nvme-s3-copy.yaml kubectl get pod nvme-s3-copy -w kubectl logs nvme-s3-copy -f ``` 1. Limpia el pod una vez finalizada la sincronización. ``` kubectl delete pod nvme-s3-copy ``` ## Nombres de volúmenes reservados El operador administra varios volúmenes internos que no se pueden anular mediante ellos. `kubernetes.volumes` El uso de cualquiera de estos nombres da como resultado una `KubernetesVolumeValidationFailed` condición. **Nombres de volúmenes reservados** | \# | Name | Finalidad | | --- | --- | --- | | 1 | shm | Memoria compartida (/dev/shm) para la comunicación entre procesos | | 2 | model-weights-copy | RAM-backed EmptyDir se usa cuando prefetchEnabled: true | | 3 | parallel-copy-configmap | ConfigMap para script de copia paralela (prefetch) | | 4 | lmcache-config | volumen de configuración de LMCache | | 5 | gated-model-downloader-configmap | ConfigMap para un modelo cerrado, descargue el script | ## Cosas para recordar + **No utilice nombres de volúmenes reservados.** El operador administra varios volúmenes internos (consulte[Nombres de volúmenes reservados](#sagemaker-hyperpod-model-deployment-deploy-nvme-reserved-volumes)). El uso de cualquiera de estos nombres `kubernetes.volumes` da como resultado una `KubernetesVolumeValidationFailed` condición. + **Los nombres de los volúmenes deben coincidir.** El operador deriva el nombre del `modelVolumeMount.name` volumen. Cuando se usa`modelSourceType: kubernetesVolume`, `kubernetes.volumes` debe contener un volumen con el mismo nombre. + **Monte los volúmenes en la ubicación correcta de su InitContainer.** Asegúrese de que cualquier volumen que cree esté montado en la ruta correcta en su InitContainer. + **No se necesita una cuenta de servicio personalizada para. S3/FSx** Si no puede crear cuentas de servicio personalizadas o prefiere no hacerlo, puede usar `modelSourceType: s3` o`fsx`. El operador aprovisiona S3/FSx los volúmenes automáticamente. Aún puede agregar volúmenes personalizados `initContainers` y anularlos además del almacenamiento administrado por el operador. + **Las credenciales de IRSA se insertan en todos los contenedores.** Cuando configura `kubernetes.serviceAccountName` una cuenta de servicio con una anotación IRSA, Amazon EKS inyecta las AWS credenciales (`aws-iam-token`volumen,,`AWS_WEB_IDENTITY_TOKEN_FILE`) en todos los contenedores`AWS_ROLE_ARN`, incluidos los InitContainers personalizados. + **No lo configure cuando lo utilice. `modelLocation` `kubernetesVolume`** La trayectoria del volumen se controla mediante`kubernetes.volumes`. Si `modelLocation` se establece cuándo `modelSourceType` se `kubernetesVolume` produce un error de validación. + **Comprenda cómo `model-weights-copy` funciona `model-weights` vs con prefetch.** Cuando`prefetchEnabled: true`, el operador crea dos volúmenes relacionados con el modelo: + `model-weights`— el volumen de origen (de Amazon S3/Amazon FSx PVC o de su sustituto) + `model-weights-copy`— un RAM-backed EmptyDir desde donde el trabajador lee realmente + Como referencia `model-weights` en su configuración, cuándo`prefetchEnabled: true`, en realidad es lo `model-weights-copy` que se monta `/opt/ml/model` en el contenedor de trabajo. Cuando utilices un InitContainer personalizado, asegúrate de copiar los datos en el volumen denominado`model-weights-copy`, que es donde el trabajador espera encontrarlos. Cuando `prefetchEnabled: false` solo hay un volumen (que lleva el nombre del suyo`modelVolumeMount.name`) y está montado directamente en él. `/opt/ml/model` ## Resolución de problemas Use estos comandos de depuración si la implementación no funciona según lo previsto. + Compruebe el `InferenceEndpointConfig` estado para ver el estado de la implementación de alto nivel y cualquier problema de configuración. ``` kubectl describe InferenceEndpointConfig -n ``` + Compruebe el estado de la implementación de Kubernetes. ``` kubectl describe deployment -n ``` + Comprueba el estado de todos los objetos de Kubernetes de tu espacio de nombres. ``` kubectl get pods,svc,deployment,InferenceEndpointConfig,sagemakerendpointregistration -n ``` + Comprueba los registros de InitContainer si el paso de carga del modelo falla. ``` kubectl logs -c smart-loader -n ``` + Si la implementación falla y dice «no se encuentra en el espacio de nombres», compruebe que existe: ServiceAccount ``` kubectl get serviceaccount -n ``` + Si la implementación falla y dice «no está etiquetada como asignable por el usuario», pídale al administrador del clúster que añada la etiqueta requerida: ``` kubectl label serviceaccount sagemaker.amazonaws.com/user-assignable=true -n ``` + Si la implementación falla y dice «no debe hacer referencia a la cuenta de servicio del operador», cree una cuenta independiente ServiceAccount para su carga de trabajo. No puede utilizar la propia ServiceAccount del operador de HyperPod inferencia.