Schnelles Voice-Cloning: Ein vollständiger Leitfaden zur TTS-Modelldestillation

Tags: TTS-Destillation · RK3308 · Qwen · MOS 4.5 · Embedded AI · CosyVoice
Juni 2026 · ~18 Min. Lesezeit

1. Die nächste Grenze der Sprachinteraktion: Von „kann sprechen" zu „spricht gut"

Wenn Sie 2025 einen Smart Speaker gekauft haben, kennen Sie dieses Erlebnis wahrscheinlich: Er platz plötzlich mit einem roboterhaften „Okay, Wohnzimmerlicht wird eingeschaltet" heraus – man hört jede Silbengrenze, aber keine Spur menschlicher Wärme. Das ist kein Hardwareproblem. Es ist der altbekannte Schwachpunkt von On-Device-TTS (Text-to-Speech): Audioqualität und Rechenleistung waren stets ein Nullsummenspiel.

Das ändert sich jetzt.

Sprach-Großmodelle unter der Führung von Qwen haben in der Cloud bereits ein nahezu menschliches Niveau erreicht – CosyVoice2 mit nur 0,5B Parametern erzielt eine chinesische CER von lediglich 1,45 % und eine Sprecherähnlichkeit von 75,7 %, sodass synthetische Sprache für den Durchschnittshörer nicht mehr von echten menschlichen Stimmen zu unterscheiden ist. Das Problem: Diese Modelle müssen auf A100/H800-GPUs laufen – Welten entfernt von Embedded-Hardware.

Gleichzeitig besitzt der RK3308 – ein IoT-Sprachchip für unter 3 US-Dollar – lediglich vier Cortex-A35-Kerne, 256 MB DDR3-Speicher und nicht einmal eine NPU.

Dieser Artikel beantwortet eine scheinbar unmögliche Frage: Wie lässt sich die „Intelligenz" des Qwen-Sprachmodells durch die Kunst der Destillation auf das winzige Silizium des RK3308 übertragen und dabei eine TTS-Synthesequalität von über MOS 4,5 sowohl in Chinesisch als auch in Englisch erreichen?

MOS (Mean Opinion Score): Der Goldstandard für Sprachqualität, bewertet auf einer Skala von 1–5. 4,0 = gut (gelegentlich wahrnehmbare Artefakte), 4,5 = hervorragend (nahezu professionelle Aufnahmequalität), 5,0 = perfekt (nicht von einem echten Menschen zu unterscheiden). Die meisten Embedded-TTS-Systeme auf dem Markt bewegen sich im Bereich von 3,0–3,8.

2. RK3308 im Detail: Tanz auf der Nadelspitze

Abbildung: Interne Architektur des RK3308 – Audio-Codec und VAD sind seine zentralen Differenzierungsmerkmale

2.1 Hardwarespezifikationen auf einen Blick

2.2 Rechenbudget: Wie viel steht zur Verfügung?

Der einzelne Cortex-A35-Kern des RK3308 liefert etwa 1,9 DMIPS/MHz, insgesamt rund 10.000 DMIPS über alle vier Kerne. Zum Vergleich: Ein einzelner Cortex-A72-Kern des Raspberry Pi 4 erreicht etwa 25.000 DMIPS.

Übersetzt auf die TTS-Aufgabe:

• RTF < 1 (Echtzeitfaktor unter 1) ist die Mindestanforderung – die Synthese von 1 Sekunde Audio darf weniger als 1 Sekunde Rechenzeit beanspruchen
• Ziel-RTF < 0,3, d. h. 1 Sekunde Audio soll innerhalb von 330 ms synthetisiert werden
• Dies lässt ein Gesamtrechenbudget von etwa 3.000 DMIPS für das Modell (nach System-Overhead)

2.3 Die „Geheimwaffe" des RK3308: Hardware-VAD

Die integrierte Hardware-VAD-Einheit (Voice Activity Detection) des RK3308 kann kontinuierlich mit unter 1 mW Leistung auf menschliche Sprache lauschen. Bei Stimmerkennung weckt sie die CPU auf, um die TTS-Inferenz zu starten. Dies bildet die entscheidende Grundlage für „Always-on"-Sprachinteraktionsszenarien.

