9 points par GN⁺ 2026-03-06 | 1 commentaires | Partager sur WhatsApp
  • Le modèle PersonaPlex 7B, implémenté en Swift/MLX sur Apple Silicon, prend en charge des conversations vocales bidirectionnelles en temps réel
  • Il unifie l’ancien pipeline vocal en 3 étapes ASR→LLM→TTS en un seul modèle, traitant directement l’entrée et la sortie audio sans conversion en texte
  • Grâce à une quantification en 4 bits (quantization), la taille du modèle est passée de 16,7 Go à 5,3 Go, avec une vitesse de traitement de 68 ms/étape (RTF 0,87), donc plus rapide que le temps réel
  • Il s’appuie sur le codec audio Mimi et l’architecture Depformer pour assurer un streaming efficace sans dégradation de la qualité vocale
  • Il fonctionne nativement en Swift sans serveur et constitue une technologie de base importante pour le développement d’assistants vocaux et d’agents conversationnels

Intégration de qwen3-asr-swift et PersonaPlex 7B

  • La bibliothèque qwen3-asr-swift intègre NVIDIA PersonaPlex 7B sur Apple Silicon pour prendre en charge les conversations vocales bidirectionnelles (full-duplex speech-to-speech)
    • Elle traite l’audio d’entrée en temps réel tout en générant simultanément l’audio de réponse
    • Elle s’étend en une bibliothèque de traitement vocal unifiée incluant ASR, TTS et synthèse multilingue
  • Le modèle est proposé en version 4 bits de 5,3 Go sur Hugging Face : aufklarer/PersonaPlex-7B-MLX-4bit

Unification du pipeline vocal traditionnel

  • Les assistants vocaux classiques reposent sur une architecture en 3 étapes ASR → LLM → TTS, où chaque étape introduit de la latence et une perte d’émotion
  • PersonaPlex unifie cela dans un modèle unique qui traite directement les audio tokens
    • L’audio est converti en temps réel via 17 flux parallèles (12.5Hz)
    • Basé sur l’architecture Moshi de Kyutai, il prend en charge 18 préréglages vocaux et des system prompts fondés sur des rôles

Architecture du modèle et conversion

  • Le checkpoint PyTorch d’origine de 16,7 Go a été converti en safetensors optimisés pour MLX
    • Le script de conversion (convert_personaplex.py) automatise la classification des poids, la quantification 4 bits, l’extraction des préréglages et l’envoi sur Hugging Face
  • Le Temporal Transformer (7B paramètres) et le Depformer ont tous deux été compressés en 4 bits
    • Le Depformer utilise une structure de bascule de poids par étape (MultiLinear) pour passer de 2,4 Go à 650 Mo
    • Cela permet une réduction de taille de 3,7× sans perte de qualité

Pipeline de traitement vocal

  • Le Mimi Encoder/Decoder convertit l’audio 24 kHz en 16 tokens de codebook
    • Le Temporal Transformer traite conjointement les flux audio utilisateur et agent
    • Le Depformer génère les tokens audio de l’agent en 16 étapes
    • Le Mimi Decoder les reconvertit ensuite en audio 24 kHz
  • Des composants de modèles TTS existants, comme le codec Mimi, le cache KV, RoPE, SwiGLU et RMSNorm, sont réutilisés tels quels

System prompts et contrôle du dialogue

  • PersonaPlex contrôle le style de conversation via des system prompts textuels
    • Sans prompt, le modèle a tendance à s’éloigner du sujet ou à répondre de façon verbeuse
    • Des préréglages comme assistant, customer service, teacher peuvent être sélectionnés via la CLI ou l’API
    • Pour une même question, la qualité de réponse varie fortement selon la présence ou non d’un prompt

Performances et traitement en temps réel

  • Sur un M2 Max (64 Go), il atteint 68 ms/étape, RTF 0,87, soit une vitesse supérieure au temps réel
    • Il fonctionne de manière stable dans un budget de 80 ms par frame (12.5Hz)
  • ASR, TTS et Speech-to-Speech peuvent être testés de manière unifiée dans une seule bibliothèque
    • La validation E2E vérifie la cohérence thématique en reconvertissant l’audio de réponse en texte via l’ASR

Streaming et optimisations

  • L’API respondStream() génère en temps réel des chunks audio de 2 secondes
    • Ils peuvent être lus immédiatement sous forme de AsyncThrowingStream<AudioChunk>
  • Quatre optimisations principales :
    • Intégration de eval() pour réduire les synchronisations GPU
    • Bulk audio extraction pour améliorer l’efficacité du décodage
    • Prefill batching pour paralléliser les étapes initiales
    • Compilation du temporal transformer pour optimiser plus de 450 appels de kernels Metal
  • L’activation de la fusion de kernels est possible via l’option --compile ou model.warmUp()

Exécution et déploiement

  • Dépôt GitHub : ivan-digital/qwen3-asr-swift
    • Après compilation avec swift build -c release, il est possible d’exécuter ASR, TTS et Speech-to-Speech via des commandes CLI
    • Au premier lancement, un téléchargement d’environ 5,3 Go du modèle est nécessaire
  • Basé sur le framework MLX, il fonctionne intégralement dans un environnement Swift natif sans Python ni serveur

