La télémétrie du routeur MoE trahit les données de fine-tuning : une attaque plus précise de 2,7 à 9,4 pts

Si vous affinez un modèle MoE sur des données privées tout en écrivant des logs de routage « pour le monitoring », ces logs peuvent devenir un canal de fuite. Dans un nouvel article publié sur arXiv (2610.10616), les auteurs décrivent une attaque par membership inference qui exploite la télémétrie du routeur. Elle détermine si un exemple précis faisait partie du jeu de données de fine-tuning. Sur trois architectures MoE et trois domaines de données, le gain de TPR à 1% FPR va de 2,7 à 9,4 points de pourcentage dans chacune des neuf configurations. La référence de comparaison est un ensemble robuste de signaux issus de la sortie du modèle.

Comment fonctionne l'attaque

À chaque couche, un modèle Mixture-of-Experts choisit quels experts activer pour un token. Ces décisions sont souvent journalisées pour le débogage, l'analyse de la charge et les audits de sécurité. Contrairement au texte de la réponse, ces données exposent le fonctionnement interne du réseau.

Les auteurs combinent deux types de features. Le premier regroupe des signaux de sortie classiques, comme la confiance du modèle et la perte sur l'exemple. Le second correspond à des features agrégées de routage. Le classifieur d'appartenance est entraîné sur des modèles shadow affinés indépendamment, puis appliqué au modèle cible. Il n'a pas besoin d'accéder aux données d'entraînement de ce dernier.

Résultats clés de l'abstract :

• 3 architectures MoE × 3 domaines de données = 9 configurations, et dans chacune, la télémétrie améliore l'attaque.
• Gain de TPR à 1% FPR : de +2,7 à +9,4 points de pourcentage par rapport à l'ensemble de signaux de sortie.
• La fuite persiste en fine-tuning complet, avec un routeur gelé, avec LoRA et en instruction tuning.
• Les choix discrets d'experts, une télémétrie limitée ou un seul modèle shadow suffisent.
• Bruiter la télémétrie ne réduit la fuite supplémentaire qu'au prix d'une perte équivalente de précision.

Pourquoi le routeur n'a pas besoin de mémoriser

La parade intuitive est la suivante : geler le routeur pour qu'il ne puisse pas mémoriser les exemples d'entraînement. L'analyse mécaniste montre que cela ne fonctionne pas. Le fine-tuning inscrit l'information d'appartenance dans les représentations cachées. Le routeur lit ces représentations et en livre ainsi une projection, même lorsque ses propres paramètres n'ont pas changé. La fuite n'exige pas de mémoire propre au routeur.

Il en découle une conclusion importante pour la défense. Il suffit que le routeur voie les états cachés : des correctifs ciblés sur le routeur ne régleront rien. Il faudra traiter soit la télémétrie elle-même, soit la manière dont les données s'impriment dans les poids.

Ces chiffres appellent une réserve. L'abstract ne donne pas de valeurs absolues de TPR, seulement les gains. Neuf points à 1% FPR sont notables, tandis que deux points et demi paraissent modestes. Mais c'est précisément ce régime à faible taux de faux positifs qui détermine l'utilité de l'attaque pour un audit réel ou un usage malveillant. Un effet systématiquement positif dans les neuf configurations est convaincant en soi.

Que faire pour les équipes qui journalisent le routage

Voici les enseignements pratiques de l'étude et leurs conséquences immédiates :

• Traitez les logs de routage comme des données dérivées du jeu d'entraînement. Limitez l'accès, la durée de conservation et l'export vers des systèmes de monitoring externes.
• Ne transmettez pas la télémétrie brute aux clients ni aux auditeurs tiers avec les réponses du modèle, en particulier pour les modèles affinés sur des données d'utilisateurs ou des données médicales.
• Réduisez la granularité. Des agrégats à la place des choix d'experts token par token affaiblissent le signal. Mais les auteurs montrent que les choix discrets suffisent déjà : il s'agit donc d'une atténuation, pas d'une garantie.
• Le bruitage fonctionne comme un compromis. La fuite diminue exactement dans la mesure où la télémétrie perd en utilité pour le débogage. Il faut décider à l'avance quelle précision vous êtes prêt à sacrifier.
• Intégrez un test à votre processus d'évaluation des risques. Entraînez plusieurs modèles shadow sur votre architecture et mesurez de combien l'attaque progresse quand on ajoute le routage. L'étude montre qu'un seul suffit.
• Envisagez une protection au niveau du fine-tuning lui-même, par exemple la confidentialité différentielle. Cette conclusion est la mienne, pas un résultat de l'article, mais la logique est directe : si le signal vit dans les représentations cachées, c'est la source qu'il faut verrouiller.

Le monitoring d'une infrastructure MoE, où les logs d'experts servent à l'équilibrage de charge et au débogage, devra être conçu en tenant compte de la confidentialité.