vLLM ou Ollama: qual usar para servir modelos para a equipe

vLLM ou Ollama: qual usar para servir modelos para a equipe

Para uma pessoa, ou para poucos usuários que não pedem respostas ao mesmo tempo, o Ollama costuma ser a escolha certa: instala rápido, roda em máquinas variadas e exige pouca manutenção. Quando várias pessoas ou vários agentes usam o mesmo modelo simultaneamente, o vLLM tende a servir melhor, porque foi pensado para atender requisições concorrentes em GPU. E, se o volume é baixo ou irregular, a API de um provedor ainda pode ser mais simples, mais segura e mais barata de operar.

Principais pontos

• Ollama prioriza facilidade: um comando baixa e executa o modelo, em notebook, desktop ou servidor pequeno. É ótimo para uso individual, testes e protótipos.
• vLLM prioriza vazão: foi desenhado para servidor de inferência com GPU dedicada, com agrupamento contínuo de requisições e API compatível com o formato da OpenAI.
• O critério que mais separa os dois é a concorrência: quantas pessoas ou agentes pedem respostas ao mesmo tempo, e por quanto tempo cada pedido precisa esperar.
• Servir modelo próprio troca custo por requisição por responsabilidade operacional: atualização, monitoramento, segurança, capacidade e plantão.
• Para volume baixo, picos raros ou tarefas que exigem o melhor modelo disponível, a API continua sendo a opção mais racional.

Qual é a diferença real entre vLLM e Ollama?

Os dois expõem um modelo de linguagem por uma API HTTP que seus sistemas podem chamar. A diferença está no que cada um otimiza.

O Ollama é uma ferramenta de execução local com foco em simplicidade. Ele cuida de baixar o modelo, carregar na memória e responder. Funciona bem em máquinas com GPU, em computadores com memória unificada e até só com CPU, com desempenho bem menor. Quem quiser ver o que ele oferece e como se configura deve consultar o repositório oficial do Ollama. Para um passo a passo de adoção sem improviso, temos o texto Ollama na empresa: como rodar um modelo local sem improvisar.

O vLLM é um motor de inferência e servidor pensado para atender muitas requisições ao mesmo tempo com bom aproveitamento de GPU. A documentação do vLLM descreve as técnicas de agrupamento e gerenciamento de memória que sustentam isso. Em troca, ele pede um ambiente mais controlado: GPU compatível, drivers corretos, versões alinhadas e alguém que entenda os parâmetros de memória e de contexto.

Resumindo: Ollama reduz o atrito para começar. vLLM reduz o custo por resposta quando há muita gente usando ao mesmo tempo.

Uso individual: quando o Ollama basta

Um desenvolvedor testando um modelo, uma analista resumindo documentos internos ou um pequeno grupo que usa a ferramenta em momentos diferentes têm um perfil parecido: poucas requisições simultâneas, tolerância a esperar alguns segundos e vontade de começar logo.

Nesse perfil, o Ollama tem vantagens práticas:

• instalação e troca de modelos simples, o que ajuda a comparar opções rapidamente;
• funciona em hardware que a empresa já tem, sem compra dedicada;
• manutenção leve, quase sem configuração de servidor;
• boa porta de entrada para testar se um modelo menor resolve a tarefa (veja modelos pequenos de IA na empresa).

O risco está em deixar o que nasceu como teste virar serviço de equipe sem perceber. Um Ollama no computador de alguém, acessível pela rede, sem autenticação e sem registro de uso, não é uma plataforma. É um ponto único de falha com dados da empresa passando por ele.

Uso concorrente em equipe: onde o vLLM se justifica

Quando o modelo passa a ser usado por uma equipe inteira, por um agente de atendimento ou por rotinas automáticas, o problema muda. Não importa só a velocidade de uma resposta, e sim o que acontece quando muitos pedidos chegam juntos.

O Ollama tem configurações para processar pedidos em paralelo e uma fila com limite, descritas em sua documentação. Elas ajudam em escala pequena, mas o paralelismo divide a mesma memória da GPU, e o contexto de cada conversa também ocupa memória. Passando de certo ponto, a latência sobe e pedidos podem ser recusados.

O vLLM foi construído em torno desse cenário: ele agrupa pedidos de forma contínua, gerencia a memória usada pelo histórico de cada conversa e permite configurar limites com mais controle. A hipótese de trabalho, que deve ser confirmada em teste com a sua carga, é que ele sustenta mais usuários simultâneos por GPU do que uma ferramenta pensada para uso local.

