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 para validar la disponibilidad de su tipo de instancia.

Puede elegir entre los siguientes enfoques en función de sus requisitos de almacenamiento:

Requisitos previos

Antes de comenzar, compruebe que:

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 configuramodelSourceType: 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

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.

Implementación del modelo

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 conprefetchEnabled: true, el operador crea dos volúmenes automáticamente:

Añades un nvme-cache volumen personalizado que apunta al almacenamiento NVMe local del nodo y un volumen personalizado initContainer que:

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:

En tuInferenceEndpointConfig, defines:

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

Al hacer referencia a cuándo model-weightsprefetchEnabled: 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 denominadomodel-weights-copy, que es donde el trabajador espera encontrarlos.

Cuando prefetchEnabled: false solo hay un volumen (que lleva el nombre del suyomodelVolumeMount.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 delspec.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.

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ónInferenceEndpointConfig.

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 <your-service-account> \
  sagemaker.amazonaws.com/user-assignable=true \
  -n <namespace>

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 suInferenceEndpointConfig:

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:

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

Ámbito: funciones de IRSA (IAM)

Proteja la etiqueta asignable por el usuario

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.

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.

Cosas para recordar

Resolución de problemas

Use estos comandos de depuración si la implementación no funciona según lo previsto.