Inversion de prompt : l'inférence LLM distribuée fuit, une défense rigoureuse arrive

De quoi s’agit-il ?

L’inférence collaborative découpe un grand modèle de langage entre plusieurs machines : un téléphone ou un boîtier edge exécute les premières couches transformer, un serveur cloud (ou un essaim de GPU bénévoles) exécute le reste, et seules les activations intermédiaires transitent sur le réseau. C’est une réponse populaire au coût de service des modèles open-weight — qui suppose, implicitement, que les activations peuvent être partagées sans risque.

Cette hypothèse est fausse. L’attaque par inversion de prompt (PIA), introduite dans arXiv:2503.09022 (soumis le 12 mars 2025, révisé le 2 mai 2025), montre qu’un participant malveillant peut reconstruire le prompt d’origine à partir du tenseur d’activations qu’il reçoit. Sur le jeu de données Skytrax avec Llama-65B, l’attaque récupère 88,4 % des tokens d’entrée, même en inversant le nombre maximal de couches transformer — là où la meilleure méthode antérieure plafonnait à 22,8 %. Une ligne de travaux voisine (arXiv:2503.09291) a démontré des attaques similaires d’inférence de prompt contre les frameworks d’inférence LLM distribuée.

Le 10 juin 2026, un nouveau papier — Defense Against Prompt Inversion Attacks: An Information-Theoretic Approach for LLM Collaborative Inference (arXiv:2606.11592, Noorbakhsh, Khalili et Sehatbakhsh) — a proposé la première défense de ce cadre assortie de garanties formelles, plutôt que de bruit heuristique.

Comment ça fonctionne

Côté attaque d’abord : inverser des activations de LLM passait pour difficile en raison de la forte non-linéarité des couches transformer. PIA décompose le problème en deux étapes.

# Attaque par inversion de prompt (PIA), pipeline conceptuel
[activation reçue]
   → Étape 1 : optimiser un embedding d'entrée continu,
               contraint vers la matrice d'embedding du modèle
   → Étape 2 : reconvertir les embeddings en tokens discrets,
               via calibration d'activations + spéculation sémantique
   → [prompt reconstruit, ~88 % de précision token]

Le terme de contrainte est l’astuce centrale : au lieu d’explorer tout l’espace d’embedding, l’optimisation est attirée vers des points correspondant à de vrais tokens du vocabulaire, ce qui rend la récupération discrète finale bien plus précise.

Côté défense : arXiv:2606.11592 formalise la fuite comme une information mutuelle entre l’activation transmise et le prompt d’entrée. Le cadre apprend des représentations préservant la vie privée qui minimisent explicitement cette information mutuelle tout en conservant l’utilité de la tâche, sous contraintes de calcul et de latence. Concrètement, les auteurs insèrent des adaptateurs de confidentialité — des goulets d’information de faible dimension — au point de découpe, et dérivent des bornes théoriques sur l’erreur de reconstruction du prompt et sur la précision token de l’inférence en aval. Résultats annoncés : jusqu’à 35 % de réduction du taux de succès de l’attaque par rapport aux défenses existantes, avec de meilleurs compromis confidentialité-utilité-latence.

Pourquoi c’est important

Toute architecture qui fait franchir une frontière de confiance à des activations hérite de ce risque : déport edge-cloud, places de marché GPU et calcul bénévole, service multi-parties de modèles open-weight, et même certains designs « privacy-friendly » qui gardent les embeddings en local mais transmettent les sorties de couches. Les prompts qui transitent incluent des transcriptions de support client, du code source, des questions médicales. PIA démontre que le destinataire n’a pas besoin du texte brut — les activations sont le texte, à ~88 % de précision token près.

Le papier de défense de juin 2026 compte pour une seconde raison : il documente que les réponses existantes — perturbation heuristique, bruit réglé empiriquement — n’offraient aucune compréhension théorique du gain réel de confidentialité. C’est précisément l’écart entre « nous avons ajouté du bruit » et « nous savons borner l’erreur de reconstruction » qui piège les déploiements en production.

Défenses

• Modélisez la menace de votre découpe. Considérez toute partie recevant des activations intermédiaires comme capable de lire le prompt. Si cette partie n’est pas de confiance, le design équivaut à envoyer du texte en clair, jusqu’à preuve du contraire.
• Préférez les mécanismes rigoureux au bruit ad hoc. Les adaptateurs de confidentialité à goulet d’information (arXiv:2606.11592) offrent une réduction mesurable de l’information mutuelle et des bornes d’erreur de reconstruction ; la perturbation aléatoire, non.
• Surveillez le point de découpe. L’inversion a été démontrée même à travers le nombre maximal de couches — la profondeur seule ne protège pas.
• Isolez les charges sensibles. Routez les prompts réglementés ou confidentiels vers de l’inférence mono-partie, ou vers des montages à isolation matérielle (TEE) ou chiffrement de bout en bout, plutôt que vers du service collaboratif multi-locataires.
• Évaluez contre la vraie attaque. Mesurez toute défense déployée face à l’inversion en deux étapes de type PIA, pas seulement face aux anciennes méthodes d’inversion d’embedding qui récupèrent ~23 % des tokens.

État des lieux

Élément	Détail
Attaque (PIA)	arXiv:2503.09022, soumis le 12 mars 2025 (v3 le 2 mai 2025)
Récupération démontrée	88,4 % de précision token, Skytrax / Llama-65B, inversion max-couches
Attaque liée	arXiv:2503.09291, frameworks d’inférence distribuée
Défense	arXiv:2606.11592, soumis le 10 juin 2026
Gain annoncé	Jusqu’à 35 % de réduction du succès de l’attaque vs défenses existantes
Designs concernés	Inférence découpée edge-cloud, service GPU distribué/bénévole