mrsaynothing.dev
vLLM y GGUF FAQ: diez preguntas de búsqueda, respondidas
Diez preguntas reales de búsqueda sobre vLLM y GGUF — soporte de CPU, sintaxis de serve, cobertura de quants, la trampa del tokenizer — respondidas desde la doc y nuestros posts probados.
la lista de verificación de cinco minutos
Los modos de fallo tienen una tabla — recórrela de arriba abajo.
| Síntoma | Causa | Arreglo |
|---|---|---|
404 o "modelo no encontrado" al servir |
GGUF pasado como ruta plana — vLLM quiere repo:quant_type |
Usa la forma repo:quant_type (siguiente sección) |
| Error de tokenizer al cargar | --tokenizer ausente o apuntando al repo GGUF |
Apúntalo al repositorio del modelo base original |
| Corre en Ollama/llama.cpp, se niega en vLLM | Mismo archivo, motor distinto — la ruta GGUF de vLLM es solo-GPU | Las máquinas CPU se quedan en llama.cpp |
| Esquema de quant rechazado al cargar | Quant exótico fuera de la cobertura del plugin | Baja a Q4_K_M o compañeros — ver la guía de cuantización |
Can vLLM run GGUF ?
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 termina en GPU. El recorrido completo de serve vive en Can vLLM Run GGUF? Yes — on GPU Only.
¿Soporta vLLM GGUF en CPU?
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.
¿Cómo se sirve un modelo GGUF con vLLM?
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.
verificación: sírvelo, luego nvidia-smi — el proceso vLLM debe estar sosteniendo VRAM, no RAM del sistema.
¿Qué quants GGUF soporta vLLM?
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. Antes de descargar nada, calcula el tamaño con la guía de cuantización GGUF.
¿Está el soporte GGUF de vLLM listo para producción?
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.
¿Carga vLLM GGUF más rápido que 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 está en otra parte enteramente: el batching — y ese costo de arranque se repite por cada reinicio, a diferencia del kv-cache que paga renta mientras el modelo sigue cargado.
¿vLLM o llama.cpp para GGUF — quién gana?
Mismo archivo, instintos opuestos: llama.cpp trata GGUF como el formato, vLLM lo trata como una opción. Un GPU sirviendo a varias personas → vLLM más el plugin. Una persona, cualquier hardware, la mayor variedad de quants → llama.cpp, un solo binario. La tabla de frente a frente — CPU, concurrencia, cobertura de quants, configuración — está en el análisis profundo.
¿Por qué falla mi archivo GGUF en vLLM?
Tres causas reales, todas en la tabla de arriba: 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 arriba abajo — las primeras tres filas cubren la mayoría de los reportes.
¿Ejecuta Ollama GGUF?
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: Ollama Not Using GPU? Fix It.
¿Pueden varios usuarios compartir un servidor vLLM GGUF?
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. Todo lo que este cluster asume — el formato, los motores, el hardware — está mapeado en el hub run-LLMs-locally.
Una trampa más: carga, y luego revienta de memoria bajo carga
Un GGUF que sirve bien a un usuario todavía puede reventar la VRAM cuando el batching multiplica el kv-cache 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 — la lógica de dimensionamiento es la misma que en cualquier despliegue de vLLM.
Las diez respuestas de arriba se remontan a dos fuentes: la documentación oficial de vLLM y nuestros propios logs de serve. Lo que nadie ha publicado todavía es un banco — Q4_K_M por el plugin contra el mismo archivo en llama.cpp en una tarjeta, tok/s lado a lado. Cuando ese banco corra, aterriza primero en el hub local-LLM primero.