Enrutamiento automático

Cuando una solicitud usa “model”: “auto”, MKA1 aplica la política auto de la organización para ese endpoint. De forma predeterminada, auto es un alias directo a un modelo del registro de modelos. Las organizaciones también pueden configurar un juez LLM que elija entre un conjunto aprobado de modelos. El juez recibe señales sobre la solicitud, los modelos disponibles y la conversación existente para elegir el modelo más adecuado para el trabajo.

Endpoints compatibles

La selección mediante juez está disponible para varios tipos de solicitudes de IA.

Endpoint	Tipo de candidato
Responses y Chat Completions	LLM
Audio Transcriptions	Voz a texto
Text-to-Speech	Texto a voz

Solo se consideran los modelos adecuados para el tipo de solicitud. Por ejemplo, un modelo de TTS no se puede seleccionar para una solicitud de Responses.

Cómo funciona la selección de modelo

La organización define los modelos que se pueden seleccionar. En cada solicitud, MKA1 excluye los candidatos que ya no están activos en el registro de la organización o que no pueden atender la solicitud, como un modelo sin entrada de imagen para una solicitud que contiene una imagen. Si solo queda un modelo adecuado, MKA1 lo selecciona directamente; cuando hay varios, el juez configurado elige entre ellos. Cada solicitud que pasa por el juez hace una llamada adicional al modelo juez. La llamada se factura al precio del modelo juez y cuenta para tus presupuestos, pero no se incluye en el usage de la respuesta. También añade un viaje de ida y vuelta completo al juez antes de que empiece el modelo seleccionado, y una respuesta en streaming solo se abre después de que el juez haya elegido. Una política con juez no hace failover. Si el modelo seleccionado falla, la solicitud falla: MKA1 no prueba otro candidato y las reglas de redirección de los candidatos no se aplican. El estado de salud del proveedor no es una señal de selección, así que un modelo seleccionado cuyo proveedor no está disponible también hace fallar la solicitud. Si no queda ningún modelo adecuado, o si el juez configurado no está disponible o falla, MKA1 devuelve un error transparente en lugar de cambiar la política en silencio. Consulta Errores.

Señales usadas para la selección de modelo

MKA1 le da al juez una visión coherente de los factores que importan para la solicitud actual:

Solicitud y herramientas: la naturaleza de la tarea, las herramientas disponibles, la salida solicitada y si hay imágenes, audio o archivos. Se prefieren los modelos que pueden trabajar directamente con la entrada original.
Capacidades del modelo: modalidades y tipos de archivo compatibles, contexto disponible y otros requisitos necesarios para completar la solicitud.
Precio: las tarifas por unidad de cada candidato según el precio efectivo de tu organización. Un modelo sin precio cuenta como gratuito.
Latencia: estimaciones continuas de latencia y de tasa de fallos que el gateway mide sobre el tráfico real.
Evaluaciones: las ejecuciones de evaluación completadas más recientes de tu propio equipo que puntúan dos o más de los candidatos. No se usan benchmarks de la plataforma.
Continuidad de la conversación: en una solicitud de Responses que continúa una conversación, qué candidato atendió la respuesta anterior y cuántos tokens procesó, para que el juez pueda valorar quedarse en ese modelo y mantener bajos el costo y la latencia.

La política seleccionada le indica al juez cuál de estas señales importa más:

balanced considera la calidad, el precio, la velocidad, las capacidades y la continuidad de la conversación en conjunto.
price prioriza el menor costo esperado entre los modelos adecuados para la solicitud.
quality prioriza la adecuación a la tarea y los resultados de evaluación, e ignora la continuidad de la conversación.
speed prioriza la rapidez de respuesta usando señales continuas de latencia y fiabilidad.

Los requisitos de capacidad siempre se aplican, sin importar la política. La mejor elección puede cambiar a medida que evolucionan la solicitud, la disponibilidad de los modelos, el rendimiento o la conversación.

Privacidad y seguridad

El juez recibe un resumen acotado y depurado de la solicitud y de sus requisitos de herramientas. Las credenciales y el contenido binario sin procesar no se reenvían. Las políticas de seguridad habituales de la organización siguen aplicándose, y el juez solo puede seleccionar entre los modelos que la organización aprobó para la política.

Inspecciona la política actual

Los endpoints auto son operaciones de administrador de la organización: la clave de API necesita el scope read:registry para listar las sobrescrituras y write:registry para cambiarlas. El mode de cada sobrescritura es direct o el nombre de la política con juez, así que lee primero ese campo para saber qué otros campos están presentes.

import { SDK } from '@meetkai/mka1';
import type { ResponseObject } from '@meetkai/mka1/models/components';

const sdk = new SDK({ bearerAuth: 'Bearer <mka1-api-key>' });

