Un service d’IA local peut-il basculer sur le processeur lorsque la mémoire du GPU est pleine ?
Oui, mais un basculement fiable vers le processeur doit être conçu avant que la mémoire du GPU ne soit saturée ; la plupart des processus d’inférence ne récupèrent pas automatiquement d’un dépassement de mémoire inattendu.
Un serveur IA domestique peut répondre rapidement sur son GPU jusqu’à ce qu’un prompt plus long, un lot plus volumineux, une requête d’image ou un second modèle consomme la VRAM restante. L’allocation suivante peut alors échouer, même si la mémoire vive et le processeur sont inactifs. La survie de la requête dépend de l’environnement d’exécution : certains peuvent placer les poids sur le processeur dès le départ, tandis que d’autres nécessitent un processus distinct sur le processeur et un routeur capable de réessayer sans risque.
Le déchargement vers le processeur et le basculement vers le processeur répondent à des problèmes différents
Le déchargement vers le processeur est une stratégie de placement du modèle. Certaines couches, certains tenseurs ou composants du pipeline résident dans la mémoire vive et sont transférés vers l’accélérateur lorsque nécessaire, ce qui réduit la VRAM requise pour une requête normale. Le basculement vers le processeur est un comportement du service : lorsque le chemin GPU est indisponible ou rejette une requête, un autre processus l’accepte et exécute un modèle compatible avec le processeur sans perdre la tâche.
Hugging Face Accelerate propose des méthodes de déchargement vers le processeur qui déplacent délibérément l’état du modèle entre la mémoire du processeur et un périphérique d’exécution. Il s’agit d’une exécution hétérogène planifiée, et non d’une intervention d’urgence après l’échec d’un état CUDA arbitraire. Le modèle, la répartition des périphériques, les hooks et le budget mémoire sont préparés avant le début de l’inférence.
Un modèle partiellement déchargé peut déjà utiliser le processeur tout en dépendant du GPU pour chaque token. Si le GPU tombe en panne, ce processus ne peut pas nécessairement poursuivre l’exécution sur le processeur à partir du token interrompu. Un véritable basculement redémarre généralement la requête sur un processus prêt à fonctionner sur le processeur. Cette distinction explique pourquoi une application peut annoncer la prise en charge du processeur tout en renvoyant une erreur de dépassement de mémoire au lieu de terminer la requête en cours.
La VRAM peut se remplir après le chargement réussi d’un modèle
Les poids du modèle ne représentent qu’une partie du budget mémoire. Le cache clé-valeur augmente avec la longueur de séquence active et la concurrence, les noyaux temporaires ont besoin d’espace de travail, les encodeurs d’image ou audio ajoutent des tenseurs, et un allocateur mémoire peut réserver des blocs pour les réutiliser. Un modèle qui tient au démarrage peut donc échouer avec un contexte long ou plusieurs utilisateurs simultanés.
PyTorch utilise un allocateur mémoire avec mise en cache ; la mémoire indiquée comme réservée ne correspond donc pas exactement à la mémoire occupée par les tenseurs actifs. La fragmentation et les allocations effectuées en dehors du framework peuvent réduire davantage la marge disponible. Un déclencheur de basculement doit surveiller les allocations rejetées et l’état des processus, plutôt que de déduire la sécurité d’un seul indicateur de tableau de bord ou du simple fait que le chargement du modèle a réussi.
C’est également pourquoi une règle statique du type « taille du modèle inférieure à la VRAM » est incomplète. Un service peut limiter la longueur du contexte, plafonner le nombre de séquences simultanées ou laisser un pourcentage de VRAM inutilisé afin de protéger les allocations d’exécution. Ces contrôles évitent davantage de défaillances qu’un basculement réactif vers le processeur, car ils maintiennent le processus GPU dans un état connu et préservent une latence prévisible pour les requêtes acceptées.
La nouvelle tentative automatique n’est sûre que si la requête peut être rejouée
Après un dépassement de mémoire, le routeur peut considérer le processus GPU comme défaillant, le libérer ou le redémarrer, puis rejouer la requête d’origine sur un processus fonctionnant sur le processeur. Cela fonctionne pour une génération de texte ordinaire lorsqu’aucun effet externe ne s’est produit. La tâche est plus complexe avec les réponses en continu, les pipelines d’images utilisant des graines aléatoires ou les agents qui ont peut-être déjà appelé un outil.
Les frameworks peuvent également répartir les grands modèles entre plusieurs périphériques dès le départ. L’inférence de grands modèles d’Accelerate prend en charge les répartitions de périphériques ainsi que le placement sur le processeur ou le disque lorsqu’un modèle dépasse les capacités d’un seul périphérique. Cette approche peut maintenir une requête active au sein d’un graphe d’exécution planifié, mais elle échange de la vitesse contre de la capacité et ne doit pas être confondue avec le routage d’une requête échouée vers un service distinct.
Le basculement cesse d’être applicable lorsque le processeur ne dispose pas de suffisamment de mémoire vive, que l’environnement d’exécution ne possède pas de noyaux compatibles avec le processeur, que la requête a déjà produit une action irréversible ou que la latence attendue sur le processeur dépasse le délai d’attente du client. Dans ces cas, renvoyez une erreur de capacité contrôlée ou placez la requête en file d’attente. Une nouvelle tentative silencieuse peut dupliquer des effets externes ou faire patienter les utilisateurs bien plus longtemps que ce que l’interface promet.
Validez le basculement avec un test mémoire délibéré
Exécutez un processus GPU et un processus processeur derrière un routeur, puis envoyez une requête qui dépasse le profil GPU sans dépasser la mémoire vive du système. Enregistrez la première défaillance, la décision de nouvelle tentative, l’heure de démarrage sur le processeur, la sortie finale et la survie de la connexion client. Répétez d’abord avec la diffusion en continu désactivée, puis testez l’annulation, le trafic concurrent et une requête d’agent avec un outil simulé.
L’exécution partielle sur GPU constitue une base de comparaison utile, car des environnements tels que l’inférence llama.cpp peuvent placer une portion configurable du traitement du modèle sur des accélérateurs tout en conservant une exécution sur le processeur. Comparez les profils avec modèle entièrement sur le GPU, répartition processeur/GPU planifiée et solution de secours indépendante sur le processeur. Un modèle de charge de travail IA hybride aide à distinguer le basculement pour manque de capacité du routage cloud habituel.
Ne considérez la conception comme fiable que si la nouvelle tentative aboutit une seule fois, conserve l’identité de la requête, évite les actions d’outil en double et restaure le processus GPU sans interrompre les tâches indépendantes. Si l’exécution sur le processeur est trop lente, utilisez-la comme voie de sécurité préservant la file d’attente plutôt que comme équivalent interactif. L’objectif opérationnel est une dégradation progressive, et non de prétendre que les niveaux de service du processeur et du GPU sont interchangeables.
| Comportement | Préparé avant le dépassement de mémoire ? | Peut sauvegarder la requête en cours ? |
|---|---|---|
| Déchargement processeur/GPU | Oui | Généralement, dans le graphe planifié |
| Réduction de la concurrence GPU | Oui | Empêche l’admission d’un travail risqué |
| Nouvelle tentative sur le processeur par le routeur | Oui | Oui, si la requête peut être rejouée |
| Basculement non planifié au sein du processus | Non | Généralement non |
FAQ
Vider le cache du GPU déclenche-t-il un basculement ?
Non. La libération du cache peut rendre disponibles des blocs réservés inutilisés, mais elle ne crée pas d’exécution sur le processeur, ne répare pas l’état corrompu d’une requête et ne garantit pas une quantité suffisante de mémoire contiguë pour l’allocation suivante.
Le basculement vers le processeur produira-t-il la même réponse ?
C’est possible si les mêmes poids, la même précision, le même prompt, le même tokenizer et le même état d’échantillonnage sont utilisés. Des noyaux différents, la quantification, les graines ou l’état redémarré d’une diffusion en continu peuvent toutefois modifier la sortie exacte.
Un modèle plus petit est-il préférable au basculement vers le processeur ?
Souvent, pour un service interactif. Un modèle GPU plus petit peut offrir une latence prévisible, tandis que le basculement vers le processeur protège la disponibilité pour les requêtes exceptionnelles. Ces deux mécanismes répondent à des objectifs de service différents et peuvent être combinés.
Produits recommandés
Centre Tech & IA
Plus à lire
Comment un courtier secret fournit-il des identifiants à un agent d’IA sans les exposer dans les prompts ?
Suivez l’identité de charge de travail, les politiques, l’émission de jetons, l’injection des requêtes, la rédaction, l’expiration et la révocation au sein d’une architecture...
Comment un bac à sable d’outils contient-il les effets secondaires des agents d’IA ?
Découvrez comment l’isolation, les contrôles de capacité, l’état jetable, le contrôle des sorties réseau, les quotas et les journaux d’audit limitent les effets secondaires...
Comment le décodage contraint produit-il un JSON valide selon le schéma ?
Comprenez la compilation des schémas, le masquage des jetons, l’état de l’analyseur, les sous-ensembles pris en charge, la latence, la troncature et pourquoi la...
