Quant Recipe Search

Utilise cette skill quand la quantification est une recherche itérative de recette, pas une exécution PTQ unique. La skill maîtrise la stratégie : définir le succès, choisir l'espace de recherche, séquencer les candidats et décider de l'itération suivante. Elle délègue la génération de checkpoint, le déploiement, l'évaluation, la surveillance et la comparaison de métriques aux skills d'exécution existantes.

Traite une demande directe telle que « trouve la meilleure recette de quantification et génère un checkpoint PTQ pour ce modèle » comme suffisante pour commencer. Récupère d'abord l'état local, puis demande uniquement les décisions manquantes qui modifient la recherche.

Skill Boundaries

• Utilise ptq pour produire et valider les checkpoints.
• Utilise deployment pour servir les checkpoints et déboguer les flags spécifiques au déploiement.
• Utilise evaluation pour créer des configs NEL et soumettre des evals.
• Utilise launching-evals pour exécuter, reprendre, déboguer et analyser les exécutions NEL.
• Utilise monitor pour le suivi actif des tâches.
• Utilise accessing-mlflow pour les recherches d'artefacts MLflow.
• Utilise compare-results pour les deltas baseline-vs-candidate validés et la comparabilité des champs de score.

Ne duplique pas ces workflows ici. Cette skill doit laisser l'utilisateur avec un portefeuille de recettes clair, une métrique de succès, une séquence d'expériences et une prochaine décision.

Problem

La tâche est de trouver la meilleure recette pour une cible définie par l'utilisateur, pas simplement de produire un checkpoint quantifié. Un checkpoint PTQ généré n'est qu'un candidat. Il devient une recette recommandée seulement après évaluation et comparaison par rapport à la baseline correspondante.

Entrées requises avant la planification des candidats :

• Objectif d'optimisation : calcul/débit, mémoire/latence, ou une métrique personnalisée.
• Famille de quantification principale : par exemple NVFP4, W4A16 NVFP4, FP8/W8A8, INT4/AWQ, ou un ensemble mixte personnalisé.
• Ensemble de benchmark ou résultats de baseline : la surface d'acceptation définie par l'utilisateur.

Si l'une de ces éléments manque, demande-la. Ne définis pas silencieusement FP8/W8A8 par défaut ni n'appelle un checkpoint « meilleur » avant l'évaluation.

Règle de succès par défaut : maximiser l'objectif de performance choisi tout en gardant chaque benchmark à moins d'1 point de pourcentage de la baseline BF16/FP16 correspondante. Les régressions proches du seuil ou bruyantes nécessitent des réexécutions avant de prendre une décision.

Search Space

Garde l'espace de recherche explicite. Une recette candidate est un tuple sur ces axes :

• Format numérique : FP8/W8A8, NVFP4/W4A4, W4A16 NVFP4, INT4/AWQ, ou formats mixtes tels que NVFP4+FP8.
• Algorithme de calibration/recherche : calibration max, calibration MSE, GPTQ, AWQ, notation AutoQuant, et variantes de dataset de calibration ou de nombre d'échantillons.
• Méthode de sélection : règles manuelles/heuristiques, recettes manuelles guidées par la sensibilité, sélection AutoQuant, ou un hybride d'AutoQuant plus remplacements manuels.
• Famille de modules : attention, MLP, experts MoE, routeurs/gates, embeddings, lm_head, adaptateurs, encodeurs visuels, et modules spécifiques au modèle.
• Contraintes de fusion runtime : les modules fusionnés par la bibliothèque d'inférence doivent utiliser une quantification compatible. Exemples : vLLM Qwen linear_attn.in_proj_qkvz et projections d'experts MoE fusionnées telles que gate/up (w1/w3).
• Budget de calibration : mix de dataset, nombre d'échantillons, longueur de séquence et paramètres de batch.

Ne réduis pas la recherche à une seule dimension telle que le format numérique uniquement. Lis references/recipe_iteration.md quand tu choisis des axes ou des candidats concrets.

Design Workflow

