Comparação de servidores de inferência: soluções de código aberto para modelos de IA

O que um servidor de inferência faz

Um servidor de inferência disponibiliza um modelo de IA já treinado para responder a consultas. Uma aplicação envia dados de entrada para um API, o servidor transmite-os para uma execução do modelo, que os processa utilizando os pesos do modelo carregados. O resultado é devolvido ao aplicativo através do servidor. No caso de um modelo de linguagem, pode tratar-se de uma resposta textual; dependendo da interface, também pode ser apresentada gradualmente como um fluxo de tokens.

O servidor, o ambiente de execução e o modelo são componentes distintos. Os pesos contêm os parâmetros aprendidos; o ambiente de execução realiza os cálculos no hardware disponível. O servidor, por sua vez, organiza o acesso e o encaminhamento das solicitações. Uma mudança de servidor não substitui, portanto, automaticamente o modelo, mas pode exigir um formato diferente ou um ambiente de execução diferente.

Para a gestão de utilizadores e a lógica de negócio, é normalmente necessária uma camada de aplicação adicional. Esta camada determina, por exemplo, quais os utilizadores que podem efetuar um pedido, quais os dados que chegam ao modelo e como a resposta deste é integrada num fluxo de trabalho. Uma API do modelo acessível, por si só, não reflete estas regras; a proteção de acesso e o registo de atividades também têm de ser planeados como parte do sistema global.

Além disso, um servidor LLM concebido para a geração de texto não é, automaticamente, uma plataforma para a classificação de imagens ou outros tipos de modelos. Para tal, é necessário que a respetiva arquitetura do modelo e um ambiente de execução adequado sejam suportados. O Triton adota uma abordagem mais abrangente: encaminha as solicitações para os back-ends através de agendadores específicos para cada modelo. No entanto, a possibilidade de um modelo específico ser executado depende do backend adequado.

Verificar o modelo, o hardware e os direitos

Começa a seleção pela tarefa e por um exemplo concreto Revisão do modelo: Um modelo de chat, um modelo de embedding e um classificador de imagens apresentam requisitos diferentes. Anote também o formato dos pesos em questão e verifique se o tempo de execução pretendido suporta exatamente essa arquitetura e revisão. Um nome de modelo conhecido, por si só, não é suficiente para presumir compatibilidade ou resultados consistentes.

• Registar a tarefa, a revisão do modelo e o formato de peso disponível.
• Verificar a CPU ou a GPU, a memória disponível, os controladores e o backend necessário.
• Esclarecer separadamente os direitos de utilização relativos aos servidores, aos pesos dos modelos e aos componentes adicionais.
• Documentar os comprimentos previstos das consultas, o paralelismo e os requisitos de proteção de acesso.

A escolha do hardware vai além da simples questão de saber se existe uma GPU. Os pesos têm de caber na memória disponível, juntamente com o tempo de execução e os dados adicionais; além disso, os controladores e o backend têm de ser compatíveis com a plataforma. A documentação do backend do Triton indica que nem todos os backends são suportados em todas as plataformas. Por isso, verifica a combinação de versão do servidor, modelo, backend e hardware, em vez de deduzir a compatibilidade a partir do nome do produto.

O formato também pode limitar a escolha: de acordo com a documentação do projeto, o llama.cpp requer modelos no Formato GGUF. Para outros formatos, o projeto descreve um processo de conversão; no entanto, isso não significa que todas as arquiteturas ou variantes do modelo funcionem sem alterações. O código-fonte encontra-se no ramo de desenvolvimento. Por isso, antes de uma implementação, deves verificar se as informações correspondem à versão selecionada.

Um servidor de código aberto não transfere a sua licença para os pesos dos modelos. Verifica, separadamente para cada um deles, se a utilização interna ou comercial prevista é permitida e quais as condições aplicáveis. O facto de os pesos poderem ser descarregados não significa, por si só, que estejam autorizados para qualquer tipo de utilização ou partilha.

Como as consultas a modelos LLM consomem recursos

Quando recebe um pedido de texto, o modelo processa primeiro a entrada. Esta fase denomina-se Preenchimento prévio. Em seguida, na etapa de descodificação, gera a resposta token a token. Um prompt curto e uma resposta longa transferem uma parte diferente do trabalho para a fase de geração, em comparação com um excerto longo de um documento acompanhado de uma resposta sucinta. Ambos os casos devem, portanto, ser tidos em conta no planeamento da capacidade.

Durante a geração, o tempo de execução armazena dados intermédios no Cache KV para que o contexto já processado possa ser utilizado nas etapas seguintes. Esta necessidade de memória soma-se aos pesos do modelo e varia consoante o comprimento das sequências e o número de pedidos processados simultaneamente. O facto de o modelo caber sozinho na memória não significa, por si só, que a carga prevista também nela caiba.

