Início Rápido do vLLM: Servidor de LLM de Alto Desempenho - em 2026

vLLM é um motor de inferência e serviço de alto rendimento e eficiente em memória para Grandes Modelos de Linguagem (LLMs), desenvolvido pelo Laboratório de Computação Sky da UC Berkeley.

Com seu revolucionário algoritmo PagedAttention, o vLLM alcança um rendimento de 14 a 24 vezes superior aos métodos de serviço tradicionais, tornando-se a escolha preferida 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—including trade-offs de custos e infraestrutura—consulte LLM Hosting: Infraestrutura Local, Auto-hospedada e Nuvem Comparadas.

O que é o vLLM?

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

Principais Características

Desempenho de Alto Rendimento: o vLLM oferece um rendimento 14 a 24 vezes maior em comparação com os Transformers do HuggingFace, utilizando o mesmo hardware. Este ganho massivo de desempenho vem do loteamento contínuo, kernels CUDA otimizados e do algoritmo PagedAttention que elimina a fragmentação de memória.

Compatibilidade com a API do OpenAI: o vLLM inclui um servidor de API embutido totalmente compatível com o formato do OpenAI. Isso permite a migração transparente 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 em até 4x e permite tamanhos de lote muito maiores.

Loteamento Contínuo: Diferente do loteamento estático, onde você espera que todas as sequências sejam concluídas, o vLLM usa loteamento contínuo (rolante). 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 recebidas.

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

Amplo Suporte de Modelos: Compatível com arquiteturas de modelos populares, incluindo LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma e muitos outros. Suporta modelos base e ajustados com instruções do HuggingFace Hub.

Quando Usar o vLLM

O vLLM se destaca em cenários específicos onde suas forças brilham:

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

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

Otimização de Custos: Quando os custos de GPU são uma preocupação, o superior rendimento 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 4x do PagedAttention também permite usar instâncias de GPU menores e mais baratas.

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

Quando NÃO Usar o vLLM: Para desenvolvimento local, experimentação ou cenários de usuário único, ferramentas como Ollama ou llama.cpp oferecem uma melhor experiência de usuário com configuração mais simples. A complexidade do vLLM é justificada quando você precisa de suas vantagens 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 estes requisitos:

• GPU: GPU NVIDIA com capacidade de computação 7.0+ (V100, T4, A10, A100, H100, séries RTX 20/30/40)
• CUDA: Versão 11.8 ou superior
• Python: 3.8 a 3.11
• VRAM: Mínimo de 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 de instalação mais simples é 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 do 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 de implantação mais confiável, especialmente para produção:

# Baixe 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 flag --ipc=host é importante para configurações multi-GPU, pois permite comunicação interprocessos adequada.

Compilando a partir do Código Fonte

Para as funcionalidades mais recentes ou modificações personalizadas, compile a partir do código 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 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á uma 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 é vLLM em uma frase:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

Usando o Cliente Python do OpenAI:

from openai import OpenAI

# Aponte para o seu servidor 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="Explain what vLLM is in one sentence:",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

API de Completas 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 numerosos 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 \  # Usar 95% da memória da GPU
    --max-model-len 8192 \            # Comprimento máximo de sequência
    --tensor-parallel-size 2 \        # Usar 2 GPUs com paralelismo de tensor
    --dtype float16 \                 # Usar precisão FP16
    --max-num-seqs 256                # Tamanho máximo de lote

Parâmetros Chave Explicados:

• --gpu-memory-utilization: Quanta 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 de 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 pesos (float16, bfloat16 ou float32). FP16 geralmente é o ideal.
• --max-num-seqs: Número máximo de sequências para processar em um lote.

Comparação vLLM vs Ollama

Tanto o vLLM quanto o 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 Rendimento

vLLM é projetado para rendimento máximo em cenários multi-usuário. Seu PagedAttention e loteamento contínuo permitem servir centenas de solicitações simultâneas de forma eficiente. Benchmarks mostram o vLLM alcançando um rendimento 14-24x maior que implementações padrão e 2-4x maior que o Ollama sob alta concorrência.

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

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 assemelha-se ao Docker – puxar, executar e ir.

vLLM requer mais configuração: gerenciamento de ambiente Python, instalação 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 granular sobre a otimização de desempenho. Esta 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 OpenAI nativamente, tornando-o uma substituição direta para a API do OpenAI em aplicações existentes. Isso é crucial para migrar serviços em produção de provedores de nuvem para infraestrutura auto-hospedada sem alterações de código.

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

Gerenciamento de Memória

