Benchmark de Inferencia: ¿Qué Métrica de Latencia Deberías Optimizar?

Un benchmark de latencia cara a cara entre Telnyx, Together.ai y Fireworks.ai en 540 solicitudes transmitidas con tres modelos fronterizos de pesos abiertos.

La Conclusión

Ejecutamos 540 completions de chat transmitidas entre tres proveedores de inferencia (Telnyx, Together.ai y Fireworks.ai) en tres modelos de pesos abiertos (Kimi K2.6, GLM-5.1 y MiniMax-M2.7) desde un único host en la región de EE. UU. Esto es lo que importa:

• La métrica que importa depende de lo que estés construyendo. Para IA de voz y aplicaciones en tiempo real, el Time-to-first-token (TTFT) determina si la experiencia funciona. Para cargas de trabajo por lotes y agentes, la latencia E2E y el throughput determinan el costo y la velocidad. Evaluamos ambos.
• El primer token no es la línea de meta. Fireworks entrega consistentemente el time-to-first-token más rápido en Kimi K2.6 y GLM-5.1, pero Telnyx termina más rápido en latencia end-to-end para GLM-5.1 en perfiles de salida larga y domina en MiniMax-M2.7 en todas las métricas.
• MiniMax-M2.7 corre 3-6x más rápido en Telnyx. En cargas de trabajo de salida larga, Telnyx completa en 8-11 segundos. Together tarda 36-50 segundos. Throughput: 125-170 tok/s vs 27-42 tok/s.
• El rendimiento de Together es el más volátil. 15 celdas atípicas donde los máximos de una sola ejecución superaron 5x la mediana, incluyendo una pausa de 143 segundos a mitad del stream en GLM-5.1. Telnyx tuvo 4. Fireworks tuvo 3.
• FP8 supera a FP4 en throughput. Together ejecuta GLM y MiniMax con cuantización FP4. Telnyx ejecuta FP8. Nuestro FP8 entrega mayor throughput que su FP4 en ambos modelos, mayor precisión, salida más rápida.
• La infraestructura regional es escasa en LATAM. La mayoría de los proveedores de inferencia concentran su infraestructura en EE. UU. y Europa. Para los equipos en América Latina, enrutar solicitudes a esas regiones añade 100-200ms de latencia de red antes de que la inferencia siquiera comience. El despliegue serverless de Telnyx en São Paulo y la próxima región de Dubai significan que los equipos en LATAM pueden ejecutar inferencia con TTFT sub-segundo y soberanía de datos en región por primera vez. Cuando tus usuarios están en Ciudad de México, Buenos Aires o São Paulo, la latencia E2E desde una GPU local es la métrica que hace o deshace el producto.

TTFT vs E2E: Métricas Diferentes para Diferentes Cargas de Trabajo

El time-to-first-token (TTFT) es el benchmark de inferencia más comúnmente citado. Para algunas cargas de trabajo como IA de voz o agentes en tiempo real, es la métrica correcta. Para otras, procesamiento por lotes, cadenas de agentes, la latencia end-to-end (E2E) y el throughput importan más. La pregunta no es qué métrica es mejor. Es qué métrica se ajusta a lo que estás construyendo.

Nuestro benchmark encontró un patrón consistente: los proveedores que ganan en TTFT no siempre ganan en latencia end-to-end (E2E).

El ejemplo más claro: GLM-5.1 con 10k de entrada, 1k de salida.

Fireworks entrega el primer token en 1.7 segundos. Pero la respuesta completa tarda más de 40 segundos. Telnyx entrega la respuesta completa en menos de 16 segundos, 2.5x más rápido que Fireworks, 1.7x más rápido que Together.

Si estás construyendo un producto en tiempo real, tus usuarios no experimentan el "primer token." Experimentan la respuesta completa. E2E es la métrica que se ajusta a la experiencia del usuario. El throughput es la métrica que se ajusta al costo por token a escala.

Al evaluar proveedores de inferencia, pregunta:

• ¿Cuál es la latencia E2E en mis tamaños de entrada/salida esperados?
• ¿Cuál es el throughput efectivo, no solo el tiempo al primer token?
• ¿Qué tan estable es la distribución? Un p50 rápido con una cola de 5x no es "rápido" en producción.

IA de Voz: Por Qué TTFT Es la Métrica Que Importa

La IA de voz es el ejemplo más claro de por qué TTFT importa. Cuando un usuario habla con un agente, cada milisegundo de retraso en el primer token es aire muerto. La respuesta no se transmite progresivamente como en un chatbot; el usuario está esperando que el agente empiece a hablar.

Por eso Kimi K2.6 es el modelo que recomendamos para aplicaciones de voz y tiempo real. Su modo sin razonamiento se mantiene altamente inteligente mientras entrega un TTFT más bajo que GLM-5.1. Si estás construyendo IA de voz, Kimi K2.6 en Telnyx es la herramienta correcta.

Análisis Modelo por Modelo

MiniMax-M2.7 — Telnyx destaca en latencia end-to-end

Aquí es donde la brecha es más amplia. Telnyx gana en latencia E2E en absolutamente todos los perfiles, salida corta y larga, contexto pequeño y grande.

Cargas de trabajo de salida larga (1k de salida objetivo):

Telnyx completa las solicitudes de salida larga de MiniMax-M2.7 3-6x más rápido que Together y ligeramente más rápido que Fireworks. Con 100k de entrada, Together tarda casi un minuto completo; Telnyx termina en 11 segundos.

