Mesurer le goulot d’étranglement avant de déplacer le travail du GPU

Un modèle peut dépasser la mémoire du GPU, un flux vidéo peut aller plus vite que son processeur, et des appels répétés au modèle peuvent prendre du temps pour préparer le texte ou récupérer un état enregistré.

Chaque problème appelle un usage différent de la mémoire et du calcul, avec ses propres coûts de déplacement ou de préparation.

À travers quatre études, la première étape utile consiste à mesurer où une charge de travail donnée passe son temps.

Placer les données, préparer le travail à l’avance, transférer le traitement du texte vers le GPU et réutiliser un état distant modifient des coûts différents ; économiser du calcul ne réduit pas à lui seul la mémoire occupée et ne garantit pas une réponse plus rapide.

Imaginez un chatbot dont le modèle dépasse la mémoire du GPU, tandis qu’un autre service répond à des questions sur un flux vidéo en direct. Un assistant de programmation ajoute une difficulté : il renvoie une grande partie de la même longue conversation à chaque nouvel appel au modèle.

Ce sont des problèmes concrets de capacité et de délai. Garder les données du modèle près du GPU peut accélérer la génération ; préparer la vidéo peut accélérer une réponse ultérieure ; réutiliser une conversation précédente peut éviter une partie du calcul. Chaque choix mobilise une ressource ou déplace des données avant d’apporter son bénéfice.

Une réponse lente n’en indique pas la cause. Quand la mémoire du GPU est pleine, charger une autre page peut obliger à en évacuer une qui s’y trouve déjà.

Dans un service vidéo, préparer chaque image dès son arrivée pour toutes les questions possibles peut consommer la capacité de traitement nécessaire pour suivre le flux. Lors d’appels répétés au modèle, le texte doit toujours être converti en entrées pour le modèle, et récupérer un résultat stocké peut prendre du temps.

La question commune est de savoir où placer le travail et quand l’effectuer, compte tenu des limites d’une charge de travail précise.

Les quatre études modifient différentes parties de cette décision. Ember change l’emplacement des données gérées lorsqu’un GPU manque de mémoire.

StreamAhead décide quelle part du traitement vidéo effectuer avant l’arrivée d’une question, afin de créer des représentations réutilisables stockées. GraphTok déplace la conversion du texte du processeur hôte vers le GPU : il change ainsi l’endroit où le calcul s’exécute.

Une étude sur un cache distant demande si charger un état du modèle enregistré est plus rapide que le recalculer. Ces choix ne peuvent pas être résumés par une seule affirmation sur la vitesse, car ils évitent des calculs différents et entraînent des coûts distincts.