Ingenierie des performances IA : une echelle de preuves de performance du GPU a la production pour les goulots d'etranglement d'inference

Pourquoi l'utilisation du GPU n'est pas un diagnostic de performance

Un service d'inference GPU peut sembler sain dans un tableau de bord et rester lent pour les utilisateurs. Le peripherique est occupe. Les requetes attendent. La latence de queue derive. Les nouvelles tentatives consomment la capacite. Certaines sorties ne passent jamais l'acceptation produit. Tous ces faits peuvent etre vrais en meme temps.

L'utilisation du GPU est souvent la metrique de titre la moins utile lors d'un incident d'inference. Elle indique que le materiel a travaille. Elle n'indique pas si le bon travail s'est termine dans les regles de charge de travail et de qualite dont le produit a besoin.

La carte de ressources Wafer AI Performance Engineering V2 aide parce qu'elle rassemble les couches que les equipes doivent generalement raisonner, de l'execution CUDA et du profilage aux kernels, aux systemes de service et a la communication distribuee. Une carte de ressources n'est toujours pas une methode d'acceptation. Les equipes ont besoin d'un chemin allant du symptome a la preuve, puis de la preuve a un changement de production avec un plan de retour arriere.

Pour l'inference en production, l'unite pratique est la tache acceptee sous un contrat de charge de travail defini. Cela signifie que p50, p95, p99, le temps jusqu'au premier token, la latence inter-token, le temps de file d'attente, la longueur du prompt, la longueur de sortie, la concurrence, le batching, le taux d'erreur, le taux de nouvelles tentatives, le taux d'acceptation et le cout par tache acceptee doivent avancer ensemble dans l'analyse. Les tokens bruts par seconde ont leur place dans un essai de laboratoire. En production, une route plus rapide qui provoque plus de nouvelles tentatives ou echoue aux controles d'acceptation est pire, pas meilleure. Une latence moyenne plus basse peut aussi masquer une queue defaillante.

Cette meme posture centree sur les preuves apparait dans des guides d'infrastructure Optijara connexes, dont le test d'acceptation de route AI-in-RAN, le test d'acceptation checkpoint-to-bundle TensorRT Model Connect et le guide QRAT Qwen3.8-27B. Le principe est le meme ici. Definissez le dossier de preuves avant de changer le systeme. Pour les produits IA exposes a la recherche, cette discipline s'associe aussi a la mise a jour anti-spam d'aout de Google et a la checklist GEO d'Optijara, ou les affirmations etayees par des sources comptent plus qu'un score unique bien net.

L'Optijara Performance Evidence Ladder (PEL)

L'Optijara Performance Evidence Ladder, ou PEL, est une methode de diagnostic en cinq etapes pour le travail d'inference du GPU a la production. Elle existe pour arreter un schema d'echec courant : quelqu'un voit un symptome, choisit son correctif prefere, puis cherche des metriques qui rendent ce correctif raisonnable. PEL ralentit juste assez ce mouvement pour placer les preuves dans le bon ordre.

Etape 1 : trace des requetes et de la charge de travail

Commencez la ou l'utilisateur ressent le systeme. Capturez le taux d'arrivee des requetes, les bandes de concurrence, la distribution de longueur des prompts, la distribution de longueur des sorties, le comportement de batching, le temps de file d'attente, le temps jusqu'au premier token, la latence inter-token, p50, p95, p99, les echecs, les nouvelles tentatives et le statut d'acceptation. Si le service gere differents types de taches, separez-les. Les appels de retrieval, les workflows avec outils, le chat en streaming et les requetes a long contexte peuvent atteindre des limites differentes.

Le resultat est un contrat de charge de travail. Il indique ce qui est servi, sous quelles contraintes, et ce qui compte comme accepte. Sans lui, les preuves GPU ulterieures peuvent accelerer la mauvaise route.

Etape 2 : preuves d'execution GPU et de memoire

L'etape 2 demande ce que le peripherique et l'hote font reellement. La documentation CUDA fournit le modele mental de l'execution, de la hierarchie des threads, de la hierarchie memoire et de la synchronisation. Nsight Systems aide les equipes a inspecter l'activite CPU, les appels d'API CUDA, les kernels GPU, les operations memoire et les intervalles entre eux sur une meme chronologie.

Ne poursuivez pas une barre d'activite plus remplie. Cherchez les causes. Un intervalle entre kernels n'est pas la meme chose qu'une pression sur la bande passante memoire. Un delai de synchronisation n'est pas la meme chose qu'un kernel lent. L'admission des requetes cote hote n'est pas l'execution cote peripherique. L'etape 2 doit nommer la classe de preuve avant que quelqu'un ne reecrive des kernels ou ne change des reglages de service.

Etape 3 : preuves sur les kernels et les operateurs

