Rendimiento, concurrencia y planificación de capacidad en IA de voz

Nota sobre el alcance. Un resultado de capacidad solo se aplica a la carga de trabajo, el modelo, la voz, el hardware, el software y la configuración de servicio probados. Esta guía ofrece un método para producir un resultado, no una cifra universal de llamadas por GPU.

Ideas clave

• Mida el tiempo desde el final del turno hasta el primer audio reproducible para reflejar la experiencia de usuario, y conserve las marcas de tiempo por componente para diagnosticar.
• Genere las pruebas con llegadas, comportamiento de sesión, texto y duración de audio con forma de producción. Un bucle de concurrencia fija no sustituye a un modelo de llegadas.
• Defina la capacidad utilizable como la carga máxima probada que sigue cumpliendo todos los objetivos de latencia, fallos, cola y recuperación.
• Trate el p99, el factor de tiempo real y el uso de GPU como evidencia con un alcance declarado, no como afirmaciones de capacidad por sí solas.
• Ponga precio a la capacidad utilizable probada, incluido el trabajo fallido y el cancelado, en lugar de dividir el coste por el rendimiento máximo teórico.

Última actualización: agosto de 2026. Aquí no se reivindica ningún resultado de capacidad de hardware ni de latencia de KugelAudio.

¿Qué latencia experimenta realmente el usuario de una IA de voz?

El usuario percibe el intervalo entre el final de su turno y el inicio de una reproducción útil. Según la aplicación, eso incluye la detección del final de turno, la transcripción, la lógica de la aplicación, la salida del modelo de lenguaje, la normalización del texto, el TTS, la transferencia por red, la decodificación y un búfer de reproducción. El tiempo de inferencia del modelo por sí solo no describe esa experiencia.

Instrumente una única traza con marcas de tiempo monótonas en estos puntos:

user turn end
-> transcript ready
-> first stable text sent to TTS
-> TTS request admitted
-> synthesis starts
-> first audio byte received
-> enough valid audio is decoded and buffered
-> playback starts
-> synthesis completes or is cancelled

Ponga a la métrica el nombre de sus extremos. Por ejemplo, el tiempo hasta el primer audio del TTS (TTFA) puede ir desde la admisión de la petición hasta el primer fragmento de audio, mientras que el primer audio reproducible visible para el usuario va desde el final del turno hasta el inicio de la reproducción. El primer byte de red puede ser una cabecera o un fotograma parcial, así que no es automáticamente audio reproducible. Registre junto al resultado la región del cliente, la reutilización de la conexión, el códec, la frecuencia de muestreo y la regla del búfer de reproducción.

La guía de streaming y segmentación de KugelAudio documenta cómo su segmentación en el servidor y el comportamiento de flush en el cliente afectan al TTFA. No elimina la necesidad de medir la ruta completa de la aplicación.

Idóneo para: ejecutar estos casos como escenarios con nombre propio. Combinar arranques en frío, ráfagas y tráfico estable en un solo agregado oculta la causa de un percentil lento.

¿Cómo debe modelar una prueba de capacidad la carga de producción?

Empiece por un manifiesto de carga versionado, no por un recuento genérico de peticiones. Incluya:

• la tasa de llegada de sesiones y la distribución de las ráfagas;
• las llamadas en curso, los turnos por sesión y el tiempo de reflexión entre turnos;
• la mezcla de longitudes de texto, idiomas, voces y normalización;
• la duración, el formato y la frecuencia de muestreo del audio generado;
• el comportamiento de los fragmentos de streaming y del flush;
• la reutilización de conexiones, las reconexiones, los plazos y los reintentos;
• las interrupciones, el momento de la cancelación y las sesiones abandonadas;
• el tráfico vecino ruidoso o por lotes que comparte las mismas dependencias.

Use distribuciones de producción anonimizadas cuando estén disponibles. En caso contrario, publique el corpus de texto o el generador determinista, la semilla aleatoria y los parámetros de la distribución. Calcule el hash del corpus y registre la revisión del generador de carga para que una ejecución posterior use el mismo trabajo.

