Implementación de modelos cuantificados en Amazon SageMaker AI con Unsloth

Esta publicación fue coescrita con Daniel Han y Michael Han de Unsloth.

La implementación de grandes modelos básicos (FM) almacenados con su precisión original de punto flotante de 16 bits (BF16 o FP16) es costosa. Necesitan grandes instancias de GPU, lo que aumenta los costos de servicio y ralentiza los ciclos de iteración. La cuantificación soluciona este problema reduciendo la precisión numérica de los pesos de un modelo (por ejemplo, de 16 bits a 4 bits), lo que reduce significativamente el uso de memoria. El inconveniente de la cuantificación es que puede reducir la precisión de un modelo, que es donde la cuantificación dinámica se vuelve convincente. Cuando se realiza correctamente, la cuantificación dinámica puede reducir el uso de memoria manteniendo la precisión. Los ahorros en costos de instancias, almacenamiento y tiempo de inicio pueden aumentar rápidamente a escala.

En esta publicación, aprenderá cuatro patrones de implementación para tomar modelos que ya han sido cuantificados con Unsloth e implementarlos en la infraestructura de AWS. Los patrones utilizan Amazon Elastic Compute Cloud (Amazon EC2) para el acceso directo a la instancia, puntos finales de inferencia de IA de Amazon SageMaker para el servicio administrado y Amazon Elastic Kubernetes Service (Amazon EKS) o Amazon Elastic Container Service (Amazon ECS) cuando la inferencia debe encajar en un marco de contenedor existente. También aprenderá prácticas operativas para implementaciones de producción.

¿Qué es la cuantización dinámica de Unsloth?

Como explica Daniel Han, cofundador de Unsloth:

"El mayor problema de un modelo potente es que es muy grande y necesitas 1,5 TB para ejecutar este modelo. Usando algunos trucos puedes hacer que el modelo tenga un tamaño de 217 GB. Podrías pensar que debido a que es un 86% más pequeño, la precisión se degradará en un 86%, pero ese no es el caso, solo se degrada en un 14%. Esta metodología la llamamos cuantificación dinámica y mostramos muchos puntos de referencia en los que se puede reducir el espacio en disco del modelo, sin cuantificar todos los pesos hasta 4 bits, etc., pero algunas capas permanecen en 8 bits superiores”.

En términos prácticos, la cuantificación reduce la cantidad de bits utilizados para almacenar cada peso. Un modelo BF16 estándar utiliza 16 bits por parámetro. La cuantificación a 4 bits reduce el tamaño en un 75 por ciento, aunque los tamaños de archivos reales son ligeramente mayores debido a los metadatos de cuantificación. Para un modelo de 8 mil millones de parámetros, eso reduce la huella de memoria de aproximadamente 16 GB a aproximadamente 5 GB. Esa suele ser la diferencia entre necesitar una instancia de múltiples GPU y adaptarse cómodamente a una sola GPU.

Unsloth es una herramienta para ajustar y cuantificar modelos básicos. Unsloth Dynamic es una metodología de cuantificación que va más allá de la compresión uniforme. En lugar de aplicar la misma reducción de bits a cada capa, funciona en tres pasos:

Análisis capa por capa: Unsloth mide qué tan sensible es cada capa a la pérdida de precisión. Asignación dinámica de bits: las capas importantes (aquellas en las que la pérdida de precisión provoca una degradación significativa de la salida) se mantienen con mayor precisión (por ejemplo, 16 bits), mientras que las capas menos sensibles se cuantifican agresivamente (4 bits o menos). Ajuste de precisión: la cuantificación se ajusta para que la calidad de salida combinada permanezca lo más cercana posible a la original, manteniendo al mismo tiempo el uso de espacio en disco lo más pequeño posible.

El objetivo final de este proceso es hacer que las diferencias de precisión entre el modelo cuantificado y el modelo estándar sean lo más pequeñas posible, y al mismo tiempo comprimir el tamaño del modelo en una cantidad significativa. Con el paquete Unsloth de código abierto, puede ajustar, ejecutar, exportar e implementar modelos en un flujo de trabajo unificado.

