Le runtime exclusivement CPU d'Audio8 fait tenir le clonage vocal dans environ 1 Gio de RAM

Voici le chiffre qui compte dans la sortie du runtime ONNX TTS d'Audio8 : sur un MacBook Air Apple M2 de 16 Go avec cinq threads ONNX Runtime, le service d'inférence se stabilise à environ 1004 Mio de mémoire après le chargement et atteint un pic entre 1,1 et 1,2 Gio pendant la synthèse. C'est du clonage vocal et de la génération de parole sur le CPU d'un ordinateur portable, sans GPU dans l'équation. Les fichiers du modèle pèsent environ 572 Mio en ligne, soit environ 968 Mio si l'on ajoute l'encodeur d'enregistrement vocal optionnel.

Ce runtime est le pendant exclusivement CPU d'Audio8-TTS-Preview-0.6B-ONNX-INT4, le modèle open-weight qu'Audio8 a publié sous licence Apache 2.0. La promesse du modèle : 11 langues, un clonage vocal zero-shot à partir d'un court échantillon de référence, et un codec 44,1 kHz intégré, pour des applications vocales de périphérie qui exigent rapidité et confidentialité. Ce portage ONNX est ce qui rend cette promesse concrète en dehors d'une machine GPU : une fois les poids téléchargés, l'inférence n'a besoin ni de PyTorch, ni de Transformers, ni du Hub Hugging Face.

Ce que coûte réellement le runtime

La précision est répartie selon le rôle. Les poids autorégressifs slow et fast, la partie du modèle qui génère les codes du codec, sont en INT4 réservé aux poids. Les activations, les états cachés et le cache KV restent en FP16, tout comme l'encodeur et le décodeur du codec. Seule la forme d'onde finale en sortie est en FP32.

La synthèse normale ne charge que trois sessions : Slow AR, Fast AR et le décodeur du codec. Le codec intégré explique en partie la légèreté du pipeline : aucun vocodeur séparé à ajouter. La synthèse se déroule en deux étapes : les modèles autorégressifs émettent les codes du codec, et le décodeur du codec les transforme en audio. La CLI écrit ces codes dans un fichier .npy à côté de la sortie .wav.

L'enregistrement vocal suit la même logique. Un profil vocal est un ensemble de codes du codec extraits d'un enregistrement de référence : d'une durée de 0,5 à 30 secondes, d'une taille maximale de 50 Mio, lisible par libsndfile et converti en mono 44,1 kHz par le service. L'enregistrement doit être associé à sa transcription exacte. L'encodeur n'est chargé que pour cette étape, ce qui porte la mémoire à environ 1,55 Gio, puis il est déchargé pour que les sessions de synthèse reprennent. Le README est direct sur le point faible : des références bruitées, longues ou mal transcrites réduisent la stabilité et la similarité du locuteur.

Conçu pour le déploiement, pas pour les démos

Le budget des dépendances est l'information discrète de cette sortie. Les prérequis : Python 3.11 ou plus récent, la CLI du Hub Hugging Face pour un téléchargement unique, et une structure de répertoires fixe. Audio8 a testé la version actuelle sur macOS arm64 avec le CPUExecutionProvider. À partir de là, c'est un service HTTP sur 127.0.0.1:8024 avec trois points d'entrée : une page web, une API JSON à /api/tts, et un endpoint compatible OpenAI à /v1/audio/speech qui répond en WAV. Le code déjà écrit pour cette forme d'API peut pointer vers un modèle local à la place. Le streaming passe par /api/tts/stream, qui renvoie du JSON délimité par des sauts de ligne avec du PCM 16 bits encodé en base64 à 44,1 kHz, et /api/tts/cancel arrête un flux actif. Un script CLI couvre les usages scriptés, et les journaux sont écrits dans service.log.

Le service sérialise les requêtes de synthèse et d'enregistrement, un compromis délibéré qui borne l'utilisation de la mémoire au détriment de la concurrence. Le README le destine à un usage local et à des déploiements CPU à faible concurrence. Le nombre de threads, le répertoire des modèles, le répertoire des voix, l'hôte et le port sont des variables d'environnement avec des valeurs par défaut raisonnables, et un script d'arrêt ferme le service d'arrière-plan géré.

Le moment des petits modèles

Audio8 sort dans une période où les petits modèles vocaux continuent de combler l'écart avec les grands. Voxtral Realtime, un modèle open source de reconnaissance vocale en streaming développé par des chercheurs, revendique une transcription au niveau de Whisper d'OpenAI avec un délai de seulement 480 ms. La préversion TTS 0.6B se situe sous la barre du milliard de paramètres où se concentrent la plupart des modèles TTS ouverts, et elle clone une voix à partir d'un court échantillon sans fine-tuning. Le mouvement open-weight défend le même argument en public : 41 signataires ont récemment défendu les modèles ouverts dans une lettre. La contribution d'Audio8 diffère par nature : elle est générative, créant de la parole plutôt que de la transcrire, et le runtime local est livré comme un artefact de première classe, et non comme une réflexion après coup.

Les réserves tiennent aux données. Environ 1 Gio après le chargement, c'est un ensemble de travail qui convient à un ordinateur portable de 16 Go, pas à un téléphone. La file de requêtes sérialisée plafonne le débit par conception, et les mesures varient selon le système d'exploitation et le comportement de l'allocateur d'ONNX Runtime, comme le note le README. Mais la direction est difficile à contester : un pipeline autorégressif-plus-codec qui aurait exigé une machine GPU il n'y a pas si longtemps s'exécute désormais sur des threads CPU avec de la marge. Le clonage vocal local est désormais un choix d'ingénierie, pas une décision d'infrastructure.