AngelSlim : la compression de grands modèles vue comme une chaîne d'outils, pas comme un algorithme

Ce que le dépôt cherche à couvrir, et pour qui

AngelSlim ne se présente pas comme un quantifieur unique mais comme une boîte à outils de compression. La description du dépôt parle d'accessibilité, d'exhaustivité et d'efficacité, et l'historique des versions confirme cette ambition : quantification FP8, INT4, NVFP4, ternaire, distillation, décodage spéculatif, attention creuse. Le public visé est donc l'ingénieur qui doit réduire un modèle précis, pas celui qui veut un bouton unique. Les notes de version citent des modèles nommés : GLM-4.6, Qwen3-VL, Qwen3-Omni, DeepSeek-R1/V3, Kimi-K2, Hunyuan-MT-7B, FLUX, Seed-OSS. Cette liste indique une priorité donnée aux architectures récentes et aux modèles multimodaux, y compris audio et diffusion. Un utilisateur qui travaille sur un modèle absent de cette liste doit s'attendre à devoir écrire lui-même la configuration correspondante.

Une architecture en scripts, configs et kernels

D'après l'arborescence visible dans le README, le projet s'organise autour de répertoires `scripts/ptq`, `configs/flux`, `configs/seed_oss` et d'un dossier `docs/source/features`. Autrement dit : des configurations par modèle, des scripts d'exécution par algorithme, et une documentation rangée par fonctionnalité plutôt que par type d'utilisateur. Le flux de travail typique consiste à choisir une configuration existante, à l'adapter au modèle cible, puis à lancer un script de quantification. Les algorithmes ne vivent pas tous sur la branche principale : le README renvoie vers une branche `sherry/Sherry` pour l'algorithme de quantification 1,25 bit Sherry et vers une branche `tequila/TernaryQuant` pour TEQUILA. C'est un point de conception à connaître avant de cloner : ce que vous cherchez peut être sur une branche nommée, pas dans `main`.

Quantification : plusieurs familles d'algorithmes, pas une seule

Le dépôt distingue plusieurs approches. La quantification post-entraînement (PTQ) couvre FP8 statique, SmoothQuant pour Hy3, NVFP4 pour la série Qwen3, W4A8-FP8 pour DeepSeek et Kimi-K2. La quantification consciente de l'entraînement (QAT) apparaît à travers DAQ, décrit comme préservant les connaissances acquises lorsque la mise à jour des paramètres reste faible après l'entraînement. Sherry est présenté comme un algorithme de quantification 1,25 bit efficace sur le plan matériel, et TEQUILA comme ternaire. Ces familles ne s'échangent pas librement : elles ont leurs propres scripts et leurs propres hypothèses sur le format de sortie. La conséquence pratique est qu'un changement de modèle peut vous faire changer de famille d'algorithme, sans chemin de migration documenté entre les deux.

Distillation et décodage spéculatif : deux chaînes distinctes

La distillation est prise en charge pour les modèles HuggingFace en pleine précision et pour les modèles de type QAT quantifiés, selon la documentation de distillation. Une note du 20 juillet 2026 ajoute une distillation consciente de la quantification, en échelle seule, sur Megatron-Core pour Qwen3-MoE et Hy3, avec entraînement distribué TP/EP/CP/SP. Le décodage spéculatif forme une seconde chaîne : Eagle3 pour les LLM, VLM et modèles audio, DFlare pour la diffusion par blocs avec fusion couche par couche, D-Cut pour l'élagage adaptatif de la profondeur de vérification. Le README annonce aussi AngelSpec, framework d'entraînement de décodage spéculatif désagrégé, avec des poids de drafters pour Hy3-A21B. Ces deux chaînes n'ont pas la même dépendance matérielle : la distillation sur Megatron-Core suppose une pile d'entraînement distribué, alors que la quantification PTQ se contente d'une inférence pour produire les poids.

Mise en route : ce que le matériel permet réellement de construire

