Profile vLLM Performance

Trouvez le mécanisme de perte dominant, prouvez-le avec une chronologie corrélée, effectuez le plus petit changement causal, et validez le résultat avec une exécution A/B appairée. Un nombre de capacité ou un échantillon moyen d'utilisation GPU n'est pas une attribution de bubble.

Figer La Comparaison

Enregistrez le code exact, le conteneur, la révision du modèle, la précision, le matériel, les paramètres du planificateur, la forme de la charge de travail, les médias, le prompt, le budget de tokens, l'échantillonnage, l'état du cache, la concurrence, et les critères de succès. Prouvez la correction sémantique avant d'optimiser. Ne comparez pas les durées d'exécution quand l'une de ces dimensions diffère, sauf si cette dimension est la variable déclarée.

Établir Le Signal

1. Vérifiez les nombres réels de tokens de sortie, le travail réussi, la couverture de flux frais, les chunks supprimés, les annulations, et le nettoyage. Un EOS précoce ou un échec silencieux n'est pas un débit.
2. Reproduisez à charge fixe sous le point d'inflexion, près du point stable le plus élevé, et juste au-delà quand c'est pratique. Gardez la recherche de capacité séparée du profiling.
3. Enregistrez TTFT, la latence inter-token, le débit, le délai de queue, la taille du batch, les tokens planifiés, les séquences actives, les préemptions, l'occupation KV, la mémoire GPU, et les durées de phases disponibles dans la version vérifiée.
4. Utilisez DCGM limité au scénario ou nvidia-smi dmon pour l'enveloppe de ressources et une capture courte de Nsight Systems ou du profiler du repository pour l'attribution. Les profilers perturbent le timing ; n'utilisez jamais une exécution profilee comme résultat de capacité.

Définissez une performance bubble comme un temps GPU inactif ou à faible occupation pendant que du travail éligible est en queue. Le temps d'inactivité causé par une charge offerte insuffisante n'est pas une bubble d'exécution. Si la queue du planificateur est vide tout au long de chaque intervalle d'inactivité observé, vérifiez d'abord si du travail éligible attend en amont dans l'arrivée média, le décodage, le prétraitement, ou la soumission au moteur. Le travail d'attente en amont est une famine frontale ou média, pas un manque de charge offerte. Quand ni le planificateur ni les étapes en amont n'ont de travail éligible en attente, classifiez le résultat comme charge offerte insuffisante et faites de la première expérience une relecture à concurrence fixe plus élevée avec chaque autre dimension de charge inchangée. Ne recommandez pas d'optimisation du planificateur, kernel, batching, cache, prefill, ou decode jusqu'à ce que cette relecture montre une GPU inactive avec du travail éligible restant en queue.

Corréler La Chronologie

Utilisez des identifiants stables de request, séquence, stream, et chunk à travers :

• l'arrivée média et le décodage ;
• la sélection de frame CPU, le redimensionnement, la normalisation, la tokenization, et le travail du processeur ;
• le transfert host-vers-device et la synchronisation ;
• l'encodeur de vision et le projecteur ;
• le prefill texte et visuel ;
• l'admission du planificateur, la formation de batch, l'allocation KV, la préemption, et la dispatch ;
• le décodage, l'échantillonnage, la détokenization, et la livraison de sortie.

Capturez uniquement assez de NVTX ou de timing structuré pour aligner ces phases avec les kernels CUDA, les copies mémoire, les réveils CPU, et l'état du planificateur. Évitez la journalisation à haut volume dans le chemin mesuré.

Consultez references/bubble-playbook.md pour la matrice de preuve et l'expérience discriminante la plus courte pour chaque classe de bubble.

Prouver La Bubble Dominante

Pour chaque candidat, énoncez l'intervalle précis d'inactivité ou de sous-occupation, si du travail éligible était en queue, l'événement qui l'a immédiatement précédé, sa fréquence et sa part du temps mesuré, et l'observation qui écarte l'explication concurrente la plus proche. Classez les candidats par temps du chemin critique récupérable, pas par prominence visuelle dans une trace.

N'inférez pas un goulot d'étranglement de décodage d'un manque de capacité OSL seul. Comparez les chronologies prefill et decode à concurrence fixe appairée plus les tokens par étape de planificateur.

Pour la vision sérialisée, comparez d'abord un prétraitement par batch existant ou un chemin d'encodage de vision utilisant les mêmes formes visuelles fixes et le même ensemble de requests. Énoncez explicitement ses critères d'acceptation : exigez la parité de sortie et la parité du nombre, de l'ordre, et de la position des tokens visuels multimodaux avant d'attribuer tout amélioration de performance au changement.

Réparer Et Valider

Arrêtez au premier échelon qui supprime la bubble prouvée :

1. Corrigez les défauts de benchmark ou de configuration tels que EOS précoce, formes mal appairées, politique de cache, limites du planificateur, ou charge offerte insuffisante.
2. Réglez un knob runtime existant supporté par la version vérifiée.
3. Réutilisez un chemin de batching, prétraitement, cache, CUDA-graph, tensor-IPC, ou planificateur existant qui est configuré incorrectement ou contourné.
4. Corrigez une limite d'intégration qui sérialise ou copie du travail inutilement.
5. Modifiez le code de planification ou model-runner uniquement quand les traces prouvent que le chemin existant ne peut pas exprimer le chevauchement requis.
6. Modifiez un kernel uniquement après avoir écarté le lancement, la planification, la forme, et le mouvement de données.

Changez une variable causale à la fois. Répétez la trace courte, puis exécutez une comparaison A/B ou A/B/B/A appairée non profilee à concurrence fixe. Réexécutez la limite de capacité uniquement quand la capacité est la revendication. Préservez la parité de sortie, l'ordre, l'annulation, la durée de vie KV, et les invariants de token et position multimodaux.

Rapportez confirmé, amélioré, non concluant, ou comparaison invalide, suivi de la bubble dominante, l'estimation du temps récupérable, la preuve, les alternatives écartées, la correction, les distributions avant/après, les chemins d'artefacts, le goulot d'étranglement restant, et la plus petite expérience suivante.

N'installez pas de profilers, ne lancez pas de travail GPU coûteux, ne poussez pas de changements, ou ne mutez pas une machine partagée sans autorisation.