Cinque motori musicali, un solo adapter

Di recente un potenziale cliente mi ha chiesto di stimare l'aggiunta della generazione musicale con l'IA al suo prodotto. Due generatori, l'utente sceglie uno stile, esce una canzone. In superficie è una richiesta POST a un provider e un pulsante play. Per rispondere alle sue domande ho finito per mappare gran parte del mercato, e il panorama si è rivelato abbastanza interessante da spingermi a costruire l'integrazione cinque volte, con cinque motori diversi, per mostrare cosa serve davvero. Il risultato è un piccolo proof of concept funzionante: un livello adapter, cinque provider, una CLI e una UI da studio dockerizzata in cui cambiare motore è un dropdown.

Ecco cosa insegna questo esercizio.

La chiamata API è la parte facile

La generazione musicale non è richiesta e risposta. Una traccia impiega da 30 secondi ad alcuni minuti per il rendering, quindi la vera ingegneria è tutto ciò che sta intorno alla chiamata: un modello di job, webhook oppure polling con backoff, retry che tollerano uno status endpoint instabile, timeout che falliscono in modo rumoroso, e lo storage. Soprattutto lo storage. Gli URL dei provider scadono: uno cancella i file dopo 14 giorni, un altro dopo una settimana, un terzo uccide il link dopo 24 ore. Se il tuo prodotto salva l'URL del provider invece dell'audio, la libreria dei tuoi utenti marcisce in silenzio. La prima regola quando costruisci su queste API è scaricare il file nel momento in cui un job va a buon fine e metterlo in uno storage di tua proprietà.

Cinque provider, cinque forme diverse

I cinque motori che ho integrato, e la forma che ognuno si è rivelato avere:

• Suno, rivenduto. Suno non ha un'API pubblica di prima parte, quindi il suono preferito dal mercato arriva attraverso rivenditori non ufficiali. Quello che ho integrato richiede un callback URL anche se fai polling, risponde ai poll in camelCase e ai webhook in snake_case per gli stessi dati, e restituisce due variazioni della traccia per ogni richiesta.
• MiniMax. Supportato ufficialmente e, sorprendentemente, sincrono: la risposta HTTP della chiamata di creazione contiene già la traccia finita. L'integrazione più semplice possibile, e il link restituito muore entro 24 ore.
• ACE-Step. Un modello open-weights con licenza Apache servito attraverso un'API a coda. La parola dello schema di autenticazione è letteralmente "Key" invece di "Bearer", e non esiste un campo prompt: vuole tag di stile e testi, dove "[inst]" significa strumentale.
• Treblo. Un'API di prima parte il cui status endpoint restituisce una stringa JSON nuda, il cui formato di output predefinito è ogg, e che richiede un'attribuzione visibile in qualsiasi prodotto rivolto agli utenti. Ha anche cambiato nome da Sonauto e spostato gli endpoint a metà della mia ricerca, come se l'universo volesse sottolineare il punto di questo articolo.
• Eleven Music. Sincrono come MiniMax, ma il corpo della risposta sono i byte audio grezzi. Nessun job id, nessun URL, niente su cui fare polling. O catturi i byte o li perdi.

Cinque provider, cinque schemi di autenticazione, tre modelli asincroni, due convenzioni di casing nelle risposte e un rebrand in una sola settimana. Niente di tutto questo deve avvicinarsi al codice del tuo prodotto.

L'adapter è la decisione di prodotto

La soluzione è vecchia, noiosa e funziona: metti ogni motore dietro un unico contratto. Il mio è fatto di due funzioni, creare un job e aggiornare un job, entrambe restituiscono la stessa forma normalizzata. L'orchestrazione, lo storage, la UI e la fatturazione non sanno mai quale motore ha girato. Aggiungere un provider è un file; cambiare provider è una stringa di configurazione; e quando un rivenditore muore da un giorno all'altro, cambia nome o compare finalmente un'API ufficiale, riconfiguri invece di riscrivere.

