Modo Router do Llama-Server - Comutação Dinâmica de Modelos Sem Reinícios

Por muito tempo, o llama.cpp teve uma limitação gritante: era possível servir apenas um modelo por processo, e a troca exigia uma reinicialização.

Essa era acabou.

Atualizações recentes introduziram o modo roteador no llama-server, trazendo algo muito mais próximo do que as pessoas esperam de runtimes locais modernos de LLMs:

• carregamento dinâmico de modelos
• descarregamento sob demanda
• troca por solicitação
• sem reinicialização do processo

Em outras palavras: comportamento semelhante ao do Ollama, mas sem as rodinhas de treinamento.

Se você ainda está decidindo entre runtimes locais, APIs em nuvem e infraestrutura auto-hospedada, o resumo sobre hospedagem de LLMs é um bom ponto de partida.

Pré-requisitos

O modo roteador requer uma versão recente do llama-server — aproximadamente pós-meados de 2024. Versões mais antigas não possuem as flags --models-preset ou --models-dir.

Para opções de instalação (gerenciador de pacotes, binários pré-compilados ou compilação completa do código-fonte com CUDA), consulte o início rápido do llama.cpp.

Uma vez que você tenha o llama-server, confirme se sua versão suporta o modo roteador:

llama-server --help | grep -i models

Se --models-preset ou --models-dir aparecerem, está tudo certo. Se estiverem ausentes, atualize para uma versão mais recente.

Meu output atual de ajuda relacionado a modelos:

-cl,   --cache-list                     show list of models in cache
                                        Prefix/Suffix/Middle) as some models prefer this. (default: disabled)
                                        models with dynamic resolution (default: read from model)
                                        models with dynamic resolution (default: read from model)
                                        embedding models (default: disabled)
--models-dir PATH                       directory containing models for the router server (default: disabled)
                                        (env: LLAMA_ARG_MODELS_DIR)
--models-preset PATH                    path to INI file containing model presets for the router server
                                        (env: LLAMA_ARG_MODELS_PRESET)
--models-max N                          for router server, maximum number of models to load simultaneously
                                        (env: LLAMA_ARG_MODELS_MAX)
--models-autoload, --no-models-autoload
                                        for router server, whether to automatically load models (default:
                                        (env: LLAMA_ARG_MODELS_AUTOLOAD)

O que o modo roteador realmente faz

O modo roteador transforma o llama-server em um dispersor de modelos.

Em vez de vincular a um único modelo via -m, o servidor:

• inicia sem nenhum modelo carregado
• recebe uma solicitação que nomeia um modelo
• carrega esse modelo se ele não estiver já na memória
• executa a inferência
• opcionalmente descarrega o modelo após a resposta, ou mantém-o ativo para a próxima solicitação

A ideia principal

Você não está mais executando:

./llama-server -m model.gguf

Você está executando:

./llama-server --models-preset models.ini --port 8080

E deixando o servidor decidir o que carregar e quando, com base no que o cliente realmente solicita.

Isso é importante porque significa que um único processo persistente pode servir uma frota inteira de modelos, com os clientes selecionando o adequado para cada tarefa — um modelo de codificação, um modelo de chat, um modelo de resumo — sem qualquer sobrecarga de coordenação do seu lado.

Configuração: definindo seus modelos

Aqui é onde as coisas ainda estão um pouco cruas.

Ainda não há um formato oficial totalmente estável, mas as versões atuais suportam definições de modelos em estilo INI via arquivo de configuração.

Exemplo de models.ini

[llama3]
model = /opt/models/llama-3-8b-instruct.Q5_K_M.gguf
ctx-size = 8192
ngl = 35
threads = 8

[mistral]
model = /opt/models/mistral-7b-instruct-v0.3.Q4_K_M.gguf
ctx-size = 4096
ngl = 20
threads = 8

[qwen]
model = /opt/models/qwen2.5-coder-7b-instruct.Q5_K_M.gguf
ctx-size = 16384
ngl = 35
threads = 8

Cada nome de seção torna-se o identificador do modelo que os clientes usam no campo "model" de suas solicitações de API.

Principais parâmetros de configuração

A escolha do valor correto de ngl depende da VRAM disponível da sua GPU — para seleção de GPU e economia de hardware, o guia de hardware de computação é uma referência útil. Para monitorar o consumo de VRAM em tempo real enquanto ajusta, consulte as ferramentas de monitoramento de GPU para Linux.

Iniciando o servidor com configuração

./llama-server --models-preset /opt/llama.cpp/models.ini --port 8080

Confirme se o servidor iniciou corretamente:

curl http://localhost:8080/v1/models | jq '.data[].id'

Você deve ver cada nome de seção do seu models.ini listado como um ID de modelo.

Uma nota sobre estabilidade

A interface de configuração INI ainda está em evolução:

• flags podem mudar entre commits
• alguns parâmetros são reconhecidos apenas por configurações de compilação específicas
• a documentação fica atrás da implementação

Fixe em um commit específico do llama.cpp se precisar de reprodutibilidade entre reinicializações.

Uso da API: alternando modelos por solicitação

Uma vez que o servidor está em execução, a troca de modelos acontece através da API padrão compatível com OpenAI. Você simplesmente define o campo "model".

Listar modelos registrados

curl http://localhost:8080/v1/models

Solicitação de conclusão — primeiro modelo

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "messages": [
      {"role": "user", "content": "Explain router mode in one paragraph"}
    ]
  }'

