Frameworks de serving de LLM: ¿cómo elijo un runtime?
Traducción automática
Este artículo se tradujo automáticamente a partir de la versión original en inglés.
Elige un runtime compatible con tu modelo concreto, su cuantización y tu hardware. Después, evalúa sus controles con el tráfico previsto. vLLM, SGLang, TensorRT-LLM y llama.cpp son candidatos útiles para distintos despliegues. El nombre de un framework no garantiza la menor latencia para tu carga de trabajo.
Comprueba la compatibilidad del modelo y del hardware antes de dedicar tiempo a las pruebas de carga.
Elige candidatos según el comportamiento necesario
| Requisito | Candidato que probar | Datos que recopilar |
|---|---|---|
| Serving general en GPU con múltiples peticiones | vLLM | Rendimiento que cumple el SLO y presión sobre la memoria |
| Muchos prefijos repetidos o generación estructurada | SGLang, junto con otro runtime compatible | Tasa de aciertos de caché y validez de la salida |
| Optimización específica para NVIDIA | TensorRT-LLM | Compatibilidad con modelos y precisiones, y latencia bajo carga |
| CPU, Apple silicon o ejecución portátil de GGUF | llama.cpp | Capacidad para alojar el modelo y velocidad en la máquina de destino |
| Configuración sencilla de modelos locales | Ollama | Si el flujo de trabajo local cumple la concurrencia necesaria |
Son comparaciones iniciales, no capacidades exclusivas. Por ejemplo, otros runtimes de serving también ofrecen caché de prefijos y structured output.
vLLM documenta el serving, la gestión de memoria, la planificación y las opciones de despliegue. SGLang incluye reutilización de prefijos y funciones de generación estructurada. La guía de inicio rápido de TensorRT-LLM utiliza una API de modelos de alto nivel y un comando de serving; comprueba los requisitos del backend y del modelo en vez de suponer que cada despliegue necesita un motor precompilado.
Hugging Face archivó el repositorio de TGI en marzo de 2026. Su README recomienda motores alternativos para los proyectos nuevos.
Compara con la misma distribución de peticiones
Utiliza el mismo artefacto del modelo, hardware, precisión, prompts y límites de salida. Prueba tanto prefijos únicos como repetidos si la caché importa. Registra el tiempo hasta el primer token, el tiempo por token de salida, los fallos de las peticiones y el rendimiento con tus umbrales de latencia.
Prueba también la cancelación, las entradas mal formadas, las peticiones largas concurrentes y el comportamiento tras un reinicio. Un runtime que supera una prueba breve con una única petición puede necesitar otros límites de admisión bajo carga.
La comparación de frameworks de serving de la LLM Engineering Guide relaciona la elección del runtime con las optimizaciones de inferencia.