NNCF : quantifier et élaguer un modèle avant de le confier à OpenVINO

Le problème : un modèle entraîné n'est pas un modèle déployable

Un modèle PyTorch ou ONNX qui atteint la précision voulue en recherche coûte souvent trop cher en mémoire et en latence pour la machine qui doit l'exécuter. NNCF vise cet écart. La bibliothèque fournit des algorithmes de compression qui transforment le graphe du modèle pour obtenir une version plus légère, avec une perte de précision que la documentation présente comme minimale. Le public visé est précis : des ingénieurs qui déploient via OpenVINO et qui travaillent sur PyTorch, TorchFX ou ONNX en amont. Le README décrit NNCF comme un paquet Python utilisable en mode autonome, avec une architecture unifiée pour ajouter des algorithmes de compression. Cette phrase dit quelque chose d'important : le projet se pense comme un cadre extensible, pas comme un script unique. Le catalogue d'algorithmes est séparé en deux familles. D'un côté la compression post-entraînement, applicable sans réentraîner le modèle : quantisation, compression des poids, et une parcimonie d'activations marquée expérimentale. De l'autre la compression à l'entraînement, réservée à PyTorch : quantisation aware training, une variante poids seuls avec LoRA, et l'élagage.

Deux régimes de compression qui ne s'adressent pas au même budget

La distinction entre post-entraînement et entraînement n'est pas cosmétique. Le README indique que la quantisation post-entraînement ne demande que le modèle et un petit jeu de calibration d'environ 300 échantillons. C'est le chemin court : on collecte des statistiques sur quelques lots, on transforme le graphe, on exporte. Aucune boucle d'apprentissage. La compression à l'entraînement suppose l'inverse : il faut réentraîner, ce qui implique du temps GPU, un jeu de données complet et une boucle d'optimisation à maintenir. Le README mentionne à ce titre des couches accélérées par GPU pour affiner plus vite les modèles compressés et un support de l'entraînement distribué. Ces deux éléments n'ont de sens que dans le régime long. Le tableau de compatibilité mérite d'être lu avant de choisir : la quantisation post-entraînement est marquée Supported sur OpenVINO, PyTorch et ONNX, mais Experimental sur TorchFX. La compression des poids suit exactement le même schéma. La parcimonie d'activations, elle, est Not supported partout sauf en PyTorch, où elle reste Experimental. Côté entraînement, les trois algorithmes listés sont Supported en PyTorch, et le tableau ne mentionne aucun autre framework.

Mise en route : trois étapes et un jeu de calibration

L'installation se fait depuis PyPI, le badge du README pointant vers le paquet nncf. L'exemple OpenVINO du README tient en trois étapes explicites. On charge d'abord le modèle non compressé avec ov.Core().read_model("/model_path"). On prépare ensuite un DataLoader torch.utils.data avec une transformation ToTensor, puis on définit une fonction transform_fn qui extrait le tenseur d'images de chaque élément. Cette fonction est passée à nncf.Dataset avec le DataLoader, ce qui produit l'objet de calibration. La compression elle-même tient en un appel : nncf.quantize(model, calibration_dataset). La variante PyTorch est identique à un détail près : le modèle vient de torchvision, par exemple models.mobilenet_v2(), et nncf.quantize s'applique au module PyTorch plutôt qu'à un modèle OpenVINO. Le README précise qu'OpenVINO est le backend préféré pour la quantisation post-entraînement, PyTorch et ONNX restant pris en charge. Le format de sortie dépend donc du point de départ : le README évoque l'export de modèles PyTorch compressés vers des checkpoints ONNX, et vers SavedModel ou Frozen Graph, prêts pour la boîte à outils OpenVINO. Autrement dit, la chaîne typique part d'un modèle d'entraînement et se termine dans un format que le runtime OpenVINO consomme.

Quand la quantisation post-entraînement ne suffit plus

