Velocidad de inferencia GLM-5 en WaveSpeed: Latencia y rendimiento

Quería una respuesta rápida mientras redactaba un correo de bienvenida. GLM-5 parecía inteligente, pero el primer token tardó lo suficiente como para que me quedara mirando el cursor. No era una crisis, solo una pequeña pausa que seguía ocurriendo. Esa suele ser mi señal para revisar qué está pasando realmente.

Soy Dora. Realicé un conjunto sencillo de pruebas para ver cuánta velocidad de inferencia de GLM-5 podía exprimir sin convertir mi flujo de trabajo en un proyecto científico. Nada sofisticado, solo lo suficiente para sentir la diferencia en trabajo real, no en un laboratorio.

Metodología de prueba (hardware, configuración, longitudes de prompts)

Probé tres vías de acceso:

• WaveSpeed: una capa de aceleración ligera que he estado probando y que gestiona el modelado de solicitudes y el almacenamiento en caché en el lado del cliente/gateway.
• API directa de Z.ai: la ruta directa a GLM-5 a través del proveedor.
• OpenRouter: un intermediario que reenvía al proveedor del modelo con algunos extras.

Hardware y contexto

• Cliente local: MacBook Pro (M2 Max, 64 GB RAM). Red en fibra estable (≈500 Mbps de bajada, ≈30 ms a endpoints comunes en EE. UU.).
• Lado del servidor: sin servidor personalizado, solo llamadas del cliente, excepto WaveSpeed, que ejecuta un pequeño gateway local para gestionar el almacenamiento en caché y el modelado de lotes.

Configuración que mantuve estable salvo indicación

• Modelo: GLM-5 (chat/completions), temperatura 0.2, top_p 0.9, max_tokens 512.
• Streaming activado, porque así es como trabajo realmente.
• Reintentos desactivados excepto para errores de red.

Prompts utilizados

• Corto: 60–80 tokens (una instrucción concisa con 2–3 restricciones).
• Medio: ~350 tokens (borrador de correo con notas de marca y ejemplos).
• Largo: ~1.500 tokens (un breve pequeño con contexto de producto, notas de tono y listas de qué hacer/no hacer).

Realicé 25 iteraciones por condición y registré:

• Tiempo hasta el primer token (TTFT): desde el envío de la solicitud hasta el primer token en streaming.
• Rendimiento (tokens/s): velocidad de salida en streaming una vez que comienzan los tokens.
• Un interruptor para el “modo de razonamiento” (trazas de razonamiento del proveedor).

Métricas clave

Tiempo hasta el primer token (TTFT)

Los prompts cortos se situaron entre 250–400 ms en rutas favorables. Los prompts medios llevaron el TTFT hacia 450–700 ms. Los prompts largos superaron el segundo a menos que el caché se activara. El salto no fue lineal: parecía que la sobrecarga de cola de espera y validación importaba tanto como la longitud del prompt.

Mi reacción: por debajo de 400 ms se siente ágil; cualquier cosa por encima de un segundo me saca del flujo. Cuando edito texto en vivo, ese primer token importa más que el rendimiento final.

Tokens por segundo (rendimiento)

Una vez iniciado el streaming, vi 35–70 tok/s en ejecuciones sin razonamiento. Es bastante rápido para redacción, justo en el límite para diferencias de código. El rendimiento bajaba en salidas más largas, lo que sospecho se debía al modelado del lado del servidor y pasadas de seguridad más que a la velocidad pura del modelo.

Modo de razonamiento vs modo sin razonamiento

Con el “razonamiento” activado, el TTFT aumentó un 30–80% y el rendimiento se redujo a la mitad en algunos casos. La prosa era más coherente en prompts complicados, pero para la redacción cotidiana no lo necesitaba. Esto no me ahorró tiempo al principio, pero después de varias ejecuciones, noté que reducía el esfuerzo mental en ediciones complejas. En tareas simples, lo dejo desactivado.

Cómo la aceleración de WaveSpeed se aplica a GLM-5

WaveSpeed no tocó los pesos del modelo. Hizo dos cosas simples y útiles de mi lado de la conexión: reducir el trabajo redundante y dar forma a las solicitudes para que el proveedor pudiera responder más rápido. En GLM-5, eso se tradujo en mejor TTFT en prompts repetidos y pequeñas ganancias en prompts medios.

ParaAttention y técnicas de almacenamiento en caché