Les commandes exactes ne figurent pas dans le README fourni, qui renvoie à la documentation en ligne et à des fichiers de configuration nommés. On peut en revanche décrire les points d'entrée confirmés : `scripts/ptq` pour la quantification post-entraînement, `configs/flux` et `configs/seed_oss` pour des modèles précis, `docs/source/features/qad/mcore_qad.md` pour la distillation consciente de la quantification sur Megatron-Core, et `docs/source/features/sparse_attention/stem.html` pour l'attention creuse Stem. Le guide de déploiement `docs/source/_extra/hy4_preview_gguf_guideline.md` accompagne le modèle hy4 preview MIX-STQ1_0 au format GGUF. Toute personne qui planifie une adoption doit partir de ces chemins, pas d'un exemple générique, car chaque fonctionnalité a sa propre page et ses propres prérequis.

Là où la boîte à outils montre ses limites

Le cas le plus révélateur est celui de hy4 preview : le README indique une compression de 1,5 To à 214 Gio, une baisse annoncée de 0,7 % sur SWE-bench Pro, et une exécution sur un portable équipé d'un 4090 plus un serveur à quatre A4000, à 1,02 token par seconde. Ces chiffres viennent du projet lui-même et décrivent un scénario de déploiement très contraint : un débit d'un token par seconde n'est pas utilisable en production interactive. AngelSlim est donc le mauvais outil si vous cherchez une quantification transparente pour un service à faible latence sans accepter de mesurer le débit vous-même. Autre limite : la licence. L'outil d'analyse du dépôt renvoie NOASSERTION, ce qui signifie qu'aucun identifiant de licence standard n'a été détecté. Avant tout usage commercial, il faut lire le fichier de licence à la racine, et non se fier à cette étiquette.

Face à un quantifieur généraliste

La différence avec un outil comme llama.cpp ne tient pas à la qualité mais à la finalité. llama.cpp vise l'inférence sur poids quantifiés, avec un format unique et un moteur d'exécution. AngelSlim se place en amont : il produit les poids, entraîne des drafters, distille des modèles, et laisse l'exécution à d'autres, ce que confirme la mention de Prima.cpp pour faire tourner le modèle hy4 et la contribution STQ1_0 sous forme de PR vers llama.cpp. Si votre besoin est d'exécuter un modèle déjà quantifié, AngelSlim n'est pas l'outil. Si votre besoin est de produire une variante 2 bits ou 1,25 bit d'un modèle précis et d'en mesurer la perte, la couverture du dépôt est plus large que celle d'un quantifieur unique.

Coût de maintenance et rythme de publication

Le rythme des notes de version est élevé : v0.2.0 en novembre 2025, v0.3.0 en janvier 2026, v0.5.0 en juin 2026, avec des annonces intermédiaires presque mensuelles. Chaque annonce ajoute des modèles ou des algorithmes, ce qui implique que les configurations existantes peuvent devenir obsolètes sans dépréciation formelle. Pour une équipe, le coût réel n'est pas l'installation mais le suivi : vérifier à chaque mise à jour si la configuration de votre modèle a changé, et si l'algorithme utilisé est toujours sur la branche principale. La présence de fonctionnalités sur des branches séparées, comme `sherry/Sherry` et `tequila/TernaryQuant`, ajoute une étape de vérification avant toute intégration dans un pipeline interne.

Conclusion éditoriale

AngelSlim convient aux équipes qui doivent quantifier ou distiller des modèles récents (Qwen3, Hy3, DeepSeek, FLUX) et qui acceptent de lire la documentation par fonctionnalité plutôt que de suivre un tutoriel unique. Il ne convient pas à qui cherche une API stable et versionnée : la licence n'est pas identifiée par l'outil d'analyse du dépôt et les algorithmes arrivent parfois sur une branche séparée avant d'être fusionnés. Avant d'adopter, vérifier la page de la fonctionnalité visée dans la documentation, puis contrôler le fichier de licence à la racine du dépôt.

Sources officielles

1. Issues
2. Project website
3. README
4. Releases
5. Tencent/AngelSlim on GitHub