Diarización local con WhisperX en 8 GB: velocidad, VRAM y errores reales

Puedes tener una transcripción perfecta y, aun así, acabar con un bonito ladrillo de texto que no sirve para demasiado.

Porque saber qué se ha dicho está muy bien.

Pero en una entrevista, una reunión o un podcast hay otra pregunta bastante importante:

¿quién demonios lo ha dicho?

Con dos personas y un audio limpio todavía puedes reconstruir la conversación a ojo. Mete cuatro voces, alguna interrupción, dos personas hablando a la vez y un poco de ruido de fondo, y aquello empieza a parecer una discusión de comunidad de vecinos pasada por una trituradora.

Ahí entra la diarización.

La idea es sencilla:

• Transcripción: qué se dijo.
• Alineación: cuándo se dijo.
• Diarización: quién lo dijo.

La teoría está muy bien.

Lo que quería saber yo era otra cosa:

¿Puede un PC doméstico con una GPU de 8 GB hacer las tres cosas localmente, sin arrastrarse y sin explotar por el camino?

Para comprobarlo he utilizado una RTX 2080 SUPER de 8 GB, un Ryzen 7 5800X, 32 GiB de RAM y cinco audios de distinta dificultad.

No he mirado una tabla de requisitos y dado el asunto por resuelto.

He cargado los audios.

He medido tiempos.

He medido VRAM y RAM.

He provocado OOM.

He probado CPU contra GPU.

Y además he creado una referencia manual para comprobar cuántas palabras terminaban asignadas al hablante equivocado.

Porque «funciona con 8 GB» puede querer decir muchas cosas.

Puede querer decir que arranca.

Puede querer decir que entra por los pelos.

O puede querer decir que puedes meterle un audio de 40 minutos y marcharte tranquilamente sin preguntarte si CUDA va a decidir incendiar el proceso a mitad de camino.

Y esas tres cosas no son lo mismo.

Resultado rápido

Sí: en mi equipo, una GPU de 8 GB pudo ejecutar el pipeline completo de WhisperX de forma estable.

La configuración que mejor resultado práctico me dio fue large-v2 + int8_float16 + batch 4. Con ella medí:

• 6,4 GB de pico de VRAM
• 0 OOM en cinco audios
• 12,2× tiempo real de rendimiento agregado

Cuando intenté apretar más la tarjeta empezó la fiesta. Con float16 + batch 4 llegué a 8,1 GB y tuve 2 OOM de 5. Con int8_float16 + batch 8 alcancé 8,0 GB, apareció 1 OOM y, para rematar, el rendimiento agregado bajó de 12,2× a 11,5×. Más batch, más memoria, menos velocidad. Maravilloso.

El audio más largo tenía 40 minutos y 46 segundos y el pipeline completo —transcripción, alineación y diarización— terminó en aproximadamente 1 minuto y 38 segundos. Unas 25 veces más rápido que el tiempo real para ese archivo concreto.

También probé a quitar la GPU. El Ryzen 7 5800X consiguió aproximadamente 2× tiempo real con large-v2 en INT8. Mucho más lento, evidentemente. Pero una hora de audio en aproximadamente media hora de proceso está bastante lejos de ser inútil.

Y quedaba la pregunta más importante: ¿separó bien a los hablantes? En los cinco audios, el diarizador local detectó automáticamente el número correcto de voces. El error de atribución por palabra fue desde 0 % en una entrevista limpia con dos personas hasta 8,1 % cuando añadí ruido y voces solapadas. Ahí es donde la magia empieza a perder purpurina. Y precisamente por eso merece la pena medirlo.

Qué es diarizar, y por qué una transcripción a secas no basta

Diarizar es averiguar quién habla y en qué momentos dentro de una grabación.

No te da el nombre de nadie. Te da etiquetas anónimas —SPEAKER_00, SPEAKER_01, SPEAKER_02— y se encarga de que esas identidades sean coherentes de principio a fin del audio.

Whisper, por sí solo, hace lo básico: convierte audio en texto. WhisperX monta un pipeline alrededor de esa transcripción para añadir alineación temporal más fina y asignación de hablantes. Su documentación define la diarización como partir el audio en segmentos según quién habla.

En una frase:

Para una nota de voz tú solo, la última fila te da igual. Para una entrevista, un podcast o una reunión, es la diferencia entre un texto y una transcripción que de verdad puedes usar.

El PC de pruebas y una advertencia (una)

