Latest / M365.FM – Podcast Microsoft 365, Copilot & IA en français / Inférence GPU lente démasquée : repli sur CPU, conflits de versions CUDA/TensorRT et erreurs de conteneur (Doublage IA)

Transcript

Inférence GPU lente démasquée : repli sur CPU, conflits de versions CUDA/TensorRT et erreurs de conteneur (Doublage IA) · M365.FM – Podcast Microsoft 365, Copilot & IA en français

• 0:00
  Tout a commencé par un avertissement, puis le silence.
• 0:02
  La facture GPU grimpait comme si l'accélérateur ne dormait jamais,
• 0:05
  pourtant les résultats traînaient comme si tout s'était éteint.
• 0:07
  Les tableaux de bord étaient au vert, les clients non.
• 0:10
  L'anomalie ne collait pas.
• 0:12
  Une utilisation GPU proche de zéro alors que la latence explosait.
• 0:15
  Aucune alerte, aucune ligne rouge, juste du temps qui s'évapore.
• 0:18
  Les preuves suggèrent une pathologie unique se faisant passer pour la normale.
• 0:22
  Voici notre engagement.
• 0:23
  Nous retracerons les artefacts, nommerons le coupable et corrigerons cette pathologie.
• 0:27
  Nous examinerons trois modes de défaillance.
• 0:28
  Le recours au CPU, l'incompatibilité de version entre CUDA et ONX Tensor RT
• 0:32
  et la mauvaise configuration des conteneurs,
• 0:34
  nous le prouvons par la latence, le débit et l'utilisation du GPU avant et après.
• 0:39
  Mise en place du cas, l'environnement et le profil de la victime.
• 0:41
  Chaque configuration raconte une histoire,
• 0:43
  et celle-ci commence par un locataire ordinaire sous pression.
• 0:46
  La charge de travail, la diffusion texte vers images,
• 0:49
  des variantes de stable diffusion tournant en 512, BIOK 512 et montant jusqu'en 1024 et K1024.
• 0:54
  Le trafic est irrégulier.
• 0:55
  La concurrence pousse entre 8 et 32 requêtes.
• 0:57
  Les tailles de l'eau varient de 1 à 8.
• 1:00
  Les niveaux de service sont stricts sur la latence de Q.
• 1:02
  Dépassement du P95 se traduisent directement en crédit et pénalité.
• 1:05
  Les modèles ne sont pas exotiques, mais leur choix compte.
• 1:08
  Pipeline Stable Diffusion exporté en ONX,
• 1:11
  optimisation de cross-attention comme X-Formers
• 1:12
  ou le produit scalaire mis à l'échelle,
• 1:13
  et sélection de planificateurs qui sacrifient des étapes pour la qualité.
• 1:16
  Et...
• 1:16
  L'écosystème est censé accélérer lorsque la tue.
• 1:19
  IE3 est saine.
• 1:21
  Le matériel semble respectable sur le papier.
• 1:23
  Carte NVIDIA RTX et série A dans le cloud, 16 à 32 gigas de VRAM, 1.
• 1:27
  Le PCI-E se place entre l'hôte et le périphérique comme un péage.
• 1:30
  C'est rapide quand il est configuré,
• 1:31
  punitif quand les eustiocès reviennent à des transferts paginables.
• 1:34
  Dans cet environnement, rien n'est accidentel.
• 1:36
  La chaîne d'outils s'empile en couche familière.
• 1:38
  Pitorch est utilisé pour l'export,
• 1:40
  puis ONX Runtime ou TensorRT prend le relais pour l'inférence.
• 1:42
  Les pilotes CUDA se trouvent sous tout le reste.
• 1:44
  Les noyaux d'attention promettent de la vitesse si les versions concordent.
• 1:48
  Le déploiement est strictement conteneurisé.
• 1:50
  Image immuable, déploiement, contrôlé par CI, politique blue green.
• 1:54
  Cette contrainte devrait assurer la sécurité.
• 1:56
  Elle peut aussi figer les défauts dans l'ambre.
• 1:58
  Les enjeux commerciaux ne sont pas abstraits.
• 1:59
  Le coût par requêt définit la marge.
• 2:01
  Les réservations GPU sont facturées à l'heure que les noyaux tournent ou non.
• 2:05
  Quand la latence s'étire de quelques secondes à une demi-minute, le débit s'effondre.
• 2:08
  Une mauvaise configuration transforme un accélérateur en chauffage,
• 2:11
  coûteux, silencieux et occupé à ne rien faire qu'il y ait de la file d'attente.
• 2:14
  En y regardant de plus près, le profil de la victime se précise.
• 2:17
  Concurrence à 16, l'os à 2 pour rester sous les plafonds de V-RAM en 512,
• 2:21
  passant à 1024 pour la qualité,
• 2:24
  le locataire attend un P95 cohérent.
• 2:27
  Au lieu de cela, les traces montrent des latences erratiques de large delta
