Dernière révision : juin 2026
Une référence concise des modèles d'architecture évalués par l'examen NCP-GENL. Lisez de haut en bas ou sautez à une section.
Besoin d'une latence réduite sur H100/Blackwell sans l'impact sur la précision d'une quantization INT agressive.
Utiliser la quantization FP8 (E4M3) via TensorRT-LLM ; Hopper et Blackwell disposent de Tensor Cores FP8 natifs.
Pourquoi: FP8 préserve mieux la plage dynamique que INT8 et fonctionne à pleine vitesse matérielle sur Hopper+, offrant une qualité proche de FP16 avec un débit de classe INT8.
Le modèle tient à peine dans la mémoire GPU et le débit est limité par la bande passante mémoire.
Appliquer la quantization INT4 poids-seulement (AWQ ou GPTQ) ; maintenir les activations en FP16/FP8.
Pourquoi: INT4 poids-seulement réduit environ de moitié la mémoire par rapport à INT8 et soulage la pression sur la bande passante ; la précision d'activation reste élevée, donc la perte de précision est minime.
Décider entre la quantization post-entraînement et l'entraînement conscient de la quantization.
Commencer par la PTQ (calibrer sur un échantillon représentatif) ; ne recourir à la QAT que si la perte de précision de la PTQ dépasse le budget.
Pourquoi: La PTQ est rapide et ne nécessite pas de réentraînement ; la QAT récupère la précision mais coûte un cycle d'entraînement, il faut donc la réserver aux modèles critiques en précision.
Inférence à long contexte où le cache KV domine la mémoire et limite la taille du lot.
Activer la quantization du cache KV en FP8 ou INT8 dans TensorRT-LLM.
Pourquoi: Le cache KV augmente avec la longueur de séquence × lot ; sa quantization libère de la mémoire pour des lots plus grands et des contextes plus longs avec un impact minimal sur la qualité.
Des longueurs de requête mixtes entraînent un temps d'inactivité du GPU avec le batching statique.
Utiliser le batching en vol (continu) dans TensorRT-LLM afin que les séquences terminées soient évincées et que de nouvelles rejoignent le processus en cours.
Pourquoi: Le batching continu maintient le GPU saturé et augmente le débit bien au-delà du batching statique pour les flux de requêtes hétérogènes.
Un grand modèle "enseignant" répond aux exigences de qualité mais pas aux objectifs de latence et de coût.
Distinguer vers un modèle "étudiant" plus petit, puis quantizer l'étudiant pour l'inférence.
Pourquoi: La distillation transfère les capacités à une architecture moins coûteuse ; combinée à la quantization, elle augmente les économies de coût/latence.
La latence en flux unique est trop élevée pour un cas d'utilisation interactif.
Appliquer le décodage spéculatif avec un petit modèle "brouillon" vérifié par le modèle cible.
Pourquoi: Le brouillon propose plusieurs tokens que le grand modèle vérifie en un seul passage, réduisant la latence réelle sans modifier la distribution de sortie.
Quantizer tout en INT4 dégrade la précision sur quelques couches sensibles.
Utiliser la précision mixte : maintenir les couches sensibles (par exemple, projection finale, attention) avec une précision plus élevée et quantizer le reste.
Pourquoi: La sensibilité par couche varie ; la précision sélective protège la précision là où c'est important tout en réduisant la majeure partie des poids.
La précision de la PTQ est médiocre malgré un schéma de quantization raisonnable.
Recalibrer avec un échantillon de la distribution (des centaines de prompts représentatifs) correspondant au trafic de production.
Pourquoi: La calibration définit les plages d'activation ; un échantillon non représentatif produit de mauvaises échelles et une perte de précision évitable.
Les poids du modèle dépassent la capacité d'un seul GPU mais tiennent dans un nœud connecté par NVLink.
Utiliser le parallélisme de tenseur sur les GPU du nœud.
Pourquoi: Le parallélisme de tenseur fragmente chaque couche et échange les activations à chaque étape, il nécessite donc la bande passante intra-nœud élevée de NVLink/NVSwitch.
Le modèle est trop grand pour un seul nœud et doit s'étendre sur plusieurs nœuds via InfiniBand.
Ajouter du parallélisme de pipeline entre les nœuds, en conservant le parallélisme de tenseur au sein de chaque nœud.
Pourquoi: Le parallélisme de pipeline communique uniquement aux limites des étapes, tolérant des liens inter-nœuds plus lents ; réserver le parallélisme de tenseur gourmand en bande passante pour NVLink.
La mise à l'échelle vers plus de GPU donne des gains de débit décroissants.
Profiler avec Nsight Systems pour classer le goulot d'étranglement ; si les collectifs dominent, réduire le degré de parallélisme ou améliorer la topologie.
Pourquoi: Au-delà d'un certain point, le surcoût de all-reduce/all-gather l'emporte sur le calcul ajouté ; diagnostiquer si la limite est la communication ou le calcul guide la solution.
Le surcoût de lancement de noyau à chaque étape augmente la latence de décodage pour les petites tailles de lot.
Activer les CUDA Graphs pour capturer et rejouer la boucle de décodage.
Pourquoi: Les CUDA Graphs regroupent de nombreux petits lancements en une seule relecture, supprimant le surcoût de lancement côté CPU qui domine pour les petites tailles de lot.
Des rangs de parallélisme de tenseur placés sur un lien lent entraînent des blocages.
Assigner les rangs de parallélisme de tenseur aux GPU partageant NVLink/NVSwitch ; placer les étapes de pipeline entre les nœuds.
Pourquoi: Un placement mal adapté achemine les collectifs haute fréquence via PCIe ou InfiniBand, étranglant l'ensemble du pipeline.
L'attention est limitée par la mémoire et restreint la longueur de contexte réalisable.
Utiliser FlashAttention (noyaux d'attention fusionnés et conscients des E/S) tels que fournis par la pile TensorRT-LLM/NeMo.
Pourquoi: FlashAttention évite de matérialiser la matrice d'attention complète, réduisant le trafic mémoire et permettant des séquences plus longues à une vitesse supérieure.
Plusieurs petits modèles sous-utilisent les GPU H100 complets.
Partitionner les GPU avec MIG (Multi-Instance GPU) pour isoler chaque modèle sur une tranche.
Pourquoi: MIG offre des partitions isolées au niveau matériel, augmentant l'utilisation et fournissant une QoS prévisible pour les petites charges de travail colocalisées.
Le service en aval nécessite un JSON strictement valide à chaque fois.
Utiliser le décodage guidé/contraint (grammaire ou schéma JSON) dans le runtime de service plutôt que de se fier uniquement à la formulation du prompt.
Pourquoi: Le décodage contraint masque les tokens invalides au moment de la génération, garantissant une sortie valide par rapport au schéma, là où le prompting ne fait que réduire le taux d'échec.
La tâche nécessite un format cohérent que le modèle de base gère de manière incohérente.
Essayer d'abord des exemples few-shot ; passer au fine-tuning uniquement si la direction par prompt stagne ou si le coût des tokens est excessif.
Pourquoi: Le few-shot ne nécessite aucun entraînement et est instantanément modifiable ; le fine-tuning n'est avantageux que lorsque les schémas sont stables et que le surcoût du prompt est pénalisant.
Une tâche de raisonnement en plusieurs étapes donne des réponses finales erronées.
Solliciter une "chaîne de pensée" ('pense étape par étape') ou utiliser un modèle de raisonnement structuré avant la réponse finale.
Pourquoi: L'exposition des étapes intermédiaires améliore la précision des raisonnements complexes et rend les erreurs vérifiables, au coût de tokens supplémentaires.
Une légère modification de prompt a discrètement dégradé la qualité en production.
Versionner les prompts système comme du code, subordonner les changements à l'évaluation et les déployer via la même CI que les artefacts du modèle.
Pourquoi: Les prompts font partie du contrat du modèle ; les modifications non versionnées entraînent des régressions non suivies et un comportement non reproductible.
Le modèle hallucine des faits extérieurs à ses données d'entraînement.
Récupérer le contexte pertinent et l'injecter dans le prompt avec une instruction de répondre uniquement à partir du contexte fourni.
Pourquoi: L'ancrage sur des passages récupérés contraint le modèle au matériel source et réduit l'hallucination sur les requêtes à forte intensité de connaissances.
La latence et le coût sont élevés car les prompts sont surchargés.
Élaguer et compresser le prompt : dédupliquer les instructions, résumer le contexte récupéré et limiter les exemples au minimum nécessaire pour maintenir la qualité.
Pourquoi: Le préremplissage s'adapte aux tokens d'entrée ; des prompts épurés réduisent à la fois la latence et le coût par requête sans perte de qualité mesurable.
Le texte fourni par l'utilisateur peut outrepasser l'instruction du système.
Séparer les instructions fiables des entrées non fiables par des délimiteurs clairs et traiter le contenu récupéré/utilisateur comme des données, pas des commandes.
Pourquoi: La concaténation de texte non fiable dans le canal d'instructions invite à l'injection de prompt ; des limites explicites réduisent la surface d'attaque.
Adapter un grand modèle de base à un domaine avec un budget GPU limité.
Utiliser LoRA : entraîner des adaptateurs de bas rang et geler les poids de base.
Pourquoi: LoRA entraîne une infime fraction des paramètres, réduisant considérablement la mémoire et le calcul tout en égalant le fine-tuning complet sur la plupart des tâches spécifiques.
Même l'entraînement LoRA d'un modèle 70B ne tient pas dans la mémoire disponible.
Utiliser QLoRA : quantizer la base gelée en 4 bits (NF4) et entraîner les adaptateurs LoRA par-dessus.
Pourquoi: Maintenir la base en 4 bits tout en ne mettant à jour que les adaptateurs permet d'effectuer le fine-tuning de grands modèles sur un seul GPU avec une perte de précision minimale.
Choisir le rang LoRA pour une nouvelle tâche de fine-tuning.
Commencer avec un rang modeste (par exemple, 8-16) ; l'augmenter uniquement si la tâche est complexe et que la perte de validation continue de s'améliorer.
Pourquoi: Un rang plus élevé ajoute de la capacité et du coût ; un sur-classement risque le surapprentissage sur de petits jeux de données tandis qu'un sous-classement limite la qualité réalisable.
Le modèle suit les instructions mais ses sorties ne correspondent pas aux préférences humaines.
Effectuer d'abord un fine-tuning supervisé, puis un alignement des préférences avec RLHF ou DPO.
Pourquoi: Le SFT enseigne le format et la tâche ; l'optimisation des préférences façonne les réponses valides que les humains préfèrent réellement.
RLHF avec PPO est instable et lourd en opérations.
Utiliser DPO (Direct Preference Optimization) sur un jeu de données de préférences au lieu d'un modèle de récompense + boucle PPO.
Pourquoi: DPO optimise directement les préférences sans modèle de récompense séparé ni déploiement RL, simplifiant le pipeline et améliorant la stabilité.
L'adaptateur LoRA ajoute un surcoût par requête au moment de l'inférence.
Fusionner les poids de l'adaptateur dans la base pour le déploiement lorsqu'un seul adaptateur est servi.
Pourquoi: Un modèle fusionné n'a pas de branche d'adaptateur à l'inférence ; ne garder les adaptateurs séparés que lors du changement à chaud de plusieurs tâches sur une seule base.
Le fine-tuning sur une tâche spécifique dégrade les capacités générales.
Intégrer une partie de données générales/d'instructions, réduire le taux d'apprentissage et préférer PEFT au fine-tuning complet.
Pourquoi: Rejouer des données générales et limiter le mouvement des poids préserve les compétences larges tout en apprenant la nouvelle tâche.
Les données de pré-entraînement/fine-tuning contiennent de nombreux quasi-doublons.
Exécuter une déduplication floue (par exemple, MinHash/LSH) avant l'entraînement.
Pourquoi: Les doublons gaspillent le calcul, biaisent le modèle vers le contenu répété et peuvent entraîner la mémorisation ; la déduplication améliore la généralisation par token.
Scores de référence anormalement élevés après l'entraînement.
Décontaminer l'ensemble d'entraînement par rapport aux données de référence/évaluation via un filtrage de chevauchement de n-grammes.
Pourquoi: La fuite d'éléments de test gonfle les métriques et masque la qualité réelle ; la décontamination maintient l'évaluation honnête.
Le corpus peut contenir des données personnelles soumises aux règles de gouvernance.
Ajouter une étape de détection et de rédaction des PII au pipeline de données avant l'entraînement.
Pourquoi: L'entraînement sur des PII brutes risque la régurgitation et les violations de conformité ; l'épuration préalable est bien moins coûteuse que la correction d'un modèle "fuyant".
Les données brutes extraites du web sont bruyantes et diminuent la qualité du modèle.
Appliquer des filtres de qualité (heuristiques plus un classificateur) pour éliminer les documents de faible qualité, les modèles et les spams.
Pourquoi: La qualité des données l'emporte sur la quantité brute au-delà d'un certain seuil ; le filtrage permet d'obtenir de meilleurs modèles avec le même budget d'entraînement.
Les données de fine-tuning doivent être intégrées proprement dans le pipeline d'entraînement NeMo.
Convertir au format NeMo attendu (par exemple, JSONL avec des champs prompt/response) et tokeniser avec le tokenizer du modèle.
Pourquoi: Des incompatibilités de format et de tokenizer entraînent des tronquages silencieux ou des erreurs d'étiquetage ; se conformer au schéma de NeMo assure la reproductibilité de l'entraînement.
Mettre en place rapidement un endpoint LLM de production avec une API compatible OpenAI.
Déployer avec un microservice NVIDIA NIM ; construire un ensemble Triton personnalisé uniquement pour les besoins non-standards de pré/post-traitement.
Pourquoi: NIM fournit des moteurs optimisés et une API standard prête à l'emploi ; un Triton personnalisé ne vaut l'effort que lorsque vous avez besoin d'un contrôle de pipeline sur mesure.
Des requêtes indépendantes arrivent plus vite que le service par requête unique ne peut les gérer.
Activer le batching dynamique de Triton pour regrouper les requêtes concurrentes en lots GPU.
Pourquoi: Le batching amortit le surcoût du noyau sur les requêtes, augmentant le débit avec un coût de latence faible et borné.
Une seule instance de modèle sous-utilise le calcul GPU.
Configurer plusieurs instances de modèle par GPU dans Triton pour chevaucher l'exécution.
Pourquoi: Les instances concurrentes comblent les lacunes de calcul laissées par les blocages mémoire, améliorant l'utilisation lorsque la mémoire le permet.
Le trafic est irrégulier et les réplicas fixes gaspillent des GPU ou ne respectent pas les SLO.
Mettre à l'échelle automatiquement les réplicas en fonction de la profondeur de la file d'attente / de l'utilisation du GPU avec un pool "chaud" pour absorber les démarrages à froid.
Pourquoi: Les démarrages à froid de LLM (chargement du moteur) sont lents ; la mise à l'échelle sur un signal précurseur avec une capacité chaude protège la latence pendant les pics.
Les clients existants attendent l'API OpenAI de chat-completions.
Exposer le modèle via le endpoint compatible OpenAI de NIM afin que les clients s'intègrent sans réécritures.
Pourquoi: Une API compatible prête à l'emploi minimise le travail de migration des clients et permet de permuter les backends de manière transparente.
Une modification du modèle ou du prompt ne doit pas dégrader silencieusement la qualité.
Exécuter un ensemble d'évaluation "golden" sélectionné en CI et bloquer les déploiements qui descendent en dessous d'un seuil de qualité.
Pourquoi: Les portes de régression automatisées détectent les baisses de qualité avant qu'elles n'atteignent les utilisateurs, de la même manière que les tests unitaires contrôlent le code.
Les sorties ouvertes n'ont pas de réponse de référence unique pour être évaluées.
Utiliser un LLM-juge avec une grille d'évaluation, calibré par rapport aux évaluations humaines sur un échantillon.
Pourquoi: Un juge guidé par une grille d'évaluation met à l'échelle l'évaluation subjective ; la calibration humaine protège contre le propre biais du juge.
Score MMLU élevé, mais les utilisateurs se plaignent de la tâche en production.
Évaluer sur des métriques spécifiques à la tâche, liées aux résultats commerciaux, et non pas seulement sur des benchmarks génériques.
Pourquoi: Les benchmarks génériques corrèlent faiblement avec les tâches spécifiques déployées ; la bonne métrique reflète ce dont les utilisateurs ont réellement besoin.
Les évaluations hors ligne semblent bonnes mais l'impact réel est incertain.
Exécuter un test A/B en ligne en acheminant une fraction du trafic vers la nouvelle version et comparer les métriques de résultat.
Pourquoi: Le test A/B en direct capture le décalage de distribution et le comportement de l'utilisateur que les ensembles hors ligne manquent, confirmant une réelle amélioration.
Besoin de visibilité sur la santé et l'utilisation des GPU sur l'ensemble d'une flotte de serveurs.
Exporter les métriques DCGM (utilisation, mémoire, ECC, température) vers Prometheus et générer des alertes.
Pourquoi: DCGM est la source de télémétrie NVIDIA standard ; sans elle, la saturation et les pannes au niveau du GPU passent inaperçues.
Les utilisateurs observent sporadiquement des réponses lentes mais la latence moyenne semble correcte.
Suivre le temps de premier token et la latence inter-token aux p95/p99, et alerter en cas de non-respect des SLO en centiles.
Pourquoi: Les moyennes masquent la latence de queue ; l'expérience utilisateur des LLM est régie par les p95/p99, donc les SLI en centiles sont le bon signal d'alerte.
Déployer une nouvelle version de modèle sur un endpoint à fort trafic.
Déployer en "canary" (petite tranche de trafic) avec rollback automatisé en cas de régression de SLO ou de qualité.
Pourquoi: Le déploiement canary limite la portée de l'impact et permet aux métriques de confirmer la sécurité avant le déploiement complet, contrairement à un déploiement "big-bang".
Le débit s'effondre sous charge sans pic évident de calcul GPU.
Surveiller l'utilisation du cache KV et des slots de lot ; mettre à l'échelle ou raccourcir le contexte maximal lorsque le cache sature.
Pourquoi: L'épuisement du cache KV limite la concurrence avant même le calcul ; le surveiller explique les chutes de débit que la seule utilisation du GPU ne révèle pas.
Le cache KV est trop volumineux pour le lot et le contexte cibles.
Préférer une architecture utilisant Grouped-Query Attention (GQA) ou Multi-Query Attention (MQA).
Pourquoi: GQA/MQA partagent les têtes clé/valeur, réduisant la mémoire du cache KV et augmentant la taille de lot réalisable avec peu de perte de qualité.
Besoin d'étendre le contexte utilisable d'un modèle au-delà de sa longueur entraînée.
Utiliser la mise à l'échelle RoPE (par exemple, NTK-aware / YaRN) plus un léger fine-tuning de long-contexte.
Pourquoi: L'interpolation RoPE étire les encodages de position ; un court fine-tuning adapte le modèle à la plage plus longue sans réentraînement complet.
Vouloir plus de capacité sans coût d'inférence proportionnel.
Envisager un modèle Mixture-of-Experts qui n'active que les k meilleurs experts par token.
Pourquoi: MoE met à l'échelle les paramètres tout en maintenant les FLOPs par token faibles, mais ajoute une complexité de routage et une charge d'experts inégale à gérer.
Un modèle déployé nécessite des limites de sujet, de sécurité et de format.
Envelopper le modèle avec NeMo Guardrails pour appliquer des rails d'entrée et de sortie (thématiques, modération, jailbreak).
Pourquoi: Les rails programmables ajoutent une couche de sécurité contrôlable autour du modèle sans le réentraîner.
Le modèle produit occasionnellement du contenu toxique ou dangereux.
Ajouter un classificateur de modération de sortie et bloquer/régénérer les réponses qui dépassent un seuil de risque.
Pourquoi: Un passage de modération séparé détecte les générations dangereuses que les instructions au niveau du prompt seules ne peuvent pas empêcher de manière fiable.
Les parties prenantes exigent des preuves que le modèle respecte les normes d'IA responsable.
Exécuter des benchmarks de biais et de toxicité, documenter les résultats et les suivre à travers les versions dans une fiche de modèle.
Pourquoi: Une évaluation de sécurité documentée et reproductible soutient la conformité et révèle les régressions avant qu'elles n'atteignent la production.