Un agent axé d'abord sur le local pour le travail de la connaissance privé et rentable

Perplexity Portable Computer est un agent axé d'abord sur le local.

L'ensemble de la pile s'exécute localement par défaut. Le modèle, l'infrastructure, la conversation et la trajectoire résident tous sur la machine de l'utilisateur. Le travail qui nécessite le monde extérieur, tel que la recherche Web, les connecteurs ou l'escalade vers un modèle conseiller plus puissant sur le nuage, n'est invoqué que lorsque c'est nécessaire et est toujours contrôlé par l'utilisateur. Par conséquent, les données sensibles ne quittent jamais l'appareil sans permission, et les modèles locaux n'entraînent aucuns frais d'inférence : le système est privé et rentable par conception.

Un agent axé d'abord sur le local efficace exige que le modèle et l'infrastructure soient conçus conjointement. Les infrastructures à usage général supposent un modèle de pointe capable d'absorber de longs contextes, de naviguer dans une vaste surface d'outils et de planifier sur de longs horizons. Les modèles locaux sont moins fiables face à ces exigences. Plutôt que de demander à un petit modèle de gérer une infrastructure conçue pour un grand, nous avons façonné les deux l'un autour de l'autre : une infrastructure adaptée au profil de capacités du modèle, et un modèle post-entraîné pour utiliser cette infrastructure efficacement.

Introduction

Ces derniers mois, les capacités des agents ont progressé rapidement dans un large éventail de tâches de travail de la connaissance. Bien que ces progrès apportent d'importants gains de productivité et d'efficacité, ils posent également deux défis.

La consommation de jetons augmente rapidement, tout comme les dépenses globales. Lorsque l'intelligence est accessible par le biais des API de modèles à code source fermé exécutés sur des grappes distantes, les renseignements personnels et la propriété intellectuelle quittent l'appareil de l'utilisateur à chaque requête. À mesure que les agents se multiplient dans les flux de travail individuels et au sein des organisations entières, la consommation de jetons et le mouvement des données deviennent de plus en plus difficiles à régir.

Dans le même temps, les modèles à source ouverte se sont améliorés à un rythme encore plus rapide. Les progrès sont particulièrement visibles dans les modèles très petits et efficaces tels que NVIDIA Nemotron 3.5 Lightning (30 milliards de paramètres au total), Qwen 3.6 (35 milliards) et Qwen 3.8 (27 milliards). Ces petits modèles surpassent leur catégorie et sont désormais capables de flux de travail complexes fondés sur des agents. Le matériel d'inférence locale progresse en parallèle : des systèmes tels que le NVIDIA DGX Spark peuvent désormais exécuter ces modèles localement. Ensemble, ces tendances rendent le fonctionnement entièrement sur appareil pratique tout en permettant aux utilisateurs d'opter pour des capacités externes en cas de besoin, telles que la recherche Web, les connecteurs ou l'escalade vers un modèle sur le nuage.

Cette approche axée d'abord sur le local permet des économies de coûts considérables, car l'inférence locale évite les frais d'API par jeton. Elle résout également naturellement les problèmes de confidentialité et de propriété intellectuelle : les jetons privés n'ont jamais besoin d'être transmis à des grappes distantes et restent en toute sécurité dans les limites de l'appareil local.

En juin, nous avons présenté le premier orchestrateur d'inférence hybride local-serveur qui décide quel travail doit s'exécuter sur l'appareil et quel travail doit être confié à des agents dans le nuage. Nous expliquons ici comment nous avons conçu un tel agent axé d'abord sur le local, y compris l'infrastructure et les modèles co-optimisés l'un pour l'autre.

Nous présentons un aperçu des principaux choix de conception et évaluons Computer par rapport à des infrastructures à usage général à source ouverte populaires (Hermes et Pi) sur trois repères publics et notre repère interne Local Knowledge Work Bench. Sur notre repère, avec le modèle Qwen 3.8 27B exécuté sur un NVIDIA DGX Spark, Computer obtient le score le plus élevé, soit 82,6 %, contre 77,6 % pour Pi et 74,0 % pour Hermes. PPLX 27B, notre modèle post-entraîné au-dessus de Qwen 3.8 27B, fait passer le score à 85,4 %.

