Saltar al contenido principal
Utiliza auto_routing cuando quieras que el gateway elija entre variantes cuantizadas, MoE y densas según la complejidad de la solicitud. Cuando las variantes hermanas aún no están registradas, usa auto_routing_debug para verificar la decisión de enrutamiento en sí. La metadata de la respuesta incluirá:
  • routed_model
  • auto_routing_debug
auto_routing_debug es una cadena JSON compacta con el modelo solicitado, el nivel seleccionado, el esfuerzo de razonamiento, el puntaje y las razones.

Ejecutar la validación

La verificación en producción del 31 de marzo de 2026 utilizó el endpoint de Responses directamente con un modelo fijo y una bandera de depuración opcional.
bash
Si el despliegue está en vivo, la metadata de la respuesta incluye un payload como este:
El routed_model aún puede ser igual al modelo solicitado si no existe una familia hermana compatible en producción todavía. Eso no significa que la heurística haya fallado. La prueba está en desired_tier, reasoning_effort, score y reasons dentro de auto_routing_debug.

Método de prueba

La verificación en producción utilizó seis solicitudes Responses contra https://apigw.mka1.com/api/v1/llm/responses. Cada solicitud estableció:
  • model: "meetkai:functionary-pt"
  • auto_routing: true
  • auto_routing_debug: true
La matriz cubrió:
  1. Prompt corto de transformación en inglés
  2. Prompt de salida estructurada de longitud media
  3. Prompt largo de análisis de incidentes
  4. Prompt forzado de uso de herramienta
  5. Prompt corto de transformación en portugués
  6. Prompt largo de análisis de incidentes en portugués
Para cada respuesta, la validación registró:
  • Estado HTTP
  • metadata.routed_model
  • metadata.auto_routing_debug parseado
  • reasoning.effort efectivo

Resultados en producción en vivo

Estos fueron los resultados observados en producción el 31 de marzo de 2026 después del despliegue del PR 321: Las seis solicitudes devolvieron 200 OK. Las seis respuestas incluyeron auto_routing_debug. El nivel observado coincidió con el nivel esperado en todos los casos.

Fragmentos de respuesta en crudo

Los siguientes ejemplos están adaptados del registro de producción en vivo.

Prompt corto de transformación

Solicitud:
Fragmento de respuesta observado:

Prompt de salida estructurada

Solicitud:
Fragmento de respuesta observado:

Prompt largo de análisis de incidentes

Solicitud:
Fragmento de respuesta observado:

Prompt forzado de uso de herramienta

Solicitud:
Fragmento de respuesta observado:

Prompt de transformación en portugués

Solicitud:
Fragmento de respuesta observado:

Prompt de análisis de incidentes en portugués

Solicitud:
Fragmento de respuesta observado:

Interpretar el resultado

Utiliza esta lista de verificación al validar un despliegue:
  1. Confirma que la respuesta incluya metadata.auto_routing_debug.
  2. Parsea la cadena JSON e inspecciona desired_tier.
  3. Verifica que reasoning_effort coincida con el nivel de complejidad esperado.
  4. Verifica que las reasons coincidan con las características del prompt que pretendías activar.
  5. Si existen variantes hermanas, confirma también que routed_model cambie al hermano esperado.
Si falta auto_routing_debug, probablemente la imagen de la API desplegada aún no incluye la funcionalidad.

Notas

  • auto_routing_debug está destinado a validación y verificaciones de despliegue. Es opcional y no debe habilitarse por defecto para el tráfico de producción normal.
  • auto_routing_debug está disponible actualmente en la API de Responses.
  • Las heurísticas para prompts en portugués están incluidas en la lógica de enrutamiento de producción actual, por lo que los prompts cortos de transformación y los prompts complejos de análisis de incidentes pueden validarse tanto en inglés como en portugués.