Início Rápido do vLLM: Servimento de LLMs de Alto Desempenho – em 2026
Inferência rápida de LLMs com a API da OpenAI
vLLM é um motor de inferência e serviço de alto rendimento e eficiente em memória para Modelos de Linguagem Grandes (LLMs), desenvolvido pelo Laboratório Sky Computing da UC Berkeley.
Com seu algoritmo revolucionário PagedAttention, o vLLM alcança um rendimento 14 a 24 vezes maior do que os métodos de serviço tradicionais, tornando-se a escolha padrão para implantações de LLMs em produção. Para ver como o vLLM se encaixa entre Ollama, Docker Model Runner, LocalAI e provedores em nuvem — incluindo compromissos entre custo e infraestrutura — veja Hospedagem de LLM: Infraestrutura Local, Auto-Hospedada e em Nuvem Comparada.

O que é o vLLM?
O vLLM (virtual LLM) é uma biblioteca de código aberto para inferência e serviço rápidos de LLMs que se tornou rapidamente o padrão da indústria para implantações em produção. Lançado em 2023, ele introduziu o PagedAttention, uma técnica groundbreaking de gerenciamento de memória que melhora drasticamente a eficiência do serviço.
Principais Recursos
Desempenho de Alto Rendimento: O vLLM oferece um rendimento 14 a 24 vezes maior em comparação com o HuggingFace Transformers usando o mesmo hardware. Esse ganho massivo de desempenho vem do loteamento contínuo (continuous batching), kernels CUDA otimizados e do algoritmo PagedAttention que elimina a fragmentação de memória.
Compatibilidade com a API da OpenAI: O vLLM inclui um servidor de API incorporado totalmente compatível com o formato da OpenAI. Isso permite uma migração sem emendas da 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 contíguos de memória para os 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 (Continuous Batching): Diferente do loteamento estático, onde se 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 entre várias 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 populares de modelos, incluindo LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma e muitas outras. Suporta tanto modelos ajustados por instruções quanto modelos base 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 a muitos usuários concorrentes 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 se beneficiam de sua capacidade de processar 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 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 rendimento 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 4x do PagedAttention também permite o uso de instâncias de GPU menores e mais baratas.
Implantações em Kubernetes: O design sem estado (stateless) e a arquitetura amigável a contêineres do vLLM o tornam ideal para clusters Kubernetes. Seu desempenho consistente sob carga e o gerenciamento de recursos direto se integram bem com a infraestrutura cloud-native.
Quando NÃO Usar o vLLM: Para desenvolvimento local, experimentação ou cenários de usuário único, ferramentas como Ollama ou llama.cpp proporcionam uma melhor experiência do 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 esses 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 novo
Instalação via pip
O método de instalação mais simples é usar o pip. Isso funciona em sistemas com CUDA 11.8 ou mais novo:
# 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 diferentes versões do CUDA, instale a roda (wheel) 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
O flag --ipc=host é importante para configurações multi-GPU, pois habilita a comunicação adequada entre processos.
Compilação do Código Fonte
Para os recursos 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 Rápido de Início 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 estiver em execução, você pode fazer solicitações usando o cliente Python da OpenAI ou o curl:
Usando curl:
curl http://localhost:8000/v1/completions \
-H "Content-Type: application/json" \
-d '{
"model": "mistralai/Mistral-7B-Instruct-v0.2",
"prompt": "Explain what vLLM is in one sentence:",
"max_tokens": 100,
"temperature": 0.7
}'
Usando o Cliente Python da 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 Conclusões de Chat:
response = client.chat.completions.create(
model="mistralai/Mistral-7B-Instruct-v0.2",
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "What is PagedAttention?"}
],
max_tokens=200
)
print(response.choices[0].message.content)
Configuração Avançada
O vLLM oferece inúmeros 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 tensor
--dtype float16 \ # Use precisão FP16
--max-num-seqs 256 # Tamanho máximo do lote
Explicação dos Parâmetros Principais:
--gpu-memory-utilization: Quanta memória da GPU usar (0.90 = 90%). Valores maiores 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 é o ótimo.--max-num-seqs: Número máximo de sequências para processar em um lote.
vLLM vs Ollama
O vLLM é projetado para serviço em produção de alto rendimento e multiusuário com loteamento contínuo, PagedAttention e suporte multi-GPU. O Ollama otimiza para configuração local rápida, conveniência para usuário único e gerenciamento simples de modelos.
Para um guia de decisão detalhado cobrindo sinais de migração, etapas de planejamento, configuração Docker Compose e uma lista de verificação prática, veja Do Ollama para vLLM: Quando Migrar Seu Servidor Local de LLM.
vLLM vs Docker Model Runner
O Docker introduziu recentemente o Model Runner (antigo GenAI Stack) como sua solução oficial para implantação local de modelos de IA. Como ele se compara ao vLLM?
Filosofia de Arquitetura
O 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.
O vLLM é um motor de inferência especializado focado exclusivamente no serviço de LLMs com desempenho máximo. É uma ferramenta de baixo nível que você contêineriza com o Docker, em vez de uma plataforma completa.
Configuração e Início
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 trabalho de imagens do Docker o torna instantaneamente familiar para desenvolvedores que já usam contêineres.
O 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 <nome-do-modelo>
Características de Desempenho
O vLLM oferece rendimento superior para cenários multiusuário devido ao PagedAttention e ao loteamento contínuo. Para serviços de API em produção que processam centenas de solicitações por segundo, as otimizações do vLLM fornecem 2 a 5 vezes melhor rendimento do que abordagens genéricas de serviço.
O Docker Model Runner foca na facilidade de uso em vez do desempenho máximo. É adequado para desenvolvimento local, testes e cargas de trabalho moderadas, mas não implementa as otimizações avançadas que fazem o vLLM se destacar em escala.
Suporte a Modelos
O Docker Model Runner fornece uma biblioteca curada de modelos com acesso em 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.
O vLLM se especializa em inferência de LLMs 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
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 fato para o serviço de LLMs em produção.
O Docker Model Runner é mais novo e se posiciona mais para cenários de desenvolvimento e testes locais. Embora possa servir tráfego de produção, falta-lhe o histórico comprovado e as otimizações de desempenho que as implantações em produção exigem.
Ecossistema de Integração
O vLLM integra-se com ferramentas de infraestrutura de produção: operadores Kubernetes, métricas Prometheus, Ray para serviço distribuído e extensa compatibilidade com a API da OpenAI para aplicações existentes.
O Docker Model Runner integra-se naturalmente com o ecossistema do Docker e o Docker Desktop. Para equipes já padronizadas no Docker, essa integração fornece uma experiência coesa, mas com menos recursos especializados de serviço de LLMs.
Quando Usar Cada Um
Use o vLLM para:
- Serviços de API de LLM em produção
- Implantações de alto rendimento e multiusuário
- Implantações em nuvem sensíveis a custos necessitando máxima eficiência
- Ambientes Kubernetes e cloud-native
- Quando você precisa de escalabilidade e desempenho comprovados
Use o Docker Model Runner para:
- Desenvolvimento e testes locais
- Execução de 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 localmente com o Docker Model Runner por conveniência e, em seguida, implamtam com o vLLM em produção pelo 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 de 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 em 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
# Obtenha as métricas
metrics = requests.get("http://localhost:8000/metrics").text
print(metrics)
Métricas principais para monitorar:
vllm:num_requests_running- Solicitações ativasvllm:gpu_cache_usage_perc- Utilização do cache KVvllm:time_to_first_token- Métrica de latênciavllm:time_per_output_token- Velocidade de geração
Ajuste de Desempenho
Otimize a Utilização da Memória da GPU: Comece com --gpu-memory-utilization 0.90 e ajuste com base no comportamento observado. Valores maiores permitem lotes maiores, mas correm o risco de erros OOM (Out of Memory) durante picos de tráfego.
Ajuste o Comprimento Máximo da Sequência: Se seu caso de uso não precisar do comprimento completo do contexto, reduza --max-model-len. Isso libera memória para lotes maiores. Por exemplo, se você precisar apenas de contexto de 4K, defina --max-model-len 4096 em vez de usar o máximo do modelo (frequentemente 8K-32K).
Escolha a Quantização Adequada: Para modelos que suportam, use versões quantizadas (8 bits, 4 bits) para reduzir a memória e aumentar o rendimento:
--quantization awq # Para modelos quantizados AWQ
--quantization gptq # Para modelos quantizados GPTQ
Habilite o 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 o 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
Sintomas: O servidor cai com erros de memória insuficiente do CUDA.
Soluções:
- Reduza
--gpu-memory-utilizationpara 0.85 ou 0.80 - Diminua
--max-model-lense seu caso de uso permitir - Reduza
--max-num-seqspara diminuir o tamanho do lote - Use uma versão quantizada do modelo
- Habilite o paralelismo de tensor para distribuir entre mais GPUs
Em um único cartão de 16 GB, a maioria desses erros OOM é atribuída ao orçamento do cache KV em vez de apenas aos pesos — Cache KV em GPUs de 16 GB cobre a fórmula exata, o tipo de dado FP8 do cache KV e os compromissos do cache de prefixo por trás de --max-model-len e --max-num-seqs antes de recorrer a um modelo menor.
Baixo Rendimento
Sintomas: O servidor processa menos solicitações do que o esperado.
Soluções:
- Aumente
--max-num-seqspara permitir lotes maiores - Aumente
--gpu-memory-utilizationse você tiver folga - Verifique se a CPU não é o gargalo com
htop– considere CPUs mais rápidas - Verifique a utilização da GPU com
nvidia-smi– deve ser 95%+ - Habilite FP16 se estiver usando FP32:
--dtype float16
Tempo Lento do Primeiro Token
Sintomas: Alta latência antes do início da geração.
Soluções:
- Use modelos menores para aplicações críticas em latência
- Habilite o cache de prefixo para prompts repetidos
- Reduza
--max-num-seqspara priorizar latência sobre rendimento - Considere decodificação especulativa para modelos suportados
- Otimize a configuração de paralelismo de tensor
Falhas na Carregamento do 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 com o HuggingFace Hub
- Certifique-se de espaço em disco suficiente em
~/.cache/huggingface - Para modelos restritos (gated), defina a variável de ambiente
HF_TOKEN - Tente baixar manualmente com
huggingface-cli download <modelo>
Recursos Avançados
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 a 2x. Para um guia abrangente sobre métodos de decodificação especulativa — modelos de rascunho, EAGLE-3, P-EAGLE e n-gram — veja Decodificação Especulativa: Inferência Mais Rápida sem Perda de Qualidade.
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 vários 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
Então especifique qual adaptador usar por solicitação:
response = client.completions.create(
model="sql-lora", # Use o adaptador SQL
prompt="Convert this to SQL: Show me all users created this month"
)
Serviço Multi-LoRA
O serviço multi-LoRA do vLLM permite hospedar dezenas de adaptadores refinados com sobrecarga de memória mínima. Isso é ideal para servir variantes de modelos específicas do cliente ou da tarefa:
# Solicitação com adaptador LoRA específico
response = client.chat.completions.create(
model="meta-llama/Llama-2-7b-hf",
messages=[{"role": "user", "content": "Write SQL query"}],
extra_body={"lora_name": "sql-lora"}
)
Cache de Prefixo
Habilite o cache de prefixo automático para evitar recalcular o 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 de poucos exemplos (few-shot) repetidos entre 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("Explain PagedAttention in simple terms")
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("What is 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 concorrentes
- HuggingFace Transformers: ~250 tokens/segundo com a mesma concorrência
- Ollama: ~1.200 tokens/segundo com a 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 concorrentes
- vLLM com PagedAttention: 24GB VRAM, 128 sequências concorrentes
- Resultado: 4x mais solicitações concorrentes com a mesma memória
Latência Sob Carga (Mixtral-8x7B em 2xA100):
- vLLM: Latência P50 de 180ms, latência P99 de 420ms a 100 req/s
- Serviço padrão: Latência P50 de 650ms, latência P99 de 3.200ms a 100 req/s
- Resultado: O vLLM mantém latência consistente sob alta carga
Esses benchmarks demonstram por que o vLLM se tornou o padrão de fato para o serviço de LLMs em produção onde o desempenho é importante.
Análise de Custos
Compreender as implicações de custo da escolha do 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 de tokens: ~$0,75
Com vLLM:
- Necessário: 2x GPUs A100 (80GB)
- Custo AWS: ~$8/hora × 24 × 30 = $5.760/mês
- Custo por 1M de tokens: ~$0,19
- Economias: $17.280/mês (redução de 75%)
Essa 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 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 (Rate Limiting)
Implemente limitação de taxa para evitar 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
Da OpenAI para o vLLM
Migrar da OpenAI para o vLLM auto-hospedado é direto 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": "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 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. A mudança básica do lado do cliente é alternar do endpoint REST do Ollama para a API compatível com OpenAI do vLLM:
API do Ollama:
import requests
response = requests.post('http://localhost:11434/api/generate',
json={'model': 'llama2', 'prompt': 'Why is the sky blue?'})
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="Why is the sky blue?"
)
Para um guia de migração abrangente cobrindo seleção de modelos, modelos de chat, migração em estágios e uma lista de verificação prática, veja Do Ollama para vLLM: Quando Migrar Seu Servidor Local de LLM.
Dos HuggingFace Transformers para o vLLM
Migração direta de uso 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.
Futuro do vLLM
O vLLM continua um desenvolvimento rápido com recursos emocionantes no roadmap:
Serviço Desagregado: Separando o pré-preenchimento (processamento de prompt) e a decodificação (geração de tokens) em GPUs diferentes para otimizar a utilização de recursos. O pré-preenchimento é 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) entre várias máquinas, habilitando o serviço de modelos grandes demais para configurações de nó único.
Quantização Aprimorada: Suporte para novos formatos de quantização como GGUF (usado pelo llama.cpp) e integração aprimorada de AWQ/GPTQ para melhor desempenho com modelos quantizados.
Melhorias na Decodificação Especulativa: Modelos de rascunho mais eficientes e estratégias de especulação adaptativa 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.
Cobertura Melhorada de Modelos: Expansão do suporte para modelos multimodais (modelos visão-linguagem), modelos de áudio e arquiteturas especializadas à medida que surgirem.
O projeto vLLM mantém um desenvolvimento ativo com contribuições da UC Berkeley, Anyscale e a comunidade open-source mais ampla. À medida que a implantação de LLMs 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 de LLM locais e em nuvem, confira nosso Hospedagem de LLM: Infraestrutura Local, Auto-Hospedada e em Nuvem Comparada.
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 do Ollama, LocalAI, Jan, LM Studio e outros. Cobre maturidade de API, suporte a chamada de ferramentas, compatibilidade GGUF e benchmarks de desempenho para ajudar a escolher a solução certa.
-
Folha de Dicas do Ollama - Referência completa de comandos e folha de dicas do Ollama cobrindo instalação, gerenciamento de modelos, uso de API e melhores práticas para implantação local de LLM. Essencial para desenvolvedores usando Ollama ao lado ou em vez do vLLM.
-
Início Rápido do llama.cpp com CLI e Servidor - Inferência leve C/C++ para modelos GGUF com llama-cli e servidor llama-server compatível com OpenAI. Ideal quando você precisa de controle fino, 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 do Ollama para implantação local de LLM, analisando desempenho, suporte a GPU, compatibilidade de API e casos de uso. Ajuda a entender o cenário competitivo em que o vLLM opera.
-
Folha de Dicas do Docker Model Runner: Comandos & Exemplos - Folha de dicas prática do Docker Model Runner com comandos e exemplos para implantação de modelos de IA. Útil para equipes comparando a abordagem do Docker com as capacidades especializadas de serviço de 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 comunitárias ativas. Recurso essencial para se manter atualizado com os recursos mais recentes e solucionar problemas.
-
Documentação do vLLM - Documentação oficial cobrindo todos os aspectos do vLLM, desde a configuração básica até a configuração avançada. Inclui referências de API, guias de ajuste de desempenho e melhores práticas de implantação.
-
Papel PagedAttention - Papel 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çamentos, 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 LLMs de código aberto que funcionam 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 recursos avançados como auto-escalabilidade, serviço multi-modelo e gerenciamento de recursos para sistemas de 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 da API OpenAI - Documentação oficial da API OpenAI com a qual a API do vLLM é compatível. Consulte isto ao construir aplicações que precisam funcionar tanto com endpoints OpenAI quanto com vLLM auto-hospedados alternadamente.