const overrides = await sdk.llm.models.listOrgAutoModels();
for (const override of overrides.data) {
  switch (override.mode) {
    case 'direct':
      console.log(override.endpoint, '->', override.modelId, 'resolvable:', override.resolvable);
      break;
    case 'balanced':
    case 'price':
    case 'quality':
    case 'speed':
      console.log(
        override.endpoint, '->', override.mode,
        'judge:', override.judgeModelId,
        'candidates:', override.resolvableCandidateModelIds,
      );
      break;
  }
}

from meetkai_mka1 import SDK

sdk = SDK(bearer_auth="Bearer <mka1-api-key>")

overrides = sdk.llm.models.list_org_auto_models()
for override in overrides.data:
    if override.mode == "direct":
        print(override.endpoint, "->", override.model_id, "resolvable:", override.resolvable)
    else:
        print(
            override.endpoint, "->", override.mode,
            "judge:", override.judge_model_id,
            "candidates:", override.resolvable_candidate_model_ids,
        )

using MeetKai.MKA1;
using MeetKai.MKA1.Types.Components;
using System.Collections.Generic;

var sdk = new SDK(bearerAuth: "Bearer <mka1-api-key>");

var overrides = await sdk.Llm.Models.ListOrgAutoModelsAsync();
foreach (var o in overrides.ListOrgAutoModelsResponseValue!.Data)
{
    if (o.DirectOrgAutoModel is { } direct)
    {
        Console.WriteLine($"{direct.Endpoint} -> {direct.ModelId} (resolvable: {direct.Resolvable})");
    }
    else if (o.BalancedOrgAutoModel is { } judged)
    {
        Console.WriteLine($"{judged.Endpoint} -> balanced, judge {judged.JudgeModelId}, " +
            $"candidates {string.Join(", ", judged.ResolvableCandidateModelIds)}");
    }
    // las sobrescrituras price, quality y speed llegan en o.PriceOrgAutoModel,
    // o.QualityOrgAutoModel y o.SpeedOrgAutoModel con los mismos campos.
}

mka1 llm models get \
  --model-id auto

curl https://apigw.mka1.com/api/v1/llm/models/auto \
  --header 'Authorization: Bearer <mka1-api-key>'

Una sobrescritura directa se ve así:

{
  "object": "list",
  "data": [
    {
      "endpoint": "responses",
      "mode": "direct",
      "model_id": "meetkai:functionary-pt",
      "resolvable": true,
      "set_by": "user-org-admin-1",
      "set_at": "2026-09-01T12:00:00.000Z"
    }
  ]
}

Configura un juez LLM

El siguiente ejemplo activa la selección de modelo mediante juez para solicitudes de LLM con la política balanced. Define policy como price, quality o speed para priorizar otro objetivo. El juez y todos los candidatos deben ser identificadores de modelos LLM válidos y disponibles para la organización. Elige un juez rápido, sin razonamiento y compatible con salidas estructuradas, como openai:gpt-4.1-nano: el juez se ejecuta antes de cada solicitud que evalúa y debe devolver su elección como JSON estructurado. La disponibilidad de modelos depende de cada organización; reemplaza los IDs del ejemplo por los IDs que devuelve GET /models para tu organización.

const override = await sdk.llm.models.putOrgAutoModel({
  endpoint: 'responses',
  putOrgAutoModelRequest: {
    policy: 'balanced',
    judgeModelId: 'openai:gpt-4.1-nano',
    candidateModelIds: ['meetkai:functionary-pt', 'openai:gpt-4.1-mini'],
  },
});
if (override.mode === 'balanced') {
  console.log(override.judgeResolvable);              // true
  console.log(override.resolvableCandidateModelIds);  // ambos candidatos
}

override = sdk.llm.models.put_org_auto_model(
    endpoint="responses",
    body={
        "policy": "balanced",
        "judge_model_id": "openai:gpt-4.1-nano",
        "candidate_model_ids": ["meetkai:functionary-pt", "openai:gpt-4.1-mini"],
    },
)
print(override.mode)                            # "balanced"
print(override.judge_resolvable)                # True
print(override.resolvable_candidate_model_ids)  # ambos candidatos

var judged = await sdk.Llm.Models.PutOrgAutoModelAsync(
    endpoint: AutoEndpoint.Responses,
    body: PutOrgAutoModelRequestUnion.CreatePutOrgAutoModelRequest2(new PutOrgAutoModelRequest2()
    {
        Policy = Policy.Balanced,
        JudgeModelId = "openai:gpt-4.1-nano",
        CandidateModelIds = new List<string> { "meetkai:functionary-pt", "openai:gpt-4.1-mini" },
    })
);
var balanced = judged.OneOf!.BalancedOrgAutoModel!;
Console.WriteLine(balanced.JudgeResolvable);                               // True
Console.WriteLine(string.Join(", ", balanced.ResolvableCandidateModelIds)); // ambos candidatos

