Quelles sont les causes des défaillances du serving de LLM et comment les corriger ?
Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
Les défaillances du serving de LLM viennent souvent d’une mémoire insuffisante, d’un volume de travail simultané supérieur à ce que le service peut traiter ou de nouvelles tentatives qui répètent des requêtes coûteuses. Identifiez la ressource ou l’étape qui échoue avant de modifier le runtime. Le chargement réussi d’un modèle ne prouve pas qu’il peut traiter le trafic prévu.
Associez le symptôme aux données observées
| Symptôme | Premières données à examiner | Modification à tester |
|---|---|---|
| Erreur de mémoire insuffisante sur GPU | Poids, allocation KV, activations, longueurs des requêtes | Lot actif plus petit, limites plus courtes ou quantification prise en charge |
| La latence augmente sans erreur | Utilisation de KV, préemptions, requêtes en attente | Moins de requêtes admises simultanément ou davantage de capacité confirmée par des mesures |
| Premier token lent | File d’attente, tokenisation, prefill, temps réseau | Corriger l’étape lente ; tester le prefill par blocs si les phases interfèrent |
| La charge augmente après des expirations de délai | Nombre de nouvelles tentatives et travail encore en cours | Nouvelles tentatives limitées et annulation du travail abandonné |
Le stockage des poids et le stockage KV sont distincts. Un modèle de 70B en FP16 nécessite environ 140 GB pour les seules valeurs des poids. Avec une organisation classique du cache à attention complète, une séquence de Llama 3.1 70B de 128K tokens ajoute 40 GiB de données KV en FP16, avant le surcoût du runtime. Aucun de ces chiffres ne représente à lui seul le besoin total en mémoire.
Vérifiez les préemptions avant d’agrandir la file
Lorsque l’espace KV ne suffit pas, un moteur de serving peut préempter des requêtes. vLLM V1 recalcule normalement le travail préempté, ce qui augmente la latence même si l’API finit par répondre correctement. Mettez le nombre de préemptions en relation avec les longueurs des prompts, les séquences actives et l’utilisation de KV.
Réduisez le travail admis ou modifiez l’allocation mémoire testée. Pour augmenter l’utilisation de la mémoire GPU, vérifiez que les autres allocations tiennent toujours en mémoire. Déplacer des données KV réutilisables vers le CPU ou le disque ajoute aussi des transferts ; cela ne garantit pas qu’une requête active trop volumineuse tienne en mémoire.
Limitez les nouvelles tentatives
Réessayez après un échec transitoire dans la limite d’un délai et d’un budget de nouvelles tentatives. Utilisez des délais progressifs avec une variation aléatoire et confiez les nouvelles tentatives à une seule couche pour que celles de la passerelle et du client ne se multiplient pas. Le guide SRE de Google explique comment les nouvelles tentatives peuvent aggraver la surcharge.
Propagez l’annulation lorsque l’appelant abandonne, vérifiez que la génération s’arrête et testez ce comportement sous charge. Une file plus grande retarde le rejet, mais ne crée pas de capacité de traitement.
Consultez la section modes de défaillance du serving de LLM du guide pour les concepts de mémoire et d’ordonnancement associés.