• 2:29
  entre P50 et P95 et des cycles de travail GPU,
• 2:33
  oscillant de 5%, 40% sans raison évidente.
• 2:35
  Les graphiques CPU révèlent une autre vérité.
• 2:38
  Les cœurs sont saturés sans aucune justification de pré-traitement.
• 2:41
  Les preuves suggèrent trois pistes.
• 2:43
  Premièrement, le recours au CPU.
• 2:45
  Lorsque le fournisseur d'exécution Xeuda ou TensorRT échoue à se charger,
• 2:48
  le moteur bascule silencieusement sur le graph CPU.
• 2:50
  Le modèle fonctionne, mais avec une latence multipliée par 10 autres.
• 2:53
  Une incompatibilité de version.
• 2:54
  ONNX Runtime, compilé pour une version Xeuda a donné.
• 2:57
  Des nœuds utilisant une autre, des moteurs TensorRT invalidés
• 2:59
  et reconstruits avec des noyaux génériques.
• 3:01
  L'utilisation est visible, mais les chemins optimisés ont disparu.
• 3:05
  Troisièmement, une mauvaise configuration des conteneurs,
• 3:08
  des images trop lourdes à l'absence de montage des périphériques GPU,
• 3:10
  des mauvais paramètres du toolkit Nvidia
• 3:11
  et des zones mémoires conservant des allocations
• 3:13
  qui amplifient la latence de queue sous charge.
• 3:16
  Fin de compte, ce n'est pas un mystère lié au modèle.
• 3:18
  C'est une affaire de fiabilité de l'infrastructure.
• 3:20
  Nous allons tracer les artefacts, l'ordre des fournisseurs,
• 3:22
  les journaux de capacité, les montages de périphériques
• 3:24
  et les corrélés à trois métriques implacables.
• 3:26
  Latence, débit et utilisation GPU.
• 3:28
  Dossier de preuve A, le recours au CPU.
• 3:33
  Ce saboteur, silencieux.
• 3:36
  Tout a commencé avec une requête qui aurait dû prendre quelques secondes,
• 3:37
  mais qui n'a pas été le cas.
• 3:38
  Le compteur GPU était silencieux.
• 3:40
  Bien trop silencieux.
• 3:41
  Le graphique CPU, lui, s'est emballé comme une alarme incendie.
• 3:44
  Après un examen approfondi, le moteur avait fait un choix.
• 3:46
  Il a exécuté une tâche destinée au GPU sur le CPU.
• 3:48
  Puis une alerte n'a été déclenchée.
• 3:49
  Le résultat a fini par arriver.
• 3:51
  C'est ça, le saboteur silencieux.
• 3:53
  Le recours au CPU.
• 3:54
  La raison pour laquelle c'est important est ça.
• 3:55
  Faire tourner stable diffusion sur un CPU est une perte de temps.
• 3:57
  Le modèle fonctionne, mais la latence explose.
• 4:00
  10 à 30 fois plus lente.
• 4:01
  Et le débit s'effondre.
• 4:03
  Dans un environnement qui vend des millisecondes, cet écart est fatal.
• 4:06
  La facture continue de compter le temps GPU,
• 4:07
  alors que le périphérique ne fait pas le travail.
• 4:09
  La chronologie a révélé le schéma.
• 4:10
  Les conteneurs qui tournaient localement avec CUDA étaient très rapides.
• 4:13
  Déployés sur un autre cluster avec une pile de pilotes légèrement différente,
• 4:16
  les mêmes conteneurs ont démarré, répondu aux sondes de santé,
• 4:18
  puis ont dégradé leur performance.
• 4:19
  Le point de terminaison de santé vérifiait uniquement le serveur est-il opérationnel.
• 4:22
  Il n'a jamais vérifié le GPU est-il réellement en train d'exécuter la tâche.
• 4:27
  Le silence est un artefact.
• 4:29
  L'artefact principal est l'ordre des fournisseurs d'exécution dans ONNX Runtime.
• 4:33
  Le moteur accepte une liste.
• 4:35
  Essayez Tensor RT, puis CUDA, puis le CPU.
• 4:37
  Si CUDA échoua à s'initialiser, mauvais pilote, bibliothèque manquante, périphériquement montée,
• 4:41
  ORT basculera silencieusement vers le fournisseur d'exécution CPU.
• 4:45
  Pas d'exception, pas de plantage, juste une ligne dans les journaux, souvent cachée.
• 4:48
  Fournisseur d'exécution CUDA non disponible.
• 4:50
  Basculement vers le CPU.
• 4:52
  Cette ligne est l'aveu que la plupart des équipes ne lisent jamais.
• 4:54
  Voici le plus étrange.
• 4:54
  Les graphiques d'utilisation semblent faussement normaux au premier coup d'œil.
• 4:58
  Les requêtes finissent tout de même par aboutir.
• 5:00
  La cartographie des services est au vert.