O algoritmo PagedAttention do vLLM oferece eficiência de memória superior 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 em produção.

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

Suporte Multi-GPU

vLLM destaca-se com paralelismo de tensor e paralelismo de pipeline nativos, distribuindo modelos eficientemente através de 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 principalmente com uma única GPU. Isso o torna menos adequado para modelos muito grandes que requerem inferência distribuída.

Recomendações de Casos de Uso

Escolha o vLLM quando:

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

Escolha o Ollama quando:

• Desenvolvimento local e experimentação
• Uso interativo de usuário único (assistentes pessoais, chatbots)
• Prototipagem rápida e avaliação de modelos
• Aprender 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 ambos: Ollama para desenvolvimento e experimentação, e depois vLLM para implantação em produção. Esta combinação fornece produtividade para desenvolvedores enquanto mantém o desempenho em produção.

Comparação vLLM vs Docker Model Runner

O Docker introduziu recentemente 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 que executar containers. Ele abstrai a complexidade e fornece uma interface consistente através de diferentes modelos e frameworks.

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

Configuração e Início Rápido

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

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

Essa semelhança com o fluxo de imagem do Docker torna-o instantaneamente familiar para desenvolvedores que já usam containers.

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

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 rendimento superior para cenários multi-usuário devido ao PagedAttention e loteamento contínuo. Para serviços de API em produção que lidam com centenas de solicitações por segundo, as otimizações do vLLM fornecem um rendimento 2-5x melhor que abordagens genéricas de serviço.

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

Suporte de Modelos

Docker Model Runner fornece uma biblioteca de modelos curada 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 para 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 é testado em batalha em produção em empresas como Anthropic, Replicate e muitas outras, servindo bilhões de tokens diariamente. Suas características de desempenho e estabilidade sob carga pesada o tornam o padrão de facto para serviço de LLM em produção.

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

Ecossistema de Integração

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

Docker Model Runner integra-se naturalmente com o ecossistema do Docker e Docker Desktop. Para equipes já padronizadas no Docker, esta integração oferece uma experiência coesa, mas com menos recursos especializados de serviço de LLM.

Quando Usar Cada Um

Use o vLLM para:

• Serviços de API de LLM em produção
• Implantações de alto rendimento e multi-usuário
• Implantações em nuvem sensíveis a custos que precisam de máxima eficiência
• Ambientes Kubernetes e nativos da nuvem
• Quando você precisa de escalabilidade e desempenho comprovados

Use o Docker Model Runner para:

• Desenvolvimento local e teste
• Executar vários tipos de modelos de IA (não apenas LLMs)
• Equipes fortemente investidas no ecossistema Docker
• Experimentação rápida sem configuração de infraestrutura
• Finalidades de aprendizado e educacionais

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

Melhores Práticas de Implantação em Produção

Implantação 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 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 Prometheus para monitoramento:

import requests

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

Métricas-chave para monitorar:

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

Ajuste de Desempenho

Otimize a Utilização de 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 arriscam erros de OOM durante picos de tráfego.

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

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

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

Habilite Cache de Prefixo: Para aplicações com prompts repetidos (como chatbots com mensagens de sistema), habilite o cache de prefixo:

--enable-prefix-caching

Isso faz cache dos 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 (Out of Memory)

Sintomas: O servidor trava 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
• Habilite paralelismo de tensor para distribuir em mais GPUs

Baixo Rendimento

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 houver margem
• Verifique se a CPU é o gargalo com htop – considere CPUs mais rápidos
• Verifique a utilização da GPU com nvidia-smi – deve ser 95%+
• Habilite FP16 se estiver usando FP32: --dtype float16

Tempo de Primeiro Token Lento

Sintomas: Alta latência antes que a geração comece.

Soluções:

• Use modelos menores para aplicações críticas de latência
• Habilite cache de prefixo para prompts repetidos
• Reduza --max-num-seqs para priorizar latência em vez de rendimento
• Considere decodificação especulativa para modelos suportados
• Otimize a configuração de paralelismo de tensor

Falhas de Carregamento de Modelo

Sintomas: O servidor falha ao 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 ao HuggingFace Hub
• Certifique-se de ter espaço em disco suficiente em ~/.cache/huggingface
• Para modelos restritos, defina a variável de ambiente HF_TOKEN
• Tente baixar manualmente com huggingface-cli download <model>

Funcionalidades Avançadas

Decodificação Especulativa

O vLLM suporta decodificação especulativa, onde um modelo de rascunho menor propõe tokens que um modelo alvo 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

Adaptadores LoRA

