PhoneLLM ouvre un modèle spécialisé pour les agents vocaux

Pipecat publie un modèle à poids ouverts conçu pour les appels automatisés, avec des réponses rapides, un usage précis des outils et un coût estimé à 0,0025 dollar par minute.

Réserver une table, vérifier un dossier ou transférer un appel ne demande pas nécessairement plusieurs secondes de réflexion. Avec PhoneLLM Alpha 1, Daily et l’équipe de Pipecat proposent un modèle spécialisé dans les tâches courantes des agents vocaux, où la rapidité compte autant que la qualité de la réponse.

PhoneLLM n’est pas un modèle audio. Il ne transcrit pas directement la voix et ne produit pas lui-même la réponse sonore. Il intervient entre un service de reconnaissance vocale et un moteur de synthèse, au sein d’une chaîne comme Pipecat. Son rôle consiste à comprendre la demande transcrite, décider de l’action à effectuer, appeler les bons outils et rédiger une réponse courte avant sa lecture à voix haute.

Les modèles généralistes peuvent accomplir ces tâches, mais leurs modes de raisonnement ajoutent souvent un délai difficilement compatible avec le rythme d’une conversation téléphonique. Désactiver cette réflexion réduit la latence, au risque de détériorer le suivi des consignes ou l’appel d’outils. PhoneLLM a précisément été entraîné pour fonctionner sans cette étape intermédiaire.

Le modèle repose sur NVIDIA Nemotron 3 Nano 30B-A3B. Il compte 30 milliards de paramètres au total, mais n’en active qu’environ 3,5 milliards pour chaque entrée. Pipecat a réalisé un ajustement complet de ses poids avec le framework NeMo de NVIDIA, à partir de conversations téléphoniques et de scénarios de service client.

L’entraînement couvre notamment la finance, la santé, le commerce, l’hôtellerie et les appels sortants. L’objectif est d’obtenir des réponses brèves, pertinentes et cohérentes au fil d’une longue conversation. Une attention particulière a été portée à la différence entre dire qu’une action a été effectuée et réellement appeler l’outil nécessaire.

Dans un cas classique, un agent peut annoncer qu’une réservation est confirmée sans avoir transmis la moindre requête au système concerné. PhoneLLM doit éviter ce décalage en vérifiant les informations nécessaires, en appelant le service approprié et en ne confirmant l’opération qu’après son exécution.

Pour mesurer ces comportements, l’équipe présente PhoneBench v1, un nouveau banc d’essai consacré aux agents téléphoniques. Il évalue le style oral, la pertinence, la cohérence de la conversation, la précision des appels d’outils, la concordance entre les paroles et les actions, le respect des procédures d’authentification ou d’escalade et l’issue obtenue pour l’appelant.

Les réponses sont notées par plusieurs modèles juges, calibrés à partir d’évaluations humaines. Les scénarios, consignes et listes d’outils sont séparés des données utilisées pour entraîner PhoneLLM. Cette méthode cherche à vérifier sa capacité à traiter des situations inédites, mais PhoneBench reste un test développé par l’équipe qui publie le modèle. Ses résultats ne disposent pas encore d’une validation indépendante.

Selon ce benchmark, PhoneLLM obtiendrait des performances proches de GPT 5.6 Terra sur les tâches typiques d’un agent vocal, avec un coût inférieur de 94 % et un délai P95 avant le premier token réduit d’environ 1,3 seconde. La comparaison est effectuée avec les modes de raisonnement désactivés ou réduits, une configuration cohérente avec les contraintes du temps réel mais qui ne représente pas tous les usages possibles des modèles évalués.

Sur une NVIDIA B200 peu chargée, le temps P95 avant le premier token descendrait sous les 100 millisecondes pour une requête isolée. Ce chiffre mesure uniquement le traitement effectué par PhoneLLM côté serveur. Il n’inclut pas la transcription, la synthèse vocale, la logique applicative ni l’ensemble des échanges réseau qui composent la latence réellement perçue par l’utilisateur.

Pour se rapprocher d’une charge de production, Pipecat et Modal ont également simulé des conversations complètes à partir de pipelines vocaux. Leur configuration optimisée peut prendre en charge 88 processus d’agents sur une B200 tout en maintenant un délai P95 inférieur à 600 millisecondes avant le premier token de réponse, réseau compris pour la partie testée.

L’estimation de 0,0025 dollar par minute repose sur cette densité de 88 agents, un coût effectif de 13,392 dollars par heure pour la B200 hébergée chez Modal et un taux d’utilisation fixé à 70 %. Elle concerne le modèle de langage et ne couvre pas nécessairement la reconnaissance vocale, la génération de la voix, la téléphonie ou les autres services nécessaires à l’agent final.

Ces performances dépendent donc d’une infrastructure haut de gamme, d’un taux d’occupation élevé et des optimisations développées avec Modal. Un déploiement moins fréquenté, une autre carte ou une configuration générique de vLLM ne retrouvera pas automatiquement le même coût par minute. Modal estime d’ailleurs que ses réglages doublent approximativement le nombre d’agents simultanés par rapport à une configuration standard.

Les poids de PhoneLLM Alpha 1 sont disponibles sur Hugging Face. Le modèle possède une fenêtre de contexte de 262 144 tokens, fonctionne actuellement en anglais et peut être servi avec vLLM ou SGLang. L’équipe recommande une température réglée sur zéro et la désactivation complète du mode de réflexion.

La version publiée utilise une licence BSD à deux clauses pour les modifications de Pipecat. Comme elle dérive de Nemotron 3 Nano, la licence ouverte de NVIDIA continue également de s’appliquer au modèle d’origine, notamment pour la conservation des mentions et documents requis lors d’une redistribution.

Un déploiement peut être lancé directement depuis Modal ou installé sur une infrastructure compatible. La taille de 30 milliards de paramètres en bfloat16 maintient néanmoins des besoins matériels importants, même si seuls 3,5 milliards sont actifs pendant le traitement. « Ouvert » ne signifie donc pas nécessairement léger ou simple à exploiter localement.

PhoneLLM illustre une tendance plus large : utiliser un modèle plus petit, entraîné sur une fonction précise, plutôt qu’un système généraliste mobilisé