• 5:01
  Mais le taux d'utilisation du GPU stagne à 5% tandis que le temps CPU utilisateur explose et plafonne.
• 5:06
  La latence P50 quadruple et le P95 s'effondrent.
• 5:09
  Le trafic par rafale aggrave la situation.
• 5:11
  Les files d'attente s'accumulent et l'autoscaling ajoute des répliques qui héritent toutes du même défaut.
• 5:15
  Imaginez une équipe de relais où le sprinter ne se présente jamais, forçant le bibliothécaire à courir à sa place.
• 5:19
  Le témoin avance, mais pas à la vitesse d'une course.
• 5:21
  En d'autres termes, votre système assure la justesse au prix de la totalité du budget SLO.
• 5:25
  Les artefacts s'accumulent rapidement lorsque vous analysez la séquence de démarrage.
• 5:28
  Les gens de chargement des fournisseurs montent des tentatives d'initialisation CUDA avec vérification des versions de pilote.
• 5:32
  Si le conteneur a été conçu pour CUDA 12.2, mais que le nœud n'a que la version 12, l'initialisation échoue.
• 5:39
  Si le toolkit NVIDIA pour conteneur n'est pas configuré, le montage du périphérique n'apparaît jamais dans le conteneur.
• 5:44
  Pas de dev, sage NVIDIA, pas de libre CUDA.
• 5:46
  Ainsi, si la spécification du pod ne demande pas explicitement de GPU, le planificateur n'assigne jamais le périphérique.
• 5:52
  N'importe lequel de ces éléments déclenche la dégradation silencieuse.
• 5:55
  La reproduction est directe.
• 5:56
  Sur un nœud mal configuré, une inférence simple, afficheur, un fournisseur CPU au lieu du fournisseur TensorRT ou si UDA attendu.
• 6:07
  Envoyer une requête simple, le GPU reste inactif.
• 6:11
  Les trades CPU s'envolent, l'image revient en 20-40 secondes au lieu de 2 à 6.
• 6:15
  Répéter l'opération sur un nœud avec les pilotes et montages corrects, la requête est traitée en une fraction du temps et le GPU s'active durablement.
• 6:22
  Les preuves suggèrent que les gardes foie actuels ne sont que de façade.
• 6:25
  Les sondes de santé renvoient 200 car le serveur répond qu'aucune vérification au démarrage confirmant que le chemin GPU est auto-garde.
• 6:31
  Les sondes de performance n'existent pas, donc l'orchestrateur croit que les répliques sont saines.
• 6:34
  Le système ne fait pas la distinction entre accélération et émulation.
• 6:38
  La contre-mesure est délibérément ravie.
• 6:40
  Échec critique si le fournisseur d'exécution GPU est absent ou dégradé.
• 6:44
  Refuser tout démarrage avec le CPU en production.
• 6:47
  Au lancement du processus, énumérer les fournisseurs, vérifier que TensorRT ou CUDA est chargé et que le nombre de périphériques correspond aux attentes.
• 6:53
  Journaliser les capacités, QDNN, Curtain de sort disponible, limite mémoire, et terminer avec un code d'erreur si quelque chose manque.
• 7:01
  Sacrifier la disponibilité pour l'intégrité.
• 7:03
  Laissez l'orchestrateur reprogrammer sur un nœud sain.
• 7:05
  Pour garantir la fiabilité, imposez une vérification des liaisons.
• 7:08
  Liez les entrées et sorties à la mémoire du périphérique et validez une inférence triviale au démarrage.
• 7:13
  Une exécution de chauve qui sollicite le noyau d'attention fusionné.
• 7:15
  Si le timing dépasse un seuil de latence, considérez le chemin comme dégradé et faites échouer le pot.
• 7:20
  Ajoutez un jeu de roquettes canarie avec des germes déterministes.
• 7:23
  Comparez la latence par rapport à la fenêtre de référence.
• 7:26
  Si la dérive dépasse votre tolérance, alertez la production et arrêtez le déploiement.
• 7:29
  Cela peut sembler dur, mais l'alternative est pire.
• 7:32
  Un cluster qui fonctionne tout en dilapidant temps et budget.
• 7:35
  Verrouillez l'or des fournisseurs, rejetez le repli sur CPU, exigez que le système prouve sa rapidité avant d'être jugé opérationnel.
• 7:40
  C'est seulement alors que le VR signifie accélération.
• 7:43
  Preuve B, inadéquation de version, incompatibilité entre UDA, ONNX et TensorRT.
• 7:49
  Si le GPU n'a pas été utilisé, la question suivante est de savoir s'il pourrait atteindre sa pleine vitesse même en étant présent.
• 7:54
  Les preuves suggèrent une défaillance plus subtile.
• 7:56
  Les versions s'alignent assez pour exécuter, mais pas assez pour débloquer le chemin rapide.
• 8:00
  Le système semble accélérer jusqu'à ce que vous observiez les horloges.
