vLLM Quickstart: Serviço de LLM de Alto Desempenho - em 2026

vLLM é um motor de inferência e servidores de alto throughput e eficiência de memória para Modelos de Linguagem Grandes (LLMs), desenvolvido pelo Sky Computing Lab da UC Berkeley.

Com seu algoritmo revolucionário PagedAttention, o vLLM atinge um throughput 14-24 vezes maior do que os métodos tradicionais de servidores, tornando-se a escolha ideal para implantações de LLM em produção. Para ver como o vLLM se encaixa entre Ollama, Docker Model Runner, LocalAI e provedores de nuvem — incluindo comparações de custo e infraestrutura — veja LLM Hosting: Local, Self-Hosted & Cloud Infrastructure Compared.

O que é o vLLM?

O vLLM (virtual LLM) é uma biblioteca de código aberto para inferência e servidores rápidos de LLM que rapidamente se tornou o padrão da indústria para implantações em produção. Lançado em 2023, introduziu PagedAttention, uma técnica revolucionária de gerenciamento de memória que melhora drasticamente a eficiência do serviço.

Recursos Principais

Alto Throughput de Desempenho: O vLLM entrega um throughput 14-24 vezes maior em comparação com o HuggingFace Transformers usando a mesma hardware. Este grande ganho de desempenho vem da empacotamento contínuo, núcleos CUDA otimizados e o algoritmo PagedAttention que elimina a fragmentação de memória.

Compatibilidade com API do OpenAI: O vLLM inclui um servidor de API embutido que é totalmente compatível com o formato do OpenAI. Isso permite a migração sem problemas do OpenAI para infraestrutura auto-hospedada sem alterar o código da aplicação. Basta apontar seu cliente de API para o endpoint do vLLM e ele funciona de forma transparente.

Algoritmo PagedAttention: A inovação central por trás do desempenho do vLLM é o PagedAttention, que aplica o conceito de paginação de memória virtual aos mecanismos de atenção. Em vez de alocar blocos de memória contíguos para caches KV (o que leva à fragmentação), o PagedAttention divide a memória em blocos de tamanho fixo que podem ser alocados sob demanda. Isso reduz o desperdício de memória até 4 vezes e permite lotes muito maiores.

Empacotamento Contínuo: Ao contrário do empacotamento estático, onde você espera que todas as sequências sejam concluídas, o vLLM usa empacotamento contínuo (rolamento). Assim que uma sequência termina, uma nova pode ser adicionada ao lote. Isso maximiza a utilização da GPU e minimiza a latência para solicitações entrantes.

Suporte a Multi-GPU: O vLLM suporta paralelismo de tensores e paralelismo de pipeline para distribuir modelos grandes entre múltiplas GPUs. Ele pode servir eficientemente modelos que não cabem na memória de uma única GPU, suportando configurações de 2 a 8+ GPUs.

Ampla Suporte a Modelos: Compatível com arquiteturas de modelos populares, incluindo LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma e muitos outros. Suporta tanto modelos ajustados para instruções quanto modelos básicos do HuggingFace Hub.

Quando Usar o vLLM

O vLLM se destaca em cenários específicos onde seus pontos fortes se destacam:

Serviços de API em Produção: Quando você precisa servir um LLM para muitos usuários simultâneos via API, o alto throughput e o empacotamento eficiente do vLLM tornam-no a melhor escolha. Empresas que operam chatbots, assistentes de código ou serviços de geração de conteúdo se beneficiam de sua capacidade de lidar com centenas de solicitações por segundo.

Cargas de Trabalho de Alta Concorrência: Se sua aplicação tem muitos usuários simultâneos fazendo solicitações, o empacotamento contínuo e o PagedAttention do vLLM permitem servir mais usuários com a mesma hardware em comparação com alternativas.

Otimização de Custo: Quando os custos da GPU são uma preocupação, o throughput superior do vLLM significa que você pode servir o mesmo tráfego com menos GPUs, reduzindo diretamente os custos de infraestrutura. A eficiência de memória 4 vezes maior do PagedAttention também permite usar instâncias de GPU menores e mais baratas.

Implantações no Kubernetes: O design sem estado do vLLM e sua arquitetura amigável a containers tornam-no ideal para clusters do Kubernetes. Seu desempenho consistente sob carga e gestão de recursos direta se integram bem com a infraestrutura nativa da nuvem.

