¿Puede vLLM ejecutar GGUF? Diez preguntas, respondidas primero

vLLM ejecuta GGUF mediante el vllm-gguf-plugin oficial, solo en GPU NVIDIA y AMD. La sintaxis de serve es repo:quant_type con un --tokenizer obligatorio apuntando al modelo original. En CPU, llama.cpp sigue siendo la respuesta.

Un GPU sirviendo a varias personas → vLLM + vllm-gguf-plugin. Una persona, cualquier hardware, la mayor variedad de quants → llama.cpp, un solo binario. Sin GPU o GPU Intel → llama.cpp, CPU de primera clase. Ambos motores leen el mismo GGUF; la diferencia es para qué optimizan — elige por hardware y número de gente, no por formato de archivo.

Sí — mediante el vllm-gguf-plugin oficial, en GPU NVIDIA y AMD. El plugin es el propio de vLLM, no un fork comunitario. Importan ambas mitades: el plugin es oficial, y la tabla de hardware se termina en GPU.

No. vLLM no tiene kernel de CPU detrás de su ruta GGUF — las CPU x86/Arm y las GPU Intel quedan fuera de la tabla de hardware soportado. Esta es la trampa detrás del reporte clásico: el mismo GGUF que da 404 en vLLM en un portátil corre bien en Ollama, porque el terreno natal del GGUF son los motores CPU-primero. El archivo nunca fue el problema.

Una línea — el repo, el tipo de quant, y el tokenizer:

vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M --tokenizer Qwen/Qwen3-0.6B

La sintaxis es repo:quant_type. La trampa es la bandera --tokenizer: nombra el repositorio del modelo original, nunca el repo GGUF — los archivos GGUF llevan pesos, y vLLM quiere el tokenizer real del modelo fuente.

Los K-quants que la gente realmente descarga — Q4_K_M y compañía — funcionan; los esquemas exóticos puede que no. llama.cpp sigue siendo la implementación de referencia del formato, así que los nuevos esquemas de quant y las nuevas arquitecturas de modelo aterrizan ahí primero y llegan al plugin después.

La doc responde esto por sí misma: "El soporte GGUF en vLLM es sumamente experimental y está sub-optimizado." Esa frase vive en el primer párrafo de la página oficial de GGUF — más honestidad de la que recibe la mayoría de funciones experimentales. Trata el plugin como una forma de reutilizar archivos que ya tienes, y deja abierta la salida hacia llama.cpp.

No — y la velocidad nunca fue el punto. llama.cpp mapea el archivo en memoria, así que un GGUF arranca perezosamente; vLLM lo carga como cualquier otro checkpoint. GGUF dentro de vLLM es una función de huella de memoria: la doc lo plantea como una forma de achicar el uso de VRAM, no una jugada de caudal. La ganancia de caudal es el batching — completamente en otra parte.

Tres causas reales: sintaxis de serve mal puesta (ruta plana en lugar de repo:quant_type), un --tokenizer ausente o equivocado, o hardware fuera de la tabla soportada. Una cuarta aparece más rara: un esquema de quant que el plugin no cubre. Recorre la tabla de abajo hacia lo alto — las primeras tres filas cubren la mayoría de los reportes.

Sí — nativamente; GGUF es el formato por defecto de Ollama, no un complemento. Baja un GGUF de Hugging Face, apunta Ollama hacia él, listo. Si el GPU queda ocioso mientras corre, ese es otro problema con su propia lista de verificación.

Es el único trabajo para el que existe vLLM: el batching continuo pone en cola las peticiones concurrentes contra un modelo cargado una vez. El plugin GGUF hereda esa maquinaria — la advertencia honesta es la propia línea "sub-optimizado" de la doc, así que si dimensionas un servidor compartido, mide tu quant en tu tarjeta antes de prometerle un número a alguien. Y una trampa más: un GGUF que sirve bien a un usuario todavía puede reventar la VRAM cuando el batching multiplica la caché KV por petición concurrente — los pesos bajaron; la caché crece con cada usuario. Baja la concurrencia, acorta el contexto, o baja el quant un peldaño.