mka1 llm models put-org-auto-model \
  --body '{
    "policy": "balanced",
    "judge_model_id": "openai:gpt-4.1-nano",
    "candidate_model_ids": [
      "meetkai:functionary-pt",
      "openai:gpt-4.1-mini"
    ]
  }' \
  --endpoint responses

curl https://apigw.mka1.com/api/v1/llm/models/auto/responses \
  --request PUT \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <mka1-api-key>' \
  --data '{
    "policy": "balanced",
    "judge_model_id": "openai:gpt-4.1-nano",
    "candidate_model_ids": [
      "meetkai:functionary-pt",
      "openai:gpt-4.1-mini"
    ]
  }'

La sobrescritura guardada informa la política como su mode, además de cuáles de los modelos configurados se pueden usar ahora:

{
  "endpoint": "responses",
  "mode": "balanced",
  "judge_model_id": "openai:gpt-4.1-nano",
  "candidate_model_ids": ["meetkai:functionary-pt", "openai:gpt-4.1-mini"],
  "judge_resolvable": true,
  "resolvable_candidate_model_ids": ["meetkai:functionary-pt", "openai:gpt-4.1-mini"],
  "set_by": "user-org-admin-1",
  "set_at": "2026-09-01T12:00:00.000Z"
}

Este conjunto de candidatos combina un modelo ajustado para portugués con uno general: una solicitud en portugués puede enrutarse a meetkai:functionary-pt, mientras que las demás solicitudes pueden enrutarse a openai:gpt-4.1-mini. Puedes configurar responses, completions, transcriptions y tts de forma independiente. Los endpoints sin una sobrescritura de la organización mantienen el enrutamiento directo por alias del registro de modelos.

Valida el modelo seleccionado

Haz una solicitud normal con “model”: “auto”:

const response = await sdk.llm.responses.create({
  xOnBehalfOf: '<end-user-id>', // opcional — atribuye la solicitud a uno de tus usuarios finales
  responsesCreateRequest: {
    model: 'auto',
    input: 'Resuma este relatório de incidente e liste os três próximos passos de maior risco.',
    maxOutputTokens: 300,
  },
}) as ResponseObject;
console.log(response.model);         // "auto"
console.log(response.resolvedModel); // p. ej. "meetkai:functionary-pt"

import OpenAI from 'openai';

const openai = new OpenAI({
  apiKey: '<mka1-api-key>',
  baseURL: 'https://apigw.mka1.com/api/v1/llm/',
  defaultHeaders: { 'X-On-Behalf-Of': '<end-user-id>' },
});

const response = await openai.responses.create({
  model: 'auto',
  input: 'Resuma este relatório de incidente e liste os três próximos passos de maior risco.',
  max_output_tokens: 300,
  stream: false,
});
console.log(response.model); // "auto"
// resolved_model es una extensión de MKA1, por eso no está en el tipo de respuesta del SDK de OpenAI.
console.log((response as { resolved_model?: string }).resolved_model); // p. ej. "meetkai:functionary-pt"

res = sdk.llm.responses.create(
    model="auto",
    input="Resuma este relatório de incidente e liste os três próximos passos de maior risco.",
    max_output_tokens=300,
    x_on_behalf_of="<end-user-id>",  # opcional — atribuye la solicitud a uno de tus usuarios finales
)
print(res.model)           # "auto"
print(res.resolved_model)  # p. ej. "meetkai:functionary-pt"

var res = await sdk.Llm.Responses.CreateAsync(new ResponsesCreateRequest()
{
    Model = "auto",
    Input = ResponsesCreateRequestInput.CreateStr(
        "Resuma este relatório de incidente e liste os três próximos passos de maior risco."),
    MaxOutputTokens = 300,
});
Console.WriteLine(res.ResponseObject!.Model);         // auto
Console.WriteLine(res.ResponseObject!.ResolvedModel); // p. ej. meetkai:functionary-pt

mka1 llm responses create \
  --model auto \
  --input '"Resuma este relatório de incidente e liste os três próximos passos de maior risco."' \
  -H 'X-On-Behalf-Of: <end-user-id>'

curl https://apigw.mka1.com/api/v1/llm/responses \
  --request POST \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <mka1-api-key>' \
  --data '{
    "model": "auto",
    "input": "Resuma este relatório de incidente e liste os três próximos passos de maior risco.",
    "max_output_tokens": 300
  }'