Quando NÃO Usar o vLLM: Para desenvolvimento local, experimentação ou cenários com um único usuário, ferramentas como Ollama oferecem uma melhor experiência do usuário com configuração mais simples. A complexidade do vLLM é justificada quando você precisa de seus benefícios de desempenho para cargas de trabalho em produção.

Como Instalar o vLLM

Pré-requisitos

Antes de instalar o vLLM, certifique-se de que seu sistema atenda a esses requisitos:

• GPU: GPU NVIDIA com capacidade de cálculo 7.0+ (V100, T4, A10, A100, H100, RTX 20/30/40 series)
• CUDA: Versão 11.8 ou superior
• Python: 3.8 a 3.11
• VRAM: Mínimo 16GB para modelos de 7B, 24GB+ para 13B, 40GB+ para modelos maiores
• Driver: Driver NVIDIA 450.80.02 ou mais recente

Instalação via pip

O método mais simples de instalação é usando o pip. Isso funciona em sistemas com CUDA 11.8 ou superior:

# Crie um ambiente virtual (recomendado)
python3 -m venv vllm-env
source vllm-env/bin/activate

# Instale o vLLM
pip install vllm

# Verifique a instalação
python -c "import vllm; print(vllm.__version__)"

Para sistemas com versões diferentes de CUDA, instale a roda apropriada:

# Para CUDA 12.1
pip install vllm==0.4.2+cu121 -f https://github.com/vllm-project/vllm/releases

# Para CUDA 11.8
pip install vllm==0.4.2+cu118 -f https://github.com/vllm-project/vllm/releases

Instalação com Docker

O Docker fornece o método mais confiável de implantação, especialmente para produção:

# Puxe a imagem oficial do vLLM
docker pull vllm/vllm-openai:latest

# Execute o vLLM com suporte a GPU
docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model mistralai/Mistral-7B-Instruct-v0.2

A bandeira --ipc=host é importante para configurações de multi-GPU, pois permite a comunicação inter-processo adequada.

Construção a partir da Fonte

Para as últimas funcionalidades ou modificações personalizadas, construa a partir da fonte:

git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -e .

Guia de Início Rápido do vLLM

Executando Seu Primeiro Modelo

Inicie o vLLM com um modelo usando a interface de linha de comando:

# Baixe e sirva o Mistral-7B com API compatível com o OpenAI
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000

O vLLM baixará automaticamente o modelo do HuggingFace Hub (se não estiver em cache) e iniciará o servidor. Você verá saída indicando que o servidor está pronto:

INFO:     Started server process [12345]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8000

Fazendo Solicitações de API

Uma vez que o servidor esteja em execução, você pode fazer solicitações usando o cliente Python do OpenAI ou curl:

Usando curl:

curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "mistralai/Mistral-7B-Instruct-v0.2",
        "prompt": "Explique o que é o vLLM em uma frase:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

Usando o Cliente Python do OpenAI:

from openai import OpenAI

# Aponte para seu servidor do vLLM
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # O vLLM não requer autenticação por padrão
)

response = client.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    prompt="Explique o que é o vLLM em uma frase:",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

API de Completções de Chat:

response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[
        {"role": "system", "content": "Você é um assistente útil."},
        {"role": "user", "content": "O que é PagedAttention?"}
    ],
    max_tokens=200
)

print(response.choices[0].message.content)

Configuração Avançada

O vLLM oferece diversos parâmetros para otimizar o desempenho:

python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000 \
    --gpu-memory-utilization 0.95 \  # Use 95% da memória da GPU
    --max-model-len 8192 \            # Comprimento máximo da sequência
    --tensor-parallel-size 2 \        # Use 2 GPUs com paralelismo de tensores
    --dtype float16 \                 # Use precisão FP16
    --max-num-seqs 256                # Tamanho máximo do lote

Explicação dos Parâmetros Principais:

• --gpu-memory-utilization: Quanto da memória da GPU usar (0.90 = 90%). Valores mais altos permitem lotes maiores, mas deixam menos margem para picos de memória.
• --max-model-len: Comprimento máximo do contexto. Reduzir isso economiza memória para lotes maiores.
• --tensor-parallel-size: Número de GPUs para dividir o modelo.
• --dtype: Tipo de dados para os pesos (float16, bfloat16 ou float32). FP16 geralmente é ótimo.
• --max-num-seqs: Número máximo de sequências para processar em um lote.

Comparação entre vLLM e Ollama

Ambos, vLLM e Ollama, são escolhas populares para hospedagem local de LLM, mas eles visam casos de uso diferentes. Entender quando usar cada ferramenta pode impactar significativamente o sucesso do seu projeto.