Cuando implementa en AWS, la cuantificación es importante porque cambia tres cosas simultáneamente. Primero, la decisión de instancia: un modelo grande que de otro modo requeriría GPU más grandes podría resultar práctico en uno más pequeño, o incluso en una CPU. En segundo lugar, el perfil de inicio y almacenamiento: los archivos de modelos más pequeños se mueven, almacenan y promocionan entre entornos más rápidamente. En tercer lugar, la flexibilidad de implementación: puede elegir un archivo de modelo más pequeño para inferencias sensibles al costo, una exportación de mayor fidelidad para inferencias sensibles a la calidad o una representación fusionada para un servicio de GPU de mayor rendimiento. Esa flexibilidad es lo que hace que Unsloth sea útil en un entorno de AWS. Con él, puede adaptar el modelo a la ruta de servicio en lugar de forzar cada implementación a los mismos supuestos de hardware y tiempo de ejecución.

Qué formato de modelo usar

Un principio clave en el flujo de trabajo de implementación de Unsloth es que el artefacto de salida debe impulsar el diseño de entrega. La selección de infraestructura ocupa el segundo lugar. Primero, elija el artefacto y el tiempo de ejecución, luego coloque ese tiempo de ejecución en el servicio de AWS que coincida con su modelo operativo.

Unsloth admite múltiples tipos de resultados orientados a la implementación:

Archivos GGUF: GGUF es un formato de archivo único que empaqueta pesos de modelo, tokenizadores y metadatos juntos, haciéndolo autónomo y listo para cargar sin archivos adicionales. Úselos para tiempos de ejecución livianos como llama.cpp, Ollama y Unsloth. En AWS, esto se asigna a Amazon EC2 o a un contenedor personalizado de Amazon SageMaker AI. Se pueden crear pesos de tensores de seguridad fusionados (16 bits, 8 bits, FP8 de 4 bits, NVFP4) a través de Unsloth para motores de mayor rendimiento como vLLM y SGLang. En AWS, esto se asigna a contenedores de inferencia de modelos grandes (LMI) de IA de Amazon SageMaker, Amazon EKS o Amazon ECS.

Un mapa de despliegue práctico

La siguiente tabla asigna cada tipo de artefacto a su tiempo de ejecución más adecuado y al objetivo de AWS, para que pueda identificar rápidamente qué patrón de implementación coincide con sus requisitos.

Artefacto Tiempo de ejecución de mejor ajuste Destino de AWS de mejor ajuste Usar cuando GGUF llama.cpp / llama-server o Unsloth Amazon EC2 Ruta más rápida para pruebas prácticas con acceso directo a la instancia GGUF llama.cpp en un contenedor personalizado o Unsloth Amazon SageMaker AI Puntos finales administrados con escalado automático y tiempo de ejecución liviano Pesos combinados de 16 bits o 4 bits vLLM / SGLang / LMI backends Amazon SageMaker AI Alto rendimiento, procesamiento por lotes, escalado automático y producción Servicio de GPU Cualquier pila en contenedores Su tiempo de ejecución preferido Amazon EKS o Amazon ECS Inference debe integrarse en un marco de contenedores existente

Cada patrón de implementación en esta publicación sigue el mismo flujo de trabajo general:

Ajusta o descarga un modelo en Unsloth. Exporte el archivo de modelo que coincida con el tiempo de ejecución que desee. Valide el tiempo de ejecución localmente o en Amazon EC2. Promueva la misma combinación de archivo de modelo y tiempo de ejecución a una implementación administrada o nativa del entorno.

Esa secuenciación ayuda a evitar comportamientos inesperados más adelante, especialmente en relación con el uso de la memoria, el formateo rápido y el comportamiento de latencia.

Patrón 1: GGUF en Amazon EC2 con llama.cpp y Unsloth

Utilice este patrón para validar los niveles de cuantificación rápidamente con acceso directo a la instancia. Para muchos casos de uso, Amazon EC2 es un sólido punto de partida porque obtiene el máximo control con una mínima abstracción. Compare varios niveles de cuantificación, pruebe el formato de los mensajes, compare el comportamiento de la CPU con el de la GPU y comprenda la huella de memoria real antes de comprometerse con un diseño de terminal administrado.

Una exportación típica de Unsloth se ve así:

Esto produce un archivo GGUF listo para la inferencia local basada en llama.cpp. El repositorio complementario utiliza q4_k_xl para su punto final cuantificado. Los diferentes métodos de cuantificación controlan el equilibrio entre el tamaño del archivo y la fidelidad de salida: use q8_0 para una mayor fidelidad de salida con aproximadamente el doble del tamaño del archivo, o f16 para un GGUF de precisión total sin pérdida de cuantificación. Consulte la documentación de Unsloth GGUF para obtener la lista completa de métodos de cuantificación y sus características.

