Phase 17 - Lesson 28

Escolha de Mecanismo de Serviço Local (Self-Hosted) — llama.cpp, Ollama, TGI, vLLM, SGLang

Quatro mecanismos dominam a inferência local (self-hosted) em 2026. Escolha com base no hardware, na escala e no ecossistema. O llama.cpp é o mais rápido em CPU — suporte mais amplo a modelos, controle total sobre quantização e threading. O Ollama é a instalação de um único comando para notebooks de desenvolvedores, sendo ~15-30% mais lento que o llama.cpp (Go + CGo + serialização HTTP), com uma diferença de 3x no throughput sob cargas parecidas com produção. O TGI entrou em modo de manutenção em 11 de dezembro de 2025 — apenas correções de bugs, throughput bruto ~10% mais lento que o vLLM, mas historicamente com excelente observabilidade e integração com o ecossistema Hugging Face. Esse estado de manutenção o torna uma aposta arriscada no longo prazo — SGLang ou vLLM são padrões mais seguros para novos projetos. O vLLM é o padrão de produção para uso geral — a versão v0.15.1 (fevereiro de 2026) adiciona PyTorch 2.10, suporte à arquitetura RTX Blackwell SM120 e otimização para H200. O SGLang é o especialista em múltiplos turnos de agentes e reutilização de prefixo (prefix-heavy) — mais de 400.000 GPUs em produção (xAI, LinkedIn, Cursor, Oracle, GCP, Azure, AWS). Restrições de hardware: apenas CPU → apenas llama.cpp. AMD / não-NVIDIA → apenas vLLM (TRT-LLM é restrito a NVIDIA). Padrão de pipeline de 2026: dev = Ollama, staging = llama.cpp, prod = vLLM ou SGLang. Mesmos pesos GGUF/HF em todo o processo.

Tipo: Learn Linguagens: Python (stdlib, interpretador de árvore de decisão de mecanismos) Pré-requisitos: Todas as lições da Fase 17 que cobrem mecanismos (04, 06, 07, 09, 18) Tempo: ~45 minutos

Objetivos de Aprendizado

• Escolher um mecanismo com base no hardware (CPU / AMD / NVIDIA Hopper / Blackwell), escala (1 usuário / 100 / 10.000) e carga de trabalho (chat geral / agente / contexto longo).
• Apontar o estado de modo de manutenção do TGI em 2026 (11 de dezembro de 2025) e por que isso direciona novos projetos para o vLLM ou SGLang.
• Descrever o pipeline de dev/staging/prod usando os mesmos pesos GGUF ou HF em todo o processo.
• Explicar por que "apenas CPU" força o uso do llama.cpp e "AMD" exclui o TRT-LLM.

O Problema

Sua equipe está iniciando um novo projeto de LLM local (self-hosted). Um engenheiro diz Ollama, outro diz vLLM e um terceiro diz "o TGI não funciona direto de fábrica?". Todos os três estão certos para contextos diferentes. Nenhum está certo para todos os casos.

Em 2026, a árvore de escolha é o que importa: hardware primeiro, escala em segundo, carga de trabalho em terceiro. E um evento específico de 2025 — o TGI entrando em modo de manutenção em 11 de dezembro — muda o padrão para novos projetos.

O Conceito

Os cinco mecanismos

Decisão de hardware em primeiro lugar

Apenas CPU → llama.cpp. O Ollama também funciona, mas é mais lento. Nenhum outro mecanismo é competitivo em CPU.

GPU AMD → vLLM (suporte a AMD ROCm). O SGLang também funciona. O TRT-LLM é exclusivo para NVIDIA, então está fora.

NVIDIA Hopper (H100 / H200) → vLLM, SGLang ou TRT-LLM. Todos os três são de primeira linha.

NVIDIA Blackwell (B200 / GB200) → TRT-LLM é o líder em throughput (Fase 17 · 07). vLLM e SGLang o seguem de perto.

Apple Silicon (M-series) → llama.cpp (Metal). O Ollama envelopa essa implementação.

Decisão de escala em segundo lugar

1 usuário / desenvolvimento local → Ollama. Um único comando, primeiro token em segundos.