Portée technique

  • Il démontre l’exécution on-device de modèles vocaux haute performance en exploitant la mémoire unifiée d’Apple Silicon et l’accélération Metal
  • En mettant en œuvre une conversation vocale en temps réel fondée sur un modèle unique, il ouvre la voie à de nombreuses applications comme les assistants IA, centres d’appels et interfaces vocales éducatives
  • Il est présenté comme une réussite d’intégration entre plusieurs écosystèmes open source : NVIDIA, Kyutai, Alibaba Qwen, FunAudioLLM et Apple MLX

1 commentaires

 
GN⁺ 2026-03-06
Commentaires sur Hacker News
  • J’ai vraiment beaucoup aimé ce projet. J’avais déjà essayé de faire tourner PersonaPlex sur un appareil Blackwell sans succès, donc cette fois je vais tenter sur Mac
    Pour avoir pas mal travaillé sur des agents vocaux, il y a quelques points à garder en tête. Même un pipeline VAD→ASR→LLM→TTS donne une impression de temps réel si le RTT reste sous une seconde. Mon projet ova, ainsi que voice-agent et parakeet.cpp, peuvent servir d’exemples
    Après avoir discuté avec la communauté PersonaPlex, il semble qu’une architecture full-duplex complète soit encore difficile, autant en précision qu’en performance, et délicate à entraîner. À l’inverse, une architecture ASR→LLM→TTS est modulaire, avec la flexibilité de mélanger librement petits et grands LLM, ainsi que des endpoints locaux ou basés sur API

    • Je développe aussi moi-même un agent vocal, donc j’aimerais vraiment en discuter. En ce moment, je réfléchis à la manière d’intégrer un pipeline full-duplex dans un agentic framework
      L’architecture classique STT→LLM→TTS s’intègre bien avec les appels d’outils, la gestion avancée du contexte, le RAG, etc. Le fait de séparer l’agent qui parle directement à l’humain et les sous-agents internes fonctionne bien pour réduire la latence et la charge de contexte
      Le full-duplex paraît plus dynamique, mais je ne vois pas encore clairement comment l’intégrer concrètement à un agent vocal. J’aimerais échanger là-dessus sur Discord
    • Le point central de ce fil semble être l’opposition entre full-duplex et pipeline composable, mais en pratique les deux architectures doivent fonctionner en même temps. Cette bibliothèque est déjà à mi-chemin
      Comme qwen3-asr-swift regroupe ASR, TTS et PersonaPlex dans un seul package Swift, tous les composants nécessaires sont déjà là. PersonaPlex gère les backchannels à faible latence et la prise de tour de parole naturelle, tandis qu’un LLM séparé s’occupe des appels d’outils
      Le problème, c’est l’orchestration entre les deux. On ne sait pas encore quand le « cerveau » doit écraser la « bouche », comment éviter que PersonaPlex n’énonce avec assurance des réponses non vérifiées, ou comment gérer les cas où le résultat d’un outil entre en conflit avec une énonciation en cours
    • Je suis entièrement d’accord avec ce pipeline. On peut générer des réponses immédiates avec un petit modèle, tout en lançant en parallèle des appels d’outils ou un routage vers un modèle plus intelligent. Une architecture qui traite en parallèle réponses asynchrones rapides et appels d’outils est excellente
    • Moi aussi, je préfère encore une architecture de composable pipeline. Pour les services à grande échelle, la flexibilité de pouvoir remplacer un LLM selon le coût ou la qualité est un avantage énorme
  • Le projet est intéressant, mais personnellement j’aimerais qu’un modèle local 7B prenne en charge les appels d’outils. Dans sa forme actuelle, c’est surtout une proof of concept qui prend simplement des fichiers wav en entrée

    • J’ai forké le projet et modifié le code pour faire tourner en parallèle un autre LLM chargé d’inférer le moment où déclencher un appel d’outil. Ma version fonctionne bien pour des tâches simples comme le contrôle de l’éclairage. Les mises à jour du code sont ici
    • Le dossier /Examples/PersonaPlexDemo inclut une démo de conversation par tours de parole. En revanche, la transformation en temps réel n’est pas encore implémentée
    • Dire qu’il n’accepte que des fichiers wav est un peu trompeur. Il suffit d’avoir des buffers audio, et la prise en charge du streaming est prévue. Quand on voit l’évolution avec l’ASR, le TTS en streaming et la synthèse multilingue, la direction de PersonaPlex est clairement celle du traitement vocal en streaming
    • Dans l’idéal, une architecture où le téléphone se connecte au modèle du PC/Mac via PWA + WebRTC serait très bien. Avec Livekit, la plupart des parties complexes sont déjà gérées
    • NVIDIA/personaplex fonctionne effectivement de manière interactive
  • Le style de rédaction LLM de l’article me semblait tellement artificiel que j’ai douté de la qualité du projet

    • Mais il est naturel que les chercheurs en IA utilisent des LLM partout. Quand on est passionné par l’IA, c’est assez logique
    • Je serais curieux de savoir ce qui te donnait cette impression de texte écrit par un LLM. Pour les schémas, d’accord, mais dans le texte lui-même, qu’est-ce qui te faisait penser ça ?
    • Moi, au contraire, j’ai trouvé les textes écrits par l’IA plus agréables à lire. Les humains écrivent souvent de façon verbeuse, alors que l’IA structure l’information de manière plus digeste
    • Personnellement, ce sont surtout les graphiques ou diagrammes générés par IA que je n’aime pas
  • J’ai essayé la démo sur un MacBook M1 Max, et il fallait plus de 10 secondes pour répondre, avec en plus des réponses à côté de la plaque

    • En réalité, la limite d’un modèle full-duplex de taille 7B, c’est son niveau d’intelligence trop faible pour permettre les appels d’outils. Il y a aussi ce problème où il ne fait qu’imiter des fonctions comme la recherche web ou la lecture de liens, comme dans le mode vocal de ChatGPT
      Bien sûr, ça peut rester utile pour certains usages spécifiques, mais j’aimerais en apprendre davantage sur ce point
    • D’après l’article cité, PersonaPlex permet de contrôler le style de conversation via un prompt système. Sans prompt, il dérive du sujet, mais avec un prompt, les réponses sont bien plus cohérentes
    • Je me demande quelle est la taille de contexte
    • Sur un GPU de type RTX 5070, il répondait plus vite qu’un humain
  • Cette technologie semble assez dangereuse. Article connexe : article du Guardian

    • Quand on utilise un LLM comme conseiller, il suffit souvent de modifier légèrement une entrée précédente et de régénérer la réponse pour voir à quel point il est biaisé. Il a l’air humain, mais dépend en réalité excessivement de l’entrée
    • Si on expliquait aux utilisateurs qu’un LLM n’est qu’un document completer, la plupart des problèmes seraient sans doute résolus. Certains produits masquent cette réalité pour paraître plus humains, mais c’est plutôt contre-productif
    • L’article résume bien les risques. Il y a eu un cas où un chatbot disait à un utilisateur qu’il l’« aimait » tout en l’encourageant au suicide, et Google a aussi été poursuivi dans une affaire similaire
  • La meilleure démo full-duplex que j’aie vue à l’époque, c’était Sesame. Je me demande ce que c’est devenu aujourd’hui (lien)

    • J’ai aussi beaucoup aimé utiliser unmute.sh
    • Le niveau de finition était vraiment difficile à croire
  • Je suis fan de whisperKit. Avec l’ajout récent de la fonction TTS, c’est devenu bien meilleur. Il prend aussi en charge la diarisation des locuteurs et les dictionnaires personnalisés
    Il y a même un test de charge où 4 modèles tournent en temps réel simultanément sur un seul appareil :

    • Qwen3-TTS (texte→voix)
    • Parakeet v2 (voix→texte)
    • Canary v2 (STT/traduction multilingue)
    • Sortformer (diarisation des locuteurs)
      Vidéo du test
  • J’aimerais construire un système où mon téléphone redirige automatiquement les appels spam vers ce modèle, qui débiterait lentement de fausses infos personnelles en y mêlant des banalités sur la météo ou le sport

    • Ce serait aussi amusant pour les SMS spam. Automatiser des réponses absurdes du genre « À cause de la météo, mon lave-vaisselle s’est mis à dysfonctionner. J’ai tellement de sacs de yoga pour chèvres que mes assiettes s’usent très vite » serait excellent
  • J’essaie de fine-tuner PersonaPlex pour des appels sortants. J’ai appliqué l’approche LoRA de Kyutai/moshi-finetune, mais il faut monter le facteur de scaling à 5 pour que ça fonctionne, et ça casse d’autres choses
    GPT-5.3 Codex m’a signalé pendant la revue de code que les locuteurs A/B étaient inversés, donc je régénère actuellement le dataset.
    Sur mon GitHub (runvnc), il y a des versions de moshi-finetune et personaplex, et une app Gradio permet de générer les données et de lancer l’entraînement. Je n’ai pas encore de résultats vraiment exploitables

  • J’utilise souvent MacWhisper, mais même si le modèle Whisper Large v3 Turbo est correct, la latence s’accumule. La post-traitance avec un LLM en ligne améliore la qualité, mais ralentit le tout

    • MacWhisper prend déjà en charge des modèles 10 fois plus rapides comme Parakeet v2. Tu l’as essayé ?
    • Pour ma part, j’utilise Parakeet V2 sur Handy pour le STT, et gpt-oss-120b de Cerebras pour le post-traitement, et j’en suis satisfait
    • Les modèles pris en charge par Handy valent aussi le détour. La qualité est inférieure à Whisper-large, mais la vitesse est excellente
    • Le modèle Parakeet TDT optimisé CoreML de Fluid Audio est le plus rapide que j’aie utilisé jusqu’à présent, grâce à l’offload NPU
      Lien du modèle, FluidAudio GitHub
      La communauté Discord est active, et les discussions autour des fonctionnalités récentes comme VAD, TTS, EOU sont très animées
    • La combinaison Handy + Parakeet v2 est vraiment excellente