La cuantización de vLLM puede hacer que un modelo quepa en menos memoria GPU, pero no es un interruptor universal de velocidad. Un checkpoint más pequeño puede dejar más espacio para la caché KV y las solicitudes concurrentes. El rendimiento real depende del modelo, el formato de cuantización, la arquitectura de la GPU, el kernel, la longitud del prompt, la longitud de salida y el patrón de tráfico. La decisión sensata es elegir un formato compatible y luego medir una carga de trabajo representativa frente a una línea base sin cuantizar.
Esta guía de cuantización de vLLM le proporciona un proceso práctico de selección y pruebas. No afirma un resultado de benchmark para una GPU o un modelo que no hayamos probado.
Qué cambia la cuantización de vLLM
La cuantización almacena algunos valores del modelo en menos bits que un checkpoint típico de FP16 o BF16. El efecto de primer orden más claro es una menor memoria de pesos. Si la memoria de pesos es la razón por la que un modelo no cabe, un checkpoint cuantizado compatible puede permitir ejecutarlo en una GPU más pequeña o dejar más memoria disponible para solicitudes. Una GPU aún necesita memoria para las activaciones, la caché KV, la sobrecarga de tiempo de ejecución y cualquier worker paralelo. Por lo tanto, dividir el número de parámetros entre los bits por peso es solo un límite inferior aproximado, no una estimación de memoria apta para despliegue.
Hay dos rutas comunes para la cuantización de vLLM. Puede cargar un checkpoint que se cuantizó con antelación o utilizar una ruta de cuantización en línea compatible en el momento de carga. En ambos casos, revise la tarjeta del modelo y la matriz de compatibilidad actual de vLLM antes de elegir un formato. La documentación de cuantización de vLLM es la fuente de referencia para los métodos y la compatibilidad de hardware; advierte explícitamente que la matriz cambia a medida que evoluciona la compatibilidad.
Elija el formato según el checkpoint y la GPU
| Opción | Punto de partida práctico | Verifique antes del despliegue |
|---|---|---|
| AWQ | Un modelo distribuido como checkpoint AWQ y una GPU compatible | Calidad del modelo, selección de kernel, longitudes de prompt y latencia real. |
| GPTQ | Un modelo distribuido como checkpoint GPTQ | Configuración exacta del checkpoint, versión de vLLM, compatibilidad de GPU y regresión de calidad. |
| FP8 | Un checkpoint compatible y una GPU con ejecución FP8 compatible | Si la implementación de vLLM elegida admite su arquitectura y las capas del modelo. |
| GGUF | Un modelo ya distribuido en formato GGUF | La arquitectura específica y la compatibilidad de funciones de vLLM; no suponga que el comportamiento de Ollama se corresponde uno a uno. |
| BitsAndBytes o tensores comprimidos | Un checkpoint y una ruta de despliegue que los requieran explícitamente | Dependencias de tiempo de ejecución, comportamiento de carga, kernels compatibles y rendimiento. |
La matriz actual de vLLM incluye AWQ y GPTQ para Ampere, Ada y Hopper. Incluye FP8 mediante llm-compressor para Ada, Hopper y algunas rutas de GPU AMD, mientras que GGUF tiene un patrón de compatibilidad diferente. A100 es una GPU Ampere y H100 es una GPU Hopper, pero la compatibilidad es específica de cada método. No deduzca que cada variante de FP8, FP4 o Marlin funciona en todas las tarjetas de una familia. Consulte la fila exacta en la tabla de compatibilidad de hardware y los metadatos del propio checkpoint.
Si aún no ha seleccionado un modelo, compare dos checkpoints candidatos que utilicen el mismo modelo base y conjunto de evaluación. Comparar un modelo AWQ de una familia con un modelo sin cuantizar de otra confundirá la cuantización de vLLM con la calidad del modelo.
Un flujo de trabajo de despliegue que evita victorias engañosas
- Defina el objetivo del servicio. Registre el modelo, la longitud de contexto, las longitudes esperadas de entrada y salida, las solicitudes concurrentes, el objetivo de latencia p95 y las pruebas de calidad. Un chatbot, un clasificador por lotes y un agente de contexto largo tienen distintos cuellos de botella.
- Registre la línea base. Ejecute el checkpoint sin cuantizar en la misma GPU y versión de vLLM. Capture la memoria GPU máxima, el tiempo hasta el primer token, el rendimiento de tokens de salida, la latencia p50/p95 de extremo a extremo, los errores y la tasa de resultados aceptados.
- Elija un checkpoint cuantizado compatible. Lea su tarjeta de modelo y la matriz actual de métodos de vLLM. Fije la revisión del checkpoint, la versión de vLLM, la pila de CUDA/controladores y la SKU de hardware en el registro de pruebas.
- Comience con una prueba canario pequeña. Confirme que el modelo carga, sirve el endpoint y la configuración de generación requeridos, y produce resultados plausibles antes de aplicar tráfico.
- Realice benchmarks con varios niveles de concurrencia. Mida con las longitudes reales de prompt y respuesta. Una sola solicitud puede favorecer una configuración distinta a la del servicio sostenido.
- Ejecute la misma batería de calidad. La cuantización puede cambiar las salidas. Evalúe la corrección específica del dominio, el cumplimiento de formato, las negativas y los casos sensibles a la seguridad en lugar de confiar únicamente en la perplejidad.
- Calcule el coste por resultado aceptado. El precio por hora de la GPU dividido entre los tokens brutos por segundo no es suficiente si el modelo cuantizado falla más tareas o necesita reintentos.
Para un benchmark de servicio, vLLM documenta vllm bench serve y sus opciones de conjuntos de datos y endpoints en la guía oficial de la CLI de benchmarking. Utilice un conjunto de datos de tráfico que coincida con su aplicación; los prompts aleatorios sintéticos son útiles para comparaciones controladas, pero no deben presentarse como rendimiento de producción.
Planificación de memoria: los pesos son solo una partida
Una hoja de planificación sencilla separa cuatro categorías:
memoria total de GPU necesaria ≈ pesos del modelo + caché KV + sobrecarga de ejecución/activación + margen de seguridad
El formato de cuantización cambia principalmente el término de los pesos del modelo. La presión sobre la caché KV aumenta con la longitud del contexto y las secuencias activas. Un modelo que apenas cabe con una solicitud puede aun así fallar o ralentizarse considerablemente con tráfico simultáneo de contexto largo. En configuraciones con varias GPU, el paralelismo de tensores cambia tanto la memoria por tarjeta como la sobrecarga de comunicación; el checkpoint más pequeño posible no es automáticamente el despliegue más económico.
Antes de alquilar una GPU, pregúntate si necesitas alojar un modelo más grande, aumentar la concurrencia para un modelo más pequeño o reducir costes manteniendo la calidad. Esa respuesta determina qué compromiso entre memoria y rendimiento importa. Cloud GPU Compute de Flatkey enumera opciones de alquiler de GPU y pide a los clientes que confirmen la configuración, la región, la capacidad y las condiciones de alquiler. Considera la disponibilidad y el precio en tiempo real como datos del momento de la cotización, no como cifras fijas en un artículo de evaluación comparativa.
Evaluación comparativa justa de la cuantización de vLLM
Mantén fijos el modelo base, los parámetros de generación, el conjunto de prompts, el límite de salida, el estado de la caché y la GPU. Mide al menos tres cargas: una sola solicitud para la capacidad de respuesta, una concurrencia de producción representativa y un punto de estrés en el que la latencia comienza a degradarse. Informa tanto del rendimiento total como de la latencia p95. Si solo informas de tokens por segundo en saturación, los usuarios no podrán saber si las solicitudes interactivas siguen siendo aceptables.
Incluye la calidad del modelo en la tarjeta de puntuación:
| Medida | Por qué importa |
|---|---|
| Memoria GPU máxima | Muestra si la cuantización crea margen utilizable. |
| Tiempo hasta el primer token | Importa para las interfaces de streaming. |
| Tokens de salida por segundo | Muestra el rendimiento de generación, pero no la calidad de la tarea. |
| Latencia de extremo a extremo p95 | Revela el comportamiento de cola bajo carga. |
| Tasa de errores y OOM | Detecta una configuración que parece rápida solo cuando las solicitudes tienen éxito. |
| Tasa de resultados aceptados | Convierte la velocidad bruta en trabajo útil. |
La comparación clave para la cuantización de vLLM no es «cuantizado frente a no cuantizado» en abstracto. Es «este checkpoint y kernel en esta GPU, con esta carga de trabajo, frente a nuestra referencia». Publica las condiciones junto con cualquier resultado. Si tu prueba carece de una comprobación de calidad, llámala experimento solo de rendimiento.
Modos de fallo habituales
El modelo no se carga. Comprueba los metadatos del checkpoint, el método de cuantización, la versión de vLLM, la capacidad de la GPU y si el método admite cada capa utilizada por la arquitectura. La matriz de métodos de vLLM debe revisarse antes de cambiar a ciegas las opciones de comando.
El ahorro de memoria no mejoró la latencia. Una menor huella de pesos no garantiza un kernel más rápido. Prueba con tu concurrencia objetivo e inspecciona el tiempo hasta el primer token, la velocidad de decodificación y la utilización de la GPU. Un mayor margen para la caché KV puede ser el beneficio real.
Un checkpoint de pocos bits parece rápido, pero no supera las pruebas de calidad. Mantén un conjunto de aceptación de producción y mide el porcentaje de salidas que cumplen los criterios de tu aplicación. Debe establecerse un umbral de reversión antes del canario.
La evaluación comparativa no se puede reproducir. Registra las revisiones del modelo y del checkpoint, las versiones de vLLM y del controlador, la SKU de GPU, el conjunto de datos, la concurrencia, las longitudes de los prompts, las longitudes de salida y los argumentos del comando. Sin estos datos, una cifra de rendimiento es marketing en lugar de evidencia de ingeniería.
Cuándo usar Flatkey Cloud GPU
Si necesitas ejecutar tu propio servidor vLLM y comparar checkpoints cuantizados, elige la capacidad de GPU basándote en un requisito medido de memoria y concurrencia. Flatkey proporciona opciones de alquiler de GPU NVIDIA mediante Cloud GPU Compute. Confirma la SKU disponible, la región de despliegue, la capacidad, los precios y las condiciones del servicio antes de comprometerte. Una prueba de cuantización de vLLM debe realizarse en la configuración que realmente pretendes alquilar. Si necesitas una API de modelo administrada en lugar de operar vLLM, evalúa por separado la ruta de API y el directorio de modelos de Flatkey; se trata de un modelo operativo diferente.
Para decisiones de despliegue relacionadas, consulta nuestra guía de despliegue de vLLM, guía de inferencia de vLLM con varias GPU y comparación entre vLLM y Ollama.
Preguntas frecuentes
¿La cuantización de vLLM siempre hace que la inferencia sea más rápida?
No. Puede reducir la memoria de pesos, pero la latencia y el rendimiento dependen del checkpoint, el kernel, la GPU, las longitudes de secuencia y la carga de solicitudes. Compara una carga de trabajo real con una referencia.
¿Puedo usar AWQ en una A100 o H100?
La matriz de compatibilidad actual de vLLM enumera compatibilidad con AWQ para Ampere y Hopper, que incluyen A100 y H100. Comprueba el checkpoint exacto, la versión actual de vLLM y la arquitectura del modelo antes del despliegue.
¿FP8 es compatible con todas las GPU NVIDIA?
No. La compatibilidad varía según la implementación y la arquitectura de cuantización. La matriz actual distingue métodos como llm-compressor FP8 y Marlin; verifica la fila exacta para tu hardware.
¿Debo cuantizar antes o después de seleccionar una GPU?
Primero dimensiona la carga de trabajo y el objetivo de calidad; luego prueba los checkpoints candidatos en GPU compatibles. La elección del formato y del hardware debe evaluarse conjuntamente.
