Sobre o projeto

llama-swap é um proxy para executar vários modelos de IA generativa em uma única máquina e alternar entre eles sob demanda. Ele fica na frente de qualquer servidor de inferência compatível com a API OpenAI ou Anthropic, lê o campo `model` de cada requisição recebida e inicia ou substitui o servidor upstream necessário para atendê-la. O projeto é escrito em Go, é distribuído como um único binário mais um arquivo de configuração e não reporta dependências externas. Os upstreams suportados incluem llama.cpp e seus forks, vllm, stable-diffusion.cpp, whisper.cpp, audio.cpp e ComfyUI. Como o proxy atua em nível de protocolo, em vez de estar vinculado a um mecanismo específico, o README observa que os servidores de inferência podem ser atualizados de forma independente. Superfície da API - Endpoints no estilo OpenAI: `v1/completions`, `v1/chat/completions`, `v1/responses`, `v1/embeddings`, `v1/models`, `v1/audio/speech`, `v1/audio/transcriptions`, `v1/audio/voices`, `v1/images/generations` e `v1/images/edits`. - Endpoints no estilo Anthropic: `v1/messages` e `v1/messages/count_tokens`. - Extras do llama-server: `v1/rerank`, `v1/reranking`, `/rerank`, `/infill`, `/completion`, `/models` e `/props`. - Endpoints SDAPI do servidor do stable-diffusion.cpp, além de endpoints de tarefas do audio.cpp e um endpoint personalizado `/comfyui/`. - Endpoints de gerenciamento: `/ui`, `/upstream/:model_id`, `/running`, `POST /api/models/unload` (todos os modelos) e `POST /api/models/unload/:model_id`, listagem e ativação de perfis via `/api/profiles`, `/health` e `/metrics` para métricas de sistema e GPU no Prometheus. - Endpoints de logs: `/logs` para logs em texto simples armazenados em buffer, `/logs/stream` para streaming ao vivo, com variantes `/logs/stream/proxy`, `/logs/stream/upstream` e `/logs/stream/{model_id}`; `?no-history` transmite apenas novas linhas. Configuração e recursos Uma configuração mínima declara um mapa `models` em que cada entrada tem um ID e um `cmd`; `${PORT}` é substituído por uma porta atribuída automaticamente. Configurações opcionais incluem `ttl` para descarregamento automático após inatividade, `unloadTimeout`, `aliases` para nomes de modelos familiares, variáveis `env`, `cmdStop` para desligamento gracioso no Docker/Podman, `useModelName`, `filters` de requisição (`stripParams`, `setParams`, `setParamsByID`), `hooks` para pré-carregamento na inicialização, `macros` e uma DSL `matrix` para executar modelos concorrentes com lógica de troca personalizada. Chaves de API podem ser definidas para restringir o acesso aos endpoints, e perfis permitem alternar o roteamento de IDs de modelo em tempo de execução. A interface web incluída oferece um playground, métricas de tokens, inspeção de requisições/respostas, carregamento e descarregamento manual de modelos e streaming de logs em tempo real. Uma página de Ajuda executa um modelo local com suporte a ferramentas contra a própria documentação do llama-swap, e as mesmas ferramentas são expostas como um endpoint MCP em `/api/mcp`. Instalação As opções listadas são Docker, Homebrew, MacPorts, WinGet, binários de release (Linux, macOS, Windows, FreeBSD) e compilação a partir do código-fonte com Go e Node.js. As imagens Docker noturnas vêm em duas famílias: imagens unificadas que agrupam llama-server, ik-llama-server, stable-diffusion.cpp, whisper.cpp, audio.cpp e llama-swap (variantes CUDA 12, CUDA 13 e Vulkan, recomendadas), e uma imagem legada baseada no contêiner `llama-server` do próprio llama.cpp. As imagens unificadas podem ser configuradas por meio de variáveis de ambiente `LLAMA_SWAP_*` mapeadas para flags de linha de comando. Notas operacionais O README recomenda desabilitar o buffering de respostas ao colocar o llama-swap atrás do nginx, pois o buffering quebra SSE e streaming de chat completions; o llama-swap também define `X-Accel-Buffering: no` em respostas SSE. Para servidores baseados em Python, como vllm ou tabbyAPI, recomenda-se executá-los sob Podman ou Docker para isolamento de ambiente e tratamento correto de `SIGTERM`.