Alterar para um modelo diferente — mesmo endpoint, mesma porta

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen",
    "messages": [
      {"role": "user", "content": "Write a Python function that reads a CSV file"}
    ]
  }'

O servidor lida com o ciclo de descarregamento/carregamento transparentemente. Seu código cliente não muda — apenas o campo model.

Exemplo em Python

Se você estiver usando o cliente Python openai:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8080/v1", api_key="not-needed")

# Use the coding model
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Write a Go HTTP handler"}],
)
print(response.choices[0].message.content)

# Switch to the chat model — same client, different model name
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "What is the capital of Australia?"}],
)
print(response.choices[0].message.content)

O que acontece internamente

Quando uma solicitação chega para qwen e llama3 está atualmente carregado:

1. llama3 é descarregado da VRAM
2. os pesos de qwen são lidos do disco e carregados na VRAM
3. a inferência é executada
4. a próxima solicitação determina se qwen deve permanecer carregado ou ser trocado novamente

Isso responde diretamente à pergunta comum:

Como um servidor LLM local pode alternar modelos sem reiniciar

Carregando dinamicamente os modelos por solicitação, não vinculando na inicialização.

Serviço Systemd: configuração pronta para produção

Criar um usuário dedicado e diretórios

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/llama.cpp llm
sudo mkdir -p /opt/llama.cpp/models
sudo chown -R llm:llm /opt/llama.cpp

Copie seu binário e configuração de modelo para o lugar certo:

sudo cp build/bin/llama-server /opt/llama.cpp/
sudo cp models.ini /opt/llama.cpp/

/etc/systemd/system/llama-server.service

[Unit]
Description=Llama.cpp Router Server
After=network.target

[Service]
Type=simple
User=llm
WorkingDirectory=/opt/llama.cpp
ExecStart=/opt/llama.cpp/llama-server --models-preset /opt/llama.cpp/models.ini --port 8080
Restart=always
RestartSec=5

Environment=LLAMA_LOG_LEVEL=info

[Install]
WantedBy=multi-user.target

Habilitar e iniciar

sudo systemctl daemon-reload
sudo systemctl enable llama-server
sudo systemctl start llama-server

Verificar e inspecionar logs

sudo systemctl status llama-server

journalctl -u llama-server -f

Em uma inicialização bem-sucedida, você verá linhas indicando que o servidor está ouvindo e o registro de modelos foi carregado. Uma verificação rápida de sanidade:

curl -s http://localhost:8080/v1/models | jq '.data[].id'

Agora você tem um serviço persistente com reinicialização automática e troca de modelos centralizada — sem gerenciamento manual de processos. Se você deseja aplicar o mesmo padrão a outros binários, hospedar qualquer executável como um serviço no Linux percorre a abordagem geral.

A flag --metrics do llama-server expõe um endpoint compatível com Prometheus. Para dashboards específicos do llama.cpp, consultas PromQL e regras de alerta, consulte o guia de monitoramento de inferência de LLM. Para a configuração de observabilidade mais ampla, o guia de observabilidade cobre toda a pilha.

Limitações que você precisa entender

O modo roteador é genuinamente útil, mas vem com compensações sobre as quais você deve estar claro antes de depender delas em produção.

Apenas um modelo na memória por vez

Apesar de múltiplos modelos serem definidos em models.ini, apenas um está residente na VRAM por worker em qualquer momento dado. Alternar significa um ciclo completo de descarregamento e recarregamento.

• alternar significa recarregar
• pico de latência é inevitável
• em um modelo típico de 7B em Q5, um recarregamento pode levar de 3 a 10 segundos, dependendo da velocidade do disco e da largura de banda da VRAM

Isso responde a outra pergunta-chave:

O llama.cpp suporta servir múltiplos modelos ao mesmo tempo

Não exatamente. Ele suporta múltiplas definições, não residência simultânea. Se você precisar de dois modelos genuinamente carregados em paralelo, você precisa de dois processos em duas GPUs separadas.

