Keystone tira o nome do modelo do código: gateway de LLM open source adiciona 0,64 ms

A linha mais cara de um microsserviço com LLM é model="gpt-4o". Junto com ela vêm a chave do provedor, os retries próprios e uma fatura que ninguém consegue destrinchar. A equipe do Keystone lançou o gateway open source The Model Switchboard (KTMS), em Go e sob Apache 2.0, que elimina essa linha por completo. O serviço diz ao gateway o quão difícil é a tarefa, e as regras decidem qual modelo responde. A sobrecarga no ambiente de teste é de cerca de 0,64 ms no p50 e 1,1 ms no p99, a 200 RPS.

Quarenta serviços e um nome de modelo

A história costuma ser esta: o primeiro serviço recebe uma chave da OpenAI e, seis meses depois, há quarenta serviços, cada um com seu segredo, seu wrapper de retries e sua própria contagem de tokens. Dali em diante, tudo quebra de forma previsível. Saiu um modelo melhor ou mais barato: são quarenta pull requests e quarenta deploys, e metade das equipes só atualiza daqui a um trimestre. O provedor caiu: os quarenta serviços falham, porque o fallback ou não foi escrito ou foi escrito de maneiras diferentes. Chegou a fatura: a chave é compartilhada, as chamadas não têm metadados e não dá para saber quem gastou o dinheiro.

No Keystone, o serviço envia o effort (LOW, MEDIUM ou HIGH) e atributos: idioma, tipo de tarefa, usuário. Para o gateway, os atributos são apenas chaves e valores que as regras comparam. Clientes em Python nem precisam de gRPC: o HTTP compatível com a OpenAI entende as mesmas regras. O effort é codificado no nome do modelo (auto:high), o metadata vira atributos, e o campo user vai para os limites.

Regras, canários e um juiz de 250 ms

As regras ficam no Postgres e são substituídas por inteiro em uma única chamada atômica. Vence a regra aplicável de maior prioridade, e o campo use define a cadeia de fallbacks, que por convenção vai do modelo barato ao caro. A validação rejeita qualquer conjunto em que algum effort fique sem uma regra sem atributos, de modo que nenhuma requisição escapa de todas as regras. As réplicas incorporam as mudanças em até 60 segundos. O comando ktms route explain mostra a rota de antemão, sem chamar o modelo.

É possível atribuir pesos às regras, por exemplo [90, 10]. Quando há user_id ou canary_key, a distribuição é "fixa" (sticky): o mesmo usuário sempre cai no mesmo modelo. Assim, um modelo novo chega a 10% do público sem nenhuma alteração nos serviços. Há ainda um roteamento shadow, em caráter experimental: uma parcela do tráfego é duplicada de forma assíncrona para o candidato, e o juiz compara as respostas e grava o resultado nas métricas.

Se o serviço não sabe a complexidade, entra o model: "auto". O gateway consulta um modelo juiz, que não devolve texto, e sim uma resposta tipada com probabilidades. Há suporte a Jev, da TypeSafe, e a OpenAI Decisions. O prazo é rígido, de 250 ms; se o juiz falhar ou demorar, a requisição segue com MEDIUM. A complexidade fixada sempre tem precedência sobre o juiz, e a escolha aparece nos cabeçalhos X-KTMS-Route-Mode, X-KTMS-Judge-Score e X-KTMS-Judge-Model. A seleção pelo juiz na branch 1.x está marcada como experimental; só auto:high e seus equivalentes são estáveis.

Falhas de provedores e dinheiro sob controle

Os retries embutidos nos SDKs dos provedores ficam desativados: uma tentativa do roteador equivale a uma chamada ao provedor. O roteador repete uma vez, no mesmo modelo, em caso de 429, 5xx ou queda de conexão, e depois segue pela cadeia; no streaming, isso vale até o primeiro chunk. Os mecanismos de proteção:

• Circuit breaker por par (provedor, modelo): após 5 falhas seguidas, o circuito abre; depois de 30 s, uma requisição de teste verifica o modelo.
• Retry-After, retry-after-ms e google.rpc.RetryInfo, no caso do Gemini: esperas de até 1 s são cumpridas no local, e esperas maiores colocam o modelo em pausa para aquela chave específica (no máximo 5 minutos por padrão).
• Se a cadeia inteira estiver em pausa, o cliente recebe UNAVAILABLE vendors_unavailable com um Retry-After fiel à realidade.

Os limites de gasto são definidos em dólares por chave e por usuário, por dia UTC ou por mês, além de um orçamento mensal da equipe. Antes de cada chamada, o gateway reserva o pior caso (entrada × preço de entrada + máximo de tokens × preço de saída) com um único script Lua no Redis e, depois da resposta, recalcula para o custo real. Os valores são armazenados em nano-dólares. Se a chamada ultrapassasse o limite, ela é rejeitada, mas um modelo mais barato adiante na cadeia ainda pode responder. Sem max_output_tokens, a reserva é calculada com 4096 tokens, por isso vale sempre definir o parâmetro.

Outros recursos:

• Organizações e equipes com listas de modelos permitidos e orçamentos mensais; o org_id e o team_id são preenchidos pelo gateway a partir da chave.
• Batch pela API dos provedores com desconto de 50%, envio idempotente por client_batch_id; os prompts não são armazenados no banco.
• Limite de requisições GCRA com burst configurável e orçamentos diários de tokens com tolerância de 5%.
• Um evento por chamada para o light-tokenmeter ou para qualquer serviço de contabilização via gRPC.

Limitações e como lidar com elas

Provedores: OpenAI, Anthropic, Gemini, DeepSeek, Groq, Mistral, Azure OpenAI, Bedrock, qualquer servidor compatível com a OpenAI e TypeSafe para as decisões. Um provedor exótico pode não estar na lista. Em latência, o Keystone perde para agentgateway, Apache APISIX e Kong. Ambiente de teste: Google Cloud c3-standard-4 com 4 vCPU e upstream mock; o gateway sustentou no mínimo 4000 RPS. Sem o Redis, os limites não funcionam, e, se ele cair, os limites de requisições e de tokens deixam o tráfego passar. Para os limites de gasto, é possível ativar o modo estrito SPEND_LIMITS_FAIL_MODE=closed.

Conclusão prática para equipes com dezenas de serviços de LLM: comece com três regras (LOW, MEDIUM e HIGH, sem atributos) e cadeias que vão do modelo barato ao caro, e só depois adicione regras com atributos. Defina desde o início o max_output_tokens e limites em dólar por chave, para que a fatura passe a ser compreensível. O esquema também pode ser reproduzido em outro gateway; o essencial é tirar o nome do modelo do código dos serviços e levá-lo para a configuração.