# Architecture du modèle Suno Ce document décrit l’architecture visible dans les branches `HEAD` des dépôts présents dans `/mnt/workspace/suno/`, principalement `Glockenspiel.git`, `neon.git` et `tony.git`. Il faut distinguer trois niveaux de certitude : - **Confirmé par le code** : structure, dimensions et flux explicitement présents dans les sources ou les configurations. - **Dépendant du checkpoint** : valeur relue depuis le checkpoint au chargement et non récupérable depuis son seul nom. - **Historique ou expérimental** : architecture encore présente dans les dépôts, mais différente du chemin sélectionné par défaut dans le snapshot. Le worker sélectionné par défaut dans le snapshot de `Glockenspiel.git` est `6b_sem_t3`. Cela décrit le chemin configuré dans ce code, pas nécessairement la version actuellement servie par Suno hors de ce snapshot. --- ## 1. Overview ### 1.1 Vue d’ensemble Le système n’est pas un modèle unique qui produit directement une forme d’onde. C’est une pile hiérarchique à trois étages principaux : 1. un **Transformer autorégressif sémantique** planifie le morceau sous forme de tokens audio à 25 Hz ; 2. un **Transformer latent de diffusion ou de flow** transforme cette structure sémantique en latents audio continus à 25 Hz ; 3. un **codec neuronal DAC-VAE** décode les latents en audio stéréo 48 kHz. ```mermaid flowchart LR A[Paroles, tags, consignes] --> P[Construction du prompt multimodal] R[Audio de référence] --> E1[MERT ou MusicFM 25 Hz] R --> E2[DAC-VAE encoder] R --> E3[Hoot / Ditto] E1 --> P E2 --> P E3 --> P P --> G[Transformer sémantique autorégressif ~6B] G --> S[Tokens sémantiques 25 Hz] S --> D[Transformer latent ~2B] P --> D E2 --> D D --> Z[Latents VAE 128 canaux à 25 Hz] Z --> V[Décodeur DAC-VAE] V --> O[Audio stéréo 48 kHz] ``` ### 1.2 Pile sélectionnée par défaut dans le snapshot | Étage | Variante sélectionnée | Rôle | |---|---|---| | Planificateur | `6b_sem_t3` | Génération autorégressive de tokens sémantiques musicaux à 25 Hz | | Checkpoint sémantique | `model_45_6b_crow_sft0828_t14_r15_d87.pt` | Modèle 6B après SFT et plusieurs itérations de préférence/DPO | | Générateur latent | famille `v45_2b...infill...` | Conversion tokens sémantiques → latents VAE continus | | Codec | `dac_vae_tuned_25hz.pth` ou variante PEAQ | Conversion latents 128D à 25 Hz ↔ audio stéréo 48 kHz | | Encodeur sémantique | MERT 25 Hz, avec clustering 4k | Création des cibles et des références sémantiques | | Tokenizer texte | vocabulaire d’environ 60k tokens | Paroles, styles, tags et contrôles | | Hoot | CTC audio-vers-texte | Transcription, alignement et contrôle temporel des paroles | | Ditto | encodeur contrastif texte-audio | Embedding global de style ou de « vibe » | ### 1.3 Contrat tensoriel entre les étages Pour une durée audio de `T` secondes : | Représentation | Forme conceptuelle | Cadence | |---|---:|---:| | Tokens texte | `[B, L_text]` | tokenizer 60k | | Tokens sémantiques | `[B, 25 × T]`, éventuellement plusieurs codebooks | 25 Hz | | Latents VAE | `[B, 128, 25 × T]` | 25 Hz | | Audio | `[B, 2, 48000 × T]` | 48 kHz stéréo | Le codec utilise un facteur temporel total de : ```text 2 × 3 × 5 × 8 × 8 = 1920 48000 / 1920 = 25 Hz ``` Chaque latent VAE représente donc exactement 40 ms d’audio. ### 1.4 Conditionnements acceptés Le système de prompt est structuré en blocs typés et ne se limite pas à une simple concaténation texte + audio. Les types visibles dans `sunoGPT/block_types.py` comprennent notamment : - paroles, tags, consignes et embeddings mmBERT ; - tokens Hoot pour le placement temporel des paroles ; - embedding Ditto de style global ; - historique et futur audio ; - artiste, playlist, cover et remix ; - voix de référence (`vox`) ; - underpaint : voix fournie, instrumental à compléter ; - overpaint : instrumental fourni, voix à compléter ; - stem manquant, sample, mashup et source de sample ; - préfixe, suffixe et infill ; - contexte VAE continu pour la diffusion ; - description textuelle associée à un conditionnement audio. Chaque bloc indique s’il est causal ou non causal. Le Transformer construit ensuite un masque d’attention à partir de : - l’identifiant du document packé ; - l’identifiant du bloc ; - la causalité propre au bloc ; - la fenêtre d’attention locale éventuelle. Cela permet de mélanger dans une seule séquence des entrées bidirectionnelles, des sorties autorégressives et plusieurs exemples packés. ### 1.5 Transformer sémantique #### Configuration de la famille 6B récente Les scripts récents `dodo`, `auk_6b` et leurs variantes utilisent : | Paramètre | Valeur | |---|---:| | Nombre de blocs | 32 | | Largeur résiduelle | 4096 | | Têtes Q | 32 | | Têtes K/V | 4 par défaut | | Dimension par tête | 128 | | Contexte d’entraînement | 32 000 positions | | Vocabulaire texte | 60 032 | | Codebook texte utile | 60 001 | | Vocabulaire sémantique | 4 032 | | Codebook sémantique utile | 4 000 | | Cadence sémantique | 25 Hz | | Position | RoPE, `theta = 500000` | | Normalisation Q/K | oui | | Activation MLP | SwiGLU | | Précision | bfloat16 | Avec une largeur de 4096, le MLP SwiGLU utilise une dimension interne arrondie à 11 008 : ```text round_multiple_256((4 × 4096) × 2 / 3) = 11008 ``` #### Bloc Transformer Chaque couche est pré-normalisée : ```text x = x + Attention(LayerNorm(x)) x = x + SwiGLU(LayerNorm(x)) ``` L’attention possède : - des projections Q, K et V séparées ; - une Grouped-Query Attention lorsque `n_kv_head < n_head` ; - une LayerNorm par tête sur Q et K ; - RoPE ; - FlashAttention 2 ou 3 sur les séquences causalement simples ; - FlexAttention lorsque le masque mélange plusieurs documents ou blocs causaux/non causaux ; - une fenêtre glissante configurable, avec des couches globales périodiques. Le MLP est un SwiGLU : ```text MLP(x) = Wout(SiLU(Wgate(x)) × Wvalue(x)) ``` #### Entrées et sorties modulaires Le Transformer possède plusieurs modules d’entrée additionnés dans le flux résiduel : - texte tokenisé ; - tokens sémantiques d’un ou plusieurs codebooks ; - embeddings sémantiques continus ; - embeddings mmBERT ; - latents VAE ; - timestep de diffusion ; - sorties Hoot ; - embedding Ditto ; - embedding du type de bloc. Ses têtes de sortie peuvent prédire : - les tokens sémantiques autorégressifs ; - des embeddings sémantiques continus ; - des latents VAE ; - du texte ; - un score de récompense ; - des cibles auxiliaires RePA : sémantique continu, Hoot, MIDI ou représentation mixée. Le chemin `6b_sem_t3` est un modèle **semantic-only** : il émet des tokens sémantiques, sans ancien flux acoustique « coarse ». #### Codebooks sémantiques Deux variantes coexistent dans le snapshot : - le chemin historique et plusieurs checkpoints déployés utilisent un codebook de 4 000 entrées ; - les sources les plus récentes savent utiliser quatre codebooks RVQ, intercalés avec un motif de retard hiérarchique. Le nombre exact de codebooks de `6b_sem_t3` est stocké dans son checkpoint et doit être lu lors de son chargement. Le nom du checkpoint seul ne suffit pas à le certifier. Le worker applique toutefois `n_skip_semantic = 1`, donc il ne saute pas temporellement les tokens transmis à l’upsampler. ### 1.6 Encodeur sémantique Le chemin historique/déployé visible utilise MERT : - audio d’entrée à 24 kHz ; - représentation extraite à la couche 7 ; - cadence ramenée à 25 Hz ; - quantification par centroïdes, généralement 4 000 clusters ; - support de plusieurs codebooks résiduels dans les versions récentes. Le code plus récent accepte aussi MusicFM : - mode k-means externe ; - mode quantification interne ; - variantes RVQ multi-codebooks. Cet encodeur ne produit pas l’audio final. Il fournit une représentation discrète de haut niveau : rythme, mélodie, phonétique, structure et contenu musical, mais pas tous les détails acoustiques fins. ### 1.7 Transformer latent Le générateur latent reçoit la structure sémantique et génère les 128 canaux continus attendus par le VAE. La famille v4.5/2B visible utilise : | Paramètre | Valeur | |---|---:| | Cadence entrée/sortie | 25 Hz | | Canaux latents | 128 | | Largeur Transformer | 2048 | | Profondeur | 32 blocs | | Têtes | 32 | | Dimension par tête | 64 | | Longueur audio d’un bloc | 750 tokens = 30 s | | Tokens sémantiques conditionnants | 750 | | Tokens texte maximum du modèle | 1 536 | | Contexte latent | jusqu’à 750 tokens | | QK normalization | oui | | Position | RoPE, base 50 000 | #### Conditionnement Les éléments suivants sont projetés dans la largeur 2048 puis placés avant les tokens audio : - embedding du texte ; - embedding des tokens sémantiques ; - contexte latent du chunk précédent ; - contexte de préfixe/suffixe pour l’infill ; - référence vocale ; - contexte de stem ; - embedding Fourier du timestep, projeté par un MLP. Le masque d’attention forme deux zones : 1. la zone de conditionnement, qui reste interne à elle-même ; 2. la zone audio, qui peut voir le conditionnement et les tokens audio. Le cœur est un Transformer continu pré-norm : ```text latent 128D → projection 2048D → 32 × [attention complète + SwiGLU] → projection 128D ``` Une convolution 1×1 résiduelle est appliquée avant et après le Transformer. #### Diffusion v4.5 et rectified flow v3 Deux familles sont présentes : - le checkpoint sélectionné pour `6b_sem_t3` appartient à la famille v4.5 « 2B » ; le code de génération associé utilise par défaut une formulation `v` avec sampler DPM++ et dix étapes ; - les configurations `25hz_v3_flow_shared_*` plus récentes utilisent explicitement le **rectified flow**, avec sampling log-SNR et contexte partagé. Il ne faut pas confondre ces deux générations. L’objectif exact est relu dans la configuration du checkpoint au chargement. ### 1.8 Codec DAC-VAE Le codec est un autoencodeur convolutionnel stéréo inspiré de Descript Audio Codec. #### Encodeur ```text Audio [B, 2, N] → Conv1d 2 → 128 → bloc stride 2 → bloc stride 3 → bloc stride 5 → bloc stride 8 → bloc stride 8 → Conv1d vers 256 canaux → split moyenne / échelle → échantillonnage VAE → latent [B, 128, N/1920] ``` Chaque bloc contient trois unités résiduelles avec dilatations 1, 3 et 9. Les activations sont des Snake périodiques : ```text Snake(x) = x + sin²(alpha × x) / alpha ``` Le bottleneck produit une moyenne et une échelle. L’écart-type est obtenu par `softplus`, puis un latent est échantillonné par reparamétrisation gaussienne. Une perte KL régularise l’espace latent. #### Décodeur ```text Latent 128D → Conv1d 128 → 2048 → ConvTranspose stride 8 → ConvTranspose stride 8 → ConvTranspose stride 5 → ConvTranspose stride 3 → ConvTranspose stride 2 → Conv1d vers 2 canaux → tanh → audio stéréo 48 kHz ``` Le décodeur reconstitue donc 1 920 échantillons stéréo pour chaque token latent de 40 ms. ### 1.9 Modèles auxiliaires #### Hoot Hoot est un modèle CTC de transcription et d’alignement : - entrée 16 kHz ; - logits à environ 12,5 Hz ; - transcription des paroles ; - alignement mot par mot ; - détection de débuts/fins vocales et de longues zones instrumentales ; - possibilité de transférer le timing des paroles d’une référence. #### Ditto Ditto est un encodeur contrastif texte-audio : - audio à 24 kHz ; - embedding global à faible cadence ; - conditionnement de la couleur générale du morceau ; - interpolation possible entre plusieurs références. #### mmBERT mmBERT fournit une représentation sémantique dense du texte en complément du tokenizer discret. Son utilisation est probabiliste pendant certains entraînements récents. ### 1.10 Variantes historiques Les dépôts contiennent plusieurs générations antérieures : | Famille | Couches | Têtes Q | Dimension tête | Têtes K/V | Largeur | |---|---:|---:|---:|---:|---:| | 13B | 40 | 40 | 128 | 2 à 8 selon variante | 5 120 | | 30B | 60 | 56 | 128 | 4 | 7 168 | | 6B récente | 32 | 32 | 128 | 4 par défaut | 4 096 | Les modèles 13B et 30B restent visibles dans les scripts, checkpoints et historiques de DPO, mais le worker v4 sélectionne par défaut la famille sémantique 6B. --- ## 2. Inférence ### 2.1 Entrées utilisateur Une requête peut contenir : - paroles ; - tags de style ; - tags négatifs ; - contrôles de durée, début, fin et présence vocale ; - seed ; - audio historique ; - audio futur pour infill ; - référence artiste, playlist, cover ou voix ; - stem, sample ou morceau à transformer ; - poids de style, poids audio et contrainte de « weirdness ». Le worker nettoie les tags, détecte les générations instrumentales et ajoute les contrôles nécessaires. Les tâches spéciales modifient aussi les flux de classifier-free guidance. ### 2.2 Encodage des références Lorsqu’une référence audio est fournie, plusieurs encodages peuvent être produits : ```text Audio de référence ├─ MERT/MusicFM → tokens sémantiques 25 Hz ├─ DAC-VAE → latents continus 128D à 25 Hz ├─ Hoot → transcription et timing des paroles └─ Ditto → embedding global de style ``` Le type de tâche décide quelles représentations sont insérées dans le prompt sémantique et lesquelles sont transmises au générateur latent. ### 2.3 Construction du prompt sémantique Le moteur construit une séquence de blocs : ```text [contrôles] [tags positifs] [tags négatifs] [paroles] [références audio typées] [historique/futur éventuels] [token d’inférence sémantique] ``` Les blocs sont packés avec leurs métadonnées de causalité. Les embeddings de toutes les modalités actives sont additionnés à la position correspondante. Pour une requête de type continuation : ```text texte + tags + historique sémantique → nouveaux tokens sémantiques ``` Pour un infill : ```text texte + tags + préfixe + suffixe + zone masquée → tokens de la zone manquante ``` Pour un cover ou une référence artiste : ```text texte + tags + représentation de la référence → nouvelle trajectoire sémantique ``` ### 2.4 Décodage autorégressif des tokens sémantiques Le GPT réalise d’abord un prefill, puis génère les tokens un par un avec KV cache. Réglages par défaut du chemin `6b_sem_t3` dans le worker : | Paramètre | Valeur | |---|---:| | Température sémantique | 0,90 | | Top-k | 1 500 | | Top-p | désactivé dans l’override du worker | | Min-p | 0,005 | | CFG texte principal | 1,0 | | CFG tags | 1,0 pour la variante Crow/T3 | | CFG tags négatifs | -1,0 | | EOS minimum | 0,1 | | Cadence de sortie | 25 tokens/s | Les valeurs peuvent être modifiées par une configuration d’expérience ou une configuration forcée côté développement. Le système sait construire plusieurs flux CFG indépendants. Chaque flux peut : - conserver certaines modalités ; - supprimer certaines modalités dans la branche nulle ; - utiliser un poids propre ; - n’être actif que pendant une plage de tokens. Cela permet par exemple de renforcer l’audio de référence sans renforcer les tags, ou de limiter le CFG aux premières secondes. ### 2.5 Streaming des tokens Le GPT produit un flux continu à 25 Hz. Le worker d’upsampling ne patiente pas jusqu’à la fin du morceau. Sa stratégie est : - premier chunk minimal : 125 tokens, soit 5 secondes ; - croissance progressive des chunks ; - bloc maximal : 750 tokens, soit 30 secondes ; - retrait des cinq derniers tokens des chunks non finaux pour réduire les artefacts de frontière ; - priorité au job dont le buffer audio est le plus proche du temps réel. Le buffer est mesuré ainsi : ```text buffer = durée_audio_déjà_générée - temps_réel_écoulé ``` ### 2.6 Tokens sémantiques vers latents VAE Pour chaque chunk, l’upsampler prépare : - les tokens sémantiques du chunk ; - les latents des chunks précédents ; - les latents initiaux éventuels ; - le préfixe et le suffixe d’infill ; - un contexte de stem ; - le texte et les tags tokenisés ; - les masques de modalités. Puis il appelle le générateur latent : ```text z_chunk = latent_model( noise, semantic_tokens, text_tokens, previous_latents, infill_prefix, infill_suffix, voice_or_stem_context ) ``` Le modèle peut calculer en un seul batch : - la branche complètement conditionnée ; - une branche sans texte ; - une branche sans tags ; - une branche sans sémantique ; - une branche sans historique ; - une branche sans contexte d’infill ; - une branche sans stem. Les sorties sont combinées indépendamment : ```text v = v_cond + Σ scale_i × (v_cond - v_without_i) ``` ### 2.7 Sampling latent Le code supporte deux familles principales. #### Famille v4.5 Le chemin associé au checkpoint sélectionné utilise par défaut : - objectif `v` ; - dix étapes ; - sampler DPM++ ; - schedule polyexponentiel ; - `sigma_min = 0.5` ; - `sigma_max = 50` ; - mise à l’échelle VAE 0,4 pour les variantes v2. #### Famille rectified flow v3 Les expériences récentes utilisent : - objectif rectified flow ; - timesteps distribués par log-SNR ; - solveurs Euler, RK4, DPM++ adapté au flow ou ping-pong ; - possibilité de distiller le modèle vers très peu d’étapes. Le sampler réellement choisi dépend de la configuration sauvegardée avec le checkpoint. ### 2.8 Continuité entre chunks Les latents déjà générés sont utilisés comme contexte du chunk suivant. Le modèle dispose d’un conditionneur de contexte latent distinct. Pour une continuation longue : ```text chunk N-1 latents + semantic chunk N → latent chunk N ``` Pour les chunks non finaux, quelques tokens sont recalculés ou supprimés à la frontière. Le décodeur audio applique ensuite un chevauchement et un mélange temporel. ### 2.9 Infill L’infill existe à deux niveaux : 1. le GPT sémantique prédit le contenu structurel manquant entre un préfixe et un suffixe ; 2. le générateur latent reçoit les latents connus avant et après la zone à remplacer. Le chemin de remplacement final limite typiquement le contexte à : - 10 secondes d’historique ; - 10 secondes de futur ; - 10 secondes de zone rééchantillonnée ; soit 750 positions au total, ce qui correspond exactement au bloc de 30 secondes du modèle latent. ### 2.10 Décodage VAE et streaming audio Chaque chunk latent est envoyé au décodeur DAC-VAE : ```text [B, 128, T] → [B, 2, 1920 × T] ``` Le décodeur streaming : - regroupe plusieurs requêtes en batch GPU ; - décode des fenêtres de latents ; - conserve plusieurs tokens de recouvrement ; - fusionne les zones communes ; - émet des chunks audio successifs ; - peut reconstruire à la fin un fichier audio complet. Des valeurs fréquemment utilisées sont : - stride de 20 tokens, soit 0,8 seconde ; - overlap de 5 tokens, soit 0,2 seconde. ### 2.11 Séquence d’inférence complète ```mermaid sequenceDiagram participant U as Requête participant P as Prétraitement participant G as GPT sémantique participant D as Transformer latent participant V as DAC-VAE participant O as Stream audio U->>P: paroles, tags, références, tâche P->>P: tokenisation et encodages auxiliaires P->>G: blocs multimodaux packés loop 25 fois par seconde générée G->>G: attention avec KV cache G-->>D: token sémantique end loop dès qu’un chunk est disponible D->>D: sampling latent avec CFG D-->>V: latents 128D à 25 Hz V->>V: décodage stéréo 48 kHz V-->>O: chunk avec overlap end O-->>U: audio progressif puis fichier final ``` ### 2.12 Pseudocode simplifié ```python request = parse_request(lyrics, tags, references, task) conditions = encode_references(request) prompt = build_typed_block_sequence(request, conditions) semantic_stream = semantic_gpt.generate( prompt, temperature=0.90, top_k=1500, min_p=0.005, ) for semantic_chunk in progressive_chunks(semantic_stream, rate_hz=25): latent_chunk = latent_generator.sample( semantic=semantic_chunk, text=conditions.text, history=conditions.previous_latents, infill=conditions.infill_context, steps=checkpoint_config.steps, objective=checkpoint_config.objective, ) audio_chunk = codec.decode_streaming(latent_chunk) yield audio_chunk ``` --- ## 3. Training ### 3.1 Préparation des données La préparation transforme chaque morceau en plusieurs vues synchronisées : ```text Audio stéréo ├─ audio normalisé 48 kHz ├─ latents DAC-VAE 128D à 25 Hz ├─ tokens MERT/MusicFM à 25 Hz ├─ transcription et alignement Hoot ├─ embedding Ditto ├─ stems et masques d’activité ├─ métadonnées : artiste, genre, tags, langue, structure └─ texte tokenisé : paroles et contrôles ``` Les jeux de données sont stockés sous forme de JSONL, memmaps et métadonnées indexées. Plusieurs outils du dépôt filtrent : - doublons ; - artistes ou personas trop proches ; - mauvaises transcriptions ; - clips de faible qualité ; - erreurs de stems ; - exemples étrangers ou mal alignés ; - contenus préférés/rejetés pour DPO. ### 3.2 Entraînement du codec DAC-VAE #### Objectif Apprendre une représentation compacte, continue et décodable à 25 Hz, sans imposer une quantification discrète acoustique au générateur final. #### Générateur Le générateur contient : - encodeur DAC convolutionnel ; - bottleneck VAE 128D ; - décodeur DAC convolutionnel ; - activations Snake ; - résidus multi-dilatation. #### Discriminateurs Le code utilise une combinaison de discriminateurs : - multi-période avec périodes 2, 3, 5, 7 et 11 ; - multi-résolution STFT avec FFT 2 048, 1 024 et 512 ; - bandes fréquentielles séparées. #### Pertes par défaut | Perte | Poids par défaut | |---|---:| | Mel-spectrogramme | 15,0 | | KL VAE | 0,0001 | | Feature matching | 2,0 | | Adversariale générateur | 1,0 | | Discriminateur | 1,0 | Certaines variantes PEAQ utilisent une régularisation KL différente, indiquée dans le nom de leurs checkpoints. #### Optimisation | Élément | Valeur par défaut | |---|---:| | Optimiseur | AdamW | | LR générateur | 1,5 × 10⁻⁴ | | LR discriminateur | 3 × 10⁻⁴ | | Betas | 0,8 / 0,99 | | Weight decay | 0 | | Gradient clip générateur | 10 | | Gradient clip discriminateur | 1 000 | | Précision | bfloat16 | Le codec peut ensuite être gelé et utilisé pour préencoder tous les morceaux destinés au Transformer latent. ### 3.3 Entraînement de l’encodeur sémantique L’encodeur sémantique est entraîné séparément ou importé depuis une famille préentraînée. Le chemin MERT : 1. extrait des représentations audio continues ; 2. sélectionne une couche intermédiaire ; 3. ramène la cadence à 25 Hz ; 4. apprend ou charge des centroïdes k-means ; 5. remplace chaque frame par l’identifiant du centroïde le plus proche. Les variantes plus récentes MusicFM/RVQ apprennent plusieurs codebooks résiduels. Les motifs temporels de ces codebooks peuvent être décalés et entrelacés avant l’apprentissage autorégressif. ### 3.4 Préentraînement du Transformer sémantique #### Cible La cible principale est une cross-entropy sur les tokens sémantiques du morceau. Pour plusieurs codebooks : ```text L_semantic = Σ w_k × CE(logits_k, target_k) ``` Les derniers codebooks peuvent recevoir un poids inférieur, car ils décrivent des détails plus fins. Une z-loss de l’ordre de `1e-5` stabilise les logits. #### Données multitâches Pendant l’entraînement, un exemple peut être converti en : - génération texte-vers-musique ; - continuation ; - infill ; - cover ; - conditionnement artiste ou playlist ; - ajout d’un stem ; - reconstruction sous voix ou sous instrumental ; - référence vocale ; - inclusion d’un sample ; - transformation de morceau ; - reconstruction textuelle auxiliaire. Le modèle apprend donc les tâches dans une même grammaire de blocs, plutôt qu’avec une architecture différente par fonction. #### Configuration 6B récente Les lancements `dodo`/`auk_6b` utilisent typiquement : | Paramètre | Valeur | |---|---:| | Couches | 32 | | Largeur | 4 096 | | Têtes Q | 32 | | Dimension tête | 128 | | Contexte | 32 000 | | Microbatch | 2 | | LR de préentraînement | 5 × 10⁻⁴ | | Warmup | 1 000 itérations | | Weight decay | 0,1 | | Betas AdamW | 0,9 / 0,9 | | Gradient clip | 1,0 | | Précision | bfloat16 | | Distribution | FSDP | | Activation checkpointing | activé | Un lancement visible utilise 32 nœuds × 8 GPU H100, soit 256 GPU. #### Packing Plusieurs documents sont concaténés dans une seule longue séquence. Le masque interdit toute attention entre documents, tout en conservant les règles causales propres à chaque bloc. Cela augmente fortement le taux de remplissage du contexte de 32k positions. #### Pertes auxiliaires Le code peut ajouter : - reconstruction de texte ; - prédiction sémantique continue ; - représentation Hoot ; - représentation MIDI ; - représentation mixée adaptée aux stems ; - tête de récompense. Ces têtes peuvent être attachées à une couche intermédiaire ou à la dernière couche. ### 3.5 Supervised fine-tuning du GPT Après préentraînement, les scripts SFT : - chargent le checkpoint principal ; - sélectionnent des exemples filtrés de haute qualité ; - réduisent généralement le learning rate à `5e-5` ; - entraînent environ 10 000 étapes dans les configurations visibles ; - ajustent la fréquence des tâches, notamment stems, covers et transformations ; - conservent FSDP, bfloat16 et activation checkpointing. Le checkpoint `6b_sem_t3` porte dans son nom la trace d’un SFT suivi de plusieurs itérations de préférence. ### 3.6 DPO, IPO et modèle de récompense du GPT Les dépôts contiennent : - `train_dpo.py` ; - des chaînes de DPO/IPO ; - un modèle de récompense ; - des caches de scores ; - des datasets chosen/rejected ; - de nombreux checkpoints successifs 13B, 30B puis 6B. Le principe est : ```text prompt + sortie préférée + sortie rejetée → log-probabilités du modèle courant → comparaison à un modèle de référence → perte de préférence ``` Cette étape ajuste surtout : - qualité musicale perçue ; - respect des paroles et du style ; - cohérence longue ; - gestion des fins de morceau ; - comportement en cover, extension et infill ; - compromis créativité/fidélité. Les suffixes `t1`, `t2`, `t3`, etc. correspondent à des générations successives de préférence, pas à des changements fondamentaux de topologie. ### 3.7 Entraînement du Transformer latent v4.5 #### Données Chaque exemple contient : - latents VAE cibles `[128, 750]` pour 30 secondes ; - tokens sémantiques `[750]` ; - texte tokenisé, jusqu’à 1 536 positions ; - contexte latent précédent ; - éventuellement contexte futur, voix ou stem. #### Objectif La famille v4.5 apprend à débruiter les latents VAE avec une paramétrisation de diffusion de type `v`. Le texte, la sémantique et les contextes peuvent être supprimés aléatoirement pendant l’entraînement afin de rendre possible le classifier-free guidance à l’inférence. #### Optimisation typique | Paramètre | Valeur | |---|---:| | LR | 5 × 10⁻⁵ | | Betas | 0,9 / 0,999 | | Weight decay | 0,001 | | Gradient clip | 0,5 | | EMA | activée | | Précision | mixte/bfloat16 selon lancement | | Longueur | 750 latents = 30 s | Le modèle est ensuite fine-tuné pour : - infill ; - continuité entre chunks ; - contexte partagé ; - références vocales ; - stems ; - données synthétiques ou étrangères ; - guidance plus fine. ### 3.8 Entraînement rectified flow v3 La configuration récente `25hz_v3_flow_shared_pretrain.json` conserve la même géométrie 2B : - 128 canaux à 25 Hz ; - largeur 2 048 ; - 32 couches ; - 32 têtes ; - blocs de 750 positions ; - contexte partagé. Elle remplace l’objectif par : ```text velocity target = x_data - x_noise x_t = interpolation(x_noise, x_data, t) ``` avec timesteps échantillonnés via une distribution log-SNR. Configuration visible : | Paramètre | Valeur | |---|---:| | Étapes prévues | jusqu’à 10 000 000 | | Batch par GPU | 1 | | Réutilisation du batch | 4 | | LR | 5 × 10⁻⁵ | | Warmup | 10 000 | | Weight decay | 0,001 | | Gradient clip | 0,5 | | EMA | oui | | Compilation | oui | Augmentations/abandons de conditionnement visibles : | Augmentation | Probabilité | |---|---:| | Drop texte | 0,10 | | Masquage sémantique | 0,10 | | Masquage contexte | 0,20 | | Exemple stem | 0,10 | | Exemple voix | 0,90 | | Exemple infill | 0,10 | | Texte précisément aligné | 0,25 | Le contexte audio reçoit aussi du bruit afin d’empêcher le modèle de simplement recopier les latents adjacents. ### 3.9 DPO du générateur latent `sunoDiff/train_dpo.py` entraîne le générateur latent sur des paires préférées/rejetées. La préférence peut être calculée à plusieurs niveaux de bruit. Le modèle courant est comparé à un modèle de référence pour éviter une dérive excessive. Cette étape optimise directement la qualité acoustique et le respect des conditionnements, alors que le DPO du GPT agit surtout sur la trajectoire sémantique. ### 3.10 Distillation du rectified flow La configuration de distillation visible utilise : - un teacher complet ; - un student initialisé depuis le teacher ; - un critic/discriminateur ; - une discrétisation du temps pouvant descendre à une étape ; - un CFG texte de 1,5 ; - un learning rate student de `1e-6` ; - un learning rate critic de `5e-5` ; - cinq mises à jour critic par cycle dans la configuration visible ; - 200 000 étapes et scheduler cosinus. Le but est de remplacer le sampling multi-étapes par une génération beaucoup plus courte, sans changer le contrat 128D à 25 Hz du codec. ### 3.11 Ordre global d’entraînement ```mermaid flowchart TD A[Corpus audio + paroles + métadonnées] --> B[Nettoyage, stems, alignements] B --> C[Entraînement DAC-VAE] C --> C1[Latents 128D à 25 Hz] B --> D[Entraînement ou adaptation MERT/MusicFM] D --> D1[Tokens sémantiques à 25 Hz] C1 --> E[Dataset multimodal packé] D1 --> E B --> E E --> F[Préentraînement GPT sémantique] F --> G[SFT multitâche] G --> H[DPO / IPO / reward model] C1 --> I[Entraînement diffusion v4.5 ou flow v3] D1 --> I B --> I I --> J[Fine-tuning infill / context / stems] J --> K[DPO latent] K --> L[Distillation éventuelle] H --> M[Pile d’inférence] L --> M C --> M ``` ### 3.12 Dépendances entre les modèles L’ordre est important : 1. le codec fixe l’espace latent acoustique ; 2. l’encodeur sémantique fixe le vocabulaire de structure ; 3. le GPT apprend à produire ce vocabulaire ; 4. le générateur latent apprend la correspondance structure → acoustique ; 5. les étapes de SFT/DPO spécialisent séparément la planification et le rendu ; 6. la distillation accélère le rendu sans modifier les interfaces entre étages. Changer le codec impose au minimum de réentraîner ou d’adapter le générateur latent. Changer les tokens sémantiques impose de réentraîner le GPT et le conditionneur sémantique du générateur latent. ### 3.13 Sources locales principales Cette reconstruction s’appuie principalement sur : ```text Glockenspiel.git/ suno_utils/suno_utils/worker/modal_runner_chirp_v4_engine.py suno_utils/suno_utils/worker/modal_model_configs.py suno_utils/suno_utils/worker/modal_model_volume.py suno_utils/suno_utils/gpt/generation.py suno_utils/suno_utils/gpt/generation_engine.py suno_utils/suno_utils/gpt/modules/ suno_utils/suno_utils/diffusion/ suno_utils/suno_utils/tasks/upsample_engine.py suno_utils/suno_utils/tasks/dac_vae_fixed_25hz.py suno_utils/suno_utils/tasks/mert_25.py suno_utils/suno_utils/tasks/hoot.py suno_utils/suno_utils/tasks/ditto_v2.py neon.git/ sunoGPT/modules/gpt.py sunoGPT/modules/base.py sunoGPT/block_types.py sunoGPT/ordering_utils.py sunoGPT/train.py sunoGPT/train_dpo.py sunoDiff/prefix_model/model.py sunoDiff/prefix_model/base.py sunoDiff/train.py sunoDiff/train_dpo.py sunoDiff/config/ sunoCodec/models/codec_dac_vae.py sunoCodec/train.py tony.git/ Inference_chirp* FineTuning_chirp_* slurm/13b_* slurm/30b_* slurm/diffusion/ ``` ### 3.14 Limites de la reconstruction Les sources permettent de reconstruire précisément la topologie et le pipeline. En revanche, les éléments suivants nécessitent l’ouverture des checkpoints eux-mêmes : - nombre exact de codebooks sémantiques de chaque checkpoint déployé ; - objectif et sampler sauvegardés avec un checkpoint latent précis ; - poids réellement actifs derrière une configuration distante modifiée après le snapshot ; - différences mineures entre le code d’entraînement ayant produit un ancien checkpoint et le code `HEAD` actuel ; - nombre exact de paramètres après prise en compte de toutes les têtes optionnelles. Le document évite donc de présenter ces valeurs dépendantes du checkpoint comme des certitudes lorsque le fichier de poids n’est pas directement inspecté.