Proyectos de SageMaker Brindar a las organizaciones la capacidad de configurar y estandarizar fácilmente entornos de desarrollo para científicos de datos y sistemas CI / CD para ingenieros de MLOps. Con los proyectos de SageMaker, los ingenieros de MLOps o los administradores de la organización pueden definir plantillas que inicien el flujo de trabajo de ML con control de versión de origen, canalizaciones de ML automatizadas y un conjunto de código para comenzar a iterar rápidamente sobre los casos de uso de ML. Con Proyectos, la administración de dependencias, la administración de repositorios de código, la reproducibilidad de compilación, el uso compartido y la administración de artefactos se vuelven fáciles de configurar para las organizaciones. Los proyectos de SageMaker se aprovisionan utilizando Catálogo de servicios de AWS productos. Las organizaciones utilizan las plantillas de proyecto para aprovisionar proyectos para cada uno de sus usuarios.
Esta publicación describe cómo las plantillas de SageMaker Project se pueden personalizar para adaptarse al caso de uso de cualquier organización. Este repositorio de GitHub contiene ejemplos de plantillas personalizadas.
Proyectos de SageMaker
Cada organización tiene su propio conjunto de estándares y prácticas que brindan seguridad y gobernanza para su entorno de AWS. SageMaker proporciona un conjunto de plantillas propias para organizaciones que desean comenzar rápidamente con los flujos de trabajo de ML y CI / CD. En las plantillas se incluyen proyectos que utilizan servicios nativos de AWS para CI / CD, como Construcción de código AWS, AWS CodePipeliney Compromiso de código de AWS y también proyectos que utilizan herramientas de terceros como Jenkins y GitHub.
A menudo, las organizaciones necesitan un control estricto sobre los recursos de MLOps que se aprovisionan, restringen y administran; esto incluye: configurar roles / políticas de IAM, hacer cumplir las etiquetas de recursos, hacer cumplir el cifrado y desacoplar recursos en varias cuentas. Para brindar a las organizaciones la flexibilidad para hacer esto, los proyectos de SageMaker admiten plantillas personalizadas donde las organizaciones usan scripts de AWS CloudFormation para definir los recursos necesarios para un flujo de trabajo de AA. Estas plantillas personalizadas se crean como Catálogo de servicios de AWS productos y aprovisionados como plantillas de organización en la interfaz de usuario de SageMaker Studio. Aquí es donde los científicos de datos elegirían una plantilla y harían arrancar y preconfigurar su flujo de trabajo de ML. AWS Service Catalog es un servicio de AWS que permite a las organizaciones crear y administrar catálogos de productos aprobados para su uso en AWS. Estos productos se crean utilizando Formación de nubes plantillas.
Comprensión de las plantillas de SageMaker 1P
Para ayudar a nuestros clientes a comenzar con paradigmas comunes de implementación y construcción de modelos, SageMaker Projects ofrece un conjunto de Plantillas 1P. Las plantillas 1P generalmente se enfocan en la creación de recursos para la construcción y entrenamiento de modelos.
Para comprender los proyectos de SageMaker en detalle, es útil dividirlos en dos componentes: recursos de AWS y código semilla del proyecto.
Las siguientes secciones harán referencia "Plantilla de MLOps para la creación de modelos, la capacitación y la implementación.
Recursos de AWS
- Dos repositorios de CodeCommit llenos de código semilla. Un repositorio para la construcción de modelos y otro para la implementación de modelos.
- Dos etapas de CodeBuild que son activadas por CodePipeline:
- Creación de modelos: crea el código en el repositorio de creación de modelos.
- Implementación del modelo: esto crea el código en el repositorio de implementación.
- Dos tuberías de CodePipeline:
- Canalización de construcción de modelos
Esta canalización orquestará los pasos para la construcción de modelos. Esto incluye extraer el código más reciente de CodeCommit e iniciar la ejecución de CodeBuild. - Canalización de implementación de modelos
Esta canalización orquestará los pasos para la implementación del modelo. Esto incluye extraer código de CodeCommit, iniciar la ejecución de CodeBuild y cualquier otro paso definido en la plantilla del modelo.
- Canalización de construcción de modelos
- Tres puestos Puente de eventos de Amazon reglas-
- Activar la canalización de creación de modelos en función de los cambios en el repositorio "modelbuild"
- Activar la canalización de implementación del modelo en función de los cambios en el repositorio "modeldeploy"
- Activar la canalización de implementación del modelo cuando un modelo está "Aprobado" en el registro de modelos asociado con este proyecto. Cuando un punto final ya está implementado, cambiando el estado de "Aprobado" a "Rechazado", el punto final será derribado y el más reciente "Aprobado" antes de ese será implementado.
- An Amazon S3 cubo para el proyecto.
Código de semilla
Los repositorios de CodeCommit creados por la plantilla se rellenan previamente con código semilla para la construcción y la implementación de modelos.
- Código de semillas de construcción modelo
El código semilla para la canalización de construcción de modelos incluye una canalización SageMaker que preprocesa el Abulón conjunto de datos, entrena un modelo XGBoost, evalúa el rendimiento de un modelo mediante un paso de procesamiento y registra el modelo en un registro de modelo basado en el rendimiento del modelo. Un archivo llamadocodebuild-buildspec.yml
es parte del código semilla en el repositorio. Este archivo describe los pasos en CodeBuild para activar SageMaker Pipeline. Los científicos de datos realizarían cambios en el código de este repositorio para reflejar sus casos de uso. El código semilla se proporciona como punto de partida para ayudar a incorporar rápidamente nuevos casos de uso de ML. - Código semilla de implementación del modelo
El código semilla para la implementación del modelo incluye un paso de CodeBuild para encontrar el último modelo que ha sido aprobado en el registro de modelos y crear archivos de configuración para implementar las plantillas de CloudFormation. La plantilla de CloudFormation implementa el modelo en la etapa de "preparación" o "producción". Un archivo llamadobuildspec.yml
es parte de este repositorio, que describe los pasos que se tomaron para encontrar el último modelo para implementar y crear los scripts de CloudFormation para crear el SageMaker Endpoint. Los ingenieros de MLOps actualizarían el código en este repositorio para cambiar la lógica de implementación específica. Tenga en cuenta que los cambios en las etapas de implementación (preparación, producción, etc.) requerirían una plantilla personalizada, ya que es un cambio en CodePipeline, no en el código semilla.
Activar el oleoducto
Proceso de construcción de modelos
- Los científicos de datos actualizan la lógica de creación del modelo (es decir, preprocesamiento, scripts de entrenamiento, etc.) y envían una confirmación al Repositorio n. ° 1 en CodeCommit.
- Una regla de EventBridge desencadena la canalización de CodePipeline de modelbuild.
- En la canalización, un proyecto de CodeBuild crea una canalización de SageMaker (esto se puede reemplazar con cualquier código de entrenamiento de modelo) y ejecuta el flujo de trabajo, es decir, entrena un modelo y registra el modelo en el registro de modelos de SageMaker.
Luego, el modelo puede aprobarse o rechazarse en el registro. Las organizaciones deben determinar cómo se lleva a cabo la aprobación de su modelo y tener procesos que rijan qué usuarios pueden aprobar modelos en el registro.
Proceso de implementación del modelo
- Los ingenieros de MLOps actualizan el código de implementación del modelo y envían un compromiso al Repositorio n. ° 2 en CodeCommit, o se aprueba un modelo en el registro de modelos.
- Las reglas de EventBridge activan el modelo de implementación de la canalización de CodePipeline.
- El proyecto CodeBuild crea configuraciones para Staging y Production para ser utilizadas por las plantillas de CloudFormation.
- En la etapa "DeployStaging":
- Se crea un punto final de SageMaker en "Staging" a través de CloudFormation
- Un proyecto de CodeBuild prueba el punto final para un estado 'InService'.
- Si la prueba pasa, se activa un paso de aprobación manual.
- El usuario designado en la organización aprobará manualmente el modelo en CodePipeline
- En la etapa "DeployProd", el punto final de SageMaker se implementa en "Producción". Tenga en cuenta que para la plantilla 1P, ambos extremos se implementan en la misma región, con diferentes sufijos (Staging o Prod).
Si se rechaza el modelo, no se realiza ninguna acción.
Cuando se crea por primera vez este proyecto 1P SageMaker, cada canalización se ejecuta automáticamente cuando el código semilla se inserta en estos repositorios por primera vez. A medida que los usuarios actualicen posteriormente el código en cualquiera de los repositorios para cumplir con su caso de uso, las canalizaciones se volverán a activar. Algunos casos de uso encajan dentro del paradigma ofrecido por las plantillas de primera parte, lo que hace que estas plantillas sean una excelente manera de sembrar proyectos de aprendizaje automático. Por ejemplo, agregar pasos adicionales a la canalización, cambiar el conjunto de datos, actualizar las propiedades del punto final implementado, como agregar DataCaptureConfig, usar GitHub o Jenkins en lugar de las contrapartes nativas de AWS, se pueden lograr usando las plantillas de primera parte. Para obtener más información sobre las plantillas de proyectos propios de SageMaker, visite el Documentación de proyectos de SageMaker.
Por qué crear plantillas personalizadas
Es posible que las organizaciones deseen ampliar las plantillas de origen para admitir casos de uso más allá de la simple capacitación y el modelo de implementación. Plantillas de proyecto personalizadas son una forma para que las organizaciones creen un flujo de trabajo estándar para proyectos de aprendizaje automático. La organización puede crear varias plantillas y usar políticas de IAM para administrar el acceso a esas plantillas en SageMaker Studio, asegurándose de que cada uno de sus usuarios acceda a proyectos dedicados a sus casos de uso.
A continuación, se muestran algunos escenarios comunes en los que la organización necesitaría crear una plantilla de proyecto personalizada:
Guión | Oferta 1P actual | Caso de uso de la organización |
El uso de sistemas SVC no es compatible con las plantillas de terceros | Las plantillas de origen se utilizan en AWS CodeStar Connections para autenticarse con el repositorio, lo que limita las plantillas de origen a CodeCommit, GitHub, BitBucket y GitHub Enterprise. | Las organizaciones pueden tener sistemas de control de versiones distintos a los que ofrecen actualmente las plantillas 1P. |
Uso de una estrategia de cuentas múltiples para la implementación y el entrenamiento de modelos. | Actualmente, las plantillas 1P realizan el entrenamiento y la implementación de modelos, todo en la misma cuenta. | Es posible que las organizaciones deseen utilizar una estrategia de múltiples cuentas como una mejor práctica con cuentas de capacitación dedicadas y cuentas de ensayo / producción para implementaciones. |
Flujos de trabajo de aprobación personalizados para la implementación de modelos. | Las plantillas 1P tienen 2 pasos de aprobación: aprobación en el registro de modelos y aprobación manual en la canalización de CI / CD | Las organizaciones pueden tener varios pasos de aprobación que deben llevarse a cabo antes de que se pueda implementar un modelo. |
Varias etapas de implementación | Las plantillas 1P implementan modelos en 2 etapas: preparación y producción. Ambos extremos se implementan en la misma cuenta. | Las organizaciones pueden tener más de 2 etapas (puesta en escena, preproducción, producción) para la implementación. |
Varias ramas de código para experimentación | Las plantillas 1P asumen solo una rama en el repositorio utilizado | Las organizaciones pueden tener varios usuarios trabajando en el mismo repositorio donde cada uno de ellos trabaja en ramas individuales para experimentar con la rama principal que tiene la mejor versión del proceso de capacitación. |
Opciones de alojamiento personalizado | Las plantillas 1P solo utilizan puntos finales alojados en SageMaker | Las organizaciones pueden querer aprovechar una variedad de opciones de alojamiento de SageMaker: MME, Edge, etc. |
Canal único para múltiples casos de uso | Las plantillas 1P utilizan una única canalización de SageMaker que entrena un modelo | Es posible que las organizaciones deban utilizar un canal de SageMaker para entrenar y registrar varios modelos, cada uno con sus propios criterios de evaluación para limitar el número de canales a administrar. |
Pipelines de desarrollo y producción | Las plantillas 1P utilizaron una única canalización para el desarrollo y la producción. | Las organizaciones pueden querer probar primero su canalización en un entorno de desarrollo y luego usar un proceso de CI / CD para crear y ejecutar esa canalización en un entorno de producción. |
Usando código de semilla personalizado | Las plantillas 1P tienen un código semilla estándar para la construcción e implementación de modelos. | Es posible que las organizaciones deseen proporcionar a sus desarrolladores un conjunto de código semilla personalizado específico para los casos de uso en los que trabajan. |
Usar SageMaker Studio en una VPC | Las plantillas 1P usan SageMaker en modo Internet | Es posible que la organización esté usando SageMaker en modo solo vpc |
Prácticas recomendadas para diseñar una plantilla de proyecto personalizada
En esta sección, las organizaciones verán cómo pueden crear sus propias plantillas personalizadas y las consideraciones a tener en cuenta al diseñar sus propias plantillas.
Integración de control de versión fuente
Las plantillas 1P utilizan Conexiones de AWS CodeStar para administrar la autenticación entre el proyecto y el repositorio para que el código semilla se pueda enviar a él. Este método admitirá GitHub, GitHub Enterprise y BitBucket, además del repositorio nativo de AWS, CodeCommit. Si las organizaciones desean utilizar diferentes repositorios, se debe proporcionar un mecanismo de autenticación diferente en el Proyecto. Un enfoque recomendado es utilizar un AWS Lambda funcionar con Director de secretos de AWS para autenticarse con el repositorio y enviar el código semilla. Una vez que se ha enviado el código semilla, la autenticación con el repositorio en SageMaker Studio se realiza mediante el nombre de usuario y la contraseña del repositorio. El método con Lambda y Secrets Manger está diseñado para que el código semilla se envíe al repositorio cuando se crea el proyecto. Se pueden explorar estrategias alternativas para insertar código semilla en el repositorio en función del repositorio de la organización, el mecanismo de autenticación, el caso de uso, etc.
El código semilla enviado al repositorio debe personalizarse para admitir el caso de uso del proyecto.
Habilitación de CI / CD
En el Proyecto SageMaker, la herramienta CI / CD utilizada será responsable de desencadenar el proceso de implementación y entrenamiento del modelo. Cuando se cambia el estado de un modelo en el Registro de modelos, se emite una notificación EventBridge que puede alertar a la herramienta CI / CD para que comience la implementación. De manera similar, la herramienta CI / CD deberá utilizar la API de SageMaker para iniciar la ejecución de la canalización de SageMaker cuando se realice un cambio en el repositorio de creación de modelos. En la plantilla 1P que usa Jenkins para CI / CD, Jenkins Pipeline se activa al enviarlo al repositorio de SVC. La canalización de CI / CD utiliza los comandos de la AWS CLI para iniciar una canalización de SageMaker para el entrenamiento de modelos y ejecutar scripts de CloudFormation para implementar el modelo en el punto final.
En los casos en que las organizaciones deseen utilizar herramientas de CI / CD no compatibles con las plantillas 1P (Jenkins, CodePipeline), deben asegurarse de que su repositorio pueda activar su canalización de CI / CD y que los comandos de la CLI de AWS se puedan invocar para CI / CD. pipeline para que se puedan llamar los servicios de AWS relevantes (SageMaker Pipelines, CloudFormation, etc.). En la plantilla 1P, se usa una función Lambda para activar la canalización de Jenkins / CodePipeline cuando se aprueba un modelo en el Registro de modelos; lo mismo se puede hacer cuando se usan otras herramientas de CI / CD.
Identificar roles y actores de IAM
Los proyectos de SageMaker requieren un conjunto de roles de IAM que se dividen en dos categorías:
- Roles de lanzamiento - Se utiliza para definir una restricción en el catálogo de servicios que obliga a aprovisionar el producto subyacente mediante el LaunchRole designado. Esto permite a los desarrolladores crear proyectos utilizando plantillas sin necesidad de que su rol de ejecución de SageMaker tenga todas las políticas necesarias para iniciar el proyecto. Service Catalog asume el rol de restricción de lanzamiento al crear el proyecto para que los desarrolladores que lo utilicen puedan tener sus roles limitados a las políticas específicas que necesitan.
- Usar roles - Usado dentro de la plantilla por cada recurso para las operaciones requeridas. Para cada operación en la plantilla de producto, el rol de uso lo asume el respectivo principal de servicio de AWS.
Roles en las plantillas 1P:
Las plantillas 1P utilizan los siguientes roles administrados por AWS.
- Roles de lanzamiento - La política administrada por Amazon
AmazonSageMakerServiceCatalogProductsLaunchRoleis
utilizado por las plantillas de terceros para la restricción de lanzamiento del catálogo de servicios. - Usar rol –
AmazonSageMakerServiceCatalogProductsUseRole
es utilizado por los recursos creados en el 1st plantillas de fiesta.
Funciones en la plantilla personalizada:
En el caso de plantillas personalizadas, el LaunchRole
debe actualizarse para tener suficientes permisos para implementar todos los recursos en la plantilla de CloudFormation; y el UseRole
necesita tener todos los servicios asociados en su política de confianza para que los servicios puedan asumir el rol correcto. Los clientes pueden definir un UseRole
para cada servicio en lugar de una única función para todos los servicios.
Para comenzar, identifique las personas de usuario asociadas con la aplicación además del administrador, es decir, científicos de datos, equipo de MLOps, etc., y diseñe las políticas de IAM con el acceso de privilegios mínimo para cada usuario y servicios como SageMaker Studio y Service. Catalogar. Ver Acciones, recursos y claves de condición para los servicios de AWS para obtener una lista exhaustiva de las políticas de IAM. Un conjunto de muestra de funciones de IAM son:
- Administrador: Este usuario será responsable de crear la plantilla personalizada y de proporcionarla a los usuarios científicos de datos. Los privilegios necesarios incluyen acceso a Service Catalog, IAM (para crear roles y políticas) y SageMaker como mínimo.
- Datos Científico: Este usuario iniciará SageMaker Studio, creará cuadernos y desplegará plantillas de proyectos, ejecutará el procesamiento, capacitará trabajos, etc. la función de ejecución del portátil.
- Científico principal de datos: Este usuario será el encargado de aprobar el despliegue de recursos en Producción. Este rol normalmente podría ser el líder del equipo, quien validará los recursos de preparación, verificará que se cumplan todas las condiciones y aprobará los cambios en la producción. Este usuario adicional proporciona auditabilidad y agrega una verificación manual antes de realizar cambios en el entorno en vivo.
- Rol de ejecución del cuaderno de Studio: Este es el rol de servicio que asume el usuario de SageMaker Studio. Por lo general, incluye un permiso de nivel superior para SageMaker, con acceso adicional a Elastic Container Registry, depósitos de S3 específicos, CodePipeline, CodeBuild, registros de CloudWatch, etc., según sea necesario. Para poder enumerar y crear un proyecto de SageMaker, el rol también necesita acceso al catálogo de servicios.
- Función de inicio de plantilla personalizada y función de usuario: Roles asumidos por SageMaker al lanzar la plantilla de proyecto personalizada y para crear los recursos implementados por la plantilla. Agregar una distinción entre la función del portátil y la función de lanzamiento de la plantilla permite a los administradores limitar el permiso de los usuarios finales al mínimo que requieren para cada producto. Ver Restricciones de lanzamiento de AWS Service Catalog para obtener documentación detallada.
Estrategias de implementación de modelos
Según la opción de alojamiento adecuada para el caso de uso, los componentes de implementación de la plantilla deben actualizarse para usar esa opción de alojamiento. Por ej. Si el modelo debe implementarse en un punto final de varios modelos, los scripts de CloudFormation deben actualizarse para reflejar eso. O si se utiliza una canalización de inferencia en serie, la canalización de formación debe registrar un modelo de tubería en el Registro de modelos y se utiliza CloudFormation para implementar PipelineModel en un punto final de SageMaker. De manera similar, la plantilla se puede modificar para admitir la compilación de un modelo para la implementación de Edge usando SageMaker Neo.
Además de la opción de alojamiento, la estrategia de aprobación debe codificarse en la plantilla personalizada. En las plantillas de 1P descritas anteriormente, el proceso de aprobación para la implementación se realiza en 2 pasos. El primero es aprobar el modelo en el Registro de modelos, el segundo es un paso de aprobación manual en CodePipeline o Jenkins. Es posible que esto no encaje en los mecanismos de gobierno de aprobación establecidos para las organizaciones cuando implementan modelos. Un ejemplo de un mecanismo de aprobación diferente podría ser restringir los usuarios que pueden actualizar el estado del modelo del Registro de modelos para que solo los ingenieros de MLOps puedan actualizar el estado a "Aprobado". Una vez aprobada, la canalización de CI / CD puede tener un paso que verifique que se completen ciertas pruebas de integración junto con la aprobación manual de un administrador de cuenta antes de implementar el modelo. Estos flujos de trabajo de aprobación se pueden diseñar en la plantilla personalizada para definir una práctica estándar para la implementación en toda la organización.
Por último, las plantillas 1P operan dentro de una sola cuenta de acuerdo con las mejores prácticas de CI / CD, las organizaciones pueden tener una estrategia de múltiples cuentas con cuentas dedicadas de desarrollo, preparación y producción. En este caso, los clientes pueden hacer uso de Organizaciones de AWS para administrar esas cuentas y aprovechar las pilas de CloudFormation de cuentas cruzadas para manejar la implementación. El siguiente diagrama ilustra cómo se puede configurar.
Para obtener instrucciones detalladas sobre cómo configurar la implementación de múltiples cuentas utilizando Proyectos de SageMaker, consulte así blog.
Seguridad, cifrado y etiquetado
- Seguridad y cifrado
La seguridad es la máxima prioridad en AWS. Al crear flujos de trabajo de CI / CD para el aprendizaje automático, es imperativo comprender cómo proteger los datos confidenciales utilizados para la capacitación. AWS recomienda el cifrado de almacenamiento AWS KMS-CMK, es decir, buckets de S3, objetos, volumen de SageMaker Studio, etc. El control de versiones de S3 permite la recuperación de objetos en caso de una eliminación accidental, y el registro de S3 entrega registros de acceso para el bucket a un bucket de destino. Cree el dominio de SageMaker Studio en una VPC segura y utilice puntos de conexión de VPC para evitar la transferencia de datos a través de Internet público. Ver el whitepaper Cree una plataforma de aprendizaje automático empresarial segura en AWSpara conocer las mejores prácticas. - Etiquetado
Las etiquetas se utilizan para organizar los recursos por usuarios, equipos, proyectos o departamentos, y realizar un seguimiento de los costos de AWS en un nivel detallado. Además, las etiquetas se pueden usar para hacer cumplir las políticas de IAM, por ejemplo, aislar recursos entre dos equipos como se describe en la publicación del blog. Configuración de Amazon SageMaker Studio para equipos y grupos con aislamiento completo de recursos. Por tales motivos, puede aplicar el etiquetado en cualquier proyecto de SageMaker creado por el usuario a través de las políticas de IAM. A la función de científico de datos, agregue la siguiente declaración de política de IAM:
Cuando crea un producto personalizado, también puede utilizar el Biblioteca de TagOption para hacer cumplir los valores de cada etiqueta. Cuando se especifica una etiqueta para un proyecto, SageMaker propaga las etiquetas a todos sus recursos.
En un entorno organizativo, también puede crear varias plantillas de proyecto (productos de catálogo de servicios) para diferentes equipos y restringir el acceso de cada equipo a su plantilla correspondiente mediante políticas de IAM.
Aplicar estas mejores prácticas a un caso de uso
Esta tabla describe cómo las mejores prácticas descritas anteriormente pueden ayudar a resolver una variedad de casos de uso en los que se crean plantillas de proyectos personalizadas.
Guión | Solución propuesta |
El uso de sistemas SVC no es compatible con las plantillas de terceros | Las plantillas de origen se pueden personalizar para utilizar mecanismos de autenticación personalizados como funciones Lambda con AWS Secrets Manager o cualquier otra forma de acceder al código en el repositorio. Consulte Control de versión fuente en la sección Prácticas recomendadas para diseñar una plantilla de proyecto personalizada. Aquí Es un ejemplo de esto. |
Uso de una estrategia de cuentas múltiples para la implementación y el entrenamiento de modelos. | Utilice AWS Organization para administrar varias cuentas y pilas de CloudFormation de cuentas cruzadas para administrar la implementación de modelos en varias cuentas. Consulte "Estrategias de implementación de modelos" en la sección Prácticas recomendadas para diseñar una plantilla de proyecto personalizada. |
Flujos de trabajo de aprobación personalizados para la implementación de modelos. | Agregue pruebas unitarias, pruebas de integración, pasos adicionales de aprobación manual, múltiples pasos de evaluación en el proceso de capacitación, etc. para tener una estrategia sólida de aprobación de modelos. Consulte "Estrategias de implementación de modelos" en la sección Prácticas recomendadas para diseñar una plantilla de proyecto personalizada. |
Varias etapas de implementación | La canalización CI / CD (CodePipeline, Jenkins, etc.) debe actualizarse con todos los pasos de implementación necesarios. Un paso para cada etapa de implementación. Consulte "Estrategias de implementación de modelos" en la sección Prácticas recomendadas para diseñar una plantilla de proyecto personalizada. |
Varias ramas de código para experimentación | Se podría crear una plantilla personalizada en la que cada vez que se empuja una nueva rama en SVC para experimentación, se crea y ejecuta una tubería de SageMaker para esa rama. Aquí es un ejemplo de una plantilla personalizada para habilitar esta estrategia. |
Opciones de alojamiento personalizado | Se puede crear una plantilla personalizada que cambie los scripts de CloudFormation utilizados para la implementación de endpoints y las etapas de implementación se pueden actualizar para adaptarse a la opción de alojamiento seleccionada. Consulte "Estrategias de implementación de modelos" en la sección Prácticas recomendadas para diseñar una plantilla de proyecto personalizada. |
Canal único para múltiples casos de uso | El código semilla del proyecto se puede actualizar para que un solo SageMaker Pipeline entrene múltiples modelos que atienden múltiples casos de uso. Las instancias en las que esto es útil podrían ser cuando se usa un solo conjunto de datos para entrenar varios modelos, cada modelo se entrena en diferentes subconjuntos de datos. Esto evita la necesidad de administrar múltiples canalizaciones y reduce la cantidad de pasos necesarios para la preparación de datos. |
Pipelines de desarrollo y producción | Se puede crear una plantilla personalizada que cree una tubería de SageMaker utilizando una definición de tubería en un entorno de producción cuando la definición se envía al repositorio de SVC. De esta manera, los científicos de datos pueden probar su canalización en un entorno de desarrollo, iterar sobre él hasta que la canalización alcance el estado deseado, enviar el archivo de definición de canalización al repositorio, hacer que la canalización CI / CD cree una nueva canalización usando la misma definición en el entorno de producción e iniciar su ejecución. |
Usando código de semilla personalizado | Se puede crear una plantilla personalizada que extraiga el código de una ubicación que aloje el código semilla personalizado para el proyecto. Puede ser un depósito de S3 administrado por una organización o un repositorio del que extraer código. Consulte Control de versión fuente en la sección Prácticas recomendadas para diseñar una plantilla de proyecto personalizada. |
Usar SageMaker Studio en una VPC | Se puede crear una plantilla personalizada que tenga acceso al depósito con código semilla a través de un punto final de VPC. Sin esto, cuando se crea el proyecto, el código semilla no estará disponible para poblar el repositorio. Consulte Seguridad, cifrado y etiquetado en la sección Prácticas recomendadas para diseñar una plantilla de proyecto personalizada. |
Conclusión
Con las mejores prácticas y la guía descritas aquí, las organizaciones pueden habilitar a sus usuarios con flujos de trabajo estandarizados para ML que ayudan a impulsar la productividad y garantizar el cumplimiento de los estándares de la organización.
Visite este repositorio de GitHub para obtener un ejemplo sobre cómo crear su propia plantilla y contribuir al repositorio con sus propias plantillas personalizadas.
Acerca de los autores
kirit thadaka es un arquitecto de soluciones ML que trabaja en el equipo de SageMaker Service SA. Antes de unirse a AWS, Kirit pasó un tiempo trabajando en nuevas empresas de IA en etapa inicial, seguido de un tiempo en consultoría en varios roles en investigación de IA, MLOps y liderazgo técnico.
Durga Sury es un científico de datos en el equipo de suministro de energía en servicios profesionales. Antes de AWS, permitió que las agencias gubernamentales y sin fines de lucro obtengan conocimientos de sus datos para mejorar los resultados educativos. En AWS, se centra en el procesamiento del lenguaje natural y MLOps.
- '
- &
- 100
- 11
- 7
- 9
- de la máquina
- Mi Cuenta
- la columna Acción
- Adicionales
- Admin
- AI
- ai investigación
- Todos
- Amazon
- Amazon SageMaker
- abejas
- Aplicación
- Autenticación
- Confirmación de Viaje
- AWS
- MEJOR
- y las mejores prácticas
- Blog
- sucursales
- build
- Construir la
- cases
- el cambio
- CHARGE
- Cheques
- código
- Algunos
- compliance
- Conexiones
- consultoría
- Envase
- Precio
- Creamos
- Clientes
- datos
- científico de datos
- conjunto de datos
- entrega
- Diseño
- detalle
- Dev
- Developer
- desarrolladores
- Desarrollo
- Southern Implants
- Categoría Educación
- cifrado
- Punto final
- energía
- certificados
- Empresa
- Entorno
- etc.
- ejecución
- Nombre
- primer vez
- cómodo
- Flexibilidad
- función
- GitHub
- gobierno
- Gobierno
- maravillosa
- esta página
- hosting
- Cómo
- Como Hacer
- HTTPS
- AMI
- ICS
- Identifique
- información
- Insights
- integración
- Internet
- solo
- IT
- Empleo
- claves
- idioma
- más reciente
- lanzamiento
- Lead
- Liderazgo
- aprendizaje
- Nivel
- Apalancamiento
- Limitada
- Lista
- Ubicación
- máquina de aprendizaje
- Realizar
- Management
- ML
- MLOps
- modelo
- Lenguaje natural
- Procesamiento natural del lenguaje
- sin fines de lucro
- ordenadores portátiles
- .
- Ofertas
- habiertos
- Operaciones
- Optión
- Opciones
- organización
- para las fiestas.
- Otro
- paradigma
- Contraseña
- actuación
- plataforma
- políticas
- política
- Director de la escuela
- Producto
- Producción
- productividad
- Productos
- Mi Perfil
- proyecto
- proyecta
- público
- tracción
- razones
- recuperación
- la investigación
- Recurso
- Recursos
- reglas
- Ejecutar
- correr
- sabio
- los científicos
- EN LINEA
- dispersores
- seleccionado
- Servicios
- servicio
- set
- pólipo
- So
- Soluciones
- RESOLVER
- Etapa
- estándares de salud
- comienzo
- fundó
- Startups
- Estado
- Posicionamiento
- Estado
- STORAGE
- Estrategia
- SOPORTE
- Soportado
- Todas las funciones a su disposición
- Target
- Técnico
- test
- pruebas
- equipo
- seguir
- Formación
- trenes
- Confía en
- ui
- Actualizar
- usuarios
- control de versiones
- volumen
- Blackpaper
- QUIENES
- dentro de
- Actividades:
- flujo de trabajo
- funciona