1. Récupère l'état

   • Lis les tables de résultats, les logs de recette, les états AutoQuant, les rapports de sensibilité et les notes d'expérience avant de proposer un nouveau travail.
   • Demande à monitor, launching-evals ou compare-results de récupérer l'état des tâches actives et les métriques complétées quand nécessaire.

2. Définis la cible

   • Confirme l'objectif d'optimisation, la famille de quantification principale, l'ensemble de benchmark, le seuil de perte de précision, le budget de calibration et la métrique de coût.
   • Inclus les métadonnées de quantification telles que le stockage de l'échelle dans le coût actif ou les estimations de taille.

3. Choisis les baselines et les premiers candidats

   • Inclus toujours BF16/FP16 et une baseline FP8/W8A8 quasi sans perte, sauf si FP8 est la cible.
   • Pour le travail ModelOpt, pars de modelopt_recipes : recettes spécifiques au modèle d'abord, puis présets PTQ généraux ou fragments de recette.
   • Ajoute un candidat AutoQuant dans la famille principale demandée quand AutoQuant est disponible. Attends-toi à ce qu'AutoQuant trouve un meilleur compromis qu'une première recette manuelle, mais valide cette hypothèse avec les mêmes evals.
   • Ajoute au moins un candidat manuel ou guidé par la sensibilité pour pouvoir comparer AutoQuant contre des ablations contrôlées et avoir un secours si AutoQuant rate la meilleure frontière ou frappe des contraintes runtime.

4. Génère les candidats

   • Délègue la génération de checkpoint et la validation PTQ à ptq.
   • Change un axe majeur à la fois : format, algorithme de calibration, sélection de modules, granularité, exclusions, ou données de calibration.
   • Utilise AutoQuant pour la génération large de candidats et les rapports de sensibilité ; utilise les recettes manuelles pour les ablations contrôlées des familles de modules et les remplacements.

5. Porte avant de passer à l'échelle

   • Valide la couverture et les métadonnées du checkpoint.
   • Rejette ou réécris les recettes qui mélangent les algorithmes de quantification à l'intérieur d'un groupe runtime fusionné.
   • Si le checkpoint est valide mais que le déploiement échoue à cause du support runtime, ne rejette pas la recette immédiatement. Délègue à deployment / debug pour les petits patches ou flags, puis réexécute une vérification clean-pipe.

Iteration Loop

1. Exécute des evals de dépistage bon marché pour chaque candidat qui passe les gates.
2. Compare la précision, la verbosité/utilisation de tokens et le coût actif par rapport aux baselines.
3. Réexécute les résultats bruyants ou proches du seuil avant d'étiqueter une régression.
4. Décide du candidat suivant :
   • Chute de précision : protège ou ablate les familles de modules sensibles, essaie MSE/GPTQ, ou utilise la sensibilité AutoQuant pour choisir les remplacements.
   • Mauvaise performance/coût : quantifie la prochaine famille active à coût élevé, ajuste l'objectif de coût actif, ou essaie un format plus agressif.
   • AutoQuant sous-performe les recettes manuelles : inspecte les rapports de sensibilité, les bits réalisés, les modules exclus et les contraintes de fusion runtime ; garde la recette manuelle dans le portefeuille au lieu de forcer le résultat AutoQuant.
   • Incompatibilité runtime : réécris autour des groupes fusionnés ou isole le support de déploiement de la qualité du checkpoint.
   • Recettes AutoQuant répétées : inspecte les bits réalisés et les hashes de recette, puis ajuste les contraintes avant de lancer un balayage plus large.
5. Promeut seulement quand compare-results montre que le candidat est comparable à la baseline et satisfait l'objectif défini par l'utilisateur.

Maintiens un tableau de portefeuille de recettes avec le nom de la recette, l'objectif, l'estimation du coût actif, les notes de calibration, le chemin du checkpoint, les références eval/log, la précision, la verbosité et la décision.

References

• Pour la conception de recettes, les détails de l'espace de recherche, la sensibilité et la comptabilité du coût actif, lis references/recipe_iteration.md.
• Pour une étude de cas concrète antérieure, lis references/qwen36_case_study.md uniquement quand les détails Qwen3.5/Qwen3.6 sont pertinents.