Desempenho e Throughput

vLLM foi projetado para máximo throughput em cenários com muitos usuários. Seu PagedAttention e empacotamento contínuo permitem servir centenas de solicitações simultâneas de forma eficiente. Benchmarks mostram que o vLLM atinge 14-24x mais throughput do que implementações padrão e 2-4x mais do que Ollama sob alta concorrência.

Ollama otimiza para uso interativo com único usuário, com foco em baixa latência para solicitações individuais. Embora não corresponda ao throughput multi-usuário do vLLM, ele oferece excelente desempenho para desenvolvimento e uso pessoal com tempos de início mais rápidos e consumo de recursos ociosos mais baixo.

Facilidade de Uso

Ollama vence decisivamente em simplicidade. A instalação é um único comando (curl | sh), e executar modelos é tão simples quanto ollama run llama2. Ele inclui uma biblioteca de modelos com versões quantizadas otimizadas para diferentes perfis de hardware. A experiência do usuário se assemelha ao Docker – puxe, execute e vá.

vLLM requer mais configuração: gerenciamento de ambiente Python, instalação de CUDA, compreensão de parâmetros de serviço e especificação manual de modelos. A curva de aprendizado é mais íngreme, mas você ganha controle fino sobre a otimização de desempenho. Essa complexidade é justificada para implantações em produção onde você precisa extrair o máximo desempenho de seu hardware.

API e Integração

vLLM fornece APIs REST compatíveis com o OpenAI prontamente, tornando-o uma substituição direta para a API do OpenAI em aplicações existentes. Isso é crucial para migrar serviços de produção de provedores de nuvem para infraestrutura auto-hospedada sem mudanças no código.

Ollama oferece uma API REST mais simples e uma biblioteca dedicada para Python/JavaScript. Embora funcional, não é compatível com a API do OpenAI, exigindo mudanças no código ao integrar com aplicações que esperam o formato do OpenAI. No entanto, projetos comunitários como adaptadores Ollama-OpenAI preenchem essa lacuna.

Gerenciamento de Memória

vLLM algoritmo PagedAttention oferece eficiência superior de memória para solicitações simultâneas. Ele pode servir 2-4x mais usuários simultâneos com a mesma VRAM em comparação com implementações ingênuas. Isso se traduz diretamente em economia de custos em implantações de produção.

Ollama usa gerenciamento de memória mais simples adequado para cenários de único usuário. Ele gerencia automaticamente o carregamento/desligamento de modelos com base na atividade, o que é conveniente para desenvolvimento, mas não ótimo para uso de alta concorrência em produção.

Suporte a Multi-GPU

vLLM excel com paralelismo nativo de tensores e pipeline, distribuindo eficientemente modelos entre 2-8+ GPUs. Isso é essencial para servir modelos grandes, como LLMs de 70B parâmetros, que não cabem em uma única GPU.

Ollama atualmente tem suporte limitado a multi-GPU, funcionando melhor com uma única GPU. Isso torna-o menos adequado para modelos muito grandes que exigem inferência distribuída.

Recomendações para Caso de Uso

Escolha vLLM quando:

• Servir APIs de produção com muitos usuários simultâneos
• Otimizar custo por solicitação em implantações na nuvem
• Executar em clusters do Kubernetes ou plataformas de orquestração de contêineres
• Precisar de compatibilidade com API do OpenAI para aplicações existentes
• Servir modelos grandes que exigem suporte a multi-GPU
• Desempenho e throughput são requisitos críticos

Escolha Ollama quando:

• Desenvolvimento local e experimentação
• Uso interativo com único usuário (assistentes pessoais, chatbots)
• Prototipagem rápida e avaliação de modelos
• Aprendizado sobre LLMs sem complexidade de infraestrutura
• Executar em estações de trabalho pessoais ou laptops
• Simplicidade e facilidade de uso são prioridades

Muitas equipes usam ambas: Ollama para desenvolvimento e experimentação, depois vLLM para implantação em produção. Esta combinação fornece produtividade dos desenvolvedores enquanto mantém o desempenho em produção.

vLLM vs Docker Model Runner

O Docker recentemente introduziu o Model Runner (anteriormente GenAI Stack) como sua solução oficial para implantação local de modelos de IA. Como ele se compara ao vLLM?

Filosofia de Arquitetura

Docker Model Runner visa ser o “Docker para IA” – uma maneira simples e padronizada de executar modelos de IA localmente com a mesma facilidade de executar contêineres. Ele abstrai a complexidade e fornece uma interface consistente entre diferentes modelos e frameworks.

