On a testé OpenZL, le modèle de compression de Meta : résultats et limitations
Allez, on se tasse !
Il y a trois semaines, Meta annonçait un nouveau modèle de compression en open source. Nous l’avons installé sur une de nos machines afin de tester ses possibilités sur différents types de fichiers, au-delà des tests de Meta. Nous avons découvert quelques limitations au passage.
Pour nos tests, nous utilisons une machine virtuelle avec Ubuntu Server 24.02 LTS (SSD dédié, 24 cœurs CPU et 56 Go de mémoire) sur notre serveur Dell PowerEdgeT630 avec Proxmox.
Installation d’OpenZL et premiers tours de piste
L’installation n’est vraiment pas compliquée et ne nécessite que trois lignes de code.
git clone https://github.com/facebook/openzl.git
cd openzl
makeLa première ligne va créer un répertoire openzl et y copier le contenu du dépôt GitHub d’OpenZL de Meta (Facebook). La deuxième ligne nous permet d’aller dans ce répertoire, la troisième de lancer la compilation d’OpenZL. C’est tout !
Le programme s’appelle « zli » et on peut l’appeler, dans notre cas, via cette commande : « /home/gathor/openzl-repo/cachedObjs/*/zli ». Par exemple, pour connaitre la version de l’algorithme : « /home/gathor/openzl-repo/cachedObjs/*/zli --version ». Pour simplifier, nous garderons simplement la commande zli pour la suite de cet article.
Le fonctionnement classique de zli est le suivant : « zli <command> [options] < args> ». Les commandes possibles sont compress, decompress, train, benchmark, etc. On peut aussi préciser un nom de fichier de sortie avec -o, un profil avec -p, etc. On peut utiliser « zli --help » pour avoir tous les détails.
Sur sao, OpenZL explose bien la concurrence
Premier test : vérifier les allégations de Meta sur le niveau de compression des données sao. Il faut d’abord récupérer le corpus silesia et ensuite extraire le fichier sao. Deux lignes de commandes plus tard, c’est fait.
Nous lançons dans la foulée trois tests de compression avec zli (profil sao), xz avec le niveau 9 de compression et zstd avec le niveau 3 (time permet de récupérer le temps nécessaire au traitement de la commande) pour répéter les tests de Meta.
curl -L -o silesia.zip http://sun.aei.polsl.pl/~sdeor/corpus/silesia.zip
python3 -c "import zipfile; zipfile.ZipFile('silesia.zip').extract('sao', '')"
time zli compress sao -o sao.ozl -p sao -f
time xz - 9 -k sao -f
time zstd - 3 -k sao -o sao.zst -fNous arrivons bien à un ratio de 2,06, exactement ce qu’annonce Meta. Même chose pour xz avec 1,64x et zstd avec 1,31x. xz est déjà à son niveau maximum de compression, mais pas zstd qui peut monter bien plus haut. Avec un niveau de 22, cela donne un ratio de compression de 1,45x (mais avec un temps de traitement beaucoup plus long), comme on peut le voir dans le graphique ci-dessous.
Passons maintenant aux tests maison !
Commentaires (7)
Le 28/10/2025 à 11h39
Mais cela vient aussi en contre partie que, potentiellement, la compression peut échouer. Un algo de compression qui peut échouer ainsi, cela n'inspire pas vraiment confiance pour l'automatisation (et je pense qu'Amazon ne viendra pas me contredire
@SébastienGavois as-tu regardé aussi le temps de décompression ? Et est-ce que le fichier décompressé est bien identique bit à bit au fichier qui a été compressé ? (je pense notamment aux CSV ^^).
Modifié le 28/10/2025 à 11h46
Edit : mais j’aurais certainement besoin de passer par un stockage en ram pour plus de précision et ne pas être SSD limited pour être certain des perfs.
Le 28/10/2025 à 11h48
Le 28/10/2025 à 12h02
- SAO est un catalogue d'étoiles réalisé par le Smithsonian Astrophysical Observatory en 1966
- Ce jeu de données est un des jeux utilisés par Silesia Corpus. C'est un corpus créé pour tester les algorithmes de compression sans perte. Les autres jeux sont par exemple l'exécutable de Mozilla 1.0, le code source de Samba 2.2.3, etc.
Le 28/10/2025 à 12h46
Le 28/10/2025 à 13h38
Le 28/10/2025 à 13h37
Silesia compression corpus qui mène à SAO Star Catalog
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?