Cómo crear un modelo de enrutamiento LLM que tenga en cuenta los costos sin sacrificar la calidad

El enrutamiento del modelo LLM teniendo en cuenta los costos no debería significar enviar todas las solicitudes al modelo más barato disponible. Esto crea un modo de falla silencioso: las facturas mejoran durante algunas semanas, luego los equipos de producto descubren esquemas rotos, razonamientos más débiles, tonos inconsistentes o borradores de soporte que requieren una mayor limpieza humana.

El mejor patrón es una política de enrutamiento respaldada por evaluación. Clasifique la solicitud, defina la calidad mínima aceptable para esa tarea, elimine las rutas que no pueden satisfacer las limitaciones de capacidad o gobernanza, estime la economía de la ruta y luego elija el modelo elegible de menor costo. La decisión de enrutamiento se vuelve explicable durante una revisión de costos porque está vinculada a una versión de la política, no a las preferencias del desarrollador o a un valor predeterminado vago del proveedor.

Qué se está optimizando el enrutamiento con reconocimiento de costos

Un enrutador práctico optimiza la ruta más económica que aún cumple con los requisitos operativos de la tarea. Esto es diferente a optimizar para el modelo más económico.

Datos: los principales proveedores de modelos publican precios de tokens con dimensiones separadas, como tokens de entrada, tokens de entrada almacenados en caché, tokens de salida, almacenamiento en caché de avisos y procesamiento por lotes. Algunos proveedores también exponen campos de uso que informan sobre el comportamiento del token almacenado en caché. Esto significa que la opción de menor costo puede cambiar según la forma del mensaje, la longitud de salida esperada, la elegibilidad de la caché y si la carga de trabajo se puede ejecutar de forma asincrónica.

Recomendación: trate el enrutamiento como un problema de política dentro de una puerta de enlace API de IA multimodelo, no como una declaración de cambio a nivel de aplicación. La puerta de enlace ve registros de capacidad del proveedor, reglas de inquilinos, API metadatos clave, tablas de precios, telemetría de uso y comportamiento de respaldo en un solo lugar.

Predicción: los equipos que mantienen la lógica de enrutamiento dispersa en los repositorios de aplicaciones tendrán dificultades para explicar los cambios de costos más adelante. Es posible que aún reduzcan el gasto, pero tendrán pruebas más débiles de por qué una solicitud determinada utilizó un modelo determinado.

Comience con clases de tareas, no con nombres de proveedores

El enrutador necesita una etiqueta de carga de trabajo antes de poder tomar una decisión útil. Un único modelo predeterminado no puede representar el perfil de riesgo de cada solicitud.

Las clases de tareas útiles incluyen:

• Extracción: convierte texto no estructurado en campos, a menudo con una estricta validación del esquema.
• Clasificación: asigna etiquetas, prioridad, intención, sentimiento o categorías de enrutamiento.
• Resumen: comprime los datos extensos conservando al mismo tiempo los hechos y las decisiones clave.
• Redacción de atención al cliente: genera una respuesta que un humano puede revisar o enviar.
• Síntesis de respuesta de RAG: respuesta del contexto recuperado con requisitos de citación o fundamento.
• Revisión de código: inspecciona las diferencias o los archivos fuente para detectar problemas de corrección, riesgo o estilo.
• Análisis de contexto prolongado: motivo de contratos, transcripciones, registros, políticas o paquetes de investigación.
• Soporte para decisiones de alto impacto: cualquier flujo de trabajo en el que una mala respuesta pueda afectar el dinero, el cumplimiento, la seguridad o la confianza del cliente.

La clase de tarea puede provenir de metadatos de solicitud explícita, un alcance clave API, una ruta de aplicación o un clasificador ligero. Los metadatos explícitos suelen ser mejores que inferir la intención a partir del texto del mensaje, porque los mensajes vagos obligan al enrutador a adoptar valores predeterminados conservadores.

Asociar un piso de calidad a cada tarea

El enrutamiento consciente de los costos solo funciona si cada tarea tiene un nivel mínimo de calidad. Sin uno, el enrutador no tiene una forma fundamental de rechazar un modelo más barato.

Un piso de calidad puede incluir varios controles:

• Conjunto de evaluación reproducible: ejemplos representativos de desarrollo y producción, sin datos confidenciales cuando sea necesario.
• Validez del esquema: la salida debe analizarse, validarse según el esquema canónico y evitar campos no admitidos.
• Criterios de contenido: la respuesta debe seguir las reglas de estilo, rechazo, fundamento e integridad de la tarea.
• Criterios de seguridad: la salida no debe filtrar instrucciones ocultas, ignorar los límites de las políticas ni ejecutar instrucciones que no sean de confianza a partir del contenido recuperado.
• Revisión humana: necesaria para flujos de trabajo de alto impacto o para la promoción de una nueva ruta.
• Umbral de regresión: la ruta candidata debe igualar o superar la ruta actual en categorías de fallas críticas, no solo en la puntuación promedio.

Hecho: la documentación del proveedor describe las evaluaciones como una forma de probar los resultados del modelo con criterios de estilo y contenido específicos. Un producto de evaluación alojado está programado para quedar obsoleto, por lo que los sistemas de enrutamiento deben almacenar conjuntos de datos de evaluación independientes del proveedor, resultados esperados, rúbricas de calificación y resultados en lugar de depender de una superficie de evaluación alojada por el proveedor.

Recomendación: almacene los resultados de la evaluación por clase de tarea, modelo, versión del adaptador del proveedor, versión de solicitud, versión del esquema y versión de evaluación. Una ruta no debería ser elegible simplemente porque un modelo sea nuevo o más barato. Se vuelve elegible cuando pasa el límite de calidad actual de la tarea.

Crear un registro de capacidades de proveedores

Antes de estimar el costo, elimine cualquier ruta que no pueda satisfacer la solicitud. Este paso evita que el enrutador seleccione un modelo económico que carezca de las capacidades requeridas.

Un registro de capacidad debe incluir:

• Modalidades de entrada y salida admitidas.
• Límites de la ventana de contexto.
• Salida estructurada y soporte para llamadas de herramientas.
• Soporte de transmisión.
• Soporte de almacenamiento en caché rápido y disponibilidad de telemetría de caché.
• Soporte del lote API.
• Opciones de procesamiento regionales.
• Términos de supervisión de abuso y retención de datos que son importantes para su política.
• Dimensiones del límite de tarifa y capacidad actual.
• Diferencias conocidas en los contratos de salida en su capa de adaptador.

Este registro debe mantenerse separado de los mensajes de la aplicación. Pertenece cerca de la capa de enrutamiento y adaptador de proveedor, donde el sistema puede comparar modelos sin filtrar suposiciones específicas del proveedor en cada aplicación.

Estimar el costo de la ruta antes de la selección

El enrutador no puede conocer el costo final antes de la ejecución, pero puede estimarlo lo suficientemente bien como para elegir entre las rutas elegibles. La estimación debe incluir las variables que realmente mueven la factura.

estimated_cost =
  input_tokens * input_token_price
  + cached_input_tokens * cached_input_token_price
  + output_tokens_expected * output_token_price
  + tool_call_overhead_expected
  + retry_allowance_expected
  - batch_discount_if_eligible

Utilice la telemetría reciente para estimar los tokens de salida por clase de tarea. Por ejemplo, las tareas de extracción pueden tener una duración de resultados limitada, mientras que el análisis de contexto prolongado puede variar ampliamente. Los agentes que utilizan herramientas pueden tener costos ocultos adicionales debido a la planificación de llamadas a herramientas, reintentos y mensajes intermedios.

La estimación de costos también debe tener en cuenta la elegibilidad de caché y lotes:

• Elegibilidad de la caché: prefijo de aviso estable, instrucciones del sistema reutilizables, contexto recuperado repetido, comportamiento del proveedor admitido y suficiente probabilidad de acierto en la caché.
• Elegibilidad por lotes: la carga de trabajo puede esperar, tiene un manejo de solicitudes idempotente, tiene un seguimiento de trabajos duradero y no necesita transmisión interactiva.
• Riesgo del token de salida: el modelo tiende a producir respuestas más largas o más cortas para la misma tarea, y el truncamiento perjudicaría la calidad.
• Riesgo de reintento: el proveedor o modelo tiene tasas de error, tasas de reparación de esquemas o errores de latencia elevados para esta tarea.

Aquí es donde el enrutamiento de costos se conecta con una gestión de costos de LLM más amplia. La tabla de precios por sí sola no es suficiente. El enrutador necesita metadatos de solicitud, estructura de avisos, mediciones de aciertos de caché y datos de uso establecido para saber si los ahorros esperados realmente se produjeron.

Usar niveles de modelo en lugar de un valor predeterminado global

