Pular para o conteúdo principal
Quando uma solicitação usa “model”: “auto”, o MKA1 aplica a política auto da organização para aquele endpoint. Por padrão, auto é um alias direto para um modelo do registro de modelos. As organizações também podem configurar um juiz LLM para escolher entre um conjunto aprovado de modelos. O juiz recebe sinais sobre a solicitação, os modelos disponíveis e a conversa existente para escolher o modelo mais adequado ao trabalho.

Endpoints compatíveis

A seleção por juiz está disponível para vários tipos de solicitação de IA. Somente modelos adequados ao tipo de solicitação são considerados. Por exemplo, um modelo de TTS não pode ser selecionado para uma solicitação de Responses.

Como funciona a seleção de modelo

A organização define os modelos que podem ser selecionados. Em cada solicitação, o MKA1 exclui os candidatos que não estão mais ativos no registro da organização ou que não conseguem atender à solicitação, como um modelo sem entrada de imagem para uma solicitação que contém uma imagem. Se restar apenas um modelo adequado, o MKA1 o seleciona diretamente; quando houver vários, o juiz configurado escolhe entre eles. Cada solicitação que passa pelo juiz faz uma chamada extra ao modelo juiz. A chamada é cobrada pelo preço do modelo juiz e conta para os seus orçamentos, mas não entra no usage da resposta. Ela também adiciona uma ida e volta completa ao juiz antes de o modelo selecionado começar, e uma resposta em streaming só é aberta depois que o juiz escolhe. Uma política com juiz não faz failover. Se o modelo selecionado falhar, a solicitação falha: o MKA1 não tenta outro candidato, e as regras de redirecionamento dos candidatos não se aplicam. A saúde do provedor não é um sinal de seleção, então um modelo selecionado cujo provedor esteja indisponível também faz a solicitação falhar. Se nenhum modelo adequado restar, ou se o juiz configurado estiver indisponível ou falhar, o MKA1 retorna um erro transparente em vez de mudar a política silenciosamente. Consulte Erros.

Sinais usados na seleção de modelo

O MKA1 dá ao juiz uma visão consistente dos fatores que importam para a solicitação atual:
  • Solicitação e ferramentas: a natureza da tarefa, as ferramentas disponíveis, a saída solicitada e se há imagens, áudio ou arquivos. Modelos que conseguem trabalhar diretamente com a entrada original têm preferência.
  • Capacidades do modelo: modalidades e tipos de arquivo compatíveis, contexto disponível e outros requisitos necessários para concluir a solicitação.
  • Preço: as tarifas por unidade de cada candidato pelo preço efetivo da sua organização. Um modelo sem preço conta como gratuito.
  • Latência: estimativas contínuas de latência e de taxa de falhas que o gateway mede no tráfego real.
  • Avaliações: as execuções de avaliação concluídas mais recentes da sua própria equipe que pontuam dois ou mais candidatos. Benchmarks da plataforma não são usados.
  • Continuidade da conversa: em uma solicitação de Responses que continua uma conversa, qual candidato atendeu a resposta anterior e quantos tokens ele processou, para que o juiz possa ponderar manter esse modelo e reduzir custo e latência.
A política selecionada indica ao juiz qual desses sinais importa mais:
  • balanced considera qualidade, preço, velocidade, capacidades e continuidade da conversa em conjunto.
  • price prioriza o menor custo esperado entre os modelos adequados à solicitação.
  • quality prioriza a adequação à tarefa e os resultados de avaliação, e ignora a continuidade da conversa.
  • speed prioriza a rapidez de resposta usando sinais contínuos de latência e confiabilidade.
Os requisitos de capacidade sempre se aplicam, independentemente da política. A melhor escolha pode mudar à medida que a solicitação, a disponibilidade dos modelos, o desempenho ou a conversa evoluem.

Privacidade e segurança

O juiz recebe um resumo limitado e higienizado da solicitação e dos seus requisitos de ferramentas. Credenciais e conteúdo binário bruto não são encaminhados. As políticas de segurança normais da organização continuam valendo, e o juiz só pode selecionar entre os modelos que a organização aprovou para a política.

Inspecione a política atual

Os endpoints auto são operações de administrador da organização: a chave de API precisa do escopo read:registry para listar as sobrescritas e de write:registry para alterá-las. O mode de cada sobrescrita é direct ou o nome da política com juiz, então leia esse campo primeiro para saber quais outros campos estão presentes.
Uma sobrescrita direta se parece com isto:

Configure um juiz LLM

O exemplo a seguir ativa a seleção de modelo por juiz para solicitações de LLM com a política balanced. Defina policy como price, quality ou speed para enfatizar outro objetivo. O juiz e todos os candidatos devem ser identificadores de modelos LLM válidos e disponíveis para a organização. Escolha um juiz rápido, sem raciocínio e compatível com saídas estruturadas, como openai:gpt-4.1-nano: o juiz é executado antes de cada solicitação que avalia e precisa retornar sua escolha como JSON estruturado. A disponibilidade de modelos é específica de cada organização; substitua os IDs do exemplo pelos IDs retornados por GET /models para a sua organização.
A sobrescrita armazenada informa a política como seu mode, além de quais dos modelos configurados podem ser usados agora:
Este conjunto de candidatos combina um modelo ajustado para português com um modelo geral: uma solicitação em português pode ser roteada para meetkai:functionary-pt, enquanto outras solicitações podem ser roteadas para openai:gpt-4.1-mini. Você pode configurar responses, completions, transcriptions e tts de forma independente. Endpoints sem uma sobrescrita da organização mantêm o roteamento direto por alias do registro de modelos.

Valide o modelo selecionado

Faça uma solicitação normal usando “model”: “auto”:
A resposta repete no campo model o alias que você enviou e informa em resolved_model o modelo que de fato atendeu à solicitação. Com uma política direta, é o destino do alias do registro, ou o modelo para o qual uma regra de redirecionamento enviou a solicitação. Com um juiz LLM configurado, é o candidato aprovado selecionado para a solicitação. resolved_model é um campo da API Responses. Chat Completions retorna apenas o nome solicitado em model e não informa o modelo que atendeu à solicitação. Ao receber uma resposta em streaming, leia resolved_model no evento final, como response.completed. O evento response.created traz apenas a primeira resolução, que um redirecionamento pode alterar mais adiante na solicitação. Uma solicitação em segundo plano com política de juiz não informa resolved_model até o evento final.

Erros

Quando o roteamento automático não consegue selecionar um modelo, a solicitação falha com HTTP 503 e um destes códigos em error.code: Uma solicitação em streaming recebe o erro como uma resposta HTTP normal, antes de o stream ser aberto. Uma solicitação em segundo plano que falha na seleção depois de entrar na fila termina com status: “failed” e o mesmo código em error.code. Em GET /models/auto, judge_resolvable: false aponta para auto_judge_unavailable, e um resolvable_candidate_model_ids vazio, para auto_no_eligible_models.

Restaure o roteamento direto

Defina uma política direta explicitamente:
Ou limpe a sobrescrita da sua organização para que “model”: “auto” volte a usar o padrão do cluster: