O vLLM roda GGUF? Sim — só em GPU

Semana passada um leitor perguntou por que o arquivo GGUF dele falha no vLLM numa máquina sem GPU, enquanto o mesmo arquivo roda de boa no Ollama. Resposta curta, antes de tudo: sim, o vLLM roda GGUF — via um plugin oficial, só em GPU. O plugin se chama vllm-gguf-plugin, a sintaxe é repo:quant_type, e no momento em que você tenta em CPU, está fora da tabela de hardware suportado. Tudo abaixo vem da documentação do vLLM e do histórico do repositório vllm-project/vllm (mais de 92 mil estrelas desde fevereiro de 2023) — a doc, não minha bancada de teste.

Como servir um modelo GGUF com o vLLM?

Dois passos: instalar o plugin e apontar o vLLM para o modelo. O suporte a GGUF não mora mais no núcleo do vLLM — a doc avisa que ele “migrou para o vllm-gguf-plugin”, então um simples pip install vllm não basta:

uv pip install vllm-gguf-plugin

# Direto do Hugging Face, no formato repo_id:quant_type:
vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M 
  --tokenizer Qwen/Qwen3-0.6B

# Ou um arquivo local já baixado:
vllm serve ./Qwen3-0.6B-Q4_K_M.gguf 
  --tokenizer Qwen/Qwen3-0.6B

A flag --tokenizer não é enfeite. A doc oficial recomenda o tokenizer do modelo base porque a conversão do tokenizer GGUF é “demorada e instável, principalmente em modelos com vocabulário grande”. Pular isso é trocar uma flag de uma linha por uma inicialização longa e birmante.

Duas GPUs, um modelo: adicione --tensor-parallel-size 2 para dividir o mesmo GGUF entre as duas placas — o tensor parallelism funciona com GGUF como com qualquer outro formato.

Por que o vLLM recusa GGUF em CPU?

Essa é a parte que surpreende. A fama do GGUF é ser CPU primeiro — é o formato sobre o qual o llama.cpp construiu o nome, rodando modelos em laptops e Raspberry Pi. Dentro do vLLM a situação se inverte. A tabela oficial de compatibilidade de hardware marca o GGUF:

Hardware	GGUF no vLLM
NVIDIA Volta / Turing / Ampere / Ada / Hopper	suportado
GPU AMD	suportado
GPU Intel	não suportado
CPU x86	não suportado
CPU Arm	não suportado

Fonte: docs de quantização do vLLM. O motivo é arquitetural: o caminho GGUF do vLLM desquantiza blocos para kernels de GPU feitos para serving em lote. Não existe kernel CPU por trás, porque o vLLM é um motor de serving, não um brinquedo de laptop. Sem GPU na máquina, nenhuma flag salva — use llama.cpp.

O que quebra: a lista honesta de limites

A mesma página da doc carrega um aviso que merece citação literal: “o suporte a GGUF no vLLM é altamente experimental e pouco otimizado”. Na prática:

• A cobertura de quantização é mais estreita que a do llama.cpp. Os K-quants que todo mundo baixa (Q4_K_M e companhia) funcionam; esquemas exóticos nem sempre. O llama.cpp continua sendo a implementação de referência do formato.
• O suporte a arquiteturas vai atrás. Famílias novas de modelos chegam primeiro no llama.cpp; o plugin vem depois.
• Sem carregamento preguiçoso via mmap. O llama.cpp mapeia o arquivo em memória; o vLLM carrega como qualquer checkpoint.
• É antes de tudo um recurso de pegada de memória. A doc posiciona o GGUF como jeito de reduzir o uso de VRAM, não como aposta de throughput.

Nada disso está escondido. Está tudo no primeiro parágrafo da página oficial do GGUF — mais do que a maioria das funcionalidades experimentais oferece.

vLLM ou llama.cpp para GGUF: quem ganha?

Ferramentas diferentes que leem o mesmo arquivo:

	vLLM + GGUF	llama.cpp
Inferência em CPU	não	sim, de primeira classe
Usuários simultâneos	continuous batching, feito pra isso	limitado
Cobertura de quants	subconjunto, experimental	a referência
Instalação	vLLM + plugin	um binário
Ideal para	uma GPU, muitos usuários	um usuário, qualquer hardware

Se você serve um modelo para uma equipe a partir de uma única GPU, o vLLM + GGUF deixa você reutilizar os mesmos arquivos Q4_K_M que o resto do mundo local-LLM compartilha — com mais opções no nosso guia de quantização GGUF. Para a comparação completa dos engines, veja llama.cpp vs Ollama e como rodar modelos GGUF localmente.

A regra em uma linha: mesmo arquivo, instintos opostos — o llama.cpp trata GGUF como O formato, o vLLM como uma opção.