¿Puede vLLM ejecutar GGUF? Sí — vía el plugin, solo en GPU\nEl plugin, la sintaxis repo:quant, la bandera tokenizer que nunca es opcional — y la tabla de hardware que da la espalda a las CPU en la puerta.\n

■ space · el escritorio del intérprete

■ la respuesta primero

Sí — vLLM ejecuta GGUF, vía vllm-gguf-plugin, solo en GPU.

Sintaxis repo:quant_type + --tokenizer modelo base; CPU x86/Arm y GPU Intel: sin soporte.

una GPU, muchos usuarios concurrentes → vLLM; sin GPU o la mayor cobertura de cuantizados → llama.cpp.

Las palabras de la propia doc: «altamente experimental y suboptimizado» — una función de huella de memoria, no una jugada de throughput.

EN EL PUESTO

Di sobre qué corre el archivo. El puesto revisa su lista de invitados — la tabla oficial de compatibilidad de hardware para cuantizados de vLLM — y sella un veredicto.

SOPORTADO

Los kernels de GPU están detrás del camino GGUF — el plugin des-cuantiza los bloques directo al batching de servicio. Hagan fila en el mostrador.

ruta: uv pip install vllm-gguf-plugin → vllm serve repo:quant

fuente de la lista de invitados: la tabla oficial de compatibilidad de hardware de cuantizados de vLLM — el rechazo es arquitectónico: ningún kernel de CPU está detrás del camino GGUF, porque vLLM es un motor de servicio, no un juguete de portátil

EL MOSTRADOR

Dos pasos, y una bandera que nunca es decoración:

uv pip install vllm-gguf-plugin

# directly from Hugging Face, repo_id:quant_type format:
vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M \
  --tokenizer Qwen/Qwen3-0.6B

# or a local file you already downloaded:
vllm serve ./Qwen3-0.6B-Q4_K_M.gguf \
  --tokenizer Qwen/Qwen3-0.6B

arranque limpio. La doc recomienda el tokenizer del modelo base porque convertir tokenizers GGUF es «lento e inestable, especialmente para algunos modelos con vocabularios grandes». Una línea, sin arranques largos.

El soporte GGUF ya no viene en el core de vLLM — la doc nota que «ha migrado a OOT vllm-gguf-plugin »; un simple pip install vllm no alcanza.

Dos GPU, un modelo: --tensor-parallel-size 2 parte el mismo GGUF entre ambas tarjetas.

¿Vienes de Ollama en CPU? Eso es el motor, no el formato — llama.cpp corre GGUF en Raspberry Pis. vLLM no tiene kernel de CPU detrás del GGUF.

Un candado está encima del de hardware: el SO. vLLM en Windows significa WSL2 — saltárselo cuesta el impuesto del fork.

LA LISTA HONESTA DE LÍMITES

La misma página de la doc lleva una advertencia que vale citar verbatim: «El soporte de GGUF en vLLM es altamente experimental y suboptimizado.» En concreto:

La cobertura de cuantizados es más estrecha que llama.cpp. Los K-quants que la gente realmente descarga (Q4_K_M y amigos) funcionan; con los esquemas exóticos puede que no. llama.cpp sigue siendo la implementación de referencia del formato.
El soporte de arquitecturas va con retraso. Las familias nuevas de modelos aterrizan primero en llama.cpp; el plugin sigue después.
Sin carga perezosa estilo mmap. llama.cpp mapea el archivo en memoria; vLLM lo carga como cualquier otro checkpoint.
Es ante todo una función de huella de memoria. La doc enmarca GGUF como una forma de encoger el uso de VRAM, no una jugada de throughput.

Nada de esto está escondido — está todo en el primer párrafo de la página oficial de GGUF, lo que es más de lo que consigue la mayoría de las funciones experimentales.

MISMO ARCHIVO, INSTINTOS OPUESTOS

	vLLM + GGUF	llama.cpp
Inferencia en CPU	no	sí, de primera clase
Usuarios concurrentes	batching continuo, hecho para eso	limitado
Cobertura de cuantizados	subconjunto, experimental	la referencia
Instalación	vLLM + plugin	solo un binario
Mejor para	una GPU, muchos usuarios	un usuario, cualquier hardware

¿Servir a un equipo desde una GPU? vLLM + GGUF reutiliza los mismos archivos Q4_K_M que el resto del mundo local-LLM.

¿Un usuario, cualquier hardware? llama.cpp es un binario y el formato completo.

La regla de una línea: mismo archivo, instintos opuestos — llama.cpp trata el GGUF como el formato, vLLM lo trata como una opción.

■ sello honesto La doc, no mi banco de pruebas. Probado en: el registro público — vLLM + vllm-gguf-plugin · NVIDIA Volta → Hopper · GPU AMD. Registrado 2026-09-23, refrescado 2026-10-12. Todo lo de aquí viene de la documentación de vLLM y del registro del repo vllm-project/vllm (92.000+ estrellas desde febrero de 2023): la lista de invitados es su tabla de compatibilidad de hardware verbatim, las advertencias son sus palabras entre comillas, y ningún tokens-por-segundo se inventó para llenar los huecos.

fin del escritorio del intérprete · nada fetchado · todo local