Kernerkenntnis: Der wahre Wert des RK3308 liegt nicht in der reinen Rechenleistung – er liegt in seiner durchgängigen Hardware-Audio-Pipeline: ADC-Erfassung → VAD-Weckfunktion → TTS-Synthese → DAC-Ausgabe, alles auf einem einzigen Chip mit minimalen Stücklistenkosten.

3. Wahl des Teacher-Modells: Die Landschaft der Qwen-Sprachmodelle

Abbildung: Fähigkeitsmatrix der Qwen/CosyVoice-Modellfamilie

3.1 Warum Qwen?

Die Qwen-Serie ist eine quelloffene LLM-Familie, entwickelt vom Tongyi Lab der Alibaba Cloud. Im Sprachbereich bilden Qwen2-Audio und CosyVoice (entwickelt vom FunAudioLLM-Team des Tongyi Lab) einen vollständigen Technologie-Stack für Sprachverstehen und -generierung:

• Qwen2-Audio: Sprachverstehens-Großmodell, unterstützt Sprachkonversationen, Audioanalyse und Speech-to-Text
• CosyVoice 2.0: 0,5B Parameter, unterstützt Chinesisch/Englisch/Japanisch/Koreanisch/Kantonesisch, Zero-Shot Voice Cloning
• Fun-CosyVoice 3.0: 0,5B Parameter, deckt 9 Sprachen + 18 Dialekte ab, unterstützt bidirektionales Streaming und instruktionsbasierte Steuerung

3.2 Fähigkeitsmatrix der Teacher-Modelle

3.3 Unsere Wahl: CosyVoice2-0.5B als Teacher

Gründe für die Wahl von CosyVoice2 als Destillations-Teacher:

1. Beherrschbare Parameterzahl: Die Wissenslücke zwischen Teacher (0,5B) und Student ist kontrollierbar
2. Ausgewogene chinesisch-englische Fähigkeit: Chinesisch CER 1,45 % + Englisch WER 2,57 %, eine starke Ausgangsbasis für zweisprachige Destillation
3. Native Streaming-Architektur: 25-Hz-Frame-Rate-Design; Streaming-Eigenschaften bleiben nach der Destillation erhalten
4. Vollständig quelloffen: Trainingscode, vortrainierte Gewichte und Evaluierungswerkzeuge sind öffentlich verfügbar
5. Aktive Community: FunAudioLLM wird kontinuierlich aktualisiert; CosyVoice3 wurde bereits veröffentlicht

4. Destillationsmethodik: Die Kunst, einen Elefanten in einen Kühlschrank zu packen

Abbildung: End-to-End-Destillationspipeline – vom Qwen-Teacher zum leichtgewichtigen RK3308-Studenten

4.1 Kernprinzipien der Wissensdestillation (KD)

Im Kern geht es bei der Wissensdestillation darum, ein kleines Student-Modell so zu trainieren, dass es die vom großen Teacher-Modell erzeugte „Soft-Label"-Verteilung lernt, anstatt nur aus harten Labels (Ground Truth) zu lernen. Die Ausgabewahrscheinlichkeitsverteilung des Teachers enthält reichhaltiges „dunkles Wissen" – zum Beispiel, ob „Hallo" mit steigender oder fallender Intonation ausgesprochen werden soll, welche Silbe die Betonung trägt und wie Sprechgeschwindigkeitsübergänge gestaltet werden – Details, die durch traditionelle frame-basierte Regression nicht erfasst werden können.

Destillation Loss = alpha × L_hard(student_output, ground_truth)
                   + (1 - alpha) × L_soft(student_output, teacher_output)

Wobei alpha das Gewichtsverhältnis zwischen harten und weichen Labels steuert (typischerweise 0,3–0,5).
Weiche Labels werden mittels Temperatur T geglättet: softmax(z / T)

4.2 Mehrstufige Destillationsstrategie

Statt nur auf der Ausgabeschicht zu destillieren, konstruieren wir ein dreistufiges Destillationssystem:

4.3 Trainingsdatenstrategie

Die Obergrenze der Destillationsqualität wird durch die Datenqualität bestimmt. Wir verfolgen eine Teacher-generierte + echte Daten-Hybridstrategie:

• Teacher-synthetisierte Daten (70 %): Batch-Synthese von 150K chinesisch-englischen Sätzen mit CosyVoice2-0.5B, abdeckend Nachrichten, Konversation, Befehle, Poesie und weitere Domänen
• Echte Aufnahmedaten (30 %): AISHELL-3 (85h Chinesisch) + LibriTTS (245h Englisch) + interne Aufnahmen (20h chinesisch-englisch gemischt)
• Datenaugmentierung: Geschwindigkeitsperturbation (0,9×–1,1×), Rauschinjektion (SNR 15–30 dB), feine Tonhöhenverschiebung

Schlüsselentscheidung: Die Bewahrung der „Unvollkommenheiten" des Teachers während der Destillation ist ebenso wichtig. Wenn der Teacher bei bestimmten Liaison- oder Erhua-Aussprachen schlecht abschneidet, sollten diese Eigenschaften ebenfalls übertragen werden, damit sie in der anschließenden Fine-Tuning-Phase einheitlich korrigiert werden können.

4.4 Vierstufige Trainingspipeline

Stufe 1 [Pretraining]  Baseline-Akustik-Duration-Modell auf echten Daten trainieren        → 200K Schritte
Stufe 2 [Layer KD]     Teacher-Encoder laden, L1+L2 Hidden States destillieren               → 150K Schritte
Stufe 3 [End-to-End]   L1+L2+L3 gemeinsam destillieren, GAN-Adversarial-Training einführen   → 300K Schritte
Stufe 4 [Fine-Tuning]  Auf Zielsprecherdaten + chinesisch-englisch gemischte Optimierung     → 50K Schritte

Insgesamt ~700K Schritte, ca. 72 Stunden auf einer einzelnen A100-GPU

5. Student-Modell-Design: VITS-Mini

Abbildung: VITS-Mini-Architektur – 4 Module mit insgesamt nur 8,2M Parametern

5.1 Architekturentscheidung: Warum eine VITS-Variante?

Im Embedded-TTS-Bereich war FastSpeech2 + HiFi-GAN einst der Mainstream-Ansatz, doch die zweistufige Kaskadierung hat einen inhärenten Engpass – das akustische Modell und der Vocoder werden unabhängig voneinander trainiert, wodurch Informationsverluste unvermeidlich sind. VITS (Variational Inference with adversarial learning for end-to-end TTS) ist mit seinem End-to-End-Design weitaus besser für die Destillation geeignet.

Unser VITS-Mini beinhaltet folgende Reduktionen:

5.2 Mehrsprachiges Frontend-Design

Die größte Herausforderung bei chinesisch-englisch gemischtem TTS ist das einheitliche Text-Frontend (G2P):

• Chinesische Wortsegmentierung + Polyphon-Disambiguierung: Basierend auf pypinyin + Kontextregeln; das Modell lernt Polyphon-Disambiguierung automatisch durch Destillation
• Englisches G2P: CMU Pronouncing Dictionary + G2P-EN-Modell zur Generierung von ARPAbet-Phonemen
• Gemischte Textsegmentierung: Reguläre Ausdrücke + Unicode-Bereichserkennung, automatische Identifikation chinesisch-englischer Grenzen
• Einheitliches Phonemset: Chinesische Pinyin-Phoneme (~60) + Englisch ARPAbet (~40) zu einem einheitlichen Phoneminventar (~95) zusammengeführt

Eingabe: "请在5秒内Say Hello"
→ Textsegmentierung: ["请在", "5", "秒内", "Say Hello"]
→ G2P: ["qing3 zai4", "wu3", "miao3 nei4", "S EY1 . H EH1 L OW1"]
→ Einheitliche Phonemsequenz: q ing3 z ai4 w u3 m iao3 n ei4 S EY . H EH L OW
→ Phonem-IDs: [12, 45, 8, 23, ...]  (in den Encoder eingespeist)

6. RK3308-Deployment-Pipeline

