Le DGX Spark fait tourner Perplexity Computer en local, avec le cloud sous autorisation

Portable Computer exécute modèles, orchestration, outils et fichiers sur un DGX Spark, puis demande une autorisation avant toute sortie vers le cloud.

Lire des documents confidentiels, analyser un dépôt de code ou mener une tâche longue sans envoyer chaque étape vers des serveurs distants : c’est la proposition de Portable Computer. Cette nouvelle version de Perplexity Computer déplace sur une machine locale le modèle, le harnais d’agent, la planification, l’exécution des outils, la mémoire des sessions et la recherche dans les fichiers.

Le premier environnement compatible est le NVIDIA DGX Spark, un ordinateur de bureau compact équipé de 128 Go de mémoire unifiée. Portable Computer est accessible aux abonnés Perplexity Pro et Max, avec une première version sous Linux. Les PC équipés de cartes NVIDIA RTX et Windows doivent suivre.

Contrairement à Perplexity Computer, dont l’exécution dépend principalement de modèles et de sandbox distants, chaque tâche commence ici sur le DGX Spark. Le modèle local décompose la demande, consulte les fichiers autorisés, appelle les outils nécessaires et conserve l’état du travail d’une session à l’autre. Une migration de dépôt, l’analyse en série de documents ou la production d’un rapport peuvent ainsi être traitées sans facturation liée au nombre de tokens utilisés par le modèle local.

L’expression « entièrement local » demande malgré tout une précision. Portable Computer peut fonctionner sans modèle cloud pour les tâches limitées aux données et aux outils présents sur la machine. Une recherche web, la consultation d’une information récente, l’accès à Gmail ou la publication d’un message dans Slack nécessitent toujours une connexion à des services extérieurs. Le produit est donc local-first plutôt que systématiquement hors ligne.

Les connecteurs couvrent Google Drive, Gmail, Outlook, Slack et GitHub. Ils sont pilotés par l’orchestrateur local, mais l’action elle-même touche nécessairement l’infrastructure du service concerné. Lire un document enregistré sur le DGX Spark peut rester entièrement local. Envoyer son résumé dans Slack fait sortir le message de la machine.

Le même principe vaut pour Perplexity Search, les recherches approfondies et les modèles cloud. Lorsqu’une étape dépasse les capacités du modèle local ou demande des données extérieures, Portable Computer interrompt l’exécution et affiche ce qui doit quitter l’appareil. L’utilisateur peut refuser ou autoriser cette sortie avant que la tâche reprenne.

Pour une escalade vers un modèle plus puissant, le harnais sélectionne uniquement le contexte jugé utile et applique un classificateur chargé de signaler les informations personnelles. L’utilisateur examine ensuite le contenu transmis. Le modèle distant reçoit ce contexte approuvé et renvoie seulement des indications textuelles. Il n’accède pas directement aux fichiers, aux outils ou à la conversation complète conservée sur le DGX Spark.

Cette séparation maintient également le contrôle des actions en local. Le modèle cloud peut suggérer une méthode, résoudre une ambiguïté ou aider à débloquer une étape, mais il ne manipule pas lui-même les ressources de la machine. Le modèle local et le harnais décident de la suite à donner à ses recommandations.

Le vocabulaire employé par Perplexity entretient une légère ambiguïté. Le fil publié sur 𝕏 parle d’un « orchestrator LLM » installé localement. Le billet technique décrit plus précisément un orchestrateur composé de code déterministe. Celui-ci contrôle la boucle d’exécution, prépare le contexte et applique les règles, tandis que le modèle local propose l’action suivante. Dans l’interface, ce modèle est malgré tout désigné comme l’« orchestrateur ». Les deux composants fonctionnent sur la machine, mais ils ne jouent pas le même rôle.

La pile locale comprend aussi un planificateur, un routeur d’outils, un ordonnanceur, une file de tâches persistante et un index de recherche local. Ce dernier sert à retrouver des informations dans les documents et le code sans les envoyer vers un moteur distant. Des sous-agents peuvent travailler simultanément sur plusieurs parties d’une demande.

L’exécution du code et des outils passe par des sandbox isolés au niveau du système d’exploitation. Les processus, les chemins accessibles et les connexions réseau sont limités selon les règles appliquées à la tâche. Le billet technique précise que le harnais s’arrête si cette isolation devient indisponible, au lieu de continuer avec les permissions générales de l’utilisateur.

Portable Computer s’appuie au lancement sur Qwen 3.8 27B et PPLX 27B, une version post-entraînée par Perplexity à partir de Qwen. Le travail supplémentaire porte moins sur les connaissances générales du modèle que sur son comportement dans le harnais : choisir un outil, lire des fichiers, vérifier une action, limiter la taille du contexte et décider si une aide extérieure devient nécessaire.

Perplexity indique avoir entraîné PPLX 27B en deux étapes, avec un premier apprentissage sur les meilleures trajectoires synthétiques, suivi d’un renforcement destiné à rendre son comportement plus robuste. Les exercices ont été construits à partir de situations de travail représentatives, mais sans reprendre de documents ou de données provenant de personnes réelles.

Le harnais a également été allégé pour tenir compte des limites d’un modèle local. Perplexity indique que Qwen 3.8 27B accepte théoriquement 260 000 tokens de contexte, mais perd en fiabilité au-delà de 100 000. Le système conserve donc un prompt principal court, charge ses skills à la demande et résume les informations devenues moins utiles au fil d’une tâche.

Les connecteurs suivent la même logique. Au lieu de charger de longues définitions MCP dans le contexte, les intégrations les plus courantes ont été converties en outils compacts utilisables depuis le terminal. Cette réduction laisse davantage de place aux instructions, aux documents et aux résultats intermédiaires.

Les évaluations publiées par Perplexity cherchent à mesurer l’apport de cette architecture. Sur Local Knowledge Work Bench, un test interne composé de 53 tâches réparties entre recherche, finance,