Le README est explicite sur le point de rupture : si l'algorithme de quantisation post-entraînement ne satisfait pas les exigences de qualité, il faut affiner le modèle PyTorch quantisé. Le projet renvoie vers un exemple de pipeline de quantisation aware training pour un ResNet18. C'est la limite pratique la plus fréquente, et elle est structurelle. Une calibration sur environ 300 échantillons capture la distribution des activations sur ces échantillons, pas sur l'ensemble des cas que le modèle rencontrera en production. Sur des architectures sensibles, ou sur des domaines où la distribution de déploiement s'éloigne de la calibration, l'écart de précision peut devenir inacceptable, et le seul recours documenté est de passer au régime long, donc de réentraîner. Le coût change de nature à ce moment-là : on ne parle plus de quelques minutes de collecte de statistiques mais d'un cycle d'affinage complet. Autre limite, plus discrète : les algorithmes d'entraînement ne sont documentés que pour PyTorch. Un utilisateur TensorFlow, dont le topic du dépôt mentionne pourtant le support, ne trouvera dans les tableaux du README aucune ligne d'entraînement correspondante. La compression post-entraînement reste accessible via ONNX, mais l'élagage et la quantisation aware training non.

Ce que NNCF n'est pas : un compresseur agnostique du runtime

Il faut résister à une lecture trop large du nom. NNCF n'est pas un outil de compression qui produit un artefact neutre, utilisable ensuite partout. Le titre du projet le dit : Neural Network Compression Framework for enhanced OpenVINO inference. Les algorithmes sont conçus pour optimiser l'inférence dans OpenVINO, et le README recommande explicitement ce backend pour la quantisation post-entraînement. L'export vers ONNX ou vers SavedModel existe, mais il est présenté comme une conversion de sortie, pas comme un mode d'emploi principal. Si votre cible d'exécution est un autre runtime, vous vous retrouvez à utiliser une bibliothèque dont le chemin recommandé ne correspond pas à votre cible, avec les risques de conversion que cela suppose. La comparaison la plus utile est avec les outils de quantification intégrés à un framework d'entraînement, du type de ceux exposés par PyTorch lui-même. Ceux-ci restent dans l'écosystème du framework, sans étape de conversion vers un format intermédiaire. NNCF ajoute une couche de transformation de graphe et une interface commune entre algorithmes, ce qui a un sens quand la destination finale est OpenVINO. Pour un déploiement qui reste en PyTorch pur, cette couche supplémentaire n'apporte rien et ajoute une dépendance.

Maintenance, rythme de publication et licence

Le dépôt est actif : la branche par défaut est develop, le dernier push indiqué date du 9 septembre 2026, et trois versions sont sorties en 2026, v3.1.0 en avril, v3.2.0 en juin, v3.3.0 en août. Ce rythme, environ une version tous les deux mois, implique une chose concrète pour un utilisateur : les API peuvent bouger entre deux versions mineures, et un pipeline figé sur une version ancienne devra être retesté lors d'une montée de version. Le README signale lui-même que certaines fonctionnalités sont marquées Experimental, notamment la quantisation sur TorchFX et la parcimonie d'activations en PyTorch. Une API expérimentale est par définition plus exposée au changement. Pour l'intégration, le projet fournit un patch Git destiné à huggingface-transformers, qui montre comment greffer NNCF dans un pipeline d'entraînement existant plutôt que de réécrire la boucle. La licence est Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et de l'avis de licence. Le README ne détaille pas de politique de support à long terme pour les versions publiées, et il vaut mieux le constater que de le supposer.

Conclusion éditoriale

Adoptez NNCF si votre cible d'inférence est OpenVINO et que vous acceptez une calibration sur quelques centaines d'échantillons : la quantisation post-entraînement s'écrit en trois appels. Passez votre chemin si votre runtime final n'est pas OpenVINO, car l'export vers ONNX est présenté comme une étape de conversion, pas comme le chemin principal. Avant de vous engager, vérifiez deux choses concrètes : que votre modèle figure dans la liste des architectures testées du Model Zoo, et que la précision après nncf.quantize reste dans votre budget sur votre propre jeu de validation. Le reste se décide sur votre matériel.

Sources officielles

1. Issues
2. License: Apache-2.0
3. openvinotoolkit/nncf on GitHub
4. README
5. Releases