vLLM é um motor de inferência especializado focado exclusivamente no serviço de LLM com máximo desempenho. É uma ferramenta de nível mais baixo que você containeriza com o Docker, em vez de uma plataforma completa.

Configuração e Início Rápido

Docker Model Runner instalação é simples para usuários do Docker:

docker model pull llama3:8b
docker model run llama3:8b

Essa semelhança com o fluxo de trabalho de imagem do Docker torna-o imediatamente familiar para desenvolvedores já usando contêineres.

vLLM requer mais configuração inicial (Python, CUDA, dependências) ou usar imagens pré-construídas do Docker:

docker pull vllm/vllm-openai:latest
docker run --runtime nvidia --gpus all vllm/vllm-openai:latest --model <model-name>

Características de Desempenho

vLLM entrega throughput superior em cenários com múltiplos usuários devido ao PagedAttention e empacotamento contínuo. Para serviços de API de produção que lidam com centenas de solicitações por segundo, as otimizações do vLLM fornecem 2-5x mais throughput do que abordagens gerais de serviço.

Docker Model Runner se concentra em facilidade de uso em vez de máximo desempenho. É adequado para desenvolvimento local, testes e cargas de trabalho moderadas, mas não implementa as otimizações avançadas que fazem o vLLM excelar em escala.

Suporte a Modelos

Docker Model Runner fornece uma biblioteca curada de modelos com acesso de um comando a modelos populares. Ele suporta múltiplos frameworks (não apenas LLMs) incluindo Stable Diffusion, Whisper e outros modelos de IA, tornando-o mais versátil para diferentes cargas de trabalho de IA.

vLLM especializa-se em inferência de LLM com suporte profundo a modelos de linguagem baseados em transformers. Ele suporta qualquer LLM compatível com HuggingFace, mas não se estende a outros tipos de modelos de IA como geração de imagens ou reconhecimento de fala.

Implantação em Produção

vLLM foi testado em produção em empresas como Anthropic, Replicate e muitas outras que servem bilhões de tokens diariamente. Suas características de desempenho e estabilidade sob carga pesada tornam-no o padrão de fato para servir LLMs em produção.

Docker Model Runner é mais novo e posiciona-se mais para cenários de desenvolvimento e testes locais. Embora possa servir tráfego de produção, ele carece do histórico comprovado e otimizações de desempenho que implantações em produção exigem.

Ecosistema de Integração

vLLM integra-se com ferramentas de infraestrutura de produção: operadores do Kubernetes, métricas do Prometheus, Ray para servidores distribuídos e compatibilidade extensa com a API do OpenAI para aplicações existentes.

Docker Model Runner integra-se naturalmente com o ecosistema do Docker e do Docker Desktop. Para equipes já padronizadas no Docker, essa integração fornece uma experiência coesa, mas com menos recursos especializados para servidores de LLM.

Quando Usar Cada Um

Use vLLM para:

• Serviços de API de LLM em produção
• Implantações de alto throughput com múltiplos usuários
• Implantações na nuvem sensíveis ao custo que precisam de máxima eficiência
• Ambientes de Kubernetes e infraestrutura nativa da nuvem
• Quando você precisa de escalabilidade e desempenho comprovados

Use Docker Model Runner para:

• Desenvolvimento e testes locais
• Executar vários tipos de modelos de IA (não apenas LLMs)
• Equipes profundamente investidas no ecosistema do Docker
• Experimentação rápida sem configuração de infraestrutura
• Propósitos educacionais e de aprendizado

Abordagem Híbrida: Muitas equipes desenvolvem com Docker Model Runner localmente para conveniência, depois implantam com vLLM em produção para desempenho. As imagens do Docker Model Runner também podem ser usadas para executar contêineres do vLLM, combinando ambas as abordagens.

Boas Práticas para Implantação em Produção

Implantação com Docker

Crie uma configuração Docker Compose pronta para produção:

version: '3.8'

services:
  vllm:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    environment:
      - CUDA_VISIBLE_DEVICES=0,1
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
      - ./logs:/logs
    ports:
      - "8000:8000"
    command: >
      --model mistralai/Mistral-7B-Instruct-v0.2
      --tensor-parallel-size 2
      --gpu-memory-utilization 0.90
      --max-num-seqs 256
      --max-model-len 8192      
    restart: unless-stopped
    shm_size: '16gb'
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]

Implantação no Kubernetes