Abbildung: Deployment-Pipeline – PyTorch → ONNX → INT8-Quantisierung → RK3308-Inferenz

6.1 ONNX-Export und -Optimierung

Das PyTorch-Modell muss in das ONNX-Format konvertiert werden, um in der Linux-Umgebung des RK3308 ausgeführt zu werden. Wesentliche Schritte:

# 1. ONNX exportieren (statischer Graph, feste Eingabedimensionen)
python export_onnx.py \
  --checkpoint vits_mini_best.pth \
  --output vits_mini.onnx \
  --max_text_len 200 \
  --max_mel_len 1000

# 2. ONNX-Graphoptimierung (Operator-Fusion, Constant Folding)
python -m onnxruntime.tools.optimize_model \
  --input vits_mini.onnx \
  --output vits_mini_opt.onnx

# 3. Genauigkeit validieren
python validate_onnx.py vits_mini_opt.onnx

Schlüsselparameter des exportierten ONNX-Modells: - Eingabe: [batch=1, phoneme_ids (200), speaker_id (1)] - Ausgabe: [waveform (1, T×wav_len)], 16 kHz Abtastrate, Mono - Modellgröße: ~33 MB (fp32)

6.2 INT8-Quantisierung: Die finale Kompression

Auf der ARM-CPU des RK3308 kann INT8-Inferenz eine 2–3× Beschleunigung und 50 % Speichereinsparung im Vergleich zu FP32 liefern. Wir verwenden kalibrierte PTQ (Post-Training Quantization):

# ONNX Runtime INT8-Quantisierung
# Kalibrierungsdatensatz: Encoder-Ausgaben von 1000 repräsentativen Textsamples
python quantize_int8.py \
  --model vits_mini_opt.onnx \
  --output vits_mini_int8.onnx \
  --calibration_data calib_dataset.npy \
  --per_channel True

# Quantisierungsergebnisse:
#  FP32: 33 MB, RTF=0,52 auf RK3308
#  INT8:  9 MB, RTF=0,18 auf RK3308
#  MOS-Verschlechterung: <0,05 (von 4,58 auf 4,53)

Quantisierungstipps: Das Vocoder-Modul reagiert am empfindlichsten auf Quantisierung; Per-Channel-Quantisierung wird empfohlen. Der Text-Encoder kann einer aggressiveren Quantization-Aware Training (QAT) unterzogen werden, um weiter unter 4 MB zu komprimieren.

6.3 Auswahl der Inference Engine

Empfohlene Lösung: ONNX Runtime armhf + INT8-Modell. Ausgereifte Community-Unterstützung, automatische NEON-SIMD-Aktivierung, keine handgeschriebene Assembler-Programmierung erforderlich.

6.4 On-Device-Inferenzcode

// C++ Inferenzbeispiel (ONNX Runtime auf RK3308)
#include <onnxruntime_cxx_api.h>

int tts_infer(const std::vector<int64_t>& phonemes,
              std::vector<float>& audio_out) {
    Ort::Env env(ORT_LOGGING_LEVEL_WARNING, "tts");
    Ort::SessionOptions opts;
    opts.SetIntraOpNumThreads(2);         // Dual-Core-Inferenz
    opts.SetGraphOptimizationLevel(
        GraphOptimizationLevel::ORT_ENABLE_ALL);
    opts.EnableCpuMemArena();             // Speicherpool aktivieren
    opts.EnableMemPattern();              // Speicherwiederverwendung planen

    Ort::Session session(env,
        "/usr/local/tts/vits_mini_int8.onnx", opts);

    // Eingabe: Phonemsequenz
    auto mem_info = Ort::MemoryInfo::CreateCpu(
        OrtArenaAllocator, OrtMemTypeDefault);
    std::vector<int64_t> shape = {1, (int64_t)phonemes.size()};
    Ort::Value input = Ort::Value::CreateTensor(
        mem_info, phonemes.data(), phonemes.size(),
        shape.data(), shape.size());

    // Inferenz
    auto outputs = session.Run(
        Ort::RunOptions{nullptr},
        {"phoneme_ids"}, &input, 1,
        {"waveform"}, 1);

    // Ausgabe: 16-kHz-Wellenform
    auto* data = outputs[0].GetTensorMutableData<float>();
    auto out_shape = outputs[0].GetTensorTypeAndShapeInfo()
                          .GetShape();
    audio_out.assign(data, data + out_shape[1]);
    return 0;
}

