Pruna : orchestrer plusieurs algorithmes de compression sur un même modèle

Le problème : cinq techniques de compression, cinq intégrations à maintenir

Un modèle entraîné qui coûte trop cher en inférence peut être accéléré de plusieurs façons. On peut mettre en cache des résultats intermédiaires, quantifier les poids, élaguer des couches, distiller un modèle plus petit ou compiler pour un matériel donné. Chacune de ces techniques vient d'une bibliothèque différente, avec sa propre API, ses propres contraintes de version et son propre format de sauvegarde. Pruna part de ce constat et propose une couche unique au-dessus de ces familles d'algorithmes. Le README les regroupe sous cinq catégories : caching, quantification, élagage, distillation et compilation. Le public visé est donc l'ingénieur qui a déjà un modèle qui tourne, pas le chercheur qui part d'une architecture vide. La documentation annonce la prise en charge des LLM, des modèles de diffusion et de flow matching, des Vision Transformers et des modèles de reconnaissance vocale. Cette largeur de cible a un revers : un lecteur qui travaille sur un modèle exotique doit vérifier lui-même que son cas est couvert.

smash et SmashConfig : une liste de noms passée en argument

Le mécanisme central tient en deux objets. SmashConfig reçoit une liste de chaînes de caractères, par exemple ["deepcache", "stable_fast"], et smash applique ces algorithmes au modèle passé en argument. La fonction retourne un modèle transformé, que le README présente comme utilisable de la même manière que l'original : l'appel smashed_model("An image of a cute prune.").images[0] renvoie une image. Autrement dit, Pruna ne remplace pas l'objet modèle par une abstraction maison, il le modifie. C'est un choix d'architecture qui simplifie l'intégration dans du code existant, mais qui déplace la difficulté ailleurs : l'ordre et la compatibilité des algorithmes listés dans SmashConfig deviennent la responsabilité de l'appelant. Le README ne décrit pas de mécanisme de résolution de conflits entre deux algorithmes incompatibles. La documentation en ligne est présentée comme la référence pour la liste complète des algorithmes, ce qui suggère que cette liste évolue plus vite que le README. Un tableau récapitule d'ailleurs l'effet attendu de chaque technique sur trois axes : vitesse, mémoire et qualité. Pour batcher, le tableau indique un gain de vitesse, pas de gain mémoire, et un effet neutre sur la qualité. Ces colonnes sont une aide au choix, pas une garantie mesurée.

Installation et première exécution

Deux chemins sont documentés. Le plus court : pip install pruna. L'autre, pour suivre le dépôt : git clone https://github.com/PrunaAI/pruna.git, puis cd pruna, puis pip install -e .. Les prérequis annoncés sont Python 3.9 ou plus récent et, en option, le CUDA toolkit pour le support GPU. Le README précise que Pruna s'installe sur Linux, MacOS et Windows, mais que certains algorithmes imposent des restrictions de système d'exploitation et peuvent ne pas être disponibles partout. C'est la contrainte la plus concrète du projet : la promesse d'installation multiplateforme ne se traduit pas par une parité des algorithmes. Le README ne fournit pas de tableau associant chaque algorithme à ses plateformes supportées, il renvoie à la documentation. L'exemple d'évaluation, lui, est explicite : PrunaDataModule.from_string("LAION256"), puis datamodule.limit_datasets(10), puis Task("image_generation_quality", datamodule=datamodule) et EvaluationAgent(task).evaluate(smashed_model). Le limit_datasets(10) montre que l'évaluation est conçue pour tourner sur un petit échantillon avant un passage complet.

Ce que le tableau d'algorithmes ne dit pas

Le tableau du README attribue à chaque technique un effet sur la vitesse, la mémoire et la qualité, avec des symboles positifs, négatifs ou neutres. Il est tentant de le lire comme un menu. Il ne l'est pas. Deux algorithmes qui améliorent chacun la vitesse ne se cumulent pas forcément, et le tableau ne traite pas les interactions. Un cacher stocke des résultats intermédiaires pour accélérer les opérations suivantes, ce qui suppose des entrées répétées ou proches ; sur une charge de travail où chaque requête est unique, le gain attendu disparaît. Un batcher regroupe plusieurs entrées pour les traiter simultanément, ce qui suppose que l'appelant puisse attendre et que la mémoire disponible le permette : le tableau indique justement aucun gain mémoire pour cette technique. La compilation, décrite comme l'optimisation du modèle avec des instructions pour un matériel spécifique, lie le résultat à ce matériel. Un modèle compilé pour une cible ne se transporte pas nécessairement vers une autre. Aucun de ces points n'est un défaut caché, mais aucun n'est mis en avant dans le README, qui présente les techniques comme une suite d'options combinables.

