La mayoría de los equipos reduce los costos de inferencia reescribiendo prompts o cambiando modelos manualmente. Ambos enfoques requieren criterio humano constante y se rompen bajo volumen. Un router de prompts resuelve esto a nivel de arquitectura. Clasifica cada solicitud antes de la inferencia y la envía al modelo correcto de forma automática.
El resultado: dejas de pagar precios de clase GPT-4 por tareas que un modelo más pequeño resuelve correctamente.
Qué hace realmente un router de prompts
Un router de prompts se ubica entre tu aplicación y tus endpoints de modelos. Recibe una solicitud entrante, la evalúa contra un conjunto de criterios de enrutamiento, le asigna un nivel y la reenvía al modelo apropiado.
No modifica el prompt. No cambia el formato de salida. Solo decide qué modelo procesa la solicitud.
La decisión de enrutamiento ocurre en milisegundos. El ahorro de costos se acumula en cada solicitud.
Los cuatro criterios de enrutamiento
Antes de escribir cualquier lógica de enrutamiento, define tu superficie de decisión. Cuatro criterios cubren la mayoría de los casos en producción.
Complejidad de la tarea. ¿Es una búsqueda, una clasificación, un resumen o una tarea de razonamiento en múltiples pasos? Las búsquedas y clasificaciones rara vez necesitan un modelo frontier.
Cantidad de tokens. La longitud de tokens de entrada es un proxy confiable de complejidad. Una solicitud de menos de 300 tokens suele ser liviana. Más de 2,000 tokens generalmente indica una tarea compleja.
Requisito de latencia. Algunas solicitudes son de cara al usuario y necesitan respuesta en menos de 1 segundo. Otras son trabajos en lote donde 10 segundos es aceptable. La tolerancia a la latencia afecta qué modelos son elegibles.
Umbral de costo. Define un techo de costo por solicitud para cada nivel. Por ejemplo: nivel liviano ≤ $0.001, nivel estándar ≤ $0.005, nivel complejo ≤ $0.02. Estos números te obligan a ser explícito sobre el gasto aceptable por tipo de tarea.
Documenta estos cuatro criterios antes de construir cualquier cosa. Se convierten en tu especificación de enrutamiento.
Paso a paso: clasificar solicitudes en niveles
Tres niveles cubren la mayoría de las cargas de trabajo.
- Liviano: Extracción simple, clasificación sí/no, búsqueda de forma corta. Cantidad de tokens menor a 400. Sensible a la latencia o de alto volumen.
- Estándar: Resumen, generación de salida estructurada, razonamiento moderado. Cantidad de tokens entre 400 y 1,500. Tolerancia moderada a la latencia.
- Complejo: Razonamiento en múltiples pasos, análisis de documentos largos, generación de código con contexto. Cantidad de tokens mayor a 1,500 o señales explícitas de complejidad.
Para clasificar solicitudes automáticamente, ejecuta un clasificador liviano antes de la llamada de inferencia principal. Este clasificador puede ser un modelo pequeño, una función basada en reglas o una combinación.
Un punto de partida práctico es una función basada en reglas:
- Contar los tokens de entrada.
- Verificar señales explícitas de complejidad en los metadatos de la solicitud (por ejemplo, un campo
task_typeque tu aplicación ya establece). - Aplicar una lista de palabras clave para tipos de tareas complejas conocidas (por ejemplo, "comparar", "analizar", "generar código").
- Asignar un nivel basado en la puntuación combinada.
Este clasificador no debe agregar más de 20–50ms a tu pipeline. Si usas un modelo para la clasificación, usa el más pequeño disponible — un modelo de 7B parámetros o un clasificador fine-tuned es suficiente. No uses un modelo frontier para decidir si usar un modelo frontier.
Registra cada decisión de clasificación. Después de dos semanas, audita los logs. Encontrarás solicitudes mal clasificadas. Ajusta tus reglas o vuelve a entrenar tu clasificador con datos reales.
Asignar modelos objetivo por nivel
Una vez definidos los niveles, mapea cada uno a un modelo primario.
Ejemplo de mapeo:
- Liviano →
gpt-4o-minio modelo pequeño equivalente - Estándar →
gpt-4oo un modelo de nivel medio - Complejo →
gpt-4ocon contexto extendido, o un modelo optimizado para razonamiento
No escribas nombres de modelos como strings dispersos por tu código. Almacena el mapeo de nivel a modelo en un único archivo de configuración. Cuando un modelo quede obsoleto o quieras cambiar de proveedor, modificas un solo archivo.
Construir la cadena de fallback
Cada nivel necesita un fallback. Los endpoints de modelos se caen. Los límites de tasa se alcanzan. Un router sin cadena de fallback se convierte en un punto único de falla.
Para cada nivel, define:
- Modelo primario — el destino por defecto.
- Modelo secundario — mismo nivel, proveedor o endpoint diferente.
- Modelo de escalada — un nivel arriba, usado solo cuando el primario y el secundario no están disponibles.
Ejemplo de cadena de fallback para el nivel liviano:
- Primario:
gpt-4o-mini - Secundario:
claude-haiku(o equivalente) - Escalada:
gpt-4o(modelo de nivel estándar, usado solo como último recurso)
El paso de escalada cuesta más. Eso es aceptable. La alternativa es una solicitud fallida.
Define un timeout para cada intento de modelo. Si el primario no responde en 800ms, pasa al secundario. Si el secundario no responde en 1,200ms, escala. Registra cada evento de fallback. Un pico en el uso de fallback es una señal temprana de que un endpoint primario está degradándose.
Cómo se ve esto en la práctica
Un equipo que ejecuta 50,000 solicitudes por día sin enrutamiento envía todo a un modelo frontier. A un promedio de $0.01 por solicitud, eso es $500/día.
Con un router que clasifica correctamente el 60% de las solicitudes como livianas y las envía a un modelo pequeño a $0.0008 por solicitud:
- 30,000 solicitudes livianas × $0.0008 = $24
- 20,000 solicitudes estándar/complejas × $0.01 = $200
- Total: $224/día
Eso es una reducción de costos del 55%. Los prompts no cambiaron. Las salidas para tareas livianas son equivalentes. El único cambio es a dónde va cada solicitud.
La disciplina operativa que lo hace funcionar
Un router no es una construcción de una sola vez. Requiere:
- Revisión semanal de la precisión de clasificación
- Un ciclo de retroalimentación desde las verificaciones de calidad de salida hacia las asignaciones de nivel
- Control de versiones en el mapeo de nivel a modelo (trátalo como código)
- Alertas cuando el uso de fallback supera un umbral
Sin esta disciplina, el router se desvía. Las tareas se clasifican mal. Los costos vuelven a subir. La calidad se degrada en silencio.
Construir el router toma un día. Mantener el ciclo de retroalimentación es lo que lo mantiene funcionando.
Si estás ejecutando flujos de trabajo de IA a volumen y quieres auditar tu estructura actual de costos de inferencia, inicia una conversación →