Si te montas tu propio servidor de voz, la primera decisión es qué familia de motores instalar. Hay dos, y no se diferencian en la calidad del resultado: se diferencian en cómo tratan la memoria de la tarjeta gráfica. Elegir mal no te da peor audio — te da una tarde perdida y una GPU que no puedes usar para nada más.
| Tu VRAM | Qué instalar |
|---|---|
| 8 – 24 GB | hot/cold |
| 32 GB o más | vLLM |
Si solo quieres la respuesta, esa es. Lo que sigue es por qué.
Carga el modelo cuando hace falta y lo suelta cuando no. Mantiene un trabajador «caliente» listo para responder rápido y levanta «fríos» bajo demanda.
La consecuencia práctica es la que importa: la GPU sigue siendo tuya para otras cosas. Puedes tener el servidor de voz y, en la misma tarjeta, generar imágenes, correr un modelo de lenguaje pequeño o simplemente jugar. En un equipo personal o en un laboratorio doméstico eso no es un detalle, es la razón de existir.
Es lo que quieres con una RTX 4070, una 4080, o cualquier tarjeta de consumo, y cuando transcribes de vez en cuando en lugar de continuamente.
Reserva la memoria al arrancar —del orden de 22 a 29 GB según cómo lo configures— y no la suelta. A cambio hace continuous batching: en vez de atender las peticiones de una en una, mete muchas a la vez en el mismo paso de cómputo.
Cuando tienes volumen de verdad, la diferencia es enorme. Cuando no lo tienes, has convertido una tarjeta cara en un servicio que está parado casi todo el rato ocupando toda la memoria.
Es lo que quieres si transcribes horas de audio al día, con muchos flujos simultáneos, y tienes tarjetas dedicadas a inferencia.
Aquí es donde la gente se equivoca, porque vLLM funciona y los números de una prueba aislada salen bien.
El problema es lo que no se ve en esa prueba: con 16–24 GB, vLLM te reserva prácticamente toda la tarjeta de forma permanente. Has pagado el precio completo —perder la co-ubicación— sin recibir el beneficio completo, porque con esa memoria la caché de contexto no da para que el batching continuo luzca.
Por debajo de 16 GB directamente no compensa: la caché es tan pequeña que hot/cold gana.
Si dudas, empieza por hot/cold. Cambiar después es reinstalar, no rehacer.
En hot/cold hay varios motores de síntesis intercambiables con una variable de entorno,
TTS_BACKEND. Uno de ellos, voxcpm, no es para producción en esta familia: su ruta
de torch.compile no se lleva con el pool de subprocesos y provoca una carrera del
asignador de CUDA bajo carga concurrente. Está confirmado por los mantenedores del propio
modelo, que recomiendan un tiempo de ejecución de un solo proceso.
Para ese motor en serio, el repositorio es el de la familia vLLM. En hot/cold se queda disponible para desarrollo y pruebas, y avisa al cargar.
Lo contamos porque es el tipo de cosa que, si no te la dicen, descubres bajo carga y en producción.
Todo lo anterior son criterios, no resultados. Los resultados están publicados y son reproducibles en uttera-benchmarks: cuatro perfiles de carga —latencia, ráfaga hasta N=1024 y sostenido— sobre dos corpus.
Si tu caso no se parece a ninguno de los cuatro, clónatelo y mide el tuyo. Es exactamente para eso.
Y si lo que quieres es levantar el servidor entero, el camino completo está en cómo montar tu propio servidor de voz.
¿Algo que añadir o que corregir? Escríbenos a support@uttera.ai. Si nos corriges, editamos la entrada y te damos crédito.
Uttera