Concevoir l'infrastructure autour du modèle local

Bien que les modèles compacts sur appareil soient déjà très compétents, ils sont toujours à la traîne par rapport aux plus grands modèles de pointe en matière de performance. Une infrastructure conçue avec soin est nécessaire pour guider ces modèles efficacement et remédier à leurs limites.

Les infrastructures à source ouverte populaires telles que Pi et Hermes se sont révélées générales : elles fonctionnent bien avec une grande variété de modèles de toutes tailles et catégories. Mais elles ne sont pas optimisées pour les capacités des modèles sur appareil. Nous avons conçu l'infrastructure locale spécifiquement pour ce contexte, autour de quelques principes clés.

Efficacité du contexte

L'objectif principal lors de la conception de notre infrastructure était de tirer le meilleur parti du contexte du modèle.

Bien que les modèles sur appareil tels que Qwen 3.8 27B offrent des fenêtres de contexte de 260 000 jetons, nous avons constaté de manière empirique qu'ils commencent à peiner au-delà de 100 000 jetons. Nous veillons donc à ce que l'infrastructure principale reste succincte : une invite système minimale et un petit ensemble d'outils de base.

Toutes les autres capacités sont modularisées en compétences à la demande qui se chargent et se déchargent tout au long de la trajectoire. Nous avons conçu ces compétences pour les tâches courantes de travail de la connaissance : recherche, science des données, visualisation de données, création de documents, génie logiciel, et plus encore.

L'infrastructure prend également en charge le compactage du contexte, résumant le contexte périmé lorsqu'une trajectoire devient longue afin que le modèle reste dans sa fenêtre efficace.

Les connecteurs en tant d'outils en ligne de commande

Le travail de la connaissance quotidien nécessite souvent des connecteurs tels que Gmail, GitHub, Outlook et Google Calendar. Ceux-ci sont généralement exposés à une infrastructure sous forme de serveurs MCP, dont les grandes définitions d'outils consomment une part substantielle du contexte. Au lieu de cela, nous avons converti les MCP les plus utilisés en outils en ligne de commande compacts et faciles à utiliser, complétés par des compétences personnalisées qui font un bien meilleur usage du contexte effectif limité.

Auto-vérification

Les performances s'améliorent également lorsque l'agent vérifie son propre travail. La vérification ajoute des étapes supplémentaires, mais elle améliore considérablement les résultats finaux et réduit substantiellement l'écart avec les modèles de pointe. Elle peut être déclenchée par le modèle lui-même ou par un ensemble de crochets qui surveillent la santé de la trajectoire et demandent une auto-vérification en cas de problème.

Exécution en bac à sable

L'infrastructure exécute les outils dans un bac à sable au niveau du système d'exploitation sur l'appareil de l'utilisateur. La limite restreint les processus, les chemins du système de fichiers et l'accès au réseau conformément aux politiques. Cela limite le rayon d'impact d'une commande erronée. Si le bac à sable n'est pas disponible, l'infrastructure se désactive elle-même avant tout appel d'outil plutôt que de dégrader vers une exécution sans bac à sable.

Cela diffère des infrastructures à source ouverte telles que Pi et Hermes, qui exécutent des commandes directement avec les autorisations de l'utilisateur par défaut. Dans Computer, l'isolement est toujours activé, ne nécessite aucune configuration et les outils ne peuvent pas s'exécuter sans lui.

Le diagramme ci-dessous montre comment ces principes s'articulent dans la boucle d'exécution. L'orchestrateur est un code d'infrastructure déterministe, et non un LLM : il maintient la boucle, assemble le contexte et applique les politiques. Le modèle local propose l'action suivante; l'orchestrateur exécute les appels d'outils approuvés dans le bac à sable et retourne leurs résultats au modèle. La recherche Web, les connecteurs et les appels au conseiller ne franchissent la limite de l'appareil que lorsqu'ils sont activés et approuvés.

