> For the complete documentation index, see [llms.txt](https://unsloth.ai/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://unsloth.ai/docs/de/grundlagen/text-to-speech-tts-fine-tuning.md). # Leitfaden zur Feinabstimmung von Text-to-Speech (TTS) Erfahren Sie, wie Sie TTS- und STT-Sprachmodelle mit Unsloth feinabstimmen. Das Feintuning von TTS-Modellen ermöglicht es ihnen, sich an Ihren spezifischen Datensatz, Anwendungsfall oder gewünschten Stil und Ton anzupassen. Das Ziel ist es, diese Modelle so anzupassen, dass sie Stimmen klonen, Sprechstile und Tonlagen anpassen, neue Sprachen unterstützen, spezifische Aufgaben bewältigen und mehr. Wir unterstützen außerdem **Speech-to-Text (STT)** Modelle wie Whisper von OpenAI. Mit [Unsloth](https://github.com/unslothai/unsloth)können Sie **any** TTS-Modell (`transformers` kompatibel) 1,5x schneller mit 50 % weniger Speicher als andere Implementierungen mit Flash Attention 2 feintunen. ⭐ **Unsloth unterstützt jedes `transformers` kompatible TTS-Modell.** Selbst wenn wir noch kein Notebook oder keinen Upload dafür haben, wird es dennoch unterstützt, z. B. können Sie versuchen, Dia-TTS oder Moshi zu feintunen. {% hint style="info" %} Zero-Shot-Klonen erfasst den Tonfall, verfehlt aber Rhythmus und Ausdruck und klingt oft robotisch und unnatürlich. Feintuning liefert eine weitaus genauere und realistischere Stimmreplikation. [Lesen Sie hier mehr](#fine-tuning-voice-models-vs.-zero-shot-voice-cloning). {% endhint %} ### Feintuning-Notebooks: Wir haben auch TTS-Modelle (Original und quantisiert) auf unsere [Hugging Face-Seite](https://huggingface.co/collections/unsloth/text-to-speech-tts-models-68007ab12522e96be1e02155). | [Sesame-CSM (1B)](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Sesame_CSM_\(1B\)-TTS.ipynb) | [Orpheus-TTS (3B)](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Orpheus_\(3B\)-TTS.ipynb) | [Whisper Large V3](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Whisper.ipynb) (STT) | | ------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | [Spark-TTS (0.5B)](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Spark_TTS_\(0_5B\).ipynb) | [Llasa-TTS (1B)](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Llasa_TTS_\(1B\).ipynb) | [Oute-TTS (1B)](https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Oute_TTS_\(1B\).ipynb) | {% hint style="success" %} Wenn Sie bemerken, dass die Ausgabelänge ein Maximum von 10 Sekunden erreicht, erhöhen Sie`max_new_tokens = 125` von seinem Standardwert von 125. Da 125 Tokens 10 Sekunden Audio entsprechen, müssen Sie für längere Ausgaben einen höheren Wert festlegen. {% endhint %} ### Ein TTS-Modell auswählen und laden Für TTS werden kleinere Modelle oft bevorzugt, da sie eine geringere Latenz und eine schnellere Inferenz für Endnutzer bieten. Das Feintuning eines Modells mit weniger als 3B Parametern ist oft ideal, und unsere Hauptbeispiele verwenden Sesame-CSM (1B) und Orpheus-TTS (3B), ein auf Llama basierendes Sprachmodell. #### Sesame-CSM (1B) Details **CSM-1B** ist ein Basismodell, während **Orpheus-ft** auf 8 professionelle Sprecherinnen und Sprecher feinabgestimmt ist, wodurch die Stimmkonsistenz der entscheidende Unterschied ist. CSM benötigt Audio-Kontext für jede Sprecherstimme, um gut zu funktionieren, während Orpheus-ft diese Konsistenz bereits eingebaut hat. Das Feintuning von einem Basismodell wie CSM aus benötigt im Allgemeinen mehr Rechenleistung, während der Start von einem feinabgestimmten Modell wie Orpheus-ft sofort bessere Ergebnisse liefert. Um bei CSM zu helfen, haben wir neue Sampling-Optionen und ein Beispiel hinzugefügt, das zeigt, wie Audio-Kontext für eine verbesserte Stimmkonsistenz verwendet wird. #### Orpheus-TTS (3B) Details Orpheus wird auf einem großen Sprachkorpus vortrainiert und zeichnet sich durch die Erzeugung realistischer Sprache mit integrierter Unterstützung für emotionale Signale wie Lachen und Seufzen aus. Seine Architektur macht es zu einem der am einfachsten zu nutzenden und zu trainierenden TTS-Modelle, da es über llama.cpp exportiert werden kann, was bedeutet, dass es eine hervorragende Kompatibilität über alle Inferenz-Engines hinweg hat. Für nicht unterstützte Modelle können Sie nur die LoRA-Adapter-Safetensors speichern. #### Die Modelle laden Da Sprachmodelle normalerweise klein sind, können Sie die Modelle mit LoRA 16-Bit oder vollständigem Fine-Tuning FFT trainieren, was qualitativ hochwertigere Ergebnisse liefern kann. Um sie in LoRA 16-Bit zu laden: ```python from unsloth import FastModel model_name = "unsloth/orpheus-3b-0.1-pretrained" model, tokenizer = FastModel.from_pretrained( model_name, load_in_4bit=False # 4-Bit-Präzision verwenden (QLoRA) ) ``` Wenn dies ausgeführt wird, lädt Unsloth die Modellgewichte herunter. Wenn Sie 8-Bit bevorzugen, können Sie `load_in_8bit = True`verwenden, oder für vollständiges Feintuning setzen Sie `full_finetuning = True` (stellen Sie sicher, dass Sie genug VRAM haben). Sie können den Modellnamen auch durch andere TTS-Modelle ersetzen. {% hint style="info" %} **Hinweis:** Der Tokenizer von Orpheus enthält bereits spezielle Tokens für die Audioausgabe (mehr dazu später). Sie *nicht* benötigen keinen separaten Vocoder – Orpheus gibt direkt Audio-Tokens aus, die in eine Wellenform decodiert werden können. {% endhint %} ### Ihren Datensatz vorbereiten Mindestens besteht ein TTS-Feintuning-Datensatz aus **Audioclips und ihren entsprechenden Transkripten** (Text). Verwenden wir den [*Elise* Datensatz](https://huggingface.co/datasets/MrDragonFox/Elise) der ein englischer Sprachkorpus mit einem Sprecher von etwa 3 Stunden ist. Es gibt zwei Varianten: * [`MrDragonFox/Elise`](https://huggingface.co/datasets/MrDragonFox/Elise) – eine erweiterte Version mit **Emotions-Tags** (z. B. \, \) in die Transkripte eingebettet. Diese Tags in spitzen Klammern kennzeichnen Ausdrucksformen (Lachen, Seufzen usw.) und werden vom Tokenizer von Orpheus als spezielle Tokens behandelt * [`Jinsaryko/Elise`](https://huggingface.co/datasets/Jinsaryko/Elise) – Basisversion mit Transkripten ohne spezielle Tags. Der Datensatz ist mit einem Audio- und Transkript-Eintrag pro Beispiel organisiert. Auf Hugging Face haben diese Datensätze Felder wie `Audio` (die Wellenform), `text` (die Transkription) und einige Metadaten (Sprechername, Tonhöhenstatistiken usw.). Wir müssen Unsloth einen Datensatz aus Audio-Text-Paaren zuführen. {% hint style="success" %} Anstatt sich ausschließlich auf Tonfall, Rhythmus und Tonhöhe zu konzentrieren, sollte die Priorität darauf liegen, sicherzustellen, dass Ihr Datensatz vollständig annotiert und korrekt normalisiert ist. {% endhint %} {% hint style="info" %} Bei einigen Modellen wie **Sesame-CSM-1B**kann es vorkommen, dass Sie eine Stimmvariation über mehrere Generierungen hinweg mit Sprecher-ID 0 bemerken, weil es ein **Basismodell**ist – es hat keine festen Stimmidentitäten. Sprecher-ID-Tokens helfen hauptsächlich dabei, **die Konsistenz innerhalb eines Gesprächs**zu bewahren, nicht über separate Generierungen hinweg. Um eine konsistente Stimme zu erhalten, stellen Sie **kontextbezogene Beispiele**bereit, z. B. einige Referenz-Audioclips oder frühere Äußerungen. Das hilft dem Modell, die gewünschte Stimme zuverlässiger zu imitieren. Ohne dies sind Variationen zu erwarten, selbst bei derselben Sprecher-ID. {% endhint %} **Option 1: Verwendung der Hugging-Face-Datasets-Bibliothek** – Wir können den Elise-Datensatz mit Hugging Faces `datasets` Bibliothek laden: ```python from datasets import load_dataset, Audio # Den Elise-Datensatz laden (z. B. die Version mit Emotion-Tags) dataset = load_dataset("MrDragonFox/Elise", split="train") print(len(dataset), "samples") # ~1200 Samples in Elise # Sicherstellen, dass das gesamte Audio mit einer Abtastrate von 24 kHz vorliegt (Orpheus' erwartete Rate) dataset = dataset.cast_column("audio", Audio(sampling_rate=24000)) ``` Dadurch wird der Datensatz heruntergeladen (\~328 MB für \~1,2k Samples). Jedes Element in `Datensatz` ist ein Dictionary mit mindestens: * `"audio"`: der Audioclip (Wellenform-Array und Metadaten wie Abtastrate) und * `"text"`: die Transkriptzeichenfolge Orpheus unterstützt Tags wie ``, ``, ``, ``, ``, ``, ``, ``, usw. Zum Beispiel: `"Ich habe dich so sehr vermisst !"`. Diese Tags sind in spitze Klammern eingeschlossen und werden vom Modell als spezielle Tokens behandelt (sie entsprechen [Orpheus' erwarteten Tags](https://github.com/canopyai/Orpheus-TTS) wie `` und ``. Während des Trainings lernt das Modell, diese Tags mit den entsprechenden Audiomustern zu verknüpfen. Der Elise-Datensatz mit Tags enthält bereits viele davon (z. B. 336 Vorkommen von „laughs“, 156 von „sighs“ usw., wie in seiner Karte angegeben). Wenn Ihrem Datensatz solche Tags fehlen, Sie sie aber einbeziehen möchten, können Sie die Transkripte manuell dort annotieren, wo das Audio diese Ausdrucksformen enthält. **Option 2: Einen benutzerdefinierten Datensatz vorbereiten** – Wenn Sie Ihre eigenen Audiodateien und Transkripte haben: * Organisieren Sie Audioclips (WAV/FLAC-Dateien) in einem Ordner. * Erstellen Sie eine CSV- oder TSV-Datei mit Spalten für Dateipfad und Transkript. Zum Beispiel: ``` filename,text 0001.wav,Hallo! 0002.wav, Ich bin sehr müde. ``` * Verwenden Sie `load_dataset("csv", data_files="mydata.csv", split="train")` um es zu laden. Möglicherweise müssen Sie dem Dataset-Loader mitteilen, wie mit Audio-Pfaden umzugehen ist. Eine Alternative ist die Verwendung des `datasets.Audio` Merkmals, um Audiodaten on the fly zu laden: ```python from datasets import Audio dataset = load_dataset("csv", data_files="mydata.csv", split="train") dataset = dataset.cast_column("filename", Audio(sampling_rate=24000)) ``` Dann `dataset[i]["audio"]` wird das Audio-Array enthalten. * **Stellen Sie sicher, dass Transkripte normalisiert sind** (keine ungewöhnlichen Zeichen, die der Tokenizer möglicherweise nicht kennt, außer den Emotions-Tags, falls verwendet). Stellen Sie außerdem sicher, dass alle Audiodateien eine konsistente Abtastrate haben (resamplen Sie sie bei Bedarf auf die Zielrate, die das Modell erwartet, z. B. 24 kHz für Orpheus). Zusammenfassend gilt für **die Datensatzvorbereitung**: * Sie brauchen eine **Liste von (Audio, Text)** Paaren. * Verwenden Sie die HF `datasets` Bibliothek, um das Laden und optionales Vorverarbeiten (wie Resampling) zu handhaben. * Schließen Sie alle **speziellen Tags** in den Text ein, die das Modell lernen soll (stellen Sie sicher, dass sie im `` -Format vorliegen, damit das Modell sie als separate Tokens behandelt). * (Optional) Bei mehreren Sprechern könnten Sie ein Sprecher-ID-Token in den Text einfügen oder einen separaten Sprecher-Embedding-Ansatz verwenden, aber das geht über diese grundlegende Anleitung hinaus (Elise ist Single-Speaker). ### TTS mit Unsloth feintunen Jetzt lassen Sie uns mit dem Feintuning beginnen! Wir werden dies anhand von Python-Code veranschaulichen (den Sie in einem Jupyter-Notebook, Colab usw. ausführen können). **Schritt 1: Modell und Datensatz laden** In all unseren TTS-Notebooks aktivieren wir das LoRA-Training (16-Bit) und deaktivieren das QLoRA-Training (4-Bit) mit: `load_in_4bit = False`. So kann das Modell Ihren Datensatz in der Regel besser lernen und eine höhere Genauigkeit erzielen. ```python from unsloth import FastLanguageModel import torch dtype = None # None für automatische Erkennung. Float16 für Tesla T4, V100, Bfloat16 für Ampere+ load_in_4bit = False # 4-Bit-Quantisierung verwenden, um den Speicherverbrauch zu reduzieren. Kann False sein. model, tokenizer = FastLanguageModel.from_pretrained( model_name = "unsloth/orpheus-3b-0.1-ft", max_seq_length= 2048, # Wählen Sie beliebig für langen Kontext! dtype = dtype, load_in_4bit = load_in_4bit, #token = "hf_...", # verwenden Sie einen, wenn Sie gesperrte Modelle wie meta-llama/Llama-2-7b-hf verwenden ) from datasets import load_dataset dataset = load_dataset("MrDragonFox/Elise", split = "train") ``` {% hint style="info" %} Wenn der Speicher sehr begrenzt ist oder der Datensatz groß ist, können Sie ihn streamen oder in Blöcken laden. Hier passt 3 Stunden Audio problemlos in den RAM. Wenn Sie Ihren eigenen Datensatz-CSV verwenden, laden Sie ihn auf dieselbe Weise. {% endhint %} **Schritt 2: Fortgeschritten – die Daten für das Training vorverarbeiten (Optional)** Wir müssen Eingaben für den Trainer vorbereiten. Für Text-to-Speech besteht ein Ansatz darin, das Modell kausal zu trainieren: Text und Audio-Token-IDs werden als Zielsequenz verkettet. Da Orpheus jedoch ein nur-dekodierendes LLM ist, das Audio ausgibt, können wir den Text als Eingabe (Kontext) einspeisen und die Audio-Token-IDs als Labels verwenden. In der Praxis könnte die Integration von Unsloth dies automatisch tun, wenn die Modellkonfiguration es als Text-to-Speech identifiziert. Falls nicht, können wir so etwas tun: ```python # Die Text-Transkripte tokenisieren def preprocess_function(example): # Den Text tokenisieren (die speziellen Tokens wie intakt lassen) tokens = tokenizer(example["text"], return_tensors="pt") # In Liste von Token-IDs abflachen input_ids = tokens["input_ids"].squeeze(0) # Das Modell wird nach diesen Text-Tokens Audio-Tokens generieren. # Für das Training können wir Labels gleich input_ids setzen (damit lernt es, das nächste Token vorherzusagen). # Aber das deckt nur Text-Tokens ab, die das nächste Text-Token vorhersagen (was ein Audio-Token oder das Ende sein könnte). # Ein ausgefeilterer Ansatz: ein spezielles Token anhängen, das den Beginn von Audio anzeigt, und das Modell den Rest generieren lassen. # Zur Vereinfachung dieselbe Eingabe als Labels verwenden (das Modell lernt, die Sequenz aus sich selbst heraus auszugeben). return {"input_ids": input_ids, "labels": input_ids} train_data = dataset.map(preprocess_function, remove_columns=dataset.column_names) ``` {% hint style="info" %} Das Obige ist eine Vereinfachung. In Wirklichkeit müssten Sie, um Orpheus richtig zu feintunen, die *Audio-Tokens als Teil der Trainingslabels*haben. Das Vortraining von Orpheus umfasste wahrscheinlich die Umwandlung von Audio in diskrete Tokens (über einen Audio-Codec) und das Training des Modells, diese auf Basis des vorhergehenden Textes vorherzusagen. Für das Feintuning auf neue Sprachdaten müssten Sie entsprechend die Audio-Tokens für jeden Clip ermitteln (unter Verwendung des Audio-Codecs von Orpheus). Das Orpheus-GitHub stellt ein Skript für die Datenverarbeitung bereit – es kodiert Audio in Sequenzen von `` Tokens. {% endhint %} Allerdings **könnte Unsloth dies abstrahieren**: Wenn das Modell ein FastModel mit einem zugehörigen Prozessor ist, der weiß, wie Audio behandelt werden muss, könnte es das Audio im Datensatz automatisch in Tokens kodieren. Falls nicht, müssten Sie jeden Audioclip manuell in Token-IDs kodieren (unter Verwendung des Codebooks von Orpheus). Dies ist ein fortgeschrittener Schritt, der über diese Anleitung hinausgeht, aber beachten Sie, dass das bloße Verwenden von Text-Tokens dem Modell nicht das eigentliche Audio beibringt – es muss die Audiomuster abgleichen. Nehmen wir an, Unsloth bietet eine Möglichkeit, Audio direkt einzuspeisen (zum Beispiel durch Setzen von `processor` und Übergabe des Audio-Arrays). Wenn Unsloth die automatische Audio-Tokenisierung noch nicht unterstützt, müssen Sie möglicherweise das `encode_audio` -Funktion des Orpheus-Repository verwenden, um Token-Sequenzen für das Audio zu erhalten, und diese dann als Labels verwenden. (Die Datensatzeinträge enthalten tatsächlich `Phoneme` und einige akustische Merkmale, was auf eine Pipeline hindeutet.) **Schritt 3: Trainingsargumente und Trainer einrichten** ```python from transformers import TrainingArguments,Trainer,DataCollatorForSeq2Seq from unsloth import is_bfloat16_supported trainer = Trainer( model = model, train_dataset = dataset, args = TrainingArguments( per_device_train_batch_size = 1, gradient_accumulation_steps = 4, warmup_steps = 5, # num_train_epochs = 1, # Dies für einen vollständigen Trainingslauf setzen. max_steps = 60, learning_rate = 2e-4, fp16 = not is_bfloat16_supported(), bf16 = is_bfloat16_supported(), logging_steps = 1, optim = "adamw_8bit", weight_decay = 0.01, lr_scheduler_type = "linear", seed = 3407, output_dir = "outputs", report_to = "none", # Verwenden Sie dies für WandB usw. ), ) ``` Wir machen 60 Schritte, um die Dinge zu beschleunigen, aber Sie können `num_train_epochs=1` für einen vollständigen Lauf setzen und `max_steps=None`deaktivieren. Die Verwendung von per\_device\_train\_batch\_size > 1 kann bei einer Multi-GPU-Einrichtung zu Fehlern führen; um Probleme zu vermeiden, stellen Sie sicher, dass CUDA\_VISIBLE\_DEVICES auf eine einzelne GPU gesetzt ist (z. B. CUDA\_VISIBLE\_DEVICES=0). Passen Sie es nach Bedarf an. **Schritt 4: Feintuning starten** Dadurch wird die Trainingsschleife gestartet. Sie sollten Protokolle zum Loss alle 50 Schritte sehen (wie festgelegt mit `logging_steps`). Das Training kann je nach GPU einige Zeit dauern – beispielsweise kann auf einer Colab-T4-GPU ein paar Epochen auf 3 Stunden Daten 1–2 Stunden dauern. Die Optimierungen von Unsloth machen es schneller als das standardmäßige HF-Training. **Schritt 5: Das feinabgestimmte Modell speichern** Nach Abschluss des Trainings (oder wenn Sie es mittendrin stoppen, wenn Sie es für ausreichend halten) speichern Sie das Modell. Dies speichert NUR die LoRA-Adapter und nicht das vollständige Modell. Um in 16 Bit oder GGUF zu speichern, scrollen Sie nach unten! ```python model.save_pretrained("lora_model") # Lokal speichern tokenizer.save_pretrained("lora_model") # model.push_to_hub("your_name/lora_model", token = "...") # Online speichern # tokenizer.push_to_hub("your_name/lora_model", token = "...") # Online speichern ``` Dies speichert die Modellgewichte (bei LoRA werden möglicherweise nur die Adaptergewichte gespeichert, wenn das Basismodell nicht vollständig feinabgestimmt ist). Wenn Sie `--push_model` in der CLI oder `trainer.push_to_hub()`verwendet haben, könnten Sie es direkt auf den Hugging Face Hub hochladen. Jetzt sollten Sie ein feinabgestimmtes TTS-Modell im Verzeichnis haben. Der nächste Schritt ist, es zu testen, und wenn unterstützt, können Sie llama.cpp verwenden, um es in eine GGUF-Datei zu konvertieren. ### Feintuning von Sprachmodellen vs. Zero-Shot Voice Cloning Man sagt, man könne mit nur 30 Sekunden Audio eine Stimme klonen, indem man Modelle wie XTTS verwendet – ohne Training. Das ist technisch korrekt, verfehlt aber den Punkt. Zero-Shot Voice Cloning, das auch in Modellen wie Orpheus und CSM verfügbar ist, ist eine Annäherung. Es erfasst den allgemeinen **Ton und die Klangfarbe** der Stimme einer sprechenden Person, gibt aber nicht den vollen Ausdrucksbereich wieder. Details wie Sprechgeschwindigkeit, Formulierungen, vokale Eigenheiten und die Feinheiten der Prosodie gehen verloren – Dinge, die einer Stimme ihre **Persönlichkeit und Einzigartigkeit**. verleihen. Wenn Sie nur eine andere Stimme wollen und mit denselben Darbietungsmustern einverstanden sind, ist Zero-Shot normalerweise gut genug. Die Sprache folgt jedoch weiterhin dem **Stil des Modells**, nicht dem des Sprechers. Für alles, was persönlicher oder ausdrucksstärker sein soll, benötigen Sie Training mit Methoden wie LoRA, um wirklich zu erfassen, wie jemand spricht. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://unsloth.ai/docs/de/grundlagen/text-to-speech-tts-fine-tuning.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.