GLM-5.3: los endpoints con el streaming más rápido tardan entre 18 y 26 segundos en generar el primer token

Al elegir un proveedor para un modelo, la primera cifra que suele consultarse es la de “tokens por segundo”. Cuantos más, mejor. Sin embargo, una publicación reciente de Artificial Analysis sobre GLM-5.3 muestra que esta cifra puede ofrecer una imagen muy engañosa de la experiencia real del usuario.

Qué descubrieron

Los endpoints de GLM-5.3 con el streaming más rápido generan el primer token después de 18–26 segundos. En la mayoría de los demás proveedores, la respuesta comienza en 1–3 segundos. Si solo se mide la velocidad del flujo una vez iniciada la generación, los primeros parecen líderes. Al sumar la espera al tiempo total de la solicitud, pierden posiciones en la clasificación.

La publicación no explica la causa, por lo que solo cabe especular. Entre las posibilidades están una cola larga, un arranque en frío, un procesamiento previo intensivo del prompt o el razonamiento del modelo antes de entregar la respuesta. Sin datos de los propios proveedores, no se puede identificar al responsable con certeza.

Por qué importa en la práctica

Imagine un chatbot de atención al cliente. El usuario envía una pregunta y se queda mirando una pantalla vacía. Si la respuesta empieza 20 segundos después, da igual que el texto llegue luego a 300 tokens por segundo. Es posible que la persona ya haya cerrado la pestaña o haya pulsado “enviar” otra vez.

Lo mismo ocurre con los agentes. Cada paso de la cadena añade una demora hasta el primer token. Con diez llamadas consecutivas, la diferencia entre 2 y 20 segundos se convierte en minutos de espera, no en un detalle menor.

Por eso, los productos interactivos deberían medir como mínimo tres métricas:

• tiempo hasta el primer token (TTFT);
• velocidad de generación después del inicio;
• tiempo total de la solicitud para una respuesta de longitud habitual.

Qué hacer

Primero: no elija un proveedor basándose en una única cifra de velocidad de un agregador. Abra el desglose y examine el TTFT por separado.

Segundo: realice sus propias mediciones con sus prompts y en su horario habitual. La carga de los proveedores fluctúa, mientras que los benchmarks públicos promedian los resultados.

Tercero: si sus respuestas son cortas, el TTFT determina casi por completo la sensación de velocidad. Si son largas, la velocidad de streaming es más importante, pero aun así tendrá que disimular de algún modo una demora de 20 segundos, por ejemplo con un indicador de progreso.

Cuarto: incorpore un mecanismo de respaldo. Si el primer token no llega en 5 segundos, cambie a otro endpoint.

Limitaciones

Se trata de una única publicación breve con 807 visualizaciones, sin una tabla en el propio texto y sin los nombres de los proveedores. No sabemos cuánto duraron esas demoras ni si pueden reproducirse. Las conclusiones deberían contrastarse con los datos en tiempo real de Artificial Analysis y con pruebas propias.

Pero la lección es universal: “streaming rápido” y “respuesta rápida” no son lo mismo. Para el usuario importa cuándo aparece la primera palabra, no la velocidad a la que llegan después los tokens.