Nvidia PersonaPlex 7B auf Apple Silicon: Echtzeitfähiges bidirektionales Sprachdialogmodell auf Swift-Basis

• Das auf Apple Silicon mit Swift/MLX implementierte Modell PersonaPlex 7B unterstützt bidirektionale Sprachdialoge in Echtzeit
• Es integriert die bisherige dreistufige Sprachpipeline ASR→LLM→TTS in ein einziges Modell und verarbeitet Audio-Eingabe und -Ausgabe direkt ohne Textumwandlung
• Durch 4-Bit-Quantisierung wurde die Modellgröße von 16,7 GB auf 5,3 GB reduziert; zugleich wurde mit 68 ms/Schritt (RTF 0,87) eine schnellere als Echtzeit-Verarbeitung erreicht
• Mithilfe des Mimi-Audio-Codecs und der Depformer-Struktur wird effizientes Streaming ohne Einbußen bei der Sprachqualität umgesetzt
• Es läuft nativ in Swift ohne Server und ist als Basistechnologie für die Entwicklung von Sprachassistenten und dialogorientierten Agenten relevant

---

Integration von qwen3-asr-swift und PersonaPlex 7B

• Die Bibliothek qwen3-asr-swift integriert NVIDIA PersonaPlex 7B auf Apple Silicon und unterstützt bidirektionalen Sprachdialog (full-duplex speech-to-speech)
  • Eingehendes Audio wird in Echtzeit verarbeitet, während gleichzeitig Antwort-Audio erzeugt wird
  • Die Bibliothek wurde zu einer integrierten Sprachverarbeitungslösung erweitert, die ASR, TTS und mehrsprachige Synthese umfasst
• Das Modell ist als 4-Bit-quantisierte 5,3-GB-Version auf Hugging Face unter aufklarer/PersonaPlex-7B-MLX-4bit verfügbar

Vereinheitlichung der bisherigen Sprachpipeline

• Traditionelle Sprachassistenten basieren auf einer dreistufigen Struktur aus ASR → LLM → TTS, bei der in jedem Schritt Latenz und Verlust von Emotionen entstehen
• PersonaPlex führt dies in einem einzigen Modell zusammen und verarbeitet Audio-Token direkt
  • Audio wird in 17 parallelen Streams (12,5 Hz) in Echtzeit transformiert
  • Auf Basis der Moshi-Architektur von Kyutai werden 18 Sprach-Presets und rollenbasierte System-Prompts unterstützt

Modellarchitektur und Konvertierung

• Der ursprüngliche 16,7-GB-PyTorch-Checkpoint wurde in MLX-optimierte safetensors konvertiert
  • Das Konvertierungsskript (convert_personaplex.py) automatisiert Gewichtsklassifizierung, 4-Bit-Quantisierung, Preset-Extraktion und den Upload zu Hugging Face
• Sowohl der Temporal Transformer (7B Parameter) als auch der Depformer wurden auf 4 Bit komprimiert
  • Der Depformer nutzt eine Struktur für schrittweisen Gewichtswechsel (MultiLinear) und wurde von 2,4 GB auf 650 MB verkleinert
  • Das ergibt eine 3,7-fache Reduktion der Größe ohne Qualitätsverlust

Sprachverarbeitungspipeline

• Über den Mimi Encoder/Decoder wird 24-kHz-Audio in 16 Codebook-Token umgewandelt
  • Der Temporal Transformer verarbeitet die Audio-Streams von Nutzer und Agent gemeinsam
  • Der Depformer erzeugt Agent-Audio-Token in 16 Schritten
  • Der Mimi Decoder rekonstruiert daraus wieder 24-kHz-Audio
• Komponenten bestehender TTS-Modelle wie Mimi-Codec, KV-Cache, RoPE, SwiGLU und RMSNorm werden unverändert wiederverwendet

System-Prompts und Dialogsteuerung

• PersonaPlex steuert den Gesprächsstil über textbasierte System-Prompts
  • Ohne Prompt weicht das Modell vom Thema ab oder antwortet weitschweifig
  • In CLI oder API lassen sich Presets wie assistant, customer service, teacher auswählen
  • Selbst bei derselben Frage unterscheidet sich die Antwortqualität je nach Vorhandensein eines Prompts deutlich

Leistung und Echtzeitverarbeitung

