Routing por latencia vs routing por coste vs routing por calidad
Cuándo elegir cuál

Hay tres ejes de routing posibles: latencia, coste, o calidad. La mayoría de los sistemas enrutan por coste porque el coste es fácil de medir. La latencia es más difícil. La calidad es la más difícil. Y cuál deberías priorizar realmente depende completamente del workload - por eso recurrir al coste por defecto suele ser incorrecto.

Las tres estrategias de routing

Enrutar por coste

Elegir el provider más barato que pueda manejar la solicitud por encima de un umbral mínimo de calidad.

Cuándo funciona: Jobs en segundo plano, procesamiento por lotes, pipelines asíncronos. Cualquier workload donde el usuario no está esperando una respuesta ahora mismo. Indexación de documentos, colas de moderación de contenido, generación de informes nocturnos.

Cuándo falla: Cualquier interfaz de usuario donde esperar parece un bug. A 900ms de TTFT (Gemini Pro en un mal día), un chatbot parece roto aunque la respuesta sea correcta.

Los números: Enrutar todo por coste da aproximadamente Gemini Flash para consultas simples (0,19 $/1M tokens blended) y GPT-4o para las complejas (6,88 $/1M). Ahorro medio vs. Claude 3.5 Sonnet en todo: ~65%.

Enrutar por latencia

Elegir el provider más rápido que cumpla un umbral mínimo de calidad, independientemente del coste.

Cuándo funciona: Chat en tiempo real, interfaces de voz, autocompletado, sugerencias de código en directo. Cualquier UX donde la velocidad percibida es el producto.

El p99 importa más que la mediana. Groq a 65ms de mediana, 280ms en p99 es mejor que GPT-4o a 620ms de mediana aunque Groq ocasionalmente llegue a 400ms - porque el p99 de GPT-4o es de 2.100ms. El peor día de Groq supera la media de GPT-4o en rutas críticas de latencia.

El coste: Groq Llama 3.1 70B a 0,70 $/1M tokens blended no es el más barato, pero tampoco es caro. El delta de coste respecto al routing por calidad suele merecer la pena en cualquier interacción donde el usuario esté esperando activamente.

Enrutar por calidad

Elegir el provider con mayor puntuación que se ajuste a un tope de coste definido.

Cuándo funciona: Cualquier cosa que tenga un revisor humano en el bucle. Borradores legales, notas médicas, tareas de razonamiento complejo donde los errores tienen consecuencias reales. El usuario no está esperando de forma síncrona - revisará el resultado después, y una mejora de calidad del 20% vale un precio 3× mayor.

La trampa: El routing por calidad sin tope se convierte en "enrutar todo a Claude 3.5 Sonnet", que es el comportamiento por defecto en el que la mayoría de los equipos acaba accidentalmente. El routing por calidad solo tiene sentido si has definido el tope.

El árbol de decisión de routing en la práctica

En la práctica, no estás eligiendo una sola estrategia. Las apilas:

1. ¿Esta solicitud necesita completarse en < 300ms para un buen UX?
   → SÍ: enrutar por latencia (Groq > Haiku > GPT-4o-mini)
   → NO: continuar

2. ¿Es una tarea background o asíncrona?
   → SÍ: enrutar por coste (Gemini Flash > GPT-4o-mini > Haiku)
   → NO: continuar

3. ¿Revisará un humano este resultado antes de que afecte a algo importante?
   → SÍ: enrutar por calidad (Claude 3.5 Sonnet > GPT-4o > Gemini Pro)
   → NO: enrutar por coste con un umbral de calidad de 75+

La mayoría de los equipos hacen un cortocircuito en el paso 3 y envían todo a Claude 3.5 Sonnet. Resultado: pagar precios de calidad por tareas sensibles a la latencia donde Groq sería idéntico desde la perspectiva del usuario, y por tareas asíncronas donde Gemini Flash es 50× más barato.

El error que empeora las tres estrategias

Enrutar después de que la solicitud ya está en vuelo.

Si tu decisión de routing ocurre en la capa proxy después de que el cliente se ha conectado y espera, ya has pagado el coste del setup de conexión con tu provider "rápido". La verdadera ganancia de latencia con Groq viene cuando la decisión de routing se toma antes de que la solicitud llegue al provider - no a mitad de vuelo.

Esto significa que tu capa de routing necesita clasificar la solicitud en menos de 1ms, antes de elegir un provider. La clasificación mediante un modelo local pequeño (o un clasificador basado en reglas sobre metadatos de la solicitud) es el patrón correcto. La clasificación mediante una segunda llamada LLM para "decidir qué modelo usar" es más lenta que usar Claude 3.5 Sonnet para todo.

La capa CORTEX de HiWay2LLM clasifica en menos de 0,4ms usando una combinación de heurísticas de conteo de tokens y reglas de tipo de tarea derivadas de los patrones de solicitudes. Sin llamada a modelo en el hot path.

Routing blended: lo que realmente se despliega en producción

En producción, la mayoría de los equipos terminan con una estrategia blended:

• Tier latencia para rutas interactivas (chat, búsqueda, autocompletado) → Groq o Haiku
• Tier coste para rutas background (indexación, batch eval, jobs nocturnos) → Gemini Flash
• Tier calidad para pasos de planificación de agentes y resultados revisados por humanos → Claude 3.5 Sonnet

La regla de routing no necesita ser inteligente. Necesita ser consistente. Un mapa simple de endpoint → tier supera a un clasificador ML sofisticado en predictibilidad y depurabilidad.

El resultado en nuestros benchmarks: el routing blended sobre estos tres tiers cuesta 2,40 $/1M tokens de media vs. 9,75 $ con Claude 3.5 Sonnet en todo - una reducción del 75% sin pérdida de calidad perceptible en el 90% de las solicitudes.

Una configuración de partida que funciona

Aquí hay un punto de partida que funciona para la mayoría de los productos SaaS de IA:

Esta no es la configuración óptima para cada producto. Pero es mejor que el comportamiento por defecto, y es auditable - puedes ver exactamente por qué cada solicitud cuesta lo que cuesta.