Una vez que tenga GGUF, un inicio mínimo del servidor llama requiere las siguientes configuraciones:

En ese punto, su aplicación puede comunicarse con el modelo a través de una interfaz compatible con OpenAI:

⚠️ Importante: Esta configuración es adecuada para pruebas aisladas. Para producción, restrinja el grupo de seguridad a bloques conocidos de enrutamiento entre dominios sin clases (CIDR), vincúlelo a una interfaz privada (por ejemplo, 127.0.0.1) y coloque el punto final detrás de una puerta de enlace API autenticada o un equilibrador de carga.

Este camino es atractivo por tres razones. Es transparente para depurar, se mantiene cerca del comportamiento del tiempo de ejecución ascendente y le brinda un lugar limpio para probar las opciones de cuantificación antes de agregar contratos de contenedores, políticas de escalado automático o gobernanza de puntos finales.

Amazon EC2 es también el lugar más directo para evaluar cuestiones prácticas de implementación:

Calidad de cuantificación: compare los resultados en todos los niveles de cuantificación (por ejemplo, q4_k_m frente a q8_0) con sus criterios de evaluación específicos. El impacto en la calidad varía según la arquitectura del modelo y la tarea. Requisitos de hardware: si el uso de memoria del modelo excede la RAM de la CPU disponible, necesitará una instancia respaldada por GPU. Verifique el uso máximo de memoria durante la inferencia, no solo la carga del modelo. Para obtener el mejor rendimiento, tenga suficiente RAM o VRAM para cargar todo el modelo en la memoria. Por ejemplo, si el modelo es de disco de 128 GB, busque más de 128 GB de RAM o VRAM disponibles. Compensaciones sobre la duración del contexto: las ventanas de contexto más largas aumentan tanto la latencia como el consumo de memoria. Pruebe con duraciones representativas de los mensajes para encontrar el equilibrio adecuado para su carga de trabajo. Validación de la plantilla de chat: verifique que el formato de solicitud estructurado (que asigna roles como "sistema" y "usuario" a las secuencias de tokens que espera el modelo) produzca un comportamiento consistente fuera del entorno de capacitación.

Para la evaluación, las herramientas internas, el trabajo de prueba de concepto y los primeros pilotos de producción, Amazon EC2 suele ser el punto de partida correcto.

Patrón 2: GGUF en Amazon SageMaker AI con un contenedor personalizado

Se recomienda Amazon EC2 para una iteración rápida, pero no ofrece un servicio de inferencia administrado listo para usar. Cuando desee un punto de enlace de producción con escalado automático, monitoreo, integración de AWS Identity and Access Management (IAM) y una superficie API estable, los puntos de enlace de inferencia de IA de Amazon SageMaker se convierten en la mejor opción.

Para implementaciones de GGUF, el diseño más práctico suele ser un contenedor de inferencia personalizado que empaqueta el archivo del modelo GGUF junto con llama.cpp u otro tiempo de ejecución liviano. Luego, el contenedor expone la interfaz de alojamiento de IA de Amazon SageMaker, lo que requiere que el contenedor escuche en el puerto 8080, implemente /ping para comprobaciones de estado e /invocaciones para solicitudes de inferencia.

El repositorio complementario de GitHub incluye un ejemplo funcional completo de este patrón. Implementa una comparación lado a lado del Qwen3-VL-8B-Instruct cuantificado dinámicamente de Unsloth (Q4_K_XL GGUF servido con llama.cpp en ml.g5.xlarge, aproximadamente $1.41/hr) contra la variante BF16 de precisión total (servido con vLLM en ml.g5.12xlarge, aproximadamente $7.09/hr). Precios a partir de junio de 2026; consulte la página de precios de Amazon SageMaker AI para conocer las tarifas actuales. El script del punto de entrada inicia llama-server en un puerto interno y utiliza nginx como proxy inverso para satisfacer la interfaz AI de Amazon SageMaker:

Luego, Nginx asigna /ping a la verificación de estado del servidor llama y /invocaciones al punto final de finalización del chat, lo que brinda a Amazon SageMaker AI una interfaz estándar y al mismo tiempo mantiene el tiempo de ejecución liviano:

# Ubicación del punto final de verificación de estado de SageMaker /ping { proxy_pass http://llama_backend/health; } # Punto final de inferencia de SageMaker -> ubicación de finalización del chat llama.cpp /invocaciones { proxy_pass http://llama_backend/v1/chat/completions; proxy_read_timeout 120s; }

Una arquitectura común podría verse así:

Almacene el archivo del modelo GGUF finalizado en Amazon Simple Storage Service (Amazon S3). Inicie el contenedor de Amazon SageMaker AI y coloque el modelo en /opt/ml/model. Inicie llama.cpp o Unsloth en el archivo del modelo local. Exponga una capa API delgada que traduce las solicitudes de IA de Amazon SageMaker en llamadas de inferencia locales.

El siguiente diagrama de arquitectura del repositorio complementario de GitHub muestra cómo el ejemplo implementa un punto final GGUF cuantificado (este patrón) y un punto final vLLM de precisión total (Patrón 3). El flujo funciona de la siguiente manera:

Figura: Diagrama de arquitectura de la implementación de muestra complementaria.

Terraform aprovisiona toda la infraestructura, incluidos los recursos de Amazon Elastic Container Registry (Amazon ECR), AWS CodeBuild y Amazon S3. AWS CodeBuild crea la imagen del contenedor personalizado y la envía a Amazon ECR. Amazon SageMaker AI crea dos puntos finales en tiempo real dentro de una nube privada virtual (VPC): uno para el modelo GGUF cuantificado (Patrón 2) y otro para el modelo de precisión total (Patrón 3). Ambos puntos finales extraen sus respectivos archivos de modelo de Amazon S3 al inicio. Una instancia de cuaderno de Amazon SageMaker proporciona acceso al cuaderno de comparación para ejecutar evaluaciones en ambos puntos finales.

Este patrón funciona bien porque mantiene el tiempo de ejecución liviano y al mismo tiempo permite que Amazon SageMaker AI maneje las preocupaciones operativas que importan en la producción, como el ciclo de vida de los terminales y el escalado automático. Para modelos más pequeños, esta ruta es especialmente atractiva en terminales respaldados por CPU. Para modelos cuantificados más grandes o requisitos de latencia más baja, puede mover el mismo diseño a puntos finales respaldados por GPU.

Una compensación es que llama.cpp es el motor de inferencia/implementación, pero no todo el sistema de servicio. En Amazon SageMaker AI, aún necesita un contenedor que se comporte como un punto final de Amazon SageMaker AI. Esa capa envolvente no requiere un esfuerzo de implementación significativo, pero es una parte importante del diseño de producción.

Patrón 3: Pesos combinados en Amazon SageMaker AI con motores de publicación optimizados para GPU

GGUF es excelente cuando las prioridades son el tamaño del archivo del modelo y la publicación liviana. No siempre es la elección correcta cuando se prioriza el rendimiento y la eficiencia de la GPU. Las ponderaciones fusionadas se vuelven más atractivas en esos escenarios.

Los pesos fusionados se refieren a un modelo guardado como un único conjunto unificado de pesos de tensores de seguridad. Esto suele ser el resultado de combinar un adaptador ajustado (como un adaptador de adaptación de bajo rango (LoRA)) con el modelo base, pero también se aplica a los modelos base guardados directamente en un formato listo para la implementación. Unsloth admite rutas de guardado para salidas fusionadas de 16 y 4 bits, junto con exportaciones solo de LoRA. Estos están más alineados con tiempos de ejecución como vLLM y SGLang, que se basan en patrones de servicio de GPU de producción, como procesamiento por lotes, alto rendimiento de tokens y escalado de múltiples GPU.

Una exportación representativa se ve así:

La ruta de servicio es:

En AWS, los contenedores LMI disponibles para Amazon SageMaker AI son especialmente relevantes aquí. Para el punto final de precisión total en el ejemplo complementario, el contenedor LMI para Amazon SageMaker AI se configura completamente a través de variables de entorno en el recurso del modelo Terraform:

No se necesita ningún contenedor personalizado. El contenedor LMI descarga el modelo de Hugging Face al inicio y lo entrega a través de vLLM con paralelismo tensorial en 4 GPU A10G. El paralelismo tensorial divide un modelo en varias GPU, de modo que cada GPU maneja una parte del cálculo en paralelo. Si la carga de trabajo exige procesamiento por lotes continuo, mayor simultaneidad o espacios de modelo más grandes, una ruta de estilo vLLM suele ser una mejor opción de producción que un tiempo de ejecución GGUF liviano. Las prioridades de implementación pasan de adaptarse al modelo de forma económica a servirlo de manera eficiente a escala, y este patrón aborda ese cambio directamente.