• In einer M2-Max-(64 GB)-Umgebung wurde mit 68 ms/Schritt, RTF 0,87 eine schnellere als Echtzeit-Verarbeitung erreicht
  • Das System arbeitet stabil innerhalb des 80-ms-Frame-Budgets (12,5 Hz)
• ASR, TTS und Speech-to-Speech können in einer einzigen Bibliothek integriert getestet werden
  • Für die E2E-Validierung wird das Antwort-Audio per ASR erneut in Text umgewandelt, um die thematische Konsistenz zu prüfen

Streaming und Optimierung

• Die API respondStream() erzeugt Audio-Chunks in 2-Sekunden-Intervallen in Echtzeit
  • Sie können als AsyncThrowingStream<AudioChunk> sofort wiedergegeben werden
• Vier zentrale Optimierungen:
  • Integration von eval() zur Reduzierung der GPU-Synchronisierung
  • Bulk audio extraction zur Verbesserung der Dekodierungseffizienz
  • Prefill batching für parallele Verarbeitung in der Initialphase
  • Kompilierung des Temporal Transformers zur Optimierung von mehr als 450 Metal-Kernel-Aufrufen
• Kernel-Fusion kann mit dem Flag --compile oder über model.warmUp() aktiviert werden

Ausführung und Bereitstellung

• GitHub-Repository: ivan-digital/qwen3-asr-swift
  • Nach dem Build mit swift build -c release lassen sich ASR, TTS und Speech-to-Speech per CLI-Befehl ausführen
  • Beim ersten Start ist ein Download des Modells von etwa 5,3 GB erforderlich
• Auf Basis des MLX-Frameworks läuft es vollständig nativ in Swift ohne Python oder Server

Technische Bedeutung

• Es zeigt die On-Device-Ausführung leistungsfähiger Sprachmodelle unter Nutzung der Unified-Memory-Architektur von Apple Silicon und Metal-Beschleunigung
• Mit der Umsetzung von Echtzeit-Sprachdialogen auf Basis eines Einzelmodells ergeben sich vielfältige Einsatzmöglichkeiten, etwa für KI-Assistenten, Callcenter und sprachbasierte Bildungsschnittstellen
• Es gilt als Ergebnis der Integration mehrerer Open-Source-Ökosysteme wie NVIDIA, Kyutai, Alibaba Qwen, FunAudioLLM und Apple MLX

[GN⁺]

Hacker-News-Kommentare

• Dieses Projekt hat mir wirklich gefallen. Ich hatte früher versucht, PersonaPlex auf einem Blackwell-Gerät zum Laufen zu bringen, bin aber gescheitert; diesmal werde ich es auf dem Mac ausprobieren.
  Aus meiner Erfahrung mit Sprachagenten gibt es ein paar Dinge zu beachten. Auch eine VAD→ASR→LLM→TTS-Pipeline fühlt sich in Echtzeit an, wenn die RTT unter 1 Sekunde liegt. Als Beispiele sind mein Projekt ova sowie voice-agent und parakeet.cpp einen Blick wert.
  Nach Gesprächen mit der PersonaPlex-Community scheint eine vollständig full-duplexe Struktur in Bezug auf Genauigkeit und Performance noch schwierig zu sein, und das Training ist ebenfalls anspruchsvoll. Dagegen ist eine ASR→LLM→TTS-Struktur modular und bietet die Flexibilität, kleine und große LLMs sowie lokale und API-basierte Endpunkte frei zu kombinieren.

  • Ich baue auch selbst Sprachagenten und würde mich deshalb unbedingt gern austauschen. Im Moment überlege ich, wie sich eine full-duplexe Pipeline in ein agentic framework integrieren lässt.
    Die bestehende STT→LLM→TTS-Struktur passt gut zu Tool-Calling, fortgeschrittenem Kontextmanagement, RAG usw. Es funktioniert gut, den Agenten für das direkte Gespräch mit Menschen von internen Sub-Agenten zu trennen, um Latenz und Kontextlast zu reduzieren.
    Eine full-duplexe Struktur wirkt dynamischer, aber ich habe noch kein gutes Gefühl dafür, wie man sie praktisch in einen Sprachagenten integriert. Ich würde mich gern auf Discord dazu austauschen.
  • Der Kern dieses Threads wirkt wie ein Gegensatz zwischen full-duplex und composable Pipelines, aber in der Praxis müssen beide Strukturen gleichzeitig laufen. Diese Bibliothek ist davon bereits etwa zur Hälfte dort.
    Da qwen3-asr-swift ASR, TTS und PersonaPlex in einem einzigen Swift-Paket bündelt, sind die nötigen Bausteine bereits vorhanden. PersonaPlex übernimmt latenzarme Backchanneling-Reaktionen und natürliches Turn-Taking, während ein separates LLM die Tool-Calls ausführt.
    Das Problem ist die Orchestrierung zwischen beiden. Wann soll das „Gehirn“ den „Mund“ übersteuern? Wie verhindert man, dass PersonaPlex ungeprüfte Antworten mit Sicherheit ausspricht? Und wie geht man damit um, wenn Tool-Ergebnisse mit einer bereits laufenden Äußerung kollidieren? Das sind noch ungelöste Fragen.
  • Ich stimme dieser Pipeline vollkommen zu. Mit einem kleinen Modell kann man sofortige Antworten erzeugen und gleichzeitig Tool-Calls oder die Weiterleitung an ein intelligenteres Modell ausführen. Eine Struktur, die schnelle asynchrone Antworten und Tool-Calling parallel verarbeitet, ist großartig.
  • Ich bevorzuge nach wie vor eine composable pipeline. In großen Diensten ist die Flexibilität, LLMs je nach Kosten oder Qualität austauschen zu können, ein großer Vorteil.

