Mesurer les coûts de transfert et de capacité avant de déplacer les données ou le travail du service d’inférence GPU

Un modèle peut dépasser la mémoire du GPU, une longue requête peut occuper l’interface de traitement du texte, et la récupération d’une requête mise en cache peut prendre du temps. Déplacer les données ou le travail peut alléger chacune de ces contraintes, mais le nouvel emplacement a son propre coût.

À travers les trois études, la question utile est de savoir quelle contrainte mesurée un changement d’emplacement réduit.

La réponse dépend de la charge de travail testée : l’accès à la mémoire de l’hôte peut ralentir la génération, la préparation du texte sur GPU peut augmenter la capacité de l’interface, et le chargement d’un cache distant peut prendre plus de temps que le recalcul.

Imaginez que vous serviez un modèle dont les données dépassent la mémoire du GPU. Garder une partie des données dans la mémoire de l’hôte permet au modèle de fonctionner, mais le GPU doit les lire en passant par une interconnexion.

Déplacer les données dans la mémoire du GPU accélère leur accès, mais occupe un espace dont une autre partie du modèle pourrait bientôt avoir besoin. Ember, un gestionnaire de mémoire conçu pour les charges de travail qui dépassent la mémoire du GPU, étudie ce choix pendant la génération de texte. Il s’agit de décider où placer les données que le GPU utilise de façon répétée.

Une autre requête peut mettre le système sous pression avant même le début du calcul du modèle. Un agent peut renvoyer une longue conversation en n’ajoutant que peu de texte.

Un cache peut éviter au modèle de refaire une grande partie du travail sur le début répété, mais l’interface de service doit toujours convertir le texte reçu en identifiants de jetons, c’est-à-dire en une suite ordonnée d’identifiants que le modèle lit.

GraphTok étudie le transfert de cette préparation du processeur (CPU) vers un processeur graphique (GPU). Il mobilise une partie de la capacité du GPU pour alléger une contrainte de l’interface, plutôt que pour faire de la place aux données stockées du modèle.

Il existe une troisième possibilité pour les requêtes répétées : stocker les résultats du traitement antérieur d’une requête et les récupérer pour les réutiliser. Cet état stocké s’appelle un cache KV.

Une copie distante n’économise du calcul sur le GPU que si sa récupération répond à l’objectif visé à un coût acceptable. L’étude sur le cache distant cherche à déterminer à quelle vitesse cet état doit être transféré et quel travail le moteur doit encore effectuer lorsqu’il le trouve.

Ensemble, ces cas posent une question de déploiement : quel coût chaque déplacement élimine-t-il, et quel nouveau coût entraîne-t-il ?