Sirva múltiplos adaptadores 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 adaptador usar por solicitação:

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

Serviço Multi-LoRA

O serviço multi-LoRA do vLLM permite hospedar dezenas de adaptadores ajustados com sobrecarga de memória mínima. Isso é ideal para servir variantes de modelos específicas de 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"}
)

Cache de Prefixo

Habilite o cache de prefixo automático para evitar re-computar cache KV para prefixos de prompt repetidos:

--enable-prefix-caching

Isso é particularmente eficaz para:

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

O cache de prefixo 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 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 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 é 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 do mundo real ajudam a ilustrar as vantagens do vLLM:

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

• vLLM: ~3.500 tokens/segundo com 64 usuários simultâneos
• HuggingFace Transformers: ~250 tokens/segundo com a mesma concorrência
• Ollama: ~1.200 tokens/segundo com a mesma concorrência
• Resultado: vLLM oferece 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 solicitações simultâneas com a mesma memória

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

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

Esses benchmarks demonstram por que o vLLM se tornou o padrão de facto para serviço de LLM em produção onde o desempenho importa.

Análise de Custos

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

Cenário: Servindo 1M de solicitações/dia

Com Serviço Padrão:

• Necessário: 8x GPUs A100 (80GB)
• Custo AWS: ~$32/hora × 24 × 30 = $23.040/mês
• Custo por 1M tokens: ~$0.75

Com vLLM:

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

Esta vantagem de custo cresce com a escala. Organizações que servem bilhões de tokens mensalmente economizam centenas de milhares de dólares usando o serviço otimizado do vLLM 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 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 exposto diretamente à internet:

# Exemplo de NetworkPolicy 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 (Rate Limiting)

Implemente limitação de taxa para prevenir abuso:

# 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 a Modelos

Para implantações multi-inquilino, 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

Do OpenAI para o vLLM

Migrar do OpenAI para o vLLM auto-hospedado é simples graças à compatibilidade de 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": "Olá"}]
)

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": "Olá"}]
)

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

Do Ollama para o vLLM

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

API Ollama:

import requests

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

Equivalente 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 chamadas de API em toda a sua base de código, mas as bibliotecas de cliente OpenAI oferecem melhor tratamento de erros e recursos.

Do HuggingFace Transformers para o 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 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 e recursos emocionantes no roteiro:

Serviço Desagregado: Separar pré-processamento (processamento de prompt) e decodificação (geração de token) em GPUs diferentes para otimizar a utilização de recursos. O pré-processamento é limitado por computação, enquanto a decodificação é limitada 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) através de múltiplas máquinas, permitindo servir modelos muito grandes para configurações de nó único.

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

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

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

Melhor Cobertura de Modelos: Expansão do suporte para modelos multimodais (modelos visão-linguagem), modelos de áudio e arquiteturas especializadas à medida que surgem.

O projeto vLLM mantém desenvolvimento ativo com contribuições da UC Berkeley, Anyscale e da comunidade de código aberto mais ampla. À medida que a implantação de LLM se torna mais crítica para sistemas em 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 de LLM locais e em nuvem, consulte nosso LLM Hosting: Infraestrutura Local, Auto-hospedada e Nuvem Comparadas.

Links Úteis

Artigos Relacionados neste Site

• Hospedagem Local de LLM: Guia Completo 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 maturidade de API, suporte a chamada de ferramentas, compatibilidade GGUF e benchmarks de desempenho para ajudar a escolher a solução certa.

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

• Início Rápido llama.cpp com CLI e Servidor - Inferência C/C++ leve para modelos GGUF com llama-cli e llama-server compatível com OpenAI. Ideal quando você precisa de controle granular, implantação offline ou uma pilha mínima sem Python.

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

• Guia Rápido Docker Model Runner: Comandos & Exemplos - Guia rápido 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 serviço de LLM do vLLM.

Recursos Externos e Documentação

• Repositório GitHub 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 se manter atualizado com os últimos recursos e solucionar problemas.

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

• Artigo PagedAttention - Artigo acadêmico introduzindo 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 vLLM - Blog oficial do vLLM com anúncios de lançamentos, benchmarks de desempenho, mergulhos técnicos e estudos de caso da comunidade de implantações em produção.

• HuggingFace Model Hub - Repositório abrangente de LLMs de código aberto que funcionam com 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 Ray Serve - Documentação do framework Ray Serve para construir implantações de vLLM escaláveis e distribuídas. O Ray oferece recursos avançados como auto-escalamento, serviço multi-modelo e gerenciamento de recursos para sistemas em produção.

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

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