El auge de potentes modelos de lenguaje grande (LLM) que se pueden consumir a través de llamadas API ha hecho que sea notablemente sencillo integrar capacidades de inteligencia artificial (IA) en las aplicaciones. Sin embargo, a pesar de esta conveniencia, un número significativo de empresas están optando por alojar sus propios modelos, aceptando la complejidad de la administración de la infraestructura, el costo de las GPU en la pila de servicio y el desafío de mantener los modelos actualizados. La decisión de autohospedarse a menudo se reduce a dos factores críticos que las API no pueden abordar. En primer lugar, está la soberanía de los datos: la necesidad de garantizar que la información confidencial no abandone la infraestructura, ya sea debido a requisitos regulatorios, preocupaciones competitivas u obligaciones contractuales con los clientes. En segundo lugar, está la personalización del modelo: la capacidad de ajustar modelos en conjuntos de datos propietarios para terminología y flujos de trabajo específicos de la industria o crear capacidades especializadas que las API de propósito general no pueden ofrecer.
Amazon SageMaker AI aborda la complejidad de la infraestructura del autohospedaje eliminando la carga operativa. A través de puntos finales administrados, SageMaker AI maneja el aprovisionamiento, el escalado y el monitoreo de los recursos de GPU, lo que permite a los equipos concentrarse en el rendimiento del modelo en lugar de en la administración de la infraestructura. El sistema proporciona contenedores optimizados para inferencia con marcos populares como vLLM preconfigurados para un rendimiento máximo y una latencia mínima. Por ejemplo, la imagen del contenedor Large Model Inference (LMI) v16 utiliza vLLM v0.10.2, que utiliza el motor V1 y viene con soporte para nuevas arquitecturas de modelos y nuevo hardware, como la generación Blackwell/SM100. Este enfoque administrado transforma lo que normalmente requiere experiencia en operaciones de aprendizaje automático (MLOps) en un proceso de implementación que requiere solo unas pocas líneas de código.
Lograr un rendimiento óptimo con estos contenedores administrados aún requiere una configuración cuidadosa. Parámetros como el grado de paralelismo del tensor, el tamaño del lote, la longitud máxima de la secuencia y los límites de simultaneidad pueden afectar drásticamente tanto la latencia como el rendimiento, y encontrar el equilibrio adecuado para su carga de trabajo específica y sus restricciones de costos es un proceso iterativo que puede llevar mucho tiempo.
LLM-Optimizer de BentoML aborda este desafío al permitir una evaluación comparativa sistemática en diferentes configuraciones de parámetros, reemplazando la prueba y error manual con un proceso de búsqueda automatizado. La herramienta le permite definir restricciones como objetivos de latencia específicos o requisitos de rendimiento, lo que facilita la identificación de configuraciones que cumplan con sus objetivos de nivel de servicio. Puede usar LLM-Optimizer para encontrar parámetros de servicio óptimos para vLLM localmente o en su entorno de desarrollo, aplicar esas mismas configuraciones directamente al punto final de SageMaker AI para una transición perfecta a producción. Esta publicación ilustra este proceso al encontrar una implementación óptima para un modelo Qwen-3-4B en un punto final de IA de Amazon SageMaker.
Esta publicación está escrita para ingenieros de aprendizaje automático, arquitectos de soluciones y creadores de sistemas en ejercicio que ya implementan modelos en Amazon SageMaker o una infraestructura similar. Asumimos estar familiarizados con las instancias de GPU, los puntos finales y el servicio de modelos, y nos centramos en la optimización práctica del rendimiento. Las explicaciones de las métricas de inferencia se incluyen no como un tutorial para principiantes, sino para desarrollar una intuición compartida. Para parámetros específicos como el tamaño del lote y el paralelismo tensorial, y cómo impactan directamente en el costo y la latencia en la producción.
Descripción general de la solución
El desglose paso a paso es el siguiente:
Definir restricciones en Jupyter Notebook: el proceso comienza dentro de SageMaker AI Studio, donde los usuarios abren un Jupyter Notebook para definir los objetivos de implementación y las restricciones del caso de uso. Estas restricciones pueden incluir latencia objetivo, rendimiento deseado y tokens de salida. Ejecute puntos de referencia teóricos y empíricos con BentoML LLM-Optimizer: LLM-Optimizer primero ejecuta una estimación teórica del rendimiento de la GPU para identificar configuraciones factibles para el hardware seleccionado (en este ejemplo, un ml.g6.12xlarge). Ejecuta pruebas comparativas utilizando el motor de servicio vLLM en múltiples combinaciones de parámetros, como paralelismo tensorial, tamaño de lote y longitud de secuencia, para medir empíricamente la latencia y el rendimiento. En función de estos puntos de referencia, el optimizador determina automáticamente la configuración de servicio más eficiente que satisfaga las restricciones proporcionadas. Genere e implemente una configuración optimizada en un punto final de SageMaker: una vez que se completa la evaluación comparativa, el optimizador devuelve un archivo de configuración JSON que contiene los valores de parámetros óptimos. Este JSON se pasa desde Jupyter Notebook a la configuración de SageMaker Endpoint, que implementa el LLM (en este ejemplo, el modelo Qwen/Qwen3-4B que utiliza el contenedor LMI basado en vLLM) en un extremo HTTP administrado utilizando los parámetros de tiempo de ejecución óptimos.
La siguiente figura es una descripción general del flujo de trabajo realizado a lo largo de la publicación.
Antes de pasar a los fundamentos teóricos de la optimización de la inferencia, vale la pena explicar por qué estos conceptos son importantes en el contexto de las implementaciones del mundo real. Cuando los equipos pasan de modelos basados en API a puntos finales autohospedados, heredan la responsabilidad de ajustar los parámetros de rendimiento que afectan directamente el costo y la experiencia del usuario. Comprender cómo interactúan la latencia y el rendimiento a través de la lente de la arquitectura de la GPU y la intensidad aritmética permite a los ingenieros realizar estas compensaciones deliberadamente en lugar de mediante prueba y error.
Breve descripción general del desempeño del LLM
Antes de profundizar en la aplicación práctica de este flujo de trabajo, cubrimos conceptos clave que generan intuición sobre por qué la optimización de la inferencia es fundamental para las aplicaciones impulsadas por LLM. El siguiente manual no es académico; es proporcionar el modelo mental necesario para interpretar los resultados de LLM-Optimizer y comprender por qué ciertas configuraciones producen mejores resultados.
Métricas clave de rendimiento
Rendimiento (solicitudes/segundo): cuántas solicitudes completa su sistema por segundo. Un mayor rendimiento significa atender a más usuarios simultáneamente.
Latencia (segundos): el tiempo total desde que llega una solicitud hasta que se devuelve la respuesta completa. Una latencia más baja significa una experiencia de usuario más rápida.
Intensidad aritmética: la relación entre el cálculo realizado y los datos movidos. Esto determina si su carga de trabajo es:
Limitado a la memoria: limitado por la rapidez con la que se pueden mover los datos (baja intensidad aritmética)
Limitado a la computación: limitado por la potencia de procesamiento bruta de la GPU (alta intensidad aritmética)
El modelo de línea de techo
El modelo de línea de techo visualiza el rendimiento trazando el rendimiento frente a la intensidad aritmética. Para obtener contenido más profundo sobre el modelo de línea de techo, visite la documentación de AWS Neuron Batching. El modelo revela si su aplicación tiene un cuello de botella por el ancho de banda de la memoria o la capacidad computacional. Para la inferencia LLM, este modelo ayuda a identificar si está limitado por:
Ancho de banda de memoria: transferencia de datos entre la memoria de la GPU y las unidades de cómputo (típica para tamaños de lotes pequeños) Capacidad de cómputo: operaciones de punto flotante sin formato (FLOPS) disponibles en la GPU (típica para tamaños de lotes grandes)
La compensación entre rendimiento y latencia
En la práctica, la optimización de la inferencia LLM sigue una compensación fundamental: a medida que aumenta el rendimiento, aumenta la latencia. Esto sucede porque:
Tamaños de lote más grandes → Más solicitudes procesadas juntas → Mayor rendimiento Más solicitudes simultáneas → Tiempos de espera de cola más largos → Mayor latencia Paralelismo tensorial → Distribuye el modelo entre GPU → Afecta ambas métricas de manera diferente
El desafío radica en encontrar la configuración óptima entre múltiples parámetros interdependientes:
Grado de paralelismo tensorial (cuántas GPU usar) Tamaño de lote (número máximo de tokens procesados juntos) Límites de concurrencia (número máximo de solicitudes simultáneas) Asignación de caché KV (memoria para estados de atención)
Cada parámetro afecta el rendimiento y la latencia de manera diferente, respetando al mismo tiempo las limitaciones del hardware, como la memoria de la GPU y el ancho de banda de procesamiento. Este problema de optimización multidimensional es precisamente la razón por la que LLM-Optimizer es valioso: explora sistemáticamente el espacio de configuración en lugar de depender del ensayo y error manual.
Para obtener una descripción general de LLM Inference en su conjunto, BentoML ha proporcionado recursos valiosos en su LLM Inference Handbook.
Aplicación práctica: encontrar una implementación óptima de Qwen3-4B en Amazon SageMaker AI
En las siguientes secciones, analizamos un ejemplo práctico de cómo identificar y aplicar configuraciones de servicio óptimas para la implementación de LLM. Específicamente, nosotros:
Implemente el modelo Qwen/Qwen3-4B usando vLLM en una instancia ml.g6.12xlarge (4 GPU NVIDIA L4, 24 GB de VRAM cada una). Defina restricciones de carga de trabajo realistas: Objetivo: 10 solicitudes por segundo (RPS) Longitud de entrada: 1024 tokens Longitud de salida: 512 tokens Explore múltiples combinaciones de parámetros de entrega: Grado de paralelismo tensorial (1, 2 o 4 GPU) Máximo de tokens por lotes (4K, 8K, 16K) Niveles de simultaneidad (32, 64, 128) Analice los resultados utilizando: Cálculos teóricos de memoria de GPU Datos de evaluación comparativa Compensaciones entre rendimiento y latencia
Al final, verá cómo el análisis teórico, la evaluación comparativa empírica y la implementación de puntos finales administrados se combinan para ofrecer una configuración de LLM lista para producción que equilibra la latencia, el rendimiento y el costo.
Requisitos previos
Los siguientes son los requisitos previos necesarios para ejecutar este ejemplo:
Acceso a SageMaker Studio. Esto hace que la implementación y la inferencia sean sencillas, o un entorno de desarrollo interactivo (IDE) como PyCharm o Visual Studio Code. Para comparar e implementar el modelo, verifique que los tipos de instancia recomendados sean accesibles, según el tamaño del modelo. Para verificar las cuotas de servicio necesarias, complete los siguientes pasos: En la consola Cuotas de servicio, en Servicios de AWS, seleccione Amazon SageMaker. Verifique una cuota suficiente para el tipo de instancia requerida para la "implementación de endpoints" (en la región correcta). Si es necesario, solicite un aumento de cuota o comuníquese con AWS para obtener asistencia.
El siguiente código detalla cómo instalar los paquetes necesarios:
Ejecute el optimizador LLM
Para comenzar, se deben definir restricciones de ejemplo en función del flujo de trabajo objetivo.
Restricciones de ejemplo:
Tokens de entrada: 1024 Tokens de salida: 512 E2E Latencia: <= 60 segundos Rendimiento: >= 5 RPS
Ejecute la estimación
El primer paso con llm-optimizer es ejecutar una estimación. La ejecución de una estimación analiza el modelo Qwen/Qwen3-4b en 4 GPU L4 y estima el rendimiento para una longitud de entrada de 1024 tokens y una salida de 512 tokens. Una vez ejecutado, los mejores valores teóricos de latencia y rendimiento se calculan matemáticamente y se devuelven. El análisis de la línea del techo devuelto identifica los cuellos de botella de las cargas de trabajo y se devuelven una serie de argumentos del servidor y del cliente, para su uso en el siguiente paso, ejecutando el punto de referencia real.
Debajo del capó, LLM-Optimizer realiza un análisis de la línea del techo para estimar el rendimiento del servicio LLM. Comienza obteniendo la arquitectura del modelo de HuggingFace para extraer parámetros como dimensiones ocultas, número de capas, cabezas de atención y parámetros totales. Utilizando estos detalles arquitectónicos, calcula los FLOP teóricos necesarios para las fases de precarga (procesamiento de tokens de entrada) y decodificación (generación de tokens de salida), teniendo en cuenta las operaciones de atención, las capas MLP y los patrones de acceso a la caché KV. Compara la intensidad aritmética (FLOP por byte movido) de cada fase con las características del hardware de la GPU, específicamente la relación entre la capacidad de cómputo (TFLOP) y el ancho de banda de la memoria (TB/s), para determinar si el prellenado y la decodificación están vinculados a la memoria o a la computación. A partir de este análisis, la herramienta estima TTFT (tiempo hasta el primer token), ITL (latencia entre tokens) y latencia de un extremo a otro en varios niveles de concurrencia. También calcula tres límites de concurrencia teóricos: capacidad de memoria caché KV, capacidad de cálculo previo al llenado y capacidad de rendimiento de decodificación. Finalmente, genera comandos de ajuste que barren diferentes configuraciones de paralelismo tensorial, tamaños de lote y niveles de concurrencia para realizar evaluaciones comparativas empíricas para validar las predicciones teóricas.
El siguiente código detalla cómo ejecutar una estimación inicial basada en las restricciones seleccionadas:
Resultado esperado:
Ejecute el punto de referencia
Con los resultados de la estimación en la mano, se puede tomar una decisión informada sobre qué parámetros utilizar para la evaluación comparativa en función de las restricciones definidas previamente. En el fondo, LLM-Optimizer pasa de la estimación teórica a la validación empírica mediante el lanzamiento de un ciclo de evaluación comparativa distribuido que evalúa el rendimiento del servicio en el mundo real en el hardware de destino. Para cada permutación de argumentos de servidor y cliente, la herramienta activa automáticamente una instancia de vLLM con el paralelismo tensor, el tamaño de lote y los límites de token especificados, luego impulsa la carga utilizando un generador de solicitudes sintético o basado en conjuntos de datos (por ejemplo, ShareGPT). Cada ejecución captura métricas de bajo nivel (tiempo hasta el primer token (TTFT), latencia entre tokens (ITL), latencia de extremo a extremo, tokens por segundo y utilización de memoria de GPU) en patrones de solicitudes simultáneas. Estas mediciones se agregan en una frontera de Pareto, lo que permite a LLM-Optimizer identificar las configuraciones que equilibran mejor la latencia y el rendimiento dentro de las limitaciones del usuario. En esencia, este paso fundamenta el análisis teórico anterior de la línea de techo en datos de rendimiento reales, lo que produce métricas reproducibles que informan directamente el ajuste de la implementación.
El siguiente código ejecuta el punto de referencia utilizando información de la estimación:
Esto envía las siguientes permutaciones al motor vLLM para realizar pruebas. Los siguientes son cálculos simples sobre las diferentes combinaciones de argumentos de cliente y servidor que ejecuta el punto de referencia:
3 tensor_parallel_size x 3 max_num_batched_tokens settings = 9 3 max_concurrency x 1 núm de indicaciones = 3 9 * 3 = 27 pruebas diferentes
Una vez completado, se generan tres artefactos:
Un archivo HTML que contiene un panel de Pareto de los resultados: una visualización interactiva que resalta las compensaciones entre latencia y rendimiento en las configuraciones probadas. Un archivo JSON que resume los resultados de las pruebas comparativas: esta salida compacta agrega las métricas de rendimiento clave (p. ej., latencia, rendimiento, utilización de GPU) para cada permutación de prueba y se utiliza para análisis programático o automatización posterior. Un archivo JSONL que contiene el registro completo de ejecuciones de pruebas comparativas individuales: cada línea representa una única configuración de prueba con metadatos detallados, lo que permite una inspección detallada, filtrado o trazado personalizado.
Ejemplo de salida de registro de referencia:
Al analizar los resultados de las pruebas comparativas, podemos utilizar las métricas de latencia p99 e2e y solicitar el rendimiento en varios niveles de concurrencia para tomar una decisión informada. Los resultados de la prueba comparativa revelaron que el paralelismo tensorial de 4 en las GPU disponibles superó consistentemente las configuraciones de paralelismo más bajas, siendo la configuración óptima tensor_parallel_size=4, max_num_batched_tokens=8192 y max_concurrency=128, logrando 7,51 solicitudes/segundo y 2270 tokens de entrada/segundo, una mejora de rendimiento de 2,7 veces con respecto a la línea base ingenua de una sola GPU (2,74 req/s). Si bien esta configuración proporcionó un rendimiento máximo, vino con una latencia p99 de extremo a extremo elevada de 61,4 segundos bajo carga pesada; para cargas de trabajo sensibles a la latencia, el punto óptimo fue tensor_parallel_size=4 con max_num_batched_tokens=4096 con una simultaneidad moderada (32), que mantuvo una latencia p99 inferior a 24 segundos y al mismo tiempo entregó 5,63 solicitudes/s, más del doble del rendimiento de referencia. Los datos demuestran que pasar de una configuración ingenua de una sola GPU a un paralelismo tensor de 4 vías optimizado con tamaños de lote ajustados puede generar ganancias de rendimiento sustanciales, y la elección de configuración específica depende de si la implementación prioriza el rendimiento máximo o las garantías de latencia.
Para visualizar los resultados, LLM-Optimizer proporciona una función conveniente para ver los resultados trazados en un panel de Pareto. El panel de Pareto se puede mostrar con la siguiente línea de código:
Con los artefactos correctos ahora a mano, se puede implementar el modelo con las configuraciones correctas.
Implementación en Amazon SageMaker AI
Una vez identificados los parámetros de servicio óptimos a través de LLM-Optimizer, el paso final es implementar el modelo optimizado en producción. Amazon SageMaker AI proporciona un entorno ideal para esta transición, abstrayendo la complejidad de la infraestructura del alojamiento de GPU distribuido y al mismo tiempo preservando un control detallado sobre los parámetros de inferencia. Al utilizar contenedores LMI, los desarrolladores pueden implementar marcos de código abierto como vLLM a escala, sin administrar las dependencias de CUDA, la programación de GPU o el equilibrio de carga manualmente.
Los contenedores LMI de SageMaker AI son imágenes Docker de alto rendimiento diseñadas específicamente para la inferencia LLM. Estos contenedores se integran de forma nativa con marcos como vLLM y TensorRT, y ofrecen soporte integrado para paralelismo de tensor de múltiples GPU, procesamiento por lotes continuo, generación de tokens de transmisión y otras optimizaciones críticas para el servicio de baja latencia. El contenedor LMI v16 utilizado en este ejemplo incluye vLLM v0.10.2 y el motor V1, lo que admite nuevas arquitecturas de modelo y mejora tanto la latencia como el rendimiento en comparación con versiones anteriores.
Ahora que se han determinado los mejores valores cuantitativos para la entrega de inferencia, esas configuraciones se pueden pasar directamente al contenedor como variables de entorno. (consulte aquí para obtener orientación detallada):
Cuando se aplican estas variables de entorno, SageMaker las inyecta automáticamente en la capa de configuración del tiempo de ejecución del contenedor, que inicializa el motor vLLM con los argumentos deseados. Durante el inicio, el contenedor descarga los pesos del modelo de Hugging Face, configura la topología de GPU para la ejecución paralela del tensor en los dispositivos disponibles (en este caso, en la instancia ml.g6.12xlarge) y registra el modelo con SageMaker Endpoint Runtime. Esto garantiza que el modelo se ejecute con la misma configuración optimizada validada por LLM-Optimizer, cerrando la brecha entre la experimentación y la implementación de producción.
El siguiente código demuestra cómo empaquetar e implementar el modelo para inferencia en tiempo real en SageMaker AI:
Una vez creada la construcción del modelo, puede crear y activar el punto final:
Después de la implementación, el punto final está listo para manejar el tráfico en vivo y se puede invocar directamente para realizar inferencias:
Estos fragmentos de código demuestran conceptualmente el flujo de implementación. Para obtener un ejemplo completo de un extremo a otro sobre la implementación de un contenedor LMI para inferencia en tiempo real en SageMaker AI, consulte este ejemplo.
Conclusión
El viaje desde la selección del modelo hasta la implementación de producción ya no necesita depender de prueba y error. Al combinar LLM-Optimizer de BentoML con Amazon SageMaker AI, las organizaciones ahora pueden pasar de la hipótesis a la implementación a través de un ciclo de optimización automatizado basado en datos. Este flujo de trabajo reemplaza el ajuste manual de parámetros con un proceso repetible que cuantifica las compensaciones de rendimiento, se alinea con los objetivos de rendimiento y latencia a nivel empresarial e implementa la mejor configuración directamente en un entorno de inferencia administrado. Este flujo de trabajo aborda un desafío crítico en la implementación de LLM de producción: sin una optimización sistemática, los equipos enfrentan un costoso juego de adivinanzas entre el aprovisionamiento excesivo de recursos de GPU y el riesgo de una experiencia de usuario degradada. Como se demuestra en este tutorial, las diferencias de rendimiento son sustanciales: las configuraciones mal configuradas pueden requerir entre 2 y 4 veces más GPU y, al mismo tiempo, ofrecer una latencia entre 2 y 3 veces mayor. Lo que tradicionalmente podría llevarle a un ingeniero días o semanas de pruebas manuales de prueba y error se convierte en unas pocas horas de evaluación comparativa automatizada. Al combinar la búsqueda de configuración inteligente de LLM-Optimizer con la infraestructura administrada de SageMaker AI, los equipos pueden tomar decisiones de implementación basadas en datos que impactan directamente tanto en los costos de la nube como en la satisfacción del usuario, centrando sus esfuerzos en crear experiencias de AI diferenciadas en lugar de ajustar los parámetros de inferencia.
La combinación de evaluación comparativa automatizada y la implementación administrada de modelos grandes representa un importante paso adelante para hacer que la IA empresarial sea accesible y económicamente eficiente. Al aprovechar LLM-Optimizer para la búsqueda de configuración inteligente y SageMaker AI para alojamiento escalable y tolerante a fallas, los equipos pueden concentrarse en crear experiencias de IA diferenciadas en lugar de administrar la infraestructura o ajustar las pilas de inferencia manualmente. En última instancia, la mejor configuración de LLM no es solo la que se ejecuta más rápido, sino la que cumple con objetivos específicos de latencia, rendimiento y costos en producción. Con LLM-Optimizer de BentoML y Amazon SageMaker AI, ese equilibrio puede descubrirse sistemáticamente, reproducirse de manera consistente e implementarse con confianza.
Recursos adicionales
Sobre los autores
Josh Longenecker es un arquitecto de soluciones especializado en IA/ML generativa en AWS y se asocia con clientes para diseñar e implementar soluciones de IA/ML de vanguardia. Es parte del TFC Neuron Data Science Expert y le apasiona superar los límites en el panorama de la IA en rápida evolución. Fuera del trabajo, lo encontrarás en el gimnasio, al aire libre o disfrutando del tiempo con su familia.
Mohammad Tahsin es arquitecto de soluciones especializado en IA/ML generativa en AWS, donde trabaja con clientes para diseñar, optimizar e implementar soluciones modernas de IA/ML. Le apasiona el aprendizaje continuo y mantenerse en la frontera de nuevas capacidades en el campo. En su tiempo libre, le gustan los videojuegos, el arte digital y la cocina.