• 8:03
  La raison pour laquelle cela compte est simple.
• 8:05
  Les pipelines de diffusion dépendent entièrement des performances d'attention.
• 8:07
  Quand ONNX Runtime et TensorRT ne peuvent charger les noyaux fusionnés attendus car les versions CUDA,
• 8:12
  si UDNN ou TensorRT divergent, ils basculent silencieusement vers des implémentations génériques.
• 8:17
  Le modèle fonctionne.
• 8:19
  L'utilisation oscille entre 30 et 50%, la latence, dépasse, le budget.
• 8:24
  La construction semble identique, le travail est plus lent.
• 8:26
  Après un examen plus approfondi, les artefacts sont précis.
• 8:29
  Les journaux de chargement des fournisseurs indiquent un succès à Vélateur.
• 8:31
  Repli sur les noyaux par défaut ou désactivation de X-Formers.
• 8:36
  Vous verrez l'échec de désarialisation du plan TensorRT avec une reconstruction du moteur incompatible
• 8:40
  à ce qui déclenche une compilation sur le nœud.
• 8:42
  Les moteurs construits sur une version mineure de TensorRT ne seront pas désarialisés sur une autre.
• 8:46
  La reconstruction se termine, mais le plan résultant peut omettre la tension fusionnée ou les optimisations FP16.
• 8:51
  La course s'achève.
• 8:53
  Sans pique, les cycles de service des coeurs Tensor restent modérés.
• 8:56
  Voici la partie contre-intuitive.
• 8:57
  Les équipes interprètent l'exécution comme une preuve d'optimalité.
• 9:00
  Dans cet environnement, rien n'est accidentel.
• 9:03
  Si la tension produit à l'échelle n'est pas active, si X-Formers est désactivé,
• 9:06
  si QDNN signale un espace de travail limité, les performances s'effondrent poliment.
• 9:11
  En résumé, des binaires incompatibles imposent des noyaux qui utilisent plus de mouvements mémoire
• 9:14
  et moins de densité de calcul.
• 9:16
  Le PCIE devient visible dans les traces, mais latence de queue dérive à mesure que la concurrence augmente.
• 9:20
  Considérez la pile comme un ensemble de verrous.
• 9:22
  Pilote, boîte à outils QDA, CUDNN, drapeau de build, ONNX Runtime et...
• 9:27
  Tensor RT, une dent mal placée, la clé ne tourne qu'à moitié.
• 9:31
  ORT annonce un graphe de capacité par fournisseur d'exécution.
• 9:34
  Si l'ORT compilé attend QDA 12.2, mais que le pilote du nœud expose la 12.1,
• 9:39
  QDA se charge avec des fonctionnalités restreintes ou pas du tout à...
• 9:42
  Si Tensor RT est en 8.6 sur le nœud, mais que les plans ont été générés avec la 8.4,
• 9:47
  la déshérisation échoue et se régénère avec des tactiques conservatrices.
• 9:50
  Le système préfère silencieusement la justesse à la vitesse.
• 9:53
  Les benchmarks prouvent la perte en termes pratiques.
• 9:55
  Avec X-Formers ou SDP actifs, la tension de diffusion réduit le temps réel de manière mesurable.
• 10:00
  La recherche montre systématiquement des accélérations de 2X à 5X sur le chemin d'attention
• 10:03
  selon la résolution et la taille du lot.
• 10:06
  Désactivez-les par dérive de version et vous perdez ces multiplicateurs.
• 10:08
  La fusion de jetons, Totomay, se cumule avec Sega.
• 10:13
  Sans les noyaux fusionnés, le bénéfice est limité par la bande passante mémoire
• 10:16
  et des agencements non optimisés.
• 10:17
  L'écart se creuse au-delà de 1024 par 1024 et avec une concurrence accrue.
• 10:21
  Pour tracer les artefacts, commencer par l'énumération des capacités.
• 10:24
  Au démarrage, afficher la liste exacte des fournisseurs et leurs fonctionnalités déclarées.
• 10:28
  Version de Tensor RT, disponibilité FP16i NT8, espace de travail maximal,
• 10:33
  heuristique de convolution Sud-NN, présence de NCCL pour le multi-GPU.
• 10:38
  Pour le runtime au NNX, exportez les priorités des EP.
• 10:41
  Tensor RT, Suda, puis CPU.
• 10:44
  Vérifiez lesquelles sont réellement liées à vos nœuds de graphe.
• 10:46
  Enregistrez si les nœuds d'attention sont assignés à Tensor RT
• 10:49
  avec des noyaux fusionnés ou à des noyaux CUDA génériques.
• 10:52
  Ensuite, interrogez l'environnement.
• 10:54
  Interrogez le pilote.
• 10:55
  NVIDIA SMI affiche le module noyau et la compatibilité CUDA.
• 10:58
  Lisez les versions des bibliothèques dans le contenant.