L'etape 3 passe des chronologies aux operateurs et aux kernels. PyTorch profiler peut montrer les chemins d'operateurs, le temps CPU et CUDA, le comportement memoire et les traces qui revelent quelles operations du modele dominent une execution. Les diagnostics PyTorch compile comptent lorsque la capture de graphe, la fusion ou le comportement de fallback changent le chemin d'execution. Triton entre en jeu lorsqu'une equipe doit inspecter des kernels personnalises, des formes de tuiles, le mouvement memoire et la frontiere entre la logique au niveau Python et le travail au niveau peripherique.

C'est ici que se placent l'intensite arithmetique, la pression sur la bande passante memoire, la fusion d'operateurs, les chemins de quantization et les schemas de lancement de kernels. C'est aussi ici que se produisent des erreurs couteuses. La quantization, la compilation et les kernels personnalises peuvent changer le comportement des sorties, l'observabilite, les proprietes numeriques et le cout de retour arriere. Testez le candidat face a l'acceptation des taches, pas seulement face a une trace de latence.

Etape 4 : preuves de planification du moteur d'inference et de cache

L'etape 4 examine le moteur de service. Des systemes comme vLLM exposent des metriques autour des requetes, des tokens, du comportement du planificateur, de l'etat du cache et de la mise en file d'attente. Cette couche compte parce que le service de LLM n'est pas seulement l'execution du modele. Il inclut le prefill, le decode, le batching continu, l'admission des requetes, la pression sur le cache KV, le melange de longueurs de prompts et de sorties, le comportement a froid, le comportement a chaud et les decisions du planificateur.

Un temps jusqu'au premier token eleve peut venir de la file d'attente, du cout de prefill, des demarrages a froid, du controle d'admission ou de l'etat du cache. Une latence inter-token elevee peut venir du comportement de decode, de la pression memoire, de l'efficacite des kernels, de la planification ou de la communication. PEL garde ces hypotheses separees jusqu'a ce que les preuves pointent vers l'une d'elles.

Etape 5 : preuves de service distribue et de capacite

L'etape 5 s'applique lorsqu'un GPU unique n'est pas tout le systeme. L'inference distribuee peut impliquer le parallelisme tensoriel, le parallelisme de pipeline, les collectives, le mouvement reseau, la capacite au niveau noeud, le placement, le transfert de donnees et les domaines de defaillance. La documentation NCCL compte ici parce que les collectives et le comportement de communication peuvent faire partie du chemin de service.

A ce stade, le dossier d'acceptation doit inclure le perimetre du canary, le declencheur de retour arriere, les conditions d'arret et les preuves de capacite. Un changement de topologie n'est pas accepte parce qu'un benchmark s'ameliore. Il est accepte lorsque le contrat de charge de travail, la latence de queue, les erreurs, les nouvelles tentatives, les criteres d'acceptation et le risque operationnel restent dans les bornes convenues.

Une matrice de decision sur les goulots d'etranglement pour l'inference en production

Arretez le profilage lorsque quatre choses sont vraies : le goulot d'etranglement est reproduit, la couche responsable est identifiee, l'impact sur l'acceptation est visible et le seuil de retour arriere est defini. Le profilage peut changer le comportement de la charge de travail, donc plus de traces n'est pas automatiquement meilleur. Le bon point d'arret est d'avoir assez de preuves pour prendre une decision sans pretendre que la trace est le produit.

Checklist de mise en oeuvre : de l'execution benchmark au changement de production accepte

Gardez separees les comparaisons a froid, a chaud et canary. Les executions a froid exposent les effets de demarrage, de compilation, de remplissage du cache ou de chargement du modele. Les executions a chaud montrent le comportement en regime etabli sous le contrat de charge de travail. Les executions canary repondent a la question de production : ce candidat se comporte-t-il assez bien sur du trafic reel sans exposer toute la charge de travail a un risque evitable ?

Preuves propres a chaque outil : ou chaque source s'insere dans PEL

La documentation CUDA soutient l'etape 2 parce qu'elle donne le modele des threads, des blocs, de la hierarchie memoire, de la synchronisation et du comportement d'execution. Nsight Systems soutient la meme etape sous l'angle de la chronologie, surtout lorsque les equipes doivent voir ensemble le travail CPU, les kernels GPU, les API CUDA, les operations memoire et les intervalles.

PyTorch profiler soutient l'etape 3 en rendant visible le comportement au niveau des operateurs. Les diagnostics PyTorch compile peuvent compter lorsqu'une route compilee change le comportement du graphe, la fusion ou les chemins de fallback. Triton s'insere dans l'etape 3 lorsque les operateurs standard ne suffisent pas ou lorsqu'un chemin de kernel personnalise doit etre inspecte. Cela ne veut pas dire que chaque goulot d'etranglement merite un kernel personnalise. PEL demande aux equipes de prouver d'abord que le goulot d'etranglement vit a cette couche.

