Un contexte long transforme l'inférence en un problème de gestion de la mémoire

Le même modèle peut créer des charges différentes

Une question courte et une longue analyse de document peuvent utiliser le même modèle tout en imposant des exigences très différentes au système. Plus de contexte doit être traité et le service doit conserver son état de fonctionnement lorsqu'il génère une réponse. Plusieurs demandes simultanées multiplient ces demandes.

C'est pourquoi une démonstration avec une seule invite constitue une base faible pour dimensionner un service de production. Le profil de mémoire dépend de la combinaison de requêtes et des paramètres utilisés, et pas seulement du nombre de paramètres imprimés sur la carte modèle.

Le pré-remplissage et le décodage effectuent un travail différent

L'inférence distingue généralement le traitement de l'entrée, souvent appelé pré-remplissage, de la génération ultérieure de jetons de sortie, ou décodage. Ces étapes peuvent bénéficier de différents choix de planification et de ressources. L'architecture Dynamo de NVIDIA prend explicitement en charge l'inférence désagrégée, le routage qui prend en compte le contexte mis en cache et la gestion du cache entre les niveaux de mémoire. NVIDIA Dynamo : architecture d'inférence distribuée ↗

Cela prouve que la pile logicielle résout le problème. Nous ne prétendons pas que la séparation des étapes améliorera chaque déploiement. Une coordination et un déplacement de données supplémentaires ont des coûts, et un petit service peut ne pas avoir besoin de la complexité d'une conception distribuée.

Le contexte mis en cache est utile, mais pas gratuit

La réutilisation d'un état mis en cache approprié peut éviter un travail répété. Maintenir cet état consomme des ressources et le déplacer entre des emplacements ou des niveaux de mémoire peut introduire du trafic et de la latence. L’avantage dépend de la question de savoir si les demandes réutilisent réellement suffisamment de contexte pour justifier l’arrangement.

Un assistant documentaire posant des questions de manière répétée sur le même matériel peut se comporter différemment d'un service recevant des demandes sans rapport. Un benchmark doit représenter le modèle de réutilisation attendu plutôt que de supposer que chaque requête est un accès au cache.

Cela devrait également inclure ce qui se passe lorsque le cache est froid, plein ou indisponible. Ces conditions sont importantes lors des redémarrages et des pics de demande, lorsqu’un service dispose souvent du moins de capacité disponible.

Taille de la distribution des requêtes

Mesurez les entrées typiques et exigeantes, les longueurs de sortie attendues et la concurrence réaliste. Enregistrez l’utilisation maximale de la mémoire, le temps nécessaire à la première sortie et les performances de génération soutenues. Gardez les paramètres de qualité de sortie fixes lorsque vous comparez les systèmes.

Le résultat peut suggérer un accélérateur de mémoire plus grand, une stratégie de planification différente ou une limite d'application plus stricte en termes de contexte. Cela peut également révéler que les modifications logicielles fournissent une capacité suffisante sans remplacement matériel.

La leçon d'achat est d'éviter de traiter la mémoire comme un calcul statique de la taille d'un modèle. Un service d’inférence fonctionnel a une population de requêtes changeante. Comprendre cette population donne une base beaucoup plus solide pour choisir la mémoire GPU, les ressources hôtes et le logiciel utilisé pour les coordonner.