Frameworks de serving de LLM: como escolher um runtime?
Tradução automática
Este artigo foi traduzido automaticamente a partir da versão original em inglês.
Escolha um runtime que suporte o seu modelo exato, a quantização e o hardware, e depois teste os seus controlos com o tráfego previsto. vLLM, SGLang, TensorRT-LLM e llama.cpp são candidatos úteis para diferentes implementações. O nome de um framework não garante a menor latência para a sua carga de trabalho.
Verifique a compatibilidade do modelo e do hardware antes de dedicar tempo a testes de carga.
Escolha candidatos segundo o comportamento necessário
| Requisito | Candidato a testar | Dados a recolher |
|---|---|---|
| Serving geral em GPU com vários pedidos | vLLM | Débito que cumpre o SLO e pressão sobre a memória |
| Muitos prefixos repetidos ou geração estruturada | SGLang, em conjunto com outro runtime compatível | Taxa de acertos da cache e validade da saída |
| Otimização específica para NVIDIA | TensorRT-LLM | Suporte de modelos e precisões, e latência sob carga |
| CPU, Apple silicon ou execução portátil de GGUF | llama.cpp | Capacidade para alojar o modelo e velocidade na máquina de destino |
| Configuração simples de modelos locais | Ollama | Se o fluxo de trabalho local satisfaz a concorrência necessária |
Estas são comparações iniciais, não capacidades exclusivas. Por exemplo, outros runtimes de serving também oferecem cache de prefixos e structured output.
vLLM documenta o serving, a gestão da memória, o escalonamento e as opções de implementação. SGLang inclui reutilização de prefixos e funcionalidades de geração estruturada. O guia de início rápido do TensorRT-LLM usa uma API de modelos de alto nível e um comando de serving; verifique os requisitos do backend e do modelo em vez de assumir que todas as implementações precisam de um motor previamente compilado.
A Hugging Face arquivou o repositório do TGI em março de 2026. O README recomenda motores alternativos para novos projetos.
Compare com a mesma distribuição de pedidos
Use o mesmo artefacto do modelo, hardware, precisão, prompts e limites de saída. Teste prefixos únicos e repetidos se a cache for relevante. Registe o tempo até ao primeiro token, o tempo por token de saída, as falhas dos pedidos e o débito nos seus limiares de latência.
Teste também o cancelamento, entradas malformadas, pedidos longos em simultâneo e o comportamento após um reinício. Um runtime que passa num teste curto com um único pedido pode precisar de limites de admissão diferentes sob carga.
A comparação de frameworks de serving no LLM Engineering Guide relaciona a escolha do runtime com as otimizações de inferência.