10-100 usuários / equipe pequena → vLLM com única GPU.

100-10k usuários / produção → stack de produção do vLLM (Fase 17 · 18) ou SGLang.

Mais de 10k usuários / corporativo (enterprise) → stack de produção do vLLM + desmembrada (Fase 17 · 17) + LMCache (Fase 17 · 18).

Decisão de carga de trabalho em terceiro lugar

Chat geral / Perguntas e Respostas → o vLLM vence como padrão amplo.

Vários turnos de agentes (ferramentas, planejamento, memória) → o RadixAttention do SGLang (Fase 17 · 06) domina.

RAG com forte reutilização de prefixo → SGLang.

Geração de código → vLLM atende bem; SGLang é ligeiramente melhor no cache.

Contexto longo (128K+) → vLLM + preenchimento em blocos (chunked prefill); SGLang + KV em camadas (tiered KV).

A armadilha de manutenção do TGI

O TGI da Hugging Face entrou em modo de manutenção em 11 de dezembro de 2025 — apenas correções de bugs daqui para frente. Historicamente: observabilidade de alto nível, excelente integração com o ecossistema HF (model cards, ferramentas de segurança), mas ligeiramente atrás do vLLM em throughput bruto.

Para novos projetos em 2026: evite escolher o TGI por padrão. Implantações existentes do TGI podem continuar, mas devem ser migradas eventualmente. SGLang e vLLM são as opções padrão mais seguras.

O padrão de pipeline

Dev (Ollama) → staging (llama.cpp) → prod (vLLM). Mesmos pesos GGUF ou HF em todo o fluxo. Os engenheiros iteram rapidamente em seus laptops; a fase de staging reflete a quantização da produção; prod é o alvo do serviço.

Ressalva sobre o Ollama

O Ollama é ótimo para desenvolvimento. Não é bom para produção compartilhada: a serialização HTTP do Go adiciona overhead, o gerenciamento de concorrência é mais simples do que no vLLM, e o suporte a OpenTelemetry fica para trás. Use o Ollama onde ele se destaca — um usuário, um comando — e mude para o vLLM para ambientes compartilhados.

Escolha local (self-hosted) vs gerenciado é uma decisão à parte

A Fase 17 · 01 (provedores de nuvem gerenciados) e 17 · 02 (plataformas de inferência) cobrem soluções gerenciadas. Esta lição pressupõe que você já decidiu hospedar localmente. Motivos para hospedar localmente: soberania/residência dos dados, ajuste fino personalizado (fine-tuning), custo total de propriedade (TCO) em escala, ou modelo de domínio indisponível em serviços hospedados.

Números que você deve lembrar

• Modo de manutenção do TGI: 11 de dezembro de 2025.
• vLLM v0.15.1: fevereiro de 2026; PyTorch 2.10; suporte à Blackwell SM120.
• Presença em produção do SGLang: mais de 400.000 GPUs.
• Diferença de throughput do Ollama vs llama.cpp: 15-30% mais lento; 3x sob carga de produção.

Use It

O arquivo code/main.py percorre uma árvore de decisão: dados o hardware, a escala e a carga de trabalho, escolhe um mecanismo e explica o porquê.

Ship It

Esta lição produz outputs/skill-engine-picker.md. Dadas as restrições, escolhe um mecanismo e escreve o plano de migração.

Exercícios

1. Execute code/main.py com seu hardware / escala / carga de trabalho. A resposta condiz com a sua intuição?
2. Sua infraestrutura possui 12 H100s e 8 MI300X AMD. Qual mecanismo utilizar? Por que o TRT-LLM está fora de cogitação?
3. Uma equipe quer usar o TGI em 2026 porque "é o que conhecemos". Defenda os argumentos para a migração.
4. Passando de Ollama em desenvolvimento para vLLM em produção: o que muda em termos de quantização, configuração e observabilidade?
5. Produto RAG com comprimento de prefixo P99 de 8K e alta reutilização entre inquilinos. Escolha um mecanismo e combine-o com as Fases 17 · 11 + 18.

Termos-Chave

Leituras Recomendadas