Elija con criterio el modelo del generador de carga. Un generador de bucle cerrado espera una respuesta antes de emitir la siguiente petición; cuando el servicio se ralentiza, envía menos trabajo y puede ocultar la sobrecarga. Sigue siendo útil cuando la concurrencia activa fija es en sí misma la condición de producción. Un generador de bucle abierto programa las llegadas con independencia de la finalización de las respuestas. La guía de pruebas de carga de Google Cloud explica esta distinción. En un producto de llamadas, modele los inicios de sesión como llegadas y preserve la temporización de los turnos dentro de la sesión. Informe tanto del trabajo programado como del efectivamente enviado, porque un generador de carga saturado invalida la ejecución.

Ejecute por separado los experimentos en frío y en caliente. Defina «en frío» con precisión, por ejemplo como una réplica nueva con el modelo sin cargar, y registre cada fase del arranque. En una ejecución en caliente, complete el calentamiento declarado y comience a medir solo cuando el rendimiento, la cola y las señales de recursos cumplan una regla de estabilidad declarada de antemano. No mezcle la primera petición en un percentil en caliente ni la descarte sin informar del resultado en frío.

¿Cómo encajan la concurrencia, la ley de Little y el factor de tiempo real?

«Llamadas simultáneas» puede significar sockets abiertos, sesiones activas, turnos en espera en una cola o flujos que están generando audio. Publique cada cifra por separado. El trabajo activo consume recursos de inferencia, el trabajo en cola añade espera y ocupa recursos del servicio, y quienes llaman y están inactivos siguen importando para las conexiones y la memoria.

En un sistema estable, la ley de Little relaciona promedios a largo plazo:

L = lambda * W

L       average work in the measured system
lambda  effective throughput per second
W       average time each item spends in that system, in seconds

Úsela como comprobación de coherencia y estimación inicial de la carga. No predice la latencia de cola, el rendimiento máximo ni el margen necesario. Defina el mismo límite para los tres términos, cuente el trabajo completado en lugar de usar en silencio el trabajo ofrecido, y no aplique la relación de estado estacionario a una ventana en la que la cola aún está creciendo.

El factor de tiempo real (RTF) responde a otra pregunta:

RTF  = synthesis elapsed time / generated audio duration
RTFx = generated audio duration / synthesis elapsed time = 1 / RTF

Un RTF menor es más rápido; un RTFx mayor es más rápido. La documentación de rendimiento de TTS de NVIDIA usa RTFx y publica sus entradas de prueba, flujos paralelos e iteraciones. Indique qué convención y qué límite temporal utiliza. El RTF solo de cómputo excluye el tiempo de cola y de red; el RTF de extremo a extremo, no. Ninguno captura el primer audio reproducible, así que informe del TTFA y de los huecos entre fragmentos por separado. Un RTF de flujo único inferior a uno tampoco demuestra que un servicio interactivo pueda aceptar trabajo paralelo ilimitado.

¿Cuánta evidencia respalda un percentil de latencia?

Informe del número de observaciones, la duración de la prueba, el número de repeticiones, el método de cuantiles y los intervalos del histograma junto a cada percentil. Con solo 100 observaciones correctas, el p99 lo determina aproximadamente una única observación de la cola, según el estimador. Eso describe una muestra pequeña, no un compromiso estable. Google Cloud también advierte en su guía sobre métricas de latencia de que un p99 con poco volumen puede ser simplemente la petición más lenta.

No existe un número de muestras universal útil. Defina de antemano la incertidumbre aceptable y elija después la duración y las repeticiones independientes según la variabilidad del tráfico. Si la ejecución no puede sustentar una estimación de la cola, informe de un percentil más bajo o de la fracción de peticiones que cumplen un umbral de latencia declarado. Defina explícitamente la población del percentil. Informe de los tiempos de espera agotados, los rechazos y las cancelaciones como resultados, e inclúyalos en el denominador de cualquier tasa de éxito sobre todos los intentos.

Conserve los eventos originales cuando sea viable y mantenga histogramas combinables para la operación. El modelo de datos de métricas de OpenTelemetry describe la agregación de histogramas. Sitúe los límites de los intervalos en torno a los umbrales de decisión de la aplicación. No promedie percentiles precalculados por instancia; Prometheus explica por qué eso no es válido en su guía sobre histogramas.

¿Cómo debe comportarse un servicio de voz en sobrecarga?