• Das Projekt ist interessant, aber persönlich hätte ich gern Tool-Calling in einem lokalen 7B-Modell. Die aktuelle Version ist eher ein Proof of Concept, das einfach eine wav-Datei als Eingabe nimmt.

  • Ich habe einen Fork erstellt und ihn so geändert, dass parallel ein weiteres LLM läuft, um den Zeitpunkt für Tool-Calling zu inferieren. Meine Version funktioniert gut für einfache Aufgaben wie Lichtsteuerung. Ein Code-Update gibt es hier.
  • Im Ordner /Examples/PersonaPlexDemo ist eine turn-basierte Gesprächsdemo enthalten. Echtzeit-Transformation ist allerdings noch nicht implementiert.
  • Die Aussage, dass nur wav-Dateien angenommen werden, ist etwas missverständlich. Man braucht nur Audiobuffer, und Streaming-Support ist ebenfalls geplant. Wenn man sich die Entwicklung mit ASR, Streaming-TTS, mehrsprachiger Synthese usw. anschaut, ist klar, dass PersonaPlex auf Streaming-Sprachverarbeitung zielt.
  • Ideal wäre wohl eine Struktur, bei der sich ein Telefon per PWA + WebRTC mit dem Modell auf PC/Mac verbindet. Mit Livekit ist der komplizierte Teil größtenteils schon gelöst.
  • NVIDIA/personaplex funktioniert tatsächlich interaktiv.

• Der LLM-Schreibstil des Artikels wirkte auf mich zu künstlich, sodass ich die Qualität des Projekts angezweifelt habe.

  • Aber dass AI-Forscher LLMs überall einsetzen, ist nur natürlich. Wer sich für AI begeistert, macht das zwangsläufig.
  • Mich würde interessieren, was genau daran wie von einem LLM geschrieben wirkte. Bei den Diagrammen meinetwegen, aber bei welchem Teil des Textes hattest du diesen Eindruck?
  • Ich fand im Gegenteil von AI geschriebene Texte leichter zu lesen. Menschen schreiben oft weitschweifig, während AI Informationen leicht verdaulich strukturiert.
  • Persönlich mag ich von AI erzeugte Grafiken oder Diagramme noch weniger.

• Ich habe die Demo auf einem M1 Max MacBook ausprobiert, aber die Antworten dauerten über 10 Sekunden und waren inhaltlich daneben.

  • Eigentlich liegt die Grenze darin, dass full-duplexe Modelle der 7B-Klasse vom Intelligenzniveau her zu schwach für Tool-Calling sind. Deshalb imitieren sie oft nur Dinge wie Websuche oder Link-Lesen, ähnlich dem Sprachmodus von ChatGPT.
    Natürlich kann das für bestimmte Anwendungsfälle trotzdem nützlich sein, aber darüber würde ich gern mehr lernen.
  • Dem zitierten Beitrag zufolge lässt sich bei PersonaPlex der Gesprächsstil über einen System-Prompt steuern. Ohne Prompt schweift es vom Thema ab, mit Prompt antwortet es deutlich konsistenter.
  • Weiß jemand, wie groß die context size ist?
  • Auf einer GPU der RTX-5070-Klasse reagierte es schneller als ein Mensch.