Le coût de suivi entre v0.3.2 et v0.3.4

Trois versions sont listées sur la période récente : v0.3.2 le 9 mars 2026, v0.3.3 le 23 avril 2026 et v0.3.4 le 22 juin 2026, avec un dernier push sur main en septembre 2026. Le rythme est soutenu, environ une version tous les deux mois. Pour un utilisateur, cela signifie que l'API d'optimisation peut bouger plus vite que le cycle de mise en production de son propre service. L'exemple d'évaluation du README importe trois modules distincts, pruna.evaluation.task, pruna.evaluation.evaluation_agent et pruna.data.pruna_datamodule. Une réorganisation de ces chemins entre deux versions mineures casserait du code appelant sans changer de numéro majeur, puisque le projet reste en 0.x. La licence Apache-2.0 autorise l'usage commercial, la modification et la redistribution, avec conservation des mentions de copyright et du fichier de licence, et elle inclut une concession de brevet. Elle n'impose pas de publier vos propres modifications. Ce paragraphe décrit le texte de la licence, pas une analyse juridique : faites relire votre cas par un juriste si la redistribution fait partie de votre produit.

Quand Pruna n'est pas le bon outil

Pruna optimise des modèles déjà entraînés. Si votre problème est de réduire le coût d'entraînement, ou de choisir une architecture plus petite dès le départ, le cadre n'apporte rien : aucune des cinq familles listées ne porte sur la phase d'entraînement. Deuxième cas défavorable : une équipe qui n'a qu'une seule technique à appliquer. Si vous voulez uniquement quantifier un modèle, passer par une couche d'abstraction ajoute une dépendance et une surface d'API à suivre pour un seul appel. Troisième cas : un modèle qui n'entre dans aucune des catégories annoncées. Le README cite les LLM, les modèles de diffusion et de flow matching, les Vision Transformers et la reconnaissance vocale. En dehors de cette liste, rien n'indique que les algorithmes s'appliquent, et le README ne décrit pas de procédure d'extension pour ajouter un algorithme maison. Enfin, l'absence de tableau algorithme par plateforme dans le README rend l'évaluation préalable obligatoire : sur Windows ou MacOS, une combinaison qui fonctionne sur Linux peut échouer, et le projet ne s'engage pas sur ce point.

Face à une bibliothèque de quantification spécialisée

L'alternative la plus directe n'est pas un concurrent nommé, c'est l'assemblage manuel. Une bibliothèque de quantification dédiée fait une chose : remplacer les poids par une représentation de plus faible précision, avec ses propres formats de sauvegarde et ses propres noyaux d'inférence. Elle ne fait pas de caching, ne distille pas, ne compile pas. La différence d'approche est nette. L'outil spécialisé optimise une seule dimension et laisse l'utilisateur responsable du reste du pipeline. Pruna prend le modèle entier et applique une liste d'algorithmes dans un seul appel, ce qui réduit le nombre d'intégrations à écrire mais ajoute une couche dont le comportement dépend de la combinaison choisie. Le compromis se joue sur la prévisibilité : avec un outil unique, vous savez ce qui se passe dans le modèle ; avec Pruna, vous devez évaluer le résultat après coup. C'est précisément pourquoi l'interface d'évaluation est fournie dans le même paquet, avec Task et EvaluationAgent. Si vous n'avez pas l'intention de mesurer la qualité après optimisation, la combinaison d'algorithmes devient un pari.

Conclusion éditoriale

Pruna convient aux équipes qui ont déjà un modèle entraîné et un jeu d'évaluation interne, et qui veulent comparer plusieurs combinaisons de compression sans réécrire leur pipeline d'inférence. Il ne convient pas à celles qui cherchent un entraînement distribué ou un service d'inférence clé en main : le projet reste une bibliothèque d'optimisation, pas une plateforme. Avant d'adopter, vérifiez sur votre matériel la disponibilité de chaque algorithme listé dans SmashConfig, puis fixez la version dans requirements.txt, car l'API a changé entre v0.3.2 et v0.3.4.

Sources officielles

1. License: Apache-2.0
2. Project website
3. PrunaAI/pruna on GitHub
4. README
5. Releases