La sobrecarga debe ser acotada y visible. Fije los límites de admisión a partir del plazo de la interacción y de la capacidad de servicio probada. Cuando el trabajo no pueda empezar a tiempo, recházelo o redirijalo de forma explícita en lugar de aceptar una cola ilimitada. Un pico breve no debe convertirse en minutos de habla obsoleta ni consumir memoria hasta tumbar el servicio.

Pruebe el ciclo completo:

1. establezca una base estable con una tasa ofrecida conocida;
2. aplique una ráfaga versionada o retire una réplica;
3. observe las admisiones, los rechazos, la antigüedad de la cola, la latencia y el trabajo activo;
4. cancele determinados flujos y verifique que su cómputo se detiene;
5. retire el fallo o la ráfaga;
6. compruebe que la cola se vacía y que todas las señales vuelven al rango de referencia;
7. verifique que los flujos aceptados no se mezclaron, duplicaron ni truncaron.

Reintente solo cuando el plazo restante del usuario haga útil otro intento. Acote los intentos y use retroceso con variación aleatoria; los reintentos sincronizados pueden convertirse en carga nueva. La guía de Google sobre fallos en cascada relaciona las pruebas de capacidad realistas, las colas pequeñas, el rechazo temprano y el control de reintentos. La alternativa puede ser un mensaje aprobado de antemano, un servicio provisionado aparte o el traspaso a una persona, pero debe ejercitarse bajo carga.

¿Cómo deben probarse el autoescalado y la telemetría de GPU?

El autoescalado empieza cuando la demanda ya ha cambiado. Mida el retardo completo de escalado hacia arriba: recogida de métricas, decisión, planificación, disponibilidad de la imagen, carga del modelo, comprobaciones de estado y calentamiento. El control de admisión y la capacidad reservada deben proteger las peticiones durante ese retardo. Pruebe también el escalado hacia abajo, el drenaje de conexiones, las actualizaciones progresivas y las oscilaciones, no solo el escalado hacia arriba.

Kubernetes documenta las métricas personalizadas y externas y el comportamiento de estabilización en su guía de autoescalado horizontal de pods. Un objetivo genérico de CPU no es automáticamente adecuado para un TTS en GPU. La antigüedad de la cola, el trabajo activo admitido y una señal de saturación pueden reaccionar de forma más directa, pero use solo métricas oportunas, acotadas y validadas frente a la latencia de cara al usuario.

El uso de GPU, la memoria, la temperatura, la potencia y los contadores de errores de hardware explican por qué cambió un resultado; no definen la capacidad utilizable. Correlaciónelos con la espera en cola, el tiempo de síntesis, el primer audio reproducible, la finalización y los fallos. La documentación de Data Center GPU Manager de NVIDIA describe las capacidades disponibles de salud y telemetría. Registre el nombre de la métrica, el intervalo de muestreo, el hardware y la versión del exportador en lugar de presentar un gráfico suelto de «porcentaje de GPU».

¿Cómo se convierten los resultados en réplicas y en coste?

Para cada modelo y mezcla de carga, aumente la carga ofrecida por pasos y repita las ejecuciones en los límites. La capacidad utilizable por réplica es la tasa máxima probada con la que se superan todos los criterios declarados de latencia, fallos, estabilidad de la cola y recuperación. Después valide varias réplicas: el enrutamiento, la afinidad de conexión, la normalización compartida, el almacenamiento y las dependencias del plano de control pueden impedir un escalado lineal.

Una primera estimación de planificación es:

replicas = ceiling(forecast peak offered rate / validated per-replica rate)

Este no es el número final de despliegue. Añada capacidad para el escenario de fallo elegido, el mantenimiento, el error de previsión y el retardo de arranque, y vuelva a ejecutar esa topología. El margen es una decisión de negocio y de fiabilidad, no un porcentaje universal. Google SRE recomienda previsión de la demanda y pruebas de carga periódicas para relacionar los recursos brutos con la capacidad de servicio en su guía de planificación de capacidad.

Compare la economía solo con los mismos objetivos superados:

cost per delivered audio hour =
  total deployment cost during the window / successful playable audio hours

cost per 1,000 completed interactions =
  total deployment cost during the window / completed interactions * 1,000

