vLLM

01 · Conceito

Conceito

Você tem uma GPU de 80 GB, uma cópia do Qwen3.8-27B e um pedido para levantar uma API de chat interna para talvez quarenta engenheiros. Dois números decidem se isso funciona: quanto da placa o engine pode reivindicar e quão longa uma única conversa pode ficar. Erre numa direção e o servidor se recusa a iniciar; erre na outra e ele morre na primeira rajada real de tráfego. Esta lição mostra o ciclo operacional de dimensionamento, porque todo o resto sobre o vLLM — a API no formato OpenAI, o scheduler, as métricas — é documentação que você pode ler, e confundir um teto configurado com capacidade realizada é a parte que as pessoas erram.

O vLLM existe por causa da lição 7.8. Seu scheduler admite e aposenta requisições nas fronteiras de iteração em vez de segurar um batch fixo até o membro mais lento terminar, e seu cache é paginado: blocos de tamanho fixo entregues conforme os tokens são produzidos, de modo que uma sessão que para em quatro mil tokens nunca pagou pelos trinta e dois mil que lhe eram permitidos. O trabalho do engine na inicialização é decidir de que tamanho esse pool de blocos deve ser, e ele faz isso por subtração em vez de perguntar a você.

Trate --gpu-memory-utilization como um teto, não como o pool de KV. O engine paga pesos residentes, picos de ativação, pools de CUDA graph, fragmentação do alocador e estado específico da arquitetura antes de expor qualquer capacidade de cache. A lição 9.3 é dona desse orçamento completo do acelerador, enquanto a lição 7.2 é dona da derivação de cache e estado recorrente deste modelo. Na implementação de referência, as 48 camadas Gated DeltaNet mantêm cerca de 144 MiB de estado recorrente por sequência quando esse estado está em fp32; outro runtime pode escolher dtype ou layout diferentes, portanto copiar essa contagem de bytes para uma afirmação de capacidade do vLLM sem conferir a implementação seria tão errado quanto ignorar o estado.

A fonte de verdade é, portanto, o launch que você vai servir. Fixe o checkpoint e o release do vLLM, deixe folga deliberada e leia as linhas de startup que informam o pool de KV efetivamente alocado e a concorrência máxima implicada pelo comprimento de contexto escolhido. --max-model-len precisa acomodar ao menos uma requisição dentro desse pool realizado. Se não acomodar, o engine deve rejeitar a configuração no startup; reduza o limite, mude para um formato de memória validado ou acrescente capacidade e então meça de novo.

A paginação muda a admissão depois que essa condição de segurança é satisfeita. Blocos são alocados para tokens realmente presentes, não para cada token que uma requisição tem permissão de alcançar, então conversas comuns mais curtas podem coexistir com concorrência muito maior do que sugere uma divisão pelo comprimento máximo de pior caso. Dimensione o limite rígido pela alocação realizada e depois dimensione o tráfego pela distribuição medida dos comprimentos de prompt e completion.

vllm serve Qwen/Qwen3.8-27B \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

Não confie mais na estimativa acima do que no engine. O vLLM imprime o tamanho do pool de KV que efetivamente alocou e a concorrência máxima que isso implica no comprimento de contexto escolhido. Leia essa linha, compare com a sua aritmética e reconcilie qualquer diferença grande antes de fazer benchmark de qualquer coisa — uma discrepância normalmente significa que a reserva de workspace ou a contabilidade do estado recorrente é diferente do que você supôs.

Se o pool realizado não consegue admitir o contexto nativo completo, nenhuma flag transforma essa alocação falha em capacidade utilizável. As opções honestas são mais memória, sharding entre GPUs com tensor parallelism (lição 5.8 para a mecânica, lição 9.9 para o custo da interconexão) ou um formato de memória de menor precisão suportado pelo runtime e aprovado pelo canário de corretude da lição 8.1. Meça o novo pool realizado em vez de projetar um multiplicador a partir da largura em bits.

Leve a cadeia de medição com você, não um conjunto decorado de flags. A fração de utilização limita o engine, o log de startup informa o pool que ele efetivamente realizou e --max-model-len limita a maior reivindicação individual contra esse pool. As lições 7.2 e 9.3 são donas da aritmética por trás dessas quantidades; esta lição é dona de como o vLLM as expõe e impõe.