• 11:00
  LibCuda, LibCuden, LibEnvinFair, Lib...
• 11:03
  Si l'image contient des bibliothèques Suda 12.3 mais que le pilote haute ne supporte que la 12.2,
• 11:08
  le mode de compatibilité runtime peut se charger avec des contraintes.
• 11:11
  Si l'image attend des entêtes Tensor RT 8.6 mais que le plugin du nœud fournit la 8.4,
• 11:15
  les appels API seront dégradés ou annuleront certaines optimisations.
• 11:18
  La solution est une matrice de construction parveu-pieux.
• 11:21
  Fixez les versions exactes dans une source unique de vérité.
• 11:24
  Images de base avec compatibilité des pilotes.
• 11:26
  Version mineure CUDA, Sud-NN, H de construction ORT et version de Tensor RT.
• 11:30
  Générez les images d'inférence selon cette matrice et rejetez les nœuds non conformes via des étiquettes de nœuds et des contrôles d'admission.
• 11:36
  Prégénérez et mettez en cache les moteurs Tensor RT pour chaque variante de modèle et résolution sur la version exacte de Tensor RT déployée.
• 11:41
  Considérez les fichiers de plan comme des artefacts liés à la matrice.
• 11:44
  Ne comptez jamais sur la construction de moteur sur le nœud en production.
• 11:47
  Cela masque les dérives et allonge les démarrages à froid.
• 11:50
  Pour pérenniser cela, ajoutez des tests de fumée en CI qui vérifient les capacités des noyaux.
• 11:54
  Lancez le conteneur dans un exécuteur isolé avec le pilote cible et vérifiez que...
• 11:57
  Tensor RT charge des noyaux FP16 utilisés, que les nœuds d'attention sont fusionnés, la liaison IO active et X-Formers, ou SDP, reconnue.
• 12:05
  Exécutez un jeu de prompt déterministe et faites échouer la construction si la latence dépasse la fenêtre de référence ou si les journaux indiquent un repli.
• 12:13
  Stockez l'instantané des capacités avec le digeste de l'image pour que les retours en arrière restaurent le code et les caractéristiques de performance.
• 12:20
  Final, les preuves montrent que la dérive des versions n'est pas un bug.
• 12:22
  C'est un coût en termes de vitesse.
• 12:24
  Le système fonctionnera.
• 12:25
  Les horloges en témoignant.
• 12:27
  Fichier de preuve C, conteneur.
• 12:29
  Érosion de l'efficacité par mauvaise configuration par conception.
• 12:33
  Même quand les versions s'alignent, le conteneur peut saboter l'efficacité de l'intérieur.
• 12:38
  Les preuves suggèrent une lente hémorragie, une surcharge de l'image, des problèmes de plomberie GPU et un comportement de locateur qui déforme la latence sous charge.
• 12:44
  Rien ne plante.
• 12:45
  Tout se dégrade.
• 12:48
  La raison est simple.
• 12:49
  Les conteneurs définissent la réalité du runtime.
• 12:50
  Si l'image est trop lourde et que les démarrages à froid traînent, les répliques arrivent en retard sur l'incident.
• 12:55
  Si les périphériques GPU ne sont pas montés ou si le runtime manque des bons indicateurs, les fournisseurs d'exécution se comportent mal.
• 13:02
  Si les arrêts de mémoire accumulent les allocations, le turn-haken RAM déclenche la pagination et des pics de latence.
• 13:06
  Le modèle semble correct.
• 13:08
  Le conteneur taxe silencieusement chaque requête.
• 13:10
  A y regarder de plus près, les artefacts s'accumulent lors de la compilation.
• 13:14
  Les images dépassent 2 gigas chargées de compilateurs, d'entêtes et d'actifs de tests par manque de construction multi-étapes.
• 13:19
  Un docker ignore qu'une manquant laisse entrer notebooks, cache et poids expérimentaux dans les couches de production.
• 13:24
  Chaque déploiement télécharge des gigaoctets sur le réseau.
• 13:27
  A l'échelle des poules de nœuds, le démarrage à froid devient la norme plutôt qu'une exception.
• 13:31
  Plutôt qu'une exception.
• 13:32
  Les preuves ne sont pas mystérieuses.
• 13:33
  L'historique Docker raconte l'histoire couche par cas.
• 13:35
  L'exécution révèle le deuxième niveau d'érosion.
• 13:37
  Sans drapeau GPU explicite dans Docker, ou sans configuration de plugin de périphériques dans Kubernetes,
• 13:43
  le processus ne voit aucun périphérique NVIDIA à ZIA.
• 13:47
  Les mauvaises configurations du NVIDIA Container Toolkit masquent LibCuda.
• 13:51
  Ainsi, le fournisseur d'exécution se charge avec des contraintes, ou ne se charge pas du tout.
