Ollama se tornou a resposta padrão quando alguém pergunta como administrar um LLM local, e por um bom motivo. É simples, multiplataforma e esconde detalhes feios o suficiente para passar do nada a um modelo funcional em minutos. llama.cpp também está em uma grande parte do mundo nativo da IA, especialmente se você estiver usando modelos GGUF, então nada disso desaparecerá.
O problema é que um simples botão não é mais suficiente quando o modelo nativo passa a fazer parte do fluxo de trabalho. Você começa a se preocupar com o serviço de API, o empacotamento, a saída estruturada, o cache, a aceleração específica do Mac, as implantações móveis ou se está deixando o desempenho silenciosamente na mesa. Ainda acho que Ollama é a maneira mais fácil de começar a administrar LLMs locais, mas não é onde quero ficar quando construir algo mais sério.
As alternativas são mais complicadas, mas permitem controlar as partes que Ollama tenta esconder. Se você estiver usando agentes, direcionando vários aplicativos para o mesmo modelo, trabalhando em um Mac ou tentando fazer com que uma GPU de consumidor atue como uma caixa de inferência adequada, o tempo de execução é tão importante quanto o modelo.
vLLM e SGLang traduzem modelos nativos em infraestrutura
Servir uma modelo é diferente de conversar com uma modelo
vLLM é a primeira ferramenta que eu usaria se você deseja que o modelo nativo funcione menos como um aplicativo de desktop e mais como um serviço de inferência. Possui um servidor API compatível com OpenAI, inferência de alto rendimento, lote contínuo, cache de prefixo, pré-preenchimento em partes, saídas estruturadas, chamadas de ferramentas e analisadores de argumentos e suporte para muitos formatos de quantização.
Esses recursos são importantes quando o modelo é chamado por ferramentas de codificação, agentes, experimentos RAG ou vários aplicativos simultaneamente. Um único prompt no terminal não requer muita lógica de agendamento, mas um endpoint local que é atingido repetidamente certamente exige. Especialmente se essas solicitações compartilham um contexto, são longas ou precisam evitar o desperdício de VRAM no gerenciamento de cache.
O recurso mais conhecido do vLLM é o PagedAttention, que gerencia o cache dos valores-chave do modelo com mais eficiência. O objetivo é evitar que a memória da GPU se torne um gargalo quando múltiplas solicitações estiverem ativas ou quando o contexto se tornar grande. Isso não tornará todas as configurações locais mais rápidas, mas é por isso que o vLLM é visto com tanta frequência na Internet, especialmente em implantações de maior rendimento.
SGLang cai na mesma categoria ampla, mas sua identidade está mais relacionada à geração estruturada, padrões repetitivos de prompt e cargas de trabalho no estilo de agente. Sua lista de recursos inclui RadixAttention para cache de prefixo, divisão de decodificação de pré-preenchimento, decodificação especulativa, empacotamento contínuo, atenção de página, pré-preenchimento parcial, paralelismo de especialista em tensor e empacotamento multi-LoRA.
A prosa de formato livre funciona bem em uma caixa de bate-papo, mas se torna um problema se o programa espera JSON, um esquema ou uma chamada de ferramenta em um formato específico. SGLang foi projetado para prompts repetidos, saídas limitadas e reutilização de cache, que são muito mais fáceis de cuidar quando o modelo usa as ferramentas em vez de apenas responder perguntas.
Eu não instalaria nenhuma dessas ferramentas antes de me familiarizar com as ferramentas mais simples, pois elas adicionam bastante trabalho de configuração e exigem algum conhecimento para serem usadas. No entanto, eles fazem mais sentido se você estiver usando outro software que espera um endpoint mais apropriado para a empresa. Se o seu LLM local se tornou a infraestrutura de back-end para o seu laboratório doméstico, o vLLM e o SGLang estão mais próximos da solução certa para o que você precisa.
vMLX fornece um aplicativo nativo mais sério para Mac
A Apple Silicon não precisa fingir que é CUDA
Os usuários de Mac sempre tiveram uma história nativa de LLM um pouco diferente. A memória unificada de silício da Apple torna os modelos grandes mais práticos do que você esperaria de um laptop, mas o conjunto de software não é o mesmo de uma caixa Linux com GPU Nvidia. Você pode executar llama.cpp com Metal e ele funciona bem, mas há bons motivos para construir ferramentas do zero com a pilha da Apple em mente.
vMLX é interessante porque pretende estar mais próximo da experiência de aplicativo que as pessoas desejam do Ollam ou do LM Studio, ao mesmo tempo que pega emprestadas ideias de pilhas de serviços mais sérias. A própria etapa chama o cache de prefixo, o cache KV paginado, a classificação persistente de pacotes e as ferramentas MCP. É muito diferente de “baixar uma modelo e conversar com ela” e por isso merece ser considerado mais do que simplesmente outro invólucro mac.
MLX é o sistema de array da Apple em Apple Silicon com computação lenta, gráficos dinâmicos, execução de CPU/GPU e um modelo de memória unificado onde os arrays residem em memória compartilhada. MLX-LM em seguida, oferece geração de texto, integração, quantização e refinamento do Hugging Face. MLX-VLM cobre padrões de linguagem visual na mesma pilha geral. vMLX é uma ferramenta de nível de aplicativo, enquanto MLX-LM e MLX-VLM são opções de nível inferior se você quiser trabalhar mais próximo do modelo. É certo que eu não descreveria nada disso como um substituto universal para vLLM ou SGLang, porque não é, mas ainda é uma ótima ferramenta para usar se você for um usuário de Mac.
O vMLX é melhor entendido como um caminho nativo do Mac através do mundo LLM nativo, em vez de uma ferramenta CUDA mapeada desajeitadamente para o Apple Silicon. O modelo de memória, a pilha de GPU e as expectativas do aplicativo são diferentes o suficiente para que ferramentas nativas como essa realmente ofereçam uma vantagem.
MLC-LLM e ExLlamaV3 visam problemas específicos de hardware
Telefones, navegadores e GPUs de consumo nem sempre precisam do mesmo tempo de execução
MLC-LLM baseia-se na agregação e implantação de aprendizado de máquina em todas as plataformas. Seu suporte inclui navegadores da web usando WebGPU e WASM, iOS e iPadOS usando GPUs Metal Apple série A e Android usando GPUs OpenCL Adreno e Mali.
O MLC desempenha uma função diferente do tempo de execução normal do servidor, embora possa expor APIs compatíveis com OpenAI. Ele foi projetado para mais casos de uso de nicho e WebLLM infere diretamente no navegador com aceleração WebGPU e sem servidor. Ele também oferece suporte a streaming, modo JSON e geração estruturada de JSON.
O MLC não é o que eu escolheria para atender um modelo grande em um laboratório doméstico com muitos aplicativos. Seu apelo está na implantação em locais que não se parecem com hosts LLM típicos: locais como navegadores, telefones, tablets e aplicativos incorporados. Ele se destina a uma classe completamente diferente de projetos de IA nativos do vLLM e SGLang.
ExLlamaV3 especializou-se em outra direção. É a versão atual da linha ExLlama, com ExLlamaV2 arquivado, e é essencialmente uma biblioteca de inferência construída especificamente para executar LLMs nativos nas GPUs de consumo atuais. As prioridades são ajustar o modelo, manter o contexto utilizável, evitar desperdício de VRAM e obter velocidade decente sem hardware corporativo.
Seu formato de quantização EXL3, inferência paralela de tensor e paralela de especialista para hardware de consumidor, empacotamento dinâmico contínuo, decodificação especulativa, quantização de cache, suporte multimodal e suporte LoRA são construídos para essa finalidade. TabbyAPI também fornece um servidor compatível com OpenAI, portanto ainda pode ser incorporado em aplicativos que esperam um endpoint nativo normal.
Há mais do que apenas Ollama e llama.cpp
Experimente algo mais especializado
Se você estiver implantando seus próprios LLMs locais, tanto o Ollama quanto o llama.cpp são bons para começar e até mesmo continuar. No entanto, se você quiser mais, existem todos os tipos de software que você pode experimentar e que podem ser mais adequados às suas necessidades. Por exemplo, MLC e ExLlamaV3 não resolvem o mesmo problema, mas ambos são mais especializados que Ollama. O MLC foi projetado para implantação em alvos inconvenientes. O ExLlamaV3 foi projetado para aproveitar ao máximo as GPUs de consumo. Elas não são as primeiras ferramentas que eu recomendaria para alguém que está começando, mas são importantes quando seu hardware ou objetivo de implantação começa a ditar o tempo de execução.
Depois, há o llama-swap, que faz parte do pacote de ferramentas de serviço de modelo llama.cpp e é útil se você estiver executando vários servidores locais compatíveis com OpenAI ou Anthropic e quiser criar uma camada de roteamento entre eles. Depois, há o TensorRT-LLM, que é o caminho otimizado da Nvidia para placas Nvidia, o LMDeploy é um verdadeiro kit de ferramentas de manutenção e implantação, o Lemonade é uma plataforma de serviço de modelo construída com a AMD em mente, o KTransformers lida com inferência heterogênea de CPU/GPU e o LocalAI cobre mais modalidades e alvos de hardware.
Ollama ainda é uma ferramenta que eu recomendaria a qualquer pessoa que quisesse apenas começar. llama.cpp ainda é básico, e descartá-lo como básico seria injusto, considerando o quanto ele pode fazer sozinho. Mas quando os modelos nativos se tornam parte de um fluxo de trabalho real, o tempo de execução não é mais apenas um trampolim. O servidor, o cache, o modelo de empacotamento, o caminho de quantização e o back-end da plataforma começam a decidir o que você pode realmente construir.
