Cinco motores de música, un solo adaptador

Hace poco, un cliente potencial me pidió estimar el alcance de añadir generación de música con IA a su producto. Dos generadores, el usuario elige un estilo y sale una canción. En la superficie es una petición POST a un proveedor y un botón de reproducción. Acabé mapeando la mayor parte del mercado para responder a sus preguntas, y el panorama resultó lo bastante interesante como para construir la integración cinco veces, contra cinco motores distintos, para mostrar lo que de verdad hace falta. El resultado es una pequeña prueba de concepto funcional: una capa de adaptadores, cinco proveedores, una CLI y una interfaz de estudio dockerizada donde cambiar de motor es un desplegable.

Esto es lo que enseña ese ejercicio.

La llamada a la API es la parte fácil

La generación de música no es petición y respuesta. Una pista tarda entre 30 segundos y unos minutos en renderizarse, así que la ingeniería de verdad está en todo lo que rodea la llamada: un modelo de trabajos, webhooks o polling con backoff, reintentos que toleren un endpoint de estado inestable, timeouts que fallen haciendo ruido, y almacenamiento. Sobre todo almacenamiento. Las URLs de los proveedores caducan: uno borra los archivos a los 14 días, otro a la semana, un tercero mata el enlace a las 24 horas. Si tu producto guarda la URL del proveedor en lugar del audio, la biblioteca de tus usuarios se pudre en silencio. La primera regla al construir sobre estas APIs es descargar el archivo en el momento en que un trabajo termina con éxito y guardarlo en un almacenamiento que sea tuyo.

Cinco proveedores, cinco formas distintas

Los cinco motores que integré, y la forma que resultó tener cada uno:

• Suno, revendido. Suno no tiene API pública de primera mano, así que el sonido favorito del mercado llega a través de revendedores no oficiales. El que integré exige una URL de callback aunque hagas polling, responde al polling en camelCase y a los webhooks en snake_case para los mismos datos, y devuelve dos variaciones de la pista por petición.
• MiniMax. Con soporte oficial y, sorprendentemente, síncrono: la respuesta HTTP de la llamada de creación ya contiene la pista terminada. La integración más simple posible, y el enlace devuelto muere en 24 horas.
• ACE-Step. Un modelo de pesos abiertos con licencia Apache servido a través de una API de colas. La palabra del esquema de autenticación es literalmente "Key" en lugar de "Bearer", y no hay campo de prompt: quiere etiquetas de estilo y letra, donde "[inst]" significa instrumental.
• Treblo. Una API de primera mano cuyo endpoint de estado devuelve un string JSON a secas, cuyo formato de salida por defecto es ogg y que exige atribución visible en cualquier producto de cara al usuario. Además cambió de marca desde Sonauto y movió los endpoints a mitad de mi investigación, lo que pareció el universo subrayando la tesis de este artículo.
• Eleven Music. Síncrono como MiniMax, pero el cuerpo de la respuesta son los bytes de audio en crudo. Sin id de trabajo, sin URL, nada que consultar. Captura los bytes o piérdelos.

Cinco proveedores, cinco esquemas de autenticación, tres modelos asíncronos, dos convenciones de nomenclatura en las respuestas y un cambio de marca en una sola semana. Nada de esto debería acercarse siquiera al código de tu producto.

El adaptador es la decisión de producto

La solución es vieja, aburrida y funciona: pon cada motor detrás de un único contrato. El mío son dos funciones, crear un trabajo y refrescar un trabajo, ambas devolviendo la misma forma normalizada. La orquestación, el almacenamiento, la interfaz y la facturación nunca se enteran de qué motor se ejecutó. Añadir un proveedor es un archivo; cambiar de proveedor es un string de configuración; y cuando un revendedor muere de la noche a la mañana, cambia de marca o por fin aparece una API oficial, reconfiguras en lugar de reescribir.

Esa última frase no es hipotética. Los wrappers no oficiales se asientan sobre un terreno legalmente disputado mientras las demandas de las discográficas contra los creadores de los modelos siguen su curso, y el wrapper que integras hoy puede no existir con el mismo nombre el próximo trimestre. Lo vi ocurrir a mitad de proyecto. El adaptador no es una floritura de arquitectura, es la póliza de seguros.

Lo que preguntarán los abogados

Las preguntas que de verdad deciden qué motor puedes usar no tienen nada que ver con la calidad del sonido:

• Derechos comerciales. Un proveedor te cede la propiedad de los resultados en sus términos. Otro concede el uso comercial solo a través de textos de marketing, sin ninguna licencia contractual detrás. Un tercero guarda silencio total para los clientes de API. Son tres posiciones de riesgo muy distintas que se ven idénticas en una demo de la funcionalidad.
• Marcas de agua. Un motor se reserva el derecho de añadir marcas de agua a su discreción. Otro ofrece credenciales de contenido opcionales. El modelo de pesos abiertos no tiene ninguna. Si la marca de tu cliente no puede cargar con una marca de agua, esto es un filtro, no una preferencia.
• Atribución. Un motor exige un crédito "Powered by" visible en tu interfaz. Eso es una restricción de diseño de producto escondida dentro de una página de términos.
• Indemnización. Ninguno de los cinco te defenderá si una pista generada acaba demasiado cerca de la canción de alguien. Ese riesgo se queda contigo, lo que en la práctica significa que tus términos de servicio lo trasladan a tus usuarios. Merece una hora de abogado antes del lanzamiento, no después.

Guardo todo esto en una tabla comparativa en el repositorio, junto al código, porque esa tabla cambia qué adaptador activas mucho más a menudo que cualquier benchmark.

Escúchalo

Un prompt, directo a través del adaptador: una canción sobre un marido y su mujer en Banff, paseando por la orilla del lago Louise, nieve en las cumbres, enamorándose otra vez. Lo que sigue es exactamente lo que volvió, una sola generación, sin elegir la mejor de varias.

Treblo (Melodia v3), 2 minutos y 50:

Una nota de estas dos generaciones: el prompt pedía voces masculinas cálidas, y Treblo cantó la primera toma con voz de mujer. La segunda, abajo, puso la voz masculina en las primeras palabras del prompt, y también la cantó una mujer. Este motor no expone ningún parámetro de género vocal (Suno vía kie.ai tiene un vocalGender literal), lo que convierte un requisito de una palabra en una lotería. Es una lección que vale los créditos: cuando un control importa para tu producto, elige un motor que lo exponga como parámetro, no como sugerencia en el prompt.

Esta sección crece a medida que paso el mismo prompt por los demás motores; sus versiones quedarán aquí lado a lado. Cada salida está generada por IA, y los derechos sobre ella se rigen por los términos del proveedor.

Míralo en marcha

Lo que hay detrás de este artículo es real y está funcionando: una edición CLI en Node del adaptador, sin dependencias, y un estudio dockerizado con FastAPI y React donde los motores y sus modelos son desplegables, un motor simulado demuestra el pipeline completo sin claves de API, y cada pista terminada queda en almacenamiento local en cuanto se completa, porque a estas alturas ya sabes por qué. Lo guardo como un prototipo privado que funciona, y la ventaja de un prototipo es que el siguiente, el tuyo, se construye mucho más rápido.

Si estás dimensionando generación de música, o cualquier funcionalidad generativa que corra sobre el modelo de otro, la forma de la respuesta es la misma: el proveedor es un plugin, el contrato es tuyo, y las partes aburridas, la cola, el almacenamiento, los términos, son donde vive realmente el proyecto. Ese es también exactamente el tipo de proyecto que ayudo a los equipos a sacar adelante.