Aujourd'hui, nous vous présentons Altar, notre premier modèle de sécurité « open-weight », conçu pour apporter une sécurité de pointe aux infrastructures que vous contrôlez.
Nous avons franchi une première étape vers un système de renseignement de sécurité souverain grâce à notre appliance « pentest autonome » ( Aikido ), qui fonctionne entièrement au sein de l’infrastructure propre au client, y compris dans des environnements totalement isolés (air-gapped). Les équipes soumises à des règles strictes en matière de conservation du code en interne peuvent ainsi détecter, exploiter et valider en continu les vulnérabilités sur l’ensemble de leur surface d’attaque sans enfreindre ces règles.
Altar dote la plateforme «Aikido » d'une intelligence artificielle avancée qui assure la protection des données, sans transmettre les informations les plus sensibles d'une organisation à un service d'inférence tiers.
Pour ce faire, nous devions combler le fossé en matière de déploiement. La plupart des modèles à poids ouvert performants restent difficiles à déployer à l'échelle de la production tout en conservant la qualité de raisonnement des modèles de pointe.
Nous avons commencé par le GLM-5.3, l'un des modèles les plus performants de nos évaluations de sécurité. Le modèle complet occupe 1,51 To ; la quantification permet de ramener ce volume à 488 Go, et notre processus d'élagage par des experts le réduit encore davantage à 328 Go, tout en préservant la majeure partie de la qualité de raisonnement du modèle d'origine.
.png)
Explication de la différence entre les modèles « frontier » et « open-weights »
Modèles en « frontière fermée » fonctionnant sur l'infrastructure d'un tiers
Opter pour cette solution revient à laisser sortir de votre réseau votre code source, la documentation relative à votre architecture interne et vos résultats d'audit non corrigés. Pour une banque soumise à une obligation de résidence des données, un groupe hospitalier soumis à des règles strictes en matière de traitement des données ou un opérateur industriel dont l'environnement OT n'est absolument pas connecté à Internet, ce n'est pas un compromis qu'ils sont autorisés à faire.
Le déficit de déploiement
L'exécution d'un modèle tel que GLM 5.3 avec une précision maximale nécessite des centaines de gigaoctets de mémoire unifiée et offre une vitesse d'inférence limitée lors du traitement de conversations parallèles avec des fenêtres de contexte étendues. En termes concrets, ces volumes sont colossaux.
Ces besoins en ressources s'expliquent en partie par la manière dont ces modèles sont construits. Bon nombre des modèles les plus performants actuels utilisent des architectures de type « mélange d’experts ». Ces modèles sont constitués d’une multitude de petits réseaux neuronaux spécialisés, appelés « experts ». Seul un petit nombre d’experts est actif pour chaque token, tandis que l’ensemble du pool d’experts doit tout de même être stocké et mis à disposition. Cela implique de supporter un coût important en mémoire et en infrastructure pour une capacité qui peut contribuer très peu à la charge de travail que vous exécutez réellement.
Les tâches liées à la sécurité, telles que l'analyse du code à la recherche de vulnérabilités, la proposition de correctifs et la réalisation de tests d'intrusion, ne font appel qu'à une petite partie de ce vivier d'experts. Mais la consommation de mémoire ne diminue pas en conséquence : chaque requête doit toujours charger le modèle dans son intégralité, qu'il soit pertinent ou non pour la tâche à accomplir.
Ajoutez désormais des agents à l'équation, et l'utilisation du contexte explose, ce qui sature la mémoire et conduit les agents à se disputer l'espace disponible. Chacun d'entre eux conserve un historique en temps réel de tout ce qu'il a vu et fait, et cet historique réside dans la mémoire du GPU aux côtés du modèle lui-même ; il ne cesse de grossir à mesure que l'enquête progresse et se multiplie pour chaque enquête exécutée en parallèle.
C’est pourquoi la taille du modèle a ici toute son importance : le modèle et l’ensemble de ce contexte en constante évolution puisent dans le même pool de mémoire fixe ; ainsi, plus l’un occupe de place, moins il en reste pour l’autre. L’objectif est de rendre le fonctionnement d’un modèle de pointe plus efficace pour une charge de travail spécifique, en préservant les capacités essentielles tout en libérant de la capacité pour tout ce qui s’exécute en parallèle.
Que pouvons-nous supprimer sans perdre ce qui compte vraiment ?
Le fardeau que représente l'intégration d'un si grand nombre d'experts dans un modèle peut être transformé en atout grâce à des techniques adaptées. Afin de réduire au minimum la taille des modèles à poids ouverts dans un contexte de sécurité basée sur des agents tout en conservant une grande précision, nous avons eu recours à la quantification et à l'élagage.
L'élagage des experts consiste à supprimer certains experts du modèle, généralement en supprimant des blocs entiers de poids d'experts et en ajustant le modèle de sorte que chaque token ne puisse choisir que parmi ceux qui restent. La suppression en elle-même est un processus mécanique. Le plus difficile est de déterminer quels experts supprimer, et la perte peut être inégale : un modèle plus petit peut conserver de solides performances de codage tout en perdant une grande partie de sa capacité à comprendre une langue naturelle particulière. Il peut alors se retrouver incapable d’interpréter de manière fiable la documentation, les règles métier ou les fonctionnalités de l’application décrites dans cette langue.
Pour déterminer les éléments à conserver, nous sommes partis des données les plus brutes : les traces issues de notre infrastructure de tests d'intrusion exécutant des benchmarks internes. Celles-ci enregistrent le code, les appels d'outils et les réponses traités par les agents au cours d'un test d'intrusion complet, ce qui nous fournit des données représentatives pour orienter la sélection des experts. Aucune donnée client n'a jamais été impliquée.
Cette étape d'étalonnage nous fournit une base spécifique à la charge de travail pour la sélection des experts, sans qu'il soit nécessaire d'entraîner le modèle à acquérir de nouvelles compétences.
Les traces du harnais couvraient la charge de travail technique. Nous devions également préserver la compréhension linguistique : analyser une application implique de comprendre ses fonctionnalités, ses règles métier et les flux de travail prévus, même lorsque sa documentation ou son interface est en français, en néerlandais ou dans une autre langue. Nous avons donc ajouté du texte multilingue afin de préserver ces capacités lors du nettoyage des données.
Le choix est tout aussi important que la taille
Il existe de nombreuses techniques d’élagage visant à réduire l’empreinte des LLM ; nous avons donc décidé d’opter pour une technique permettant de préserver les performances pour nos cas d’utilisation : Cerebras REAP( Router-weighted Expert Activation Pruning). Nous avons utilisé le score de contribution de REAP avec une stratégie d’agrégation préservant le domaine, sélectionnée à l’issue d’expériences de fidélité. Le simple fait de compter la fréquence à laquelle un expert est sélectionné ne donne qu’une vision partielle de la situation. REAP estime sa contribution en utilisant à la fois la pondération du routeur et l’amplitude de la sortie de l’expert.
Nous examinons également les contributions au sein de différents groupes d’exemples. Sinon, une compétence importante pour une charge de travail moins courante risque de passer inaperçue dans une moyenne globale. Les compétences en cybersécurité, en programmation et en langues sont réparties entre différents experts ; il n’existe pas de groupe clairement identifié d’« experts en cybersécurité » à conserver ou à écarter.
Dans l'étude complémentaire sur la compression, les modèles comportant le même nombre d'experts présentaient des différences substantielles quant à la fidélité de leurs résultats par rapport au modèle de référence. La taille à elle seule ne déterminait pas quels modèles étaient conservés.
De 1,51 To à 328 Go
Nous avons obtenu une réduction totale de 78,2 % de la taille du modèle par rapport à GLM 5.3 en précision maximale, et une réduction de 32,8 % par rapport à GLM 5.3 avec une quantification AWQ INT4. Altar conserve 168 des 256 experts acheminés d’origine dans chaque couche d’experts de la structure principale, en supprimant 88, soit 34,4 % d’entre eux. Le routeur sélectionne toujours huit experts par token, mais désormais à partir d’un ensemble plus restreint.
L’autre partie de la réduction provient de la quantification. Les poids d’un modèle correspondent aux valeurs numériques qu’il apprend au cours de l’entraînement. La quantification consiste à stocker ces nombres en utilisant moins de bits, ce qui permet de réduire la taille des poids stockés au détriment d’une partie de la précision. Contrairement à l’élagage, elle ne supprime pas les experts.
Notre point de départ utilisait AWQ pour stocker la plupart des poids d’expert en quatre bits au lieu des seize du modèle BF16. AWQ utilise des informations sur l’activité du modèle sur des exemples d’entrées pour limiter les erreurs introduites par une précision moindre. Les valeurs intermédiaires produites lors de l’inférence, appelées activations, restent en 16 bits : d’où W4A16, c’est-à-dire des poids en quatre bits et des activations en 16 bits. Certains poids conservent également une précision plus élevée. Nous avons ensuite appliqué un élagage à ce point de contrôle déjà quantifié.
La comparaison des deux représentations parentales permet de mettre en évidence la contribution de chaque étape :
Cela représente 78,2 % d'espace de stockage en moins par rapport au modèle complet sur 16 bits. Par rapport au modèle parent déjà quantifié, l'élagage permet de gagner 160 Go supplémentaires, soit une réduction de 32,8%.
L'impact de la compression sur les capacités d'identification des vulnérabilités
Nous avons précédemment mis au point un benchmark CVE interne que nous utilisons pour évaluer la capacité d'un modèle à identifier des vulnérabilités complexes issues du monde réel à l'aide de notre harnais « analyse de code par IA » : 32 vulnérabilités connues réparties sur 30 dépôts, avec trois exécutions par cas.
Nous avons utilisé Altar pour tester ce système. Altar a affiché un taux moyen de détection de 60,4 % par test et a redétecté 23 des 32 vulnérabilités au moins une fois au cours des trois tests.
À titre de comparaison, le modèle GLM-5.3 AWQ quantifié a affiché un taux de rappel moyen de 61,5 % et a couvert les 23 mêmes vulnérabilités. Le modèle GLM-5.3 d'origine, en précision maximale, a affiché un taux de rappel moyen de 65,6 % et a couvert 25 vulnérabilités sur 32.
En d’autres termes, la réduction du point de contrôle déjà quantifié de 488 Go à 328 Go, soit une diminution de 32,8 % des poids stockés, s’est traduite par une baisse d’environ un point de pourcentage du rappel moyen par rapport à la référence AWQ, tout en conservant l’intégralité de la couverture des vulnérabilités. Par rapport au modèle parent d’origine, Altar a conservé 23 des 25 vulnérabilités couvertes, soit 92 %, avec une baisse de 5,2 points de pourcentage du rappel moyen. Cela représente 92 % de la couverture des vulnérabilités du modèle parent, obtenue avec 33 % d’espace de stockage en moins.
C'est exactement le compromis que nous recherchions : un modèle nettement plus compact tout en conservant la plupart des fonctionnalités de sécurité du modèle d'origine.
Nous présentons le taux de détection moyen par exécution séparément de la couverture sur trois exécutions : détecter une vulnérabilité une seule fois n'est pas la même chose que la détecter de manière systématique. Les exécutions terminées sans détection sont comptabilisées comme des « manquements » ; les exécutions incomplètes sont présentées séparément.
Cet indicateur mesure la redécouverte ciblée de vulnérabilités CVE au sein d'un pipeline qui utilise d'autres modèles pour les étapes adjacentes. Il ne mesure pas la découverte « à l'aveugle » sur l'ensemble d'une base de code, n'exécute pas d'exploits pour valider les résultats, ni n'évalue l'étape de proposition de correctifs. Ces limites distinguent ce benchmark du workflow plus large de tests d'intrusion que nous développons avec Altar afin de prendre en charge.
De plus, nous avons déployé Altar sur notre parc de machines « Aikido » dès la fin de ces évaluations. Peu après son déploiement, le logiciel a identifié une vulnérabilité valide de gravité critique lors d’un test d’intrusion en environnement de production chez un client.
{{cta}}
Et ensuite ?
L'idée sous-jacente est plus large : les systèmes de renseignement de sécurité souverains devraient fonctionner au sein même de tout environnement qu'ils protègent.
Altar n'est qu'un début. En matière de compression, nous explorons des formats à faible nombre de bits, tels que l'EXL3, qui pourraient nous permettre de conserver davantage d'experts, parallèlement à de nouvelles optimisations de la diffusion H200.
La prochaine étape consiste à aller au-delà de la compression pour passer à la phase d'entraînement : affiner les modèles pour les workflows de sécurité, améliorer l'utilisation des outils et le raisonnement à long terme, et mettre en place un pipeline d'auto-apprentissage s'appuyant sur nos benchmarks internes afin de guider et de façonner les futurs modèles.
Ces travaux porteront à la fois sur la recherche de vulnérabilités, l'analyse de code, la correction des failles et d'autres processus de sécurité défensive.
Aikido Labs a pour vocation de pousser encore plus loin cette réflexion : des modèles qui gagnent en efficacité au fil du temps sans pour autant perdre de vue la contrainte essentielle, à savoir que les responsables de la sécurité doivent pouvoir les exécuter intégralement au sein des environnements dont ils ont la charge de protéger.
Nous remercions Z.AI pour GLM-5.3, Cerebras pour REAP, cyanwiki pour le modèle quantifié et 0xSero pour le travail de compression. L'étude publique sur la fidélité, ainsi que les « keep plans » et la boîte à outils de « pruning », fournissent davantage de détails techniques, sans pour autant publier les conversations brutes des agents.
Les poids d’Altar sont disponibles au sein de l’organisation Aikido. Altar peut être déployé et mis en service facilement à l’aide d’un nœud 4-H200s et de la dernière version de vLLM. Téléchargez Altar pour obtenir la fiche du modèle, la licence, les paramètres de service et les instructions de déploiement.
Vous avez besoin d'aide pour le faire fonctionner dans votre propre environnement ? Contactez le service commercial pour discuter du déploiement d'Altar sur site.
Cette approche est en train de s'étendre à l'ensemble de la gamme de produits d'Aikido, notamment Aikido Attack (pentest IA), Code Security Audit et Deep PR Review.