Les metriques vLLM s'inserent dans l'etape 4 parce que le comportement de service explique souvent des symptomes que les metriques au niveau GPU ne peuvent pas expliquer. L'etat du planificateur, le comportement du cache, les metriques de requetes, les metriques de tokens et la mise en file d'attente peuvent montrer si le probleme releve de l'admission, du batching, du prefill, du decode ou de la pression sur le cache. NCCL s'insere dans l'etape 5 lorsque la communication distribuee fait partie du chemin de service.

Ce que les equipes se trompent en optimisant l'inference GPU

Traiter l'utilisation comme la reponse

L'utilisation est facile a observer et facile a surinterpreter. Elle ne dit pas a une equipe si les utilisateurs sont en file d'attente, si la latence p99 est acceptable, si les nouvelles tentatives augmentent ou si la tache a ete acceptee. Utilisez-la comme un signal en etape 2, pas comme la metrique de titre.

Optimiser les tokens de benchmark au lieu des taches acceptees

Les tokens par seconde peuvent aider dans une experience controlee, mais les systemes de production terminent des taches. Une route qui emet des tokens rapidement tout en echouant aux controles d'acceptation, en augmentant les erreurs ou en demandant plus de nouvelles tentatives n'est pas meilleure. Le debit de taches acceptees est l'unite orientee metier la plus sure.

Changer le batching sans proteger la latence de queue

Le batching et le batching continu peuvent ameliorer l'utilisation du materiel dans certaines charges de travail. Ils interagissent aussi avec le temps de file d'attente, le TTFT, la longueur de sortie et p99. Evaluez un changement de batching par type de tache et bande de concurrence, pas seulement par debit agrege.

Ignorer la staleur du cache et la derive de charge de travail

Le comportement du cache KV, les distributions de prompts, les longueurs de sortie et les schemas de retrieval peuvent deriver. Une execution qui semble bonne sur une ancienne charge de travail peut echouer lorsque le melange de requetes change. Gardez les contrats de charge de travail versionnes et repetables.

Profiler d'une maniere qui change la charge de travail

Le profilage ajoute une surcharge et peut modifier les timings. Cela ne rend pas le profilage inutilisable. Cela signifie que la surcharge doit etre etiquetee, que les executions profilees et non profilees doivent etre comparees avec soin, et que le comportement de trace ne doit pas etre traite comme l'etat naturel du systeme.

Mises en garde et compromis : le travail de performance est un systeme d'ingenierie

Les preuves de performance reduisent les conjectures, mais elles ne suppriment pas le cout de mise en oeuvre. L'instrumentation prend du temps. La collecte de traces peut soulever des enjeux de confidentialite et de securite parce que les prompts, sorties, identifiants et metadonnees operationnelles peuvent etre sensibles. Les journaux doivent etre minimises, soumis a un controle d'acces et conserves seulement aussi longtemps que necessaire.

L'optimisation peut aussi affecter la qualite. La quantization peut changer le comportement des sorties. La compilation peut modifier les chemins d'execution. Les changements de kernels peuvent creer des problemes de correction ou de portabilite. Les changements de planificateur et de cache peuvent deplacer la latence entre types de requetes. Les changements de topologie distribuee peuvent ameliorer un chemin tout en ajoutant un cout de communication ou une complexite operationnelle ailleurs.

Les variations de fournisseur, de materiel, de pilote, de framework et de modele comptent. Les preuves d'un environnement ne doivent pas etre copiees dans un autre comme un resultat garanti. PEL rend ces hypotheses explicites au lieu de les cacher derriere une moyenne confiante. Le cout par tache acceptee peut etre utile, mais seulement lorsque l'attribution des couts est definie.

PEL en pratique : un flux de preuves compact et un resume lisible par machine

{
  "framework": "Optijara Performance Evidence Ladder",
  "stages": [
    {"stage": 1, "name": "request_trace", "signals": ["p50", "p95", "p99", "TTFT", "queue_time", "acceptance_rate"]},
    {"stage": 2, "name": "gpu_execution_memory", "signals": ["kernel_gaps", "memory_movement", "occupancy", "synchronization"]},
    {"stage": 3, "name": "kernel_operator", "signals": ["operator_time", "arithmetic_intensity", "bandwidth_pressure", "compile_path"]},
    {"stage": 4, "name": "serving_scheduler_cache", "signals": ["prefill", "decode", "KV_cache", "batching", "admission"]},
    {"stage": 5, "name": "distributed_capacity", "signals": ["collectives", "network_movement", "placement", "canary", "rollback"]}
  ],
  "acceptance_unit": "cost_per_accepted_task_under_workload_contract",
  "stop_conditions": ["reproduced_bottleneck", "owner_layer_identified", "acceptance_impact_visible", "rollback_threshold_defined"]
}

La question de travail pour PEL est directe : quelle couche limite les taches acceptees, quelle preuve le demontre, et quel changement de production peut etre livre avec un plan de retour arriere clair ? Si la reponse reste que le GPU est occupe, le diagnostic n'est pas termine.