Sinais de que vale considerar vLLM:

• vários usuários ou agentes chamam o modelo nos mesmos horários;
• há fluxos automáticos, como classificação de mensagens ou extração de dados, que geram rajadas de requisições;
• a latência importa para a experiência, por exemplo em atendimento interativo;
• existe pessoa ou fornecedor capaz de operar um servidor com GPU de forma contínua.

Que hardware cada um pede?

O fator dominante é a memória da GPU. Ela precisa comportar os pesos do modelo e, além disso, o espaço que cada conversa em andamento consome. Quanto maior o contexto e maior o número de conversas simultâneas, mais memória é necessária. Para entender por que o tamanho do texto pesa tanto, vale ler sobre tokens e sobre janela de contexto.

Na prática:

• Ollama aceita uma gama maior de máquinas, inclusive computadores com memória unificada e modelos quantizados (compactados) que cabem em hardware modesto. A qualidade e a velocidade variam bastante conforme o modelo e a quantização.
• vLLM rende mais em servidor com GPU dedicada, sobretudo NVIDIA, e exige que o conjunto de driver, biblioteca e versão do motor esteja compatível. Verifique na documentação oficial o suporte ao seu hardware antes de comprar qualquer coisa.
• Modelos maiores ou contextos longos podem exigir mais de uma GPU, o que adiciona complexidade de configuração.

Um erro comum é dimensionar pelo tamanho do modelo e esquecer a concorrência. O modelo cabe na placa, mas com três conversas longas ao mesmo tempo a memória acaba. Dimensione sempre pelo pior caso razoável, não pela média.

Filas, latência e manutenção: o que muda no dia a dia

Fila é inevitável em qualquer servidor próprio. A pergunta é como ela é tratada.

O que definir antes de abrir o serviço para a equipe:

• Limite de espera: depois de quanto tempo um pedido desiste e o usuário recebe uma mensagem clara.
• Prioridade: atendimento a cliente passa na frente de resumo de documento?
• Limite por usuário ou por aplicação, para que uma rotina automática não ocupe tudo.
• Tamanho máximo de entrada e de saída, para evitar que um único pedido monopolize a GPU.
• Comportamento em falha: o que o sistema faz se o servidor cair (tentar de novo, usar outro modelo, encaminhar para uma pessoa).

Sobre manutenção, a conta que costuma ser esquecida é esta: servidor próprio exige atualização de motor e de modelo, correção de segurança, controle de acesso, monitoramento de uso de GPU, de latência e de erros, e alguém para atender quando algo para. A introdução à observabilidade do OpenTelemetry é um bom ponto de partida para decidir quais métricas, logs e rastros coletar. Sobre quem pode chamar o quê, o guia de autorização da OWASP lembra princípios que valem também para uma API de modelo interna.

O Ollama costuma cobrar menos nessa frente enquanto o uso é pequeno. O vLLM cobra mais no início, mas oferece mais controle quando o uso cresce. Nenhum dos dois traz, sozinho, autenticação robusta, auditoria e política de retenção de logs: isso fica por sua conta, normalmente com um proxy ou gateway na frente.

Quando a API ainda é melhor?

Servir modelo próprio é atraente por privacidade, previsibilidade e controle. Mas há casos em que a API de um provedor continua sendo a melhor decisão:

• O volume é baixo ou irregular: uma GPU parada a maior parte do tempo custa mais em manutenção e atenção do que em requisições.
• A tarefa exige o melhor modelo disponível, por exemplo raciocínio complexo, código ou análise longa, e os modelos abertos que cabem no seu hardware ficam aquém nos seus testes.
• Não há quem opere: sem responsável por atualização, monitoramento e plantão, o serviço degrada em silêncio.
• Os picos são fortes e imprevisíveis, como em datas sazonais, e a capacidade elástica de um provedor absorve melhor do que uma GPU fixa (veja como preparar o atendimento para picos de demanda).

O argumento de privacidade merece cuidado. Rodar localmente evita enviar dados a terceiros, o que simplifica algumas questões, mas não elimina as obrigações da LGPD: finalidade, minimização, controle de acesso e registro continuam valendo. Se a opção for API, o texto sobre transferência internacional de dados com IA e LGPD mostra o que verificar. Em muitos casos, a resposta é híbrida: dados sensíveis e tarefas simples em modelo próprio, tarefas difíceis e de baixo risco em API.

