PLAUD, Whisper y MCP en la práctica: de la idea a una arquitectura real

Serie PLAUD MCP · Parte 2

En la primera parte de este proyecto planteaba una idea bastante concreta: convertir grabaciones, reuniones, ponencias y clases en conocimiento que pudiera reutilizar después. Sobre el papel, el flujo parecía sencillo. En cuanto empecé a construirlo, aparecieron preguntas mucho menos vistosas: ¿dónde debe ejecutarse Whisper?, ¿qué ocurre si las dos máquinas no están en la misma red?, ¿cómo evito que cada herramienta trabaje con un formato diferente?

La primera parte de la serie estaba centrada en el propósito. Esta segunda parte empieza cuando ese propósito se convierte en una arquitectura real, con decisiones sobre entradas, contratos de datos, red, GPU, privacidad y límites de automatización.

De una única vía a dos entradas equivalentes

El planteamiento inicial podía resumirse en una frase: «PLAUD entra y las skills procesan». En la práctica, el sistema ha terminado teniendo dos vías de entrada diferentes:

• PLAUD MCP: cuando PLAUD ya dispone de una transcripción asociada a la grabación.
• Audio local + Whisper remoto: cuando parto de un archivo de audio y quiero controlar directamente el motor de transcripción.

La complejidad adicional queda encerrada en la entrada. A partir de ahí, el resto del sistema debería trabajar igual. Las herramientas pueden cambiar, pero las skills que convierten la transcripción en decisiones, ideas o material docente no deberían tener que conocer todos esos detalles.

Esta forma de pensar también conecta con el módulo de Digitalización Aplicada a los Sectores Productivos: la tecnología no aparece aislada, sino dentro de un sistema de procesos, datos y personas.

La decisión clave: una transcripción como contrato

PLAUD y Whisper no devuelven exactamente la misma información. PLAUD aporta sus propios metadatos y marcas temporales. Whisper devuelve segmentos generados por el modelo. Si cada skill posterior dependiera de esos detalles, cualquier cambio de proveedor terminaría afectando a todo el proyecto.

Por eso he introducido un contrato común de transcripción. No pretende ocultar el origen del contenido, sino ordenar la información que realmente necesita el sistema:

• el origen de la transcripción: plaud o local_audio;
• el transcriptor utilizado;
• el idioma y la duración;
• los segmentos con su texto y sus tiempos en segundos;
• los participantes, únicamente cuando existen realmente en la fuente.

El normalizador también resuelve pequeñas diferencias entre proveedores. Por ejemplo, convierte los timestamps de PLAUD de milisegundos a segundos para que la salida tenga una unidad común.

Qué ha funcionado con PLAUD MCP

La vía PLAUD MCP ya está validada para el flujo básico:

1. listar las grabaciones;
2. consultar sus metadatos;
3. recuperar la transcripción;
4. normalizarla;
5. entregarla al resto del sistema.

La autenticación OAuth permanece fuera del repositorio. El proyecto contiene código, contratos y plantillas, pero no tokens ni datos reales.

También confirmé una decisión importante: la transcripción es la fuente primaria. PLAUD puede generar resúmenes útiles para leer rápidamente una grabación, pero ese resumen no entra en el flujo posterior de análisis. Si quiero extraer decisiones, tareas o material docente de forma reproducible, prefiero trabajar sobre la transcripción original.

Por qué apareció Whisper

PLAUD resuelve bien el caso en el que ya existe una transcripción disponible. Pero no todos los escenarios empiezan así. Puede haber un audio local, una grabación exportada o una sesión registrada con otro dispositivo. También puede interesarme controlar directamente el motor de transcripción.

Ahí entra Whisper. La implementación concreta utiliza faster-whisper, CUDA y el modelo small. La primera idea era ejecutarlo en el VPS. En la práctica, la GPU está en una Spark privada, así que el diseño tuvo que cambiar.

La red también forma parte del sistema