Nada de GPU profesional ni RTX moderna de gama alta. Un equipo que mucha gente puede tener todavía debajo de la mesa:

Otro detalle que se suele pasar por alto: mientras probaba, el escritorio y el sistema ya se comían alrededor de 2,4 GB de VRAM. Tu tarjeta pone 8 en la caja; disponibles del todo para un solo proceso, casi nunca. No voy a sumarle a mano esos 2,4 GB a cada fila de la tabla —Diariza mide el pico con NVML y, si no está disponible, tira de Torch—, pero conviene tenerlo presente al leer los números.

Entorno de la prueba (para reproducirlo)

Estas mediciones se hicieron con un entorno fijado a propósito (el pineado completo está en el README del repositorio):

• Python 3.12
• torch 2.4.1+cu121
• WhisperX 3.3.1
• CTranslate2 ≥ 4.5
• Resemblyzer + scikit-learn

A fecha de esta investigación, la versión estable de WhisperX es la 3.8.6, del 25 de mayo de 2026, y su rama actual ha cambiado dependencias respecto a lo que usé. Un benchmark solo sirve si sabes qué estás comparando: estos números son de este entorno, no de una versión futura instalada por encima.

Los cinco audios

Un solo audio limpio habría dado una foto demasiado bonita. Usé cinco:

Los cortos enseñan el comportamiento en trabajos de uno o dos minutos. El quinto mete 2.446 segundos —unos 40 minutos y 46 segundos— para ver qué pasa en distancias largas.

Además de tiempo y consumo, hice una referencia manual para medir la atribución de hablantes. Vuelvo sobre ella más abajo, porque no es DER y conviene no mezclarlo.

¿Cabe WhisperX en 8 GB? Sí, con matices

En mi equipo sí, pero no con cualquier combinación que consiguiera arrancar.

large-v2 + int8_float16 + batch 4: el punto dulce

6,4 GB de pico, 0 OOM en cinco audios, 12,2× tiempo real de rendimiento agregado.

No es el número de velocidad más alto de la tabla. Es el único que terminó los cinco audios sin sudores. Y esa diferencia importa más de lo que parece: una config un pelín más rápida que revienta a mitad de una grabación larga vale menos que otra un pelín más lenta que acaba siempre.

float16: un 10 % más de velocidad y dos OOM

Misma receta, large-v2 y batch 4, pero con float16. El agregado subió de 12,2× a 13,4×: alrededor de un 10 % más.

A cambio, el pico llegó a 8,1 GB y hubo 2 OOM de 5. O sea: una mejora modesta de velocidad a costa de fallar en el 40 % de un banco de cinco archivos. No es para sacar una ley universal sobre float16, pero sí para decidir qué no usaría en esta 2080 SUPER. La ganancia no compensó.

Más batch, menos velocidad

Siguiente idea: large-v2, int8_float16 y subir de batch 4 a batch 8. Lo razonable sería esperar más rendimiento.

No fue lo que pasó. Con batch 8: 8,0 GB, 1 OOM (en el audio largo, cómo no) y 11,5× de agregado. Con batch 4: 6,4 GB, 0 OOM, 12,2×.

Batch 8 gastó ~1,6 GB más de VRAM, falló una vez y encima fue un 6 % más lento. A veces exprimir la GPU es pegarte un tiro en el pie.

Esto no significa que subir batch empeore siempre las cosas. faster-whisper enseña en sus propios benchmarks que el procesado por lotes puede acelerar mucho la transcripción, a cambio de más memoria; en su prueba oficial con large-v2 y una RTX 3070 Ti de 8 GB, batch 8 sube claramente velocidad y VRAM. Justo por eso mi resultado tiene valor: cómo se comporta el componente de transcripción aislado no te dice cómo se comportará el pipeline completo, en otro hardware y con otros audios.

medium: más rápido, pero es otro modelo

medium + float16 + batch 8: 7,3 GB, 0 OOM de 5, 17,6× de agregado. Rápido y estable, y bastante por delante de large-v2 + int8_float16 + batch 4.

Pero he cambiado de modelo. La velocidad no es la única variable, y este benchmark no compara la calidad de transcripción de los dos como para dictar sentencia. Si te vale la calidad de medium y quieres volumen, míralo. Si necesitas lo que da large-v2, quédate con el ajuste anterior.

La lección de los 8 GB: deja hueco

Tres cifras y ya se ve el patrón:

• 6,4 GB → 0 OOM
• 8,0 GB → 1 OOM
• 8,1 GB → 2 OOM

Son cinco audios y una sola máquina. No voy a convertirlo en una ley de la termodinámica. Pero para este PC la decisión es clara:

En una GPU de 8 GB, dejar margen valió más que arañar la última décima de rendimiento.

La config estable no fue la que más VRAM ocupó ni la que dio el número teórico más alto. Fue la que dejó sitio para que el pipeline trabajara sin quedarse sin memoria.

El repositorio de WhisperX dice que su backend faster-whisper puede ejecutar large-v2 por debajo de 8 GB en su configuración de referencia, y recomienda bajar batch o precisión cuando falta memoria. Mis datos no lo contradicen. Lo que enseñan es que «menos de 8 GB» no responde a la pregunta que de verdad te haces si tienes una tarjeta de 8 GB: ¿puedo trabajar con ella sin rezarle a CUDA?

¿Cuánto tarda?

«12× tiempo real» suena abstracto. Traducido: si esa velocidad se mantuviera, cada 12 segundos de audio se procesan en aproximadamente uno.

Con la config estable —large-v2, int8_float16, batch 4—, los clips de uno o dos minutos se movieron entre 9× y 14×.

40 minutos y 46 segundos de audio en 1 minuto y 38 segundos

El audio largo dura 2.446 s. El pipeline completo terminó en unos 98 s. La cuenta es 2.446 / 98 ≈ 25: unas 25 veces más rápido que el tiempo real, para ese archivo.

Ese 25× no es el rendimiento habitual del benchmark. El agregado de la config sigue siendo 12,2×. Son dos cosas distintas y no las mezclo: coger el mejor archivo y venderlo como el rendimiento normal es el truco más viejo de los benchmarks.

Aun así, el dato vale por sí solo. Una GPU lanzada en 2019 se comió más de cuarenta minutos de conversación —con alineación y hablantes incluidos— en menos de dos minutos. «Hardware modesto» no tiene por qué significar «espera eterna».

¿Y los ~40× de medium?

En una medición concreta, medium rozó los 40× tiempo real. Otra vez: no es su media. En la tabla, medium + float16 + batch 8 da 17,6× de agregado. El 40× es un caso puntual que enseña hasta dónde llegó esa combinación en condiciones favorables, no una promesa para cualquier archivo.

Dónde se va el tiempo (spoiler: no en la diarización)

Tenía una intuición y la prueba la desmontó. El reparto aproximado del tiempo total:

Tres cuartas partes del tiempo se van en pasar el audio a texto. La diarización se llevó alrededor del 7 %.

Es el reparto de mis pruebas, no una ley para todo diarizador ni todo equipo. Pero responde a un miedo razonable: añadir «quién habla» no multiplicó el tiempo del pipeline.

Sin GPU NVIDIA: más lento, no inútil

También quité la GPU de la ecuación. Con el Ryzen 7 5800X, large-v2 y cómputo int8, saqué unos 2× tiempo real. Como orden de magnitud: una hora de audio → media hora de proceso.

No es un uno-contra-uno idéntico de todos los archivos y parámetros, así que tampoco saques un «la GPU es exactamente X veces más rápida». La lectura útil:

La GPU no hace posible lo imposible. Coge un trabajo que ya funciona en CPU y lo deja casi instantáneo.

WhisperX documenta oficialmente la ejecución en CPU con compute_type int8, y faster-whisper también soporta INT8 en CPU. Para quien transcribe dos entrevistas por semana, o trabaja con grabaciones que no quiere subir a ningún sitio, media hora de espera por una hora de audio es perfectamente asumible.

¿Separa bien a los hablantes?

Hasta aquí he medido si entra en memoria y cuánto tarda. Pero una diarización rapidísima que le pone las frases a la persona equivocada no sirve de gran cosa.

Hice una referencia manual de los cinco audios y calculé mi error de atribución por palabra:

Y sí: acertó el número de voces en los cinco audios sin que se lo dijera. 2 → 2, 3 → 3, 4 → 4, 3 → 3, 4 → 4. No es que vaya a acertar siempre; es lo que pasó aquí. Pero no tener que decirle de antemano cuántas personas hay, y que salgan las cinco cuentas bien, es un buen resultado.

Cómo he medido el error: esto no es DER

Merece la pena pararse aquí, porque llamar mal a una métrica hace incomparable todo el experimento.