Para consumo de VRAM medido e tokens por segundo através de tamanhos de modelo, os benchmarks de desempenho de LLM cobrem o quadro completo. Para números específicos do llama.cpp em uma GPU de 16 GB — modelos densos e MoE em múltiplos tamanhos de contexto — consulte os benchmarks do llama.cpp em VRAM de 16 GB.

Sem cache inteligente

Ao contrário do Ollama, que mantém um pool quente e expulsa modelos com base na recência:

• não há estratégia automática de expulsão de modelos
• não há pré-aquecimento em segundo plano
• não há fila de prioridade para modelos usados frequentemente

Se você enviar solicitações alternadas para llama3 e mistral, cada única solicitação aciona um recarregamento. Este é o custo fundamental de estar mais próximo do metal.

A latência é imprevisível para cargas de trabalho mistas

Uma carga de trabalho bem comportada que usa um modelo consistentemente será rápida. Uma carga de trabalho que intercala múltiplos modelos será lenta. Planeje sua lógica de roteamento de cliente em conformidade — agrupe solicitações por modelo sempre que possível.

A configuração não é estável

O suporte INI existe e funciona na maioria das versões recentes, mas não está totalmente padronizado. Flags e nomes de parâmetros mudaram entre versões. Se você atualizar o llama-server, teste seu models.ini contra a nova compilação antes de implantar.

Llama.cpp vs Ollama: comparação honesta

Opinião pessoal

Escolha o modo roteador do llama.cpp quando você quiser:

• controle máximo sobre parâmetros de runtime por modelo
• sobrecarga de processo mínima
• acesso direto às flags do llama.cpp sem camadas de abstração
• uma base hackeável para ferramentas personalizadas

Escolha o Ollama quando você quiser:

• uma experiência estável e polida
• download e versionamento automático de modelos
• keep-alive e expulsão inteligentes sem configuração
• tudo incluído desde o primeiro dia

Nenhum está errado. A escolha depende de quanto você quer gerenciar você mesmo.

Se você optar pelo Ollama, o guia rápido da CLI do Ollama cobre os comandos do dia a dia. Para uma comparação mais ampla que também inclui vLLM, LM Studio e LocalAI, consulte como diferentes runtimes locais se comparam em 2026.

Llama.cpp vs llama-swap

llama-swap é um orquestrador externo que fica na frente de uma ou mais instâncias do llama-server:

• intercepta solicitações e inspeciona o campo model
• inicia o processo llama-server apropriado para esse modelo
• desliga instâncias ociosas após um tempo limite configurável
• faz proxy da solicitação através uma vez que o modelo está pronto

Para uma configuração prática, consulte o início rápido do llama-swap.

Diferença chave

Quando usar llama-swap

llama-swap oferece isolamento em nível de processo por modelo, o que significa que uma falha em uma instância de modelo não afeta as outras. Ele também permite que cada modelo seja executado com flags llama-server completamente independentes.

Use-o se você precisar de:

• melhor controle de ciclo de vida e isolamento
• lógica de troca mais inteligente com tempos limite de inatividade configuráveis
• latência mais previsível (cada modelo tem um processo quente após o primeiro carregamento)
• estabilidade de produção hoje, não eventualmente

Quando o modo roteador nativo é suficiente

Use o roteador integrado se você quiser:

• zero dependências externas
• um único processo para gerenciar
• implantação mais simples (um binário, um arquivo de configuração)
• pilha mínima para desenvolvimento ou configurações de usuário único

Pensamentos finais

O modo roteador é um passo significativo para frente para o llama-server.

Ele responde à demanda de longa data:

O que é o modo roteador no servidor llama.cpp

É a camada faltante que transforma um binário estático em um serviço de inferência dinâmico — um processo que pode atender solicitações para um catálogo inteiro de modelos.

Mas não está terminado.

Hoje é:

• poderoso o suficiente para cargas de trabalho reais
• promissor como base para roteamento mais sofisticado
• um pouco áspero nas bordas de configuração e estabilidade

Se sua carga de trabalho for previsível e você puder agrupar solicitações por modelo, o modo roteador funciona bem hoje. Se você precisar de confiabilidade de nível de produção e isolamento por modelo, opte pelo llama-swap enquanto a implementação nativa amadurece.

Quando você precisar liberar VRAM sem reiniciar — para uma execução de benchmark, uma janela de manutenção ou uma reinicialização limpa de desenvolvimento — a abordagem scriptável é listar os modelos carregados e chamar o endpoint de descarregamento para cada um. O padrão completo de curl e jq é coberto em Desacarregar Todos os Modelos do Roteador llama.cpp Sem Reiniciar.

De qualquer maneira, você obtém comportamento semelhante ao Ollama, sem esconder a maquinaria.