• ParaAttention (mis notas): En lugar de agrupar solicitudes no relacionadas, WaveSpeed paraleliza fragmentos compatibles con la atención dentro de un único prompt largo cuando detecta scaffolding repetido. En la práctica, reutilizó el preludio (sistema + ejemplos compartidos) y solo envió el delta. No puedo verificar los elementos internos, pero el efecto parecía una reutilización parcial de KV a nivel de gateway.
• Almacenamiento en caché: Memorizó embeddings para el preludio del prompt y plantillas de sistema cortas. Cuando iteré sobre la misma tarea con ediciones menores, el TTFT bajó ~120–180 ms. En prompts fríos, el beneficio fue menor (~40 ms) pero aún perceptible.

Límites que encontré

• La primera ejecución en frío sigue estando ligada al upstream. Sin milagros.
• Si cambiaba más del ~20% del prompt, el caché no ayudaba.
• El modo de razonamiento neutralizó en gran medida las ganancias: la traza de razonamiento se comportó como un stream separado.

Comparación: WaveSpeed vs API directa de Z.ai vs OpenRouter

Aquí es donde las pequeñas diferencias importan.

• API directa de Z.ai: Consistente. Menor varianza en TTFT. Cuando necesitaba inicios predecibles para demostraciones, era mi elección. En prompts largos, la penalización de TTFT era real pero estable.
• OpenRouter: TTFT ligeramente más alto en promedio, un poco más de varianza, pero configuración fácil y flexibilidad de enrutamiento. Bueno cuando manejo varios modelos. La documentación es sólida: ver las guías de OpenRouter.

• Capa WaveSpeed: Mejor TTFT en prompts calientes e inputs medianos, probablemente gracias al almacenamiento en caché y el modelado de solicitudes. En prompts largos verdaderamente fríos, empató con el acceso directo.

Ninguno de estos cambió el comportamiento central de GLM-5. Cambiaron la rapidez con la que sentía que el modelo “despertaba” y lo fluida que resultaba la iteración.

Si estás decidiendo:

• ¿Necesitas rendimiento estable y menos piezas móviles? Ve directo a través del proveedor. Referencia: la documentación de la API de ZhipuAI.
• ¿Necesitas enrutamiento multi-modelo o claves compartidas entre herramientas? OpenRouter está bien, acepta unos pocos milisegundos extra.
• ¿Iterando sobre prompts similares todo el día? Una capa de aceleración ligera compensa en calma mental más que en velocidad bruta.

Consejos de optimización para cargas de trabajo en producción

Lo que realmente ayudó en la práctica:

• Calienta el preludio: Mantén los prompts del sistema y los ejemplos compartidos estables. Guárdalos en caché, incluso del lado del cliente. Mis ahorros en TTFT: ~100–200 ms en repeticiones.
• Recorta la cola: Limita max_tokens a lo que realmente necesitas. Reducir un límite de 1.000 tokens a 400 redujo el tiempo total un 10–20% en mis borradores.
• Prefiere reintentos estructurados: Si debes reintentar, reanuda los streams, no los reinicies. Los reintentos a ciegas arruinaban el TTFT.
• Controla la variabilidad: temperatura ≤0.3 para producción. La menor entropía redujo las pasadas del servidor y estabilizó el rendimiento.
• Aplaza el modo de razonamiento: Actívalo solo en prompts que históricamente fallan. Mapeo los “prompts difíciles” y activo el indicador por ruta.
• Divide el contexto largo upstream: Resume las referencias una vez, guarda el resumen y reutilízalo. La segunda y tercera ejecución se sienten dramáticamente más ligeras.
• Vigila la tokenización: Diferentes SDKs tokenizan de forma ligeramente distinta. Fija el cliente y vuelve a medir: vi regresiones fantasma solo por esto.
• Mide p95, no solo p50: Las colas con picos causan el lag visible que los usuarios recuerdan.

Datos brutos del benchmark (tabla)

Aquí está el resumen de mis ejecuciones (25 iteraciones por fila). Todos los números son aproximados pero representativos de lo que sentí al teclado.

Notas

• “Preludio caliente” significa que el sistema + los ejemplos compartidos estaban en caché en el gateway.
• El rendimiento se mide después del primer token. Tiempo total = TTFT + tokens_salida / rendimiento.
• La red era estable: cuando lo probé en Wi‑Fi de hotel, todo empeoraba un 10–20%.

Una última observación: reducir 150 ms del TTFT me importó más que añadir 5 tok/s, porque eliminó la pequeña espera que desencadena el cambio de contexto. Esa no es una regla universal, solo la forma en que mi cerebro gestiona los streams.