• 13:55
  Le MIG n'est pas appliqué, donc les charges se battent pour d'étranges mémoires, créant un gaspillage invisible pour les ordonnanceurs.
• 14:00
  Les journaux restent polis, la performance se dégrade.
• 14:02
  Le comportement mémoire est le troisième niveau.
• 14:04
  Par défaut, l'arène mémoire Cuda d'ONX Runtime et encache les allocations de manière agressive.
• 14:08
  Sous concurrent, cela semble stable, jusqu'à ce que l'arène sur réserve et affame les nouvelles requêtes.
• 14:14
  La mémoire épinglée n'étant pas définie, les transferts hautes périphériques passent par des tampons paginables, saturant le PCIE.
• 14:20
  Les ECAS ne sont pas liés au périphérique, donc les tenseurs font des allers-retours entre CPU et GPU créant une latence invisible.
• 14:26
  Le comportement des queues de distribution se détériore en premier, puis la médianité.
• 14:28
  Voici à quoi ressemble l'ensemble des symptômes sur le terrain.
• 14:30
  Le débit effectif est à la traîne malgré une utilisation GPU modérée.
• 14:34
  La latence sous faible charge est acceptable, mais le P95 oscille sous concurrence, puis grimpe de façon imprévisible.
• 14:40
  Des OM-Kill occasionnels réinitialisent les réplicas au pic de trafic, créant un effet de troupeau.
• 14:44
  Les redémarrages s'enchaînent, l'autoskilling s'emballe, et les files d'attente s'accumulent.
• 14:47
  Les opérateurs cherchent la mauvaise cause, croyant le modèle lourd alors que ce sont les politiques des conteneurs qui causent l'effondrement.
• 14:52
  Considérer l'hygiène des conteneurs comme une gestion de preuve.
• 14:54
  Les constructions multi-étapes suppriment les empreintes inutiles.
• 14:56
  Les compilateurs et outils de développement n'entrent jamais dans l'exécution.
• 14:59
  Une image de base d'istrolet c'est que, où SlimMaker réduit la surface d'attaque et le temps de téléchargement.
• 15:03
  Des audits avec Docker Slim ou Dive confirment ce qui a survécu à la construction.
• 15:06
  Un Docker ignore évite tout encombrement accidentel.
• 15:09
  Le résultat est d'une propreté médico-légale.
• 15:11
  Seul ce qui doit tourner est exécuté.
• 15:13
  La pombrie GPU nécessite des déclarations explicites.
• 15:15
  Dans Docker, déclarer tous les GPU ou la tranche MIG exacte.
• 15:19
  Dans Kubernetes, demandez les ressources GPU NVIDIA et assurez-vous que le plugin de périphérique correspond à votre version de pilote.
• 15:25
  Au démarrage, vérifiez la présence du périphérique et la compatibilité du pilote.
• 15:28
  Les configurations NVIDIA SMI et LD ne sont pas là pour la décoration, ce sont des contrôles d'accès.
• 15:32
  Si quelque chose manque ou ne correspond pas, loguez une violation et quittez.
• 15:35
  Ensuite, ajustez au NNX Runtime et Answer RT avec Intensement.
• 15:38
  Verrouillez l'ordre du fournisseur d'exécution sur les chemins GPU, uniquement en production.
• 15:41
  Pensez à désactiver ou à reconfigurer l'arène de mémoire CUDA lorsqu'elle accapare plus que votre jeu de travail.
• 15:47
  Limitez la croissance ou définissez une pré-allocation selon des limites prévisibles.
• 15:51
  Activez le FP16 par défaut lorsque les gardes-fous de précision le permettent.
• 15:54
  Soumettez l'INT8 à un test de précision préal.
• 15:57
  Liez les ECUS à la mémoire du périphérique pour que les entrées arrivent là où résille le calcul
• 16:00
  et choisissez les flux, délibérément, pour éviter le blocage en tête de ligne.
• 16:04
  Appliquez ces règles avec deux barrières, santé et performance.
• 16:07
  La santé n'est pas juste un code de sang, c'est un instantané vérifier des capacités.
• 16:09
  La performance est un jeu d'invite de référence qui s'exécute à chaud au démarrage avec une fenêtre de latence et un seuil d'utilisation.
• 16:21
  Si le conteneur ne peut atteindre ces deux objectifs, il n'est pas admis en service.
• 16:24
  Appliquez des budgets de taille de tirage à lisser afin que les images dépassant les seuils échouent à la compilation.
• 16:28
  Gardez un div du contenu des images par condensé pour que les restaurations préservent le code et l'hygiène.
• 16:32
  Les preuves suggèrent que les conteneurs ne font pas que déployer du logiciel, ils encodent le comportement sous stress.
• 16:38
  S'ils sont bruyants, lourds ou vagues sur le GPU, ils transforment l'accélération en cérémonie.
• 16:43
  S'ils sont légers, explicites et assertifs, ils préservent la voie rapide pour laquelle vous avez payé.