Implante o vLLM no Kubernetes para escala de produção:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
          - --model
          - mistralai/Mistral-7B-Instruct-v0.2
          - --tensor-parallel-size
          - "2"
          - --gpu-memory-utilization
          - "0.90"
        resources:
          limits:
            nvidia.com/gpu: 2
        ports:
        - containerPort: 8000
        volumeMounts:
        - name: cache
          mountPath: /root/.cache/huggingface
      volumes:
      - name: cache
        hostPath:
          path: /mnt/huggingface-cache
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm
  ports:
  - port: 80
    targetPort: 8000
  type: LoadBalancer

Monitoramento e Observabilidade

O vLLM expõe métricas do Prometheus para monitoramento:

import requests

# Obter métricas
metrics = requests.get("http://localhost:8000/metrics").text
print(metrics)

Métricas principais para monitorar:

• vllm:num_requests_running - Solicitações ativas
• vllm:gpu_cache_usage_perc - Utilização do cache de KV
• vllm:time_to_first_token - Métrica de latência
• vllm:time_per_output_token - Velocidade de geração

Otimização de Desempenho

Otimizar Uso da Memória da GPU: Comece com --gpu-memory-utilization 0.90 e ajuste com base no comportamento observado. Valores mais altos permitem lotes maiores, mas correm o risco de erros OOM durante picos de tráfego.

Ajustar Comprimento Máximo da Sequência: Se seu caso de uso não exigir o comprimento total do contexto, reduza --max-model-len. Isso libera memória para lotes maiores. Por exemplo, se você precisar apenas de 4K de contexto, defina --max-model-len 4096 em vez de usar o máximo do modelo (geralmente 8K-32K).

Escolher Quantização Apropriada: Para modelos que suportam, use versões quantizadas (8-bit, 4-bit) para reduzir a memória e aumentar o throughput:

--quantization awq  # Para modelos quantizados AWQ
--quantization gptq # Para modelos quantizados GPTQ

Ativar Caching de Prefixos: Para aplicações com prompts repetidos (como chatbots com mensagens de sistema), ative o caching de prefixos:

--enable-prefix-caching

Isso cacheia os valores KV para prefixos comuns, reduzindo a computação para solicitações que compartilham o mesmo prefixo de prompt.

Solução de Problemas Comuns

Erros de Memória Insuficiente

Sintomas: O servidor crasha com erros de memória CUDA.

Soluções:

• Reduza --gpu-memory-utilization para 0.85 ou 0.80
• Diminua --max-model-len se seu caso de uso permitir
• Reduza --max-num-seqs para diminuir o tamanho do lote
• Use uma versão quantizada do modelo
• Ative o paralelismo de tensores para distribuir entre mais GPUs

Baixo Throughput

Sintomas: O servidor lida com menos solicitações do que o esperado.

Soluções:

• Aumente --max-num-seqs para permitir lotes maiores
• Aumente --gpu-memory-utilization se tiver margem
• Verifique se o CPU está limitado com htop – considere CPUs mais rápidas
• Verifique a utilização da GPU com nvidia-smi – deve ser 95%+
• Ative FP16 se estiver usando FP32: --dtype float16

Tempo de Primeiro Token Lento

Sintomas: Alta latência antes do início da geração.

Soluções:

• Use modelos menores para aplicações críticas de latência
• Ative caching de prefixos para prompts repetidos
• Reduza --max-num-seqs para priorizar latência sobre throughput
• Considere decodificação especulativa para modelos compatíveis
• Otimize a configuração de paralelismo de tensores

Falhas no Carregamento do Modelo

Sintomas: O servidor não consegue iniciar, não consegue carregar o modelo.

Soluções:

• Verifique se o nome do modelo corresponde exatamente ao formato do HuggingFace
• Verifique a conectividade de rede com o HuggingFace Hub
• Certifique-se de que haja espaço em disco suficiente em ~/.cache/huggingface
• Para modelos protegidos, defina a variável de ambiente HF_TOKEN
• Tente baixar manualmente com huggingface-cli download <model>

Recursos Avançados

Decodificação Especulativa

O vLLM suporta decodificação especulativa, onde um modelo de rascunho menor propõe tokens que um modelo de destino maior verifica. Isso pode acelerar a geração em 1,5-2x:

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-70b-chat-hf \
    --speculative-model meta-llama/Llama-2-7b-chat-hf \
    --num-speculative-tokens 5

Adapters LoRA

Sirva vários adapters LoRA sobre um modelo base sem carregar múltiplos modelos completos:

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-7b-hf \
    --enable-lora \
    --lora-modules sql-lora=./path/to/sql-adapter \
                   code-lora=./path/to/code-adapter