Como decidir: roteiro em cinco passos

Este roteiro segue a lógica de mapear, limitar, pilotar e transferir. Primeiro se entende o uso real, depois se restringem dados e ações, testa-se um fluxo de verdade com registro e métrica combinada, e só então se decide expandir, ajustar ou parar.

• Mapear: liste quem vai usar, para quê, em quais horários e com que tamanho de texto. Registre quantos pedidos podem chegar ao mesmo tempo no pior momento razoável.
• Limitar: defina quais dados podem passar pelo modelo, quais ações ele pode disparar e quem tem acesso. Comece por um fluxo, não pela empresa toda.
• Pilotar com Ollama ou com API: use a opção mais simples para validar se o modelo escolhido resolve a tarefa com qualidade aceitável, com um conjunto fixo de exemplos para comparar. A medição de um piloto de automação detalha métricas e critérios de decisão.
• Testar a concorrência: simule a carga do pior horário contra Ollama e vLLM no hardware que você pretende usar. Meça tempo de espera, taxa de erro e qualidade das respostas sob carga.
• Transferir: documente a operação (quem atualiza, quem monitora, o que fazer em falha), entregue ao responsável e decida com base nos dados se expande, ajusta ou encerra.

Cenário ilustrativo: uma empresa de serviços quer um assistente interno para resumir contratos e responder dúvidas sobre procedimentos. No começo, duas analistas testam o Ollama em uma máquina com GPU, em horários diferentes, e a experiência é boa. Quando o assistente passa a ser usado pelo time inteiro e por uma rotina que classifica documentos de manhã, aparecem esperas longas e erros por falta de memória. O piloto de concorrência mostra que o gargalo é a carga do início do dia. A empresa então compara três caminhos: migrar para vLLM em servidor dedicado, manter o Ollama só para uso individual e mandar a rotina em lote para uma API, ou usar API para tudo. A decisão depende de quem vai operar o servidor e do nível de qualidade que os modelos abertos alcançaram nos exemplos de teste, não de preferência por uma ferramenta.

Cuidados de segurança que valem para os dois

Seja qual for a ferramenta, algumas práticas pesam mais do que a escolha entre elas:

• Não exponha a porta do servidor diretamente à internet. Coloque autenticação e limite de taxa na frente.
• Registre quem chamou, quando e com qual finalidade, evitando guardar conteúdo sensível desnecessário nos logs.
• Trate entradas externas como não confiáveis. Se o modelo lê e-mails ou páginas, há risco de injeção de instruções, tema coberto pelo Top 10 da OWASP para aplicações com LLM.
• Limite as ações que um agente pode executar com base na resposta do modelo, com aprovação humana para o que for irreversível.
• Defina quem responde se algo der errado, antes de dar errado.

Perguntas frequentes

O Ollama aguenta uma equipe inteira? Pode aguentar uma equipe pequena com uso espaçado, desde que o hardware tenha memória suficiente e haja limites de fila e de contexto. Se a equipe usa ao mesmo tempo, ou se há automações gerando rajadas, teste a carga real antes de prometer o serviço. Se a latência subir demais, é o sinal para avaliar vLLM ou API.

O vLLM é sempre mais rápido que o Ollama? Não necessariamente. Para uma única requisição por vez, a diferença pode ser pequena ou até favorecer o Ollama, dependendo do modelo e da máquina. A vantagem do vLLM aparece principalmente com muitas requisições simultâneas, por isso o teste deve reproduzir a sua carga e não um uso isolado.

Rodar modelo próprio resolve a LGPD? Não resolve sozinho. Manter os dados dentro da sua infraestrutura reduz o envio a terceiros, mas você continua precisando de finalidade clara, minimização, controle de acesso, registro e resposta a incidentes. Em caso de dúvida sobre base legal ou dados sensíveis, consulte o jurídico e as orientações da ANPD.

Quando faz mais sentido ficar com a API? Quando o volume é baixo ou irregular, quando a tarefa pede o melhor modelo disponível ou quando não existe uma pessoa responsável por operar o servidor. Nesses casos, o custo de manter GPU e plantão tende a superar o benefício. Uma arquitetura híbrida, com modelo próprio para o que é sensível e simples e API para o restante, costuma ser um bom ponto de equilíbrio.

Fontes

• vLLM: documentação oficial
• Ollama: repositório oficial
• OWASP: guia de autorização
• OpenTelemetry: conceitos de observabilidade