Medí otra cosa, más directa para quien va a leer la transcripción: qué porcentaje de palabras acaba bajo el nombre del hablante equivocado frente a mi referencia. Lo llamo error de atribución por palabra. Si una frase es de SPEAKER_01 y el sistema se la cuelga a SPEAKER_02, esas palabras cuentan como fallo.

Responde a una pregunta muy concreta: «¿cuánto texto me voy a encontrar con el nombre cambiado?». No lo compares con un DER de otro proyecto: son cosas distintas.

El audio largo: 5 % de palabras no es 5 % del tiempo

En el archivo de 2.446 s, el 5,0 % de las palabras quedó mal atribuido. Y 71,9 segundos de audio estaban asociados a la voz equivocada. La cuenta: 71,9 / 2.446 ≈ 2,9 % del tiempo total.

No hay contradicción entre «5,0 % de palabras» y «≈2,9 % de duración». Una métrica cuenta palabras; la otra, segundos. Una intervención corta puede tener muchas palabras; otra, silencios y pausas. Por eso no cuadran, y por eso doy las dos en vez de elegir la que quede mejor.

Dónde falla

El mejor caso fue sencillo: dos voces, audio limpio, 0,0 % de error.

Al meter gente: tres voces, 2,3 %; cuatro en reunión, 3,7 %.

Y luego el escenario difícil a propósito: tres voces + ruido + solapamientos → 8,1 %.

Ese 8,1 % es el dato que no voy a esconder. En cuanto dos personas se pisan, hay interrupciones o el sitio suena peor, el sistema deja de parecer magia. Y coincide con una limitación que el propio WhisperX reconoce: el habla solapada no la lleva bien y la diarización no es perfecta.

Con cinco archivos no puedo separar cuánto pesa el ruido, cuánto el solape y cuánto el número de voces. Pero el que juntaba las tres cosas fue, con diferencia, el peor.

Diariza: repite la prueba en tu equipo

Un benchmark vale más cuando dejas de creerte mis cifras y sacas las tuyas.

Por eso está Diariza: el mismo pipeline —transcripción → alineación → diarización—, pensado para que cargues tu audio y veas qué da tu máquina. No es un producto ni una plataforma. Está publicado en GitHub con licencia MIT.

Mide cada etapa por separado y, en un hilo aparte, muestrea VRAM (NVML o, si no, Torch), RAM, pico y OOM. Al terminar te suelta duración, tiempo total y por etapa, factor sobre tiempo real, pico de VRAM y RAM, y si petó por memoria. Si tras un OOM puede salvar un resultado parcial, lo intenta en vez de tirar todo el trabajo.

Tres formas de usarlo:

• diariza doctor — comprueba GPU, VRAM, WhisperX, ffmpeg y el diarizador antes de que descubras el problema a los veinte minutos de proceso.
• diariza transcribe audio.ext — ejecuta el pipeline. Con --no-diarize si solo quieres texto; con --min-speakers N --max-speakers N si sabes cuánta gente habla.
• diariza serve — interfaz local en 127.0.0.1:8000: subes el audio, ves el progreso por etapas, lees la transcripción con un color por hablante, tienes reproductor sincronizado y descargas TXT, SRT, VTT y JSON. Todo en tu equipo, sin mandar el audio a ninguna web.

La instalación, las versiones y las dependencias están en el README del proyecto. Aquí el protagonista es el experimento.

Qué usaría con una GPU de 8 GB

Si tuviera que repetir mañana en este mismo equipo, empezaría por:

Modelo: large-v2
Compute: int8_float16
Batch: 4

¿Por qué? Porque me dio 6,4 GB de pico, 0 OOM en cinco audios y 12,2× tiempo real de rendimiento agregado. No porque sea matemáticamente óptima: porque terminó el trabajo las cinco veces.

Si te vale la calidad de medium y quieres volumen, pruébalo: fue estable y 17,6×. Lo que no haría en esta 2080 SUPER es perseguir los 13,4× de float16 sabiendo que dos de cada cinco archivos acaban en OOM. Una tarea que falla no es un benchmark rápido; es una tarea que repites.

El preset 8gb-seguro

Diariza trae presets para no tener que recordar parámetros: entrevista (dos voces fijas), reunion (2–8), radio (locución y cortinillas), podcast (2–4) y 8gb-seguro (large-v2, int8_float16, batch 4).

