NVIDIA Nemotron 3.5 Transcribe: 40 idiomas, etiquetas de hablantes y uso local

Qué abarca el modelo 30B-A4B: 40 idiomas, alternancia de código y hablantes superpuestos

Durante los últimos años, obtener localmente la transcripción traducida de una reunión con etiquetas de hablantes implicaba construir una canalización frágil. Ejecutabas un modelo acústico como Whisper o Parakeet para obtener las palabras sin procesar, ejecutabas un segundo modelo como pyannote para agrupar las voces por marca de tiempo, escribías un script para alinear ambos resultados y luego pasabas el texto a un LLM local o en la nube para su traducción. Cada vez que dos personas hablaban al mismo tiempo durante una reunión intensa, la alineación de las marcas de tiempo se desfasaba y atribuía la mitad de una oración a la persona equivocada.

Nemotron 3.5 Transcribe integra todas esas etapas en un solo modelo al combinar un codificador de audio basado en Conformers con un decodificador de lenguaje 30B-A4B y un cabezal dedicado de marcas de tiempo de clasificación temporal conexionista (CTC) (ctc_timestamp.*, configurado mediante word_timestamp_config en el punto de control). En lugar de tratar los cambios de hablante como un problema de agrupación acústica añadido después de la transcripción, el modelo genera etiquetas de hablante, puntuación y tiempos por palabra directamente junto con el texto en grabaciones de hasta 60 minutos de duración.

El soporte lingüístico abarca 40 idiomas de forma nativa, incluyendo los principales idiomas de Europa, Asia y Medio Oriente, además de contar con traducción bidireccional integrada. Donde la base de lenguaje de 30B marca una diferencia notable frente a los modelos acústicos estándar es en la alternancia de código interlingüística: grabaciones en las que hablantes bilingües mezclan con naturalidad dos idiomas dentro de la misma oración, como en llamadas de negocios en hindi e inglés o en español e inglés. Los reconocedores de voz estándar suelen obligarte a fijar una sola etiqueta de idioma por segmento o caen constantemente en texto sin sentido cuando un hablante pasa de la gramática hindi a sustantivos técnicos en inglés. Debido a que Nemotron 3.5 Transcribe enruta los tokens de audio a través de un modelo de lenguaje multilingüe de 30B, mantiene baja la tasa de error de palabras durante los cambios a mitad de frase y maneja terminología médica o de ingeniería compleja sin deletrear las palabras fonéticamente.

Esa gran base de lenguaje conlleva ciertas concesiones cuando cuantizas los pesos para que quepan en hardware de consumo. En mis pruebas con pesos cuantizados a 4 bits (Q4 e IQ4_NL), el modelo maneja bien las conversaciones con múltiples hablantes y el vocabulario técnico, pero su traducción integrada de una sola pasada a 4 bits sigue siendo más rígida y propensa a errores de redacción que tomar una transcripción limpia y enviarla a un LLM dedicado. También puede tropezar cuando hay música mezclada con voz. Procesar un episodio completo de anime con un punto de control de 4 bits —tanto en la pista de audio original como después de aislar las voces— falló tres veces seguidas porque la letra en inglés del tema de apertura desajustó el estado de idioma del decodificador para el diálogo posterior.

Nemotron 3.5 Transcribe frente a modelos locales estándar y Parakeet

Si ya utilizas herramientas de transcripción local —ya sea mediante un script de línea de comandos o una aplicación como MacWhisper—, tu pregunta principal será si un modelo de 30B justifica el salto en consumo de memoria frente a los modelos locales estándar o la propia familia Parakeet de NVIDIA.

Para audio sencillo de un solo hablante en inglés o idiomas europeos, Parakeet TDT v3 sigue siendo más rápido, ligero y, a menudo, más preciso que una ejecución cuantizada a 4 bits de Nemotron 3.5 Transcribe. Parakeet ocupa aproximadamente 1 GB de memoria, se ejecuta rápido incluso en una CPU y nunca tiene problemas para convivir con el resto de tus aplicaciones. Esa diferencia de memoria es la razón exacta por la que las herramientas ligeras de subtitulado para escritorio —como Subtitle Edit— siguen recomendando Parakeet en lugar de integrar un modelo de 30B cuyo decodificador por sí solo consume de 15 a 20 GB de memoria.

Frente a un entorno optimizado de Whisper large-v3 en una Mac, Nemotron 3.5 Transcribe es notablemente más lento y pesado si todo lo que haces es transcribir un pódcast limpio o una nota de voz. Deberías recurrir a Nemotron 3.5 Transcribe específicamente cuando Whisper y Parakeet fallan: grabaciones en las que tres personas hablan al mismo tiempo en una sala de reuniones, entrevistas bilingües con constante alternancia de código o grabaciones con terminología muy específica (como dictados médicos o revisiones de arquitectura) donde un modelo acústico de 1B adivina el homófono equivocado cada treinta segundos.

