Las organizaciones están adoptando cada vez más modelos de lenguaje de gran tamaño (LLMs) personalizados en Amazon SageMaker AI, utilizando marcos de implementación como SGLang, vLLM o TorchServe. Esta práctica permite un mayor control sobre sus implementaciones y optimiza costos, además de alinear las operaciones con requisitos de cumplimiento. Sin embargo, esta flexibilidad también ha traído consigo un desafío técnico crítico: la incompatibilidad en el formato de las respuestas con los agentes de Strands. Aunque estos marcos de implementación personalizados devuelven respuestas en formatos compatibles con OpenAI para asegurar un soporte amplio en el ecosistema, los agentes de Strands esperan respuestas que se alineen con el formato de la API de mensajes Bedrock. Esta discrepancia provoca fallos de análisis cuando la clase SageMakerAIModel intenta acceder a campos que no existen en el formato de OpenAI, generando errores como TypeError: ‘NoneType’ object is not subscriptable.
El desafío se vuelve aún más significativo debido a que el soporte para la API de mensajes no está garantizado para todos los modelos alojados en los endpoints en tiempo real de SageMaker AI. Si bien el motor de inferencia distribuido Amazon Bedrock Mantle ha soportado formatos de mensajería de OpenAI desde diciembre de 2024, la flexibilidad de SageMaker permite a los clientes alojar una variedad de modelos fundamentales, algunos de los cuales requieren formatos de entrada y salida esotéricos que no se ajustan a las APIs estándar. Esto crea una brecha entre la estructura de salida del marco de servicio y lo que Strands espera, impidiendo una integración fluida a pesar de que ambos sistemas sean funcionales técnicamente.
La solución a este problema radica en la implementación de parsers de modelos personalizados que extiendan la clase SageMakerAIModel y traduzcan el formato de respuesta del servidor del modelo al que Strands espera, permitiendo a las organizaciones aprovechar sus marcos de servicio preferidos sin sacrificar la compatibilidad con el SDK de Strands. Este proceso incluye la creación de un proveedor de modelo personalizado que maneje el formato de respuesta específico de los modelos como Llama 3.1, utilizando herramientas como el generador de contenedores de ml-container-creator de AWS, que facilita la creación de proyectos de despliegue en SageMaker.
Los pasos incluyen la instalación de las herramientas necesarias, la configuración del proyecto de despliegue y la construcción y despliegue del contenedor que albergará el modelo. También se destaca la importancia de una correcta implementación del método stream en el parser personalizado, crucial para que el agente interprete adecuadamente las respuestas. Una vez creado el proveedor, es posible inicializar agentes en Strands, que pueden interactuar con este modelo de manera efectiva.
Los autores subrayan que construir parsers de modelos personalizados para los agentes de Strands permite a los usuarios aprovechar diversas implementaciones de LLM en SageMaker, independientemente de su formato de respuesta, facilitando así una integración fluida y manteniendo la interfaz limpia del agente. Se enfatizan tres aprendizajes clave: ml-container-creator simplifica las implementaciones de SageMaker, los parsers personalizados ayudan a cerrar la brecha entre los formatos de respuesta del servidor y las expectativas de Strands, y el método stream es el punto de integración crucial para los proveedores personalizados.
vía: AWS machine learning blog