Enrutamiento de peso abierto a escala: GLM-5.1 vs Claude Opus 4.7 en TrueFoundry AI Gateway

Ejecutamos 20 prompts fijos a través de TrueFoundry AI Gateway comparando cuatro estrategias: todas Claude Opus 4.7, todas Z.AI GLM-5.1, un enrutador clasificador Haiku (fácil → abierto, difícil → frontera), y un modelo virtual 80/20. Con esta combinación, el enrutamiento clasificador redujo el costo combinado ~31% frente a todo Opus ($15.72 frente a $22.72 por 1M de tokens) mientras obtenía una puntuación más alta en nuestro juez Sonnet (4.94 vs 4.85). All-open fue el más barato (3,00 $ / 1M) pero más lento y de calidad ligeramente inferior. La conclusión: no necesitas una única cadena de modelo para cada solicitud; el enrutamiento de puerta de enlace más un clasificador económico pueden mantener la calidad de vanguardia en tareas difíciles sin pagar precios de vanguardia en las fáciles.

Por qué esto importa ahora

La ola de modelos de peso abierto ya no es teórica. Modelos como GLM-5.1 se lanzan con codificación agéntica posicionamiento, contexto de 200K tokens y precios de lista un orden de magnitud por debajo de las API de vanguardia, mientras que Claude Opus 4.7 sigue siendo la referencia para el razonamiento complejo.

Los equipos de plataforma se enfrentan a una disyuntiva conocida:

• Enrutar todo a la vanguardia → calidad predecible, economía unitaria dolorosa a gran volumen.
• Dirigir todo a de peso abierto → costo atractivo, calidad inconsistente y picos de latencia en prompts difíciles.
• Construir enrutadores personalizados → flexible, pero usted es responsable de la lógica de clasificación, la conmutación por error, la conciliación de facturación y la semántica de caché entre proveedores.

TrueFoundry AI Gateway se sitúa en el medio: más de 1000 LLM a través de una API unificada compatible con OpenAI, modelos virtuales con enrutamiento basado en peso, encabezados de caché semántica y métricas de precios transparentes para una facturación precisa. Queríamos medir si un clasificador simple FÁCIL/DIFÍCIL —una llamada a Haiku por solicitud— podría superar ambos extremos en costo y calidad para una carga de trabajo realista de 20 prompts.

Lo que comparamos (recorrido técnico)

Línea base de peso abierto: GLM-5.1

GLM-5.1 es el modelo insignia de Z.AI de abril de 2026, accesible a través del Gateway de TrueFoundry, orientado a trabajos agenciales de largo plazo: planificación, uso de herramientas y bucles de codificación de varios pasos.

Modelo de referencia de vanguardia: Claude Opus 4.7

Opus 4.7 es el modelo de gama alta de Anthropic para el razonamiento complejo. Nota: Opus 4.7 utiliza un nuevo tokenizador que puede emitir más tokens que los modelos Claude anteriores para el mismo texto; las comparaciones de costos deben usar recuentos de tokens medidos, no recuentos de caracteres.

Enrutador clasificador a nivel de aplicación

Nuestro enrutador clasifica cada prompt como FÁCIL o DIFÍCIL en una sola llamada (~8 tokens de salida). FÁCIL → GLM-5.1; DIFÍCIL → Opus 4.7. La puntuación de calidad utiliza Claude Sonnet 4.6 como juez LLM (1-5 según las rúbricas por prompt).

Modelo virtual de Gateway (80/20)

También probamos un modelo virtual en Gateway configurado para enrutamiento basado en peso (80% abierto / 20% de vanguardia en la interfaz de usuario). Esto mide el equilibrio de carga del lado del proveedor sin clasificación a nivel de aplicación, un enfoque diferente al del enrutador Haiku.

Sobre nuestro benchmark

Prompts: 20 tareas — 10 etiquetadas como fáciles (resumir, formatear JSON, traducir) y 10 difíciles (compensaciones de sistemas distribuidos, revisión de inyección SQL, ambigüedad contractual, depuración de K8s OOM, etc.).

Métricas por estrategia:

Lo que no afirmamos: puntuaciones SWE-bench del proveedor, formas de tráfico de producción.
‍

Contexto de precios del proveedor (mayo de 2026)

GLM-5.1 es aproximadamente 5 veces más barato en la entrada y ~8 veces más barato en la salida que Opus 4.7 al precio de lista — antes de aplicar enrutamiento, almacenamiento en caché o descuentos empresariales. La pregunta interesante es cuánto de esa diferencia se mantiene después de enviar prompts difíciles a la frontera.
‍

Nuestro análisis (ejecución de 20 prompts)

Costo por 1M de tokens (mezcla de tokens de esta ejecución)

‍

División del router (clasificador)

El router Haiku envió 10/20 prompts a GLM-5.1 y 10/20 a Opus 4.7 — una división 50/50 en este conjunto de prompts (10 fáciles + 10 difíciles por diseño). El volumen de tokens siguió el mismo patrón: 7.774 tokens en GLM frente a 10.072 en Opus para el tráfico de finalización.

Las colas de latencia importan

