HopBaseRespuesta corta: el rendimiento de una API de LLM se reduce a tres aspectos medibles: la distribución P95/P99 del tiempo hasta el primer token (TTFT), la estabilidad del streaming (la proporción de salidas largas que terminan sin un corte silencioso a mitad del stream) y la forma en que los aciertos de la caché de prompts amplifican tanto la velocidad como el costo. La latencia total y los promedios le inducirán a error: el tiempo de generación depende sobre todo de la longitud de la salida, y una media oculta la cola que sus usuarios realmente perciben. Un benchmark útil es aburrido a propósito: un conjunto fijo de prompts, temperatura 0, al menos 30 ejecuciones en una misma franja horaria, percentiles en lugar de promedios y la misma prueba repetida contra la API oficial del proveedor en la misma franja. El rendimiento no debería ser un adjetivo en la página de un proveedor, sino una cifra en su terminal. El método que se describe a continuación empieza con un solo comando curl y es totalmente reproducible.
Por qué la latencia total es una mala métrica
El tiempo total de generación depende sobre todo de la longitud de la salida: 2000 palabras tardan diez veces más que 200, sea cual sea la calidad del enlace. En streaming, lo que los usuarios perciben realmente son dos cosas: cuándo llega el primer token (TTFT) y si los tokens siguen fluyendo de forma constante después. El TTFT es la verdadera métrica del enlace: contiene toda la sobrecarga de la entrada, la planificación del gateway y la cola del lado del proveedor.
Lea distribuciones, no medias
Los promedios ocultan la cola: 90 solicitudes de 1 s más 10 de 8 s dan una media de 1.7 s que parece aceptable, pero uno de cada diez usuarios espera 8 segundos. Un P95/P99 abultado indica colas o reintentos, uno de los criterios de calidad de ingeniería de la prueba de fidelidad. La disciplina: prompt fijo, temperatura 0, al menos 30 ejecuciones consecutivas en una misma franja horaria y, después, lectura de percentiles.
Tasa de truncamiento: la métrica más ignorada
Un corte silencioso a mitad del stream en una salida larga es el peor modo de fallo del streaming: recibe la mitad del contenido y ningún código de error. La prueba es sencilla: solicite salidas largas (por ejemplo, 2000 palabras), repita N veces y mida la proporción de streams que terminan limpiamente con una finalización SSE correcta. Un canal con una tasa de truncamiento alta hace que cualquier cifra de TTFT carezca de sentido.
Aciertos de caché: rendimiento y costo son la misma moneda
Con un acierto de la caché de prompts, la entrada se factura con descuento y el TTFT baja de forma visible: aquí rendimiento y costo son una misma cosa. La tasa de aciertos depende de la topología de enrutamiento: las solicitudes deben llegar a la misma cuenta de backend, por lo que el tráfico enrutado al azar tiende a cero. Cómo la planificación por afinidad conserva las tasas de aciertos bajo carga: nuestras notas de ingeniería sobre alta concurrencia; la mecánica de facturación: la guía de caché de prompts.
Códigos de error y comportamiento de reintento
Un punto que se pasa por alto con facilidad: ¿el gateway transmite intactos los códigos de error del proveedor del modelo? Un canal que se traga los 429 y los convierte en tiempos de espera agotados rompe su lógica de backoff y colapsa en los picos de carga. Pruébelo provocando deliberadamente límites de tasa o parámetros no válidos y comparando el comportamiento con la documentación oficial.
Un benchmark que empieza con un comando
El TTFT se puede medir con curl sin más (con el streaming activado, time_starttransfer es la llegada del primer fragmento):
curl -N -s -o /dev/null \
-w "TTFT %{time_starttransfer}s | total %{time_total}s\n" \
https://api.hop-base.com/v1/chat/completions \
-H "Authorization: Bearer $HOPBASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"gpt-6-luna","stream":true,"messages":[{"role":"user","content":"Introduce yourself in one sentence"}]}'Sustituya gpt-6-luna por cualquier modelo que pueda llamar con su propia clave; GET /v1/models los enumera. Ejecútelo en un bucle 30 veces, repítalo en horas pico y tendrá el P95 y la variabilidad. La disciplina completa: conjunto fijo de tareas, temperatura 0, descartar la primera ejecución en frío, repetir la prueba en distintas franjas horarias y comparar siempre la API oficial del proveedor con el servicio evaluado en la misma franja.
Cómo nos instrumentamos nosotros
HopBase registra el modelo, el uso, la latencia y el estado de cada solicitud: el mismo rastro que sustenta las auditorías de facturación alimenta nuestra monitorización del rendimiento; sondas permanentes prueban continuamente cada canal para detectar y gestionar las anomalías lo antes posible. Por eso publicamos el método: las cifras que usted mide y las que nosotros vigilamos provienen del mismo enlace.
Preguntas frecuentes
¿Qué se considera un buen TTFT?
Los valores absolutos dependen del modelo, la región y el punto de entrada. Lo comparable es un A/B en la misma franja horaria frente a la API oficial del proveedor: la diferencia y la estabilidad de la distribución dicen más que cualquier cifra absoluta.
¿Un gateway es más lento que la conexión directa?
El costo fijo de un salto adicional es de milisegundos; las ganancias por menos colas y por aciertos de caché van de cientos de milisegundos a segundos. Mida ambos lados con el método anterior y deje que decidan las cifras: no hace falta confiar en nadie.
¿Cómo evito el ruido en la prueba?
Temperatura 0, prompts fijos, N de al menos 30, descartar los arranques en frío, repetir en distintas franjas y nunca comparar entre franjas horarias diferentes; de lo contrario, las variaciones del proveedor según la hora del día se harán pasar por diferencias del gateway.
Para la incorporación empresarial y benchmarks comparativos, contáctenos; los detalles de integración están en la documentación.