Incluya el cómputo, las réplicas ociosas, la orquestación, las licencias y los costes de red imputables. El trabajo fallido, rechazado y cancelado permanece en el numerador, de modo que el desperdicio no queda oculto. Publique el uso y la fecha de los precios. Un resultado de saturación más barato que no cumple el objetivo de latencia no es un sistema utilizable más barato.

¿Qué debe contener un informe de capacidad reproducible?

Un informe debe aportar el manifiesto de carga y el hash del corpus; la revisión y la topología del generador de carga; las regiones de cliente y de servidor; la fuente de reloj; las versiones de modelo, voz, normalización y servicio; el hardware, el controlador y el modo de energía; la configuración de réplicas, batching y colas; las ventanas de calentamiento y de medición; las distribuciones de latencia originales o combinables; el trabajo ofrecido, admitido, rechazado y completado; la duración del audio de salida; todas las clases de fallo y de cancelación; las trazas de recursos; y la cronología de la sobrecarga y la recuperación.

Termine con decisiones, no con adjetivos: la carga superada, el criterio incumplido, el número de réplicas elegido, la reserva ante fallos, los límites de autoescalado y el desencadenante de una nueva ejecución. La guía de SRE de Google sobre objetivos de nivel de servicio es un marco útil para derivar esos criterios de las expectativas de los usuarios.

Para KugelAudio operado por el cliente, la guía de despliegue autoalojado documenta la entrega en Kubernetes con un chart de Helm. No publica ninguna garantía de concurrencia por hardware. Dimensione el modelo, el hardware y la carga elegidos con el método anterior.

¿Qué limitaciones tiene esta guía?

Este artículo no evalúa ninguna GPU, modelo, voz ni despliegue concretos. Tampoco prescribe un objetivo de latencia conversacional, un tamaño de cola ni un margen de seguridad. Esas decisiones dependen del flujo de llamada, de las expectativas del usuario, de la variación del tráfico, de la política ante fallos y de la evidencia que produzca el propio sistema.

Preguntas frecuentes

¿Es lo mismo el tiempo hasta el primer byte que el tiempo hasta el primer audio reproducible?

No. El primer byte puede ser una cabecera o un fotograma parcial. El primer audio reproducible es el punto en el que el cliente tiene audio decodificado válido y búfer suficiente para empezar a reproducir según la política declarada del reproductor.

¿Por qué no basta la latencia media?

Una media oculta la distribución y no dice nada sobre los fallos. Informe del número de observaciones, los percentiles elegidos, la tasa de cumplimiento del umbral, los errores, los tiempos de espera agotados, los rechazos y las cancelaciones de la misma ventana de medición.

¿Cuántas llamadas admite una GPU?

Solo puede responderlo un benchmark equivalente. El modelo, el hardware, la compilación de servicio, el texto y la duración del audio, el comportamiento del streaming, la mezcla de carga y el objetivo de latencia cambian la concurrencia utilizable.

¿Basta un RTF inferior a uno para un agente de voz en tiempo real?

No. Indica que el intervalo de síntesis medido fue más corto que la duración del audio generado. No acredita el primer audio reproducible, el retardo de cola, la latencia de cola, el comportamiento ante cancelaciones ni la capacidad con varios flujos.

¿Debería el uso de GPU disparar el autoescalado?

Solo si las pruebas demuestran que anticipa la presión sobre el usuario con suficiente antelación. Compárelo con la antigüedad de la cola, la generación activa, la tasa de admisión, la latencia de cara al usuario y el tiempo real que necesita una réplica nueva para estar lista.

¿Qué debe ocurrir cuando se agota la capacidad?

Dejar de admitir trabajo que no pueda cumplir su plazo, emitir un resultado explícito de sobrecarga y activar la alternativa probada. No oculte el exceso de demanda en una cola ilimitada ni en un bucle de reintentos inmediatos.

¿Con qué frecuencia deben repetirse las pruebas de capacidad?

Repítalas tras cambios relevantes en el modelo, el runtime, el controlador, el hardware, la normalización, el enrutamiento, la política de autoescalado o la carga de trabajo. Repítalas también antes de adquirir o renovar un compromiso de capacidad en producción.