Una regla general útil: utilice GGUF y llama.cpp cuando desee la ruta de implementación más ligera y el tiempo de ejecución se ajuste a la carga de trabajo. Utilice pesos combinados (el modelo base combinado y la salida del adaptador) con vLLM, SGLang o un backend LMI cuando el rendimiento, el procesamiento por lotes, la simultaneidad o la topología de hardware se conviertan en las limitaciones dominantes.

Patrón 4: utilice Amazon EKS o Amazon ECS cuando la inferencia deba ajustarse al entorno que ya ejecuta

Si desea que la inferencia se parezca a cualquier otro servicio que opere, ejecutándose dentro de la misma pila de orquestación, red y observabilidad, este patrón encaja. Si ya está estandarizado en Kubernetes o Amazon ECS, empaquete el tiempo de ejecución de Unsloth en ese entorno en lugar de introducir una superficie de servicio separada solo para los modelos.

Este patrón es particularmente útil cuando:

La inferencia debe coexistir con otros servicios de aplicaciones. Ya cuenta con herramientas sólidas en torno a Amazon EKS o Amazon ECS. Ya ha estandarizado la implementación, las redes, la observabilidad y la seguridad en la capa de infraestructura.

En esos entornos, la pregunta práctica deja de ser "¿Debería utilizar Amazon SageMaker AI?" y más "¿Qué exportación de Unsloth se adapta mejor al tiempo de ejecución que quiero contener?"

Para los equipos que necesitan una infraestructura de clúster administrada para la inferencia y el entrenamiento de modelos a gran escala, también vale la pena evaluar Amazon SageMaker HyperPod, aunque esta publicación se centra en patrones de implementación solo de inferencia.

Prácticas operativas que más importan

Independientemente de la ruta de AWS que elija, algunas prácticas tienen un efecto enorme sobre si la implementación funciona bien en producción. Para obtener orientación detallada sobre cada tema, consulte la documentación de alojamiento de IA de Amazon SageMaker.

Mantenga el formato rápido consistente de principio a fin

El formato de aviso inconsistente es una de las formas más comunes de diagnosticar erróneamente un buen modelo como una mala implementación. Cuando un modelo exportado se comporta peor fuera de Unsloth, el problema no suele ser el método de cuantificación. Por lo general, se trata de una falta de coincidencia en la plantilla de chat, el manejo del final de la secuencia (EOS) (la lógica que le dice al modelo cuándo dejar de generar tokens) o la estructura rápida entre el entrenamiento y la inferencia. Si el modelo es coherente en un entorno e inestable en otro, verifique el formato del mensaje antes de investigar el archivo del modelo. Consulte la documentación de las plantillas de chat de Unsloth para obtener detalles sobre la configuración de la plantilla en el momento de la exportación.

Compare la forma de implementación completa, no solo el nivel de cuantificación

Un punto de referencia de cuantificación por sí solo no es suficiente. El comportamiento real depende de la duración del contexto, la simultaneidad, la combinación de solicitudes, el comportamiento de la transmisión, la ruta de inicio y el tiempo de ejecución mismo. Es posible que un archivo de modelo más pequeño no produzca el mejor resultado de producción si la aplicación requiere contextos más largos o tráfico más intenso. Del mismo modo, es posible que un archivo de modelo más preciso no valga la pena el costo adicional de memoria si la carga de trabajo es sensible a la latencia y tiene un costo limitado. Evalúe el panorama completo de la implementación: tamaño del archivo, comportamiento del tiempo de ejecución, ajuste del hardware y patrón de solicitud. Amazon SageMaker AI también proporciona recomendaciones de inferencia que pueden ayudarle a identificar tipos y configuraciones de instancias óptimas.

Utilice la entrega estable de artefactos

Después de finalizar el modelo, promuévalo a través de una ruta de almacenamiento predecible. En AWS, eso generalmente significa almacenar el archivo del modelo elegido en Amazon S3 y cargarlo desde allí en lugar de depender de descargas de tiempo de ejecución de fuentes externas durante el inicio. Esto hace que la inicialización de los terminales sea más predecible y simplifica la gobernanza, especialmente en entornos de red restringidos.

Monitorear el servicio, no solo el modelo