• 16:47
  Dans cet environnement, rien n'est accidentel.
• 16:48
  Le conteneur aide le GPU à faire son travail où il fait obstacle.
• 16:52
  Laboratoire médico-légal, des mesures qui comptent.
• 16:54
  Latence, débit, utilisation.
• 16:56
  La preuve surpasse l'opinion.
• 16:58
  Alors nous fixons le jeu d'invite, verrouillons les graines et exécutons à chaud.
• 17:01
  Mêmes ordonnanceurs, mêmes étapes, 20 pour 512, étendus à 50 pour du 1000, 24 par 1000, 24 afin de révéler la contrainte.
• 17:10
  La concurrence est maintenue à 16 avec un balayage jusqu'à 32.
• 17:13
  La taille des lots commence à 1, augmentant prudemment jusqu'à ce que les limites de la VRAM s'imposent.
• 17:16
  Pas d'extrapolation, pas d'excuse, juste des horloges et des compteurs.
• 17:19
  La latence témoigne en premier.
• 17:20
  Dans l'état dégradé, le repli CPU ou le chemin d'attention générique, le P50 à 512 par 512 grimpe à deux chiffres.
• 17:28
  Le P95 raconte la vraie histoire.
• 17:30
  Il erre entre 20 et 40 secondes de manière imprévisible car les files d'attente aggravent les petites inefficacités.
• 17:36
  A 1024 par 1024 avec 50 étapes, le P95 devient une rupture dès l'arrivée.
• 17:41
  Après remédiation, GPU EP verrouillé, attention fusionnée active, E sur S lié au périphérique,
• 17:46
  le P50 revient à des chiffres simples et le P95 se comprime sous le budget.
• 17:50
  L'écart se réduit, le système devient prévisible, le débit corrobore.
• 17:55
  A une concurrence de 16, le chemin dégradé ne produit qu'un filet.
• 17:58
  Les images par minute grimpent à peine avec les répliques car chaque instance se bloque elle-même.
• 18:02
  Passé à 32 multiplie la contention, pas la production.
• 18:05
  Après correction, la relation se redresse.
• 18:07
  Les images par minute augmentent presque linéairement jusqu'à ce que le cycle de service des coeurs tensoriels sature ou clavé RAM limite le lot.
• 18:13
  La différence de pente est la preuve irréfutable.
• 18:15
  Le travail franchit réellement la ligne d'arrivée plus vite, pas seulement plus bruyamment.
• 18:17
  L'utilisation clôt le dossier.
• 18:19
  Avant, le cycle d'utilisation du GPU stagne entre quelques pourcents et cinquante pourcents avec de longs creux plats.
• 18:24
  Les compteurs PCIe montrent l'agitation, des transferts paginables.
• 18:29
  Après, le cycle d'utilisation se stabilise dans une bande haute et constante avec un engagement visible des coeurs tensor.
• 18:36
  Le CPU revient à l'orchestration et au pré-traitement léger.
• 18:38
  Les pics PCIe diminuent car la mémoire verrouillée et la liaison IO ont éliminé le trafic inutile.
• 18:44
  Rien d'autre n'explique ce changement qu'une accélération réelle.
• 18:47
  Nous ajoutons une vérification de contraintes.
• 18:48
  Sous 512 par 512 à 25 étapes, le chemin optimisé soutient une concurrence de 1600 pics de latence.
• 18:54
  Poussez jusqu'à 32 et le système se dégrade gracieusement.
• 18:56
  Le P95 s'étend de manière prévisible, non chaotique.
• 19:00
  Sous 1024 par 1024 à 50 étapes, la différence est amplifiée.
• 19:03
  Le chemin non optimisé s'effondre sous les délais d'attente.
• 19:07
  Le chemin renforcé maintient P50 viable et un P95 acceptable avec un lot de 1 à 2 jusqu'aux limites de la VRAM.
• 19:13
  C'est là que les arènes et les flux importent.
• 19:15
  Après optimisation, le blocage en tête de ligne recule.
• 19:17
  L'angle des coups est une simple arithmétique.
• 19:19
  Les requêtes par heure.
• 19:20
  GPU grimpe de 2 à 5 fois une fois la tension fusionnée, FP16 et la liaison IO vérifiée.
• 19:26
  Le coût effectif par 1.0.0 images diminue en conséquence.
• 19:29
  Les pénalités de démarrage à froid diminuent car les images sont légères et les moteurs préconstruits.
• 19:32
  Les nœuds cessent de payer la taxe de compilation au premier axe.
• 19:35
  Le registre concorde avec lui journaux.
• 19:37
  La vérification empêche les exécutions chanceux.
• 19:39
  Répétez sur un second pool de nœuds avec une version mineure de pilote différente.
• 19:42
  L'image renforcée refuse de démarrer sur un nœud incompatible par conception, par conception.
• 19:46
  Ainsi, les résultats sont comparables, non confondus.