Une infrastructure locale tire davantage parti du même modèle

En utilisant le même modèle de base sur appareil, nous comparons notre infrastructure locale à des solutions de rechange à usage général sur la recherche Web et la compréhension de documents multimodaux. Toutes les infrastructures utilisent le modèle Qwen 3.8 27B avec un raisonnement moyen, exécuté sur un NVIDIA DGX Spark. Cette comparaison isole les capacités apportées par l'infrastructure elle-même, avant tout post-entraînement du modèle.

Nous nous concentrons sur ces deux capacités parce que le travail de la connaissance combine souvent des documents privés sur l'appareil de l'utilisateur avec des informations publiques du Web pour produire un artefact ancré. La recherche Web nécessite une connectivité, mais l'inférence du modèle et le traitement des documents privés restent locaux. Les fichiers locaux servent de source faisant autorité, les sources publiques ajoutent du contexte et les utilisateurs peuvent désactiver entièrement la recherche Web pour un travail entièrement hors ligne.

Recherche Web

Nous construisons notre infrastructure locale parallèlement au moteur de recherche de Perplexity, qui a atteint les premiers rangs dans des évaluations indépendantes. L'infrastructure y accède par le biais de l'interface Search as Code.

Nous évaluons la qualité de la recherche sur 1 266 tâches BrowseComp. Computer utilise l'infrastructure de recherche de Perplexity ainsi que notre infrastructure locale, tandis que Pi et Hermes s'appuient sur Brave, leur fournisseur de recherche recommandé. Computer atteint une précision de 66,7 %, contre 50,2 % pour Pi et 43,9 % pour Hermes.

Computer présente également le temps réel moyen enregistré et l'utilisation de jetons les plus faibles : 402,1 secondes et 852 000 jetons par tâche, contre 1 020,9 secondes et 1,01 million de jetons pour Hermes, et 826,0 secondes et 2,82 millions de jetons pour Pi. Computer utilise donc 61 % de temps réel en moins et 16 % de jetons en moins qu'Hermes, et 51 % de temps réel en moins et 70 % de jetons en moins que Pi.

Compréhension de documents multimodaux sur appareil

De nombreux documents contiennent des informations visuelles et sont difficiles à analyser sous forme de texte brut : PDF, pages numérisées, captures d'écran, graphiques et présentations. Ces flux de travail dépendent de la reconnaissance optique de caractères (OCR) et de la compréhension d'images, et tirent le plus grand profit d'un modèle nativement multimodal.

L'infrastructure transmet directement les pages de documents et les images au modèle, qui les comprend et combine les preuves visuelles avec le texte extrait. Le traitement de ces fichiers sur l'appareil garantit la confidentialité des documents sensibles et de leur contenu extrait.

Nous évaluons la compréhension de documents multimodaux sur ParseBench-100, un sous-ensemble de 100 tâches du repère ParseBench, avec 20 tâches chacune pour les graphiques, la mise en page, les tableaux, le contenu textuel et le formatage.

Computer atteint un score moyen de 65,1 %, contre 34,6 % pour Hermes et 13,9 % pour Pi. Il accomplit également les tâches avec le moins de temps et le moins de jetons : en moyenne 60,6 secondes et 20 100 jetons par tâche, contre 108,3 secondes et 32 100 jetons pour Hermes, et 410,5 secondes et 829 100 jetons pour Pi. Computer est en tête dans les cinq catégories de documents, son plus grand avantage se situant sur les graphiques. La mise en page reste difficile pour les trois infrastructures.

Tableau 1. Score moyen de ParseBench-100 par catégorie de document pour les infrastructures Computer, Hermes et Pi avec le modèle Qwen 3.8 27B sur appareil. Computer est en tête dans les cinq catégories.

Réduction de l'écart avec les modèles de pointe grâce à l'escalade vers un conseiller

