Amazon Bedrock lanza periódicamente nuevas versiones del modelo básico (FM) con mejores capacidades, precisión y seguridad. Comprender el ciclo de vida del modelo es esencial para una planificación y gestión eficaces de las aplicaciones de IA creadas en Amazon Bedrock. Antes de migrar sus aplicaciones, puede probar estos modelos a través de la consola o API de Amazon Bedrock para evaluar su rendimiento y compatibilidad.
Esta publicación le muestra cómo administrar las transiciones FM en Amazon Bedrock, para que pueda asegurarse de que sus aplicaciones de IA permanezcan operativas a medida que evolucionan los modelos. Analizamos los tres estados del ciclo de vida, cómo planificar migraciones con la nueva función de acceso extendido y estrategias prácticas para realizar la transición de sus aplicaciones a modelos más nuevos sin interrupciones.
Descripción general del ciclo de vida del modelo de Amazon Bedrock
Un modelo ofrecido en Amazon Bedrock puede existir en uno de tres estados: activo, heredado o al final de su vida útil (EOL). Su estado actual es visible tanto en la consola de Amazon Bedrock como en las respuestas de la API. Por ejemplo, cuando realiza una llamada a GetFoundationModel o ListFoundationModels, el estado del modelo se mostrará en el campo modelLifecycle de la respuesta.
El siguiente diagrama ilustra los detalles de cada estado del modelo.
El detalle del estado es el siguiente:
ACTIVO: los modelos activos reciben mantenimiento continuo, actualizaciones y correcciones de errores de sus proveedores. Mientras un modelo está activo, puede usarlo para realizar inferencias a través de API como InvokeModel o Converse, personalizarlo (si es compatible) y solicitar aumentos de cuota a través de AWS Service Quotas. LEGADO: cuando un proveedor de modelos realiza la transición de un modelo al estado Legacy, Amazon Bedrock notificará a los clientes con al menos 6 meses de anticipación antes de la fecha EOL, brindando tiempo esencial para planificar y ejecutar una migración a versiones de modelo más nuevas o alternativas. Durante el período heredado, los clientes existentes pueden continuar usando el modelo, aunque es posible que los nuevos clientes no puedan acceder a él y los clientes existentes pueden perder el acceso a cuentas inactivas si no llaman al modelo durante un período de 15 días o más. Las organizaciones deben tener en cuenta que la creación de un nuevo rendimiento aprovisionado por unidades modelo ya no está disponible y las capacidades de personalización del modelo pueden enfrentar restricciones. Para los modelos con fechas de EOL posteriores al 1 de febrero de 2026, Amazon Bedrock introduce una fase adicional dentro del estado Legacy: Período de acceso extendido público: después de pasar un mínimo de 3 meses en el estado Legacy, el modelo ingresa a esta fase de acceso extendido. Los usuarios activos pueden continuar usándolo durante al menos otros 3 meses hasta el EOL. Durante el acceso extendido, no se espera que se aprueben las solicitudes de aumento de cuota a través de cuotas de servicio de AWS, por lo que debe planificar sus necesidades de capacidad antes de que un modelo entre en esta fase. Durante este período, los precios pueden ajustarse (consulte Precios durante el acceso extendido a continuación) y los clientes recibirán notificaciones sobre la fecha de transición y cualquier cambio. FINAL DE VIDA ÚTIL (EOL): cuando un modelo llega a su fecha EOL, se vuelve completamente inaccesible en todas las regiones de AWS, a menos que se indique específicamente en la lista EOL. Las solicitudes de API a los modelos EOL fallarán, lo que hará que no estén disponibles para la mayoría de los clientes a menos que existan acuerdos especiales entre el cliente y el proveedor para el acceso continuo. La transición al EOL requiere una acción proactiva del cliente: la migración no ocurre automáticamente. Las organizaciones deben actualizar el código de su aplicación para utilizar modelos alternativos antes de que llegue la fecha EOL. Cuando se alcanza el EOL, el modelo se vuelve completamente inaccesible para la mayoría de los clientes.
Después del lanzamiento de un modelo en Amazon Bedrock, permanece disponible durante al menos 12 meses después del lanzamiento y permanece en estado Legacy durante al menos 6 meses antes del EOL. Este cronograma ayuda a los clientes a planificar las migraciones sin prisas.
Precios durante el acceso extendido
Durante el período de acceso extendido, el proveedor del modelo puede ajustar el precio. Si se planean cambios de precios, se le notificará en el anuncio inicial del legado y antes de que los cambios posteriores entren en vigencia, por lo que no habrá aumentos de precios retroactivos sorpresa. Los clientes con acuerdos de precios privados existentes con proveedores modelo o aquellos que utilizan rendimiento aprovisionado continuarán operando bajo sus términos de precios actuales durante el período de acceso extendido. Esto garantiza que los clientes que hayan realizado acuerdos específicos con proveedores de modelos o hayan invertido en capacidad aprovisionada no se verán afectados inesperadamente por ningún cambio de precios.
Proceso de comunicación para cambios de estado del modelo
Los clientes recibirán una notificación 6 meses antes de la fecha EOL de un modelo cuando el proveedor del modelo haga la transición de un modelo al estado Legacy. Este enfoque de comunicación proactiva garantiza que los clientes tengan tiempo suficiente para planificar y ejecutar sus estrategias de migración antes de que un modelo llegue al final de su vida útil.
Las notificaciones incluyen detalles sobre el modelo que está obsoleto, fechas importantes, disponibilidad de acceso extendido y cuándo el modelo estará en EOL. AWS utiliza múltiples canales para garantizar que estas importantes comunicaciones lleguen a las personas adecuadas, incluidos:
Notificaciones por correo electrónico Alertas de AWS Health Dashboard en la consola de Amazon Bedrock Acceso programático a través de la API.
Para asegurarse de recibir estas notificaciones, verifique y configure las direcciones de correo electrónico de contacto de su cuenta. De forma predeterminada, las notificaciones se envían al correo electrónico del usuario raíz de su cuenta y a los contactos alternativos (operaciones, seguridad y facturación). Puede revisar y actualizar estos contactos en la página de su cuenta de AWS en la sección Contactos alternativos. Para agregar destinatarios o canales de entrega adicionales (como Slack o listas de distribución de correo electrónico), vaya a la consola de Notificaciones de usuario de AWS y elija Suscripciones de notificaciones administradas por AWS para administrar sus canales de entrega y contactos de cuenta. Si no recibe las notificaciones esperadas, verifique que sus direcciones de correo electrónico estén configuradas correctamente en estas configuraciones y que su proveedor de correo electrónico no filtre los correos electrónicos de notificación de health@aws.com.
Estrategias de migración y mejores prácticas
Al migrar a un modelo más nuevo, actualice el código de su aplicación y verifique que sus cuotas de servicio puedan manejar el volumen esperado. Planificar con anticipación le ayuda a realizar una transición sin problemas con una interrupción mínima.
Planificación de su cronograma de migración
Comience a planificar tan pronto como un modelo entre en estado heredado:
Fase de evaluación: evalúe su uso actual del modelo heredado, incluidas las aplicaciones que dependen de él, los patrones de solicitud típicos y los comportamientos o resultados específicos de los que dependen sus aplicaciones. Fase de investigación: investigue el modelo de reemplazo recomendado, entendiendo sus capacidades, diferencias con el modelo heredado, nuevas características que podrían mejorar sus aplicaciones y la disponibilidad regional del nuevo modelo. Revise los cambios y la documentación de la API. Fase de prueba: realice pruebas exhaustivas con el nuevo modelo y compare métricas de rendimiento entre modelos. Esto ayuda a identificar los ajustes necesarios en el código de su aplicación o a impulsar la ingeniería. Fase de migración: implemente cambios utilizando un enfoque de implementación por fases. Supervise el rendimiento del sistema durante la transición y mantenga la capacidad de reversión. Fase operativa: después de la migración, supervise continuamente sus aplicaciones y los comentarios de los usuarios para asegurarse de que funcionen según lo esperado con el nuevo modelo.
Pasos de migración técnica
Pruebe su migración a fondo:
Actualizar referencias de API: modifique el código de su aplicación para hacer referencia al nuevo ID del modelo. Por ejemplo, cambiar de anthropic.claude-3-5-sonnet-20240620-v1:0 a anthropic.claude-sonnet-4-5-20250929-v1:0 o inferencia global entre regiones global.anthropic.claude-sonnet-4-5-20250929-v1:0. Actualice las estructuras de avisos de acuerdo con las mejores prácticas del nuevo modelo. Para obtener orientación más detallada, consulte Migración de Claude Sonnet 3.x de Anthropic a Claude Sonnet 4.x en Amazon Bedrock. Solicite aumentos de cuota: antes de realizar la migración completa, asegúrese de tener cuotas suficientes para el nuevo modelo solicitando aumentos a través de la consola de cuotas de servicio de AWS, si es necesario. Ajuste las indicaciones: los modelos más nuevos pueden responder de manera diferente a las mismas indicaciones. Revise y refine sus indicaciones de acuerdo con las especificaciones del nuevo modelo. También puede utilizar herramientas como el optimizador de mensajes en Amazon Bedrock para ayudar a reescribir el mensaje para el modelo de destino. Actualizar el manejo de respuestas: si el nuevo modelo devuelve respuestas en un formato diferente o con características diferentes, actualice su lógica de análisis y procesamiento en consecuencia. Optimice el uso de tokens: aproveche las mejoras de eficiencia en los modelos más nuevos revisando y optimizando sus patrones de uso de tokens. Por ejemplo, los modelos que admiten el almacenamiento en caché rápido pueden reducir el costo y la latencia de sus invocaciones.
Estrategias de prueba
Las pruebas exhaustivas son fundamentales para una migración exitosa:
Comparación en paralelo: ejecute las mismas solicitudes en los modelos nuevos y heredados para comparar resultados e identificar cualquier diferencia que pueda afectar su aplicación. Para entornos de producción, considere realizar pruebas paralelas: enviar solicitudes duplicadas al nuevo modelo junto con el modelo existente sin afectar a los usuarios finales. Con este enfoque, puede evaluar el rendimiento del modelo, las tasas de latencia y errores, y otros factores operativos antes de la migración completa. Realice pruebas A/B para evaluar el impacto del usuario dirigiendo un porcentaje controlado del tráfico en vivo al nuevo modelo mientras monitorea métricas clave como la participación del usuario, las tasas de finalización de tareas, los puntajes de satisfacción y los KPI comerciales. Pruebas de rendimiento: mida los tiempos de respuesta, el uso de tokens y otras métricas de rendimiento para comprender cómo funciona el nuevo modelo en comparación con la versión anterior. Valide métricas de éxito específicas del negocio. Pruebas de regresión y casos extremos: asegúrese de que la funcionalidad existente siga funcionando como se esperaba con el nuevo modelo. Preste especial atención a entradas inusuales o complejas que puedan revelar diferencias en cómo los modelos manejan escenarios desafiantes.
Conclusión
La política de ciclo de vida del modelo en Amazon Bedrock le brinda etapas claras para administrar la evolución de FM. Los períodos de transición ofrecen opciones de acceso ampliadas y las disposiciones para modelos perfeccionados le ayudan a equilibrar la innovación con la estabilidad.
Manténgase informado sobre los estados de los modelos a través de AWS Health Dashboard, planifique las migraciones cuando los modelos entren en el estado heredado y pruebe las versiones más recientes a fondo. Estas pautas pueden ayudarlo a mantener la continuidad en sus aplicaciones de IA mientras utiliza capacidades mejoradas en modelos más nuevos.
Si tiene más preguntas o inquietudes, comuníquese con su equipo de AWS. Queremos ayudarlo y facilitarle una transición sin problemas mientras continúa aprovechando los últimos avances en tecnología FM.
Para obtener aprendizaje continuo y soporte para la implementación, explore la documentación oficial de AWS Bedrock para obtener guías completas y referencias de API. Además, visite el blog de aprendizaje automático de AWS y el centro de arquitectura de AWS para conocer estudios de casos del mundo real, prácticas recomendadas de migración y arquitecturas de referencia que pueden ayudarle a optimizar su estrategia de gestión del ciclo de vida de su modelo.
Sobre los autores
Saurabh Trikande es gerente senior de productos de Amazon Bedrock y Amazon SageMaker Inference. Le apasiona trabajar con clientes y socios, motivado por el objetivo de democratizar la IA. Se centra en los desafíos principales relacionados con la implementación de aplicaciones complejas de IA, la inferencia con modelos multiinquilino, la optimización de costos y hacer más accesible la implementación de modelos generativos de IA. En su tiempo libre, Saurabh disfruta hacer senderismo, aprender sobre tecnologías innovadoras, seguir TechCrunch y pasar tiempo con su familia.
Melanie Li, PhD, es arquitecta sénior de soluciones especializada en IA generativa en AWS con sede en Sydney, Australia, donde se centra en trabajar con los clientes para crear soluciones utilizando herramientas de IA/ML de última generación. Ha participado activamente en múltiples iniciativas de IA generativa en APJ, aprovechando el poder de los LLM. Antes de unirse a AWS, el Dr. Li ocupó puestos de ciencia de datos en las industrias financiera y minorista.
Derrick Choo es arquitecto senior de soluciones en AWS y acelera la transformación digital empresarial mediante la adopción de la nube, IA/ML y soluciones de IA generativa. Se especializa en desarrollo full-stack y ML, diseñando soluciones de extremo a extremo que abarcan interfaces frontend, aplicaciones de IoT, integraciones de datos y modelos de ML, con un enfoque particular en visión por computadora y sistemas multimodales.
Jared Dean es arquitecto principal de soluciones de IA/ML en AWS. Jared trabaja con clientes de todos los sectores para desarrollar aplicaciones de aprendizaje automático que mejoren la eficiencia. Está interesado en todo lo relacionado con la inteligencia artificial, la tecnología y la barbacoa.
Julia Bodia es directora principal de productos de Amazon Bedrock.
Pooja Rao es gerente senior de programas en AWS, lidera la gestión de cuotas y capacidad y respalda el desarrollo comercial para el equipo de Bedrock Go-To-Market. Fuera del trabajo, le gusta leer, viajar y pasar tiempo con su familia.