O «Continuous Batching» agrupa de forma flexível as solicitações de geração em curso, em vez de esperar apenas por uma pilha comum fixa. O «PagedAttention» organiza a memória da cache KV em blocos. Ambos os métodos são descritos para vLLM e podem melhorar a utilização dos recursos. No entanto, a eficácia destas técnicas depende, entre outros fatores, do tamanho das solicitações, do paralelismo e do hardware; não é possível concluir que representem uma vantagem para qualquer carga de trabalho.

O Triton, por outro lado, descreve uma arquitetura de servidor geral: um agendador baseado em modelos recebe as solicitações e encaminha-as para o backend responsável. É possível configurar o agrupamento dinâmico para um modelo. Isso não significa que todos os backends tratem internamente as solicitações LLM da mesma forma ou utilizem os mesmos métodos de armazenamento que o vLLM. Por isso, para efeitos de comparação, o que importa é a combinação concreta de backend e modelo.

Por isso, para um serviço de chat interno, não basta um único valor de tokens por segundo. Para além da velocidade de saída, o tempo até ao primeiro token e os tempos de espera em caso de pedidos simultâneos influenciam a experiência do utilizador. Compara as opções com comprimentos de entrada e saída representativos, bem como com o mesmo nível de paralelismo, antes de tomares uma decisão relativa ao hardware.

Classificar quatro soluções, considerar o SGLang como alternativa

A tabela seguinte classifica o vLLM, o llama.cpp, o Triton e o TGI com base nas suas abordagens documentadas. Não se trata de uma comparação de funcionalidades ou desempenho relacionada com versões específicas. O SGLang continua a ser uma sugestão alternativa não avaliada: a Hugging Face recomenda-o, a par do vLLM, como sucessor do TGI; no entanto, não é possível deduzir, a partir disso, nem os formatos de modelo, nem as interfaces, nem o suporte de hardware de uma versão específica do SGLang.

A base de código-fonte contém páginas de documentação sujeitas a alterações e, no caso do llama.cpp, um ramo de desenvolvimento. Assim, não há registo de qualquer teste concluído para o vLLM 0.10.2, o llama.cpp b6000, o Triton 25.10 ou o TGI 3.3.7. Por conseguinte, estas correspondências de versões não são utilizadas como base de comparação. Antes de uma implementação, deves verificar as características necessárias para a versão do servidor e a revisão do modelo efetivamente selecionadas.

O efetivo Despesas de funcionamento depende, entre outros fatores, da disponibilização de modelos, da proteção de acesso e da monitorização. Não é possível fazer uma comparação direta dos custos a partir da tabela: uma instalação local individual e uma plataforma com vários back-ends têm requisitos diferentes. Por isso, verifica primeiro quais são as tarefas que a instalação tem efetivamente de cumprir.

A Hugging Face lidera o TGI no Modo de manutenção e aponta o vLLM e o SGLang como alternativas. Por isso, não é necessário substituir imediatamente uma instalação já existente. No entanto, no caso de novos projetos, o desenvolvimento limitado deve ser tido em conta no planeamento; antes de uma migração, é necessário comparar separadamente o comportamento da API e a qualidade do modelo.

O Triton e o vLLM não são, por princípio, incompatíveis: o Triton pode utilizar um backend vLLM. No entanto, é necessário verificar se um determinado modelo funciona com as versões selecionadas e a plataforma disponível para essa combinação. A arquitetura geral do Triton, por si só, não garante o suporte a todos os backends em todas as plataformas.

Preparar o protótipo local

Para criar um protótipo local, define primeiro a tarefa e algumas entradas típicas. Em seguida, escolhe uma revisão específica do modelo que pareça adequada para o efeito e verifica as respetivas condições de utilização. A licença do servidor, por si só, não indica se podes descarregar, alterar ou utilizar os pesos do modelo para o fim a que se destinam.

O ficheiro llama.cpp utiliza o formato GGUF. Procure uma variante adequada do GGUF ou verifique se o modelo inicial pode ser convertido com as ferramentas documentadas. A documentação do projeto descreve essas conversões no ramo de desenvolvimento; não constitui prova de que todas as versões anteriores suportem todas as arquiteturas ou opções de conversão.

Antes de fazer o download, verifica se a variante escolhida é suportada na tua CPU ou GPU com o backend previsto e se existe memória suficiente disponível para os pesos e o tempo de execução. Uma variante quantizada pode reduzir as necessidades de memória dos pesos. No entanto, compara as respostas com os teus requisitos de qualidade, em vez de deduzir que os resultados permanecem inalterados apenas pelo facto de o ficheiro ser mais pequeno.