El rendimiento de la producción no se trata sólo de la calidad simbólica. También se trata del tiempo de inicio, la latencia de cola, la simultaneidad, el comportamiento de escalado y las características de carga del modelo. Los puntos finales administrados hacen que esto sea más visible porque puede observar las métricas de invocación, el comportamiento de concurrencia y las señales de escalamiento directamente a través de Amazon CloudWatch. En implementaciones autoadministradas de Amazon EC2, exponga y realice un seguimiento de las señales equivalentes.

Validar el contrato del contenedor con antelación

Si está implementando en Amazon SageMaker AI con un contenedor personalizado, valide el contenedor localmente antes de implementarlo. Asegúrese de que /ping y /invocations se comporten correctamente, que el modelo se cargue desde la ruta esperada y que el tiempo de ejecución sobreviva tamaños de solicitud realistas. Ese paso detecta muchos problemas de integración antes de que se conviertan en sesiones de depuración de endpoints. Consulte la guía de contenedores personalizados de Amazon SageMaker para conocer las especificaciones completas de la interfaz.

Diseño para la seguridad y las redes desde el principio

El servicio de modelos a menudo se convierte en parte de un entorno de aplicaciones más amplio, lo que significa que las redes, el alcance de las funciones de IAM, el acceso a Internet, el cifrado de AWS Key Management Service (AWS KMS) y la ubicación de VPC son tan importantes como el rendimiento del tiempo de ejecución. Tome estas decisiones desde el principio en lugar de adaptarlas después de que el terminal ya esté en uso. Habilite AWS CloudTrail para el registro de auditoría a nivel de API en todos los recursos implementados. Consulte la documentación de seguridad de la infraestructura de Amazon SageMaker para obtener orientación sobre la configuración y el cifrado de VPC.

Conclusión

La mejor manera de implementar modelos cuantificados de Unsloth en AWS es comenzar con el archivo de modelo que realmente desea ofrecer. GGUF le brinda una ruta ligera hacia llama.cpp y llama-server, lo que convierte a Amazon EC2 en el lugar más directo para validar un modelo y a Amazon SageMaker AI en el siguiente paso práctico cuando necesita puntos finales administrados. Los pesos combinados le brindan una ruta más natural hacia los contenedores vLLM, SGLang y LMI cuando el rendimiento y la escala importan más que un tiempo de ejecución mínimo.

Aunque esta publicación utiliza Qwen3-VL-8B-Instruct como ejemplo, Unsloth admite una amplia gama de arquitecturas de modelos de código abierto, incluidas Llama, Qwen, Mistral, Gemma y otras. Los patrones de implementación se aplican independientemente del modelo que elija.

Esa es la verdadera ventaja de combinar Unsloth con AWS. Puede realizar ajustes según el costo, el rendimiento o el entorno sin cambiar el flujo de trabajo del modelo principal. Comience con el archivo del modelo, alinéelo con el tiempo de ejecución y luego elija el servicio de AWS que coincida con la forma en que desea operar la inferencia en producción.

Próximos pasos

Para ver estos patrones en acción, clone el repositorio complementario de GitHub y ejecute terraform apply para implementar un punto final GGUF cuantificado y un punto final vLLM de precisión total en Amazon SageMaker AI. Terraform aprovisiona la infraestructura y una instancia de cuaderno de Amazon SageMaker con el repositorio previamente clonado, para que pueda comenzar a ejecutar el cuaderno de comparación inmediatamente.

La computadora portátil envía indicaciones de imágenes idénticas a ambos puntos finales, lo que demuestra la inferencia multimodal de visión y lenguaje con Qwen3-VL y produce comparaciones en paralelo de calidad de salida, latencia, rendimiento y costo. También incluye un marco de evaluación comparativa que evalúa ambos modelos frente a un conjunto de datos estructurados utilizando métricas de calidad objetivas (coincidencia exacta, BLEU, ROUGE-L). Con este marco, puede cuantificar la degradación a partir de la cuantificación en lugar de depender de un juicio subjetivo. Para la selección automatizada de instancias y el ajuste de la configuración más allá de lo que mide el portátil, Amazon SageMaker AI también proporciona recomendaciones de inferencia que pueden identificar configuraciones de implementación óptimas para su carga de trabajo. Para evitar cargos continuos cuando haya terminado, ejecute terraform destroy para eliminar los recursos aprovisionados.

Para saber más:

Sobre los autores