El nombre 8gb-seguro necesita una aclaración: no significa «garantizado en cualquier GPU de 8 GB». Significa «la configuración que aguantó en la RTX 2080 SUPER de estas pruebas». Un punto de partida razonado, no un certificado para cualquier tarjeta, driver o escritorio.

Conclusiones: cuatro preguntas, cuatro respuestas

1. ¿WhisperX funciona estable con 8 GB?

Sí, en mi equipo y con la config adecuada. large-v2 + int8_float16 + batch 4: 6,4 GB, cinco audios, 0 OOM. No es una promesa para cualquier GPU de 8 GB.

2. ¿Es rápido?

Sí. 12,2× de agregado, 9×–14× en clips cortos, y el de 40:46 despachado en 1:38 (unos 25× para ese archivo).

3. ¿Se puede solo con CPU?

Sí. El Ryzen 7 5800X hizo ~2× tiempo real con large-v2 en INT8. Media hora de proceso por cada hora de audio. Lento, no inútil.

4. ¿Separa bien a los hablantes?

Depende del audio. De 0,0 % en la entrevista limpia a 8,1 % con ruido y voces solapadas. Y acertó el número de participantes en los cinco casos sin que se lo dijera.

La conclusión que de verdad importa

Después de todo esto, la cifra que más me dice no es 25×, ni 17,6×, ni el 0 % de la entrevista limpia.

Es la diferencia entre 6,4 GB → ningún OOM y 8,0–8,1 GB → fallos reales.

Cinco archivos y una máquina no dan para una regla universal. Pero sí para una idea muy concreta cuando trabajas con IA local en hardware justo:

La RTX 2080 SUPER salió en 2019. A estas alturas ya debería estar pensando en la jubilación. Sin embargo, acaba de tragarse 40 minutos de conversación, transcribirlos, alinearlos y separar cuatro voces en 98 segundos.

No está mal para una tarjeta que, según Internet, debería haber tirado por la ventana hace tres generaciones.

Preguntas frecuentes

¿Qué es la diarización de hablantes?

Es averiguar quién habla y cuándo en un audio. El resultado suele usar etiquetas tipo SPEAKER_00 y SPEAKER_01 para mantener separados los turnos de cada persona.

¿Qué diferencia hay entre Whisper y WhisperX?

Whisper transcribe: pasa audio a texto. WhisperX monta un pipeline encima que añade, entre otras cosas, alineación más fina a nivel de palabra y diarización de hablantes.

¿WhisperX funciona con 8 GB de VRAM?

Puede, pero «8 GB» no define una config estable por sí solo. En mi RTX 2080 SUPER, large-v2 + int8_float16 + batch 4 se quedó en 6,4 GB y 0 OOM en cinco audios. Dos configuraciones que rondaron los 8 GB sí dieron OOM. No lo extrapoles sin más a todas las GPUs.

¿Cuánta VRAM necesita WhisperX?

No hay una cifra única para todos los modelos, batch sizes, precisiones y pipelines. El repo de WhisperX dice que faster-whisper puede ejecutar large-v2 con menos de 8 GB en su configuración de referencia, y recomienda bajar batch, modelo o precisión si falta memoria. En mi prueba completa, el ajuste estable se quedó en 6,4 GB.

¿WhisperX funciona en CPU?

Sí, con compute_type int8. En mi Ryzen 7 5800X, large-v2 hizo unos 2× tiempo real: alrededor de 30 minutos de proceso por cada hora de audio en el escenario medido.

¿Se puede usar WhisperX sin conexión?

Sí. Una vez descargados los modelos y dependencias necesarios, Diariza ejecuta en local la transcripción, alineación y diarización. Su diarizador no necesita cuenta, token ni un servicio externo.

¿Diariza necesita cuenta, token o conexión a Internet?

No para procesar los audios una vez instalado. El diarizador de Diariza utiliza Resemblyzer + clustering con scikit-learn y no necesita cuenta, HF_TOKEN ni servicios externos. La conexión sí hace falta inicialmente para instalar dependencias y descargar los modelos necesarios.

¿Por qué falla más la diarización cuando dos personas hablan a la vez?

Porque el sistema tiene que decidir a la vez qué parte del sonido es de cada voz cuando las señales se solapan. El propio WhisperX reconoce el habla solapada como una de sus debilidades. En mi audio con ruido y solapamientos salió el peor dato del banco: 8,1 % de palabras con el hablante equivocado.