Escolha uma compilação específica para o protótipo e verifique se a instalação e as opções do servidor correspondem à documentação da mesma. Para a compilação b6000 acima referida, não está registada aqui qualquer verificação específica da versão; por isso, não é recomendada como ponto de partida verificado. A documentação do modelo existente no ramo de desenvolvimento não substitui nem a documentação do servidor da compilação selecionada nem a respetiva verificação de compatibilidade.

Começa por disponibilizar o serviço apenas localmente e envia várias solicitações representativas. Ao fazê-lo, verifica não só se é apresentada uma resposta, mas também se o formato de entrada, o modelo e as definições de geração se adequam à aplicação que pretendes implementar. Uma chamada isolada bem-sucedida não comprova nem a adequação a cargas mais elevadas nem a qualidade de todas as respostas.

Regista três resultados separadamente: a qualidade do conteúdo com base nos teus casos de teste, o tempo de resposta percebido e o esforço necessário para o download, a conversão e a disponibilização. Desta forma, poderás perceber, por exemplo, se um modelo configurado rapidamente é inadequado do ponto de vista técnico. Para a gestão separada do host Linux, o Visão geral do 1Panel como ferramenta de gestão de servidores contexto complementar; um painel de servidor não substitui a verificação do tempo de execução do modelo.

Planear a carga e as necessidades de armazenamento

Num serviço de chat interno, os pedidos diferem frequentemente de forma significativa: uma pergunta curta com uma resposta sucinta consome recursos diferentes dos necessários para um longo excerto de documento com uma resposta detalhada. Por isso, registe os comprimentos típicos e máximos das entradas e saídas, bem como o número esperado de utilizadores simultâneos. Uma única chamada bem-sucedida não descreve de forma suficiente a situação sob carga.

A necessidade de memória não se resume apenas aos pesos dos modelos. O tempo de execução e os valores intermédios também ocupam espaço; além disso, no caso de consultas paralelas a LLM, aumenta a necessidade de Cache KV. Contextos mais longos e um maior número de consultas processadas em simultâneo podem, por isso, levar uma configuração ao seu limite, apesar de os pesos caberem, por si só, na memória disponível.

O «Continuous Batching» e o «PagedAttention» são abordagens documentadas no âmbito do vLLM para a gestão de pedidos em curso e da memória cache, respetivamente. No entanto, não te dispensam do planeamento da capacidade: a combinação viável de paralelismo e comprimento do contexto depende do modelo, do hardware e da configuração escolhida. Não é possível deduzir daí um ganho de desempenho generalizado para qualquer carga de trabalho.

Um simples cálculo de quantidades ajuda na preparação: 100 pedidos hipotéticos, cada um com 200 tokens de distribuição, totalizam 20 000 tokens de distribuição. Isso equivale a sem medição do débito. Sem um período de tempo, comprimentos de entrada, paralelismo e outros dados operacionais, não é possível deduzir nada sobre o número de tokens por segundo nem sobre os custos.

Para uma comparação posterior, cria uma matriz de teste com o modelo e a revisão, a quantização, a versão do servidor, o hardware e a memória disponível. Varia de forma controlada o comprimento das entradas e das saídas, bem como o paralelismo. Regista o tempo até ao primeiro token, a velocidade de saída e a taxa de erros; avalia separadamente a qualidade da resposta com base nos mesmos casos de teste. Os parâmetros de geração e o modelo de chat também devem constar do registo, para que as diferenças permaneçam compreensíveis.

Operar a API de forma segura e monitorizável

Um acessível Servidor de Inferência Ainda não é um serviço seguro. Limita, por enquanto, o acesso à rede aos sistemas que precisam de enviar pedidos ou de administrar o servidor. No caso do acesso externo, deve ser implementada uma proteção de acesso a montante da API; verifica todos os pontos finais acessíveis e não apenas a rota para a geração de texto.

Aviso: De acordo com a documentação, a opção de chave API do vLLM não protege todos os pontos de extremidade. Por isso, uma chave definida não substitui nem o isolamento de rede nem um controlo de acesso a montante, que tenha também em conta as interfaces administrativas e outras interfaces acessíveis. Testa as regras a partir das respetivas redes antes de ativares o serviço.

As solicitações e respostas podem conter informações confidenciais. Por isso, define antecipadamente quais os dados que serão registados, quem tem acesso aos mesmos e quando serão eliminados. Para a resolução de problemas, bastam frequentemente dados técnicos como a hora, a versão do modelo, o tipo de erro e a duração da solicitação; só deve registar o conteúdo completo se houver uma necessidade justificada.