Quest'ultima frase non è ipotetica. I wrapper non ufficiali poggiano su un terreno legalmente conteso mentre le cause delle etichette discografiche contro i produttori dei modelli fanno il loro corso, e il wrapper che integri oggi potrebbe non esistere con lo stesso nome il prossimo trimestre. L'ho visto succedere a metà progetto. L'adapter non è un vezzo architetturale, è la polizza assicurativa.

Cosa chiederanno gli avvocati

Le domande che decidono davvero quale motore puoi usare non hanno niente a che fare con la qualità del suono:

• Diritti commerciali. Un provider ti assegna la proprietà degli output nei suoi termini. Un altro concede l'uso commerciale solo attraverso testi di marketing, senza una licenza contrattuale alle spalle. Un terzo tace del tutto per i clienti API. Sono tre posizioni di rischio molto diverse che in una demo della funzionalità sembrano tutte identiche.
• Watermark. Un motore si riserva il diritto di applicare un watermark a sua discrezione. Un altro offre content credentials in opt-in. Il modello open-weights non ne ha. Se il brand del tuo cliente non può permettersi un watermark, questo è un filtro, non una preferenza.
• Attribuzione. Un motore richiede un credito "Powered by" visibile nella tua UI. È un vincolo di design del prodotto nascosto dentro una pagina di termini.
• Manleva. Nessuno dei cinque ti difenderà se una traccia generata finisce troppo vicina alla canzone di qualcuno. Quel rischio resta a te, il che in pratica significa che i tuoi termini di servizio lo passano ai tuoi utenti. Vale un'ora di avvocato prima del lancio, non dopo.

Tengo tutto questo in una tabella comparativa nel repo, accanto al codice, perché è la tabella a cambiare quale adapter abiliti, molto più spesso di qualsiasi benchmark.

Ascolta

Un prompt, dritto attraverso l'adapter: una canzone su marito e moglie a Banff, a passeggio sulla riva del lago Louise, neve sulle cime, di nuovo innamorati. Quello che segue è esattamente ciò che è tornato indietro, una sola generazione, senza scegliere la migliore tra tante.

Treblo (Melodia v3), 2 minuti e 50:

Una nota su queste due generazioni: il prompt chiedeva una voce maschile calda, e Treblo ha fatto cantare la prima presa a una donna. La seconda, qui sotto, metteva la voce maschile nelle primissime parole del prompt, e anche quella l'ha cantata una donna. Questo motore non espone alcun parametro per il genere vocale (Suno via kie.ai ha un flag vocalGender letterale), il che trasforma un requisito di una parola in una lotteria. È una lezione che vale i crediti: quando un controllo conta per il tuo prodotto, scegli un motore che lo esponga come parametro, non come speranza nel prompt.

Questa sezione cresce man mano che faccio passare lo stesso prompt negli altri motori; le loro versioni finiranno qui fianco a fianco. Ogni output è generato dall'IA, e i diritti su di esso sono regolati dai termini del provider.

Guardalo in azione

Quello che c'è dietro questo articolo è reale e funziona: un'edizione CLI Node senza dipendenze dell'adapter e uno studio dockerizzato FastAPI più React dove i motori e i loro modelli sono dropdown, un motore mock dimostra l'intera pipeline senza API key, e ogni traccia finita atterra nello storage locale nel momento in cui si conclude, perché a questo punto il motivo lo conosci. Lo tengo come un progetto privato funzionante, e il vantaggio di un progetto già in piedi è che il prossimo, il tuo, si costruisce molto più in fretta.

Se stai valutando la generazione musicale, o qualsiasi funzionalità generativa che gira sul modello di qualcun altro, la forma della risposta è la stessa: il provider è un plugin, il contratto è tuo, e le parti noiose, la coda, lo storage, i termini, sono il posto dove vive davvero il progetto. Ed è esattamente il tipo di lavoro che aiuto i team a portare in produzione.