Depois, especifique qual adapter usar por solicitação:

response = client.completions.create(
    model="sql-lora",  # Use o adaptador SQL
    prompt="Converta isso para SQL: Mostre-me todos os usuários criados este mês"
)

Serviço Multi-LoRA

O serviço multi-LoRA do vLLM permite hospedar dezenas de adaptadores finamente ajustados com mínima sobrecarga de memória. Isso é ideal para servir variantes de modelos específicas para clientes ou tarefas:

# Solicitação com adaptador LoRA específico
response = client.chat.completions.create(
    model="meta-llama/Llama-2-7b-hf",
    messages=[{"role": "user", "content": "Escreva uma consulta SQL"}],
    extra_body={"lora_name": "sql-lora"}
)

Caching de Prefixos

Ative o caching automático de prefixos para evitar a recriação do cache KV para prefixos de prompt repetidos:

--enable-prefix-caching

Isso é particularmente eficaz para:

• Chatbots com prompts de sistema fixos
• Aplicações RAG com modelos de contexto consistentes
• Prompts de aprendizado com poucos exemplos repetidos entre solicitações

O caching de prefixos pode reduzir o tempo até o primeiro token em 50-80% para solicitações que compartilham prefixos de prompt.

Exemplos de Integração

Integração com LangChain

from langchain.llms import VLLMOpenAI

llm = VLLMOpenAI(
    openai_api_key="EMPTY",
    openai_api_base="http://localhost:8000/v1",
    model_name="mistralai/Mistral-7B-Instruct-v0.2",
    max_tokens=512,
    temperature=0.7,
)

response = llm("Explique PagedAttention em termos simples")
print(response)

Integração com LlamaIndex

from llama_index.llms import VLLMServer

llm = VLLMServer(
    api_url="http://localhost:8000/v1",
    model="mistralai/Mistral-7B-Instruct-v0.2",
    temperature=0.7,
    max_tokens=512
)

response = llm.complete("O que é o vLLM?")
print(response)

Aplicação FastAPI

from fastapi import FastAPI
from openai import AsyncOpenAI

app = FastAPI()
client = AsyncOpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"
)

@app.post("/generate")
async def generate(prompt: str):
    response = await client.completions.create(
        model="mistralai/Mistral-7B-Instruct-v0.2",
        prompt=prompt,
        max_tokens=200
    )
    return {"result": response.choices[0].text}

Benchmarks de Desempenho

Dados de desempenho reais ajudam a ilustrar as vantagens do vLLM:

Comparação de Throughput (Mistral-7B em GPU A100):

• vLLM: ~3.500 tokens/segundo com 64 usuários simultâneos
• HuggingFace Transformers: ~250 tokens/segundo com mesma concorrência
• Ollama: ~1.200 tokens/segundo com mesma concorrência
• Resultado: o vLLM fornece uma melhoria de 14x sobre implementações básicas

Eficiência de Memória (LLaMA-2-13B):

• Implementação padrão: 24GB VRAM, 32 sequências simultâneas
• vLLM com PagedAttention: 24GB VRAM, 128 sequências simultâneas
• Resultado: 4x mais sequências simultâneas com mesma memória

Latência sob Carga (Mixtral-8x7B em 2xA100):

• vLLM: P50 latência 180ms, P99 latência 420ms em 100 req/s
• Serviço padrão: P50 latência 650ms, P99 latência 3.200ms em 100 req/s
• Resultado: o vLLM mantém latência consistente sob alta carga

Esses benchmarks demonstram por que o vLLM tornou-se o padrão de fato para servir LLMs em produção onde o desempenho importa.

Análise de Custo

Entender as implicações de custo de escolher o vLLM:

Cenário: Servir 1 milhão de solicitações/dia

Com Serviço Padrão:

• Necessário: 8x A100 GPUs (80GB)
• Custo no AWS: ~$32/hora × 24 × 30 = $23.040/mês
• Custo por 1 milhão de tokens: ~$0,75

Com vLLM:

• Necessário: 2x A100 GPUs (80GB)
• Custo no AWS: ~$8/hora × 24 × 30 = $5.760/mês
• Custo por 1 milhão de tokens: ~$0,19
• Economia: $17.280/mês (75% de redução)

Essa vantagem de custo cresce com a escala. Organizações que servem bilhões de tokens por mês economizam centenas de milhares de dólares usando o vLLM otimizado em vez de implementações ingênuas.