Una política escalonada es más fácil de explicar que una lista larga de excepciones específicas del proveedor. Cada nivel debe contener uno o más modelos elegibles que hayan superado los umbrales de tareas específicas.

No permita que el nivel reemplace las evaluaciones. Un modelo puede ser económico para la clasificación pero inadecuado para la redacción de apoyo. Otro modelo puede ser sólido para el resumen, pero demasiado costoso para el etiquetado determinista corto.

Ruta con una secuencia de decisión explícita

Un enrutador que tenga en cuenta los costos debe ser lo suficientemente determinista como para poder realizar depuraciones. La implementación exacta varía, pero la secuencia de decisión debe ser estable.

1. Leer metadatos de inquilino, API clave, entorno y aplicación.
2. Identificar la clase de tarea a partir de metadatos explícitos o resultados del clasificador.
3. Cargue la versión de la política de enrutamiento para ese inquilino o espacio de trabajo.
4. Aplicar restricciones de gobernanza, como retención de datos, región, lista de modelos permitidos y restricciones de funciones.
5. Filtrar por capacidades requeridas: longitud del contexto, herramientas, salida estructurada, streaming, modalidad y soporte por lotes.
6. Filtrar por nivel mínimo de calidad respaldado por evaluaciones para la clase de tarea.
7. Estime el costo utilizando tokens de entrada, tokens de salida esperados, elegibilidad de caché, elegibilidad de lotes y riesgo de reintento.
8. Aplicar la política de presupuesto y las preferencias de los inquilinos.
9. Seleccione la ruta elegible de menor costo.
10. Adjuntar ruta alternativa, tiempo de espera, reintento y política de reparación.
11. Registrar la decisión con un código de motivo estable.

En pseudocódigo, el enrutador debería parecerse más a una evaluación de políticas que a una preferencia de proveedor codificada:

function selectRoute(request):
  context = buildRoutingContext(request)
  task = classifyTask(context)
  policy = loadPolicy(context.tenant_id, task)

  candidates = modelRegistry.models
    .filter(model => policy.allows(model))
    .filter(model => model.supports(context.required_capabilities))
    .filter(model => evalStore.passes(task, model, policy.quality_floor))

  priced = candidates.map(model => ({
    model,
    estimated_cost: estimateCost(model, context),
    expected_latency: estimateLatency(model, context),
    risk_flags: estimateRisk(model, context)
  }))

  eligible = priced.filter(route => route.risk_flags.noneBlocking())
  return minBy(eligible, route => route.estimated_cost)

Registrar cada decisión de enrutamiento

Si finanzas pregunta por qué se usó un modelo premium, o ingeniería pregunta por qué bajó la calidad, el enrutador debe responder a partir de registros. No confíe en reconstruir la intención a partir de indicaciones posteriores al hecho.

Registra estos campos para cada solicitud:

• ID de solicitud, ID de inquilino, API ID de clave, ID de aplicación y entorno.
• Resultado y confianza del clasificador de tareas.
• Versión de la política de enrutamiento.
• Versión del conjunto de datos de evaluación y puerta de calidad utilizadas.
• Modelos elegibles y modelos rechazados.
• Razón por la que se excluyó cada modelo rechazado.
• Tokens de entrada, entrada en caché y salida estimados.
• Costo de ruta estimado y costo final liquidado cuando esté disponible.
• Proveedor, modelo, versión del adaptador y nivel seleccionados.
• Ruta alternativa y política de reintento.
• Telemetría de acierto o error en caché cuando esté disponible.
• Modo de ejecución por lotes versus sincrónico.
• Validación de esquemas, intentos de reparación, estado de rechazo e indicadores de seguridad.

Estos registros también admiten la LLM API atribución de costos, porque la selección del modelo es solo una parte del gasto. Los equipos aún necesitan asignar costos por inquilino, espacio de trabajo, clave, producto, flujo de trabajo o cliente.

Agregue controles de deriva antes de promocionar rutas más económicas

Cambios en el comportamiento del modelo, los precios, las indicaciones y la combinación de cargas de trabajo. Una ruta que era segura el mes pasado puede debilitarse después de una revisión inmediata o una actualización del modelo.

Un circuito básico de control de deriva debe incluir:

• Muestra de solicitudes de producción recientes por clase de tarea.
• Eliminar o transformar datos confidenciales según la política.
• Reproducir muestras a través de rutas actuales y candidatas.
• Compare la calidad, la validez del esquema, el comportamiento de rechazo, el costo y la latencia.
• Revise los errores por categoría, no solo por puntuación agregada.
• Promocionar la ruta más barata solo si cumple con el piso de calidad y las restricciones operativas.
• Canary es la nueva ruta para un pequeño porcentaje del tráfico.
• Revertir automáticamente en caso de falla del esquema, sobrecostos, incumplimiento de latencia o escalada de revisión humana.

Recomendación: haga de la promoción de rutas un evento de gestión de cambios. Registre quién lo aprobó, qué conjunto de evaluación pasó, qué porcentaje de tráfico afecta, cuándo vence o necesita revisión y cómo funciona la reversión.

Otorgue anulaciones a los equipos, pero haga que caduquen

Existen motivos legítimos para anular el enrutamiento: incidente del proveedor, emergencia presupuestaria, revisión del cumplimiento, derivación del cliente o regresión del modelo. El problema no es la anulación. El problema es una anulación que se convierte en una política permanente invisible.

Cada anulación debe incluir:

• Ámbito: inquilino, aplicación, API clave, clase de tarea, modelo, proveedor o región.
• Motivo: incidente, presupuesto, calidad, cumplimiento, latencia o solicitud del cliente.
• Aprobador.
• Hora de inicio y hora de vencimiento.
• Impacto esperado en el coste, la latencia y la calidad.
• Condición de reversión.

Las anulaciones vencidas no deberían cerrarse según la política de enrutamiento normal o requerir renovación. Esto evita que las decisiones de emergencia se conviertan en costos ocultos o riesgos de calidad.

Compensaciones que se deben hacer explícitas

El enrutamiento consciente de los costos tiene un costo operativo real. Todavía vale la pena hacerlo cuando el gasto en LLM es significativo, pero las compensaciones deben ser visibles.

• Dependencia de los metadatos: la calidad del enrutamiento depende de etiquetas de tareas y metadatos de carga de trabajo precisos. Las etiquetas que faltan impulsan el tráfico hacia valores predeterminados conservadores.
• Mantenimiento de evaluaciones: las evaluaciones de tareas necesitan actualizaciones a medida que cambian las indicaciones, los productos y el comportamiento del usuario.
• Complejidad del proveedor: los descuentos en caché y por lotes pueden mejorar la economía, pero hacen que la lógica de enrutamiento sea más compleja.
• Riesgo de portabilidad: las funciones específicas del proveedor deben estar en adaptadores y registros de capacidad, no en el código del producto.
• Incertidumbre de la estimación: la longitud de la salida final, las llamadas a herramientas, los reintentos y los aciertos de caché no se conocen completamente antes de la ejecución.
• Carga de explicabilidad: la optimización agresiva puede hacer que el comportamiento del producto sea difícil de explicar a menos que cada decisión se registre con la versión de la política y los códigos de motivo.

Lista de verificación de implementación

• Defina clases de tareas para los principales flujos de trabajo de LLM por gasto e impacto empresarial.
• Cree conjuntos de evaluación y niveles mínimos de calidad para cada clase de tarea.
• Crear un registro de capacidades de proveedores y modelos.
• Almacenar tablas de precios actuales y modificadores de precios por proveedor, modelo y modo de ejecución.
• Estimar tokens de entrada, tokens de salida esperados, elegibilidad de caché, elegibilidad de lotes y riesgo de reintento.
• Filtrar candidatos por restricciones de gobernanza antes de optimizar costos.
• Seleccione el modelo de menor costo solo después de pasar los controles de capacidad y calidad.
• Registrar rutas seleccionadas y rechazadas con códigos de motivo.
• Compare el costo estimado con el uso liquidado y los datos de la factura.
• Ejecute evaluaciones periódicas de repetición antes de promocionar rutas más baratas.
• Cambios de ruta canarios y definición de activadores de reversión.
• Requerir fechas de vencimiento para anulaciones manuales.

Conclusión

El objetivo práctico no es dirigir todas las solicitudes a un modelo más económico. El objetivo es dejar de pagar de más por el trabajo rutinario y al mismo tiempo proteger la calidad, los contratos, las reglas de gobernanza y la explicabilidad.

Construya el enrutador en torno a clases de tareas, niveles mínimos de calidad, capacidades de proveedores, estimaciones de costos y registros de políticas. Luego elija la ruta elegible de menor costo. Esa palabra, elegible, es lo que separa el enrutamiento que tiene en cuenta los costos del enrutamiento del modelo más económico.

Lectura relacionada

• límites de gasto a nivel de puerta de enlace