A quantização no vLLM pode fazer um modelo caber em menos memória de GPU, mas não é um botão universal de velocidade. Um checkpoint menor pode deixar mais espaço para o cache KV e solicitações simultâneas. O throughput real depende do modelo, do formato de quantização, da arquitetura da GPU, do kernel, do comprimento do prompt, do comprimento da saída e do padrão de tráfego. A decisão sensata é escolher um formato compatível e, em seguida, medir uma carga de trabalho representativa em relação a uma linha de base não quantizada.
Este guia de quantização no vLLM oferece um processo prático de seleção e teste. Ele não afirma um resultado de benchmark para uma GPU ou modelo que não testamos.
O que a quantização no vLLM altera
A quantização armazena alguns valores do modelo em menos bits do que um checkpoint típico FP16 ou BF16. O efeito de primeira ordem mais claro é a redução da memória dos pesos. Se a memória dos pesos for o motivo pelo qual um modelo não cabe, um checkpoint quantizado compatível poderá permitir que ele seja executado em uma GPU menor ou com mais memória disponível para solicitações. Uma GPU ainda precisa de memória para ativações, o cache KV, sobrecarga de runtime e quaisquer workers paralelos. Portanto, dividir a contagem de parâmetros pelos bits por peso é apenas um limite inferior aproximado, não uma estimativa de memória utilizável para implantação.
Há dois caminhos comuns para a quantização no vLLM. Você pode carregar um checkpoint que foi quantizado antecipadamente ou usar um caminho de quantização online compatível no momento do carregamento. Em ambos os casos, inspecione o cartão do modelo e a matriz de compatibilidade atual do vLLM antes de escolher um formato. A documentação de quantização do vLLM é a fonte de referência para métodos e suporte de hardware; ela alerta explicitamente que a matriz muda à medida que o suporte evolui.
Escolha o formato com base no checkpoint e na GPU
| Opção | Ponto de partida prático | Verifique antes da implantação |
|---|---|---|
| AWQ | Um modelo distribuído como checkpoint AWQ e uma GPU compatível | Qualidade do modelo, seleção de kernel, comprimentos de prompt e latência real. |
| GPTQ | Um modelo distribuído como checkpoint GPTQ | Configuração exata do checkpoint, versão do vLLM, suporte da GPU e regressão de qualidade. |
| FP8 | Um checkpoint compatível e uma GPU com execução FP8 compatível | Se a implementação escolhida do vLLM é compatível com sua arquitetura e as camadas do modelo. |
| GGUF | Um modelo já distribuído no formato GGUF | A arquitetura específica e o suporte a recursos do vLLM; não presuma que o comportamento do Ollama seja mapeado um a um. |
| BitsAndBytes ou tensores comprimidos | Um checkpoint e um caminho de implantação que os exijam explicitamente | Dependências de runtime, comportamento de carregamento, kernels compatíveis e throughput. |
A matriz atual do vLLM lista AWQ e GPTQ para Ampere, Ada e Hopper. Ela lista FP8 via llm-compressor para Ada, Hopper e alguns caminhos de GPU AMD, enquanto GGUF tem um padrão de suporte diferente. A100 é uma GPU Ampere e H100 é uma GPU Hopper, mas o suporte é específico de cada método. Não infira que todas as variantes de FP8, FP4 ou Marlin funcionam em todas as placas de uma família. Verifique a linha exata na tabela de compatibilidade de hardware e os próprios metadados do checkpoint.
Se você ainda não selecionou um modelo, compare dois checkpoints candidatos que usem o mesmo modelo base e conjunto de avaliação. Comparar um modelo AWQ de uma família com um modelo não quantizado de outra confundirá a quantização no vLLM com a qualidade do modelo.
Um fluxo de trabalho de implantação que evita ganhos ilusórios
- Defina a meta do serviço. Registre o modelo, o comprimento de contexto, os comprimentos esperados de entrada e saída, as solicitações simultâneas, a meta de latência p95 e os testes de qualidade. Um chatbot, um classificador em lote e um agente de contexto longo têm gargalos diferentes.
- Registre a linha de base. Execute o checkpoint não quantizado na mesma GPU e versão do vLLM. Capture o pico de memória da GPU, o tempo até o primeiro token, o throughput de tokens de saída, a latência p50/p95 de ponta a ponta, os erros e a taxa de resultados aceitos.
- Escolha um checkpoint quantizado compatível. Leia seu cartão de modelo e a matriz de métodos atual do vLLM. Fixe a revisão do checkpoint, a versão do vLLM, a pilha CUDA/driver e o SKU do hardware no registro de teste.
- Comece com um pequeno canário. Confirme que o modelo carrega, atende ao endpoint e às configurações de geração exigidos e produz saídas plausíveis antes de aplicar tráfego.
- Faça benchmark em vários níveis de simultaneidade. Meça com os comprimentos reais de prompt e resposta. Uma única solicitação pode favorecer uma configuração diferente daquela favorecida pelo serviço sustentado.
- Execute o mesmo conjunto de testes de qualidade. A quantização pode alterar as saídas. Avalie a correção específica do domínio, a conformidade de formato, as recusas e casos sensíveis à segurança, em vez de confiar apenas na perplexidade.
- Calcule o custo por resultado aceito. O preço por hora da GPU dividido por tokens brutos por segundo não é suficiente se o modelo quantizado falhar em mais tarefas ou precisar de novas tentativas.
Para um benchmark de serving, o vLLM documenta vllm bench serve e suas opções de conjuntos de dados e endpoints no guia oficial da CLI de benchmark. Use um conjunto de dados de tráfego que corresponda à sua aplicação; prompts aleatórios sintéticos são úteis para comparações controladas, mas não devem ser apresentados como desempenho de produção.
Planejamento de memória: os pesos são apenas um item
Uma planilha simples de planejamento separa quatro categorias:
total GPU memory needed ≈ model weights + KV cache + runtime/activation overhead + safety headroom
O formato de quantização altera principalmente o termo dos pesos do modelo. A pressão do cache KV aumenta com o comprimento do contexto e as sequências ativas. Um modelo que mal cabe para uma solicitação ainda pode falhar ou ficar significativamente mais lento sob tráfego simultâneo com contexto longo. Em configurações com várias GPUs, o paralelismo de tensor altera tanto a memória por placa quanto a sobrecarga de comunicação; o menor checkpoint possível não é automaticamente a implantação mais econômica.
Antes de alugar uma GPU, pergunte se você precisa acomodar um modelo maior, aumentar a simultaneidade para um modelo menor ou reduzir custos preservando a qualidade. Essa resposta determina qual compromisso entre memória e throughput importa. O Cloud GPU Compute da Flatkey lista opções de aluguel de GPU e solicita que os clientes confirmem a configuração, a região, a capacidade e os termos de locação. Trate a disponibilidade e o preço em tempo real como informações do momento da cotação, não como números fixos em um artigo de benchmark.
Avaliando a quantização do vLLM de forma justa
Mantenha fixos o modelo base, os parâmetros de geração, o conjunto de prompts, o limite de saída, o estado do cache e a GPU. Meça pelo menos três cargas: uma única solicitação para capacidade de resposta, uma simultaneidade representativa de produção e um ponto de estresse em que a latência começa a se degradar. Informe tanto o throughput total quanto a latência p95. Se você informar apenas tokens por segundo na saturação, os usuários não poderão saber se as solicitações interativas continuam aceitáveis.
Inclua a qualidade do modelo no quadro de avaliação:
| Métrica | Por que é importante |
|---|---|
| Memória máxima da GPU | Mostra se a quantização cria margem utilizável. |
| Tempo até o primeiro token | Importa para interfaces de streaming. |
| Tokens de saída por segundo | Mostra o throughput de geração, mas não a qualidade da tarefa. |
| Latência de ponta a ponta p95 | Revela o comportamento de cauda sob carga. |
| Taxa de erros e OOM | Detecta uma configuração que parece rápida apenas quando as solicitações têm êxito. |
| Taxa de resultados aceitos | Converte velocidade bruta em trabalho útil. |
A comparação essencial para a quantização do vLLM não é “quantizado versus não quantizado” em abstrato. É “este checkpoint e kernel nesta GPU, com esta carga de trabalho, versus nossa linha de base”. Publique as condições junto com qualquer resultado. Se o seu teste não inclui uma verificação de qualidade, chame-o de experimento apenas de desempenho.
Modos de falha comuns
O modelo não carrega. Verifique os metadados do checkpoint, o método de quantização, a versão do vLLM, a capacidade da GPU e se o método é compatível com cada camada usada pela arquitetura. A matriz de métodos do vLLM deve ser consultada antes de alterar cegamente as flags de comando.
A economia de memória não melhorou a latência. Uma menor ocupação de memória pelos pesos não garante um kernel mais rápido. Teste na simultaneidade-alvo e inspecione o tempo até o primeiro token, a velocidade de decodificação e a utilização da GPU. Uma maior margem para o cache KV pode ser o benefício real.
Um checkpoint de poucos bits parece rápido, mas falha nos testes de qualidade. Mantenha um conjunto de aceitação de produção e meça a porcentagem de saídas que atende aos critérios da sua aplicação. Um limite para reversão deve ser definido antes do canário.
O benchmark não pode ser reproduzido. Registre as revisões do modelo e do checkpoint, as versões do vLLM e do driver, a SKU da GPU, o conjunto de dados, a simultaneidade, os comprimentos dos prompts, os comprimentos de saída e os argumentos de comando. Sem isso, um número de throughput é marketing, e não evidência de engenharia.
Quando usar o Flatkey Cloud GPU
Se você precisa executar seu próprio servidor vLLM e comparar checkpoints quantizados, escolha a capacidade de GPU com base em um requisito medido de memória e simultaneidade. A Flatkey fornece opções de aluguel de GPUs NVIDIA por meio do Cloud GPU Compute. Confirme a SKU disponível, a região de implantação, a capacidade, os preços e os termos de serviço antes de se comprometer. Um teste de quantização do vLLM deve ser executado na configuração que você realmente pretende alugar. Se você precisa de uma API de modelo gerenciada em vez de operar o vLLM, avalie separadamente a rota de API e o diretório de modelos da Flatkey; esse é um modelo operacional diferente.
Para decisões de implantação relacionadas, veja nosso guia de implantação do vLLM, guia de inferência do vLLM com várias GPUs e comparação entre vLLM e Ollama.
Perguntas frequentes
A quantização do vLLM sempre torna a inferência mais rápida?
Não. Ela pode reduzir a memória dos pesos, mas a latência e o throughput dependem do checkpoint, do kernel, da GPU, dos comprimentos de sequência e da carga de solicitações. Compare uma carga de trabalho real com uma linha de base.
Posso usar AWQ em uma A100 ou H100?
A matriz de compatibilidade atual do vLLM lista suporte a AWQ para Ampere e Hopper, que incluem A100 e H100. Verifique o checkpoint exato, a versão atual do vLLM e a arquitetura do modelo antes da implantação.
FP8 é compatível com todas as GPUs NVIDIA?
Não. O suporte varia conforme a implementação e a arquitetura de quantização. A matriz atual diferencia métodos como llm-compressor FP8 e Marlin; verifique a linha exata para o seu hardware.
Devo quantizar antes ou depois de selecionar uma GPU?
Primeiro, dimensione a carga de trabalho e a meta de qualidade; em seguida, teste os checkpoints candidatos em GPUs compatíveis. A escolha do formato e do hardware deve ser avaliada em conjunto.