Même avec une infrastructure conçue avec soin, les tâches les plus difficiles dépassent encore les capacités d'un modèle compact sur appareil. Pour ces tâches, l'infrastructure expose un outil de conseiller : le modèle local peut consulter un modèle de pointe plus puissant lorsqu'il a besoin d'aide pour la planification, la résolution d'ambiguïtés, la récupération après des échecs répétés ou la vérification du résultat final.

Le modèle local décide quand demander conseil, tandis que l'orchestrateur de l'infrastructure conserve l'autorité sur les outils et contrôle le contexte envoyé. L'escalade est facultative. L'utilisateur décide s'il souhaite l'activer et s'il veut approuver chaque appel au conseiller manuellement ou automatiquement.

Avant un appel au conseiller, l'infrastructure sélectionne le contexte pertinent, applique un classificateur de renseignements personnels identifiables (PII) pour signaler les informations sensibles et montre à l'utilisateur ce qui quitterait l'appareil. Le conseiller ne reçoit que le contexte approuvé et renvoie des conseils textuels; il n'a aucun accès direct aux fichiers, aux outils ou aux conversations de l'appareil. Cela améliore à la fois les coûts et la confidentialité, et nous prévoyons d'explorer davantage cette direction dans de futurs travaux.

Nous testons cette approche sur des tâches de génie logiciel exigeantes, qui nécessitent un raisonnement solide et sont celles où un modèle local est le plus souvent insuffisant. Pour ce faire, nous utilisons Terminal Bench 2.1, un repère populaire de 89 tâches pour les agents de codage.

Nous voulons répondre à deux questions : quelle part de l'écart avec un modèle de pointe l'escalade vers un conseiller peut-elle combler, et à quel coût. L'exécution de modèles entièrement locaux ne coûte pratiquement rien, puisque l'inférence se produit sur le matériel de l'utilisateur. Cependant, une fois que le modèle commence à appeler le conseiller, il commence à engendrer des coûts d'API.

Comme référence pour les performances des modèles de pointe, nous utilisons Claude Opus 5 fonctionnant dans l'infrastructure locale; le modèle local est Qwen 3.8 27B. Enfin, nous associons les deux : Qwen 3.8 27B exécute la tâche et fait appel à un conseiller Claude Opus 5 lorsqu'il a besoin d'aide. Nous n'évaluons pas l'escalade vers un conseiller avec Pi ou Hermes, car aucun d'eux ne fournit d'outil de conseiller équivalent; en ajouter un nécessiterait de modifier sa surface d'outils et sa logique d'orchestration, de sorte que le résultat ne représenterait plus l'infrastructure standard.

L'escalade vers un conseiller fait passer le score de Computer de 59,6 % à 73,0 %, soit un gain de 13,5 points de pourcentage, pour un coût d'API estimé à 0,415 $ par déploiement. L'exécution de Claude Opus 5 seul atteint 82,4 % à 0,65 $ par déploiement. L'escalade récupère ainsi environ les trois cinquièmes de l'écart avec les modèles de pointe à environ les deux tiers de leur coût, et l'utilisateur décide si ce compromis en vaut la peine.

Post-entraînement pour l'infrastructure et le travail de la connaissance

Jusqu'à présent, nous avons laissé le modèle local inchangé pour isoler la contribution de l'infrastructure. Une fois la conception de l'infrastructure en place, les gains les plus importants proviennent de l'adaptation du modèle lui-même. Les données d'utilisation de Perplexity Computer nous montrent ce que les gens font réellement pour le travail de la connaissance, ce que nous utilisons pour synthétiser des données d'entraînement. Nous post-entraînons le modèle local au sein de l'infrastructure Computer, guidés par la distribution réelle des tâches que les utilisateurs effectuent.

Concrètement, nous identifions un ensemble diversifié de cas d'utilisation qui mobilisent différentes capacités de modèles, outils et connecteurs. À partir de ces cas d'utilisation, nous synthétisons des environnements d'apprentissage par renforcement réalistes et définissons des tâches stimulantes mais vérifiables : chaque tâche consiste en une instruction, un environnement et un vérificateur qui note le résultat final, l'environnement étant un conteneur Docker dans lequel l'infrastructure fonctionne. Fait important, les tâches étant synthétiques, elles ne contiennent aucun document réel ni aucune information utilisateur.