La respuesta repite en su campo model el alias que enviaste e indica en resolved_model el modelo que realmente atendió la solicitud. Con una política directa, es el destino del alias del registro, o el modelo al que una regla de redirección envió la solicitud. Con un juez LLM configurado, es el candidato aprobado que se seleccionó para la solicitud. resolved_model es un campo de la API de Responses. Chat Completions devuelve solo el nombre solicitado en model y no informa el modelo que atendió la solicitud. Cuando recibes una respuesta en streaming, lee resolved_model del evento final, como response.completed. El evento response.created lleva solo la primera resolución, que una redirección puede cambiar más adelante en la solicitud. Una solicitud en segundo plano con una política de juez no informa resolved_model hasta el evento final.

Errores

Cuando el enrutamiento automático no puede seleccionar un modelo, la solicitud falla con HTTP 503 y uno de estos códigos en error.code:

Código	Causa
`auto_judge_unavailable`	El modelo juez no está activo en el registro de la organización, está oculto o no es un LLM.
`auto_no_eligible_models`	Ningún candidato puede atender la solicitud, o el candidato seleccionado dejó de estar disponible antes de que se le enviara la solicitud.
`auto_judge_failed`	La llamada al juez falló o tardó más de 30 segundos, o el juez no devolvió uno de los candidatos.

Una solicitud en streaming recibe el error como una respuesta HTTP normal, antes de que se abra el stream. Una solicitud en segundo plano que falla en la selección después de entrar en la cola termina con status: “failed” y el mismo código en error.code. En GET /models/auto, judge_resolvable: false apunta a auto_judge_unavailable, y un resolvable_candidate_model_ids vacío, a auto_no_eligible_models.

Restablece el enrutamiento directo

Define una política directa de forma explícita:

const override = await sdk.llm.models.putOrgAutoModel({
  endpoint: 'responses',
  putOrgAutoModelRequest: { modelId: 'meetkai:functionary-pt' },
});
if (override.mode === 'direct') {
  console.log(override.modelId, override.resolvable); // "meetkai:functionary-pt" true
}

override = sdk.llm.models.put_org_auto_model(
    endpoint="responses",
    body={"model_id": "meetkai:functionary-pt"},
)
print(override.mode, override.model_id, override.resolvable)  # direct meetkai:functionary-pt True

var direct = await sdk.Llm.Models.PutOrgAutoModelAsync(
    endpoint: AutoEndpoint.Responses,
    body: PutOrgAutoModelRequestUnion.CreatePutOrgAutoModelRequest1(
        new PutOrgAutoModelRequest1() { ModelId = "meetkai:functionary-pt" })
);
Console.WriteLine(direct.OneOf!.DirectOrgAutoModel!.ModelId); // meetkai:functionary-pt

mka1 llm models put-org-auto-model \
  --body '{ "model_id": "meetkai:functionary-pt" }' \
  --endpoint responses

curl https://apigw.mka1.com/api/v1/llm/models/auto/responses \
  --request PUT \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <mka1-api-key>' \
  --data '{ "model_id": "meetkai:functionary-pt" }'

O bien, borra la sobrescritura de tu organización para que “model”: “auto” vuelva a usar el valor predeterminado del clúster:

const cleared = await sdk.llm.models.deleteOrgAutoModel({ endpoint: 'responses' });
console.log(cleared.cleared); // true

cleared = sdk.llm.models.delete_org_auto_model(endpoint="responses")
print(cleared.cleared)  # True

var cleared = await sdk.Llm.Models.DeleteOrgAutoModelAsync(endpoint: AutoEndpoint.Responses);
Console.WriteLine(cleared.DeleteOrgAutoModelResponseValue!.Cleared); // True

mka1 llm models delete-org-auto-model \
  --endpoint responses

curl https://apigw.mka1.com/api/v1/llm/models/auto/responses \
  --request DELETE \
  --header 'Authorization: Bearer <mka1-api-key>'

Gestión de modelos

Operaciones

Control de acceso

Seguridad y cumplimiento

Comparativas

Enrutamiento automático

Endpoints compatibles

Cómo funciona la selección de modelo

Señales usadas para la selección de modelo

Privacidad y seguridad

Inspecciona la política actual

Configura un juez LLM

Valida el modelo seleccionado

Errores

Restablece el enrutamiento directo

​Endpoints compatibles

​Cómo funciona la selección de modelo

​Señales usadas para la selección de modelo

​Privacidad y seguridad

​Inspecciona la política actual

​Configura un juez LLM

​Valida el modelo seleccionado

​Errores

​Restablece el enrutamiento directo

Endpoints compatibles

Cómo funciona la selección de modelo

Señales usadas para la selección de modelo

Privacidad y seguridad

Inspecciona la política actual

Configura un juez LLM

Valida el modelo seleccionado

Errores

Restablece el enrutamiento directo