Il était une fois, à l’époque où les applications étaient simples, les réseaux lents et où tout le monde jurait que SOAP représentait l’avenir, la compression était une question de survie. On compressait parce que la bande passante coûtait cher, que l’espace de stockage était limité et que les utilisateurs appréciaient la rapidité des réponses. Des charges utiles plus légères permettaient une livraison plus rapide, des clients plus satisfaits et moins de factures surprises de la part de votre fournisseur cloud.
À l’époque, la compression était une noble pratique. Elle améliorait tout.
Mais l’ère de l’IA a un talent remarquable pour prendre nos certitudes confortables, les examiner à la lumière et révéler que le monde a tourné sans que nous nous en apercevions. Et cela n’est nulle part plus évident que dans notre façon d’envisager aujourd’hui la compression.
Traditionnellement, la compression visait à améliorer les performances. Puis, il s’agissait d’économiser de la bande passante. Et aujourd’hui ?
La compression, c’est éviter de se ruiner en coûts d’inférence.
Commençons par une évidence : oui, la bande passante coûte toujours de l’argent. Les frais de sortie des services cloud sont tristement célèbres, et les factures de transfert de données peuvent encore donner des palpitations. Mais soyons honnêtes : comparez le coût du transfert d’un mégaoctet sur le réseau à celui de la génération de 10 000 jetons par un grand modèle de langage (LLM) haut de gamme. Le premier n’est qu’un insignifiant écart d’arrondi sur la facture mensuelle. Le second vous vaut un message au ton sévère du service financier, qui vous demande pourquoi vous avez soudainement englouti le budget du troisième trimestre.
Dans le monde de l’IA, nous ne compressons pas pour réduire la taille des données. Chaque jeton généré constitue un acte de cognition, et la cognition coûte cher aux machines. Nous compressons donc pour qu’elles puissent y « réfléchir » à moindre coût« réfléchir. »
La nouvelle économie de la compression
Les LLM ont redéfini les goulets d’étranglement d’une manière qui semble presque irrespectueuse envers les trois dernières décennies d’ingénierie des systèmes. Autrefois, on optimisait les chemins réseau, réduisait au minimum la taille des charges utiles et précompressait les ressources afin que l’application ne mette pas six jours à se charger sur une connexion 3G.
Désormais, le composant le plus lent et le plus coûteux du système n’est plus du tout le réseau.
C’est le cerveau.
Chaque token produit par un LLM nécessite des cycles GPU, de la VRAM, de l’énergie, du temps de latence et de l’argent. Beaucoup d’argent, selon le modèle dont vous vous êtes entiché ce trimestre. Le coût de la génération de texte dépasse désormais largement celui de son transport, ce qui signifie que nous avons inversé la chaîne de valeur de la compression :
Nous compressons les données non pas pour en réduire la taille, mais pour réduire le nombre de pensées qu’une IA doit formuler.
Et honnêtement ? C’est une phrase très drôle, mais c’est aussi la réalité opérationnelle.
Où se trouve désormais la compression
À l’époque où nous parcourions les réseaux en montée dans les deux sens, la compression résidait à la périphérie du réseau, dans des équipements spécialisés. Elle a fini par être intégrée aux contrôleurs de mise à disposition d’applications et par prendre des noms tels que « minification » et « compression HTTP ». Pendant un temps, il s’agissait d’une fonctionnalité spécialisée. Aujourd’hui ? Elle fait tout simplement partie intégrante de la mise à disposition des applications.
Mais grâce à l’IA, nous assistons à l’émergence de nouvelles techniques de compression. Sans doute parce que nous n’avons pas le choix. Nous ne nous contentons plus de compresser du texte à l’aide d’algorithmes bien connus. Nous rayons désormais des mots à la manière d’un réviseur appliquant les normes du Chicago Manual of Style ou de l’Associated Press, armé d’un stylo rouge et bien décidé à faire ses preuves.
Compression des prompts
Voici le nouveau champion poids lourd. Réduisez le prompt pour alléger la facture. Les détails superflus ? Éliminés. Le contexte redondant ? Supprimé. Les instructions trop bavardes ? Taillées comme une haie envahissante. Plus le prompt est court, moins il consomme de tokens, et plus votre service des achats est satisfait.
Compression des sorties
« Soyez concis » est discrètement passé du statut de préférence rédactionnelle à celui de stratégie de maîtrise des coûts. Réponse courte = réponse bon marché. Réponse longue = quelqu’un paie pour toute cette verbosité.
Compression des embeddings
Ici, vous ne réduisez pas le nombre d’octets, mais la dimensionnalité, ce qui réduit l’empreinte mémoire, puis le coût de la recherche, et donc tout ce que votre base de données vectorielle vous facture discrètement minute après minute.
Compression de modèle
Élagage, quantification, distillation. À une autre époque, ces techniques n’étaient que des curiosités académiques. Aujourd’hui, elles n’ont qu’un seul objectif : réduire le coût d’exécution.
Et si, en plus, il s’exécute plus vite ? Formidable. S’il tient sur un GPU plus petit ? Miraculeux. Mais l’objectif est, et a toujours été, de réduire les ressources de calcul consommées.
La compression comme moyen de contrôle
Lorsque l’opération la plus coûteuse de votre système consiste à réfléchir, vous commencez à considérer la réflexion comme une ressource limitée. C’est l’exact opposé de tous les modèles de performance qu’on nous a enseignés. Le réseau ne coûte pas cher. Le stockage ne coûte pas cher. Le processeur ne coûte pas cher. La mémoire est suffisamment bon marché pour que nous fassions à peine semblant de la gérer désormais.
Mais l’inférence sur GPU ? C’est le nouvel or noir. Et oui, je déteste ce cliché, mais s’il convient à la situation, autant l’employer.
Et comme pour le pétrole, nous disposons désormais d’une économie mondiale vouée à en extraire efficacement jusqu’à la dernière goutte. La compression n’est plus un simple atout ; c’est un pilier de l’IA opérationnelle.
C’est ainsi que vous respectez votre budget, évoluez de manière responsable, évitez les dépassements accidentels de plusieurs millions de dollars liés aux tokens et empêchez les agents de réécrire Guerre et Paix parce que vous avez oublié de définir max_tokens.
Nous compressons désormais les données non pas parce que nos réseaux ne peuvent pas supporter la charge, mais parce que nos IA ne peuvent pas assumer la facture. L’avenir ne consiste pas à réduire la taille des données, mais à rendre la réflexion moins coûteuse.
La compression n’est plus au service du réseau. Elle est au service des comptes. Et si cela donne naissance à une comptabilité opérationnelle, ne soyez pas surpris. Moi, je ne le serai pas.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
Les paquets empoisonnés sont en train de tuer notre industrie
L’open source ne dispose pas d’un registre central recensant les paquets malveillants, alors même que l’IA et l’automatisation accélèrent les attaques contre la chaîne d’approvisionnement. L’écosystème a besoin d’un moyen fiable de signaler et de suivre les compromissions.
Top 10 des risques liés à la mise en production d’applications d’IA : manque de sécurité et de conformité réglementaire
L’IA étend la conformité au-delà de la sécurisation des chemins d’accès et des espaces de stockage pour englober la gouvernance du comportement à l’exécution — accès aux modèles, contexte de récupération, résultats et actions des agents —, de sorte que les contrôles doivent être rapprochés de l’inférence.
Top 10 de la livraison d’applications d’IA : politiques de livraison incompatibles
Les divergences de politiques deviennent des sources de pannes pour l’IA : des mécanismes de basculement, des délais d’expiration, des limites et des contrôles de sécurité incohérents entraînent des défaillances silencieuses, des résultats partiels et des résultats différents selon le point de terminaison.
Top 10 de la mise à disposition d’applications d’IA : orientation du trafic non optimisée
L’IA remet en cause les principes traditionnels de répartition du trafic : les backends ne sont pas interchangeables, les coûts varient et les agents multiplient les requêtes de manière imprévisible. Le routage doit donc tenir compte du modèle, de l’état des GPU et de la localisation des données.
Top 10 de la livraison d’applications d’IA : contrôles du trafic insuffisants
Les limites de débit et les mécanismes de régulation traditionnels ne tiennent pas compte de l’étendue réelle des répercussions. Les charges de travail d’IA se répartissent entre les modèles, les bases de données vectorielles et les services, provoquant des pics de latence, des défaillances en cascade et des nouvelles tentatives.
La gestion des fenêtres de contexte en IA n’a rien de magique. C’est une question d’architecture.
Découvrez pourquoi les créateurs d’applications d’IA doivent gérer le contexte, la mémoire et l’infrastructure, tout en faisant évoluer les processus de livraison et la sécurité afin d’éviter la dérive, la latence et les attaques par injection de prompts.