O Observabilidade deve registar separadamente o tempo de espera, o tempo até ao primeiro token, a velocidade de emissão e os erros. Se, por exemplo, o tempo de espera aumentar em caso de pedidos simultâneos, enquanto as respostas individuais são processadas rapidamente após o início, isso indica um gargalo diferente de uma emissão lenta de tokens. Avalie estes indicadores juntamente com o volume dos pedidos e o paralelismo.

Para a gestão dos hosts subjacentes, as ferramentas de gestão podem agrupar tarefas e responsabilidades. Para a seleção separada deste nível de gestão, o Comparação entre o ISPConfig e o Froxlor contexto complementar. A escolha de um painel de servidor é uma decisão de infraestrutura independente; esse painel não substitui nem a proteção da API do modelo nem a monitorização do serviço de inferência.

Identificar a origem do erro e migrar o TGI

Se um modelo não iniciar, verifica primeiro se a revisão do modelo e o formato correspondem ao ambiente de execução selecionado. No caso do llama.cpp, o formato necessário é o GGUF; no entanto, a simples conversão não garante, por si só, que a arquitetura e a tarefa específicas funcionem. Em seguida, verifica se o backend selecionado e a combinação de hardware são suportados e se existe memória suficiente disponível.

Se o servidor arrancar, mas apresentar respostas inesperadas no chat, verifica isso Modelo de chat e os parâmetros de geração fornecidos. Uma interface compatível com a OpenAI não significa que todos os parâmetros sejam implementados de forma idêntica: a documentação do vLLM também indica os parâmetros não suportados ou ignorados. Por isso, compara as definições efetivamente utilizadas e não apenas o formato da chamada à API.

No caso de um serviço TGI já existente, a migração começa com um levantamento da situação atual: isto inclui a revisão do modelo, as chamadas à API utilizadas, as definições de amostragem e os requisitos relativos à qualidade da resposta. A Hugging Face mantém o TGI em modo de manutenção e aponta, entre outras, o vLLM e o SGLang como alternativas. Isto torna a mudança digna de consideração, mas não implica uma falha imediata das instalações existentes.

Construa o Instalação de destino Analisa-os separadamente e compara ambos os serviços utilizando os mesmos dados de entrada representativos, comprimentos de saída e condições de carga. Além da qualidade da resposta e dos erros, verifique também se os clientes se adaptam à nova interface e aos seus parâmetros. Só mude o tráfego quando os resultados forem aceitáveis para a utilização prevista e estiver preparado um plano de retorno.

O guia do Hugging Faces para pontos finais de inferência também recomenda criar um novo ponto final e realizar chamadas de teste antes da transição. Trata-se de um modelo de procedimento útil para o planeamento, mas não de um guia passo a passo universal para instalações geridas pelo próprio utilizador: a rede, a implementação e o controlo de tráfego podem estar organizados de forma diferente nessas instalações.

Escolher a arquitetura adequada

Para um protótipo local O ficheiro llama.cpp constitui um ponto de verificação óbvio, desde que se disponha de um modelo GGUF adequado e do suporte de hardware adequado. Daí não decorre qualquer recomendação para uma compilação específica. O que é decisivo não é apenas se o servidor arranca: compare também a qualidade da tarefa pretendida, o tempo de resposta e o esforço necessário para os pesos do modelo. O suporte ao modelo e ao backend deve continuar a ser verificado para a combinação específica.

Para um serviço de chat interno, o vLLM pode ser considerado um candidato a teste: a documentação disponível descreve uma interface de chat compatível com a OpenAI, incluindo o modelo de chat necessário. Não há, portanto, qualquer registo de um teste para a versão 0.10.2. O SGLang continua a ser aqui uma sugestão alternativa não avaliada proveniente da documentação da TGI; sem um teste técnico da versão, não é possível compará-lo de forma equivalente.

Uma plataforma para modelos de imagem e modelos de linguagem apresenta requisitos diferentes dos de um único ponto de acesso de chat. O Triton constitui um ponto de referência devido aos seus agendadores e back-ends específicos para cada modelo, embora a versão 25.10 não tenha sido verificada neste contexto. Esta arquitetura torna a Suporte de backend Quanto à questão crucial dos detalhes: nem todos os backends são suportados em todas as plataformas, e cada modelo necessário tem de ser verificado na combinação específica.

Ao tomar a decisão, tenha em conta a revisão do modelo, a versão do servidor, o hardware, o backend e os direitos de utilização. Em seguida, compare a qualidade, os tempos de resposta sob a carga prevista e o esforço necessário para a segurança, as atualizações e a deteção de erros. Uma solução que seja suficiente para um teste local pode exigir infraestrutura adicional no caso de vários utilizadores ou tipos de modelos; uma lista de melhores resultados genérica ocultaria essas diferenças.