Skip to main content
Use auto_routing quando você quiser que o gateway escolha entre variantes quantizadas, MoE e densas com base na complexidade da solicitação. Quando variantes irmãs ainda não estiverem registradas, use auto_routing_debug para verificar a própria decisão de roteamento. Os metadados da resposta incluirão:
  • routed_model
  • auto_routing_debug
auto_routing_debug é uma string JSON compacta com o modelo solicitado, nível selecionado, esforço de raciocínio, pontuação e motivos.

Execute a validação

A verificação de produção em 31 de março de 2026 utilizou o endpoint Responses diretamente com um modelo fixo e uma flag de depuração opt-in.
bash
Se o deployment estiver ativo, os metadados da resposta incluem um payload como este:
O routed_model ainda pode ser igual ao modelo solicitado se nenhuma família irmã compatível existir em produção ainda. Isso não significa que a heurística falhou. A prova está em desired_tier, reasoning_effort, score e reasons em auto_routing_debug.

Método de teste

A checagem de produção utilizou seis requisições Responses contra https://apigw.mka1.com/api/v1/llm/responses. Cada requisição definiu:
  • model: "meetkai:functionary-pt"
  • auto_routing: true
  • auto_routing_debug: true
A matriz cobriu:
  1. Prompt curto em inglês para transformação
  2. Prompt médio para saída estruturada
  3. Prompt longo para análise de incidente
  4. Prompt forçado de uso de ferramenta
  5. Prompt curto em português para transformação
  6. Prompt longo em português para análise de incidente
Para cada resposta, a validação registrou:
  • Status HTTP
  • metadata.routed_model
  • metadata.auto_routing_debug analisado
  • reasoning.effort efetivo

Resultados ao vivo em produção

Estes foram os resultados observados em produção em 31 de março de 2026 após o PR 321 ser implantado: Todas as seis requisições retornaram 200 OK. Todas as seis respostas incluíram auto_routing_debug. O nível observado correspondeu ao nível esperado em todos os casos.

Trechos brutos de resposta

Os exemplos abaixo foram adaptados do log de produção ao vivo.

Prompt curto de transformação

Requisição:
Trecho observado da resposta:

Prompt para saída estruturada

Requisição:
Trecho observado da resposta:

Prompt longo para análise de incidente

Requisição:
Trecho observado da resposta:

Prompt forçado de uso de ferramenta

Requisição:
Trecho observado da resposta:

Prompt de transformação em português

Requisição:
Trecho observado da resposta:

Prompt de análise de incidente em português

Requisição:
Trecho observado da resposta:

Interprete o resultado

Use esta lista de verificação ao validar um deployment:
  1. Confirme que a resposta inclui metadata.auto_routing_debug.
  2. Analise a string JSON e inspecione desired_tier.
  3. Verifique se reasoning_effort corresponde ao nível de complexidade esperado.
  4. Verifique se os reasons correspondem às características do prompt que você pretendia acionar.
  5. Se variantes irmãs existirem, confirme também que routed_model muda para a irmã esperada.
Se auto_routing_debug estiver ausente, a imagem da API implantada provavelmente ainda não inclui o recurso.

Notas

  • auto_routing_debug é destinado à validação e checagens de rollout. É opt-in e não deve ser ativado por padrão para o tráfego normal de produção.
  • auto_routing_debug está disponível atualmente na API de Responses.
  • Heurísticas para prompts em português estão incluídas na lógica de roteamento em produção atual, então prompts curtos de transformação e prompts complexos de análise de incidente podem ser validados tanto em inglês quanto em português.