• 19:49
  Vérifiez les instantanées de capacité.
• 19:51
  Même ordre de fournisseur, même tensor RT, même assertion de noyaux.
• 19:55
  Relancez le jeu de requête et recoupez les distributions.
• 19:57
  Quand les histogrammes se chevauchent, la confiance augmente.
• 20:00
  Quand ce n'est pas le cas, le différentiel de capacité explique pourquoi.
• 20:03
  Final, les chiffres ne discutent pas.
• 20:04
  Ils condamnent.
• 20:05
  La latence se comprime, le débit s'adapte, l'utilisation se stabilise.
• 20:09
  La pathologie n'est pas hypothétique.
• 20:11
  Elle est mesurable et après coup, elle laisse des empreintes sur chaque graphique.
• 20:15
  Le protocole de remède.
• 20:16
  Une liste de contrôle de renforcement reproductible.
• 20:18
  Le contrôle d'admission passe en prenant.
• 20:20
  Refusez de démarrer si les fournisseurs d'exécutions tensor RT ou QTA ne sont pas présents.
• 20:24
  Énumérez les fournisseurs.
• 20:25
  Vérifiez le nombre de périphériques.
• 20:26
  Affichez les instantanées de capacité.
• 20:28
  QDNN, FP16, espace de travail INT8, espace de travail 8.
• 20:31
  Si quelque chose manque, sortez avec un code d'erreur non.
• 20:33
  La disponibilité suit l'intégrité.
• 20:35
  Le verrouillage des versions et la colle vertébrale.
• 20:37
  Maintenez une matrice unique.
• 20:38
  Branche de pilote, mineur QDA, versu DNN, H2Build, ONNX, Runtime, Tensor RT.
• 20:42
  Construisez des images d'inférence basées sur cette matrice.
• 20:45
  Étiquetez les nœuds pour qu'ils correspondent.
• 20:46
  Conditionnez l'admission sur l'égalité.
• 20:49
  Motor Tensor RT préconstruit par modèle et résolution.
• 20:51
  Les plans sont des artefacts, pas des conjectures à l'exécution.
• 20:54
  L'hygiène des conteneurs préserve la vérité.
• 20:56
  Utilisez des builds multi-étapes.
• 20:58
  Gardez le Runtime Distroless ou léger.
• 21:00
  Incluez un Docker Ignore strict.
• 21:02
  Vérifiez avec l'historique Docker et un audit d'allègement.
• 21:04
  Définissez des budgets de taille de poule dans l'intégration.
• 21:06
  Rejetez les images trop lourdes.
• 21:07
  Signez les images et comparez les contenus par digest.
• 21:09
  Configurez d'abord le GPU, verrouillez l'ordre EP sur Tensor RT QDA.
• 21:13
  Désactivez le fournisseur CPU en production.
• 21:16
  Vérifiez la présence du pilote NVIDIA et la version du toolkit de conteneur NVIDIA.
• 21:20
  Demandez explicitement un GPU NVIDIA.com ou combinez les licences et vérifiez au démarrage.
• 21:24
  Optimisez le Runtime.
• 21:25
  Activez FP16 par défaut.
• 21:27
  Contrôlez INT8 par des vérifications de précision.
• 21:30
  Liez les E sur S directement à la mémoire du périphérique.
• 21:33
  Activez la mémoire épinglée.
• 21:34
  Choisissez les flux pour éviter le blocage en tête de ligne.
• 21:36
  Réajustez ou désactivez l'arène ORT QDA lorsqu'elle s'arrête au-delà du jeu de travail.
• 21:42
  Définissez les SLO de performance comme du code autotesté au démarrage avec une fenêtre latence pour prompt déterministe et un seuil d'utilisation.
• 21:47
  Échouez en cas de ralentissement des bacs-là.
• 21:49
  Ajoutez l'observabilité, des métriques GPU par requête, des alertes de chemin dégradé, des prompts canaris et des bases de référence différenciables.
• 21:56
  Déployez en bleu slash vert avec des seuils de performance et une restauration automatique en cas de rupture.
• 22:00
  Avec ce protocole appliqué, l'accélération est prouvable, non supposée.
• 22:04
  La leçon est clinique.
• 22:06
  Le repli silencieux sur CPU, la dérive de version et l'encombrement des conteneurs ne sont pas des bugs.
• 22:10
  Ce sont des modèles de défaillance prévisibles que vous pouvez bloquer.
• 22:12
  Appliquez le protocole, instrumentez l'utilisation GPU, refusez les chemins dégradés, épinglez les versions, traitez les moteurs comme des artefacts.
• 22:18
  Pour une analyse plus approfondie du comportement mémoire d'ONNX Runtime et TensorRT et savoir quand désactiver les arènes,
• 22:23
  regardez le prochain épisode de cette série et abonnez-vous pour les notes de laboratoire.
• 22:26
  Merci d'avoir regardé cette vidéo !