Cargas de trabajo de salida corta: Misma historia. El E2E de Telnyx oscila entre 1.2-2.3 segundos. Together está entre 3-5.6 segundos. Fireworks entre 1.7-2.9 segundos.

La brecha de throughput: 125-170 tok/s en Telnyx vs 27-42 tok/s en Together. La cuantización FP4 de Together no compensa — su throughput es una fracción del FP8 de Telnyx.

Veredicto: Si estás ejecutando MiniMax-M2.7, la elección de proveedor ni siquiera es cercana. Telnyx es más rápido, más consistente y entrega 3-6x el throughput.

GLM-5.1 — Mayor Throughput en Telnyx

GLM-5.1 ilustra mejor la historia de "TTFT vs E2E."

Fireworks es consistentemente el más rápido en llegar al primer token en GLM-5.1 en contextos cortos. Pero esa ventaja inicial se evapora en salidas más largas porque el throughput efectivo de Fireworks es dramáticamente menor.

Comparación de throughput (tok/s, p50):

Telnyx entrega 81-113 tok/s en GLM-5.1 vs 32-59 tok/s en Fireworks. Eso es aproximadamente 2x el throughput en cada perfil. Para cargas de trabajo que generan salidas más largas, esto se compone en diferencias masivas de E2E:

• 10k entrada, 1k salida: Telnyx 15.9s vs Fireworks 40.2s
• 100k entrada, 1k salida: Telnyx 16.8s vs Fireworks 34.0s

Veredicto: Fireworks puede darte el primer token más rápido, pero Telnyx te da la respuesta completa más rápido, por un factor de 2-2.5x en salidas de longitud de producción.

Kimi K2.6 — Diseñado para Voz y Tiempo Real

Kimi K2.6 es el más parejo. Fireworks lidera en TTFT consistentemente. El E2E está más cerca:

Fireworks tiene una ligera ventaja en E2E de salida corta. Pero en salida larga, la brecha entre Telnyx y Fireworks es pequeña (dentro del 10-15%), mientras que Together se queda significativamente atrás.

El throughput es competitivo entre los tres proveedores en Kimi, con Telnyx y Fireworks intercambiando el liderazgo según el perfil.

Veredicto: Kimi K2.6 es el modelo al que recurrir cuando estás construyendo agentes de voz o aplicaciones en tiempo real. Su modo sin razonamiento sigue siendo altamente inteligente, y entrega un TTFT más bajo que GLM-5.1, que es la métrica que más importa cuando tus usuarios están esperando que un agente hable. Para IA de voz, la ventaja en TTFT más la disponibilidad regional y la soberanía de datos hacen de Telnyx la elección clara.

La Pregunta de Fiabilidad

Los promedios de latencia cuentan una historia. El comportamiento de la cola cuenta otra.

Marcamos cada celda donde una sola ejecución superó 5x la mediana de la celda:

El evento de Together en GLM-5.1: En una solicitud de 100k de entrada y 1k de salida, el stream produjo 423 fragmentos en 194 segundos. Luego apareció un hueco de 143 segundos entre los fragmentos 363 y 364, tras lo cual el streaming se reanudó normalmente. Esto no fue un problema de conexión. Los datos fluyeron a ambos lados del hueco. Fue una pausa a mitad del stream dentro de la infraestructura de Together.

Para un chatbot, una pausa de 143 segundos es una experiencia rota. Para un agente haciendo llamadas secuenciales a un LLM, es un retraso en cascada. Para un pipeline de IA de voz, es una llamada caída.

También destacable: Se esperaba que la cuantización FP4 de Together entregara ventajas de throughput sobre FP8. No fue así. Tanto en GLM-5.1 como en MiniMax-M2.7, el FP4 de Together entregó menor throughput que el FP8 de Telnyx.

Qué Significa Esto para la Elección de Proveedor

Metodología

• 540 completions de chat transmitidas entre 3 proveedores × 3 modelos × 6 perfiles de prompt × 10 ejecuciones por celda (538 exitosas)
• Modelos: Kimi K2.6, GLM-5.1, MiniMax-M2.7 (Telnyx FP8, Together FP4, Fireworks no verificado)
• Perfiles de prompt: Tareas de análisis literario sobre extractos de Moby-Dick (dominio público). Tres tamaños de entrada (~1k, ~10k, ~100k tokens) × dos objetivos de salida (~100, ~1k tokens)
• Región: EE. UU. Benchmarks de Europa y APAC próximamente.
• Controles: Modo streaming, temperatura 0.0, round-robin secuencial, calentamiento de 5 solicitudes por par proveedor/modelo
• Métricas: TTFT (ms), latencia E2E (ms), throughput efectivo (tok/s)
• n = 10 es escala piloto. p95/p99 no se reportan. Los resultados son direccionales, no definitivos.
• Razonamiento habilitado en todos los modelos por defecto. Un seguimiento sin razonamiento está planificado.
• Datos completos y metodología disponibles para reproducibilidad.

Este benchmark se realizó el 23 de abril de 2026. Los resultados reflejan el rendimiento de los proveedores en ese momento. La infraestructura de inferencia cambia frecuentemente; recomendamos ejecutar tus propios benchmarks para decisiones de producción. Los datos brutos y la metodología están disponibles bajo petición.