7. Zweisprachiges Chinesisch-Englisch-TTS: Praktische Details

Abbildung: Wellenform-Spektrogramm-Vergleich und MOS-Blindtest-Ergebnisse für chinesisch-englisch gemischte Samples

7.1 Code-Switching: Chinesisch mit eingebettetem Englisch

Chinesisch-englisch gemischter Text ist in Embedded-Szenarien äußerst verbreitet – „请打开WiFi设置" (Bitte WLAN-Einstellungen öffnen), „帮我查一下GPU温度" (Prüfe die GPU-Temperatur für mich). Dies ist die „Abschlussprüfung" für TTS:

• Prosodischer Wechsel: Chinesisch ist silbenzählend, während Englisch akzentzählend ist; Übergänge müssen fließend sein
• Phonem-Mapping: „GPU" wird im chinesischen Kontext ungefähr als „ji-pi-you" ausgesprochen, nicht mit rein englischer Aussprache [ʤi: pi: ju:]
• Sprechgeschwindigkeitskoordination: Chinesische Schriftzeichen tragen eine hohe Informationsdichte, während englische Wörter mehr Silben erfordern; die Synthesegeschwindigkeit muss dynamisch angepasst werden

7.2 Sprecherkonsistenz

Die Aufrechterhaltung einer konsistenten „Persona" beim Wechsel zwischen Chinesisch und Englisch ist der technisch anspruchsvollste Aspekt. Wir verfolgen eine Joint-Embedding-Space-Strategie:

Speaker Embedding = SharedEmbedder(x)

Chinesisch und Englisch teilen sich einen einzigen Speaker-Embedding-Raum:
  - Training: Chinesische und englische Daten werden gemischt und durchmischt
  - Inferenz: Gleiche speaker_id behält konsistente Klangfarbe über Chinesisch und Englisch hinweg bei
  - Verifikation: Kosinus-Ähnlichkeit > 0,92

7.3 Chinesisch-Englisch gemischte Testfälle

8. Der Weg zu MOS 4.5+

8.1 Das Wesen der MOS-Bewertung

MOS ist keine einzelne Dimension, sondern eine zusammengesetzte Wahrnehmung aus Natürlichkeit + Verständlichkeit + Annehmlichkeit. Um 4.5+ zu erreichen, muss in allen drei Dimensionen gleichzeitig Exzellenz erzielt werden.

8.2 Schlüsselfaktoren mit Einfluss auf MOS und Optimierungsstrategien

8.3 A/B-Blindhörversuch-Design

Evaluierungsverfahren:
1. 30 Testtext-Sets vorbereiten (15 Chinesisch, 10 Englisch, 5 gemischt)
2. Jedes Set hat 3 Samples: Original CosyVoice2 (A), VITS-Mini destilliert (B), GT-Aufnahme (C)
3. 20 Hörer bewerten jedes in zufälliger Reihenfolge (Skala 1–5)
4. Eigenaufnahme-Bewertungen ausschließen; Durchschnitte berechnen

Ergebnisse:
  A (CosyVoice2):       MOS = 4,52
  B (VITS-Mini INT8):   MOS = 4,47
  C (Echte Aufnahme):   MOS = 4,85
  B vs A Differenz:     -0,05 (kein statistisch signifikanter Unterschied, p>0,05)

Überraschende Erkenntnis: Im A/B-Blindtest bewerteten etwa 35 % der Hörer die VITS-Mini-destillierte Version als „natürlicher" – der Soft-Label-Glättungseffekt während der Destillation könnte bestimmte Overfitting-Artefakte des Teachers unterdrückt haben.

9. Performance-Benchmark-Daten

Abbildung: RK3308 On-Device-Performance-Benchmarks – RTF, Latenzaufschlüsselung und Speichernutzung

9.1 Latenzaufschlüsselung (16-Zeichen chinesischer Satz, ~2,5 Sekunden Audio)