Nous utilisons ces environnements pour un entraînement en deux étapes : un réglage fin par rejet suivi d'un apprentissage par renforcement. Dans la première étape, nous déployons le modèle face à chaque tâche plusieurs fois, sélectionnons les meilleures trajectoires selon le score du vérificateur et les entraînons par apprentissage supervisé. Cette étape initialise le modèle pour l'infrastructure spécifique et la distribution des tâches. Dans la deuxième étape, l'apprentissage par renforcement affine davantage le modèle, le rendant plus robuste.

Un sous-ensemble de tâches est mis de côté lors de l'entraînement et utilisé pour l'évaluation finale; nous appelons cet ensemble mis de côté Local Knowledge Work Bench : 53 tâches couvrant sept catégories de travail de la connaissance quotidien, de la recherche approfondie à la création de documents. Nous publierons bientôt un rapport technique décrivant l'entraînement du modèle en détail, et nous prévoyons de diffuser ce repère d'évaluation en source ouverte.

Nous avons post-entraîné Qwen 3.8 27B avec cette approche, produisant un modèle que nous appelons PPLX 27B, et l'avons évalué sur le Local Knowledge Work Bench. Avec le modèle de base Qwen 3.8 27B, Computer obtient le score le plus élevé (82,6 %, contre 77,6 % pour Pi et 74,0 % pour Hermes) et utilise le moins de jetons (520 000, contre 681 000 pour Pi et 634 000 pour Hermes). Pi accomplit les tâches le plus rapidement à 176 secondes par tâche, contre 218 secondes pour Computer et 292 secondes pour Hermes. PPLX 27B porte le score de Computer à 85,4 %, au prix d'un plus grand nombre de jetons (678 000 contre 520 000). Son temps réel estimé est de 250 secondes.

Tableau 2. Catégories de tâches du Local Knowledge Work Bench.

Conclusion

Nos recherches montrent qu'un modèle à source ouverte puissant, doté d'un matériel local performant et d'une infrastructure conçue pour eux, peut gérer un véritable travail de la connaissance à un coût d'inférence presque nul, sans exiger que des données sensibles quittent l'appareil.

Sur l'ensemble des différents repères, Computer a égalé ou dépassé Hermes et Pi en matière de précision tout en exécutant Qwen 3.8 27B sur un NVIDIA DGX Spark. Parmi les trois repères qui rapportent la latence et l'utilisation de jetons, Computer a été le plus rapide sur BrowseComp et ParseBench-100 et a utilisé le moins de jetons sur les trois; Pi a été le plus rapide sur le Local Knowledge Work Bench.

Les gains proviennent des choix que nous avons faits. Nous avons construit une infrastructure locale succincte dotée de compétences qui se chargent à la demande. Nous avons converti les connecteurs en outils CLI compacts plutôt qu'en serveurs MCP. L'exécution a été placée dans un bac à sable pour des raisons de sécurité.

Les résultats montrent également où les modèles compacts peuvent encore s'améliorer. Par exemple, sur les tâches de codage exigeantes de Terminal Bench 2.1, le modèle local est à la traîne par rapport au modèle de pointe dans toutes les infrastructures. L'escalade vers un conseiller réduit l'écart, mais ne le comble pas entièrement; des améliorations continues des capacités des modèles et du matériel local sont encore nécessaires pour pousser les performances plus loin.

L'objectif de la création de l'infrastructure et du modèle pour les contraintes locales est de donner aux utilisateurs un contrôle explicite sur les informations qui quittent leurs machines. Il y a également des avantages en matière de coûts pour l'utilisateur. Nous y voyons une composante d'un changement plus vaste dans lequel des agents de plus en plus performants passent de l'infrastructure distante aux appareils individuels et locaux. Nous nous attendons à ce que les progrès des puces, des modèles et des appareils élargissent continuellement la portée et la qualité du travail de la connaissance que Portable Computer gère localement.