Considerações de Segurança

Autenticação

O vLLM não inclui autenticação por padrão. Para produção, implemente autenticação no nível do proxy reverso:

# Configuração do Nginx
location /v1/ {
    auth_request /auth;
    proxy_pass http://vllm-backend:8000;
}

location /auth {
    proxy_pass http://auth-service:8080/verify;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
}

Ou use gateways de API como Kong, Traefik ou AWS API Gateway para autenticação e limitação de taxa de nível empresarial.

Isolamento de Rede

Execute o vLLM em redes privadas, não diretamente expostas à internet:

# Exemplo de NetworkPolicy do Kubernetes
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: vllm-access
spec:
  podSelector:
    matchLabels:
      app: vllm
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api-gateway
    ports:
    - protocol: TCP
      port: 8000

Limitação de Taxa

Implemente limitação de taxa para prevenir abusos:

# Exemplo usando Redis para limitação de taxa
from fastapi import FastAPI, HTTPException
from fastapi.middleware.cors import CORSMiddleware
import redis
from datetime import datetime, timedelta

app = FastAPI()
redis_client = redis.Redis(host='localhost', port=6379)

@app.middleware("http")
async def rate_limit_middleware(request, call_next):
    client_ip = request.client.host
    key = f"rate_limit:{client_ip}"
    
    requests = redis_client.incr(key)
    if requests == 1:
        redis_client.expire(key, 60)  # Janela de 60 segundos
    
    if requests > 60:  # 60 solicitações por minuto
        raise HTTPException(status_code=429, detail="Limite de taxa excedido")
    
    return await call_next(request)

Controle de Acesso ao Modelo

Para implantações multi-tenant, controle quais usuários podem acessar quais modelos:

ALLOWED_MODELS = {
    "user_tier_1": ["mistralai/Mistral-7B-Instruct-v0.2"],
    "user_tier_2": ["mistralai/Mistral-7B-Instruct-v0.2", "meta-llama/Llama-2-13b-chat-hf"],
    "admin": ["*"]  # Todos os modelos
}

def verify_model_access(user_tier: str, model: str) -> bool:
    allowed = ALLOWED_MODELS.get(user_tier, [])
    return "*" in allowed or model in allowed

Guia de Migração

De OpenAI para vLLM

Migrar de OpenAI para vLLM auto-hospedado é direto graças à compatibilidade da API:

Antes (OpenAI):

from openai import OpenAI

client = OpenAI(api_key="sk-...")
response = client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": "Hello"}]
)

Depois (vLLM):

from openai import OpenAI

client = OpenAI(
    base_url="https://your-vllm-server.com/v1",
    api_key="your-internal-key"  # Se você adicionou autenticação
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "Hello"}]
)

Apenas duas mudanças necessárias: atualize base_url e model nome. Todo o código restante permanece idêntico.

De Ollama para vLLM

Ollama usa um formato de API diferente. Aqui está a conversão:

API do Ollama:

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={
        'model': 'llama2',
        'prompt': 'Por que o céu é azul?'
    })

Equivalente do vLLM:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
response = client.completions.create(
    model="meta-llama/Llama-2-7b-chat-hf",
    prompt="Por que o céu é azul?"
)

Você precisará atualizar as chamadas de API em todo o seu código base, mas as bibliotecas de cliente do OpenAI fornecem melhor tratamento de erros e recursos.

De HuggingFace Transformers para vLLM

Migração de uso direto em Python:

HuggingFace:

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")
tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")

inputs = tokenizer("Hello", return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=100)
result = tokenizer.decode(outputs[0])

vLLM:

from vllm import LLM, SamplingParams

llm = LLM(model="mistralai/Mistral-7B-Instruct-v0.2")
sampling_params = SamplingParams(max_tokens=100)

outputs = llm.generate("Hello", sampling_params)
result = outputs[0].outputs[0].text

A API do Python do vLLM é mais simples e muito mais rápida para inferência em lote.

O Futuro do vLLM

O vLLM continua com desenvolvimento rápido com recursos emocionantes no roteiro:

Servidores Desagregados: Separar prefill (processamento de prompt) e decode (geração de token) em GPUs diferentes para otimizar a utilização de recursos. O prefill é limitado por cálculo enquanto o decode é limitado por memória, então executá-los em hardware especializado melhora a eficiência.

Inferência Multi-Nó: Distribuir modelos muito grandes (100B+ parâmetros) entre várias máquinas, permitindo servir modelos que são muito grandes para configurações de único nó.