El VPS y la Spark no están en la misma red. El VPS actúa como orquestador, mientras que la Spark está alojada en una red local y es la máquina que dispone de la GPU. Por tanto, la comunicación entre ambos pasa por una VPN privada.

Esta decisión tiene una ventaja clara: el servicio Whisper no necesita exponerse directamente a Internet. La petición viaja por una red privada y el servicio queda dentro de la infraestructura que controlo.

Pero la VPN también introduce una dependencia operativa. Si falla, la Spark puede seguir funcionando y Whisper puede continuar cargado en la GPU, pero el VPS deja de poder utilizarlo. La estabilidad de la red deja de ser un detalle externo y pasa a formar parte de la arquitectura.

Cuando la infraestructura deja de ser invisible

La prueba extremo a extremo ya ha funcionado. El recorrido completo ha sido:

• una petición sale del VPS;
• atraviesa la VPN;
• llega a la Spark;
• Whisper procesa el audio;
• el servicio devuelve un JSON con los segmentos.

En una prueba corta en español se obtuvieron diez segmentos correctamente. Pero la VPN todavía puede interrumpir una subida o una respuesta. Mientras esa parte no esté suficientemente estabilizada, he preferido no automatizar el servicio como si fuera completamente fiable.

No es el punto final. Es una decisión deliberada: automatizar antes de conocer bien los fallos solo consigue ocultarlos.

Compartir GPU y proteger los datos

La Spark no se dedica exclusivamente a Whisper. Ollama y sus modelos permanecen activos en la misma máquina. Por eso el servicio Whisper se ejecuta con un único proceso: --workers 1.

La razón es sencilla: evitar que se carguen varias copias del modelo y reducir la competencia por la GPU. Este tipo de detalle no aparecía en el diagrama inicial del proyecto, pero termina formando parte de su comportamiento real.

Las grabaciones y transcripciones pueden contener información sensible, así que la privacidad tampoco se ha dejado para una fase posterior.

• Los tokens OAuth de PLAUD, las claves y los archivos de entorno quedan fuera de Git.
• Los audios reales, las transcripciones y las salidas sensibles no forman parte del repositorio.
• El audio recibido se almacena temporalmente y se elimina al terminar la petición.
• El servicio no conserva grabaciones ni transcripciones del usuario.
• El texto transcrito no se registra como parte del funcionamiento normal.

Qué funciona y qué queda pendiente

Las primeras fases ya están completadas o validadas:

• estructura, contrato, plantillas, documentación y tests;
• integración segura con PLAUD MCP;
• servicio privado Whisper con faster-whisper y CUDA en la Spark.

La siguiente fase unirá todas las piezas:

• cliente HTTP desde el VPS;
• validación del endpoint;
• reintentos explícitos;
• normalización automática;
• selección de plantilla y generación Markdown.

Después vendrán la observabilidad, el despliegue persistente y, si la red responde de forma suficientemente estable, la automatización y el procesamiento desatendido.

La arquitectura que me llevo

La solución práctica no es «PLAUD contra Whisper». Es una capa de entrada con dos adaptadores y un contrato común:

PLAUD sigue siendo la vía más directa cuando ya existe una transcripción. Whisper aporta una alternativa controlable para el audio local. MCP conecta la fuente con el entorno de trabajo. La VPN conecta dos máquinas que viven en redes distintas. Y el contrato común evita que todas esas decisiones se propaguen por el resto del sistema.

Ese ha sido el principal aprendizaje de esta fase: la parte difícil no era conseguir que un modelo transcribiera un audio. Era construir un flujo en el que transcripciones de distintos orígenes pudieran utilizarse de forma segura, trazable y honesta.

Fuente principal

Documentación y pruebas del proyecto PLAUD MCP, Whisper y arquitectura privada de transcripción.

La serie continúa

En la tercera parte de la serie abordo el paso que queda entre la transcripción y el RAG: seleccionar, estructurar y revisar el conocimiento que realmente merece conservarse.