Requisitos de hardware y VRAM: la trampa de memoria del MoE de 30B

Cuando se lee "30B de parámetros con 4B activos", resulta tentador asumir que el modelo funciona en una tarjeta gráfica de 8 GB o 12 GB como un modelo estándar de 4B. En una arquitectura MoE, el recuento activo de 4B determina cuánto cálculo se realiza por token, lo que mantiene una velocidad de inferencia aceptable una vez cargado. Sin embargo, el enrutador puede elegir diferentes expertos para cada token individual, lo que significa que los 30 mil millones de parámetros deben permanecer en la VRAM o en la memoria unificada del sistema al mismo tiempo. Si los pesos se desbordan hacia tu SSD, la generación de tokens se vuelve extremadamente lenta.

Esto es lo que requiere realmente cada formato en espacio de disco y memoria:

En primer lugar, el punto de control BF16 de precisión completa (nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B) pesa aproximadamente entre 67.5 y 68 GB. A menos que estés ajustando el modelo en un nodo de servidor con múltiples GPU, no hay razón para descargar los pesos BF16 para la transcripción diaria. Incluso en una estación de trabajo de 128 GB como una NVIDIA DGX Spark (GB10), dedicar 68 GB únicamente al modelo de transcripción deja muy poco margen si también quieres mantener cargado un LLM local o un agente de voz en paralelo.

En segundo lugar, los puntos de control cuantizados oficiales NVFP4 (NVIDIA-Nemotron-3.5-Transcribe-30B-A4B-NVFP4) y FP8 son los que NVIDIA destina al despliegue local en GPU modernas. Si revisaste Hugging Face justo después del anuncio inicial y viste errores 404 en los enlaces de NVFP4 y FP8 mientras solo estaban activos BF16 y el borrador de decodificación especulativa DFlash2, esos repositorios ya han sido publicados. El punto de control NVFP4 reduce el modelo a 21.6 GB, lo que le permite caber en una sola GPU de 24 GB (como una RTX 3090, RTX 4090 o RTX 5090) para clips más cortos, aunque las grabaciones de una hora con contexto completo elevan fácilmente el uso total de VRAM al rango de 24 GB a 32 GB.

En tercer lugar, para las Mac con Apple Silicon y entornos locales en C++ que utilizan GGUF (IQ4_NL + F16), el modelo se divide en dos archivos: un decodificador de lenguaje cuantizado a 4 bits (NVIDIA-Nemotron-3.5-Transcribe-30B-A4B-AD-IQ4_NL.gguf) y un codificador de audio de 16 bits (Encoder-F16.gguf). Juntos, esos dos archivos ocupan alrededor de 21.35 GB en disco. Al cargarse en una Mac con Apple Silicon (como un chip de la serie M Max con 36 GB o 64 GB de memoria unificada), el consumo activo se sitúa en torno a los 20 GB de RAM.

Si tienes una GPU de 12 GB como una RTX 3060 o RTX 4070 y esperas descargar los expertos MoE inactivos a la RAM del sistema como lo harías en llama.cpp, ten en cuenta una limitación actual en NeMo-Speech.cpp. Pasar un parámetro como --asr.salm.n_cpu_moe 40 a nemo-speech serve falla de inmediato con el mensaje nemo-speech serve: unknown option: --asr.salm.n_cpu_moe. Hasta que el repositorio principal añada una opción de descarga de MoE a la CPU o divida limpiamente el archivo GGUF entre dos tarjetas de 16 GB, las tarjetas con 12 GB o 16 GB de VRAM no pueden alojar tanto el decodificador como el codificador F16 en la memoria de la GPU sin parches personalizados.

Cómo ejecutar Nemotron 3.5 Transcribe localmente mediante /v1/audio/transcriptions

Una vez que dispongas de un equipo con al menos 24 GB a 32 GB de VRAM (para Linux + GPU NVIDIA) o 32 GB+ de memoria unificada, puedes configurar tu entorno local.

Para las GPU NVIDIA, SGLang-Omni ofrece soporte desde el primer día para servir el modelo con alto rendimiento. Para los pesos GGUF cuantizados en Mac o estaciones de trabajo de escritorio, NeMo-Speech.cpp expone un servidor local a través de nemo-speech serve. Este es el flujo de trabajo paso a paso para poner en marcha tu endpoint local y transcribir una grabación con múltiples hablantes:

1. Descarga los pesos cuantizados en lugar de BF16. Si ejecutas SGLang-Omni en una GPU NVIDIA de 24 GB+, descarga nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B-NVFP4 (o la variante -FP8) desde Hugging Face. Si utilizas NeMo-Speech.cpp en una Mac con 32 GB+ de memoria unificada, descarga tanto el archivo decodificador NVIDIA-Nemotron-3.5-Transcribe-30B-A4B-AD-IQ4_NL.gguf como el archivo codificador de audio Encoder-F16.gguf.
2. Prepara el archivo de audio de tu reunión. Convierte el archivo guardado de Zoom, Teams o tu grabadora en un archivo estándar .wav o .mp3 mono a 16 kHz (ffmpeg -i meeting.m4a -ar 16000 -ac 1 meeting.wav). Mantener los archivos individuales por debajo de los 60 minutos garantiza que te mantengas dentro de la ventana de contexto entrenada del modelo y evita picos de memoria en la caché KV.
3. Inicia el servidor de transcripción local. Con SGLang-Omni instalado en tu entorno de Python, inicia el servidor apuntando al punto de control en el puerto 8000 (siguiendo los argumentos de inicio de la guía práctica de SGLang-Omni para Nemotron Transcribe). Si en su lugar utilizas NeMo-Speech.cpp con archivos GGUF, ejecuta nemo-speech serve --asr-model NVIDIA-Nemotron-3.5-Transcribe-30B-A4B-AD-IQ4_NL.gguf junto con la ruta del codificador F16 y espera hasta que el modelo de ~20 GB termine de cargarse en la memoria.
4. Envía el archivo de audio a /v1/audio/transcriptions. Una vez que el servidor esté escuchando localmente, envía una solicitud POST usando curl o un cliente HTTP estándar de Python para generar una transcripción con etiquetas de hablantes:

curl http://localhost:8000/v1/audio/transcriptions \
  -H "Content-Type: multipart/form-data" \
  -F file="@meeting.wav" \
  -F model="nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B-NVFP4" \
  -F response_format="verbose_json" \
  -F timestamp_granularities[]="word" \
  -F timestamp_granularities[]="segment"

Si quieres que el modelo traduzca una grabación multilingüe o con alternancia de código a otro idioma de destino durante la misma pasada, incluye el parámetro del idioma de destino en el cuerpo de la solicitud o en la configuración del prompt compatible con tu backend de servidor, y guarda el resultado JSON devuelto en el disco.

Dos errores locales a tener en cuenta en AMD ROCm y Apple Silicon

Si te apartas de una configuración estándar con CUDA o de NeMo-Speech.cpp en Mac, existen dos problemas específicos de plataforma con los que puedes toparte ahora mismo y que parecen fallos de hardware si no sabes qué los provoca.

En primer lugar, si compilas NeMo-Speech.cpp con HIP/ROCm para una GPU AMD (como una Radeon AI PRO R9700 o RX 7900 XTX en ROCm 7.x), los clips de audio cortos de 30 o 60 segundos se transcribirán bien, pero cualquier archivo de audio de más de unos 120 a 160 segundos se bloqueará indefinidamente. Cuando esto ocurre, el uso de tu GPU cae al 0% mientras un único hilo de la CPU se queda al 100% dentro de hipStreamSynchronize, y nemo-speech serve se bloquea ante las solicitudes posteriores. Esto sucede porque NeMo-Speech.cpp fija un commit antiguo del submódulo llama.cpp anterior a la integración de la corrección ARGSORT de HIP en el repositorio principal; cuando la duración del audio hace que la matriz de ordenación supere las 1,024 columnas en una compilación ROCm sin CUB, la ejecución se detiene. Actualizar o aplicar un parche al submódulo subyacente ggml/llama.cpp para incluir la corrección ARGSORT de HIP resuelve el bloqueo en archivos de más de dos minutos.

En segundo lugar, si estás en una Mac e intentas ejecutar el modelo a través de mlx-audio en lugar de NeMo-Speech.cpp, no esperes que la exportación de subtítulos .srt o .vtt funcione todavía. Aunque los pesos públicos en Hugging Face incluyen el cabezal ctc_timestamp.* para la sincronización por palabra, mlx-audio actualmente descarta los pesos ctc_timestamp.* al cargar el modelo. Debido a que esos pesos de marcas de tiempo se eliminan en el momento de la carga, mlx-audio solo puede generar transcripciones en texto plano .txt o .json básico. Si tu objetivo final es generar archivos de subtítulos SRT o VTT sincronizados y con etiquetas de hablantes, quédate con SGLang-Omni o NeMo-Speech.cpp para que el cabezal de marcas de tiempo CTC permanezca intacto.