Quantização Melhorada: Suporte para novos formatos de quantização como GGUF (usado pelo llama.cpp) e integração melhorada de AWQ/GPTQ para melhor desempenho com modelos quantizados.

Melhorias na Decodificação Especulativa: Modelos de rascunho mais eficientes e estratégias adaptativas de especulação para obter acelerações maiores sem perda de precisão.

Otimizações de Attenção: FlashAttention 3, atenção de anel para contextos extremamente longos (100K+ tokens) e outros mecanismos de atenção de ponta.

Melhor Cobertura de Modelos: Expansão do suporte a modelos multimodais (modelos de linguagem e visão), modelos de áudio e arquiteturas especializadas conforme surgem.

O projeto vLLM mantém desenvolvimento ativo com contribuições da UC Berkeley, Anyscale e a comunidade open-source mais ampla. À medida que a implantação de LLM se torna mais crítica para sistemas de produção, o papel do vLLM como padrão de desempenho continua a crescer. Para uma comparação mais ampla do vLLM com outras infraestruturas locais e de nuvem de LLM, consulte nosso LLM Hosting: Local, Self-Hosted & Cloud Infrastructure Compared.

Links Úteis

Artigos Relacionados Neste Site

• Anfitrião Local de LLM: Guia Completo de 2026 - Ollama, vLLM, LocalAI, Jan, LM Studio & Mais - Comparação abrangente de 12+ ferramentas de hospedagem local de LLM, incluindo análise detalhada do vLLM ao lado de Ollama, LocalAI, Jan, LM Studio e outros. Aborda a maturidade da API, suporte a chamada de ferramentas, compatibilidade com GGUF e benchmarks de desempenho para ajudar a escolher a solução certa.

• Guia Rápido do Ollama - Referência completa de comandos e guia rápido do Ollama, abrangendo instalação, gerenciamento de modelos, uso da API e melhores práticas para implantação local de LLM. Essencial para desenvolvedores que usam Ollama junto ou em vez do vLLM.

• Docker Model Runner vs Ollama: Qual Escolher? - Comparação aprofundada entre o Model Runner do Docker e o Ollama para implantação local de LLM, analisando desempenho, suporte a GPU, compatibilidade da API e casos de uso. Ajuda a entender o cenário competitivo no qual o vLLM atua.

• Guia Rápido do Docker Model Runner: Comandos & Exemplos - Guia prático do Docker Model Runner com comandos e exemplos para implantação de modelos de IA. Útil para equipes que comparam a abordagem do Docker com as capacidades especializadas de servir LLM do vLLM.

Recursos Externos e Documentação

• Repositório GitHub do vLLM - Repositório oficial do vLLM com código-fonte, documentação abrangente, guias de instalação e discussões ativas da comunidade. Recurso essencial para ficar atualizado com as últimas funcionalidades e resolver problemas.

• Documentação do vLLM - Documentação oficial que abrange todos os aspectos do vLLM, desde a configuração básica até a configuração avançada. Inclui referências da API, guias de ajuste de desempenho e melhores práticas de implantação.

• Artigo PagedAttention - Artigo acadêmico que introduz o algoritmo PagedAttention, que impulsiona a eficiência do vLLM. Leitura essencial para entender as inovações técnicas por trás das vantagens de desempenho do vLLM.

• Blog do vLLM - Blog oficial do vLLM com anúncios de lançamento, benchmarks de desempenho, análises técnicas profundas e estudos de caso da comunidade de implantações em produção.

• HuggingFace Model Hub - Repositório abrangente de modelos de LLM de código aberto compatíveis com o vLLM. Pesquise modelos por tamanho, tarefa, licença e características de desempenho para encontrar o modelo certo para seu caso de uso.

• Documentação do Ray Serve - Documentação do framework Ray Serve para construir implantações escaláveis e distribuídas do vLLM. O Ray fornece funcionalidades avançadas, como escalabilidade automática, serviço multi-modelo e gerenciamento de recursos para sistemas de produção.

• TensorRT-LLM da NVIDIA - TensorRT-LLM da NVIDIA para inferência altamente otimizada em GPUs da NVIDIA. Alternativa ao vLLM com estratégias diferentes de otimização, útil para comparação e compreensão do cenário de otimização de inferência.

• Referência da API do OpenAI - Documentação oficial da API do OpenAI com a qual a API do vLLM é compatível. Use-a como referência ao construir aplicações que precisam funcionar com endpoints do OpenAI e do vLLM auto-hospedado de forma intercambiável.