Solo el de peso abierto tuvo el p50 más lento (20.1s) y un extremo p95 (~115s) — una larga finalización de GLM en una solicitud difícil dominó la cola. Solo Opus fue el más rápido en p50 (9.1s) con un p95 moderado (~21s). El clasificador se situó en un punto intermedio en p50 (14.9s) con un p95 de ~26s.

Calidad vs. costo: el punto óptimo del clasificador

• Enrutador vs. solo Opus: ~31% inferior costo combinado $/1M ($15.72 vs $22.72) con mayor puntuación media del juez (4.94 vs 4.85). El costo total en dólares para 20 solicitudes fue esencialmente el mismo (~$0.28) porque los gastos generales del juez + enrutador compensaron los ahorros de GLM — a mayor volumen, la brecha por token se agrava.
• Enrutador vs. solo abierto: ~5.2× más caro por millón, pero +0.19 puntos de calidad. Lo más barato no es lo mejor si las indicaciones complejas importan.
• Virtual 80/20: $7.19 / 1M según una estimación de mezcla de precios de lista, pero la calidad (4.50) quedó por debajo de ambas referencias. El enrutamiento basado en peso sin conocimiento de la tarea no es un sustituto de la clasificación en esta carga de trabajo; valide la mezcla real de backends en Métricas de Gateway, no solo el ID del modelo virtual.

Por qué estos resultados son importantes

1. La clasificación es económica en comparación con las finalizaciones de vanguardia. Una llamada a Haiku por solicitud es ruido en comparación con una finalización de Opus de 1,024 tokens en tareas difíciles. La economía del enrutador funciona cuando el tráfico fácil representa una gran parte del volumen, y cuando los enrutamientos erróneos son poco frecuentes.
2. El precio de lista ≠ su factura. Gateway puede enrutar a través de diferentes proveedores, aplicar almacenamiento en caché o negociar tarifas. Aplicamos precios de lista públicos a los tokens medidos de nuestra ejecución; debería conciliar con Métricas de Gateway → Descargar Datos Brutos antes de establecer las salvaguardas de FinOps.
3. La latencia y la calidad están acopladas. Ahorrar un 31% en tokens no sirve de nada si la latencia p95 incumple los SLO. Nuestra línea base de pesos abiertos demostró que una única mala decisión de enrutamiento (enviar un prompt complejo solo a GLM) puede disparar la latencia de cola.
4. Dos patrones de enrutamiento, dos historias. A nivel de aplicación FÁCIL/DIFÍCIL el enrutamiento optimizó la relación calidad-costo en este conjunto. A nivel de UI modelos virtuales 80/20 optimizados para la simplicidad operativa, pero con un rendimiento inferior en calidad aquí — útiles para implementaciones graduales, no un reemplazo completo para el enrutamiento consciente de la tarea.

Conclusiones prácticas para equipos de plataforma

1. Comience con un par de modelos de vanguardia y de pesos abiertos conectados a través de una única URL base del Gateway. Intercambie modelos cambiando la cadena del modelo — sin bifurcación del SDK por proveedor.
2. Añada un clasificador económico (Haiku o similar) antes de añadir complejidad a los pesos del modelo virtual. Mida la tasa de enrutamiento incorrecto en un subconjunto de prompts de referencia.
3. Publique una lista de niveles de prompts (fácil/difícil) alineada con sus rúbricas — nuestro conjunto de 20 prompts es una plantilla, no su distribución de producción.
4. Concilie los costos en las Métricas del Gateway, no en estimaciones de notebooks. Exporte el CSV de facturación en bruto y únase a los metadatos de seguimiento
5. Implemente una caché semántica después de que el enrutamiento se estabilice — el almacenamiento en caché semántico en prompts fáciles y parafraseados es donde suele aparecer el ROI de la caché (no medido en esta ejecución de línea base).

Cómo TrueFoundry AI Gateway hizo esto posible

• API unificada compatible con OpenAI — un cliente, base_url apuntando a Gateway; la misma ruta de código para GLM, Opus, Haiku y Sonnet.
• Modelos virtuales — enrutamiento 80/20 basado en peso sin cambios en la aplicación (documentación).
• Caché semántica — reutilización de respuestas basada en similitud (documentación).
• Observabilidad — encabezados de uso de tokens, latencia y costo para la conciliación; ~3–4 ms de latencia y más de 350 RPS en 1 vCPU en la capa de la pasarela para escenarios de proxy de alto rendimiento.

Conclusión

Modelos de peso abierto como GLM-5.1 están diseñados para atraer tráfico fácil. Claude Opus 4.7 sigue siendo rentable para prompts difíciles. La brecha entre ellos es lo suficientemente grande como para que el enrutamiento importe más que el marketing del modelo.

En nuestra prueba de 20 prompts a través de TrueFoundry AI Gateway, un enrutador clasificador Haiku ofreció el mejor resultado combinado: ~31% menos de costo combinado por millón de tokens que con solo Opus, con una puntuación media de juez más alta (4.94 frente a 4.85). El modelo "all-open" se mantuvo como el límite inferior de costo; el modelo "all-Opus" como el límite superior de calidad y velocidad para la latencia p50.

‍