Comment planifier la capacité GPU et la mise à l’échelle automatique pour les LLMs ?
Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
Dimensionnez l’ensemble des répliques à partir du débit mesuré à la latence requise, puis vérifiez que chaque réplique peut contenir les séquences actives prévues. Utilisez les distributions réelles des longueurs de prompts et de sorties. Arrondissez au nombre supérieur de répliques complètes de serving, en incluant tous les GPUs nécessaires au parallélisme de tenseurs ou de pipeline.
Vérifier la mémoire avant le débit
Avec une organisation classique du cache à attention complète, Llama 3.1 70B nécessite 1.25 GiB de données KV en FP16 pour une séquence de 4,096 tokens. Un budget KV hypothétique de 40 GiB peut donc contenir au maximum 32 séquences de ce type, avant de prendre en compte la surcharge de l’allocateur et du runtime. À 131,072 tokens, une seule séquence utilise les 40 GiB entiers.
Comptez ensemble les tokens d’entrée et les tokens générés. La formule change pour des architectures telles que MLA et l’attention à fenêtre glissante, et l’allocation par appareil dépend du partitionnement. Il s’agit d’une limite de mémoire, pas d’une prédiction de la taille de lot qui respecte les objectifs de latence. Le calcul du KV cache dans le guide présente les hypothèses et un calcul exécutable.
Calculer des répliques entières
Supposons que les mesures montrent qu’une réplique à deux GPUs peut maintenir 1,200 tokens de sortie par seconde aux TTFT et TPOT requis, sur une charge de travail fixe. La demande de pointe prévue est de 4,000 tokens de sortie par seconde. Un facteur de sécurité hypothétique de 1.3 donne :
Cinq répliques à deux GPUs nécessitent dix GPUs. Ces chiffres illustrent le calcul ; ce ne sont pas des résultats de benchmarks matériels. Refaites les mesures lorsque le modèle, la distribution des contextes, la topologie ou le SLO change. Un facteur de 1.3 signifie un débit supérieur de 30% à la demande avant l’arrondi, et non 30% de capacité inutilisée.
Augmenter la capacité avant de dépasser les délais
Combinez la longueur de la file d’attente et le temps d’attente avec l’utilisation de KV, les préemptions et le goodput conforme au SLO. L’utilisation des GPUs peut rester élevée une fois le service surchargé. vLLM documente ces métriques de serving ; déduisez les seuils des tests de charge.
Mesurez le téléchargement des images, le chargement des poids, l’initialisation du modèle et la phase de préparation avant de choisir les seuils de mise à l’échelle automatique. Les commandes de mise à l’échelle des déploiements de KEDA permettent de réduire les charges de travail jusqu’à zéro, mais ne suppriment pas la latence de démarrage du modèle. Gardez de la capacité prête lorsque les requêtes ne peuvent pas attendre le démarrage.
Consultez la planification de capacité et la mise à l’échelle automatique dans le guide pour les décisions associées concernant le matériel et l’admission des requêtes.