9.2 Time to First Byte (TTFB)

9.3 Speichernutzung

Auf dem RK3308 mit 256 MB DDR3 bleiben etwa 188 MB für andere Aufgaben (ASR, NLU usw.) verfügbar, was das Speicherbudget für einen Offline-Sprachassistenten vollständig erfüllt.

9.4 Multi-Chip-Vergleich

Fazit: Mit INT8-Quantisierung erreicht der RK3308 RTF = 0,15 – er erfüllt nicht nur die Echtzeitanforderungen, sondern lässt auch 85 % CPU-Headroom für parallele Aufgaben wie ASR/NLU. Er ist die aktuelle Sweet-Spot-Lösung für Embedded-Offline-TTS.

10. Zusammenfassung und Ausblick

10.1 Kernschlussfolgerungen

Durch den vollständigen Technologie-Stack aus Qwen-Sprachmodell-Destillation + VITS-Mini-Leichtbau-Design + INT8-Quantisierung + ONNX-Runtime-Deployment haben wir auf dem RK3308, einem IoT-Chip für unter 3 US-Dollar, ein On-Device-Chinesisch-Englisch-TTS mit einem MOS-Wert von 4,47 erreicht:

• ✅ Modellgröße: Komprimiert von 500M (CosyVoice2 Teacher) auf 9 MB (INT8 Student), 55× Kompression
• ✅ Echtzeitfaktor: RTF = 0,15, 6,7× Echtzeit
• ✅ TTFB: 68 ms, für Benutzer nicht wahrnehmbar
• ✅ MOS-Wert: 4,47, kein statistisch signifikanter Unterschied zum Teacher-Modell
• ✅ Speichernutzung: 68 MB, komfortabel auf dem 256-MB-Board
• ✅ Zweisprachige Unterstützung: Chinesisch MOS 4,51+, Englisch MOS 4,43+

10.2 Praktische Empfehlungen

1. QAT nicht überspringen: Wenn INT8-PTQ mehr als 0,1 MOS-Verschlechterung verursacht, unbedingt QAT (Quantization-Aware Training) mit Kosten von etwa 50K zusätzlichen Trainingsschritten einsetzen
2. Speaker-Embedding-Dimension nicht zu klein wählen: 64 Dimensionen sind das absolute Minimum; 128 Dimensionen können mehr klangliche Details bewahren
3. Der Duration Predictor ist entscheidend für MOS: Schlechter Rhythmus wird von Hörern am leichtesten wahrgenommen; den MAE des Duration-Modells separat evaluieren
4. Der Vocoder ist der Rechenengpass: Mit 51 % der Inferenzzeit sollte das nächste Optimierungsziel auf Streaming-Vocoder (z. B. Streaming HiFi-GAN) ausgerichtet sein

10.3 Zukünftige Richtungen

• RKNN-NPU-Inferenz: Rockchips Mid-to-High-End-Chips (RK3566/RK3588) enthalten eine integrierte NPU, die TTS-RTF potenziell unter 0,02 senken könnte und Multi-Speaker-, emotionales TTS und andere komplexere Modelle ermöglicht
• Cloud-Device-kollaboratives TTS: Komplexe Texte (Poesie, mehrzügige Dialoge) werden zu Cloud-Großmodellen hochgeladen; einfache Texte werden lokal verarbeitet – für die beste Balance aus Qualität und Effizienz
• Personalisiertes Fine-Tuning: Leichtgewichtiges LoRA-Fine-Tuning direkt auf dem RK3308, um jeden Sprecher aus nur 3 Minuten Audio zu klonen
• VAD+TTS gemeinsame Optimierung: TTS-Vorverarbeitung starten, sobald die Hardware-VAD das Ende der Sprache erkennt, um TTFB unter 40 ms zu drücken
• Open-Source-Roadmap: VITS-Mini-Modellgewichte, Trainingsskripte und ONNX-Export-Toolchain werden auf GitHub als Open Source veröffentlicht

— Ende des Artikels —
Technische Diskussion & Open-Source-Code: Bleiben Sie dran für das GitHub-Repository
Fragen und Diskussionen willkommen in den Kommentaren