• Diese Technik wirkt ziemlich gefährlich. Verwandter Artikel: Bericht im Guardian

  • Wenn man LLMs wie Berater einsetzt und frühere Eingaben leicht verändert, um Antworten neu zu generieren, merkt man sofort, wie voreingenommen sie sein können. Sie wirken menschlich, hängen in Wirklichkeit aber übermäßig stark an der Eingabe.
  • Wenn man Nutzer darüber aufklärt, dass ein LLM schlicht ein document completer ist, ließen sich die meisten Probleme vermutlich lösen. Manche Produkte verbergen genau das, damit sie menschlicher wirken, aber das ist eher kontraproduktiv.
  • Der Artikel fasst die Risiken gut zusammen. Es gab Fälle, in denen ein Chatbot den Nutzer „liebte“ und zum Suizid ermutigte, und in einem ähnlichen Fall wurde Google verklagt.

• Das beste full-duplexe Demo, das ich je gesehen habe, war Sesame. Ich frage mich, was daraus geworden ist (Link).

  • Ich habe auch unmute.sh ziemlich gern benutzt.
  • Die Qualität war wirklich kaum zu glauben.

• Ich bin ein Fan von whisperKit. Vor Kurzem wurde TTS-Funktionalität hinzugefügt, wodurch es noch besser geworden ist. Es unterstützt auch Sprechertrennung (speaker diarization) und benutzerdefinierte Wörterbücher.
  Es gibt sogar einen Lasttest, bei dem auf einem Gerät vier Modelle gleichzeitig in Echtzeit liefen:

  • Qwen3-TTS (Text→Sprache)
  • Parakeet v2 (Sprache→Text)
  • Canary v2 (mehrsprachiges STT/Übersetzung)
  • Sortformer (Sprechertrennung)
    Testvideo

• Ich würde gern ein System bauen, bei dem mein Handy Spam-Anrufe automatisch an dieses Modell weiterleitet, sodass es langsam falsche persönliche Daten einstreut und zwischendurch über Wetter oder Sport redet.

  • Auf Spam-SMS angewendet wäre das auch lustig. Wenn Antworten wie „Wegen des Wetters spinnt meine Spülmaschine. Ich habe so viele Taschen fürs Ziegenyoga, dass meine Teller schnell verschleißen“ automatisch generiert würden, wäre diese Art Nonsens-Antworten perfekt.

• Ich versuche gerade, PersonaPlex für Outbound-Calls zu finetunen. Ich habe den LoRA-Ansatz aus Kyutai/moshi-finetune übernommen, aber es funktioniert nur, wenn ich den Skalierungsfaktor auf 5 erhöhe, und dabei geht anderes kaputt.
  GPT-5.3 Codex meinte bei einer Code-Review, Sprecher A/B seien vertauscht, deshalb generiere ich den Datensatz gerade neu.
  Auf meinem GitHub (runvnc) gibt es Versionen von moshi-finetune und personaplex, und mit einer Gradio-App lassen sich Datengenerierung und Training durchführen. Brauchbare Ergebnisse habe ich bisher noch nicht.

• Ich nutze MacWhisper oft, aber beim Whisper-Large-v3-Turbo-Modell summiert sich die Latenz. Wenn man anschließend mit einem Online-LLM nachbearbeitet, wird die Qualität besser, aber es wird langsam.

  • MacWhisper unterstützt bereits Modelle, die etwa 10-mal schneller sind, etwa Parakeet v2. Hast du das schon ausprobiert?
  • Ich bin mit Handy für STT mit Parakeet V2 und Cerebras mit gpt-oss-120b für die Nachbearbeitung sehr zufrieden.
  • Die von Handy unterstützten Modelle sind ebenfalls einen Blick wert. Die Qualität ist niedriger als bei Whisper-large, aber die Geschwindigkeit ist sehr hoch.
  • Das Parakeet-TDT-CoreML-optimierte Modell von Fluid Audio ist das Schnellste, das ich bisher verwendet habe. Das liegt am NPU-Offloading.
    Modell-Link, FluidAudio GitHub
    Die Discord-Community ist ebenfalls aktiv, und es gibt viele Diskussionen über aktuelle Features wie VAD, TTS, EOU.
  • Die Kombination aus Handy + Parakeet v2 ist wirklich hervorragend.